代理模型
什麼是代理？
標題為「什麼是代理？」的章節代理是具名的行為者，擁有角色人格、一組技能，以及要在其上執行的配接器。代理和人類一樣都是主體：它們撰寫訊息、擁有工單、留下審查意見，並出現在同一份名冊上。它們才是真正做事的角色。
每個代理只屬於一個工作區。這是硬性不變條件 — agent.workspaceId 不可為 null，決定代理的資料列會寫入哪個資料庫檔案的，正是代理自己所屬的工作區，而建立不屬於任何工作區的代理會被拒絕。
代理同時也是一個目錄。它的定義位於工作區資料目錄下的 agents/<slug>/AGENTS.md，其持有的技能則以符號連結連到 agents/<slug>/.agents/skills。資料庫資料列與檔案會一起寫入。植入程序具等冪性：若代理資料列已存在，磁碟上的檔案與技能連結仍會重新寫入。正式環境中呼叫此流程的是建立工作區，而不是每次啟動伺服器。
代理包含哪些內容
標題為「代理包含哪些內容」的章節| 屬性 | 作用 |
|---|---|
name |
簡短的類 slug 識別碼（architect、qa）。也是 @mentions 解析的對象 |
title |
人類可讀的職稱 |
persona |
自由文字的性格與行為指示，會以提示區段的形式注入 |
systemPrompt |
選用的額外指示，會以「代理指示」區段注入 — 它們不會取代組裝後提示的其餘部分 |
skills |
不區分大小寫的技能名稱集合，會以磁碟上的技能連結呈現 |
adapterId |
代理派送至哪個執行器。null 會回退至內建迴圈 |
modelId |
該配接器中的哪個模型 |
effort |
推論等級，取自所選模型本身的詞彙 |
contextSize |
情境視窗的覆寫值 |
silenceTimeoutMinutes |
每位代理對靜默監控的覆寫值（1–240） |
reportsTo |
上層代理 id — 組織圖所描繪的回報鏈 |
你可以在 設定 → 工作區 → 代理 編輯上述所有項目。新增代理 會建立一個未命名的代理，之後再由你填寫。
技能是代理實體上不區分大小寫的名稱。它們會引發兩件各自獨立的事：
- 這些名稱會列在組裝後的提示中，位於「技能」標題之下。實體上的技能集合本身就只有這個作用 — 並不存在以它為索引的個別技能提示庫。
- 每個具名技能的目錄（工作區中的
skills/<slug>/SKILL.md）會連結至代理自己的資料夾。在內建執行環境上，已連結技能的 frontmatter 會自動載入系統提示，代理再視需要讀取本文；在對話中輸入/skill:<name>會載入該技能本文，作為該回合的指令。
從外部取得的技能會在取得與寫入之間通過失效即拒絕的供應鏈掃描 — 未取得判定結果之前，任何技能內容都不會寫入磁碟或進入提示。所謂外部，指的是你自己註冊為技能來源的 GitHub 儲存庫：這裡沒有經過策畫的市集，因此儲存庫自身的中繼資料（其說明、其星星數、技能名稱）都是不受信任的顯示資料，掃描判定結果才是唯一的安全訊號。安裝時會取得技能的整個目錄，並在 skills-lock.json 中將其固定於來源提交，之後更新時會先再次通過同一道關卡，才會取代任何內容。做法說明請見安裝與管理技能。
儲存庫範圍的技能
標題為「儲存庫範圍的技能」的章節儲存庫可以自帶技能，放在任何慣例位置（.agents/skills/、.claude/skills/、.opencode/skills/）。空間會將每個已連結的儲存庫並排簽出至 repos/<name>/ 下，但代理一次只在一個儲存庫中工作 — 因此它只攜帶該儲存庫的技能，並在移動時整組換掉。
哪個儲存庫處於作用中，是由代理碰觸的檔案推斷：在 repos/<name>/ 下寫入檔案會使該儲存庫成為作用中的儲存庫，而只是跨儲存庫讀取則不會，因此為了追查某個符號而進入同層服務，絕不會在任務進行中把技能組整組換掉。在單一儲存庫的空間中，第一次回合之前就能知道答案。
這種範圍劃分是基於情境預算的決定。技能索引在每個回合都會留在提示中，而技能本文不會，因此一次列出每個儲存庫的技能會持續耗費 token — 而且當工作實際落在另一個服務時，某個服務的 testing 技能會產生誤導。同樣的道理也說明了為何代理的索引只帶一個儲存庫，但訊息輸入區卻不採這種範圍劃分：自己指名技能是一個明確的動作，因此 /skill:<repo>:<name> 可觸及空間中的任何儲存庫。
儲存庫技能會為每一種配接器載入，不只是內建執行環境。作用中儲存庫的技能會實際寫入代理的工作目錄，也就是 Claude Code 本來就會掃描的路徑；同一份索引也會組成內建執行環境所讀取的 AGENTS.md。儲存庫的技能在上述一切發生之前，會先通過與已安裝技能相同的失效即拒絕掃描 — 已簽出的儲存庫是複製而來的內容，其 frontmatter 會進入提示。
代理本身不帶任何權限旗標。它能否建立提交、推送、開啟 pull request、寫入追蹤器或存取網路，由動作護欄決定——在工作區、代理或空間範圍內選擇允許、先詢問或拒絕——無論由哪個配接器執行它，都適用同樣的規則。
單次執行被_交付_了什麼，並不會隨這些規則改變。在 GitHub 工作樹中的執行一律取得唯讀的 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 |
最近一次執行發生錯誤，或其存活狀態為 failed 或 dead |
blocked |
最近一次執行的存活狀態為 blocked、stalled 或 looping |
idle |
其他所有情況 — 代理先前執行過，且目前沒有進行中的工作 |
另有兩個狀態 queued 與 succeeded，存在於對話執行樹中的個別執行；名冊從不產生它們，因為已完成的執行顯示為綠色，是關於該次執行的事實，而不是關於代理的事實。
線上狀態名冊會顯示一幅平行、較粗略的圖像，由伺服器端依據即時執行事件合成 — 思考中、執行中、等待核准、完成 — 這正是代理能與人類並列出現的原因。請見多人協作。