模組 2：多 Agent 5 / 6
中階
Session 11 Autonomous Auto-claim
自主代理
建構具有 WORK/IDLE 階段和自動認領能力的代理，實現獨立運作。
2026年3月20日 · 18 分鐘閱讀
你將學到什麼
大多數 AI 互動是對話式的：人類輸入、AI 回應、重複。自主代理打破了這個模式。它們在持續迴圈中運作 — 檢查工作、認領任務、執行、回報結果、再次檢查 — 全程無需人工介入。
完成後，你將了解：
- 什麼使代理成為自主的 vs. 互動式的
- WORK/IDLE 階段循環
- 自動認領：從共享佇列中選取任務
- 用於活躍性監控的心跳模式
- 讓自主代理保持受控的安全約束
問題是什麼
互動式代理有一個瓶頸：人類。每次代理完成後，它都等待下一個指令。
SCENARIO 1: Test Watcher
Developer changes code → tests need to run
But developer is writing more code → tests sit unexecuted
SCENARIO 2: Code Review Pipeline
3 PRs need review. Agent finishes PR #1, then stops.
PRs #2 and #3 wait for human to say "now do the next one"
SCENARIO 3: Multi-Feature Sprint
5 independent features. Sequential assignment wastes time:
Assign #1 → wait → done → assign #2 → wait → done → ...
Could be: define all 5 → agents work in parallel → all done核心問題：手動任務分配造成人為瓶頸。 如果任務定義明確且相互獨立，代理應該自動認領它們。
如何運作
互動式 vs. 自主
INTERACTIVE AUTONOMOUS
Human: "Fix the login bug" Agent: [check queue] → task found
Agent: [works] → "Done." Agent: [claim] → [work] → [report]
Human: "Now add error messages" Agent: [check queue] → task found
Agent: [works] → "Done." Agent: [claim] → [work] → [report]
Human: "Run the tests" Agent: [check queue] → empty
Agent: [works] → "All passing." Agent: [idle] → [wait] → [check]
↑ Stops after each task ↑ Loops until queue is emptyWORK/IDLE 階段循環
每個自主代理在兩個階段之間交替：
┌──────────────────────────────────┐
│ │
▼ │
┌───────────┐ no tasks available │
│ IDLE │◀──────────────────┐ │
└─────┬─────┘ │ │
│ check task queue │ │
▼ │ │
┌───────────┐ nothing found │ │
│ CHECK │──────────────────▶│ │
└─────┬─────┘ │
│ task found → claim it │
▼ │
┌───────────┐ │
│ WORK │ execute task │
└─────┬─────┘ │
│ complete → report result │
└──────────────────────────────────┘在 IDLE 狀態下，代理等待可設定的間隔後重新檢查。在 WORK 狀態下，代理對其認領的任務擁有完整權限 — 讀取檔案、撰寫程式碼、執行命令。
自動認領：從佇列到執行
自動認領是自主代理如何選取未指派任務的機制：
SHARED TASK QUEUE
┌─────────────────────────────────────────────┐
│ [task-1] status: done assignee: A │
│ [task-2] status: done assignee: B │
│ [task-3] status: ready assignee: — │ ◀── Agent C claims this
│ [task-4] status: ready assignee: — │
│ [task-5] status: blocked assignee: — │
└─────────────────────────────────────────────┘
RULES:
1. Only claim tasks with status "ready" (skip "blocked")
2. Claim ONE task at a time (prevents hoarding)
3. Set assignee atomically (prevents double-claim)
4. Respect priority order (higher priority first)心跳模式
當代理自主工作時，你如何知道它仍然活著？
Agent C (autonomous) Monitor
│ │
│ ♥ { agent: "C", task: "task-3", │
├───── status: "working" } ──▶ recorded: alive
│ ... 30 seconds ... │
│ ♥ { agent: "C", task: "task-3", │
├───── progress: "60%" } ──▶ recorded: alive
│ ... 30 seconds ... │
│ (no heartbeat) │
│ ──▶ 60s without heartbeat
│ │ → agent presumed dead
│ │ → unassign task-3
│ │ → task returns to queue心跳提供活躍性偵測（崩潰的代理會被回收任務）和進度追蹤（編排器可以監控完成度）。
守護模式
某些自主代理無限期運行，監控事件而非清空佇列：
DAEMON AGENT: Test Watcher
WATCH: file system changes
TRIGGER: *.ts file modified
ACTION: run related tests, report pass/fail
LOOP: forever (until explicit stop or session end)
EXIT: stop signal, session end, or 3 consecutive fatal errors安全約束
自主代理需要護欄。自主權是分級授予的，不是全有或全無：
┌─────────────────────────────────────────────────┐
│ 1. SCOPE LIMITS │
│ allowed_paths: ["src/", "tests/"] │
│ max_files_modified: 10 │
│ │
│ 2. APPROVAL GATES │
│ auto_approve: read, test, lint │
│ require_review: write, delete │
│ blocked: deploy, publish │
│ │
│ 3. KILL SWITCHES │
│ max_runtime: 300s per task │
│ max_iterations: 50 │
│ error_threshold: 3 consecutive failures │
│ │
│ 4. RESOURCE BUDGETS │
│ max_tokens_per_task: 100,000 │
│ max_tool_calls: 200 │
│ │
└─────────────────────────────────────────────────┘代理可以對安全操作（讀取、測試）完全自主，同時對破壞性操作（刪除檔案、部署）要求審批。
關鍵洞見
自主代理是 Claude Code 中類似 CI/CD 工作流程的構建模塊。它們彌合了互動式程式設計和自動化流水線之間的差距。
關鍵的思維轉變在於：互動式代理將人類視為排程器（「我接下來該做什麼？」）。自主代理將人類視為架構師（「這是佇列、這是約束、現在獨立執行」）。
這意味著品質取決於任務定義。一個具有明確輸入、預期輸出和成功標準的定義良好的任務可以自主運行。一個模糊的任務如「改善程式碼庫」則不行。在啟用自主代理之前，先投資於任務分解（第 7 堂課）和協定（第 10 堂課）。
實作範例
一個自主運作的測試執行代理：
SETUP: Define the agent
──────────────────────────────────────
Agent: "test-runner"
Mode: autonomous
Constraints:
allowed_actions: [read_file, run_tests, report_result]
denied_actions: [write_file, delete_file]
max_runtime: 120s per task
heartbeat_interval: 30s
CYCLE 1: Claim and execute
──────────────────────────────────────
[CHECK] Query queue → status: "ready", type: "test"
[CLAIM] task-17: "Run integration tests for auth module"
[WORK] Read tests/auth/ → run pnpm test tests/auth/
[REPORT] { passed: 12, failed: 1,
failure: "tests/auth/refresh.test.ts:45" }
[♥] Heartbeat sent at 30s mark
CYCLE 2: Next task
──────────────────────────────────────
[CHECK] Query queue → task-22 found
[CLAIM] "Run unit tests for payment module"
[WORK] Read tests/payment/ → run pnpm test tests/payment/
[REPORT] { passed: 8, failed: 0 }
CYCLE 3: Queue empty
──────────────────────────────────────
[CHECK] No tasks available
[IDLE] Wait 10s → check again → still empty → wait...好的 vs. 壞的自主代理設計
GOOD: BAD:
Single responsibility Multiple responsibilities
Clear success criteria "Make it better"
Bounded execution time "Keep going until perfect"
Structured results Unstructured text output
Example: Lint checker Example: "Code improver"
Input: file path Input: entire codebase
Action: run linter Action: ??? (too broad)
Output: { errors, warnings } Output: "I made some changes"與團隊協定的連接
自主代理使用第 10 堂課中相同的協定訊息。唯一的區別是誰發起：
INTERACTIVE: Human → "Review this PR" → Agent works → responds
AUTONOMOUS: Agent → [checks queue] → [claims] → [works] → responds
Same message format. Same request_id. Different trigger.前後對比
| 互動式代理 | 自主代理 |
|---|---|
| 人類分配每個任務 | 代理從佇列認領 |
| 每個任務後停止 | 持續循環 |
| 人類監控進度 | 心跳信號表示活躍性 |
| 允許所有動作 | 每個操作有安全約束 |
| 瓶頸：人類回應時間 | 瓶頸：任務佇列深度 |
下一堂課
第 12 堂課涵蓋 Worktree 隔離 — git worktree 如何給予每個代理自己的工作目錄和自己的分支，實現真正的平行開發而不會產生合併衝突。