Harness 理論篇 Part 07｜長任務與多 Agent 協作：工作如何跨越 Context 邊界？

假設你把一個大型 Migration 交給 Coding Agent：修改多個模組、補測試、更新文件，最後產出可審查的 Pull Request。

第一個 Session 做得不錯。Agent 找到舊 Schema、改完一部分程式，也跑了幾組測試。Context 快滿時，它留下幾句摘要，然後結束。

下一個 Session 啟動後，新的 Agent 看到 Repository 已經有修改，卻不知道：

哪些改動已經驗證
哪些只是暫時探索
哪個測試原本就失敗
上一輪是否已經執行過有副作用的操作
現在最安全的下一步是什麼
整個任務還剩多少沒有完成

它可能重新探索一次，也可能接著修改一個錯誤假設，甚至看見大部分功能都存在，就宣布任務完成。

這不是 Context Window 太短這麼簡單。真正缺少的是一套能把任務狀態帶過 Session、Worker 與 Agent 邊界的 Harness。

長任務不應依賴某一段對話永久存在。它需要 Durable Artifact、Structured Progress、Clean Handoff、明確 Ownership，以及可以重新建立 Context 的執行協議。

Long-running task across fresh sessions

Figure 7-1｜每個 Session 可以使用新的 Context；Task Contract、Progress Ledger、Evidence 與 Artifact 必須留在 Session 之外。

長任務不是把單一 Session 撐得更久

Part 04 已經談過 Context 是有限資源，Part 06 則處理 Runtime 如何保存 Canonical State 與 Checkpoint。

長任務再往前一步：

當工作必須經過多個 Context Window、多個 Session，甚至多個 Agent，哪一部分必須延續，哪一部分應該丟棄？

最常見的直覺方案是：

使用更大的 Context Window
不斷 Compaction
把完整 Transcript 傳給下一輪
讓 Agent 一直 Loop，直到它說完成

這些方法可以延後問題，卻沒有建立可靠的交接機制。

Anthropic 在長任務 Harness 實驗中觀察到兩種典型失敗：Agent 一次嘗試完成太多，導致 Session 結束時留下半成品；後續 Agent 則可能看到已有大量進度，太早宣布工作完成。其解法不是單純增加 Context，而是由 Initializer 建立工作環境，再讓後續 Session 每次只做增量工作，並留下 Progress Artifact 與 Git History。¹

後續的 Harness 實驗更進一步指出，Fresh Context Reset 可以降低長 Context 帶來的失焦，但代價是 Handoff Artifact 必須足以讓下一個 Agent 重建狀態。²

換句話說，Context Window 是一次推理的工作檯面，不是整個任務的資料庫。

這不表示所有長任務都必須頻繁重開 Session。OpenAI 在 2026 年展示過約 25 小時的單一 Codex Run，說明更強模型與 Harness 確實能延長連續工作時間。那是一次實驗，而不是「不需要 Durable State」的證明。Continuous Run、Compaction 與 Fresh Session 都可以是合法策略；共同要求是任務不能因某個 Context、Process 或 Worker 消失而失去真實狀態。³

長任務常見的七種失敗

1. Context rot

重要限制逐漸被過時資訊、冗長 Tool Result 與中間討論淹沒。模型仍看得到文字，但未必能穩定抓住當前最重要的狀態。

2. Goal drift

Agent 解決了途中發現的問題，卻慢慢離開原始 Task Contract。工作量增加，不代表更接近完成。

3. One-shot overreach

Agent 一次修改太多範圍，Context 用完時留下跨模組半成品。下一輪接手者只能從 Dirty Workspace 猜測意圖。

4. Repeated exploration

每個新 Session 都重新讀相同文件、搜尋相同模組、重跑相同診斷。Token 和時間被花在重建已經得出的結論。

5. Hidden state in transcript

關鍵決策只存在某段對話中，沒有進入 Spec、Ledger、Decision Record、Code 或 Test。Transcript 一旦被 Compaction、截斷或遺失，狀態也跟著消失。

6. Premature completion

Agent 看見功能大致存在，就用自然語言判定完成。剩餘工作、未執行測試與例外路徑沒有被逐項驗證。

7. Concurrent ownership conflict

兩個 Agent 同時領取同一 Task，或在同一 Workspace 修改相同資源。最後得到兩份都自稱完成、卻無法安全合併的結果。

這七類問題需要不同控制。把所有問題都交給一份更長的 Prompt，等於把 Project Manager、Version Control、Queue、Lock、Test Runner 與 Incident Log 全塞進一段文字，然後希望模型記得主持會議。

Durable 與 Disposable：先決定什麼值得活過 Session

長任務 Harness 的第一個設計決定，是把資訊分成 Durable 與 Disposable。

Durable state

下一個 Session 必須能信任、查詢或驗證：

Task Contract 與 Scope
Spec、Plan 與 Feature Inventory
Progress Ledger
已確認 Decision 與 Assumption
Checkpoint Pointer
Artifact Reference
Test、Build、Lint 與 Review Evidence
External Operation ID
Git Commit 與 Workspace Metadata
Known Failure、Blocker 與 Open Risk
Next Safe Action

Disposable context

只對當輪推理有用，丟失後可以重新產生：

臨時思考路徑
大量未篩選的搜尋結果
冗長 Tool Output
已被正式 Decision 取代的候選方案
重複的 Repository 探索細節
不影響後續工作的語氣與對話填充

Durable 不代表所有資訊都要永久保存。它表示：只要任務仍在進行，這份資訊就不能依賴模型「大概記得」。

一個實用判斷是：

新 Session 若拿不到這項資訊，會不會重做、越界、誤判完成，或重複副作用？

答案是會，就應該把它提升成 Session 外部的 Artifact 或 State。

Fresh-context Iteration：它是一種策略，不是唯一答案

Fresh-context Loop 不追求讓同一個 Agent 永遠在線，而是把長任務切成可以重新啟動的有界迭代：

Load durable task state
→ validate handoff commit
→ select one bounded work unit
→ execute
→ verify
→ prepare immutable evidence
→ commit progress and next action
→ end or continue

每輪重新建立 Context、完成一個可驗證增量，再決定延續同一 Session、Compaction，或在 Safe Boundary 啟動 Fresh Session。

它的優點包括：

低價值 Context 不會無限累積
每輪重新核對 Contract 與 Scope
進度必須轉成 Durable Artifact
Worker、Model 或 Client 可以在邊界上替換
Reviewer 可以用較少的自我辯護偏差重新檢查結果

它也有成本：

Bootstrap 消耗 Token、Latency 與 Tool Call
Hand-off 不完整會產生一種更整齊的失憶
每次重建 Context 都可能漏載重要 Evidence
過度切割會讓協調成本大於推理收益

條件	較適合延續同一 Run	較適合 Fresh Session
Context 仍高訊號	是	不一定
已到 Durable Checkpoint	可選	是
有不可判定的 In-flight Side Effect	否，先 Reconcile	否，先 Reconcile
下一步需要不同角色或 Reviewer	可	常常適合
Handoff 重建成本很高	是	謹慎
已出現 Context Rot／Premature Wrap-up	較差	較適合

Fresh Session 的觸發應是 Runtime Policy，不是模型感覺「快沒 Token 了」就自行丟下工作。至少要先：

停止接新 Work Unit。
讓 Active Operation 到達可判定狀態。
保存不可重現 Evidence。
提交 Handoff Manifest 與新的 State Version。
驗證下一個 Session 可以重建。

這個模式適合可拆成清楚 Increment、每輪有可靠 Verification Gate、Durable State 可正確持久化，而且 Context 重建成本低於持續維護污染歷史的工作。

若任務高度耦合、沒有 Observable Completion、每輪必須重載大量不可壓縮資訊，或 Handoff Authority 本身不可靠，Fresh Session 反而可能降低品質。

Session Bootstrap：每一輪先重建可工作的世界

新 Session 不應直接問模型「接著做什麼」。Runtime 應執行一致、可驗證的 Bootstrap Protocol。

典型步驟如下：

驗證 Task ID、Tenant、Repository、Branch 與 Workspace
讀取 Task Contract、Spec、Progress Ledger 與最後 Checkpoint
對照 Repository、Artifact Store 與 External System 的實際狀態
執行符合當前 Checkpoint 的最小 Health Check
找出一個可完成、未被 Claim 的工作單元
建立本輪 Budget、Tool Scope 與 Verification Requirement
開始執行

順序可以依產品調整，但 Bootstrap 必須回答：

我現在在哪個工作環境？
任務的真實狀態是什麼？
上一輪留下哪些可信 Evidence？
哪些 Failure 是 Baseline，哪些是新出現？
目前最小且安全的下一步是什麼？

若 Bootstrap 只讀一段「上一輪摘要」，卻不檢查 Repository、Task Store 與 Artifact，新的 Agent 仍然可能從過期敘述開始工作。

Structured Progress Ledger：狀態帳冊不是散文，也不一定是 Claim Authority

Progress Ledger 是長任務的操作視圖，不應只是 Diary，也不應把 Transcript 換一個檔名保存。

task_id: migration-payment-state-v2
schema_version: 4
contract_version: 5
task_version: 18
status: in_progress
workspace_id: ws-payment-state-17
completed:
  - id: update-domain-enum
    evidence_manifest: evidence://update-domain-enum/v3
current:
  id: migrate-api-mapping
  claim:
    owner_id: worker-07
    claim_generation: 12
    claim_token: claim-12-a9f3
    lease_expires_at: 2026-07-08T06:00:00Z
remaining:
  - update-webhook-consumer
  - add-backward-compatibility-tests
known_failures:
  - id: baseline-flaky-checkout-e2e
    classification: pre_existing
last_checkpoint: cp-031
last_handoff: handoff-044
next_safe_action: run_api_mapping_contract_tests
updated_at: 2026-07-08T05:40:00Z

它不能證明 Owner 仍持有合法 Claim、Evidence 真的通過、Ledger 與 Repository 同時更新，或外部 Side Effect 已完成。

Ledger View 與 Authoritative Task State

小型系統可以用支援 Atomic Rename／Compare-and-swap 的 Markdown 或 YAML 同時承擔 Ledger 和 Task Authority。規模變大後，更常見的是：

Authoritative task / claim store
→ produces versioned progress view
→ Context Builder loads selected ledger sections

這時 Ledger 是可讀、可交接的 Projection；Task Store 才原子驗證 Claim Token、Task Version 與 Completion Transition。

無論存放方式，都需要：

Schema Version
Task ID、Contract Version 與 Task Version
Completed／Current／Remaining 分離
Immutable Evidence Reference
Blocker 與 Known Failure Classification
Checkpoint、Handoff Commit 與 Next Safe Action
Expected Version／CAS 或其他 Concurrency Control
可由另一個 Worker 在不猜測的情況下重建

progress.md 完全可以使用。只要它參與 Automated Claim、Completion 或 Handoff，它就是狀態資料模型；Markdown 不會免除 Concurrency、Versioning 與 Validation。

Progress Ledger、Checkpoint 與 Git History 各自證明什麼？

三者常一起使用，但不能互相取代。

機制	主要用途	無法單獨證明
Progress Ledger	任務目前做到哪裡、由誰負責、下一步是什麼	實際檔案或外部狀態與敘述一致
Checkpoint	Runtime 在哪個一致點可以 Resume	程式碼歷史、業務完成度或所有副作用
Git History	檔案變更與 Commit 邊界	Runtime Approval、External Operation、未提交 Artifact
Test Evidence	某個條件在某次執行中通過	整個 Task 已完成，或所有環境都正確

成熟的 Handoff 會交叉引用它們，而不是指定其中一個當萬能 Source of Truth。

例如 Ledger 可以記錄 commit: a81c2f9、checkpoint: cp-031 與 test_run: tr-442。下一輪再用實際 Store 驗證這些 Reference 是否存在、是否屬於同一 Task，以及是否仍然有效。

Clean Handoff：Session 結束是一個可提交的狀態轉移

可靠 Handoff 不是先改 Repository、再改 Ledger、最後希望兩邊剛好一致。

Stop accepting a new work unit
→ reach a safe operation boundary
→ persist immutable artefacts and evidence
→ build handoff manifest
→ validate references and consistency predicate
→ atomically commit task state + manifest pointer
→ release claim or transfer ownership
→ publish session terminal event

handoff_id: handoff-044
task_id: migration-payment-state-v2
from_session: session-19
from_task_version: 18
to_task_version: 19
workspace_ref: workspace://ws-payment-state-17@a81c2f9
checkpoint_ref: checkpoint://cp-031
evidence:
  - evidence://api-mapping-tests/tr-442
  - artifact://diff/api-mapping-v4
current_unit:
  id: migrate-api-mapping
  state: resumable
next_safe_action: run_api_mapping_contract_tests
consistency_predicate: checkpoint-api-mapping-v2

先保存 Immutable Evidence，再提交引用 Versioned Object 的 Handoff Record，可以降低 Ledger 已前進、Artifact 卻不存在的 Dual-write 風險。若無法跨 Store 做 Transaction，至少需要 Idempotent Commit、Expected Task Version、Prepared／Committed 狀態、Orphan Artifact Reconciliation，以及 Validation 通過後才生效的 Handoff Pointer。

Structured progress ledger and clean handoff

Figure 7-2｜Authoritative Task State 透過 Versioned Ledger 與 Committed Handoff Manifest，讓下一個 Session 只從已驗證的 Evidence 與 State Version 開始。

Handoff 前至少要確認：

Completed、Incomplete、Blocked、Known Failure 分開
Artifact 與 Evidence 已 Durable
External Operation ID 與 Unknown Outcome 已記錄
Background Work 有明確狀態
Temporary File、Debug Switch 與 Secret 已處理
Dirty Workspace 可以解釋
Bootstrap 路徑仍可使用
Next Safe Action 明確
Claim Release／Transfer 不會讓 Stale Worker 繼續 Commit

Clean 不等於整個 Repository 永遠全綠

大型 Migration 可能需要中間狀態。更好的方法是 Checkpoint-specific Consistency Predicate：定義目前必須通過的 Module、Baseline Failure、Required Artifact、禁止合併的 Workspace 與下一輪前置條件。

若狀態無法安全 Resume，就提交明確的 Dirty／Blocked Handoff。誠實的 Amber State 比塗成綠色的 Red State 有用。

Fresh Session Test：交接文件能否獨立成立

完成 Handoff 後，可以用一個直接的測試檢查：

啟動一個沒有舊 Transcript 的 Agent，只提供 Task Contract、Ledger、必要 Artifact 與 Workspace，它能否正確說明當前狀態並選出下一個安全動作？

如果不能，常見原因包括：

關鍵決策只留在聊天裡
Ledger 沒有 Evidence
Workspace 中存在無法解釋的 Dirty File
Task Scope 已改變，但 Contract 沒有版本化
下一步依賴某位人類或 Agent 的腦內記憶

Fresh Session Test 不證明任務最終正確。它只驗證 Handoff Artifact 是否足以重建工作狀態。這個 Proof Boundary 很重要，否則「接得起來」很容易被誤寫成「做對了」。

Subagent 是 Child Runtime，不是比較短的 Prompt

Parent 委派工作時，Harness 建立的是具有獨立 Lifecycle 的 Child Work Unit：

Subagent
= child run
+ versioned delegation contract
+ selected context projection
+ scoped resource grant
+ ownership boundary
+ evidence and acceptance contract

至少要回答六個問題：

1. Objective and input snapshot

Child 要完成什麼？它依據哪一版 Parent State、Contract、Repository Ref 與 Artifact？

2. Resources

Child 可以使用哪些 Tool、Filesystem Path、Network、Credential、Model 與 Budget？

3. Context projection

它看到哪些 Instruction、Fact、Artifact、Parent State 與 Task Constraint？哪些資訊故意不載入？

4. Ownership and authority ceiling

它可以修改哪些 File、Record、Task 或 External Resource？它能否再委派、要求 Approval 或擴張 Scope？

5. Cancellation and lifecycle

Parent Cancel、Deadline、Budget Exhaustion 或 Policy Change 如何傳給 Child？Child 的 completed、partial、failed、cancelled 與 unknown 如何持久化？

6. Evidence and acceptance

Child 必須回傳哪些 Artifact、Test、Source、Assumption、Coverage Gap 與 Trace，Parent 才能驗證並接受？

{
  "child_run_id": "child-204",
  "parent_run_id": "run-108",
  "delegation_id": "delegation-77",
  "contract_version": 3,
  "parent_state_version": 41,
  "task_id": "audit-webhook-mapping",
  "objective": "Find callers that depend on the legacy payment-state mapping.",
  "input_snapshot": {
    "repo_ref": "payments@a81c2f9",
    "spec_ref": "artifact://spec/payment-state-v2"
  },
  "resources": {
    "tools": ["read_file", "search_code", "run_readonly_tests"],
    "network": "deny",
    "write_scope": [],
    "delegation": "deny"
  },
  "budget": {
    "max_turns": 12,
    "max_cost_usd": 0.8
  },
  "required_evidence": [
    "caller inventory",
    "file and symbol references",
    "coverage gaps",
    "child trace ID"
  ],
  "result_protocol": {
    "submitted_states": ["completed", "partial", "failed", "cancelled", "unknown"],
    "parent_decisions": ["accepted", "rejected", "repair_required"]
  }
}

這段說明 Context、Resource、Authority、Budget 與 Acceptance 應被顯式限制。它不能證明 Runtime 真的強制限制、Child Search 已完整，或 Parent 可以不驗證就採納。

Anthropic 的 Claude Code Subagent 文件把 Subagent 描述為具有獨立 Context、指定 Tool Access 與獨立 Permission 的專門 Agent。OpenAI Codex 的現行文件則說明 Child 會套用 Parent Turn 的 Live Sandbox／Approval Override。這些是不同產品語意；自建 Harness 必須明確寫出 Resource Grant 與 Authority Ceiling。⁴⁵

Parent and child runtime contract

Figure 7-3｜Parent 以 Versioned Delegation Contract 建立 Child Runtime；Child 先提交 Evidence，Parent 再驗證並 Accept、Reject 或要求 Repair。

Shared Resources 不等於 Shared Transcript

Parent 與 Child 可以共享：

Repository
Artifact Store
Sandbox Image
Tool Service
Task Registry

這不表示 Child 自動知道 Parent 看過什麼、排除了什麼，或為什麼選擇目前方向。

反過來，Child 也不應把整份 Transcript 回傳給 Parent。較好的做法是回傳結構化結果：

Artifact Reference
Commands 或 Tests Executed
Source Citation
Modified Resource
Assumption
Unresolved Gap
Confidence 與 Coverage
Child Run／Trace ID

Anthropic 的 Multi-agent Research 系統採用 Orchestrator-worker Pattern，由 Lead Agent 把不同研究方向委派給平行 Subagent，再由 Lead 彙整結果；詳細搜尋 Context 留在 Worker，避免全部湧回主 Context。⁶⁷

這種設計的目標不是讓 Parent 看不到細節，而是讓細節以 Artifact 和 Provenance 的形式按需取得。

Child Summary 也不能因為來自「自己的 Agent」就自動獲得較高 Trust。Anthropic 指出，Subagent 可以隔離 Untrusted Content，但若 Parent 把整理後輸出視為 Trusted Instruction，也可能形成 Trust Escalation。Child Output 應保留 Source、Data／Instruction Role 與 Trust／Taint Metadata，再由 Parent Policy 與 Verifier 處理。⁸

Multi-agent 需要 Protocol，不是讓大家待在同一個聊天室

Agent 平行執行後，Free-form Text 不足以承擔 Assignment、Approval、Result、Cancellation 與 Shutdown。

message_id: msg-883
protocol: task_result
protocol_version: 2
request_id: req-117
from: worker-api-02
to:
  - coordinator
task_id: migrate-api-mapping
claim_generation: 12
type: response
status: result_submitted
payload_ref: artifact://results/api-mapping-02
sequence: 6
dedupe_key: task-result:migrate-api-mapping:12
created_at: 2026-07-08T06:20:00Z
expires_at: null

它不能證明 Message 已被處理、Result 已被 Parent 接受、Duplicate Delivery 已去重、Worker 仍是合法 Owner，或 Artifact 尚未被 Retention 清除。

不要假設 Exactly-once Delivery

Queue、Network 與 Restart 都可能產生 Duplicate 或 Late Delivery。較安全的假設是：

at-least-once delivery
+ idempotent handler
+ dedupe key
+ monotonic task state

created
→ delivered
→ acknowledged
→ processing
→ result_submitted
→ accepted / rejected / repair_required

Acknowledged 只表示 Receiver 接收責任；Result submitted 只表示 Worker 交付候選結果；Accepted 才表示 Coordinator 依 Contract 與 Evidence 採納。

Request 與 Response 必須可關聯

Approval、Permission、Plan Review 與 Shutdown Request 應有 request_id。Response 使用相同 ID，並進入 approved、rejected、expired 或 cancelled 等 Terminal State。真正的 Tool／Write Path 必須檢查 Protocol State、Operation Digest 與 State Version。

Idle 不等於 Completed

Worker 可能在等 Tool、Approval、External Process、Result Persistence，或已提交 Result 但等待 Parent Acceptance。Coordinator 需要 Work-unit State、Heartbeat、Pending Operation、Claim Generation 與 Result Protocol，不能只看「多久沒有 Token」。

Delivered 不等於 Processed

Broker 回報 Delivery，只證明 Message 到達 Channel。它不證明 Receiver 已驗證 Schema、接受 Task、取得 Claim、讀取 Artifact、完成 Request 或提交 Evidence。

Background Acceptance、Worker Completion 與 Parent Acceptance 是三個事件

Task request
→ authorised
→ background accepted with work_id
→ worker runs
→ worker result submitted
→ parent verifies
→ accepted / rejected / repair required

Background Acceptance 包含 Work ID、Initial State、Inspection Endpoint、Cancellation Capability，以及 Side Effect 是否可能開始。Worker Completion 包含 Terminal State、Artifact Reference、Timestamp 與 Claim Generation。Parent Acceptance 包含 Accepted Result Version、Verification Evidence、Remaining Gap 與 Authoritative Task Transition。

不要重用一個 Tool Request ID 先送 accepted、再送第二個 Result。原始 Request 以 background_accepted 結束，後續透過 Work ID 發送獨立 Event。

Atomic Task Claiming：Lease 之外還需要 Claim Generation

這種寫法有 Race：

read task where status = pending
if task has no owner:
    write owner = me

Claim 必須是 Atomic Transition：

pending, task_version=18
→ compare-and-set
→ claimed(
     owner=worker-A,
     claim_generation=12,
     claim_token=claim-12-a9f3,
     lease_until=...
   )
→ running
→ result_submitted
→ accepted / partial / failed / released

Claim Predicate 至少檢查 Task Status、Dependency、Owner／Lease、Worker Capability、Workspace Scope 與 Task Version。

Result Submission 也要驗證 Task ID、Expected Task Version、Claim Generation／Token、Workspace／Result Version、Submitter Ownership，以及 Task 是否已 Cancelled／Superseded。

Lease 只處理「Owner 多久沒有 Renewal」。舊 Worker 在 Network Partition 後醒來，仍可能提交。Task Store 或 Integration Gate 必須以單調遞增的 Claim Generation／Fencing Token 拒絕 Stale Result。

Atomic task claiming, lease and reassignment

Figure 7-4｜Claim 是 Atomic Transition；Lease 支援 Reassignment，Claim Generation 阻止過期 Worker 提交 Stale Result。

Lease 是可更新的 Operational State，不是副作用保證

Lease 通常包含 lease_id、owner_id、claim_generation、claim_token、時間、Heartbeat、Release 與 Reclaim Policy。Heartbeat Renewal 應使用 Expected Version，不能讓過期 Worker 延長已被 Reclaim 的 Claim。

Lease Expiry 不表示 Operation 可以立刻重跑。若 Worker 可能已造成 External Side Effect，Coordinator 必須先查 Operation ID 與 External Authority。Part 08 會處理 Unknown Outcome、Idempotency 與 Reconciliation。

Task 可以被重新認領，不代表之前的 Side Effect 可以安全重複；舊 Worker即使仍在執行，也不再保有提交權。

Task Portfolio：不是每個工作都值得多開幾個 Agent

Multi-agent 有協調、Context、Budget、Merge 與 Verification 成本。是否委派，可以從以下維度判斷：

Outcome Clarity
Verification Quality
Reversibility
Blast Radius
Context Availability
Dependency Stability
Judgement Density
Expected Review Cost
Parallelisability
Human Learning Value

High-confidence delegation

適合背景或平行執行：

有測試的機械式 Refactor
有穩定 Reproduction 的 Bug
邊界清楚的 Migration
從 Canonical Source 更新文件
不會對外回覆的 Issue Triage
有固定 Report Schema 的 Research

Exploration

可以委派，但輸出是 Option 與 Evidence，不是可直接 Ship 的結果：

Library Survey
Architecture Alternatives
Prototype Directions
Reproduction Experiment

Human-primary

人類應保有主導：

Product Intent 不清楚
不可逆或高風險決策
缺少可靠 Evaluator 的專業判斷
Security、Legal 或 Financial 高風險工作
人類學習本身就是任務目標

多 Agent 不會把模糊需求變清楚。它只會讓模糊需求更快地分裂成多個 Branch。

Capability-tiered Coordination：強模型規劃，受限 Worker 執行

某些工作只有少量步驟需要高階判斷，大量成本則花在搜尋、分類、轉換與讀取。

可以讓 Coordinator：

分解問題
指定 Coverage
檢查衝突
整合結論

再讓受限 Worker：

搜尋指定區域
執行重複查詢
產出結構化 Finding
保留 Provenance 與 Coverage Gap

這種方式成立的條件是：

子任務可以清楚切割
Worker Output 能被驗證
Raw Data 不必全部進入 Coordinator Context
Coordinator 有能力發現缺口與衝突
Coordination Cost 低於節省的成本

不要假設便宜模型必然適合執行。若 Worker 的錯誤很難被發現，低單價只是在把成本移到 Review 與事故處理。

Workspace Isolation：隔離 Write Surface，而不只是開另一個資料夾

Parallel Coding Agent 不能只靠 Prompt 約定「不要改同一個檔案」。

每個 Work Unit 可能需要獨立的：

Git Branch／Worktree
Container／Filesystem Snapshot
Database Schema／Test Tenant
Queue／Topic Namespace
Object-store Prefix
Temporary Credential Scope
Port、Service Instance 或 External Sandbox

Claude Code 的現行文件支援以 Worktree 隔離 Parallel Session／Subagent 的 File Edit；OpenAI Codex 也支援平行 Subagent Workflow。這些能力證明 Isolation 很實用，但 Worktree 只隔離 Checkout，不會自動隔離 Database、Cloud Resource、Credential 或 External Side Effect。⁹⁵

Anthropic 的平行 C Compiler 實驗讓多個 Container 各自 Clone Repository，再 Push 到 Shared Upstream。它也展示另一半問題：平行執行仍需要 Work Partition、Synchronization 與 Test，否則只會放大 Conflict。¹⁰

Workspace Lifecycle 應明確：

Validate name and resource scope
→ create isolated workspace
→ bind task, claim generation and owner
→ pin base revision and environment
→ execute
→ verify local result
→ submit integration candidate
→ rebase / merge in controlled order
→ run integration verification
→ accept / repair / discard
→ cleanup after retention checks

Workspace isolation and integration lifecycle

Figure 7-5｜Workspace 隔離 Local Write；Integration Gate 針對精確 Source Head、Dependency Order、External Resource 與最新 Evidence 重新驗證。

Workspace Metadata

至少保存：

Workspace ID
Repository／Base Ref
Original Commit
Branch／Snapshot ID
Task、Owner、Claim Generation
Resource Namespace
Config／Tool Catalog Version
Created At
Current State
Dirty Files
Local Verification Evidence
Integration Candidate Head
Cleanup／Retention Decision

Isolation 不能解決 Semantic Conflict

兩個 Agent 即使沒有修改同一檔案，仍可能：

對同一 API 做出互斥假設
產生衝突的 Migration Order
修改不同位置但共用一個 Schema
建立語意重複的 Abstraction
Local Test 通過，整合後失敗
共用同一 Test Tenant 或 External Sandbox，彼此污染

Integration Gate 應檢查：

Candidate Head 是否仍等於被驗證的 Source Head
Claim／Task Version 是否仍有效
Ownership／Write-set Conflict
Rebase／Merge Strategy
Schema 與 Migration Ordering
Shared External Resource Cleanup
Integration／Contract／End-to-end Test
Final Verifier 與 Acceptance Record

Merge 會建立新的 Combined State，因此 Local Evidence 不能直接當作 Integration Evidence。若 Base Branch 在 Worker 執行期間前進，可能需要 Rebase 後重跑受影響測試。

隔離防止即時覆寫。它不會自動提供共享 World Model、Dependency Order 或可接受的整合結果。

Partial Completion：不要只允許 Success 或 Failure

長任務常在以下狀態停止：

已完成部分子任務
主要實作完成，但驗證不足
遇到需要人類判斷的 Blocker
Worker Budget 用完
External Dependency 不可用
任務被取消，但已有可保留 Artifact

因此 Child、Worker 與 Session 的 Terminal Report 至少應區分：

completed
partial
blocked
failed
cancelled
unknown

還要區分 Worker Outcome 與 Task Acceptance。Worker 可以回報 completed，但在 Parent／Integration Gate 驗證前，Task 最多是 result_submitted。只有 Acceptance Contract 通過後，Authoritative Task State 才能進入 completed。 partial 不是比較委婉的 Success。它必須附上：

已完成範圍
未完成範圍
已取得 Evidence
尚未驗證的 Claim
副作用與 Operation ID
Workspace／Artifact Location
建議的 Next Safe Action

Coordinator 再依 Task Contract 決定是否接受部分結果、重新委派，或升級給人處理。

Graceful Shutdown：先停止接新工作，再處理手上的狀態

直接 Kill Worker 可能留下：

Partial File Write
Active Tool Process
Held Lease
Unflushed Artifact
Pending Message
Unknown External Side Effect

Graceful Shutdown 通常需要：

發出 Stop Request
Worker 停止接受新 Task
Active Work 在 Safe Point Checkpoint 或 Cancel
釋放 Lease 與 Resource
持久化 Partial Result 與 Final Evidence
回覆 Termination Acknowledgement
Runtime 清理 Workspace 與 Process

這不表示所有操作都能安全中斷。某些 Tool Call 必須完成到可知狀態，再由下一篇談的 Recovery 與 Reconciliation 接手。

用一個跨模組 Migration 走一次

假設任務是：

將付款狀態從舊 Enum 遷移到新版 Schema，更新 API、Webhook、Dashboard 與測試，但不執行 Production Migration。

1. Initializer 建立任務骨架

Harness 產生：

Task Contract
Feature／Work Unit Inventory
Progress Ledger
Base Workspace
Baseline Test Report
Verification Plan

2. 第一個 Session 選擇 bounded unit

Agent Claim update-domain-enum，在隔離 Workspace 修改 Domain Model 與 Unit Test。

3. Verification 與 Handoff

測試通過後，保存 Commit、Test Run、Diff Artifact，原子更新 Ledger，下一步設定為 migrate-api-mapping。

4. Fresh Session Bootstrap

新的 Agent 不讀舊 Transcript。它從 Contract、Ledger、Checkpoint 與 Repository 驗證目前狀態，確認 Baseline Failure 沒有改變。

5. Parent 委派 Read-only Subagent

Parent 要求 Child 找出所有舊 Mapping Caller。Child 只能搜尋與跑唯讀測試，回傳 Caller Inventory、File Reference 與 Coverage Gap。

6. 多 Worker 平行處理

API 與 Dashboard Task 分別取得 Atomic Claim 與獨立 Worktree。Webhook Task 因依賴 API Contract，保持 Blocked。

7. Lease Expiry

Dashboard Worker Crash。Lease 到期後 Task 可以 Reassign，但 Harness 先保留 Partial Branch 與 Artifact，不直接刪除 Workspace。

8. Integration

Coordinator 收集 Child Evidence，合併 API 與 Dashboard Branch，執行 Contract Test、Integration Test 與 Migration Order Check。

9. Partial Stop

Webhook 依賴外部 Team 確認。Harness 將任務標記 partial，列出已完成範圍、Blocker 與 Next Safe Action，而不是宣告整個 Migration 完成。

這個案例中，模型負責推理與執行。讓工作跨 Session 與 Agent 不變成考古現場的，是外部 Task State、Ownership、Evidence 與 Workspace Lifecycle。

用十二個問題審查長任務與 Multi-agent Harness

Task Truth 是否存在 Session 外，而且不依賴完整 Transcript？
Runtime 如何在 Continuous Run、Compaction 與 Fresh Session 之間做選擇？
Fresh Session 前是否已到 Safe Boundary，並提交可驗證 Handoff？
Progress Ledger 是 Authoritative State，還是 Task Store 的 Versioned Projection？
Handoff Manifest 如何避免 Ledger、Workspace、Checkpoint 與 Artifact 的 Dual-write 裂縫？
Child Contract 是否固定 Input Snapshot、Resource Grant、Authority Ceiling、Cancellation 與 Acceptance？
Child Output 是否保留 Provenance／Trust Role，而不是自動升格成可信指令？
Message Protocol 如何處理 Duplicate、Late、Acknowledged、Submitted 與 Accepted？
Claim 是否 Atomic，並以 Task Version、Claim Generation／Fencing 拒絕 Stale Result？
Delegation 是否根據 Parallelisability、Verification Cost、Blast Radius 與 Human Learning Value？
Workspace 是否同時隔離 File、Environment 與 External Resource，Integration Gate 是否驗證精確 Source Head？
Partial、Blocked、Cancelled 與 Shutdown 是否保存可恢復 Evidence、Claim 與 Next Safe Action？

若答案仍是「Agent 會記得」、「大家都看得到同一個 Chat」、「Lease 過期就直接重跑」或「Worktree 已經隔離一切」，系統只是把失憶、競態與衝突平行化。

理論轉實作：Part 07 檢查表

Part 08 會處理下一個問題：當 Worker、Tool、Network 或 External System 失敗時，Harness 如何在 Retry、Fallback、Replan、Reconciliation、Compensation 與 Stop 之間選擇，而且不重複 Side Effect？

References

Anthropic, Effective harnesses for long-running agents, 26 November 2025. ↩
Anthropic, Harness design for long-running application development, 24 March 2026. ↩
OpenAI, Run long horizon tasks with Codex, 23 February 2026. The cited run is an experiment, not a general production guarantee. ↩
Anthropic, Create custom subagents, accessed 8 July 2026. ↩
OpenAI, Subagents, accessed 8 July 2026. ↩ ↩²
Anthropic, How we built our multi-agent research system, 13 June 2025. ↩
Anthropic, Effective context engineering for AI agents, 29 September 2025. ↩
Anthropic, How we contain Claude across products, 25 May 2026. ↩
Anthropic, Run parallel sessions with worktrees, accessed 8 July 2026. ↩
Anthropic, Building a C compiler with a team of parallel Claudes, 5 February 2026. ↩