Ruflo：给 Claude Code 装一个神经系统，让 100 个 Agent 自动协作

仓库：ruvnet/ruflo

语言：TypeScript + Rust

Trending：406 stars/day

协议：MIT

一句话

Ruflo 不是另一个 coding agent，而是一个"agent 元框架"——它把 Claude Code 变成一个可以自我组织、自我学习、跨机器协作的 swarm 平台。

场景开篇

你让 Claude Code 帮你重构一个模块。它读了 10 个文件，改了 3 个，跑了测试，发现 2 个失败，修了 1 个，又发现新的依赖问题……最后你盯着它跑了 40 分钟，改了 20 个文件，其中 3 个改错了。

问题不是 Claude Code 不够聪明。问题是一个 agent 同时做太多事：读代码、改代码、跑测试、修 bug、管理依赖。每个任务都需要不同的上下文，但一个 agent 只有一个上下文窗口。

Ruflo 的作者 Reuven Cohen（rUv）的思路是：不要让一个 agent 做所有事，而是让 100 个专业 agent 各做各的，自动协调。

Agent = Model + Harness

Ruflo 的核心定义是：

Agent = Model + Harness

模型负责"写"（生成代码、回答问题），harness 负责"让模型能工作"（提供工具、记忆、循环、沙箱、控制）。

这个定义本身不新。新的是 Ruflo 对 harness 的实现：它不是给一个 agent 提供 harness，而是给一群 agent 提供 harness。

传统 coding agent 的架构是：

用户 → Claude Code → LLM

Ruflo 的架构是：

用户 → Ruflo (CLI/MCP) → Router → Swarm → Agents → Memory → LLM providers

中间多了 Router、Swarm、Memory 三层。每一层都解决一个单 agent 无法解决的问题。

Router：任务分解器

Router 做的事是：把一个用户请求拆成多个子任务，分发给不同的 agent。

你说"重构这个模块的认证逻辑"，Router 会把它拆成： 1. Agent A：读取当前认证代码，输出结构化摘要 2. Agent B：分析依赖关系，找出受影响的文件 3. Agent C：设计新的认证架构 4. Agent D：实现代码变更 5. Agent E：跑测试，验证结果

每个 agent 只做它擅长的事，上下文窗口不用塞所有信息。

关键点是：Router 不是 LLM。它是一个基于规则的调度器，用配置文件定义"什么任务应该分给什么 agent"。这比让 LLM 自己决定调度更可靠——LLM 会幻觉，规则不会。

Swarm：自组织协调

Swarm 是 Ruflo 最有野心的部分。它不是简单的任务队列，而是一个自组织的 agent 网络。

传统多 agent 系统的做法是：有一个中央调度器，决定每个 agent 做什么。问题是调度器本身成为瓶颈——它需要理解所有 agent 的状态，做全局优化。

Ruflo 的做法更接近蚁群算法：每个 agent 只看局部信息，通过共享的 Memory 层间接协调。Agent A 完成任务后把结果写入 Memory，Agent B 从 Memory 读到它需要的信息，自动开始下一步。没有中央调度器，但整体行为看起来是协调的。

这和微服务架构的思路一致：不要做一个上帝调度器，而是让每个服务通过共享状态自组织。

Memory：跨会话学习

Ruflo 的 Memory 层不只是"对话历史"。它是一个向量数据库，存储的是 agent 从每次任务中学到的经验。

具体来说：

• 每次任务完成后，agent 把"什么操作成功了"、"什么操作失败了"写入 Memory
• Memory 用向量检索找到相似的历史经验
• 下次遇到类似任务时，Router 会参考 Memory 里的经验做调度

但这里有一个设计选择值得注意：Ruflo 的 Memory 不是简单的"成功经验复制"。它用的是对比学习（contrastive learning）——同时学习"什么有效"和"什么无效"，用两者的差异作为信号。

这比只学成功案例更鲁棒。因为成功路径可能有很多条（你不知道是哪一步导致了成功），但失败路径通常更明确（某个具体操作导致了错误）。

Federation：跨机器协作

Ruflo 支持一个看起来过度设计的功能：federation——不同机器上的 agent 可以互相通信。

为什么需要这个？

想象一个场景：你的团队有 3 个开发者，各自在本地跑 Ruflo。开发者 A 的 agent 学到了一个解决某类 bug 的好方法，开发者 B 的 agent 遇到了同样的 bug。

如果没有 federation，B 的 agent 要从头摸索。有了 federation，B 的 agent 可以从 A 的 Memory 里检索到相关经验，直接复用。

这本质上是分布式学习——每个开发者的 agent 是一个节点，federation 让它们共享学习成果。和联邦学习（federated learning）的思路类似，但应用在 agent 层面而不是模型训练层面。

MCP 集成：不绑定 Claude Code

Ruflo 不只是 Claude Code 的插件。它同时支持 MCP（Model Context Protocol），意味着你可以用它连接任何支持 MCP 的客户端——Codex、Cursor、甚至自建的 agent 框架。

这是一个关键的设计选择：Ruflo 不绑定 Claude Code。如果明天 Anthropic 关了 Claude Code，或者你换到另一个 coding agent，Ruflo 的 Memory 和 Swarm 层仍然可用。

这和 ECC（另一个 agent harness）的思路不同。ECC 深度绑定 Claude Code 的 hook 系统，是"Claude Code 的优化层"。Ruflo 是"任何 coding agent 的协调层"。

314 个 MCP 工具的问题

Ruflo 暴露了 314 个 MCP 工具和 26 个 CLI 命令。这个数字看起来吓人，但 Ruflo 的 README 有一句关键说明：

"New to Ruflo? You don't need to learn 314 MCP tools or 26 CLI commands. After init, just use Claude Code normally — the hooks system automatically routes tasks, learns from successful patterns, and coordinates agents in the background."

这是一个重要的设计理念：复杂性应该被封装，而不是暴露给用户。用户不需要知道有 314 个工具，只需要正常使用 Claude Code。Ruflo 在后台自动路由任务、协调 agent、更新 Memory。

这和 Unix 哲学相反——Unix 说"每个工具做一件事，做好"，但暴露所有复杂性给用户。Ruflo 说"后台有很多工具，但你不需要知道它们存在"。

哪种更好？取决于用户画像。高级用户喜欢 Unix 的透明性，普通用户喜欢 Ruflo 的封装性。

ruOS Desktop：从 CLI 到操作系统

Ruflo 还有一个 ruOS Desktop 组件，可以连接 ChatGPT 或 Claude via MCP。这把 Ruflo 从"CLI 工具"提升到"AI 操作系统"层面。

ruOS 的定位是：不是另一个 IDE，而是 agent 的运行环境。你可以在 ruOS 里管理多个 agent 会话、查看 Memory、监控 Swarm 状态、审批 agent 的操作。

这和 OpenCode 的桌面 App 思路一致：coding agent 正在从"终端工具"变成"开发环境"。但 Ruflo 走得更远——它不只是给一个 agent 做 GUI，而是给一群 agent 做一个"控制中心"。

一个根本性的问题

Ruflo 代表了一种思路：单 agent 不够，需要 swarm。但这个思路本身值得质疑。

如果 Claude Code 3.0 的上下文窗口扩大到 100M token，能同时处理整个 codebase 的上下文，还需要 swarm 吗？如果模型本身足够强，能在一个会话里完成所有任务，还需要 Router 来分解任务吗？

Ruflo 的隐含假设是：模型的局部能力会持续强于全局能力。即不管模型多大，让它专注做一件事总比让它同时做很多事效果好。

这个假设目前成立——即使 GPT-5 有 100M 上下文，在长程任务上仍然会"忘记"中间步骤。但如果模型能力继续提升，swarm 架构的优势可能会缩小。

Ruflo 的赌注是：模型会变强，但任务的复杂性会增长得更快。今天的一个"重构模块"任务，明天可能变成"重构模块 + 迁移到新框架 + 更新文档 + 跑兼容性测试"。任务复杂度的增长永远快于模型能力的增长。

这个赌注目前看起来是对的。

核心洞察：Ruflo 的 Router/Swarm/Memory 三层架构把"一个 agent 做所有事"变成"一群专业 agent 自组织协调"。Memory 层用对比学习实现跨会话经验积累，federation 让不同机器的 agent 共享学习成果。314 个工具被封装在 hooks 系统后面，用户只需正常使用 Claude Code——复杂性被隐藏，不是被消除。