Harness 理論篇 Part 12｜模式、反模式與演化：如何讓 Harness 成長，也知道何時刪除？

假設一套 Agent 系統已經運作一段時間。

它有 Planner Agent、Review Agent、Memory、十幾個 Tool、數個 Hook、兩層 Retry、一份很長的規則檔、不同任務各自使用的 Prompt Template，還有一條沒有人敢拆的 Fallback Path。

接著模型升級了，Tool Provider 也新增原生能力。

團隊現在答不出幾個基本問題：

哪個元件仍然攔得到真實 Failure Mode？
哪條規則只是上一版模型的補丁？
哪個 Review Agent 提升品質，哪個只是增加 Token 與延遲？
哪份 Memory 還有人維護？
哪些 Tool 已經和 Runtime 內建功能重疊？
拿掉其中一層，品質真的會下降嗎？

元件很多，看起來像成熟架構。若沒有人能回答這些問題，它也可能只是一座整理得很漂亮的技術債倉庫。

Harness Engineering 的後半場，不是繼續加零件。它要建立一套方法，讓控制機制能從真實行為與風險長出來，也能在假設失效時被簡化、替換或刪除。

Behavior-to-Harness derivation loop

Figure 12-1｜從期望行為或已觀察 Failure 出發，依序找出缺少的控制、最小機制、外部證據與刪除條件。

不要從元件清單開始

第一次設計 Harness 時，很容易先問：

要不要加 Memory？
要不要上 MCP？
要不要做 Multi-agent？
要不要加 Reviewer？
要不要買一個 Agent Platform？

這些問題都太早。

它們直接跳到解法，卻沒有先說明要改變哪個行為、阻止哪個失敗，以及完成後拿什麼證明機制有效。

更可靠的推導順序是：

Desired behaviour or observed failure
→ Protected invariant or missing capability
→ Authority and canonical state
→ Smallest viable mechanism
→ External evidence and operating cost
→ Owner, review trigger and retirement condition

這個順序把 Harness 元件從「看起來應該有」，改成「為某個可描述的問題負責」。

一個簡單例子

假設目標是讓 Agent 在隔天接續一項長任務，而不是每次重新掃描整個 Repository。

Observed failure：

新 Session 不知道上一輪完成了什麼
已執行 Tool 的副作用無法確認
Agent 重做已完成工作
任務狀態只存在 Transcript

需要保護的 Invariant：

已完成工作不應被當成未開始
外部副作用必須有可查詢 Receipt
新 Session 必須能從 Durable Evidence 重建
任務狀態只能由 Canonical Authority 推進

最小機制可能是：

一份結構化 Progress Ledger
一個由 Runtime 管理的 Checkpoint
可引用的 Artifact
Session Bootstrap 驗證
Side-effect Operation ID

這時才有理由增加 Part 07 講過的長任務元件。若一份小型 Ledger 已經能解決問題，就沒有必要先部署一套 Multi-agent Coordination Platform。

每個新機制都應留下 Control Record

至少記錄：

control_id: durable-progress-ledger
failure_addressed: repeated work after session reset
protected_invariant: completed task state is not lost
authority: canonical-task-store
evidence:
  - fresh-session-reconstruction-test
  - duplicate-work-rate
cost:
  latency: low
  maintenance: medium
owner: agent-platform
review_triggers:
  - runtime upgrade
  - task model change
retirement_condition: native runtime state proves equivalent behaviour

這份 Record 不是永久許可證。它讓團隊知道元件為何存在、誰維護、如何驗證，以及底層能力改變後何時重新審查。

Mechanism Economy

同一個 Failure Mode 可能有很多解法。較合理的偏好順序通常是：

使用現有的 deterministic control
改善 Artifact 或 Context
增加可執行 Sensor
使用範圍明確的 Semantic Evaluator
最後才增加 Agent 或 Orchestration

這是一個預設偏好，不是宗教戒律。若 deterministic 機制無法表達語意風險，或維護成本已高於一個受限 Evaluator，就應以代表性 Evidence 比較，而不是為了「規則優先」繼續堆規則。

若 JSON Schema 能攔截參數錯誤，就不必讓另一個 Agent 花一輪推理來猜參數是否合理。若 Architecture Test 能確認 Dependency Direction，也不要把規則留在長 Prompt 裡，等模型每次重新理解。

模型適合處理語意、不確定性與開放探索。它不該被拿來替代每一個已能清楚編碼的 Constraint。

Deterministic-first 不是排斥 Agent

Deterministic-first 的意思，是先固定已知不能漂移的邊界，再把真正需要判斷的部分交給模型。

適合固定化的通常包括：

Authentication 與 Authorisation
Tenant 與 Resource Scope
Input Validation
Retry、Timeout 與 Budget
State Transition
Destructive 或 Financial Commit
Required Verification Gate
Audit 與 Release Authority

適合模型決策的通常包括：

模糊任務的拆解
語意 Routing
開放式搜尋策略
候選方案生成
無法以完整規則列舉的內容判斷

這不是把 Agent 關進一條死板 Workflow。它是在回答另一個問題：

哪些自由能增加任務品質，哪些自由只會增加不可預測性？

Anthropic 將 Workflow 與 Agent 區分為預先定義路徑和模型動態控制路徑，並建議只有在額外複雜度能實際改善結果時才加入 Agentic Layer。[1]

固定的是 Invariant，不一定是實作

例如「付款前必須有有效 Approval」是 Invariant。它可以由 Policy Engine、Workflow Gate 或受控 Transaction Service 實作。當底層平台提供更可靠的原生能力時，可以替換本地 Wrapper，但不能因為產品頁寫了「支援 Approval」就直接刪掉 Invariant。

同樣地：

可以刪除自製 Retry Wrapper，但不能失去 Attempt Budget 與 Unknown Outcome Control。
可以刪除 Secondary Reviewer，但不能失去 Blocking Criterion 的 Independent Evidence。
可以把 Memory Store 換成 Native Session State，但不能讓 Transcript 重新成為唯一狀態來源。

因此 Build-to-delete 的目標不是「越少控制越好」，而是：

保留必要 Invariant，用成本更低、責任更清楚的機制實現它。

例外與逃生路徑也要被治理

Deterministic Gate 若遇到合法例外，不能靠模型偷偷繞過。應使用：

Explicit Exception Type
Authority
Scope
Expiry
Evidence
Audit Record
Revalidation Trigger

否則「彈性」只會成為未命名的第二套 Policy。

元件順序錯了，元件本身再完整也沒用

Harness 的問題不只在於有沒有 Policy、Hook、Memory 與 Verifier，也在於它們插入 Agent Loop 的哪個位置，以及哪一個決策可以覆蓋哪一個決策。

一條較穩定的整合順序可以簡化為：

Receive event
→ Authenticate actor and resolve tenant
→ Load canonical state and control signals
→ Apply pre-discovery visibility and data policy
→ Build bounded context and capability snapshot
→ Call model
→ Inspect proposed operation
→ Canonicalise resource and arguments
→ Apply per-operation authorisation and approval
→ Execute or accept background work
→ Persist receipt, effect state and audit record
→ Append correlated observation
→ Verify terminal candidate
→ Commit completion, checkpoint or continuation

這裡其實有兩種 Policy Boundary：

Pre-discovery Policy：決定哪些資料、Tool Metadata 與資源可以被看見。
Per-operation Policy：在實際 Resource 與 Argument Canonicalise 後，決定這一次 Operation 是否能執行。

把兩者都寫成一個模糊的 policy_check()，很容易讓可見性與最終授權互相代替。

順序本身具有安全與可靠性意義：

Permission 若在 Path Canonicalisation 前執行，../、symlink 或 alias 可能讓授權判斷失效。
Dynamic Tool 已更新，但 Prompt 還持有舊 Catalog，模型會對不存在的能力做規劃。
Compaction 若刪除 Side-effect Receipt，後續 Retry 可能重複付款或寄信。
Task 先被標記 completed，Verifier 才開始執行，Pass State 就已經提前洩漏。
Scheduled Trigger 若繞過 Identity 與 Policy，它只是換一條入口越權。
Background Completion 若直接重用原 Tool Result Channel，可能被當成第二次同步回傳。

Production Harness 可以拆成多個 Event-driven Service，不必真的塞進一個 while True。不能丟的是 Protocol Order、Authority、Correlation 與 State Transition。

十個反模式，背後其實是十種責任逃逸

反模式不是因為某個技術看起來老派，而是它把應被系統承擔的責任藏起來了。

反模式	表面做法	被藏起來的責任
Prompt-only Control	把權限、Budget、Retry 都寫進 Prompt	Runtime Enforcement
Model Self-certification	模型說完成就標記成功	Independent Verification
Blind Retry	所有 Error 都重試	Error Classification、Idempotency、Reconciliation
Hidden Control Flow	大量 Hook 與 Callback 沒有順序文件	Traceability 與 Authority
Tool Equals Function	有函式就算 Tool	Schema、Permission、Timeout、Receipt、Error Taxonomy
Split-brain State	Planner、Tool Layer、Verifier 各自存狀態	Canonical State Authority
Final-answer-only Eval	只看最後文字	Trajectory、Side Effect、Safety 與 Cost
Separate Fake Eval Pipeline	Eval 使用另一條簡化流程	Production Parity
Context Dumping	全歷史、文件與 Tool Result 全塞入	Selection、Budget 與 Freshness
Framework-first	先選平台再找問題	Workload、Failure Mode 與 Completion Contract

其中最危險的不是某個元件做錯，而是團隊逐漸習慣「反正另一層會處理」。

Planner 假設 Tool Layer 會補 Validation；Tool Layer 假設 Policy 已在上游跑過；Verifier 假設 Transcript 就是 Canonical State。最後每一層都有一部分真相，沒有任何一層持有完整責任。

Pattern Catalog 是解法語彙，不是固定框架

這個系列介紹過許多 Pattern：

Deterministic-first Orchestration
Fresh-context Iteration Loop
Workspace Isolation
Task Portfolio Delegation
Review Feedback Promotion
Artifact Pipeline
Entropy Management
Build-to-delete

Pattern 的價值，是替重複問題提供一組可討論、可組合的解法語彙。

它不代表每套 Harness 都要把所有 Pattern 裝滿。

每個 Pattern 應有一份 Qualification Record：

pattern: fresh-context-iteration
problem: quality degrades across long sessions
applicability:
  - task can checkpoint safely
  - startup reconstruction is reliable
counterconditions:
  - low-latency conversational task
required_authority:
  - canonical progress state
required_evidence:
  - fresh-session reconstruction test
known_costs:
  - startup latency
status: conditional
owner: agent-platform
review_by: 2026-10-01

選擇 Pattern 時，至少要回答：

它對應哪個 Failure Mode 或 Protected Invariant？
它需要哪個 State 與 Authority？
它增加什麼 Runtime、Security 與 Operational Cost？
哪個 Evidence 能證明它有效？
有哪些 Countercondition 或 Interaction Effect？
何時重新測試、降級或刪除？

Pattern 的狀態可以是：

candidate
trial
adopted
conditional
deprecated
retired

若一個模式只在特定 Model、Repository 或 Workload 有效，就應標示為 conditional，而不是包裝成新的工程定律。Pattern Catalog 是治理中的活文件，不是架構購物清單。

Harness 不只適用於程式碼

只要一項工作可以定義 Input、Constraint、Intermediate Artifact、Evidence 與 Acceptance，Harness 就能用在非程式碼產物。

一條 Domain-agnostic Artifact Pipeline 可以是：

Analyse
→ Build task-specific instructions
→ Draft
→ Critique
→ Revise
→ Validate
→ Publish

它可以用於：

研究報告
翻譯與本地化
財務文件
資料清理
法規比對
技術文章
圖片或簡報製作

關鍵不是多跑幾次模型，而是把每個階段的 Artifact 與 Authority 分開。

例如 Critique 階段只診斷問題，Revision 才負責修改；Validate 依靠獨立規則、來源或 Reviewer 判斷，而不是讓 Draft Agent 自己替自己蓋章。

大型 Artifact 可以分塊並行，但所有 Worker 必須共享：

Glossary
Style Contract
Source Snapshot
Global Outline
Cross-chunk Reference Rules

局部段落全部通過，不代表整份文件沒有重複、矛盾或論點漂移。合併後仍需要 Global Validation。

Capability-tiered Coordination 要按風險與可驗證性切，不是按價格切

一個 Workload 可能同時包含少量高判斷工作，以及大量機械性閱讀、分類、轉換與查詢。

這時可以讓較強的 Coordinator 負責：

Task Decomposition
Ambiguity Resolution
Cross-worker Conflict
Coverage Review
Final Synthesis

較便宜或較快的 Worker 負責：

受限 Retrieval
格式轉換
分類
結構化抽取
已有 Rubric 的局部檢查

但「強模型規劃、便宜模型執行」不是普遍省錢公式。

Routing 至少要同時考慮：

Task Difficulty
Failure Blast Radius
Worker Capability Evidence
Verifier Coverage
Escalation Cost
Data／Tool Permission
Latency Objective
Total Cost，而不是 Token 單價

以下情況不適合分層：

子任務高度耦合
Worker 錯誤很難被 Coordinator 或 Verifier 發現
每一步都需要高階判斷
協調與驗證成本高於節省
Failure Blast Radius 太大
Child Output 會被 Parent 不經驗證地當成可信指令

每個 Routing Rule 都應留下 Segment-level Outcome、Cost 與 Escalation Evidence。只按 Token 單價切割，常會把最難驗證的錯誤送進最便宜的路徑，再把節省的成本花在事故調查。

Build、Buy、Compose 是逐邊界決策，不是整套系統三選一

一套 Harness 很少需要全做、全買或全由開源元件拼裝。較實際的做法，是對每個 Boundary 分別判斷：

Canonical State
Agent Loop／Runtime
Sandbox
Tool／Protocol Integration
Approval／Policy
Evaluation
Observability
Operator UI
Scheduling／Queue
Knowledge／Artifact Store

Build

適合：

核心流程高度差異化
安全、資料與部署限制特殊
團隊需要掌握低層 Runtime
現有系統已擁有多數 Primitive
有長期維護、On-call 與 Upgrade 能力

成本不只在首次開發，也包括 Reliability、Observability、Protocol Compatibility、Migration、Incident 與人員流動。

Buy／Adopt

適合：

需要快速建立標準流程
Workload 接近產品預設
可接受供應商的 State Model 與 Control Plane
SLA、Data Governance、Export 與 Incident Process 符合要求

主要風險是：

Lock-in
Hidden State
Policy／Identity Mismatch
Data Residency
Pricing Change
Capability／Protocol Drift
Export 或 Migration 困難

Compose

選用少量邊界清楚的元件：

Issue Tracker
+ Task Runner
+ Coding Agent
+ Container Sandbox
+ Existing CI

可替換性通常較好，但 Integration Contract、State Handoff、Version Compatibility、Security Patch 與 Incident Ownership 由自己承擔。

Shared Responsibility 必須寫下來

每個 Boundary 至少記錄：

問題	需要答案
State authority	誰持有 Canonical State？
Security	誰負責 Identity、Credential、Patch 與 Incident？
Recovery	Crash、Timeout、Unknown Outcome 如何處理？
Evidence	哪些 Log、Receipt、Eval 與 Audit 可 Export？
Change	API／Schema／Price 改變時誰負責遷移？
Exit	如何停用、搬走或回滾？

工具選擇需要 Evidence Profile，不是單一 Ladder

Marketing、README、Demo、Test、PoC 與 Production Evidence 的確有不同可信度，但 Evidence 不是只有一條由低到高的樓梯。

一個候選至少應從五個維度評估：

Source authority：官方規格、Repository、二手描述
Environment fidelity：Demo、Sandbox、代表性 Workload、Production
Failure coverage：Happy Path、Crash、Cancellation、Recovery、Security
Recency：版本、Commit、Review Date
Exitability：Export、Migration、Open Contract、Rollback

同一項工具可能有高品質官方文件，卻沒有你 Workload 的 Failure Evidence；也可能在單一 Production Case 表現良好，卻完全無法 Export。不要用一個 L5 把這些差異壓平。

Due Diligence 至少要檢查：

它位於 Coding Agent、Runtime、Task Runner、Orchestrator、Protocol 還是 Full Platform？
是否建立新的 Canonical State？
State、Permission、Cancellation、Retry、Observability 與 Export 如何處理？
Licence、Security Policy、Release、Migration 與 Bus Factor 如何？
Crash 後能否恢復？Cleanup 是否正確？
是否能演練 Kill Switch、Export 與 Provider Outage？
你的 Workload 中 Success、Human Intervention、Cost 與 Evidence Completeness 如何？

重大選型還應做 Exit Drill：匯出一個真實 Run、還原其 Artifact 與 Audit，並證明停用供應商後仍能理解已發生的工作。

Coding Agent、Orchestrator、MCP Server 與 Full Lifecycle Platform 不在同一層。把不同層產品放進一張總分排行榜，只會得到一個精確但無法採購的數字。

OpenAI App Server 將 Thread、Turn、Streaming、Approval 與 Client Integration 暴露為產品介面，正好說明 Productisation 的核心是穩定 Contract 與 Lifecycle，而不只是包一層 UI。[2]

採用不是單一路線，而是按 Task Class 選擇 Operating Mode

Harness adoption operating modes

Figure 12-2｜不同 Task Class 可以停在不同 Operating Mode；Promotion 與 Demotion 都需要 Evidence Gate，沒有必要把整個組織推向同一個「最高階段」。

導入 Agent 的成熟度，應由可驗證 Outcome、可控委派範圍與失敗恢復能力衡量，不是計算每天有多少 Agent 在背景運行。

以下七個 Stage 可以作為 Operating Mode：

Stage 0：Chat-only Exploration

用於問答、草稿與單點解釋。缺少 Repository Context、直接執行與外部驗證。

Stage 1：Agentic Reproduction

選擇自己已知道正確答案的任務，讓 Agent 在看不到人工解法的情況下重做。

這不是為了省時間，而是校準 Task Size、Context、Verification 與 Failure Pattern。Mitchell Hashimoto 的採用紀錄也先透過重做自己的工作建立判斷力，再逐步增加委派。[3]

Stage 2：Bounded Assistance

任務被切成清楚、可驗證的單元，並開始使用 Repository Tool、Test、Script 與 Completion Criteria。

Stage 3：Warm-start Delegation

在自然空檔啟動研究、Triage、受限實驗或非破壞性 Review，讓下一個工作時段有可用的起始 Artifact。

Stage 4：Confident Task Outsourcing

只把已有高成功率證據的 Task Class 交給背景 Agent。人類不再同步盯著每一步，而是在自然 Checkpoint 查看 Evidence。

Stage 5：Harness Improvement Loop

重複 Failure 會推動 Guide、Tool、Sensor、Executable Rule 與 Regression Eval 的更新。

Stage 6：Portfolio-level Orchestration

管理可委派任務池、優先級、並行量、人類注意力與整合窗口。

Stage 是 Task-class 狀態，不是公司頭銜

同一團隊可以同時：

讓 API 文件維護停在 Stage 4
讓 Security Migration 停在 Stage 2
讓開放研究停在 Stage 3
讓低風險 Triage 進入 Stage 6

Promotion Gate 應至少要求：

Representative Outcome
Verification Coverage
Failure Containment
Human Attention Cost
Incident／Recovery Readiness
Owner
Rollback 或 Demotion Path

若 Model、Tool、Policy、Task Distribution 或 Risk 改變，Task Class 可以退回較受限 Mode。這不是倒退，而是風險重新對齊。

Anthropic 的 Managed Agents 工程文章直接提醒：Harness 內含對模型弱點的假設，模型升級後這些假設可能過時；舊 Harness 中原本有用的 Context Reset 也可能變成 Dead Weight。[4]

沒有高價值工作、Verification 不成熟或 Review Queue 已飽和時，讓 Agent 不運行也是成熟決策。

Pattern 產品化需要補齊 Capability，不必追求最高 Level

Harness productisation capability layers

Figure 12-3｜Files and Scripts、Structured Runtime、Operator Controls、Team Integration 與 Managed Platform 是可組合的 Capability Layers；每一層都需要明確使用者、責任與退出條件。

Progress File、Shell Script、Task JSON 與 Git Checkpoint 可以證明 Pattern 有效。它們還不等於團隊可穩定使用的產品。

Layer 1：Files and Scripts

Progress File
Init Script
Task JSON
Manual Resume
Git Checkpoint

適合單人與早期實驗。

Layer 2：Structured Runtime

Stable ID
Typed State
Event／Protocol Contract
Checkpoint
Background Work
Versioned Config

Layer 3：Operator Controls

Timeline
Pause／Resume／Cancel
Approval Queue
Failure Diagnosis
Cost／Quality／Attention Signal
Runbook Link

Layer 4：Team Integration

Issue／Project Integration
Role／Permission
Shared Review Queue
Audit／Retention
Branch／Workspace Lifecycle
Release Gate

Layer 5：Managed Platform

Multi-tenant Isolation
Scheduling／Queue
Autoscaling
Policy Administration
Upgrade／Migration
SLO／Incident Ownership
Billing／Quota

Layer 不是必經順序，也不是產品價值排名

一個內部 Tool 可能需要 Layer 2 的 Durable Runtime 與 Layer 4 的 Team Integration，卻不需要完整 Managed Platform。另一個高風險 Service 可能先需要 Layer 3 的 Operator Control，再擴充 Team Surface。

每一層都應回答：

誰是使用者？
哪個 Lifecycle 被產品化？
新增了哪個 State／Authority？
誰 On-call？
如何 Export／Migrate？
沒有這一層時，實際 Failure 是什麼？
何時不值得繼續升級？

Productisation 不是把 Script 包成漂亮 UI。OpenAI Codex App Server 將長生命週期 Thread、Turn、Streaming、Approval 與 Client Integration 提升為穩定介面；Anthropic Managed Agents 則將 Session、Harness 與 Sandbox 解耦，讓底層實作能替換。兩者都顯示，產品化的核心是 Lifecycle Contract 與替換邊界。[2][4]

Platform 還會創造新的治理債：Migration、Backwards Compatibility、Tenant Isolation、Operator Training 與 Incident Ownership。只有當重複使用、團隊協作或營運需求足以支付這些成本時，才值得往上增加 Layer。

Template 可以縮小解法空間，也可能凍結錯誤架構

企業常反覆建立幾類 Topology：

API Business Service
Event Processor
Batch Pipeline
Data Dashboard

每類 Topology 可以有版本化 Harness Template，提供：

Repository Structure
Architecture Guide
Executable Dependency Rule
Approved Toolchain
Bootstrap／Run／Test Workflow
Observability Contract
Security Baseline
Deployment Check
Evaluator Rubric

Template 的作用是縮小合法解法空間，讓 Guide 與 Sensor 能覆蓋更多變更，同時保留局部實作自由。MartinFowler.com 將 Harness 描述為結合 Feedforward Guide 與 Feedback Sensor 的調節系統；Template 可以把這些 Control 變成一套可重複使用的環境。[5]

但 Template 也會 Drift。

至少要管理：

Template Version
Generated 與 Owned File 的差異
Upgrade Path
Compatibility Test
Local Override Policy
回饋上游的 Contribution Flow

若 Domain 差異很大，或 Template 迫使團隊使用不自然的架構，Variety Reduction 就不再是幫助，而是把錯誤決策複製得更快。

把重複 Review 升級，但先把它當成 Hypothesis

Review feedback lifecycle

Figure 12-4｜Review Feedback 先形成可驗證 Hypothesis，再經代表性 Case、False-positive 與 Failure-injection 測試，才可能成為 Diagnostic、Executable Gate 或 Runtime Invariant；規則也可以被降級與退休。

一個問題若在 Code Review、Incident 或 Agent Run 中反覆出現，不應永遠依靠人類再提醒一次。

但「重複出現」不等於「已理解根因」。較安全的 Lifecycle 是：

Observation
→ Cluster repeated evidence
→ Form a control hypothesis
→ Provisional guidance or checklist
→ Build diagnostic and representative cases
→ Evaluate false positive, false negative and repairability
→ Promote to executable gate when justified
→ Monitor, demote or retire

OpenAI 的 Harness Engineering 案例描述了類似方向：反覆出現的 Review Feedback 與不一致會被提升成 Repository Knowledge、Tooling、Mechanical Check 與 Cleanup Process。[6]

Google Conductor 的 Automated Reviews 也將 Spec／Plan Compliance、Test Suite、Guideline 與 Basic Security Check 放進 Post-implementation Verify Step，說明 Feedback 可以被產品化成可重跑 Evidence，而不只停在 Review Comment。[7]

適合 Promotion 的問題通常具備：

重複且有代表性
邊界清楚
Violation Cost 高
Sensor 能看見 Failure
False Positive／Negative 可量測
能提供 Agent-actionable Diagnostic
有 Owner 與 Rollback

不適合直接機械化的包括：

依情境變化的設計品味
一次性例外
尚未理解根因的 Incident
需要跨領域取捨的判斷
無法區分好壞案例的模糊偏好

每個 Promoted Rule 應記錄：

Source Incident／Review
Protected Invariant
Applicability／Exclusion
Severity
Diagnostic
Test／Eval
Owner
Version
Expiry／Review Trigger
Demotion／Removal Path

Promotion 不是單向升級。一條 Gate 若 False Positive 過高，可以降回 Diagnostic 或 Checklist；底層能力改進後，也可以退休。否則 Harness Improvement Loop 會長成規則堆肥場。

Harness Entropy 會從成功中長出來

一套 Harness 開始產生更多 Output 後，Entropy 通常不是突然爆炸，而是慢慢累積：

重複 Prompt 與互相衝突的 Instruction
過期 Tool Schema
無 Owner 的 Memory
Dead Config 與 Feature Flag
Progress Ledger 與實際 Repository 不一致
文件引用已不存在的 Code
重複 Hook
Eval 仍測試舊行為
Platform 已提供能力，但本地 Wrapper 還在
同一 Invariant 被三個元件各自維護
Deprecated Component 沒有 Consumer Inventory

OpenAI 的 Agent-first Repository 經驗也提到，Agent 會複製既有 Pattern，包含不一致與不理想的 Pattern，因此需要 Golden Principle、Mechanical Check 與持續 Cleanup。[6]

Entropy 需要 Inventory 與 Dependency Graph

至少要能查詢：

Component／Rule／Knowledge Artifact
Owner
Protected Invariant
Upstream／Downstream Dependency
Active Consumer
Last Used
Last Verified
Cost
Replacement Candidate
Deprecation Status
Retirement Blocker

沒有 Consumer Inventory，刪除看起來沒人使用的 Hook，可能直到月底批次工作才爆炸。沒有 Invariant Map，合併兩個 Rule 也可能把其中一條安全邊界一起磨掉。

Cleanup 使用 deterministic sensor 優先

Broken Link 與 Freshness Check
Duplicate／Dead-code Analysis
Schema Compatibility Test
Architecture Fitness Function
Unused Tool Telemetry
State-to-Repository Reconciliation
Dependency 與 Security Scanner
Feature-flag Age
Unowned Artifact／Rule Report

LLM 可以提出疑似問題、Cluster 與 Repair Candidate，但刪除 Tool、Rule、Memory、Policy 或 Artifact 前仍需要 Evidence、Dependency Check 與 Authority。

為維護複雜度建立 Budget

可以追蹤：

Active Control Count
Controls without Owner
Rules past Review Date
Duplicate Authority
Deprecated-but-active Component
Mean Time to Explain a Run
Upgrade／Migration Work
False-positive Review Cost
Telemetry／Storage Overhead

這些不是成熟度分數，而是 Triage Signal。單純把 Component Count 壓低也可能造成反向災難，因為五個清楚元件未必比一個巨型「萬能 Controller」更難維護。

真正要降低的是無法解釋、責任重疊、沒有 Evidence 與無法退休的複雜度。

Operational Knowledge 也需要生命週期與 Authority

當 Repository 文件、Spec、Skill、Runbook 與 Eval Case 成為 Agent 的 Operational Knowledge，它們需要和 Code 一樣的治理。

每份 Knowledge Artifact 至少應記錄：

Owner
Status
Last Verified
Canonical Source／Source Authority
Related Code／Schema／Policy
Supersedes／Superseded By
Review Cadence
Generated 或 Hand-authored
Consumer／Retrieval Surface
Retention／Archive Rule

一條 Doc Gardening Loop 可以是：

Scan
→ Classify stale, orphan, duplicate or conflicting knowledge
→ Open a bounded repair
→ Verify against code or authority
→ Update indexes and links
→ Archive, supersede or delete safely

Google Conductor 將 Project Context 從短暫 Chat Log 移到 Version-controlled Markdown Spec／Plan，後續 Automated Reviews 再用這些 Artifact 驗證實作。這說明 Operational Knowledge 的價值來自可版本化、可引用、可驗證，而不只是「文件很多」。[7]

Knowledge Score 只能作 Triage，不能取代個別 Finding。一個 92 分的知識庫，仍可能包含一份會讓 Agent 使用錯誤 Production Credential 的過期 Runbook。

Core、Reference、Watchlist 與 Expired 要分流

所有新資訊都進核心庫，只會讓檢索品質與維護能力一起下降。

可以採用：

Core Knowledge：通用、高訊號、有可靠來源，且能持續維護
Reference／Source-only：有查閱價值，但產品或版本依賴較重
Watchlist：新興、爭議或待實測
Rejected／Expired：過時、重複、錯誤或維護成本高於價值

Agent 可以抓取、摘要、去重與提出 Tier 建議。是否進 Core 是治理決策，需要 Human Admission Gate。

Archive 與 Delete 也要分開：

仍被 Historical Run、Audit 或 Citation 引用的內容，應保留 Immutable Archive 或 Tombstone。
已無 Consumer、無 Legal／Audit Requirement，且 Supersession 完整的內容，才適合刪除。
Retrieval Index 與 Cache 必須在 Status 變更後一起失效。

每新增一項知識，都要問：

它增加的檢索與決策價值，是否高於它增加的維護熵？

生態雷達是決策隊列，不是熱門工具排行榜

Agent Harness 生態變動很快。將每個新 Repository、產品功能與市場數字寫進 Stable Theory Core，會讓理論篇很快變成考古現場。

可以建立四個 Ring：

Adopt：已在自己的環境驗證，符合安全與品質門檻
Trial：正在受控 PoC，有 Hypothesis、Owner 與退出條件
Assess：值得研究，但尚未投入實測
Hold：過時、重疊、風險過高、缺乏維護或不適用

Ring 是組織的採用決策，不是工具的全球評分。同一個產品可以在 A 團隊是 Adopt，在 B 團隊因 Data Residency 而是 Hold。

每個候選至少記錄：

name: example-runner
category
name: example-runner
category: task-runner
primary_use_case: issue-to-isolated-run
source_snapshot: 2026-07-08
licence: verify-from-primary-source
deployment_model: self-hosted
provider_dependency: none
state_authority: external-database
evidence_profile:
  source: official-repository
  environment: executable-example
  failure_coverage: incomplete
  recency: current
  exitability: untested
ring: assess
owner: platform-team
known_risks:
  - incomplete cancellation semantics
  - no verified export path
next_review: 2026-08-15

這份記錄能說明研究狀態，不能證明工具可靠，也不能自動把它提升到 Trial 或 Adopt。

Promotion Path 應包含：

Discovery
→ Primary-source review
→ Architecture classification
→ Sandbox trial
→ Failure injection
→ Security and data review
→ Measured comparison
→ Exit drill
→ Adopt

GitHub Stars、社群熱度、Awesome List 與精美 Demo 只能幫助安排 Assess 優先級。它們不是 Production Evidence。Awesome List 應保存 Snapshot Commit 與 Review Date，個別工具仍需回到 Primary Source 驗證。[8]

Landscape Snapshot 必須標記日期與 Review-by Date；Coding Agent、Runtime、Orchestrator、Task Runner、Platform、Protocol 也要分層比較。產品改名、被收購、停止維護或被模型原生能力吸收時，候選要能降級、替換與退休。

Ecosystem Radar 的價值，不是讓團隊追上每個新名詞，而是讓「我們為什麼還沒採用它」也有一個可辯護的答案。

每個元件都要有 Assumption Ledger

Harness 元件不是自然法則。每一個元件都隱含一項判斷：

沒有這個元件，模型、工具或環境會以某種方式失敗。

因此每個重要元件都應留下 Assumption Ledger：

component: secondary-review-agent
version: reviewer-7
protected_invariant: cross-module regressions require independent evidence
assumption: primary agent and deterministic suite miss a material class of regressions
failure_addressed: unverified integration changes
dependencies:
  - integration-test-suite@12
  - completion-contract@5
baseline: primary-agent-plus-deterministic-suite
evidence:
  - eval-run-2026-07-08
segments:
  - high-risk-invoice
  - ordinary-invoice
cost:
  latency: high
  tokens: high
  operations: medium
risk_floor:
  security_non_inferiority: required
ablation:
  method: shadow-disable-reviewer
  primary_variable: reviewer
  success_margin: no material loss on blocking criteria
decision: conditional
owner: quality-platform
last_tested_model: model-profile-v7
next_review_trigger:
  - model upgrade
  - verifier coverage increase
  - task distribution change
retirement_condition: equivalent evidence with lower cost

一份可用的 Ledger 至少回答：

元件保護哪個 Invariant？
假設哪個弱點仍存在？
依賴哪些其他元件？
Baseline 與代表性 Segment 是什麼？
哪個 Evidence 支撐它？
成本與 Failure Surface 是什麼？
哪些 Safety／Quality Floor 不能下降？
誰能改變 Decision？
何時重測、降級或退休？

decision: retain 不是永久居民證。它只代表在某個 Model、Task Distribution、Verifier 與成本條件下，Evidence 仍支持保留。

重新測試的 Trigger 可以包括：

Model Upgrade
Tool／Runtime Improvement
Context Window 或 Context Strategy 改變
Codebase Architecture 改善
Task Distribution／Risk Mix 改變
Cost／Latency Pressure
Evaluator Calibration 改變
Native Capability Replacement
Incident 或 Near Miss

Anthropic 在 2026 年的 Managed Agents 工程文章以一個具體例子說明這件事：較舊模型需要的 Context Reset，在較新模型上可能變成 Dead Weight。這不是「Harness 無用」，而是 Assumption Ledger 應該被重新打開。[4]

Build-to-delete：刪除機制，但保留它保護的 Invariant

Harness ablation and retirement lifecycle

Figure 12-5｜元件從 Assumption、Baseline、Experiment 與 Segmented Evidence 走向 Retain、Simplify、Condition、Replace 或 Retire；退休前必須遷移 Consumer，並證明 Protected Invariant 仍成立。

設計一個 Harness Component 時，就應準備：

Feature Flag／Shadow Mode
Stable Interface 或替代介面
獨立 Metric 與 Evidence
清楚 Owner
Dependency／Consumer Inventory
Rollback Path
可執行 Ablation Experiment
Deprecation／Migration／Removal Plan

Ablation 不是隨手關掉一個 Flag

基本流程是：

Define protected invariant and baseline
→ choose representative tasks and segments
→ disable, bypass or replace one primary mechanism
→ run shadow, paired, canary or isolated trials
→ compare quality, safety, cost and failure modes
→ inspect uncertainty and interaction effects
→ retain, simplify, condition, replace or deprecate
→ migrate consumers
→ verify invariant after removal

「一次只改一個主要變數」是理想預設，但現實中 Component 可能和 Prompt、Verifier、Tool 或 State Schema 互相作用。遇到 Interaction Effect 時，可以使用 Paired Trial、Factorial Experiment 或分階段 Migration；重點是不要同時改五件事，最後只剩一個無法解釋的綠色總分。

比較至少涵蓋：

Blocking Criterion／Task Success
Safety Violation 與 Hard Invariant
Segment-level Quality
Trajectory Efficiency
Latency／Critical Path
Token／Monetary Cost
Human Intervention
Maintenance Burden
Incident／Unknown Outcome Rate
Trial Validity 與 Uncertainty

Non-inferiority Floor 先於平均收益

一個 Reviewer 被移除後，平均 Pass Rate 只下降 0.2%，不代表可以刪除。若下降全部集中在高風險 Invoice，或 Cross-tenant／Financial Invariant 失去保護，平均值沒有決策權。

Ablation Decision 應分開：

Mandatory Safety／Quality Floor
Allowed Non-inferiority Margin
Segment
Confidence／Uncertainty
Operational Saving
Migration Cost

常見決策不只 Retain 或 Remove

Retain：仍是 Load-bearing Control。
Simplify：保留 Invariant，減少層級或成本。
Condition：只在特定 Risk／Task Segment 啟用。
Replace：由 Native Capability 或較清楚機制承接。
Deprecate：停止新增 Consumer，進入 Migration。
Retire：Consumer 已移除，Evidence 顯示 Invariant 仍成立。

高風險、合規與複雜系統可能需要更多控制。應被刪除的是沒有可量測價值、責任重疊或假設已失效的機制，不是 Permission、Tenant Boundary、Audit 或 Independent Verification 這類 Protected Invariant。

Native Capability 是替代候選，不是刪除命令

模型、Runtime 或 Platform 新增原生能力時，先做 Parity／Failure／Migration Test：

語意是否真的等價？
Authority 與 Audit 是否仍存在？
Failure／Cancellation／Recovery 是否完整？
舊資料與 State 能否讀取？
Provider Outage 時如何退回？
Cost 與 Lock-in 是否改變？

通過後，可以 Replace 本地機制。沒通過前，「平台現在也有這個功能」只是新的 Assumption。

Build-to-delete 的成熟，不在於刪了多少，而在於團隊能安全證明：即使機制離場，它保護的行為仍然成立。

一個完整演化案例

假設團隊要讓 Agent 處理內部 Invoice Review。

第一版：只想讓它工作

團隊加入：

一份長 System Prompt
Invoice Lookup Tool
Email Tool
一個 Reviewer Agent

很快出現問題：

Agent 偶爾把測試 Invoice 當正式 Invoice
Email 發出後 Timeout，系統重試並寄了兩次
Reviewer 只讀最終答案，沒看到 Tool Side Effect
規則愈加愈長

從 Failure 反推控制

團隊不再往 Prompt 繼續補句子，而是建立：

Tenant 與 Environment Scope
Idempotency Key 與 Email Receipt
Canonical Task State
Completion Contract
Tool Trajectory Verification
Approval Gate for external email

受限採用

先用已知答案的 Invoice 重做，接著只開放非破壞性 Review，再讓高信心 Task Class 進入背景執行。

Productisation

進度檔與 Script 逐步轉成：

Durable Run
Operator Timeline
Approval Queue
Failure Diagnosis
Team Role 與 Audit

Feedback Promotion

多次出現的「稅號格式錯誤」從 Review Note 升級成 Schema Validation。

需要依合約語意判斷的特殊條款則保留為 Human Review，不硬寫成規則。

Ablation

模型與 deterministic suite 改善後，團隊關閉 Secondary Reviewer 做受控比較。

若 Integration Error 沒有增加，成本與延遲下降，就簡化或刪除 Reviewer。若高風險 Invoice 的錯誤增加，則只在該 Risk Tier 保留。

這套 Harness 的成熟不在於最後有多少 Agent，而在於每個控制都有 Failure、Evidence、Owner 與退出條件。

成熟 Harness 的最後判斷

成熟 Harness 不一定是元件最多，也不一定是 Agent 自動運行時間最長的 Harness。

它通常具備以下特徵：

邊界與 Authority 清楚
Canonical State 單一
Failure 可分類、可恢復
重要行為有外部 Evidence
執行過程可關聯、可觀測
元件可替換
Knowledge 有 Owner 與 Freshness
Pattern 有 Applicability 與 Countercondition
假設能重新測試
重複 Feedback 能被提升，也能被降級
Consumer／Dependency 可查
不必要的機制能安全退休
Protected Invariant 不會因簡化而消失

前十一篇處理的是 Harness 如何提供 Context、Capability、Runtime、Reliability、Safety、Quality 與 Observability。

最後一篇要留下的判斷是：

Harness 是一套持續校準的控制系統，不是一組只進不出的元件收藏。

當團隊能說清楚每個元件為什麼存在、由誰負責、如何證明有效、依賴誰，以及何時應該被簡化、替換或退休，Harness 才從 Scaffold 變成可維護的工程能力。

更精確地說，成熟的目標是 Minimum Sufficient Harness：

足以保護必要 Invariant
足以讓 Agent 完成代表性工作
足以在失敗時恢復與調查
沒有多餘、重疊、無 Owner 的控制
能在 Model 與 Platform 演進後重新校準

理論轉實作：Part 12 檢查表

每個主要元件都有 Failure／Protected Invariant、Authority、Owner、Evidence 與 Retirement Condition。
Deterministic Control 固定安全、State、Budget 與 Pass Authority，模型只在需要語意判斷的區域獲得自由。
Build／Buy／Compose 逐 Boundary 決策，並完成 Shared-responsibility、Export、Outage 與 Exit Drill。
每個 Task Class 有自己的 Adoption Mode、Promotion／Demotion Gate 與 Human-attention Capacity。
Pattern、Template、Rule、Knowledge 與 Ecosystem Candidate 都有 Version、Status、Consumer、Review Date 與降級路徑。
重複 Feedback 先形成可測 Hypothesis，再依 False-positive／Negative 與 Repair Evidence 決定 Promotion。
高成本或重疊元件具備 Assumption Ledger、Segmented Baseline、Safety Floor、Ablation 與 Migration Plan。
刪除或替換完成後，團隊能重新驗證 Protected Invariant，而不是只看到成本下降。

這個系列到這裡完成了 Harness 的理論地圖。下一步進入實作時，應從一個受限 Workload、清楚 Failure Mode、Canonical State 與可執行 Completion Contract 開始，不必先蓋一座全能 Agent 城堡。

References

Anthropic, Building effective agents, 19 December 2024.
OpenAI, Unlocking the Codex harness: how we built the App Server, 4 February 2026.
Mitchell Hashimoto, My AI Adoption Journey, 5 February 2026. This is a first-person adoption account, used as one practical path rather than a universal maturity model.
Anthropic, Scaling Managed Agents: Decoupling the brain from the hands, 8 April 2026.
Birgitta Böckeler, MartinFowler.com, Harness engineering for coding agent users, 2 April 2026.
OpenAI, Harness engineering: leveraging Codex in an agent-first world, 11 February 2026.
Google Developers Blog, Conductor Update: Introducing Automated Reviews, 13 February 2026.
AutoJunjie, Awesome Agent Harness, repository snapshot reviewed 7 July 2026. Used only as an ecosystem discovery index; individual tools require primary-source verification.