多 Agent 協作架構：怎麼讓 4 個 AI 不打架
一個 Agent 很好用，四個 Agent 是災難
當我只有一個 agent 的時候，一切很單純。它發它的文，我看我的報告，各做各的。
然後我加了第二個 agent。
第二天，兩個 agent 發了幾乎一樣主題的文章。一個寫「AI Agent 的未來趨勢」，另一個寫「2026 年 AI Agent 發展方向」。本質上是同一篇文章，只是換了說法。
加到四個 agent 之後，問題指數級成長：
- 重複：多個 agent 寫同樣的主題
- 矛盾：一個 agent 說「我們專注 AI 安全」，另一個在推「社群自動化」
- 資源衝突：同時呼叫 API 撞到 rate limit
- 各自為政：每個 agent 不知道其他 agent 在做什麼
這就像請了四個實習生，不給他們開會、不給他們共享文件、不告訴他們彼此的存在。結果就是一團混亂。
解法：把管理人類團隊的方法搬過來
我後來想通了——多 agent 協作的問題，本質上就是團隊管理的問題。
人類團隊怎麼協作？
- 分工明確：每個人有清楚的角色和職責
- 共享資訊：用文件、會議、Slack 同步狀態
- 定期對齊：週會、日報、策略規劃
- 交接機制：一個人做完的事，另一個人能接手
AI 團隊完全一樣，只是把「文件」換成 markdown、把「會議」換成 cron job、把「Slack」換成共享目錄。
第一層：角色定義（IDENTITY.md）
每個 agent 都有一份 IDENTITY.md，定義它是誰：
# Main Agent — UltraLabTW
## 角色
CEO / 策略思想家
## 專業
- AI 產業趨勢分析
- 品牌策略與定位
- 開源生態觀察
## 語氣
專業但不冷冰冰。像一個有經驗的技術主管在分享見解。
## 不做的事
- 不講具體產品功能（那是其他 agent 的事）
- 不寫 how-to 教學（除非是策略層面）
- 不重複其他 agent 最近寫過的主題
其他三個 agent 也各有自己的定位：
| Agent | 角色 | 專注領域 |
|---|---|---|
| Main | CEO / 策略 | 行業趨勢、品牌思維 |
| MindThread | 行銷 | 社群經營、內容策略 |
| Probe | 技術 | AI 安全、漏洞分析 |
| Advisor | 財務 | 理財知識、市場觀察 |
關鍵不是寫了什麼，而是寫了**「不做的事」**。告訴 agent 它不該做什麼，比告訴它該做什麼更重要。這是避免重疊的第一道防線。
第二層：共享記憶體（Markdown Files）
這是整個多 agent 架構最核心的設計：用 markdown 檔案當共享記憶體。
為什麼不用資料庫？不用 vector store？不用 message queue？
因為 markdown 有幾個無法取代的優勢：
- LLM 原生理解 — 不需要 serialize/deserialize，直接塞進 prompt
- 人類可讀 — 我隨時可以打開來看 agent 在想什麼
- Git 友好 — 可以追蹤變化、回滾、diff
- 零依賴 — 不需要跑任何服務，一個檔案系統就夠
每個 agent 的 workspace 裡有這些共享檔案：
workspace/
├── RESEARCH-NOTES.md ← 每日情報（research-chain 產出）
├── POST-PERFORMANCE.md ← 績效數據（post-stats 產出）
├── COMPETITOR-INTEL.md ← 競品分析（competitor-watch 產出）
├── STRATEGY.md ← 本週策略和 OKR
├── INQUIRY-STATUS.md ← 客戶詢問狀態
└── HEALTH-STATUS.md ← 系統健康狀態
這些檔案由不同的 cron job 自動更新：
05:00 research-chain.sh → 更新 RESEARCH-NOTES.md
06:30 competitor-watch.sh → 更新 COMPETITOR-INTEL.md
22:00 post-stats.sh → 更新 POST-PERFORMANCE.md
每 6h inquiry-tracker.js → 更新 INQUIRY-STATUS.md
每 1h health-monitor.sh → 更新 HEALTH-STATUS.md
Agent 發文前，會讀取所有相關的 markdown 檔案。 這代表每個 agent 都知道：
- 今天行業發生了什麼（RESEARCH-NOTES）
- 最近什麼類型的文章表現好（POST-PERFORMANCE）
- 競品在做什麼（COMPETITOR-INTEL）
- 公司目前的策略方向（STRATEGY）
這就是 Pre-Compute 架構的精髓：情報事先準備好，agent 只負責思考和產出。
第三層：Content Relay（跨 Agent 接力）
光是不重複還不夠。真正的團隊合作是——一個 agent 做完的事，另一個 agent 能接著做。
這就是 Content Relay Queue 的作用。
機制很簡單：agent 發完文之後，可以把一條訊息放進 relay queue：
# content-relay.json
[
{
"from": "probe",
"to": "main",
"message": "剛發了一篇 OWASP Top 10 分析，適合從策略角度展開",
"post_id": "abc123",
"timestamp": "2026-04-14T07:00:00Z"
}
]
下一個 agent 執行時，會檢查有沒有指給自己的 relay：
# 檢查有沒有 relay 給我
my_relays=$(jq "[.[] | select(.to == \"$AGENT_NAME\")]" \
"$DATA_DIR/content-relay.json")
if [ "$my_relays" != "[]" ]; then
# 把 relay 內容加進 prompt
RELAY_CONTEXT="你的隊友最近做了這些事：
$my_relays
考慮是否從你的角度延伸。"
fi
這創造了一種 emergent collaboration——我不需要寫死「probe 寫完安全分析後 main 要寫策略文」，我只需要讓 relay 機制存在，agent 自己會判斷要不要接力。
實際效果：
Probe 07:00 → 發文：OWASP Agentic Top 10 漏洞分析
→ relay 給 Main：「適合從企業策略角度展開」
Main 08:00 → 讀到 relay
→ 發文：為什麼你的企業需要 Agent 安全策略（引用 Probe 的分析）
→ relay 給 MindThread：「可以做社群版本的摘要」
MindThread 09:00 → 讀到 relay
→ 發文：一張圖看懂 AI Agent 十大風險
一條內容，三個角度，三篇文章。這不是我規劃的，是 relay 機制讓它自然發生的。
第四層：Team Briefing（每日對齊）
每天早上，一個叫 team-context.sh 的 script 會生成 fleet briefing：
# 從各來源匯總
BRIEFING=""
BRIEFING+="## 客戶動態\n$(tail -20 INQUIRY-STATUS.md)\n"
BRIEFING+="## 昨日績效\n$(tail -20 POST-PERFORMANCE.md)\n"
BRIEFING+="## 競品動態\n$(tail -15 COMPETITOR-INTEL.md)\n"
BRIEFING+="## 系統狀態\n$(tail -10 HEALTH-STATUS.md)\n"
echo -e "$BRIEFING" > fleet-briefing.md
這份 briefing 會被注入每個 agent 的 prompt。等於是每天早上開了一個全員會議，但不需要任何人到場。
第五層：週策略會議（Weekly Strategy）
每週日中午，weekly-strategy.sh 會做一件更有趣的事：
- 分別問 3 個 agent「你覺得下週應該做什麼？」
- 把三份建議收集起來
- 交給 Main agent（CEO 角色）做最終綜合
# 第一步：每個 agent 提案
mindthread_proposal=$(ask_agent "mindthread" \
"根據本週績效和趨勢，你建議下週的內容策略是什麼？")
probe_proposal=$(ask_agent "probe" \
"根據最新的安全趨勢，下週應該關注什麼？")
advisor_proposal=$(ask_agent "advisor" \
"從市場和競品角度，下週有什麼機會？")
# 第二步：CEO 綜合
strategy=$(ask_agent "main" \
"以下是團隊的提案，請綜合成下週策略：
行銷提案：$mindthread_proposal
安全提案：$probe_proposal
市場提案：$advisor_proposal
請輸出：3 個優先事項 + 每個 agent 的具體任務")
echo "$strategy" > STRATEGY-NEXT-WEEK.md
成本：大約 5 次 LLM call。一週一次。
效果：agent 不再是各做各的，而是有統一的週策略。 而且這個策略不是我寫的，是它們自己討論出來的。
第六層：Cross-Agent Engagement
每週二和週五，agent 們會做一件很有意思的事：互相回覆對方的文章。
# cross-engage.sh
# 規則：只回覆其他 agent 的文章，不回自己的
for agent in main mindthread probe; do
others=$(get_other_agents "$agent")
target_post=$(get_recent_post "$others")
reply=$(generate_reply "$agent" "$target_post" \
"從你的專業角度，對這篇文章提出一個有建設性的觀點")
post_reply "$reply" "$target_post"
done
這創造了一個看起來很自然的對話：安全專家回覆策略文章說「從安全角度我想補充…」，行銷專家回覆安全分析說「這個觀點對品牌推廣很有參考價值…」
不是假互動。是同一個公司的不同角色在公開場合展示專業深度。
架構總覽
┌─────────────┐
│ Weekly │
│ Strategy │ ← 每週日
└──────┬──────┘
│
┌──────▼──────┐
│ STRATEGY │
│ .md │
└──────┬──────┘
│
┌──────────────────────┼──────────────────────┐
│ │ │
┌───▼───┐ relay ┌─────▼─────┐ relay ┌─────▼─────┐
│ Main │ ◄──────── │ Probe │ ────────►│ MindThread│
│ (CEO) │ │ (Security)│ │ (Marketing)│
└───┬───┘ └─────┬─────┘ └─────┬─────┘
│ │ │
└──────────┬──────────┴──────────────────────┘
│
┌──────▼──────┐
│ 共享記憶體 │
│ RESEARCH │
│ PERFORMANCE │
│ COMPETITOR │
│ HEALTH │
└─────────────┘
六層設計，每層解決一個問題：
| 層 | 解決 | 機制 |
|---|---|---|
| IDENTITY | 角色重疊 | 明確定義做什麼、不做什麼 |
| 共享記憶體 | 資訊孤島 | Markdown 檔案 + cron 自動更新 |
| Content Relay | 各自為政 | JSON queue + 自動接力 |
| Team Briefing | 缺乏上下文 | 每日匯總注入 prompt |
| Weekly Strategy | 沒有方向 | Agent 提案 + CEO 綜合 |
| Cross-Engage | 看起來孤立 | 互相回覆建立對話 |
為什麼是 Markdown 不是資料庫
我知道很多人看到這裡會想：「為什麼不用 Redis？為什麼不用 Postgres？為什麼不用 vector store？」
因為：
- Agent 本身就是語言模型，markdown 是它最自然的輸入格式
- 我只有一台機器，跑額外的服務就是多一個要維護的東西
- Debug 的時候，我可以直接
cat RESEARCH-NOTES.md看 agent 的「想法」 - 成本是 $0，不需要任何雲端服務
當你的規模是 4 個 agent、每天 100 次操作的時候，markdown 完全夠用。
等哪天我需要管 40 個 agent，再來考慮資料庫。不要為還不存在的問題建架構。
下一篇
agent 有了角色、有了情報、有了協作機制。但有一個問題還沒解決：品質。
自動產出的內容，怎麼確保不是垃圾？怎麼讓 agent 自己知道寫得好不好？怎麼在不增加太多成本的前提下，把品質拉到「能看」以上？
下一篇：自動內容不等於垃圾：品質閘門實戰