Baton
July 10, 2026 · View on GitHub
English | 繁體中文
Dispatch less. Deliver more.｜少派一點，交付更多。
一套 AI 派工治理 skill，協助 Agent 判斷：該不該派、工作怎麼切、平行到什麼程度，以及如何把結果可靠地收回來。
安裝 Baton · 執行 smoke tests · Benchmark protocol · 信任與安全 · 版本紀錄
多開 Agent，不一定比較快。
多個 subagents 經常重複閱讀相同的文件與程式碼，只為了完成一小部分不同工作。結果是 token 重複消耗、檔案互相衝突、驗證被跑很多次，最後主 Agent 還要花更多成本整合。
Baton 讓 AI 在派工前先判斷：這件事真的值得委派嗎？哪些工作能安全平行？哪些 context 應該共用？誰負責寫入、驗證與最終決策？
它不是讓 AI 派更多 Agent，而是讓每次派工都有理由。
技術上，Baton 在 subagents、workflows、agent teams、worktrees 與程式碼智能工具之上，加上一層 dispatch control plane，引導 AI 選擇能可靠交付的最小執行結構，再管理 context 邊界、artifact ownership、停止條件、集中驗證與最終合成。
它不是另一套 swarm framework，而是避免 AI 把「開更多 Agent」當成所有大型任務預設答案的判斷層。
如果你的 Agent 已經會開 workers，卻還不擅長判斷何時、在哪裡、該派多少，歡迎 Star。如果你希望加入自己的平台限制、review gates、ownership 規則或 workflow adapters，歡迎 Fork。
有使用與沒使用，差距會有多大？
沒有一個誠實、適用所有任務的固定倍數。差距可能是：
- 原本任務就切得很好，所以改善幅度很小；
- 避免數個不必要的 Agent 冷啟動與重複驗證；
- 避免 shared files 被平行覆寫；
- 避免 schema retry 與 rate-limit 形成連鎖失敗；
- 甚至是「成功完成」與「燒完 token 卻得不到可信結果」的差別。
Anthropic 公開的 multi-agent 研究提供了一個重要邊界：多 Agent 在高度可平行的研究任務上可能顯著優於單 Agent，但 token 使用量可達一般聊天互動的約 15 倍；高度共享 context 或 Agent 之間存在大量依賴的任務，則不是理想場景。
這包 skill 的目的，就是保護這筆昂貴的協作投資。
可以把一次 Agent 任務的總成本理解成：
真正必要的工作
+ 重複重建 context
+ 協調與 handoff
+ 重複驗證
+ 衝突與重工
+ 失敗 retry
+ synthesis debt
它無法消除真正必要的工作，但會盡可能減少後六項成本；當後六項成本可能超過派工收益時，它會要求 AI 不要使用多 Agent。
三種代表性差距
以下是操作模型，不是假裝精準的 benchmark：
| 情境 | 沒有派工治理 | 使用這包 skill | 實際差距 |
|---|---|---|---|
| 已知位置的單檔小修 | investigator → builder → verifier，各自重建 context | 主 Agent 直接修改並執行 focused check | 避免冷啟動、handoff 與多餘 review |
| 多 surface 重構 | Builders 各自探索架構，並同時修改 shared types、registries 或 lockfiles | 先收斂 shared contract，再給每個 artifact 單一 owner，最後統一跑 gate | 常是乾淨平行與衝突重工的差別 |
| 大量同質 audit／migration | 任務數直接變成 Agent 數，格式錯誤與 rate limit 放大 retry | small slice → bounded batches → failure threshold → centralized synthesis | 常是可控制 workflow 與不可信昂貴輸出的差別 |
如何量測真實差距？
用相同任務做 before／after，比較：
- 總 token 或模型成本；
- 得到「已驗證結果」的牆鐘時間，而不是第一份輸出的時間；
- shared sources 被重複閱讀的次數；
- overlapping writes、merge conflicts 與被撤銷的修改；
- 重複執行的 repo-wide gates，以及被靜默丟失的 failed／partial results。
合理預期是：
- 小型或高度耦合任務會使用更少 Agent，大幅降低協調成本；
- 真正獨立的工作仍保留平行速度，但減少重複 context 與驗證；
- 高風險 workflow 最大價值可能是避免失敗，而不是讓成功任務只快一點；
- 如果原本的 Agent 已經能做出同樣成熟的判斷，差距應該很小，但規則會變得可見、可審查、可攜帶。
**Benchmark 狀態：**第一份可重現 protocol 已公開，但 paired trials 尚未執行。在保存 raw evidence 之前，Baton 不宣稱已量測的節省比例。詳見 benchmarks/。
它解決的問題
多數 Agent 平台擅長回答：
我要如何同時執行多個 Agent？
真正困難的營運問題是：
這個任務真的需要多 Agent 嗎？如果需要，最小且可靠的設計是什麼？
缺少明確派工政策時，AI 很容易：
- 把五分鐘的小修改派給三個 Agent；
- 讓每個 worker 重讀相同架構；
- 平行修改 shared contracts、registries 或相同檔案；
- 將尚未驗證的 prompt 或嚴格 schema 一次放大到大量任務；
- 讓每個 worker 各跑一次昂貴 build 或 live test；
- 把 worker 自述的結果直接視為已驗證事實；
- 在 synthesis 時靜默丟失失敗或部分完成的結果；
- 整合已經跟不上產出，卻繼續增加 Agent。
它如何改變 AI 的行為
使用者需求
│
▼
Dispatch brake
├── 成果是否明確？
├── 主 Agent 自己做是否更便宜？
├── 工作軌是否真正獨立？
├── 每個寫入 artifact 是否有單一 owner？
└── 誰負責整合與驗證？
│
▼
選擇最小有效 primitive
├── main agent
├── one worker
├── bounded parallel workers
├── batch / workflow
├── collaborative team
├── isolated workspace
└── shared-workspace builders
│
▼
Context pack → ownership → briefs → 受監控執行
│
▼
主 Agent synthesis → 集中驗證 → 誠實分級證據
| 沒有這包 skill | 使用這包 skill |
|---|---|
| 「任務很大，多開幾個 Agent。」 | 「哪些部分真的獨立到值得派工？」 |
| 每個 worker 自己重建專案理解 | 共用結論只整理一次，workers 只讀最小必要內容 |
| 用模糊角色名稱切工作 | 按來源、artifact 與 ownership 切分 |
| 平行程度跟著項目數增加 | 平行程度取決於獨立性與整合能力 |
| 每個 builder 各跑一次全部驗證 | 局部檢查留在局部，昂貴 gate 集中執行 |
| 把所有回報串接後交差 | 主 Agent 裁決矛盾並列出 coverage gaps |
| 失敗後繼續用相同方式 retry | 同因失敗會改變設計或退回直接執行 |
和現有方案有什麼不同？
Agent 生態已經有很好的執行能力：
- OpenAI Agents SDK 提供 manager-style agents、handoffs 與 code orchestration；
- LangChain／LangGraph 提供 subagents、routers、handoffs、skills 與 graph workflows；
- AutoGen 提供 concurrent、sequential、group chat、debate 與 reflection patterns；
- CrewAI Flows 提供 stateful、event-driven control flow；
- Claude Code 與 Ultracode-style workflows 能執行複雜 batches 與 pipelines。
這些工具主要提供 execution primitives。Baton 位於它們上方：
| 問題 | Orchestration frameworks | 這包 skill |
|---|---|---|
| 執行 agents、routes、graphs、flows | 核心能力 | 使用現有能力 |
| 判斷派工是否划算 | 通常交給應用端 | 核心責任 |
| fan-out 前評估 context overlap | 部分支援 | 強制判斷 |
| 分配單一 artifact owner | 通常交給應用端 | 寫入任務必備 |
| 按成本集中驗證 | 通常交給應用端 | 明確政策 |
| 把 integration backlog 當停止訊號 | 依 runtime 而定 | 全域 invariant |
| 保留 failed、partial 與少數異見 | 依實作而定 | 明確回報規則 |
| 派工失敗時乾淨退回直接執行 | 依應用端而定 | 強制出口 |
它不和 Agent runtime 競爭，而是改善 AI 使用 runtime 前後的決策。
核心運作方式
1. 先踩 dispatch brake
fan-out 前必須回答：成果是什麼、為什麼派工比直做更好、哪些工作真正獨立、誰擁有可寫 artifacts、誰負責合成與驗證。缺少答案時，先澄清、scout、收斂 shared contract 或設計 ownership。
2. 選擇最小有效 primitive
| 任務形狀 | 建議 primitive |
|---|---|
| 小任務、最終判斷、synthesis | Main agent |
| 有界探索或獨立驗證 | One worker |
| 少量低重疊角度或 surfaces | Bounded parallel workers |
| 大量重複同質項目 | Batch 或 workflow |
| Workers 必須互相挑戰或協調 | Collaborative team |
| 競爭方案或重疊修改 | Isolated workspace／branch |
| 共用未提交狀態、寫入互斥 | Shared-workspace builders |
3. 明確管理 context 與 ownership
多個 workers 共用背景時，先建立精簡 context pack，只放結論、限制、已排除方向與最小閱讀集。寫入任務則建立 ownership map，包含 allowed、forbidden 與 secondary writes，例如 indexes、generated files、config 與 lockfiles。
4. 分離產出與驗證
Workers 產出局部修改或發現；主 Agent 檢查 ownership、抽驗證據、裁決矛盾，最後集中執行 integration-wide verification。結果分成：
verifiedconsistent but not independently recheckedreasoned but unverifiedneeds human testing
5. 有意識地停止
每個 delegated phase 都必須在達成目標、預算用盡、連續無進展、同因失敗、ownership 失效，或整合成本超過剩餘收益時停止。
可選能力 adapters
核心 skill 不綁平台，只在相關時載入 adapter。
Claude Code／Ultracode Workflow
Ultracode adapter 要求先確認當前能力、先跑 representative small slice、使用 bounded batches、phase boundaries 與 stop conditions，並誠實處理 partial results。它尤其能避免 AI 把「開 Ultracode」誤解成「最大化 fan-out」。
CodeGraph
CodeGraph adapter 在三個階段提供 repository graph 證據：建立有界 task context、改善 dependency impact 與 ownership map、根據實際 changed files 選擇 affected tests。CodeGraph 改善證據，但不取代 source verification 與 ownership 判斷。
安裝
由 Agent 規劃並等待批准
建議讓 Agent 讀取固定版本的 runbook，先顯示完整計畫，取得批准後才寫入：
Read https://raw.githubusercontent.com/cablate/baton/v0.1.1/install/AGENT-INSTALL.md
and prepare a plan to install Baton as $baton-dispatch.
Inspect my current skill directories first. Do not overwrite existing files.
Show the source, destination, changed files, non-changes, and verification steps.
Wait for my approval before writing anything.
Runbook 可重複執行，不會覆寫已修改或無關的同名目錄，而且只安裝一個 baton-dispatch skill 目錄。安裝前可先檢查 安裝 manifest 與 信任邊界。
手動安裝
將固定版本 clone 到 Agent harness 使用的 skills 目錄：
git clone --branch v0.1.1 --depth 1 https://github.com/cablate/baton.git baton-dispatch
再依目前使用產品的文件，把資料夾放置或連結到能探索 SKILL.md 的個人或專案 skills 目錄。不同產品的探索路徑可能不同，因此不在這裡綁死特定版本路徑。
真正給 AI 載入的入口是 SKILL.md；README 是給人閱讀，不是 runtime 必讀內容。
安裝後，如果產品只在啟動時探索 skill，請開啟新 session，再執行 三個 smoke tests。更新前先讀 CHANGELOG.md，再用新 tag 重跑 runbook。移除則依照 UNINSTALL.md。
使用方式
使用 $baton-dispatch 判斷這次 migration 應該由主 Agent
直接做、派 workers、開 workflow，還是使用 isolated branches。請列出
ownership、驗證、synthesis 與停止條件。
開啟 Ultracode 前，先使用 $baton-dispatch 設計派工。
先跑 small slice，再決定是否放大。
使用 $baton-dispatch 搭配 CodeGraph evidence，切分這次
repo refactor，避免 overlapping writes。
研究基礎
- Anthropic：How we built our multi-agent research system
- Anthropic：Effective context engineering for AI agents
- OpenAI Agents SDK：Agent orchestration
- LangChain：Multi-agent systems
- Microsoft AutoGen：Multi-agent design patterns
- CrewAI：Flows
- CodeGraph：Local code knowledge graph
設計原則
- 派工是有成本的決策，不是努力程度的表演。
- 平行化真正獨立的工作，而不是看起來可以拆的工作。
- 共享結論，不要大量複製探索過程。
- 平行寫入之前，先確定 artifact ownership。
- 驗證本身就是 orchestration 設計的一部分。
- 主 Agent 必須擁有 synthesis 與 truth claims。
- 能乾淨退回直接執行，是重要能力。
授權
MIT © 2026 CabLate，詳見 LICENSE。