Agent Team 實戰（番外篇）：從 OS 的 IPC 看 Agent 溝通——五層決策模型

一句話： Agent 溝通不是新問題，OS 的 IPC 幾十年前就處理過了，而且幾乎可以直接套用。 提醒： 這篇主要提了很多 OS 設計的概念，如果你不想看這麼技術的東西，直接看下一篇的實戰可能比較直覺

上週我前同事在公司的 Slack 寫了一篇文，分析了 Agent 之間的溝通架構，他把 Claude Code Agent Teams、OpenClaw、A2A Protocol 三個系統拆開來看，然後做了一件讓我眼睛一亮的事：他把整個分析框架建立在作業系統的 IPC（Inter-Process Communication）之上。

讀到一半的時候我停下來，因為我突然想起去年 11 月我也查過 OS 框架，當時在發展 Agent 的記憶跟溝通框架時覺得「這好像以前讀過，來查一下」，但查完沒有深入就忘了，直到看到前同事的文章才又接上這條線，他是本科系的，所以整個概念比我清楚很多，所以我請 Em 把這篇文章 ingest 進 wiki，看看能不能從裡面提取出一個可以用的分析框架。

Em ingest 完之後，wiki 裡多了一個概念頁面：agent-communication-layers.md，裡面整理出了一個五層模型，而這個模型可以用來檢視我自己的 Agent Team 溝通設計，這是後面要講的事（下一篇），但在那之前，讓我先把這個模型講清楚。

Agent 溝通就是 OS 的 IPC

這不是比喻，是直接對應。

OS 裡的 process 之間怎麼傳遞資料？pipe、shared memory、message queue、file lock、signal，這些在學作業系統的時候都摸過（雖然那時候做夢也沒想到有一天會用來設計 AI Agent 的溝通架構），而在 Agent 系統裡，這些概念幾乎原封不動地重演了一遍：

連經典的 OS 問題都一模一樣，Scheduling、Memory isolation、Permission inheritance 這些在 Agent 系統裡各自有對應的挑戰，但最讓我有感覺的是 context switch：OS 的 process 被喚醒要從 register 重建狀態，Agent 被喚醒要從 mailbox 讀訊息重建 context，每次 session 開始的那幾秒鐘，Agent 在做的事情本質上就是 TLB miss，他必須把之前散落在各處的狀態重新載入，才能繼續工作，而這個重建的品質直接影響他接下來的判斷。

所以如果你正在設計 Agent 之間的溝通，不要從零開始，OS IPC 已經處理了幾十年，你可以直接站在巨人的肩膀上。

五層決策模型

既然 Agent 溝通就是 IPC，那 IPC 的設計可以怎麼拆解？同事的文章整理出了一個五層模型，由下往上，每一層的選擇會限制下一層的選項：

L4  Content Contract    — 傳什麼（memory selection + compression）
L3  Protocol            — 什麼格式（message envelope、interaction pattern、task lifecycle）
L2  Topology            — 誰跟誰講（hierarchy / star / peer / pub-sub）
L1  Transport           — 怎麼傳（pipe / file / WebSocket / HTTP）
L0  Environment         — Agent 在哪（same process / machine / network / internet）

最底層的 L0（Environment）通常不是你選的，是被 harness 決定的：Agent 跑在同一個 process 裡就用 function call（Smolagents、LangGraph），same machine 就用 file 或 pipe（Claude Code），跨網路就用 WebSocket 或 HTTP（OpenClaw、A2A），我的 Agent Team 全在同一台 Mac 上，所以 L0 = same machine，這直接決定了往上每一層的選項。

L1 — Transport：怎麼傳？

越往左延遲越低但耦合越高，越往右越獨立但越慢，這跟 OS 選 IPC 機制的 trade-off curve 一模一樣。

Claude Code Agent Teams 選 file 是因為精準判斷了自己的 environment，所有 Agent 保證在 same machine，file I/O 比任何 message queue 都好 debug，直接 cat 那個 inbox JSON 就能看到發生什麼事，這個 debug 優勢在實際開發中價值很高（我在第五篇就體會過了，silent failure 的時候，能直接看 inbox 的內容省了很多猜測的時間）。

L2 — Topology：誰跟誰講？

一個重要的觀念：transport 跟 topology 是解耦的， WebSocket 不必然是 star，HTTP 不必然是 P2P，選 star 常常是出於營運簡化（不用每個 Agent 各自開 port），不是技術限制。

我的 Agent Team 用的是 star（GM 做中央協調）+ limited peer（Agent 之間可以透過 filesystem 直接溝通做核心工作），這個混合拓撲是從實際需求長出來的：GM 負責協調和判斷，但 Em 和 C7 做核心工作的時候不需要經過 GM 才能讀到彼此的檔案。

L3 — Protocol：什麼格式？

Protocol 定義三件事：message envelope（寄件人、收件人、時間戳、message ID）、interaction pattern（fire-and-forget / request-response / streaming / 多輪對話）、task lifecycle（狀態機：submitted → working → input-required → completed / failed）。

Protocol 的複雜度跟信任邊界的距離成正比：

內部用薄 protocol，對外用厚 protocol，同一套系統不同場景用不同厚度，這也跟 OS 的做法一致。

L4 — Content Contract：傳什麼？

前四層只是把 bytes 送到，L4 決定對方能不能用。

Agent 之間傳的不是隨便一段文字，是經過 memory selection 和 compression 的結構化內容，你可以有完美的 transport，但如果 Agent A 傳了超大的 raw context dump，Agent B 的 context window 直接爆掉，推理品質斷崖式下降，溝通就失敗了。

L4 是 Agent 溝通成敗的真正關鍵， 用我前同事的說法，這是目前所有系統做得最粗糙的一層，之前在 Context Engineering 那篇講的 JIT loading、token budgets 這些原則，其實都應該延伸到 Agent 之間的溝通：你不會把所有東西塞進一個 Agent 的 Context 裡，你也不應該把所有東西塞進一則 Agent 間的訊息裡。

順便釐清一個常被搞混的東西：MCP vs A2A

這兩個常常被放在一起比較，但它們解決的是完全不同層面的問題：

兩者是互補的，不是競爭的，A2A 的官方 spec 裡明確說了這是 complementary protocols，一個 Agent 可以用 MCP 呼叫工具，同時用 A2A 跟另一個 Agent 溝通，在同一個工作流裡。

三系統比較：Claude Teams vs OpenClaw vs A2A

把三個系統攤開來用五層模型對照，每一層的設計選擇都很清楚：

三個系統不是「哪個比較好」的關係，而是「在不同的 L0 環境下做了合理的設計選擇」，Claude Teams 的 file I/O 在 same machine 的場景下是最好的選擇（好 debug、零基礎建設、持久化免費），但你不會用 file I/O 做跨網路的 Agent 溝通，那時候 A2A 的 HTTP + JSON-RPC 才是合理的。

帶著模型回頭看

有了五層模型之後，我做的第一件事是拿它來對照我自己的 Agent Team 設計。

L0 到 L2，我發現自己已經在不知不覺中，做了正確的選擇：same machine、file I/O、star + limited peer，這些都跟 OS 的最佳實踐一致，這些決定現在做事後驗證後確認方向是對的。

但到了 L3 和 L4，事情開始變得有趣了。

我的 Level 1 Completion Report 設計得很標準，有格式、有欄位、有 Flag 機制，但它從來沒有被真正使用過，我的 dispatch 機制有去有回，但回來的那條路只走了一半，五層模型幫我看到了這些 gap，但同時也讓我意識到，OS 的框架在 L0-L2 完全適用，但到了 L3-L4，我的 Agent 跟 OS 的 process 有一個根本性的差異，這個差異讓 OS 的解法不能直接套用。

這個差異是什麼？我又做了什麼？在 Agent Team 狀況下又該怎麼拆解跟思考？到這，番外篇結束，下一篇讓我們回到 Agent Team 實戰繼續說。

參考資料

[1] arXiv — Solving Context Window Overflow in AI Agents（context window 對推理品質的影響） https://arxiv.org/html/2511.22729v1

[2] AI Pace — Context Engineering: Mitigating Context Rot in AI Systems（「context 越大，模型可靠性越低」） https://medium.com/ai-pace/context-engineering-mitigating-context-rot-in-ai-systems-21eb2c43dd18

[3] Anthropic — Effective Context Engineering for AI Agents https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

[4] FINOS — Multi-Agent Trust Boundary Violations（scope violation 的級聯效應） https://air-governance-framework.finos.org/risks/ri-28_multi-agent-trust-boundary-violations.html

[5] Google — A2A Protocol Specification（complementary to MCP） https://google.github.io/A2A/