把 agentic system 分成五層:我自己的 L1–L5 分法

先說清楚:L1–L5 這個分層是我自己編的,沒有任何一篇原文這樣編號。Anthropic 只把系統分成 workflow 和 agent 兩類,OpenAI 講 harness engineering,arXiv 那篇講設計維度。我把它們疊起來排成五層,是因為要選型的時候需要一把有刻度的尺 —— 「這個需求該做到多複雜」比「這算不算 agent」有用得多。

底下每一層的定義都是原文的,引號裡的話也是原文。刻度是我的,別把它當成誰的官方分類。

L2 和 L3 的分界線是整張表唯一重要的一條:有沒有 LLM 動態決定下一步。這條線以下,系統的行為是你寫死的,出錯可以 trace;這條線以上,行為是模型當下決定的,debug、成本、安全代價全部跟著跳。Anthropic 的原則是「用最簡單能解決問題的最低 level」,我同意,而且會講得更硬一點:如果你說不出來為什麼需要動態規劃,那就是不需要。

反過來,什麼情況下這條原則不適用:任務的步驟真的沒辦法預先列出來(探索型的除錯、開放式的研究),那 L2 再怎麼疊也只是把不確定性搬到別的地方。

L1 Augmented LLM

“The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory”(Anthropic)

單次 LLM 呼叫加上檢索、工具或記憶。沒有自主規劃,沒有多步執行。

# 示意,非可跑程式碼
response = llm.chat(
    messages=[{"role": "user", "content": question}],
    tools=[search_tool]
)

大部分「我們公司要做 AI」的需求做完之後就是這一層,而且夠用。RAG 問答系統全部落在這裡。

L2 Workflows

“Workflows are systems where LLMs and tools are orchestrated through predefined code paths”(Anthropic)

路徑是你寫死的。Anthropic 和 LangChain 各自整理出的五種模式基本重疊:

Orchestrator-Workers 是這五個裡唯一會越界的 —— 一旦 worker 的數量和內容是模型當下決定的,它實質上已經是 L3。

例子:行銷文案生成 → 翻譯、大綱檢查 → 文件撰寫、客服路由(一般問題 / 退款 / 技術支援)。

L3 Autonomous Agents

“Agents are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks”(Anthropic)

這層是分界線的另一邊,值得多講一點。Anthropic、OpenAI 和 arXiv 對它的描述大致一致:模型自己規劃、自己選工具,從環境拿回饋(Anthropic 的用詞是 “ground truth from environment”),多輪執行(“many turns”)直到滿足停止條件。

# 示意,非可跑程式碼
def agent_loop(task):
    while not is_complete():
        thought = llm.think(context)
        action = llm.select_tool(thought)
        result = execute(action)        # ← 環境回饋,這步是 L3 的全部意義
        context.append((action, result))
    return context.final_answer

result = execute(action) 那一行是整個 L3 的重點。L2 的迴圈是你決定跑幾次,L3 的迴圈是模型看到結果之後決定還要不要再跑。這也是為什麼 L3 的成本無法事先估算 —— 停止條件在模型手上。

兩個直接後果:

• 停止條件要自己設硬上限。 模型判斷「還沒完成」的傾向比人強,沒有 max turns 就會一直轉
• 環境回饋的品質決定 agent 的品質。 工具回傳一句 Error 和回傳完整 stack trace,同一個模型的表現差很遠。實務上優化 agent 多半是在優化工具的輸出,不是在改 prompt

例子:Claude Code(單一自主 agent + 檔案/terminal 工具)、SWE-bench 解題 agent、Computer Use、Cursor 的 IDE agent。

L4 Multi-Agent Systems

多個 L3 加上分工與通訊。arXiv 2604.18071 分析 70 個公開專案,把 “subagent architecture” 列為五個核心設計維度之一。

構成條件有四個,缺一個就不算(見文末誤區):角色分工、agent 間通訊、任務分配機制、狀態共享。

架構上 arXiv 歸出三種:Hierarchical(Manager → Workers)、Peer-to-Peer(互相協商)、Blackboard(共享工作區)。實務上絕大多數是第一種。

四種模式的細節、狀態管理差異和 token 成本,另外寫在這篇。

L5 Agent Harness

“Harness engineering is the discipline of designing the scaffolding (context delivery, tool interfaces, planning artifacts, verification loops, memory systems, and sandboxes) that surrounds an AI agent”(OpenAI)

L5 不是「更多 agent」,是 agent 外面那一圈。arXiv 2604.18071 的五個維度:subagent architecture、context management、tool systems、safety mechanisms、orchestration。

OpenAI、Anthropic 和 arXiv 對 harness 的共識大致是:control plane、會機械性強制執行的 policy gates(“mechanical enforcement”)、驗證迴圈、context 管理(OpenAI 強調 “repository knowledge”)、可觀測性與審計、權限系統。

OpenAI 那篇的幾句話值得單獨記:

• “Humans steer. Agents execute.”
• “No manually-written code”:所有程式碼由 agent 生成
• “Repository knowledge is the system of record”:知識庫存在 repo,不是放 Google Docs / Slack
• “Agent legibility is the goal”:優化目標是讓 agent 看得懂

最後那條是整份文件最有用的一句。它的意思是文件、命名、錯誤訊息的設計目標從「人看得懂」變成「agent 看得懂」,這兩者不總是同一件事。

例子:OpenAI Codex Harness(百萬行 agent 生成程式碼的生產系統)、SafeHarness(arXiv 2604.13630)、Microsoft Azure SRE Agent。

選型決策樹

你的需求是什麼?
│
├─ 簡單問答 / 資訊檢索? ── 是 ──→ L1: Augmented LLM
└─ 否
   │
   ├─ 步驟可以預先列出來? ── 是 ──→ L2: Workflows
   └─ 否
      │
      └─ 說得出為什麼需要動態規劃?
         │
         ├─ 說不出來 ──→ 回去做 L2
         └─ 說得出來
            │
            └─ 任務複雜到需要分工?
               │
               ├─ 否 ──→ L3: Autonomous Agents
               └─ 是 ── 需要生產級的可控與審計?
                        │
                        ├─ 否 ──→ L4: Multi-Agent Systems
                        └─ 是 ──→ L5: Agent Harness

常見誤區:這些都不是 L4

把 L4 的門檻拉這麼高不是要吵定義,而是這四個構成條件每一個都有維護成本。三個 prompt 互相呼叫就叫 multi-agent,代價是之後沒人分得出效能問題出在哪一層。

參考文獻