摘要
1) 一句话总结
Cord是一个轻量级的多智能体框架，通过提供五个核心工具原语，允许AI智能体在运行时根据目标自主构建、拆分和协调动态任务树，打破了传统框架需预先硬编码工作流的局限。
2) 核心要点
- 现有框架的局限：LangGraph、CrewAI、AutoGen和OpenAI Swarm等现有框架均要求开发者预先定义静态的协调结构（如状态机图、角色或线性交接），无法充分利用现代大模型自然的动态规划能力。
- 自主构建任务树：开发者只需提供最终目标或规划文档，Cord智能体即可在运行时自主决定任务的拆分方式、并行逻辑以及节点间的依赖关系。
- 核心上下文原语：
- Spawn（派生）：创建“白纸”子任务，仅包含提示词和明确依赖的结果，重启成本低。
- Fork（分支）：创建继承所有已完成兄弟节点上下文的子任务，适用于需要汇总前期工作的分析任务。
- 人机协作机制：智能体可创建“提问节点”（
ask），在需要人类决策或提供信息时暂停引擎并在终端提示，使人类成为任务树的直接参与者。 - 极简的底层架构：当前系统约500行Python代码，基于Claude Code CLI和共享SQLite数据库，通过MCP（模型上下文协议）服务器强制执行依赖解析和权限范围。
- 五个核心工具：智能体通过调用
spawn、fork、ask、complete和read_tree这五个MCP工具来操作和感知任务树。 - 行为测试验证：在15个接口测试中，模型仅凭工具描述即可100%正确使用，并自发涌现出“读取-行动-验证”、向上级升级问题以及错误重试等高级行为。
- 协议的通用性：Cord的核心协议（五个原语、依赖解析、两阶段生命周期）独立于具体技术，未来可扩展至Postgres多机协调、直接调用API或混合多LLM架构。
3) 风险与不足
- 项目成熟度：当前的开源仓库仅为一个概念验证（PoC），尚未实现生产级应用。
- 运行依赖：当前实现强依赖于 Claude Code CLI，且需要包含该功能的订阅支持。
- 上下文成本：
Fork（分支）操作会将所有已完成兄弟节点的结果注入上下文，执行成本较高。 - 上下文流转局限：目前尚未将上下文流转（如
context_query）作为一等原语内置到客户端中，孤立的MCP工具在不序列化整个上下文的情况下无法直接访问父节点的上下文。
正文
AI智能体擅长一次做好一件事。给Claude一个明确的任务，它能出色地完成。但真实的工作并非单一任务，而是一棵包含依赖关系、并行处理以及需要在节点间流转的上下文的任务树。
目前多智能体框架层出不穷，但它们都解决错了问题。
现有框架的局限性
LangGraph 将协调过程建模为状态机。你需要用Python定义节点和边，由开发者提前决定智能体如何交接工作。这对于固定的工作流来说很强大，但图是静态的。如果智能体在任务执行到一半时意识到工作应该以不同的方式拆分，那就无能为力了。开发者必须提前预判所有的拆分模式。
CrewAI 是基于角色的。你为智能体定义人设——“研究员”、“分析师”、“作家”——并为它们分配任务。这很直观，但角色是由开发者决定的，而不是由智能体自己发现的。一个三人团队无法自行决定它实际上需要五个人，或者“研究员”的工作应该拆分为两个并行轨道。
AutoGen 将智能体放入一个群聊中。它们通过相互交谈来协调。这很灵活，但缺乏结构：没有依赖追踪，没有权限范围界定，没有类型化的结果。协调是在对话中涌现的，这意味着它不可预测且难以审查。
OpenAI Swarm 是最极简的——智能体之间进行轻量级的交接。智能体A决定该由智能体B接手，并转移控制权。很简单，但是线性的。没有并行处理，没有树状结构，智能体也无法派生出三个子任务并等待它们全部完成。
Claude的工具调用循环（Anthropic自家的模式）将单个智能体放入带有工具的循环中。它能很好地处理顺序复杂性，但在处理大型任务时会遇到上下文窗口限制，并且无法并行化。一个智能体，一个线程，一个上下文。
共同点在于： 每个框架都要求开发者预先定义协调结构。你来决定工作流图、智能体角色和交接模式。智能体只能在你的边界内执行。
在智能体还不可靠的时候，这样做是有道理的。你绝不会让GPT-3来决定如何拆分一个项目。但目前的模型已经非常擅长规划了。它们能自然地将问题拆分为子问题，理解依赖关系，也知道什么时候一个任务太大而无法一次性完成。
那么，为什么我们还要硬编码任务的拆分过程呢？
让智能体自主构建任务树
我开发了 Cord。你只需给它一个目标：
启动一个智能体后，它会读取目标，判断在回答之前需要进行研究，并自行创建子任务。
没有任何工作流是硬编码的。智能体在运行时自行决定了这种结构。
它将API审计和GraphQL研究并行化处理。它创建了一个“提问节点”（向人类提问），因为它意识到最终的建议取决于规模，而这是它无法自行研究出来的。它将提问节点阻塞在API审计任务之后，因为有了审计结果作为上下文，这个问题才更有意义。它将分析任务设为一个“分支（fork）”，以便分析过程能继承目前学到的所有内容。最后，它将最终建议任务安排在分析任务之后。
然后你就可以看着它运行：
研究任务并行执行。当两者都完成并且你回答了问题后，分析任务就会带着这三个结果的上下文启动。它会根据你的实际规模和API情况生成量身定制的建议——而不是一篇关于GraphQL的通用博客文章。
Spawn（派生）与 Fork（分支）
我认为这是其中唯一真正全新的理念：将 spawn 和 fork 区分开来，作为上下文流转的基础原语。
- Spawn（派生）的智能体 获得的是一张白纸。只有它的提示词和它明确依赖的节点结果。就像雇佣一个外包人员——给你需求，去干吧。重启成本低，逻辑易于推理。
- Fork（分支）的智能体 会将所有已完成的兄弟节点的结果注入到它的上下文中。就像给团队成员做简报——他们知道团队目前学到的一切。成本更高，但对于需要基于前期工作进行的分析来说是必要的。
这与并发无关。两者都可以并行或顺序执行。它的核心在于子节点知道什么。在上面的例子中，智能体为独立的研究任务选择了 spawn，为需要所有信息的分析任务选择了 fork。它做出了正确的选择——因为工具描述清楚地解释了这两者的区别。这就是关键所在：这个协议仅凭其接口就是可学习的。
自然的下一步是将上下文流转作为一等原语——在 spawn/fork 上添加一个 context_query 参数，接受自然语言指令，如“总结”、“从网页设计师的角度提取相关细节”或“关于错误处理的要点”。一个压缩子智能体会读取父节点的完整上下文，根据查询进行提炼，并仅将结果传递给子节点。这必须内置在客户端本身中——一个孤立的MCP工具无法在不将整个上下文序列化为工具输入的情况下访问父节点的上下文，那样就失去了意义。
幕后机制
每个智能体都是一个 Claude Code CLI 进程，配备了由共享 SQLite 数据库支持的 MCP 工具：
spawn(goal, prompt, blocked_by)— 创建一个子任务fork(goal, prompt, blocked_by)— 创建一个继承上下文的子任务ask(question, options)— 向人类提问complete(result)— 标记自身已完成read_tree()— 查看完整的协调树
智能体知道自己是协调树中的一个节点（系统提示词告诉了它们），但它们不负责管理这棵树。它们只看到工具并按需使用。协议——依赖解析、权限范围界定、结果注入——由 MCP 服务器强制执行。
当一个提问节点准备就绪时，引擎会暂停，在终端中提示人类。答案作为结果存储，下游节点随之解除阻塞。人类是树中的参与者，而不仅仅是观察者。
整个系统大约500行Python代码，基于 SQLite + MCP。
行为测试作为设计验证
在编写运行时之前，我需要知道这个协议是否仅凭接口就能被学习。所以我构建了一个一次性的 MCP 服务器，包含这五个工具，让 Claude Code 对接它，并运行了15个测试。没有运行时，没有引擎——只有 Claude、工具和一个任务。
有趣的结果并不是正确的工具调用，而是涌现出的行为。一个被要求拆分项目的智能体在行动前调用了 read_tree()，行动后再次调用以进行验证——未经提示就实现了“读取、行动、验证”。一个试图停止兄弟节点但被拒绝的智能体，通过向父节点提问（ask parent）进行了升级处理——这是正确的模式，但我从未描述过。一个遇到错误的智能体停止了失败的子节点，并用调整后的提示词重新派生了一个新的子节点。
15个测试全部通过。通过率本身并不是最大的洞察——真正的洞察是，清晰的工具描述加上依赖语义，就足以让模型正确使用。这告诉我，这个运行时值得被构建出来。
Cord 的本质与未来
目前的实现使用了 Claude Code CLI 和 SQLite。但这个协议——五个原语、依赖解析、权限范围界定、两阶段生命周期——是独立于这些具体技术的。
你可以基于 Postgres 实现 Cord 以进行多机协调；可以直接基于 Claude API 实现以消除 CLI 的开销；可以结合多个 LLM 提供商——用 GPT 处理廉价任务，用 Claude 处理复杂任务；甚至可以让部分节点由人类工作者来完成。
这个协议才是真正的贡献。当前的仓库只是一个概念验证。
尝试使用
你也可以将它指向一个规划文档：
根智能体会读取 Markdown 文档并将其拆解为一棵协调树。你可以用任何方式编写你的计划——要点、段落、散文——智能体会自行弄清楚任务结构、依赖关系和并行逻辑。
注：需要 Claude Code CLI 及包含该功能的订阅。