詞彙表

核心實體

代理：具備身分、角色、技能與配接器的 AI 工作者。恰好屬於一個工作區。系統中的主要行動者。

配接器：執行代理回合的執行器。產品內建兩種：Control Center（內建）——與模型供應商通訊的行程內執行框架——以及透過 claude -p 運行的 Claude Code。Cursor、Codex、Anthropic、OpenAI 等其餘的，都是內建配接器上的供應商，而非各自獨立的 CLI。參見管理配接器與模型。

工作區：最高層級的隔離租戶。把代理、程式庫、空間、工單、記憶與管線歸為一組。隔離是結構性的，而非約定俗成：每個工作區都有自己的 SQLite 檔案（<dataDir>/<workspaceId>/workspace.db），因此跨工作區讀取根本無法通過編譯。應用程式內每條路由都帶有 /workspaces/:workspaceId 前綴——參見路由圖。

程式碼託管平台：程式碼代管服務——GitHub、GitLab 或 Bitbucket Cloud。程式碼託管平台是每個程式庫的屬性，在註冊時從其 origin 遠端讀取，並決定該程式庫使用哪個 API 配接器與憑證。一個工作區可以同時容納來自這三者的程式庫；聚合類介面（收件箱、PR 佇列）會向所有出現的程式碼託管平台扇出並合併結果，同時隔離故障，令某個無法連線的程式碼託管平台絕不會令其他平台變空。各程式碼託管平台支援的能力不同——參見連接程式碼託管中的能力表。

程式庫：註冊在某個工作區內的 Git 儲存庫。以工作區為範圍——同一個檢出註冊到兩個工作區就是兩列各自獨立、各有 id 的記錄；程式庫跨工作區的身分由檔案系統路徑決定，絕不依賴 id。註冊要求該 git 工作樹的 origin 遠端指向受支援的程式碼託管平台。每個程式庫都帶有它自己的程式碼託管平台（github / gitlab / bitbucket），由它決定所用的 API 配接器與憑證。

隔離程式庫：某個已註冊程式庫的、以工作區為範圍的工作樹。在支援該原生實作的平台上透過 rift 進行寫時複製；Windows 上則用 git worktree。按空間預置——該空間中的每段對話共用同一份檢出——因此代理絕不會改動來源。

空間：以工作區為範圍的協作容器，包含人類與代理參與者、持久化的 Mode、預置狀態，以及一個 SpaceKind（topic / agentPeer / system / pr / slack），它決定該空間如何被分區、靜音、加徽章與垃圾回收。它擁有其對話所共用的隔離工作樹（透過 rift 寫時複製；Windows 上為 git worktree）。

對話：空間內的一條訊息流，擁有自己的 id、歷史與代理執行上下文。同一個空間內的各段對話完全對等——不存在主要或「主」流程。每段對話都以編輯器分頁開啟；空間的未讀狀態會跨所有對話彙總。

討論串：設定了 anchorMessageId 的對話：錨定到同一空間內某個同級對話的一則訊息，並由該錨點訊息播下全新的代理上下文。只有一層深——討論串絕不會錨定到討論串。

工單：工作單位的聚合。與廠商無關：預設為 local，並為 Linear、GitHub Issues、Jira Cloud 與 ClickUp 提供同步配接器——不過應用程式內沒有任何介面會建立同步連線。支援階層、連結與委派。把工單指派給代理只記錄歸屬，不派發任何東西；指派給團隊是例外（由 TeamRoutingService 派發領導者）。

管線：基於 DAG 的工作流，把各步驟（代理派發、腳本、條件）串連起來。由範本定義；以執行的形式執行。

值物件

AgentRole：枚舉角色（CEO、coder、reviewer、QA、designer、security、devops、PM、general）。決定人物設定、記憶存取與階層。

AgentSkills：一組不區分大小寫的技能識別碼，在派發時把相關上下文注入提示。

技能來源：按工作區註冊為技能目錄的 GitHub 儲存庫。按構造即不受信任：該儲存庫的中繼資料僅供顯示，且每次安裝都必須先通過失效即拒絕的掃描閘門，任何內容才能到達磁碟或提示。參見安裝與管理技能。

skills-lock.json：按工作區記錄的已安裝技能清單：每一項的來源儲存庫、儲存庫內路徑、所釘選的提交，以及一個彙總內容雜湊。安裝、更新與解除安裝都會令它保持最新；verify_skills 會拿它與磁碟核對。

代理執行閘道：cc_server 上的一個回送端點，在代理的沙箱內套用動作政策。代理發起的每一次 GitHub 推送都會被導到這裡，依推送到遠端規則檢查，再以代理從不持有的寫入權杖轉送；Claude Code 的 Bash 命令則經由同一端點上的鉤子檢查。參見沙箱與保安。

模式：chat、plan、review 或 orchestrate。按空間儲存，因此同一個代理可以在不同空間處於不同模式；同一空間內的每段對話共用它。它管制系統提示、沙箱寫入規則與 MCP 工具允許清單。輸入列只提供 chat、plan 與 orchestrate；chat 標示為「代理」。

SandboxBackend：microvm（隔離的 VM——唯一帶有核心邊界的後端，用於互動式終端）、native（macOS 上為 Seatbelt，Linux 與 WSL2 上為 bubblewrap）或 none。開機時探測一次；native 可用時會包裹代理派發，包裹 Claude Code CLI 與執行框架的 bash 工具。Windows 沒有原生後端，而 Linux 需要 bwrap 加 socat，因此那裏的執行不會被包裹；--sandbox off 會刻意選擇退出。

測試機：代理實時操控的一部用完即棄機器——一個隔離的瀏覽器或 Linux 桌面、一個由主機管理的 Android 模擬器或 iOS Simulator，或一個隔離終端。透過它自己的全解析度通道實時觀看，接管由伺服器端強制執行。以對話為範圍，因此人類分頁與代理的 browser_use / computer_use / mobile_use / ios_use 呼叫面對的是同一部預設機器。參見測試機與隔離環境。

隔離環境：VM 支撐的測試機的較強邊界——核心邊界、用完即棄的覆寫磁碟、預設拒絕的網絡閘門與憑證代理。Android 與 iOS 測試機是用完即棄的，但使用主機管理的網絡，並不宣稱具備這道邊界。操控任何測試機都會用到 enclosureControl 護欄類別。

RunCost：單次代理執行的權杖／成本統計（輸入權杖、輸出權杖、以分為單位的估算成本）。

喚醒原因：代理被派發的原因。共六個值：使用者訊息、工單指派、失敗後的復原重派、子工單完成、已排定的後續心跳，以及管線步驟。

埠

SandboxPort：管理沙箱生命週期（探測、啟動、事件、exec、銷毀）。

CredentialBrokerPort：為沙箱啟動鑄造受範圍限定的憑證——代理環境中為唯讀，寫入權限僅用於伺服器端的推送路徑——並在拆除時撤銷它們。

GitRepoInspectorPort：從本機 Git 程式庫路徑中擷取中繼資料（owner、repo、branch）。

EmbeddingPort：為語意搜尋產生單位範數的文字嵌入向量。

NotificationPort：顯示原生桌面通知，並遵守類別／路由閘控。

TicketProviderPort：通往工單後端的與廠商無關的邊界（建立、取得、列出、更新、轉換狀態、指派）。

PipelineEnginePort：從範本啟動一次管線執行，令呼叫方與具體引擎解耦。

領域服務

AgentDispatchService：啟動代理執行：預置隔離程式庫、建構提示、建立執行日誌、回傳實時事件串流。

TicketWorkflowService：純領域的工單生命週期引擎，帶有樂觀並行變更收口點與工作區隔離強制。它強制的轉換圖只約束代理與自動化；使用者驅動的介面變更會傳入 force: true 並繞過它。代理受讓人並沒有工單派發器——AgentDispatchService 掌管派發，把工單指派給代理不會啟動任何執行。把工單指派給團隊是例外（由 TeamRoutingService 派發領導者）。

PipelineEngine：編排執行：啟動執行、排程步驟、持久化狀態、處理路由器／匯合／失敗後繼續，並在重新啟動後恢復進行中的執行。

PipelineTriggerDispatcher：訂閱領域事件，並為已啟用的觸發器自動啟動相符的管線執行。

MemoryAccessPolicy：解析並強制各領域上的代理角色記憶權限。

HarnessCostCalculator：依據 models.dev 目錄，把內建執行框架的權杖用量折算成一個 RunCost。派發會把該統計持久化到執行日誌上。

BudgetEnforcementService：計算每個代理的每月支出，以及一個派發前封鎖（checkInvocationBlock）。該封鎖只會被復原用的對帳器（OrphanRunReaper、StrandedTicketReconciler）查閱，一般的使用者或代理派發永遠不會查閱它。

BudgetGovernanceService：在每次執行後評估每個代理的每月支出——越過軟性門檻會記錄一宗警告事故；用盡預算則記錄一宗硬性事故，並把代理的生命週期翻轉為 paused。

事件

DomainEventBus：用於跨功能通訊的行程內廣播式發佈／訂閱匯流排。事件是具型別的；訂閱者消費 on<T>() 串流。

DomainEvent：基礎介面。每個事件都有 occurredAt。主要類別：工作區／代理、PR／審查、訊息、工單、管線、會議／日曆、身分、測試機、可觀測性。

會議與日曆

會議：在本機錄製並轉錄的會議工作階段。擷取麥克風與系統音訊，以可選的 ASR 模型在裝置上轉錄（預設為 Parakeet TDT v3；Parakeet TDT v2、Whisper large-v3-turbo 與 Whisper base.en 是替代選項），區分說話者，並摘要為筆記、行動項目與決策。所選的 ASR 模型會在開機時強制安裝，錄製功能在重新啟動一次後便會啟用。以工作區為範圍；資料留在本機。

MeetingSegment：一段被轉錄的音訊視窗，帶有說話者標記（me/them）、一個說話者分離標籤與毫秒級偏移。

MeetingActionItem / MeetingDecision：由摘要管線擷取並以獨立列儲存的結構化輸出。行動項目可以連結到一張工單。

CalendarEvent：已同步的 Google Calendar 項目，以某個工作區與已連接帳戶為範圍。與會議不同：活動是已排定的承諾；會議是已錄製的工作階段。透過 MeetingCalendarLink 一對一連結。

CalendarAccount：已連接的 Google 帳戶，按工作區與電郵區分。OAuth 重新整理權杖以 google_* 鍵的形式儲存在 <dataDir>/secrets.json 中，永遠不會到達用戶端；裝置碼流程在伺服器上完成。一個 authExpiredAt 標誌驅動重新連接橫幅。

架構術語

整潔架構：依賴規則：呈現層 → 應用層／提供者層 → 領域層 ← 基礎設施層。領域層對基礎設施的匯入為零。

埠與配接器：領域層定義抽象介面（埠）；基礎設施提供具體實作（配接器）。組合根把它們綁定起來。

共用核心：core/domain/ 中由 3 個或以上功能共用的實體、值物件、埠與服務。

功能優先：程式碼按業務領域（代理、管線、訊息）組織，而非按技術分層組織。

多人協作、身分與速度

主體：把人類與代理統一為單一動作者抽象的密封值——UserPrincipal(userId) 或 AgentPrincipal(agentId)。每則訊息、每張工單、每次審查、每個計劃與每份執行日誌都經由主體歸屬。

使用者：人類身分，儲存在 global.db 中，因此跨工作區全域唯一。建立工作區的主體會成為其擁有者——在同一項操作中蓋在 Workspace.ownerUserId 上，並附有一列擁有者角色的成員身分記錄。其他人透過邀請或 SSO 加入。

WorkspaceMember / WorkspaceRole：把 User 以某個角色（owner / admin / member / viewer / guest）繫結到 Workspace 的成員身分記錄。存取邊界是成員身分——而非配對金鑰。 按程式庫授予的權限，令成員身分不會擁有高於程式碼託管平台的權限。

ParticipantPresence：針對某個主體的短暫感知（狀態、位置、游標、正在輸入、代理的實時狀態與執行中成本）。永不持久化；由伺服器集中轉發；在扇出前先按程式庫授權過濾。

跟隨模式：點擊某個頭像即可跟隨其視埠，直到你自己動手，然後脫離。對人類與代理都適用（「觀看代理工作」）。

自主程度：按空間、按代理的控制項——propose-only / act-with-approval / act-freely——以動作護欄儲存之上的具名設定檔實作。

ActionClass：13 種效果類別的封閉集合（fileDelete、gitPush、prCreate、networkEgress、processSpawn、enclosureControl 等等）。每個變更類工具都會宣告它的類別；護欄引擎按範圍解析出 allow / prompt / deny（space > agent > workspace > mode preset > built-in default）。

WriteLedger / 冪等鍵：每次變更都帶有一個由用戶端產生的冪等鍵（UUIDv7，按邏輯操作劃分）。以工作區為範圍的帳本會在處理程式運行之前去重；重播會回傳位元組完全相同的原始結果。從構造上令重新連接與多用戶端變得安全。

Needs me 收件箱：一條跨越各支柱的佇列，規則嚴格——只有當某個項目_阻塞_了某件事（某個代理、一次合併、一次同步），或明確請求操作者介入時，它才會出現。

Plan Studio：互動式規劃介面——可編輯的具型別 DAG 計劃，帶有逐步的成本、時間與風險，以及部分核准。

審查運算：伺服器端的 PR 審查運算（由圖譜推導的群組、具型別的圖表、視覺差異、API 合約差異、多軸閘門），透過 review_studio.* 提供，並併入檢閱分頁。

審查空間：PR 唯一的底層空間（模式 review、類型 pr），以冪等方式建立，並透過 ReviewSpaceAssociation 與該 PR 連結。每位審查者都在其中提交發現項，這正是它們可比較的原因；其隔離工作樹已把 PR 檢出至其 head。

審查節點：AI 審查發現項的結構化單位：類型（bug、suggestion、recommendation、question、ticket）、優先級 P0–P3、一個類別／嚴重程度／工作量的分診三元組、一個檔案與行號錨點、可選的建議修正，以及一個信心分數。以 add_review_node 提交；判定是根據節點計算，而非根據散文。

已達共識：只有在另一位同行審查者確認某個發現項後才會到達的審查節點狀態——代理無法確認自己提出的發現項。檢閱分頁的發佈到 GitHub 按鈕會送出所有仍然未解決的發現項（selection: all_open）；MCP 工具 publish_review_to_github 仍然只預設發布經同行確認的發現項。

審查級別：工作區政策（light、balanced、thorough），撥定派出哪些審查者（僅工程師；+qa+architect；+security+perf），以及低於門檻的發現項呈現在何處。絕不刪除任何發現項。

審查軸：每次審查的五條評分通道之一：correctness、security 與 testGap 取自審查者的發現項；visual 與 apiContract 則是確定性的。受閘門約束的軸會併入判定，且只會令它更嚴重——partial 或 unavailable 的閘門會扣住判定，而非讓它通過。

審查判定：ship、hold 或 block。任何信心 ≥ 0.7 的 P0 發現項都會 block；任何其他 P0 或任何 P1 則 hold；否則就是 ship。受閘門約束且失敗的軸會強制 block，且無法被發現項投票推翻。

機群與評估

cc_worker：無介面的純 Dart 機群執行器二進位檔。與一個 cc_server 配對，宣告其主機能力，拉取租約工作，執行它們並把行程事件串流回傳。不持有任何持久狀態——一部權威伺服器，N 條笨拙肢體。

JobSpec：一切可執行項目（代理執行、管線步驟、程式碼索引、金樣轉譯、基準測試、評估批次）的具型別規格。

評估套件：以工作區為範圍的評估定義（提示、目標代理與模式、評分器）。建立工作區時會預置五個入門套件；可觀測性 → 質素會列出它們。

部署與用戶端

精簡用戶端架構：沒有任何用戶端會開啟資料庫；一個無介面的 cc_server 行程持有資料，並透過 WebSocket RPC 提供。每個用戶端（桌面、網頁、手機）都只是那條 RPC 連線之上的呈現層。

cc_server：無介面的伺服器二進位檔（純 Dart，不含 Flutter 引擎）。持有 Drift／SQLite 資料庫，透過 WebSocket 提供程式庫 RPC，並執行背景服務（管線、MCP、對帳器）。

ServerConnectionMode：桌面應用程式連接其伺服器的方式——local（在本機衍生一個 cc_server，這是預設值）或 remote（撥接別處的伺服器）。網頁用戶端一律是 remote。

RemoteRpcClient：每個精簡用戶端用來與其伺服器通訊的、與傳輸方式無關的 JSON-RPC 用戶端——可經由 WSS、回送或經中介的通道。

逐呼叫工作區範圍界定：伺服器是無狀態的——不存在按工作階段繫結工作區這回事，因此同一部伺服器上的多個用戶端絕不會共用同一個「目前工作區」。每個以工作區為範圍的 repo/call 與 sub/subscribe 都必須在其引數中帶有 workspace_id；缺失或未註冊的 id 會在任何資料庫開啟之前被拒絕。存取接着由工作區成員身分與角色把關，而非由工作階段把關。

cc_remote：手機精簡用戶端——一個 Flutter 網頁 PWA，透過經中介的通道遙控機群，並採用預設拒絕的工具政策。

cc_signaling_server：無狀態的 WebSocket 中繼代理，託管需邀請才能加入的房間——一個笨拙的中繼，只轉發端對端密封的訊框，不持有任何應用程式資料，也永遠看不到配對 PSK。

詞彙表