AI 代理人擅長一次處理一件事。給予 Claude 一個專注的任務，它就能執行。但實際工作並非單一任務，而是一個包含依賴關係、並行處理和需要在任務間流動的上下文的任務樹。

多代理人框架正在快速增加，但它們都解決了錯誤的問題。

LangGraph 將協調建模為狀態機。你在 Python 中定義節點和邊。開發者預先決定代理人如何交接工作。這對於固定的工作流程非常強大，但圖是靜態的。如果一個代理人在任務中途意識到工作應該以不同的方式分解，那就沒辦法了。開發者必須預先預測所有分解模式。

CrewAI 是基於角色的。你為代理人定義角色——「研究員」、「分析師」、「寫論文者」——並分配任務給他們。這很直觀，但角色是由開發者決定的，而不是由代理人發現的。一個三人團隊無法決定它實際上需要五個人，或者「研究員」應該分成兩個並行軌道。

AutoGen 將代理人置於群組聊天中。它們透過互相交談來協調。這很靈活，但缺乏結構。沒有依賴關係追蹤，沒有權威範圍界定，也沒有類型化的結果。協調是從對話中產生的，這意味著它不可預測且難以檢查。

OpenAI Swarm 是最簡潔的——代理人之間進行輕量級交接。代理人 A 決定是時候輪到代理人 B 了，並轉移控制權。這很簡單，但卻是線性的。沒有並行處理，沒有樹狀結構，代理人無法啟動三個子任務並等待它們全部完成。

Claude 的工具使用循環——Anthropic 自己的模式——將單一代理人置於一個帶有工具的循環中。它能很好地處理序列複雜性，但在大型任務中會遇到上下文窗口限制，並且無法進行並行處理。一個代理人，一個線程，一個上下文。

共同點是：每個框架都要求開發者預先定義協調結構。你決定工作流程圖、代理人角色、交接模式。代理人在你的界限內執行。

當代理人不可靠時，這是有道理的。你絕不會讓 GPT-3 決定如何分解一個專案。但目前的模型在規劃方面表現出色。它們能自然地將問題分解為子問題。它們理解依賴關係。它們知道何時一個任務一次性無法完成。

那麼，為什麼我們仍然硬編碼分解呢？

一個代理人啟動。它讀取目標，決定在回答之前需要研究，並創建子任務：

沒有硬編碼的工作流程。代理人在運行時決定了這個結構。

它並行處理了 API 審核（#2）和 GraphQL 研究（#3）。它創建了一個提問節點（#4）——一個給人類的問題——因為它意識到建議取決於規模，這是它無法自行研究的。它將 #4 阻塞在 #2 上，因為有了審核結果作為上下文，這個問題更有意義。它將 #5 設為一個分叉，以便分析繼承所有學到的內容。它在分析之後對最終建議進行了排序。

研究並行運行。當兩者都完成並且你回答了問題後，分析將帶著所有三個結果的上下文啟動。它會產生一個針對你的實際規模和 API 表面量身定制的建議——而不是一個關於 GraphQL 的通用部落格文章。

這是我認為真正創新的想法：將 spawn 和 fork 作為上下文流原語的區別。

A spawned agent 獲得一個乾淨的開始。只有它的提示和它明確依賴的節點的結果。就像僱傭一個承包商——這是規格，去吧。容易重新啟動，容易理解。

A forked agent 獲得所有已完成的同級節點結果注入其上下文。就像向團隊成員簡報——他們知道團隊到目前為止學到的一切。成本更高，但對於建立在先前工作基礎上的分析是必要的。

這不是關於並行處理。兩者都可以並行或順序運行。這是關於子節點知道什麼。在上面的例子中，代理人選擇了 spawn 來處理獨立的研究任務，並選擇了 fork 來處理需要所有內容的分析。它做出了正確的選擇——因為工具描述清楚地解釋了區別。這就是重點：該協議可以僅從其介面學習。

自然而然的下一步是將上下文流作為一級原語——在 spawn/fork 上添加一個 context_query 參數，它接受自然語言指令，如「摘要」、「從網頁設計師的角度來看的相關細節」或「關於錯誤處理的要點」。一個壓縮子代理人將讀取父節點的完整上下文，根據查詢進行提煉，並僅將結果傳遞給子節點。這必須內建在客戶端本身——一個獨立的 MCP 工具無法在不將整個內容序列化為工具輸入的情況下訪問父節點的上下文，這就失去了意義。

每個代理人都是一個 Claude Code CLI 進程，其 MCP 工具由共享的 SQLite 資料庫支持：

代理人知道它們是協調樹中的一個節點——系統提示會告訴它們——但它們不管理它。它們看到工具並在需要時使用它們。協議——依賴關係解析、權威範圍界定、結果注入——由 MCP 伺服器強制執行。

當一個 ask 節點準備就緒時，引擎會暫停，在終端提示人類。答案將作為結果存儲，下游節點將解除阻塞。人類是樹的參與者，而不是觀察者。

在編寫運行時之前，我需要知道該協議是否可以僅從其介面學習。所以我建立了一個一次性的 MCP 伺服器，其中包含五個工具，將 Claude Code 指向它，並運行了 15 個測試。沒有運行時，沒有引擎——只有 Claude、工具和一個任務。

有趣的結果不是正確的工具調用。而是出現的行為。一個被要求分解專案的代理人在行動前調用了 read_tree()，並在之後再次調用以驗證——讀取、行動、驗證，未經提示。一個因試圖停止同級節點而被拒絕的代理人透過 ask parent 進行升級——這是正確的模式，但我從未描述過。一個遇到錯誤的代理人停止了失敗的子節點，並用調整過的提示重新啟動了一個新的子節點。

15/15 通過。通過率不是關鍵——而是清晰的工具描述加上依賴關係語義足以正確使用。這告訴我運行時是值得構建的。

此實現使用 Claude Code CLI 和 SQLite。但該協議——五個原語、依賴關係解析、權威範圍界定、兩階段生命週期——獨立於所有這些。

你可以將 Cord 實現為跨 Postgres 進行多機協調。直接透過 Claude API，無需 CLI 開銷。使用多個 LLM 提供商——GPT 用於廉價任務，Claude 用於複雜任務。對於某些節點，可以使用人類工作者。

該協議是貢獻。這個儲存庫是一個概念驗證。

你也可以將其指向一個規劃文檔：

根代理人讀取 markdown 並將其分解為協調樹。隨意編寫你的計劃——要點、章節、散文——代理人會找出任務結構、依賴關係和並行處理。