Agent 產品很容易展示「會做什麼」：查資料、改程式、操作瀏覽器、呼叫 API，再把進度串流到一個漂亮介面。

架構審查真正需要回答的是另一組問題：

Request 進來後，誰確認身份與 tenant？誰決定這次能用哪些工具？哪一份狀態代表這次執行？模型說完成時，誰根據什麼證據接受它？Client 斷線後，任務由誰繼續持有？

功能清單回答不了這些問題。

一套系統可以同時具備 RAG、Memory、MCP、Workflow、Multi-agent 與 Trace UI，卻在第一個失敗情境中裂開：前端顯示完成，Worker 還在執行；Task Runner 與 Agent 各自 Retry，讓同一副作用發生兩次；模型聲稱測試通過，實際只跑了一個套件；Browser tab 關閉後，唯一的進度也跟著消失。

架構圖的價值不在框的數量，而在於它是否畫清楚 Authority、State Ownership、資料流、證據與失敗責任。

Part 01 界定了 Harness 的工作範圍。Part 02 把那些責任放進同一張系統地圖。這裡說的「完整」，指的是責任覆蓋完整，不代表每套系統都要採用相同部署拓撲，也不要求每個框都拆成 Microservice。

Canonical Harness Architecture

Figure 2-1｜完整的責任地圖需要說清楚 Request 如何進入、誰持有執行真相、誰能授權行動，以及完成如何被證據接受。

先找 Authority，再看功能

評估 Agent 架構時，先數功能通常會把問題看反。

兩個產品都寫著「支援 Retry」，可能指完全不同的機制：

  • SDK 在 HTTP Timeout 後重送模型 Request
  • Agent Loop 在 Tool Failure 後重新規劃
  • Task Runner 在 Worker Crash 後重啟整個 Work Unit
  • Orchestrator 把工作重新指派到另一個 Workspace

四層都會重試，不會自動比一層更可靠。若 Retry Ownership 沒有被定義，它們可能重複部署、重複寄信或重複寫入資料。

State 也有相同問題。Frontend、Agent Memory、Workflow Engine、Issue Tracker 與 Database 都可能保存 status，但沒有規則說明衝突時以誰為準。Happy Path 看起來一致，斷線、取消或恢復後便開始分岔。

一張可用的 Harness 架構圖至少要回答：

  1. 哪個元件擁有哪一項決策權？
  2. 哪個記錄對哪一類事實具有 Canonical Authority？
  3. 一次操作如何跨越邊界，並留下可關聯的證據？
  4. 失敗、取消、斷線或重試後，責任回到哪裡？

沒有這些答案，圖上即使放滿技術名詞，也很難用來審查系統。

一張以責任為中心的參考架構

下面是一個通用的責任模型：

User / Client Request
 ↓
Request Boundary
 identity · tenant · schema · admission
 ↓
Task Contract + Effective Policy
 objective · acceptance · budget · tools · approval
 ↓
Canonical Run Authority ↔ Workflow / Agent Controller
 ├─ Context Builder
 ├─ Model Adapter
 ├─ Query Planner / RAG
 ├─ Capability Registry / Execution Runtime
 ├─ Hooks / Middleware
 └─ Approval and Recovery Gates
 ↓
 Verification + Completion Gate
 evidence · criteria · authority
 ↙ ↘
Not accepted: repair / retry / fallback / stop Accepted
 ↖ ↓
 └──────── Controller Commit state and evidence
 ↓
 Response / Stream / Artifact

Cross-cutting:
- Durable State / Checkpoint / Artefact Store
- Trace / Metrics / Audit / Replay / Eval Data

這張圖不是單純的線性 Pipeline。

Canonical Run Authority 必須在整個執行期間被讀取與更新；Persistence 與 Observability 也不是最後才補上的 Dump。它們橫跨 Request Boundary、Controller、Capability Execution、Approval、Verification 與 Delivery。

同一個 Process 可以承擔多項責任。一項責任也可能由多個服務協作完成。重點是 Authority 清楚，而不是服務數量漂亮。

1. Request Boundary：先建立可信的入口

Request Boundary 把外部輸入轉成內部系統可以安全處理的 Request。

它通常處理：

  • Authentication：Request 是誰送出的
  • Tenant / Project Scope：該身份屬於哪個資料與資源範圍
  • Initial Authorisation：是否可以啟動這類工作
  • Input Schema：欄位、格式、大小與必要參數是否合法
  • Rate Limit / Admission Control：系統現在是否接受工作
  • Request ID / Correlation ID：後續事件如何被串起來

這一層不能只確認「有登入」。多租戶系統若只把一段自然語言丟進後端，RAG、Memory、Tool、Trace 與 Artifact 很可能在下游失去 tenant 邊界。

Request Boundary 也不應替模型猜完整意圖。它先固定可信的身份、範圍與輸入形狀，讓後面的元件不必各自重新解讀一次。

2. Task Contract 與 Effective Policy：把完成條件和執行權限分開

Task Contract 回答：

這次工作完成時，應產出什麼，而且拿什麼證明？

常見內容包括：

  • Objective
  • In-scope / Out-of-scope
  • Required Outputs
  • Acceptance Criteria
  • Required Evidence
  • Completion、Pause 與 Stop Conditions

Task Contract 不一定由模型即時生成。它可以來自 API Request、Issue、Workflow、人工規格或版本化模板。關鍵是這次 Run 使用哪一版 Contract，必須可以追溯。

Policy 回答另一個問題：

在目前身份、tenant、任務與風險條件下，系統允許怎麼執行？

它可能包含：

  • 可用模型與 Fallback
  • Token、時間、成本、容量與步數上限
  • 可用工具、資料來源、Filesystem 與 Network 範圍
  • Timeout、Retry、Escalation 與 Cancellation 規則
  • 哪些 Operation 需要人工批准
  • 哪些 Verification Gate 必須通過

實際 Policy 往往來自 Organization、Tenant、Project、Task、Tool 與單次 Operation。集中 Authority 不等於把所有規則塞進同一份檔案，而是要有一個地方解析優先順序，產生可稽核的 Effective Policy。

若 Timeout 藏在 SDK、Budget 寫在 Controller、Tool Deny 放在 Hook，另一份 Allow List 又塞在 Prompt 裡，出事時每個元件都可能聲稱自己照規則行事，系統卻說不出哪個規則優先。

Task Contract 與 Policy 可以被摘要進 Prompt，但硬限制仍應由 Runtime、Policy Decision 與執行環境強制。

3. Canonical Run Authority：單一權威不等於單一資料表

RunState 保存的是一次執行的系統事實，不只是聊天內容。

它可能包含：

  • Run、Thread、Turn 與 Task Identity
  • 目前 Phase、Status 與 State Version
  • 已使用的 Budget
  • Tool Request、Operation ID、Result 與 Unknown Outcome
  • Pending Approval
  • Checkpoint、Artifact 與 Evidence Reference
  • Policy、Prompt、Model 與 Tool Schema Version
  • Cancellation、Error、Recovery 與 Completion State

Transcript 可以是 RunState 的一部分或衍生視圖，不能和完整執行真相畫上等號。

例如 Tool 已經成功寫入外部 Database，但 Result Event 因網路中斷沒有回到 Agent。Transcript 可能看起來像「尚未執行」，外部系統卻已經發生副作用。這時外部 Database 對自身資料仍有 Authority；RunState 要保存 Operation ID、已知結果與 Reconciliation 狀態，而不是假裝自己能取代所有外部真相。

因此，「Canonical」不代表所有事實都塞進一筆 Record。它代表：

  • 每一類關鍵事實都有明確 Authority
  • 一次 Run 的生命週期與 State Transition 有唯一控制權
  • 其他 Projection 可以被重建或 Reconcile
  • Client 顯示、Dashboard 與 Issue Status 不能各自改寫 Run 的真相

Part 06 會完整處理 Thread、Checkpoint、Pause、Resume、Fork 與 Persistence。Part 02 先固定一條邊界：Client Memory 不能成為長任務唯一的 Source of Truth。

4. Controller 協調執行，但不應吞掉所有責任

Workflow / Agent Controller 根據 Task Contract、Effective Policy、Canonical Run State 與最新 Observation，決定下一個合法的 State Transition。

在固定 Workflow 中，主要路徑由程式預先定義；在較自主的 Agent 中，模型可以提出下一步與 Tool Request。Anthropic 把前者描述為由預定 Code Path 協調模型與工具的 Workflow，後者則讓模型動態主導流程與工具使用。兩者都能存在於同一套 Harness；差別是 Decision Authority 放在哪裡。1

OpenAI 對 Codex 的拆解也顯示相同層次：Agent Loop 負責協調使用者、模型與工具；完整 Agent Experience 還需要 Thread Lifecycle、Persistence、Config、Auth、Tool Execution 與 Client Protocol。23

Controller 周圍常見的能力可以這樣分：

能力主要責任不應偷偷承擔的責任
Context Builder組裝 Instructions、Task State、History、Evidence 與可見 Tools不應成為 Durable Memory 的唯一 Authority
Model Adapter隔離 Provider Request、Streaming、Tool-call Format 與 Error不應混入 Product Policy
Query Planner / RAG判斷何時檢索、查哪些來源、如何組合 Evidence不等於整個 Orchestrator
Capability Registry描述 Schema、Risk、Cost、Timeout 與 Permission Requirements不等於已經授權這次 Operation
Execution Runtime驗證參數並執行 Tool、Command、API 或 Sandbox Action不應接受模型自我授權
Hooks / Middleware在明確 Event Point 觀察、轉換或附加控制不應成為第二個隱形 Controller
Approval / Recovery Gates暫停、取得人類決定、Repair、Fallback、Reconcile 或 StopHuman Approval 不是一般 Tool Call

這裡將 Registry 與 Runtime 分開，是因為「系統知道某個 Tool 存在」和「這次 Operation 已被授權並成功執行」是不同事實。

Approval 也不是一張和 Context Builder 平行的功能卡。它是一個受 Policy 與 State 約束的 Gate，必須綁定具體 Operation、Arguments、Risk、Expiry 與當前 State Version。

一小段 Pseudocode 能證明什麼？

Part 02 可以用短 Pseudocode 表達責任順序：

def handle_agent_request(request):
 principal = request_boundary.admit(request)
 contract = contracts.resolve(request, principal)
 policy = policies.resolve_effective(contract, principal)
 run = run_store.start(contract, policy)

 while not run.is_terminal:
 step = controller.next_step(run)

 if step.kind == "model":
 event = model_adapter.invoke(context_builder.build(run))
 elif step.kind == "capability":
 grant = policy.authorise(step.operation, run)
 event = capability_runtime.execute(step.operation, grant)
 elif step.kind == "approval":
 event = approval_gateway.request(step.operation, run)
 else:
 event = step.as_event()

 evidence = verification.check(event, run, contract, policy)
 run = run_store.commit_transition(run, event, evidence)

 return delivery.from_committed_run(run)

它可以說明：

  • Identity 與 Scope 在 Agent Execution 前建立
  • Contract 與 Effective Policy 是不同責任
  • Controller 只從已提交的 Run State 推進
  • Model Proposal 不會直接變成 Tool Execution
  • Approval 是 State Transition，而非聊天中的一句「可以」
  • Verification Evidence 與 State Transition 一起被提交
  • Delivery 來自已提交的 Terminal State

它不能證明：

  • Distributed Lock、Concurrency 與 Worker Crash 已正確處理
  • Side Effect 具備 Idempotency、Unknown-outcome Reconciliation 與 Compensation
  • Streaming、Approval Expiry、Cancel 與 Reconnect Semantics 正確
  • Authentication、Tenant Isolation、Sandbox 或 Secret Boundary 已安全實作
  • 這段示意程式可以直接進 Production

程式碼看起來像真的，不代表它證明了 Production Readiness。Proof Boundary 必須另外寫清楚。

5. Verification 與 Completion Authority：生成者不能自我驗收

模型可以產生候選答案、Patch 或行動計畫。它不應同時擁有最終 Pass Authority。

Verification 可以組合：

  • Deterministic Tests
  • Schema Validation
  • Lint、Type 與 Architecture Checks
  • Citation / Grounding Checks
  • Permission 與 Side-effect Evidence
  • Browser / API Journey
  • 經校準的 Model-based Evaluator
  • 特定風險類別的人類 Review

但「Verifier」不一定是一個中央服務，也不應被理解成無條件掌握所有權力。

更精確的做法是把它視為 Verification and Completion Gate：

  1. Verifier 產生與彙整 Evidence。
  2. Task Contract 定義必須滿足哪些 Criteria。
  3. Effective Policy 決定哪些 Gate、Threshold 或 Human Decision 適用。
  4. Completion Authority 只接受符合當前 Contract、Policy 與 State Version 的結果。

可修復的 Failure 也不應只回傳 false。它至少需要指出：

  • Failed Criterion
  • Supporting Evidence
  • Repair Boundary
  • 是否允許 Retry、Fallback 或 Escalation

OpenAI 的 Harness Engineering 文章把可執行 Architecture Constraints、Feedback Loops 與持續掃描用來維持 Agent-generated Codebase 的一致性。這類 Sensor 的價值，在於把品質判斷從模型自我宣告移到外部可檢查的 Control。4

Part 10 會展開 Verifier、Quality Gate 與 Evaluation。這一篇只先確立位置：候選產出必須通過獨立於生成者的 Acceptance Path，才會進入 Accepted Completion。

6. Persistence 與 Observability 是橫切責任

Persistence 不能只在最後把結果 Dump 進 Database。

Harness 可能需要持久化：

  • Canonical Run State 與 Version
  • Transition Event 與 Event Ordering
  • Checkpoint
  • Tool Request / Result Pairing
  • Operation ID 與 Side-effect Reconciliation State
  • Policy Decision 與 Approval Record
  • Artifact、Diff 與 Evidence Reference
  • Model、Prompt、Tool、Retriever 與 Config Version

Observability 則回答另一組問題：

  • 哪一步變慢或變貴？
  • 哪一版 Policy 允許了 Operation？
  • Model 在 Retry 前看見了什麼？
  • 哪個 Tool 改變了外部狀態？
  • Verification 為何失敗？
  • 能否重建或 Replay 這次 Trajectory？

兩者資料會重疊，但用途不同。Persistence 支援一致性與恢復；Observability 支援看見、診斷與營運。

「全部 Log 下來」也不是設計。敏感欄位需要 Redaction，Event Schema 需要版本，Trace 要能用 Run ID、Turn ID、Tool Call ID 與 Operation ID 關聯。否則系統只是把不可查的文字變得更貴。

最重要的順序是：

Execute
→ record outcome
→ verify
→ commit state and evidence
→ deliver response or event

回覆 Client 之前，系統不一定要同步完成所有冷資料寫入，但必須先完成足以恢復、去重與證明當前狀態的 Durable Commit。

一次 Request 的八個階段

Eight-stage Agent Request Lifecycle

Figure 2-2｜一次 Request 是身份、政策、狀態、執行與證據的連續轉換，不只是 Model Call 後接一個 Response。

一個典型 Request 可以分成八階段：

  1. Client 建立 Request：提交 Input、Thread Reference 與 Client Capabilities。
  2. Boundary Admission：確認 Identity、Tenant、Authorisation、Schema 與 Capacity。
  3. 解析 Contract、Effective Policy 並啟動 Run：固定本次執行的目標、限制、版本與 Correlation IDs。
  4. 組裝 Context：載入 Instructions、History、Run State、Retrieved Evidence 與可見 Capabilities。
  5. 執行 Model Inference：模型產生候選輸出、Tool Request 或下一步 Proposal。
  6. 授權並執行 Capability：Harness 驗證 Operation，必要時進入 Approval Gate，再執行並記錄 Observation。
  7. 驗證並提交 State Transition：套用當前 Gate，保存 Evidence，選擇 Continue、Repair、Retry、Fallback 或 Stop。
  8. 完成 Durable Commit 並交付：確認 Terminal State、Artifact、Trace 與必要 Evidence 已持久化，再以 Response 或 Event Stream 更新 Client。

不是每個 Request 都會重複走滿八階段。唯讀問答可能只需要一次 Model Inference 與 Verification；長任務則會在第 4～7 階段循環多次。

以 RAG 問答為例，模型提出 rag_search 只代表它需要資料。Harness 還要套用 Tenant Filter、執行 Retrieval、保存 Source Reference、把結果送回模型，再檢查 Citation 與 Grounding。呼叫搜尋工具，不等於答案已經 Grounded。

Control Plane 與 Data Plane

Control Plane 與 Data Plane 是責任分界，不是 Microservice 規定。

Data Plane 執行工作

  • 呼叫模型
  • 執行 Tool、Command 與 API
  • 讀寫 Workspace
  • 查詢 RAG 或 Database
  • 產生 Artifact
  • 執行測試

Control Plane 決定工作如何被允許與推進

  • Identity、Tenant 與 Effective Policy
  • Task Contract、Priority 與 Admission
  • Budget、Capacity 與 Cancellation
  • Canonical Run State
  • Approval、Escalation 與 Completion Authority
  • Version、Deployment、Rollback 與 Kill Control

兩者可以存在同一個 Process。分界的用途，是避免 Tool Worker 悄悄改寫全域 Policy，也避免 Client Button 直接跳過 Server Authority。

一個可擴展的原則是：

集中管理 Invariants 與 Authority，在受控邊界內保留局部自主。

Architecture Dependency、Tenant Scope、Required Tests 與高風險批准可以集中強制；Agent 仍可在邊界內選擇演算法、局部重構路徑與允許的 Tool 順序。控制「不能破壞什麼」，通常比規定每一步怎麼做更耐久。

Headless Harness Service：讓多個 Client 共用同一套執行核心

Headless Harness Service

Figure 2-3｜多個 Client 透過穩定的雙向 Protocol 共用 Harness Service、Agent Core 與 Durable Thread State。

當同一個 Agent 要出現在 CLI、IDE、Desktop、Web 與 Partner Product 時，最直接的 Prototype 是每個 Client 各接一次 Agent SDK。很快便會出現行為分岔：

  • 某個 Client 支援 Approval，另一個不支援
  • Diff、Progress 與 Tool Event 在不同介面使用不同語意
  • 每個 Client 各自組裝 Prompt 或維護 Session State
  • 修正 Agent Loop 時，需要同步修改多個產品

Headless Harness Service 把執行核心與 Durable State 放在不依賴 UI 的 Runtime 中。Client 負責輸入、呈現與互動，不負責成為長任務的唯一 Authority。

CLI / IDE / Desktop / Web / Partner Client
 ↕
 Stable bidirectional protocol
 ↕
 Headless Harness Service
 auth · thread manager · events
 approvals · config · negotiation
 ↕
 Agent Core Runtime
 loop · context · tools · sandbox
 ↕
 Durable Thread State / Event History

OpenAI 的 Codex App Server 是一個具體例子。OpenAI 說明 Codex Web、CLI、IDE Extension 與 Desktop App 由同一套 Codex Harness 支撐；App Server 提供雙向 JSON-RPC 介面，讓 Client 提交 Request、接收多個 Event Update，Server 也能在需要 Approval 時主動發出 Request 並暫停 Turn。3

這個案例同時顯示一個重要細節：相同 Harness 不代表所有 Client 都必須使用完全相同的部署方式。Local App 可以啟動 Child Process；Web Runtime 可以在 Container 中執行；某些 Client 也可能暫時保留 Same-process Integration。需要穩定的是 Thread Identity、Event Lifecycle、Approval、Cancellation、Version Negotiation 與 Reconnect Semantics。

Headless 是邏輯邊界，不是「一定遠端」的同義詞。Harness Service 與 Agent Core 也可以在同一個 Process 中，只要 Client Protocol 與 State Authority 沒有因此變得模糊。

Composable Harness Stack：組合可以，重複掌權不行

Production Harness 很少由單一產品包辦。常見組合可能是：

Requirement / Issue System
→ Task Runner
→ Orchestrator
→ Coding Agent
→ Sandbox / Workspace
→ Tool and Protocol Layer

Runtime State、Memory、Policy、Observability、Evaluation 與 Artifact Storage 可能橫跨整個 Stack。

問題不在組合，而在 Authority 重疊：

衝突典型後果
Double Retry同一 Side Effect 執行兩次
Split-brain Task State看板、Worker 與 Agent 對狀態各有不同答案
Duplicate MemoryRuntime、Project Notes 與 Local Memory 保存不同版本的事實
Nested Sandbox外層與內層的 Mount、Network 或 Permission Policy 衝突
Conflicting ApprovalUI Approval 繞過 Enterprise Deny，或兩層 Gate 給出相反決定

每兩層交界至少要有 Integration Contract，說清楚：

  • Identity 與 Tenant Scope 如何傳遞
  • Operation / Correlation ID
  • Payload 與 Protocol Version
  • Error、Retry、Cancellation 與 Unknown Outcome Semantics
  • Evidence、Audit 與 State Reconciliation
  • 哪一層擁有最終 Authority

加入新元件前，先問：

移除它之後，哪一個具體 Failure Mode 會重新出現？

如果回答不出來，新增的可能不是控制，而是另一層維護成本。

Agent 生態不是單一產品類別

Agent Harness Ecosystem Layers

Figure 2-4｜九類 Agent 產品解決不同層級的 Failure Mode；它們不是一條成熟度階梯，也不應直接放進同一排行榜。

以下九類是本系列使用的分析地圖，不是業界標準，也不是固定的產品標籤。成熟產品可能跨越多個類別。

類別主要解決的問題
Coding Agent直接讀寫程式碼、使用工具並交付 Patch 或 Artifact
Agent Runtime管理跨 Turn / Session 的執行、事件與 Process Lifecycle
Harness Framework提供 State、Tool、Checkpoint、Policy 與 Subagent Primitives
Task Runner把 Issue、Ticket 或 Spec 轉成可追蹤的 Work Unit
Orchestrator管理多個 Agent、資源、並行、隔離與工作 Ownership
Full Lifecycle Platform串接需求、執行、驗證、批准、部署與治理
Knowledge / Memory Layer管理跨 Session 知識、偏好、歷史、讀取與過期
Requirements / Specification Layer把人類意圖轉成可執行、可驗證的需求
Standards / Protocol Layer定義跨 Tool、Client、Agent 或 Repository 的交換契約

分類的用途是先定位問題：

  • MCP 提供互通契約，不會自動成為 Authorisation System
  • Coding Agent 不等於 Durable Runtime
  • Orchestrator 不會自動解決 Memory Governance
  • Task Runner 不等於完整 SDLC
  • Full Lifecycle Platform 也可能超出一個 Queue Consumer 的實際需求

先找到 Failure Mode 所在的層級，再比較產品。否則同一張 Ranking 可能同時放進執行者、Runtime 與協調平台，分數看似精確，問題卻沒有對齊。

Harness 想把什麼調節到 Desired State？

「元件齊全」也不能直接證明 Harness 有效。還要問它想把系統維持在什麼 Desired State。

MartinFowler.com 的文章在 Coding-agent 脈絡下區分 Maintainability、Architecture Fitness 與 Behaviour Harness。5 本系列在這三類之外，再加入 Reliability / Operations 與 Product Quality / Taste，作為較完整的產品與營運視角。後兩類是本文的延伸，不應反過來歸因給原文章。

Regulation Domain想維持的狀態常見 Sensor
MaintainabilityDuplication、Complexity、Dependency Hygiene、Documentation DriftLint、Static Analysis、Test-quality Checks
Architecture FitnessModule Direction、Ownership、Layering、API BoundaryArchitecture Tests、Dependency Analysis
BehaviourAcceptance Criteria、User Journey、Permission、Business CorrectnessAPI / Browser Tests、Contract Tests
Reliability / OperationsLatency、Error、Capacity、Recovery、Data IntegrityRuntime Telemetry、SLO、Incident Replay
Product Quality / TasteConsistency、Accessibility、Design Judgement、Writing VoiceCalibrated Rubric、Model Evaluator、Human Sampling

同一套 Harness 不必同時覆蓋全部 Domain，但每個 Domain 都要回答：

  • Desired State 是什麼？
  • 最重要的 Failure Mode 是什麼？
  • 哪些 Guide 與 Sensor 可 Deterministic？
  • 哪些需要 Semantic Judgement 或 Human Sampling？
  • 誰擁有最後 Authority？

Desired State 沒有被定義，再多 Sensor 也無法穩定證明「做對了」。

用這張地圖審查一套 Agent 系統

面對新的 Agent 架構，可以依序追問：

  1. Request 在哪裡被 Admit？ Identity、Tenant、Schema 與 Capacity 由誰確立？
  2. Contract 與 Effective Policy 在哪裡？ 目標、Budget、Tools、Approval 與 Stop Conditions 是否可追溯？
  3. 每類 State 的 Authority 是誰？ Client、Worker、External System 與 Issue Tracker 衝突時如何 Reconcile？
  4. 誰推進 State Transition？ 哪些步驟由程式決定，哪些允許模型提議？
  5. 誰授權並執行 Side Effect？ Operation ID、Retry Ownership 與 Unknown Outcome 如何處理？
  6. Completion 依賴哪些 Evidence？ Contract、Policy、Verifier 與 Human Gate 如何共同決定接受？
  7. Client 斷線或 Worker Crash 後怎麼恢復？ Durable Commit、Checkpoint、Reconnect 與 Replay 在哪裡？
  8. 組合元件是否重複掌權？ Retry、Memory、Approval、Workspace 與 Task State 是否有明確 Owner？

這八題能得到具體答案時，架構的真實形狀通常已經浮現。若答案只是「Framework 應該有處理」，下一步是找到真正的 State、Policy、Protocol 與 Evidence Contract，而不是再加一張 Logo。

理論轉實作：Part 02 檢查表

  • Request Boundary 明確處理 Identity、Tenant、Schema、Admission 與 Correlation ID。
  • Task Contract 與 Effective Policy 分開建模，版本與決策可以追溯。
  • Run Lifecycle、External Side Effect 與 Client Projection 的 Authority 邊界清楚。
  • Model Proposal、Capability Authorisation、Execution 與 Completion Acceptance 沒有混成一步。
  • Durable State 與 Evidence 在 Delivery 前完成足以恢復和去重的 Commit。
  • Headless Client Protocol 支援 Event、Approval、Cancel、Reconnect 與 Version Negotiation。
  • 多層 Stack 沒有 Double Retry、Split-brain State、Conflicting Approval 或重複 Memory Authority。
  • 團隊能說明這套 Harness 調節的 Desired State，以及哪些 Failure Mode 仍未被覆蓋。

Part 03 會進入這張地圖中央的 Controller，拆開 Agent Loop、Tool Request / Result Pairing、Streaming、Approval、Stop Conditions 與 Goal Drift。沒有 Part 02 的 Authority、State 與 Evidence 邊界，Loop 只會更快地放大原本的混亂。

Footnotes

  1. Anthropic, Building effective agents, 19 December 2024. ↩

  2. OpenAI, Unrolling the Codex agent loop, 23 January 2026. ↩

  3. OpenAI, Unlocking the Codex harness: how we built the App Server, 4 February 2026. ↩ ↩2

  4. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026. ↩

  5. Birgitta Böckeler, MartinFowler.com, Harness engineering for coding agent users, 2 April 2026. ↩