CoStaff 就是我針對這一段所做的系統。它由一個 Manager Agent 與數個專職 Agent 組成， 彼此透過 A2A protocol 溝通，工具整合走 MCP， 每個 Agent 各自跑在獨立的 Docker container 裡。 今天要向大家宣布，第一個 CoStaff 正式版本 v0.1.0 已經上線到 GitHub。
CoStaff 是一套自架的多 Agent 系統：你在聊天軟體裡交辦， Manager Agent 拆解後分派給專職 Agent，完成的檔案送回你的對話裡， 全部跑在自己的機器上。
這次是第一個正式版本，11 個 repo 的版本全部拉齊，
只要下 costaff update --all --tag v0.1.0，
裝到的就是一組已經驗證過的組合。
想直接動手的話可以跳到第 VI 節；
中間幾節談的是架構上的取捨。
I. 交付這一段為什麼會缺
以「幫我做南區第三季的銷售報告」這個需求為例，它其實橫跨了三種能力： 知道資料在哪張表、能把查詢結果轉成合適的圖表、能把圖表跟敘述組成一份帶字型的 PDF。 要一個 Agent 同時做到這三件，代價就是 instruction 無限膨脹、工具集互相干擾。
拆成多個專職 Agent 是自然的解法。但拆完馬上要回答兩個問題： 每位專員手上的工具從哪裡來， 以及他們之間怎麼交接產出的檔案。 這兩題答得好不好，決定了整套系統到頭來能不能真的交件， 也是 CoStaff 架構上最主要的兩個取捨。
II. Agent ↔ MCP ↔ 工具：三層各自負責什麼
一個 Agent 要能真的動手，前提是它手上得有工具。 這些工具從哪裡來、由誰定義，決定了整套系統的形狀。 CoStaff 的做法是把它拆成三層。
工具層是實際會動到檔案、資料庫、指令的那些函式。
以開源的 database agent 為例，它就四個：
get_connected_databases、inspect_database、
inspect_table、query ——
先看有哪些連線、再看 schema、最後才查。
coding agent 則有 56 個，涵蓋檔案讀寫、git、執行、lint 與環境管理。
MCP 層把這些函式暴露出去。
coding agent 的 MCP server 是自動註冊的：
掃過 tools/ 底下每個模組，把所有非底線開頭的公開函式
直接註冊成工具。要加一項能力，就是在 tools/ 新增一個函式，
不必碰 server、也不必改 Agent 的 instruction。
Agent 層只負責推理與判斷。它透過環境變數
（像 BUSINESS_ANALYSIS_AGENT_MCP_URLS）指到一組 MCP endpoint，
能做到哪些事完全看那組 MCP 開放了什麼。
最上面才是 Manager Agent，透過 A2A protocol 把任務分派給對應的專員。
為什麼這樣拆有差
一、加能力不用動模型。
工具是一般的 Python 函式，寫完放進 tools/ 就生效。
不用重訓、不用調 prompt，Agent 下次就會用了。
二、專員是真的能動手，不只是回話。
coding agent 的工具裡有 write_file、patch_file、
git_commit、run_pytest；
database agent 有 query。
它是真的去改檔案、真的跑測試，不是告訴你「你可以這樣改」。
三、交付這一段有人負責。
business-analysis agent 的 11 個工具裡，有一半在處理輸出：
create_report_from_markdown、create_html_report、
export_pdf，還有一個 inject_noto_font ——
專門處理中日文在 PDF 裡變成豆腐方塊的問題。
這種東西不迷人，但少了它，最後那份檔案就不能直接寄出去。
III. 專員之間，交接的是檔案
第二個問題更實際：一件事經手三位專員，中間產出的檔案要怎麼傳？ 把整份 CSV 塞進訊息裡傳來傳去顯然不合理。
CoStaff 的做法是所有容器共掛一個 costaff_data volume 到
/app/data，每個專員有自己的工作目錄
/app/data/agent-{id}/。
這樣一來，隔離跟共享就不衝突：專員各寫各的目錄，不會互相踩到， 但需要的時候，business-analysis agent 可以直接讀 coding agent 的產出， 不必把檔案 base64 塞進 A2A 的訊息裡傳來傳去。 一條「資料庫撈數 → 程式對帳 → 分析出報告」的鏈路， 中間傳的是路徑，不是內容。
IV. 為什麼堅持它要能自己架
整套跑在你自己的機器上，裝在 Docker 裡。這是刻意的設計前提，不是還沒做雲端版。
costaff agent add 掛載，不必改核心程式碼。V. v0.1.0 帶了什麼
- Manager Agent —— 對話入口，負責拆解與路由。
- 專職 Agent —— business-analysis（分析與報告輸出）、coding（檔案、git、測試）、database（schema 探索與查詢），另外還有 twinkle-hub 與 wrenai-oss。
- Agent template —— 要寫自己的專員就從這份開始。
- 通訊管道 —— Telegram 與 WebChat（OSS 版支援 SSE 非同步推送，長任務完成後主動送回）。
- CLI ——
costaff start、costaff agent add、costaff channel add、costaff update。
VI. 安裝與啟動
前置是 Python 3.10+ 與 Docker：
curl -fsSL https://raw.githubusercontent.com/costaff-ai/costaff/main/install.sh | bash
onboard 是互動式精靈，問完模型、通訊管道與對應的 token 之後寫進
.env；start 會依序拉起 Postgres、Agents、Manager、Channels：
costaff onboard
costaff start要加專員或通道，指定 tag 就能 pin 住版本：
costaff agent add business-analysis \
--github https://github.com/costaff-ai/costaff-agent-business-analysis --tag v0.1.0
costaff channel add telegram --tag v0.1.0更完整的流程在快速開始， Agent、Channel 與 CLI 的細節在說明文件。
總結
CoStaff 的定位不在編排層本身，而在把編排的結果真的交付出來。 工具就是一般的 Python 函式，MCP 把它們自動註冊出去， Agent 則專心推理 —— 所以加一項能力只是多寫一個函式， 而且專員是真的去改檔案、跑測試、把 PDF 產出來，不是建議你自己去做。 再加上共享卷讓專員之間交接的是檔案而不是字串， 整條鏈路都在你自己的資料邊界內完成。
到了 v0.1.0，我才敢請大家直接裝來用。 裝了之後如果哪裡不對，開 issue 告訴我 —— 版本剛發出來的時候，這種回報最有價值。
開源，自架，跑在你自己的機器上。從核心開始，只加你需要的專員。