代理模型
代理是甚麼？
標題為「代理是甚麼？」的章節代理是一個具名的行動者，擁有角色設定、一組技能，以及一個用來運行的配接器。代理與人類一樣是主體：它們撰寫訊息、擁有工單、留下審查，並出現在同一份名冊上。它們就是實際做事的一方。
每個代理只屬於一個工作區。這是一項硬性不變條件——agent.workspaceId 不可為 null，代理自己所屬的工作區決定了它的資料列會落在哪個資料庫檔案，而建立沒有工作區的代理會被拒絕。
代理同時也是一個目錄。它的定義位於工作區資料目錄下的 agents/<slug>/AGENTS.md，它持有的技能則以符號連結指向 agents/<slug>/.agents/skills。資料庫資料列與檔案會一起寫入。預置是冪等的：若代理資料列已存在，磁碟上的檔案與技能連結仍會被重寫。正式的呼叫者是建立工作區，而不是每次啟動伺服器。
代理攜帶甚麼
標題為「代理攜帶甚麼」的章節| 屬性 | 作用 |
|---|---|
name |
簡短的 slug 式識別碼（architect、qa）。也是 @mentions 解析所依據的名稱 |
title |
人類可讀的職稱 |
persona |
自由文字的人格與行為指示，以提示區段形式注入 |
systemPrompt |
選用的額外指示，以「Agent instructions」區段注入——它們不會取代組裝後提示的其餘部分 |
skills |
不區分大小寫的技能名稱集合，在磁碟上以技能連結形式鏡像 |
adapterId |
代理派發至哪個執行器。為 null 時回退至內建迴圈 |
modelId |
該配接器內的哪個模型 |
effort |
推理等級，取自所選模型本身的詞彙 |
contextSize |
上下文窗口覆寫 |
silenceTimeoutMinutes |
逐代理覆寫靜默監察機制的值（1–240） |
reportsTo |
上級代理 id——組織圖所描繪的匯報鏈 |
你可以在 設定 → 工作區 → 代理 中編輯以上全部欄位。新增代理 會建立一個未命名的代理，再由你填寫內容。
技能是代理實體上不區分大小寫的名稱。它們會引發兩件各自獨立的事：
- 這些名稱會列在組裝後的提示中，位於「Skills」標題之下。這已是該實體的集合本身所做的全部——並沒有以此為索引的逐技能提示庫。
- 每個具名技能的目錄（工作區中的
skills/<slug>/SKILL.md）會連結到代理自己的資料夾。在內建執行框架上，已連結技能的前置資料會自動載入系統提示，代理則按需讀取內文；在對話中輸入/skill:<name>會把該內文載入為該回合的指令。
從外部取得的技能會在取得與寫入之間通過一道失效即拒絕的供應鏈掃描——沒有判定結果，任何技能內容都無法到達磁碟或提示。所謂外部，就是你自己登記為技能來源的 GitHub 程式庫：這裏沒有策劃好的商店，因此程式庫自身的元資料（它的描述、它的星星數、技能的名稱）都是不受信任的顯示資料，掃描判定是唯一的安全訊號。一次安裝會取得技能的整個目錄，在 skills-lock.json 中把它固定到來源提交，之後的更新會先重新通過閘門，才會取代任何東西。操作說明見安裝與管理技能。
以程式庫為界的技能
標題為「以程式庫為界的技能」的章節程式庫可以在任何慣用位置（.agents/skills/、.claude/skills/、.opencode/skills/）隨附自己的技能。空間會把每個已連結的程式庫並排檢出到 repos/<name>/ 之下，但代理一次只會在一個程式庫中工作——因此它只會帶着那個程式庫的技能，而當它移動時，這些技能就會替換。
哪個程式庫處於作用中，是從代理碰觸的檔案推斷出來：在 repos/<name>/ 之下寫入檔案會使該程式庫成為作用中的程式庫，而僅僅跨程式庫讀取則不會，因此追蹤一個符號到同層的另一個服務，絕不會在任務進行中把這組技能換掉。在單一程式庫的空間中，答案在第一個回合之前就已確定。
劃分範圍是上下文預算的決定。技能索引每個回合都留在提示中，而內文則不然，所以一次列出每個程式庫的技能會持續消耗權杖——而且當工作其實在另一個服務時，來自某個服務的 testing 技能會主動誤導。同樣的道理也解釋了為何代理的索引只帶一個程式庫，但輸入框卻不這樣劃分範圍：由你自己指名技能是一個明確的動作，所以 /skill:<repo>:<name> 可以觸達空間中的任何程式庫。
程式庫技能會為每個配接器載入，不只是內建執行框架。作用中程式庫的技能會具體化到代理的工作目錄，也就是 Claude Code 本來就會掃描的路徑；同一份索引會組進內建執行框架所讀取的 AGENTS.md。程式庫的技能會在任何上述事情發生之前，通過與已安裝技能相同的失效即拒絕掃描——檢出的程式庫是複製回來的內容，而它的前置資料會到達提示。
代理本身不帶任何權限旗標。它能否建立提交、推送、開啟 pull request、寫入追蹤器或存取網絡，由動作護欄決定——在工作區、代理或空間範圍內選擇允許、先詢問或拒絕——無論由哪個配接器運行它，都適用同樣的規則。
一次執行「獲派」甚麼，並不會隨這些規則改變。在 GitHub worktree 中的執行一律取得唯讀的 GitHub 權杖，而推送會在發生的一刻被詢問：代理的 git 設定會把每一次 GitHub 推送都經由 Control Center 送出，Control Center 在轉送之前會套用推送到遠端規則。
這是如何運作的，包括檔案系統層面哪些受到強制執行、哪些沒有，見沙箱與保安。
配接器決定哪些事情能夠強制執行
標題為「配接器決定哪些事情能夠強制執行」的章節代理上影響最大的單一欄位就是它的配接器，因為配接器的傳輸方式決定了 Control Center 的政策有多少真正能夠強制執行。
| 傳輸方式 | 配接器 | Control Center 強制執行的範圍 |
|---|---|---|
| 內建執行框架 | Control Center（內建） | 全部。工具介面是由模式_建構_出來的，因此不被允許的工具是看不見，而不只是被拒絕；每次呼叫都會經過核准關卡與動作護欄；完成契約可以作出提醒，然後令一次未交出成果就結束的執行失敗 |
| Claude CLI | Claude Code | 提供給它的 mcp__* 工具，以及它的 Bash 命令——鉤子會在這些命令執行前把它們送交動作政策。Claude 自己的讀取、寫入與編輯工具活在它自己的行程裏，看不見地執行——而且它是以 --dangerously-skip-permissions 啟動，因為非互動式的 claude -p 否則會永遠卡在它自己的提示上 |
具體而言，只有內建執行框架支援子代理、執行中引導、暫停與恢復（因此也支援接管），以及結構化的模式強制執行。 Claude Code 一項都沒有。
沒有配接器的代理會回退至 Control Center（內建）——即伺服器內部的迴圈，因此無需安裝任何 CLI——它的執行日誌會記錄 cc-harness。每個預置的代理建立時都沒有配接器或模型，因此全新工作區的五個代理都會在那裏執行，使用 Anthropic 的預設模型，直到你為每個代理設定配接器和模型。新手導引中的「預設配接器」選項是客戶端偏好，伺服器從不讀取，也不會回溯套用到已建立的代理。
代理從何而來
標題為「代理從何而來」的章節- 隨工作區預置。 每個工作區——不只是第一個——都會有一個 CEO 加上四個向它匯報的專才（
qa、architect、engineer、librarian），在建立工作區時於背景以冪等方式建立。見工作區與隔離。 - 手動新增：在 設定 → 工作區 → 代理。要求代理聘請同事並不會建立資料列；請使用該畫面。
即時狀態
標題為「即時狀態」的章節代理沒有儲存的狀態欄。它的即時狀態每次被讀取時，都由其最近的執行日誌推導出來：
| 狀態 | 含意 |
|---|---|
neverRun |
沒有執行日誌 |
running |
目前至少有一次執行正在進行 |
failed |
最近一次執行發生錯誤，或其存活狀態為失敗或已死 |
blocked |
最近一次執行的存活狀態為受阻、停滯或循環 |
idle |
其他所有情況——代理曾經執行過，且沒有進行中的工作 |
另外還有兩個狀態 queued 和 succeeded，存在於對話執行樹中供個別執行使用；名冊從不產生它們，因為一次完成的執行是綠色，是關於執行本身的事實，而不是關於代理。
線上狀態名冊顯示一幅並行、較粗略的圖像，由伺服器端從即時執行事件合成——思考中、執行中、等待核准、完成——這正是代理得以與人類並列顯示的原因。見多人協作。