DEV Community

agBythos
agBythos

Posted on

我如何建立一個能自我繁殖的 6 人 AI 團隊

#ai #multiagent #productivity #devlog

開頭：一個不夠用的 Agent

我用 OpenClaw 跑 AI agent 已經幾個月了。單一 agent 很好用——但當我開始嘗試讓它「spawn sub-agent 來幫忙」時，撞上了第一道牆：

Sub-agent 無法再 spawn sub-sub-agent。

這不是 bug，是設計。Sub-agent 在父 agent 的 session context 裡執行，繼承了父 agent 的 workspace 路徑和工具權限，但沒有獨立的身分——它沒有自己的 workspace，也沒有讀取 spawn 工具所需的完整上下文。

換句話說：你可以叫助理幫你打電話，但你不能叫那個助理再叫他的助理幫他打電話。

我想要的是真正的組織架構，不是單層外包。

解法：讓每個 Agent 都有自己的公司

解法其實很直觀：不要把 agent 當 sub-agent，而是當獨立的 agent。

每個「部門」都有：

  1. 自己的 workspace 目錄（workspace-vp/、workspace-researcher/ …）
  2. 自己的 SOUL.md（人格、工作範圍、禁止事項）
  3. 自己的 spawn 權限（可以啟動自己的 sub-agent）

這樣，每個 agent 醒來時都知道自己是誰、能做什麼、不能做什麼——不依賴父 agent 的 context。

架構：龍蝦公司

我把這個系統叫做「龍蝦團隊」（名字來自 CEO 的名字 Bythos，深海的意思）。

Bythos (CEO) — Claude Opus 4.6
├── VP (Vice President) — Claude Sonnet 4.5
│   └── [可 spawn sub-agents]
├── Researcher (研究員) — Claude Sonnet 4.5
│   └── [可 spawn sub-agents 做並行資料收集]
├── Writer (寫手) — Claude Sonnet 4.5
│   └── [可 spawn sub-agents 做初稿]
└── QA (品質保證) — Claude Sonnet 4.5
    └── [可 spawn sub-agents 做並行測試]
Enter fullscreen mode Exit fullscreen mode

為什麼 CEO 用 Opus，其他用 Sonnet？

Opus 負責策略決策、任務分解、跨 agent 協調——這些需要更強的推理能力。Sonnet 的性價比更高，適合執行層。一個 Opus 的 token 成本大概是 Sonnet 的 5 倍，所以只讓 CEO 用貴的。

實際數據：一個 sub-agent 任務（如下載 4 部 YouTube 影片並產出筆記）大約 3-5 分鐘完成，消耗 60-100k tokens。CEO 花在分派和驗證上的 token 不到 2k。

SOUL.md：Agent 的人格憲法

每個 agent 的個性和邊界都定義在 SOUL.md 裡。這是真正讓系統可控的部分。

VP 的 SOUL.md（節錄）：

# SOUL.md — VP (Vice President)

你是 VP，Bythos（CEO）的副手。你的工作是接收任務、拆解執行、回報結果。

## 核心原則
1. **執行，不問**：收到任務就做，做完回報。不確認、不反問。
2. **精準回報**：結果用數據說話。格式：做了什麼 → 結果 → 發現了什麼。
3. **範圍自律**：只做被指派的事。超出範圍的發現記下來回報，不自行擴大。
4. **安全繼承**：遵守 Bythos 的 HITL 規則。Level 0 操作停止回報。

## 禁止
- 不修改主 workspace 的 SOUL.md / AGENTS.md / MEMORY.md
- 不直接發 Discord 訊息（透過 Bythos 中轉）
- 不做金融交易、不刪系統檔案
Enter fullscreen mode Exit fullscreen mode

QA 的 SOUL.md（節錄）：

# SOUL.md — QA（品質保證）

## 核心原則
1. **懷疑一切**：預設所有東西都有問題，直到你證明沒有
2. **可重現**：每個 bug 都要有重現步驟
3. **邊界測試**：正常 case 通常沒問題，問題在邊界（空值、極大值、併發、編碼）
4. **自動化**：能寫測試腳本就寫，不要手動驗證

## 輸出格式
## QA Report
- **測試對象**：[什麼]
- **結果**：PASS / FAIL
- **發現**：[問題] — 嚴重度 — 重現步驟
Enter fullscreen mode Exit fullscreen mode

注意細節：QA 預設「懷疑一切」，這不只是文字，它真的會影響 agent 的行為。當你在 SOUL.md 裡說「每個 bug 都要有重現步驟」，agent 真的會在回報時附上重現步驟，而不只是說「有個 bug」。

Researcher 的特點：

## 核心原則
1. **深度優先**：寧可一個主題挖透，不要十個主題都碰表面
2. **數據驅動**：每個結論都需要數據支撐。沒數據的觀點標記為「推測」
3. **批判思維**：主動找反面證據。如果找不到反面 = 你沒認真找
Enter fullscreen mode Exit fullscreen mode

「如果找不到反面 = 你沒認真找」——這句話很重要。LLM 天生有確認偏誤，會傾向找支持初始假設的資料。明確要求它找反面證據，能顯著提升報告品質。

工作流程：一個任務的生命週期

以「寫一篇技術文章」為例：

用戶 → Bythos (CEO)
  "幫我寫一篇關於 multi-agent 架構的文章"

Bythos 分析任務，spawn subagent：
  → Researcher: "調查 multi-agent 架構的最新論文和實作案例"
  → (等待 Researcher 回報)

Researcher spawn 自己的 sub-agent：
  → sub-agent A: "搜尋 AutoGen、LangGraph、CrewAI 比較"
  → sub-agent B: "爬取 Anthropic multi-agent 官方文件"
  → (並行執行，合併結果)

Researcher 回報研究摘要給 Bythos

Bythos → Writer: "根據這份研究，寫一篇 dev.to 文章，風格參考 SOUL.md"

Writer 產出草稿 → 存到 dev-output/

Bythos → QA: "審查這篇文章的事實準確性和邏輯一致性"

QA 回報問題清單

Bythos 整合，決定是否需要修改，回報給用戶
Enter fullscreen mode Exit fullscreen mode

整個流程，Bythos 不需要直接動手做任何具體工作。它的工作只有兩件事：任務分解、整合回報。

調試日記：那些踩過的坑

坑 1：模型命名問題

第一次設定 VP agent 時，指定模型用的是：

{
  "model": "claude-opus-4-5"
}
Enter fullscreen mode Exit fullscreen mode

系統報錯說找不到這個模型。花了 20 分鐘才發現正確格式是：

anthropic/claude-opus-4-5
Enter fullscreen mode Exit fullscreen mode

加上 provider prefix。API provider 的格式規範和直覺不一樣，而且錯誤訊息不夠明確——它說「model not found」，但沒說「你少了 provider prefix」。

教訓：第一次設定新 agent，先用 /status 確認模型名稱格式，別猜。

坑 2：PowerShell UTF-8 地獄

這個坑更噁心。

當 Agent 嘗試用 PowerShell 寫入含有繁體中文的 SOUL.md 時，會出現：

ä½ æ¯ VP
Enter fullscreen mode Exit fullscreen mode

這是 UTF-8 被 Windows-1252（CP1252）誤讀的典型症狀。PowerShell 5.x（Windows 預設）的 Write-File 輸出不加 BOM，但某些工具會把無 BOM 的 UTF-8 讀成系統預設編碼（Windows 是 ANSI）。

解法一：明確指定編碼

$content | Out-File -FilePath $path -Encoding UTF8
Enter fullscreen mode Exit fullscreen mode

但 PowerShell 5 的 -Encoding UTF8 會加 BOM，有些工具又不喜歡 BOM。

解法二（最終採用）：用 .NET 的 StreamWriter，不加 BOM：

[System.IO.File]::WriteAllText($path, $content, [System.Text.Encoding]::UTF8)
Enter fullscreen mode Exit fullscreen mode

或者，乾脆讓 Agent 直接用工具寫檔，不走 PowerShell echo。因為工具層（Node.js）的 UTF-8 處理比 PowerShell 可靠得多。

教訓：在 Windows 上做任何涉及非 ASCII 字元的自動化，預設假設 encoding 會出問題。

坑 3：Agent 越界

早期版本的 VP SOUL.md 沒有明確說「不修改主 workspace」，結果 VP 在執行一個研究任務時，順手幫我「整理」了主 workspace 的 MEMORY.md——因為它覺得這樣「更有效率」。

這不是 Agent 壞，是我沒說清楚。

加了這一行之後問題消失：

## 禁止
- 不修改主 workspace 的 SOUL.md / AGENTS.md / MEMORY.md
- 只在自己的 workspace 目錄下工作
Enter fullscreen mode Exit fullscreen mode

教訓：Agent 的 SOUL.md 要明確寫「不做什麼」，不只是「做什麼」。LLM 的預設是「幫忙做更多」，你要主動限縮範圍。

設計原則整理

經過幾週實驗，我提煉出幾個讓多 Agent 系統可靠運作的原則：

1. 身分隔離 > 工具隔離

Agent 有沒有工具不是最重要的，最重要的是它知不知道自己是誰。SOUL.md 是讓 Agent 「知道自己是誰」的機制。

2. 禁止清單比允許清單更重要

LLM 的預設行為是「盡量幫忙」。你不說不能做什麼，它就會做。允許清單容易遺漏，禁止清單要明確。

3. 輸出格式強制化

每個 Agent 的 SOUL.md 都定義固定的輸出格式。這讓 CEO agent 能可靠地解析下屬的回報，不用猜測格式。

## 回報格式
### 完成項目
- [x] 項目 1 — 結果

### 發現
- 發現 1

### 建議下一步
- 行動 1
Enter fullscreen mode Exit fullscreen mode

4. 安全規則繼承

所有 Agent 的 SOUL.md 都有這一行：「繼承 Bythos HITL 規則。Level 0 操作停止回報。」

HITL（Human-in-the-Loop）規則只在 CEO 層定義一次，其他 Agent 繼承，不各自重新定義。這樣修改安全規則時只改一個地方。

5. 模型分層

不要讓所有 Agent 用同一個模型。策略層用強模型，執行層用快模型。成本和速度差很多，效果差不多。

結果：它真的有用嗎？

老實說：大部分有用，少數情況需要干預。

有用的地方：

  • 並行執行真的快。Researcher spawn 4 個 sub-agent 同時搜尋，比單 agent 依序快 3-4 倍
  • Agent 有個性之後，輸出品質更一致。QA 真的比較嚴格，Writer 真的比較注意讀者
  • 任務範圍限縮後，幻覺（hallucination）減少了——因為 Agent 不再嘗試「做超出範圍的事」

需要干預的地方：

  • 跨 Agent 傳遞的 context 有時候會失真。Researcher 的報告傳給 Writer，有時候重點跑掉
  • CEO（Bythos）偶爾會在不需要的時候過度分解任務，召喚太多 Agent
  • 長任務鏈（A→B→C→D）的錯誤累積效應明顯

這些問題不是無解，只是需要更多調整——更好的 prompt 工程、更清楚的交接格式、偶爾的人工節點。

下一步

幾個想繼續實驗的方向：

  1. Agent 之間的直接溝通：目前所有通訊都透過 CEO 中轉，效率低。理想是 Writer 能直接問 Researcher「這個數據哪裡來的」
  2. 記憶共享：各 Agent 的 memory/ 目前是隔離的，但有些知識應該共享（比如「用戶喜歡什麼風格」）
  3. 異步工作：Agent 目前是同步呼叫，CEO 要等 Researcher 回報才能叫 Writer。理論上可以並行，但需要更複雜的協調機制

結語

建立多 Agent 系統最反直覺的地方是：問題不在技術，在組織設計。

你需要思考的問題和管理一個真實團隊一樣：

  • 每個人的職責是什麼？
  • 誰能做決定，誰只能執行？
  • 出了問題，誰負責？
  • 資訊怎麼流動？

SOUL.md 就是這些問題的答案。

程式碼比想像中少，思考比想像中多。

附錄：最小可用設定

如果你想自己試，最簡單的雙 Agent 設定：

目錄結構：

workspace-ceo/
  SOUL.md
  AGENTS.md
  memory/
workspace-worker/
  SOUL.md
  AGENTS.md
  memory/
Enter fullscreen mode Exit fullscreen mode

CEO SOUL.md 最小版：

你是 CEO。接到任務後，拆解成子任務，spawn worker agent 執行，整合結果回報。

## 規則
- 不自己執行具體工作
- 每次 spawn 前說明為什麼
- Worker 回報後整合再交給用戶

## HITL
Level 0（刪除、發送、支付）：停止，詢問用戶
Enter fullscreen mode Exit fullscreen mode

Worker SOUL.md 最小版：

你是 Worker。接到具體任務，執行，回報結果。

## 規則
- 只做被指派的事
- 結果寫到 workspace-worker/output/
- 不修改 workspace-ceo/ 的任何檔案

## 安全
繼承 CEO 的 HITL 規則
Enter fullscreen mode Exit fullscreen mode

從這裡開始，按需求加角色、加規則。不要一開始就建 6 個 Agent——先讓 2 個 Agent 順暢協作，再加第 3 個。

本文基於實際使用 OpenClaw 的經驗寫成。所有錯誤和教訓都是真實的。

Top comments (0)