午夜咖啡午夜咖啡

jolestar 的文章与笔记。

Post

holon v0.14.1：Rust 重写，自举开发

2026-05-24Post

用 Rust 完整重写了 holon 的底层 Agent 循环，引入 Workitem、AGENT_HOME 和事件驱动架构，实现了自举开发——holon 的开发已经完全由 holon 自己进行。

cover

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 的任务是给 ExecCommand 加 duplicate_policy，让等价的活跃 command_task 默认复用而非重复启动。结果 Holon 被选为正式 PR：

指标HolonCodex
输入 token11.33M12.73M
输出 token48.3K73.1K
工具调用159218
变更文件99
GitHub CI✅✅
PR#1266#1265

选 Holon 的理由：diff 更聚焦（没碰不相关的 RFC 文件）、保留了已有的回归测试（Codex 重写了它）、token 和工具调用成本更低。

没赢的一轮：#1261 MemorySearch 任务回执发现

#1261 的任务是为 MemorySearch 加入压缩后的任务记录索引，并让搜索结果中的 task:<id> 能通过 MemoryGet 取到。这一轮 Holon 在 token 效率上优势更夸张，但最终 Codex 胜出：

指标HolonCodex
输入 token4.61M16.66M
输出 token23.0K60.2K
工具调用71151
变更文件23
GitHub CI✅✅
PR#1268#1267

Holon 用了不到 Codex 三分之一的时间和 token，但漏了一个关键点：没改 MemoryGet 的 tool 层。底层的 get_memory() 能处理 task:<id>，但 Agent 实际调用的 MemoryGet 工具入口没放行，导致从搜索结果里拿到了 task:<id> 引用却取不出来。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。

安装（二选一）：

# Homebrew（macOS）
brew install holon
# 或者 Cargo
cargo install holon

启动：holon daemon start 拉起守护进程，然后 holon tui 进入终端界面。欢迎试用，反馈直接提 issue，holon-reviewer 会处理。