--- title: holon v0.14.1：Rust 重写，自举开发 date: '2026-05-24' draft: false summary: 用 Rust 完整重写了 holon 的底层 Agent 循环，引入 Workitem、AGENT_HOME 和事件驱动架构，实现了自举开发——holon 的开发已经完全由 holon 自己进行。 tags: - ai-agent - holon - rust - open-source topics: - ai - software-engineering syndication: - platform: X / Twitter url: https://x.com/jolestar/status/2058410746447564865 type: post slug: holon-v0.14.1 --- ![cover](./cover.jpg) holon v0.14.1 发布了。当前 holon 的开发已经完全由 holon 自己进行——holon-pm 聊需求出 issue，holon-dev 写代码提 PR，holon-reviewer 审 PR 看 CI 决定合并，holon-ops 定期分析日志发现异常。我只需要在关键节点看一眼。 这个版本推迟了很久，因为我把 holon 用 Rust 重写了一遍，然后自己一直用，一直修 bug，直到把主要工作都迁移到 holon 上，没有太明显的 bug，才觉得可以放出来让大家试试。 ## 最初的想法：一条命令解决一个 issue holon 的起点很简单。去年我在 X 上发了一条推，描述了一个工作流：给 Agent 一个 GitHub issue，它自动理解需求、写代码、提交 PR。一条命令，一个 issue，一个 PR。 但真跑起来就发现不够。PR 提交之后，有 review comments，有 CI 失败，需要继续修。我不希望每次都要手动提醒 Agent——我期望它能自己监听 GitHub 事件，感知到 "review 给了 comments" 或者 "CI 挂了"，然后自己推动 issue → PR → merge 的整个闭环。 再进一步：如果能完成一个 issue，那把一组 issue 放进一个里程碑，它应该也能逐个推进。 于是 holon 增加了外部触发机制，增加了 serve 模式，折腾了几个版本，最终确定了当前的架构。这中间有几个关键的设计决策，我放在下面讲。 ## 为什么用 Rust 重写 第一版 holon 基于 Claude Code SDK。很快就碰到了天花板：调度策略、上下文管理、缓存策略——这些对 Agent 长期运行质量至关重要的东西，SDK 层不暴露接口。同时我也希望 holon 能用任意模型——Codex、GLM、DeepSeek 等，而不是绑定在 Anthropic 上。 所以这次用 Rust 从零写了底层的 Agent 循环。调度、缓存、上下文窗口管理这些逻辑现在都握在自己手里，也就可以针对不同模型做更细致的优化。 ## 几个关键设计决策 重写的过程中做了几个比较根本的取舍，它们不是孤立的，互相之间有因果关系。 ### 放弃内置外部集成，把 holon 变成可调用的基座 holon 不再内置各种外部事件接入——GitHub webhook、IM 消息、定时任务等等。holon 本身提供 API 和服务接口，外部集成通过其他工具配合完成。比如通过 AgentInbox 集成 GitHub 和各种 IM 服务，通过 uxc 统一接入外部工具链。 这样做的好处是：holon 基座保持稳定，TUI 以及未来的桌面 App 都通过接口来调用 holon，不需要反复改底层。 ### 单 session + Workitem：同一个上下文中管理多个任务 这两件事是一体两面。 holon 放弃了多 session 机制。因为有多个 Agent 之后，再叠加多 session，用户管理起来会非常复杂。同一个 Agent 只有一个持续进行的 session——无论从 TUI 端还是外部应用和它交互，都在同一个上下文里。 那怎么并行推进多个任务？引入了 Workitem 的概念。一个 Workitem = Plan + TODO list。一个 Agent 可以管理多个 Workitem：你一次性交代给 Agent 一系列任务，它逐个制定计划、迭代完成，但所有上下文共享同一个 session，不会碎片化。 这其实是 holon 区别于其他 Agent 工具的一个核心差异。大多数工具的思路是：一个任务开一个会话，做完就扔。holon 的思路是：Agent 是一个持续存在的协作者，它记住上下文，管理多个任务，你随时可以插话。 ### AGENT_HOME：Agent 的持久化身份 每个 Agent 有一个 AGENT_HOME，这是它自己的持久化目录——身份、记忆、本地技能都存在这里。AGENTS.md 是 Agent 的角色契约，定义了它的职责、权限、工作方式。 但 Agent 不能只活在自己的 home 里。用户给它一个项目目录，它就进入那个项目工作。holon 把这个关系抽象成了 Workspace：Agent 的 AGENTS.md 定义"我是谁"，项目里的 AGENTS.md 定义"在这个项目里怎么干活"。Agent 可以绑定多个项目目录，在它们之间切换，但工具调用始终以当前 Workspace 为基准，不会因为某个命令里 `cd` 了一下就跑偏。 这个设计让 Agent 既保持独立身份，又能参与多个项目。不是一次性工具，而是有自己家、能去不同项目干活的长期协作者。 ### 事件驱动：休眠，而不是轮询 每个 Agent 有一个接口直接接收 Operator 消息，也有一个 webhook 事件接口用于唤醒通知（GitHub 事件、IM 消息等）。每个 Agent 还有一个 event stream 接口，输出 events，TUI 可以连接上去展示 Agent 当前的活动，也支持远程连接。 这意味着 Agent 不需要轮询——它正常处于休眠状态，有事件时被唤醒，处理完继续休眠。这既是资源效率的考量，也更贴近"协作者"的隐喻：不需要的时候不打扰你，有事的时候自己干活。 ## 一个真实的工作流 说了这么多设计，不如看一个具体的工作流。当前 holon 项目的日常开发是这样的： - **holon-pm**：我在 TUI 里跟它聊需求方案。它把方案整理成 issue，归类到对应的里程碑。 - **holon-dev**：追踪里程碑里的 issue，自动切换到 worktree，写代码，提交 PR。然后订阅 PR 的 review 和 CI 事件，CI 挂了或有人提了 comments，它自动修复。 - **holon-reviewer**：监听到新 PR，自动跟踪 CI 状态和 review comments，评估是否可以合并，能合并就合并，同时对 issue 做归类整理。 - **holon-ops**：定时分析 holon 中的 Agent 日志，发现异常问题自动建 issue，灌回 holon-pm 的 backlog。 整个过程我只需要在关键节点看一眼——PR 太复杂了审一下，合并前确认一下。其他时间 Agent 自己在跑。 ## 基准测试 自举开发跑了几周之后，我开始用真实 GitHub issue 做 benchmark，追踪 holon 在 token 效率、交付质量和稳定性上的变化。这里用最近的两轮说明当前状态：一轮 Holon 赢了，一轮没赢。两轮使用的对比模型都是 Codex 5.3 spark。 ### 赢了的一轮：#1257 ExecCommand 重复启动策略 [#1257](https://github.com/holon-run/holon/issues/1257) 的任务是给 `ExecCommand` 加 `duplicate_policy`，让等价的活跃 `command_task` 默认复用而非重复启动。结果 Holon 被选为正式 PR： | 指标 | Holon | Codex | |------|-------|-------| | 输入 token | 11.33M | 12.73M | | 输出 token | 48.3K | 73.1K | | 工具调用 | 159 | 218 | | 变更文件 | 9 | 9 | | GitHub CI | ✅ | ✅ | | PR | [#1266](https://github.com/holon-run/holon/pull/1266) | [#1265](https://github.com/holon-run/holon/pull/1265) | 选 Holon 的理由：diff 更聚焦（没碰不相关的 RFC 文件）、保留了已有的回归测试（Codex 重写了它）、token 和工具调用成本更低。 ### 没赢的一轮：#1261 MemorySearch 任务回执发现 [#1261](https://github.com/holon-run/holon/issues/1261) 的任务是为 `MemorySearch` 加入压缩后的任务记录索引，并让搜索结果中的 `task:` 能通过 `MemoryGet` 取到。这一轮 Holon 在 token 效率上优势更夸张，但最终 Codex 胜出： | 指标 | Holon | Codex | |------|-------|-------| | 输入 token | 4.61M | 16.66M | | 输出 token | 23.0K | 60.2K | | 工具调用 | 71 | 151 | | 变更文件 | 2 | 3 | | GitHub CI | ✅ | ✅ | | PR | [#1268](https://github.com/holon-run/holon/pull/1268) | [#1267](https://github.com/holon-run/holon/pull/1267) | Holon 用了不到 Codex 三分之一的时间和 token，但漏了一个关键点：**没改 `MemoryGet` 的 tool 层**。底层的 `get_memory()` 能处理 `task:`，但 Agent 实际调用的 `MemoryGet` 工具入口没放行，导致从搜索结果里拿到了 `task:` 引用却取不出来。Codex 的 PR 虽然贵得多，但覆盖了完整的接受标准。 ### 两条线说明的问题 这两轮基本概括了 Holon 当前的处境： - **好的方面**：token 效率优势已经稳定。增量续接命中率极高（#1261 缓存命中 3.96M/4.61M），结构化上下文管理进入稳态。#1257 证明 Holon 在保持 diff 质量和测试覆盖上的判断力不比 Codex 差。 - **需要继续修的地方**：多轮迭代中偶尔会丢失 issue 的某个约束——#1261 漏掉 `MemoryGet` 入口就是典型。这在 v0.14 后续版本中通过增强 WorkItem 的任务边界描述和接受标准跟踪来改进。 ## 边界和下一步 当前状态达到了我的工作流目标，但还有一些明确的短板： 1. **多 Agent 通信**：holon-pm / holon-dev / holon-reviewer / holon-ops 目前是通过 GitHub issue 和 PR 间接协作的——本质上还是靠外部系统做消息传递。Agent 之间直接的通信机制还没有。你让 holon-pm 直接告诉 holon-dev "这个需求优先级变了"，现在做不到，得手动去改 milestone。 2. **外部系统集成**：目前的集成方式是通过 AgentInbox 桥接，覆盖了 GitHub 和部分 IM。更多的外部系统（CI、监控、文档、项目管理）需要逐步接入。 3. **多模态**：Agent 现在还看不到界面。我调试前端的时候，仍然需要手动把错误输出贴给它。这块是下一步的重点方向之一。 ## 试试看 holon 是开源项目，代码在 [github.com/holon-run/holon](https://github.com/holon-run/holon)。 安装（二选一）： ```bash # Homebrew（macOS） brew install holon # 或者 Cargo cargo install holon ``` 启动：`holon daemon start` 拉起守护进程，然后 `holon tui` 进入终端界面。欢迎试用，反馈直接提 issue，holon-reviewer 会处理。