如果你真的一路看到 Day 30，希望你現在得到的不是一張更長的 Agent 技術清單。

你開始有能力在面對一個新的 Agent 問題時，先問：「它到底失敗在哪裡？」然後自己找到答案。

30 天前，我們從一個很簡單的問題開始：

AI Agent 的架構到底在哪裡？

到了 Day 29 ，你已經知道：

先定義 Failure，再決定哪一層 Harness 值得存在。

Day 30 不會再介紹新的 Mechanism。

今天只回答一個問題：

如果明天要從零開始做一個 Agent，我到底應該怎麼決定 Architecture？

---

第一個錯誤：Production Agent = 複製一個完整 Harness

看完 Claude Code，很容易想：

我們也要：
Permission
Hooks
Subagents
Skills
MCP
Background Tasks
Memory
Graph

看完 Hermes，又想加：

Cron
Channels
Persistent Memory
Skill Evolution

看完 DeepSeek Harness，又想加：

Plugin Kernel
Event Log
Capability Seams
Composition

最後還沒解第一個 User Problem，架構就已經有 30 個 Component。

這是最危險的學習方式。

真正應該複製的不是 Feature。

而是：

每個系統如何把一個具體 Failure 映射到一個 Control Mechanism。

---

Agent Architecture 不是 Feature Checklist

可以用一個非常簡單的公式來想：

Architecture
=
Observed Failure
+
Control Mechanism
+
Verification
+
Budget

例如：

Failure:
Agent 重複呼叫同一個 API

Control:
Retry Budget + No-progress Detection

Verification:
同類錯誤不得超過 3 次

Budget:
Max retries = 3

這就是一個完整的 Architecture Decision。

不是：

我們需要 Error Recovery，因為成熟 Agent 都有。

---

先回到最小 Agent

如果今天完全重新開始，我不會先用 Graph Framework。

也不會先做 Multi-Agent。

第一版只需要：

messages[]
↓
Model
↓
Tool Call
↓
Tool Runtime
↓
Observation
↓
Model

再加兩個最基本的 Harness Boundary：

Turn Budget
Tool Execution Boundary

這就是最小可觀察 Agent。

然後開始跑真實 Task。

---

第一步：先讓 Failure 出現

很多人怕 Agent Fail。

但對 Architecture Design 來說：

Failure 是最有價值的資料。

因為只有看到它真的怎麼失敗，才知道下一個 Mechanism 應該加在哪裡。

例如你看到：

Agent 常常傳錯 Tool Argument

這時才加：

Schema Validation
Structured Error
Repair Loop

如果你看到：

Agent 會執行不該執行的 Side Effect

再加：

Permission
Approval
Sandbox

如果你看到：

Agent 在長 Task 中忘記最初 Constraint

再考慮：

Context Selection
Pinned State
Compaction

架構應該是被 Failure 拉出來。

不是被 Framework 推進去。

---

一張 Failure → Harness 對照表

可以把前 29 天壓成這張表。

你看到的 Failure	優先考慮的 Harness
Agent 只能回答一次，不能持續做事	Agent Loop
Tool Call 有格式，但真正執行很混亂	Tool Runtime
Agent 做了不該做的事	Permission / Approval
即使批准後，Blast Radius 太大	Sandbox
每次都要改主 Loop 才能加規則	Hooks
長任務常漏 Step	Planning
Context 被不同子問題互相污染	Subagent
大量任務知識永久塞 Prompt	Skills
Context 越跑越大	Context Management
跨 Session 忘記重要資訊	Memory
Prompt 規則、Tool、State 經常不一致	Prompt Assembly
Tool / API 失敗只會重試	Error Recovery
任務需要 Pause / Resume	Task System
任務不能綁在 HTTP Request	Background Execution
任務需要未來執行	Scheduling
多個 Coding Task 互相踩 Workspace	Worktree Isolation
多 Agent 結果無法整合	Coordination
Agent 之間傳訊息很模糊	Protocol
Agent 自主執行沒有清楚邊界	Autonomy Policy
外部 Capability 越接越亂	MCP / Plugin / Channel Layer
Production 出錯但無法重建原因	Observability
不知道新版本是否真的更好	Evaluation
人類還在每輪手動 Push Agent	Loop Engineering
已知流程仍每次問 Model	Graph Engineering
架構一直變複雜但不知道值不值得	Eval-first

這張表比任何 Agent Framework Logo 都更重要。

---

第二步：先問「這個決策需要 Judgment 嗎？」

這是整個系列最值得帶走的問題之一。

每次要把某件事交給 Model 前，先問：

這件事真的需要 Judgment 嗎？

例如：

檔案存在嗎？

不需要。

用 Code。

Production Deploy 前有沒有 Approval？

不需要。

用 Policy / State。

Review Fail 後要不要回去修改？

如果流程固定，也不需要。

用 Graph Edge。

但：

這個 Bug 的 Root Cause 是什麼？

需要理解 Evidence。

交給 Model。

這三個互相衝突的來源哪個比較可信？

需要 Judgment。

交給 Model。

一句話：

把 Model Token 花在不確定性，不要花在你已經知道答案的控制流程。

---

第三步：把 Deterministic 和 Probabilistic 分開

一個成熟 Agent 最重要的架構邊界，可以畫成：

Probabilistic Layer
Model
- reasoning
- semantic judgment
- planning
- tool choice
- synthesis

Deterministic Layer
Harness
- permission
- budget
- state transition
- schema
- routing
- timeout
- retry ceiling
- approval
- verification

不是說 Harness 裡不能有 Model。

而是：

能用 Deterministic Rule 表示的 Safety / Control，不要只留在 Prompt。

---

第四步：所有 Mechanism 都要有 Budget

前 30 天幾乎每一層最後都遇到同一個問題：

如果沒有 Ceiling，能力會變成 Runaway Behavior。

例如：

• Agent Loop: Turn Budget
• Retry: Retry Budget
• Planning: Planning Budget
• Subagent: Child Count / Token Budget
• Context: Working Context Budget
• Memory: Recall Top-K
• Background: Worker / Concurrency Limit
• Scheduling: Frequency / Recurrence Limit
• Autonomy: Cost / Time / Action Budget
• Graph: Step Budget

所以可以再抽象一層：

Agent Architecture 很多時候就是 Capability + Budget。

沒有 Budget 的 Capability，Production 上幾乎一定會出現不可控成本。

---

第五步：每個 Side Effect 都要有 Evidence

Agent 會產生兩種東西。

第一種是：

Language

例如：

我已經完成修改。

第二種是：

Evidence

例如：

git diff
test result
database state
created artifact
API response
approval record

可靠 Agent 應該盡量讓完成條件落在第二種。

也就是：

不要問 Agent 覺得自己有沒有完成，問環境是否留下完成的證據。

Coding Agent 可以看：

• Diff
• Tests
• Build

Workflow Agent 可以看：

• Database
• Artifact
• External State

Research Agent 可以看：

• Sources
• Citations
• Required Evidence

這就是 Verification。

---

第六步：Context 不要當 Database

Day 8、9、10、11 其實在講同一件事。

很多 Agent Failure 都來自把 Context 當成：

所有狀態唯一存在的地方。

結果：

• Context 滿了
• Summary 壓錯
• Constraint 消失
• Memory 和 Task State 混在一起

比較健康的架構是：

Durable State
├── Task
├── Memory
├── Artifact
├── Session Log
└── External Storage

        ↓ Selection

Working Context
        ↓
Model

Context 是 View。

不是 Database。

DeepSeek Harness 把這個思想推得最徹底：

Session Log 是 durable truth，model-visible messages 是 derived view。

即使你不做 Plugin Kernel，這個 Mental Model 也非常值得保留。

---

第七步：Multi-Agent 是最後才考慮，不是第一步

Multi-Agent 很容易變成 Architecture 的捷徑：

Task 很複雜，所以多加幾個 Agent。

但 Day 7 和 Day 17 已經看到：

多 Agent 同時引入：

• Context Duplication
• Coordination Cost
• Result Merge
• Permission Duplication
• Verification Cost
• Shared State

所以先問：

可以用 Tool 解嗎？
可以 Parent 自己做嗎？
可以 Skill 解嗎？
可以 Graph 解嗎？

只有當問題真的有：

• Context Boundary
• Responsibility Boundary
• Independent Work
• Parallel Opportunity

才值得建立 Subagent。

最重要的原則仍然是：

先切責任，再增加 Agent 數量。

---

第八步：Graph 也不是最終答案

看到 Graph Engineering 後，也很容易走到另一個極端：

所有 Workflow 都畫成 Graph。

但 Open-ended Problem 很難預先知道路徑。

例如：

• Debugging
• Research
• Novel Design
• Root Cause Investigation

硬寫 Graph 反而會讓 Model 失去探索空間。

所以：

Known Structure
→ Graph

Unknown Path
→ Agent / Planning

Hybrid 才是 Production 最常見答案：

Graph
├── Code Node
├── Model Node
├── Agent Node
├── Approval Node
└── Verification Node

Graph 管 Control。

Agent 管 Judgment。

---

第九步：Observability 要早於 Autonomy

很多團隊的順序是：

先讓 Agent 自動做更多
↓
出事
↓
再補 Logging

應該反過來：

Observe
↓
Understand Failure
↓
Add Guardrail
↓
Increase Autonomy

如果你連下面問題都回答不了：

• 它剛才呼叫什麼 Tool？
• 為什麼 Retry？
• 花多少 Cost？
• 哪個 Step Fail？
• 哪個 Permission 被拒絕？

就不應該急著提高 Autonomy。

一句話：

看不見的 Agent，不應該被給更多權力。

---

第十步：Eval 要早於 Architecture Promotion

同樣的邏輯也適用於功能 Promotion。

不要：

加 Memory
↓
感覺比較聰明
↓
上線

而是：

Memory-related Failure Dataset
↓
Baseline
↓
Add Memory
↓
Eval
↓
Quality / Cost / Latency
↓
Keep or Remove

Day 29 的 Eval-first 最後其實在替整個系列提供一個刪除機制。

因為如果沒有 Eval：

Harness 只會一直增加。

有 Eval 才能問：

這層真的有用嗎？

---

四個真實 Harness 給我們的四個答案

Day 25 到 Day 28，我們看了四個很不一樣的系統。

---

Claude Code

它回答：

當 Model 可以真的修改複雜 Repository，怎麼控制它？

核心：

Permission
Tools
Hooks
Context
Subagents
MCP
Verification

適合學：

Complex Environment Control。

---

Hermes Agent

它回答：

Agent 要跨時間存在，怎麼管理 State 和 Trigger？

核心：

Memory
Skills
Channels
Cron
Background Events
Identity

適合學：

Long Time Horizon。

---

mini-swe-agent

它回答：

如果 Model 已經夠強，最少 Harness 可以剩多少？

核心：

Loop
Bash
Environment
Budget
Submission
Eval

適合學：

Minimal Baseline。

---

DeepSeek Harness

它回答：

Harness 變大後，怎麼讓每個部分仍然可以組裝與替換？

核心：

Plugin Kernel
Reversible Registration
Session Log
Projection
Capability Seams
Composition

適合學：

Runtime Composition。

---

四個系統不是四個答案，而是四種壓力

可以把它們畫成：

Environment Complexity
→ Claude Code

Time Horizon
→ Hermes

Minimality / Research
→ mini-swe-agent

Composition Complexity
→ DeepSeek Harness

所以你不應該問：

哪個 Agent Architecture 最好？

而應該問：

我的系統正在承受哪一種壓力？

Architecture 是壓力的回應。

---

一個從零開始的 Agent Architecture Workflow

如果明天要做新的 Agent，我會這樣開始。

---

Phase 0：先定義 Task

先回答：

User 是誰？
Task 是什麼？
Environment 是什麼？
Side Effect 是什麼？
Completion Evidence 是什麼？

如果連這些都不清楚，不要先選 Framework。

---

Phase 1：最小 Loop

只做：

Model
+
Tools
+
Observation
+
Budget

讓它跑真實 Task。

---

Phase 2：收 Failure

不要先補 Architecture。

先分類：

Tool Failure?
Context Failure?
Authority Failure?
Completion Failure?
Planning Failure?
State Failure?
Coordination Failure?

---

Phase 3：建立 Eval

每個高 Severity Failure 都有 Case。

建立 Baseline。

---

Phase 4：只加一個 Mechanism

例如：

False Completion
→ Verification

然後重跑 Eval。

---

Phase 5：加 Control，不要先加 Intelligence

優先看：

Permission
Budget
Verification
State
Observability

這些 Mechanism 常常比：

更多 Agent
更長 Prompt
更多 Planning

更有 Production 價值。

---

Phase 6：Task Horizon 變長才加 Persistence

只有當 Task 開始跨：

• Turn
• Session
• Process
• Hour
• Day

才逐步加入：

Context Management
Task System
Memory
Background
Scheduling

不要第一天就做 Always-on Infrastructure。

---

Phase 7：真的有 Boundary 才加 Subagent

先證明：

Context Isolation
Responsibility Isolation
Parallelism

真的需要。

---

Phase 8：固定流程出現才加 Graph

只把：

已知且必須遵守的 Control Flow

寫進 Code。

---

Phase 9：Autonomy 逐步 Promotion

L1 Report
↓
L2 Assisted
↓
L3 Unattended

每升一級，都需要：

• Eval
• Observability
• Permission
• Rollback

---

Phase 10：定期做 Ablation

最後最容易忘記的一步：

刪東西。

Model 變強。

Product 改變。

Failure Mode 消失。

舊 Harness 可能已經沒有價值。

所以定期測：

Without Planner?
Without Memory?
Without Subagent?
Without extra Judge?

如果表現沒變：

Remove it.

---

一張真正實用的 Architecture Decision Tree

可以把整個系列壓成這個 Decision Tree：

Agent 需要多輪做事嗎？
├── No → 普通 LLM / Workflow 可能就夠
└── Yes
     ↓
需要碰外部環境嗎？
├── No → Simple Loop
└── Yes → Tool Runtime

Tool 有 Side Effect 嗎？
├── No
└── Yes → Permission / Approval / Sandbox

Task 會超過單一 Context 嗎？
├── No
└── Yes → Context Management

資訊需要跨 Session 嗎？
├── No
└── Yes → Memory

Task 需要 Pause / Resume 嗎？
├── No
└── Yes → Task System

Task 需要離線執行嗎？
├── No
└── Yes → Background / Scheduling

問題能在一個 Context 裡處理嗎？
├── Yes → 不要加 Subagent
└── No → Subagent Boundary

流程下一步已經知道嗎？
├── Yes → Code / Graph
└── No → Model / Planning

完成是否可外部驗證？
├── Yes → Deterministic Verification
└── No → Rubric / Judge

準備提高 Autonomy？
├── 看不到 Trace → 先做 Observability
├── 沒有 Eval → 先做 Evaluation
└── 都有 → 逐步 Promotion

這比選 LangGraph、AutoGen、CrewAI、某個 SDK 更接近真正的 Architecture Design。

---

什麼時候其實不需要 Agent？

這也是 Day 30 一定要回答的問題。

不是所有 LLM Application 都需要 Agent。

如果流程是：

Input
↓
固定三步
↓
Output

而且每一步都已知，可能普通 Workflow 就夠。

如果：

Model 不需要 Tool
不需要多輪
不需要 State

那可能只是一次 LLM Call。

如果：

所有下一步都能 deterministic 寫出

那可能 Graph / Workflow 比 Agent 更穩。

所以 Agent 不是成熟度的象徵。

它只是適合處理：

下一步需要根據新的 Observation 動態 Judgment 的問題。

---

什麼時候不需要 Multi-Agent？

同樣地：

如果：

一個 Context 足夠
沒有獨立責任
沒有真正 Parallel Work

不要加。

Multi-Agent 不是 Single Agent 的升級版。

它是一個新的 Coordination Problem。

---

什麼時候不需要 Memory？

如果 Task：

20 分鐘內結束
不需要跨 Session
所有必要資訊都能重新取得

不要加。

Memory 不是 Agent 的標配。

它是 Persistent Failure 的解法。

---

什麼時候不需要 Graph？

如果：

Root Cause 未知
路徑高度開放
探索順序不能預先決定

不要硬畫。

讓 Agent Reason。

---

什麼時候不需要更強 Model？

如果真正 Failure 是：

Permission 沒擋住
Tool Timeout
State 丟失
Duplicate Side Effect
No Verification

換 Model 不會修好。

這些是 Harness Problem。

這也是整個系列最核心的分類能力：

先分清楚這是 Model Failure，還是 Harness Failure。

---

30 天後，真正該留下的不是 30 個 Feature

如果你把這個系列看成：

30 天學 30 個 Agent 技術。

其實會錯過重點。

真正應該留下的是一套 Debug / Design Lens。

當 Agent Fail 時，先問：

Reasoning 錯？
Tool Runtime 錯？
Context 錯？
State 錯？
Permission 錯？
Recovery 錯？
Verification 錯？
Coordination 錯？
Control Flow 錯？
Eval 本身錯？

這比：

換 Prompt 試試看。

更接近 Engineering。

---

最後回到 Day 1

Day 1 我們說：

模型決定要做什麼；Harness 決定這個決定如何被執行、觀察與限制。

30 天後，可以把它補完整：

模型負責 Judgment。Harness 負責 Action、State、Limits、Recovery、Verification 和 Coordination。Eval 負責證明這些 Mechanism 是否值得存在。

這就是整個 Awesome Agent Architecture 的核心。

---

最後一個原則：Harness 不應該一直變大

Agent Architecture 最成熟的狀態，不是：

所有 Pattern 都有

而是：

每個 Mechanism
都有一個清楚 Failure Mode
都有一個可測量的 Benefit
都有一個 Budget
都有一個 Removal Condition

如果沒有：

刪。

所以最後一句，我想留給整個系列：

Build the smallest Harness that closes the failures you can prove.

不是最完整的 Harness。

不是最複雜的 Graph。

不是最多 Agent。

不是最長 Prompt。

而是：

最小、可觀察、可驗證，而且每一層都有存在理由的系統。

---

完整系列與程式碼範例收錄於 https://github.com/hardness1020/awesome-agent-architecture