Ruflo：Agent = Model + Harness

在多智能体框架层出不穷的当下，Ruflo（原 Claude Flow）提供了一个值得注意的视角：它不造模型，也不替代 Claude Code 或 Codex，而是做harness（脚手架/执行层）——用项目自己的话说：“模型负责写，harness 提供工具、记忆、循环、沙箱和控制，让 agent 真正能干活。”

Ruflo 由 rUv（ruv.io）开发，TypeScript 编写，MIT 协议，当前 72,111 Stars，版本迭代极快（v3.41.2 发布于 2026-09-10）。它宣称一个 npx ruflo init 就能给 Claude Code 装上"神经系统"：agent 自组织成 swarm（群体）、从每个任务中学习、跨会话记忆，并通过联邦机制与其它机器上的 agent 安全协作。

核心判断

Ruflo 的价值主张可以浓缩成一张系统地图：

用户 → Ruflo (CLI/MCP) → Router → Swarm → Agents → Memory → LLM 供应商
                        ^                           |
                        +------ 学习闭环 <-----------+

这条链路上，Ruflo 补齐了裸用 Claude Code 时缺的三块：

1. 群体编排：98 个专职 agent（v3.41 的 CLI 路径）组成 swarm，按任务自动路由分工，而非单 agent 串行。
2. 自学习记忆：agent 从成功模式中学习，记忆跨会话持久化。
3. 联邦通信：v3.41.0 引入 Open Swarm Federation，不同机器上的 agent 可以加入联邦、通过 channel 协作而不泄露本机数据。

值得注意的工程细节是 v3.41.2 的修复：claims reducer 遵循 ttlSeconds——过期的资源租约会被释放。这说明其多机协调机制已经细化到租约 TTL 级别，不是玩具项目的手笔。

双安装路径：一个容易踩的坑

README 用一张表明确区分两条安装路径，这是实际使用者最容易困惑的地方（官方 issue #1744）：

官方建议很直白：想试单个插件的命令，走插件路径；要"文档里写的一切都能用"，走 CLI 路径。两者的工具命名空间也不同——插件路径下 MCP 工具名为 mcp__plugin_ruflo-core_ruflo__*，CLI 路径才是裸的 memory_store / swarm_init / agent_spawn。

插件体系

CLI 全量安装之外，Ruflo 提供 35 个按需安装的插件，覆盖五类场景：

• 编排：swarm 协同、autopilot 自主循环、定时后台 worker、可复用 workflow、跨机联邦
• 记忆：agentdb 向量库、RAG 记忆（混合检索 + 图跳数 + 多样性排序）、会话记忆快照恢复、知识图谱
• 学习：从历史成功任务中学习、子线性图推理（PageRank、增量更新）、目标拆解
• 代码质量：测试自动生成、Playwright 浏览器自动化、git diff 风险评分
• 本地模型：通过 Ollama 跑本地 LLM 并智能路由

安装方式如 /plugin install ruflo-swarm@ruflo，配合插件市场命令即可。

适用边界

• 适合：已经重度使用 Claude Code / Codex，想让多任务并行化、需要持久记忆或跨机器协作的重度 agentic 工作流用户；愿意接受工作区被注入配置文件（.claude/ 等）的团队。
• 需要警惕的：314 个 MCP 工具、26 个 CLI 命令、35 个插件的表面积极大，官方自己也承认这是上手门槛（README 明确说"你不需要学完 314 个工具，init 之后正常用 Claude Code 即可，hooks 会自动路由"）；此外 stars 增长与宣传话术（“8.1M+ ecosystem downloads”）建议以实际体验为准。
• 不适合：只想轻量增强单一会话的用户（一个 .claude/commands 文件就够了）；对工作区零侵入有洁癖的场景。

结语

Ruflo 把"多 agent 协作"从框架层的概念演示推进到了工程可用层：租约 TTL、记忆索引保护、daemon 许可机制这些 release note 里的细节，说明它在与真实的并发与安全问题搏斗。如果你正考虑把单 agent 工作流升级为群体协作，它的双路径安装设计（插件试水 → CLI 全量）也提供了低成本的验证方式。