前一天我們談 Agent Protocol。

現在 Agent 已經可以：

• 接 Task
• Background 執行
• Schedule
• Spawn Subagent
• 交換 Structured Message
• 使用 Tool
• Retry
• Replan

這時很多產品會開始追求：

更高 Autonomy。

例如：

不要一直問使用者，讓 Agent 自己做完。

這個方向沒有錯。

但最容易出現的錯誤等號是：

Autonomy 越高 = Agent 越強。

其實更高 Autonomy 同時代表：

• 更長執行時間
• 更多 Tool Calls
• 更多 Side Effects
• 更多成本
• 更多狀態漂移
• 更多需要 Recovery 的機會

所以 Autonomy 不是一個 Personality Setting。

它是一組 Control Budget。

Autonomy 應該拆成維度

不要只用：

low / medium / high

可以拆成：

• Time Autonomy: 可以自己執行多久？
• Action Autonomy: 哪些操作可以自動做？
• Scope Autonomy: 可以影響多少資源？
• Planning Autonomy: 可以自己修改多少計畫？
• Delegation Autonomy: 可以建立多少 Subagent？
• Spending Autonomy: 可以花多少 Token、API、金錢？
• Communication Autonomy: 可以直接對外發送訊息嗎？

這些維度可以分開控制。

Approval Boundary

Autonomy 最重要的問題之一是：

哪些行動需要人類重新進入 Loop？

例如：

讀檔
自動

跑測試
自動

修改 Source
自動

Deploy Staging
自動

Deploy Production
Approval

寄 External Email
Approval

這不是「Agent 是否自主」。

而是不同 Action 有不同 Approval Boundary。

Bounded Autonomy

Production Agent 更適合 Bounded Autonomy。

也就是：

在清楚邊界內高度自主。

例如：

Task:
修正 failing tests

Allowed:
read/write tests
run pytest
modify src/payments

Forbidden:
infra
production
email

Budget:
20 turns
30 tool calls

Approval:
required before deleting files

這種 Agent 可以很自主。

但自由是在 Harness 定義的邊界內。

Autonomy 需要 Exit Condition

如果只說：

自己做到完成。

Agent 可能一直：

• 搜尋
• Replan
• Retry
• 開 Subagent
• 再驗證

所以要有：

success condition
failure condition
budget exhaustion
no-progress condition
human escalation condition

沒有 Exit Condition 的 Autonomy 很容易變成 Endless Loop。

Confidence 不應該直接等於 Authority

模型說：

我有 95% 信心。

不代表它可以因此自動 Deploy。

Confidence 是模型判斷。

Authority 是系統政策。

兩者不能直接綁定。

可以用 Confidence 調整：

• 是否再驗證
• 是否需要第二個模型
• 是否 Ask User

但高風險操作仍應由 Policy 決定。

Autonomy Escalation

有些系統可以逐步增加自由。

例如：

Level 1
只讀

Level 2
可以修改 Sandbox

Level 3
可以建立 PR

Level 4
可以部署 Staging

Level 5
Production 仍需 Approval

這比一開始給所有權限更安全。

Autonomy 可以根據：

• Evaluation
• User Trust
• Task Type
• Environment
• Historical Reliability

逐步調整。

Autonomy Regression

如果 Agent 最近表現變差，也可以降低 Autonomy。

例如：

• Model 更新
• Tool 變更
• Error Rate 上升
• Policy 改變
• 新 Domain

不要只會增加自由，不會收回。

Human Handoff 是正常路徑

高 Autonomy 不代表永遠不要問人。

真正成熟的系統應該知道：

哪些決策不值得模型硬猜。

例如：

• 需求有兩種合理解讀
• 高風險操作
• 商業判斷
• 法規問題
• Side Effect 狀態不確定

Handoff 是 Autonomy Design 的一部分，不是失敗。

Autonomy 和 Budget

每個 Task 可以有：

turn_budget
tool_budget
token_budget
cost_budget
time_budget
subagent_budget

Autonomy 的實際範圍，就是這些 Budget 的交集。

如果 Agent 可以自由開 100 個 Subagent，那不叫高 Autonomy。

那叫沒有成本控制。

Autonomy Evaluation

要測的不只是 Success Rate。

還可以測：

• Success without intervention
• Human intervention rate
• Cost per autonomous success
• Unsafe action attempt
• Permission denial rate
• False completion
• Recovery count
• Time to handoff
• Unnecessary handoff

好的 Autonomy 不是人類介入越少越好。

而是：

人類只在真正需要時介入。

常見錯誤設計

1. Autonomy = Prompt「自己完成」

沒有 Budget 與 Policy。

2. 高 Confidence 自動給更多權限

混淆判斷與 Authority。

3. 所有 Task 同一個 Autonomy Level

風險完全不同。

4. 只增加不回收

可靠度下降仍保持高權限。

5. Human Handoff 視為失敗

Agent 只好硬猜。

6. 沒有 No-progress Stop

自主執行變成無限 Loop。

第一版 Autonomy Policy

可以用一張表：

再加：

• Turn Budget
• Tool Budget
• Cost Budget
• Max Subagents
• No-progress Threshold
• Handoff Conditions

這就是一個可操作的 Autonomy Model。

今天的結論

Autonomy 不是讓 Agent「自己決定更多」。

而是：

在可觀察、可撤銷、可限制的邊界內，減少不必要的人類介入。

最重要的原則：

自主性應該由 Budget、Permission、Approval 與 Verification 定義，不是由 Prompt 宣布。

下一篇會進入 MCP、Plugins 與 Channels：

Agent 能連更多外部系統後，真正需要設計的是 Capability Discovery、Trust Boundary 與 Connection Lifecycle。

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