Holon 是什么，以及我为什么要做 Holon

做 Holon，源于我自己日常使用 AI Agent 时的几个真实痛点。

第一，希望 Agent 能主动一些，可以及时跟进任务的收尾。

现在一项任务，从方案设计到具体代码实现，AI Agent 大多都能做得挺不错了。但写完代码并不意味着事情就结束了，后面往往还跟着一连串杂事需要盯着：提交 PR 之后需要盯 CI 运行结果；Reviewer 提了反馈意见要及时修改；代码合并、服务部署之后，还要观察监控和日志，看看有没有问题。

目前的 Agent 大多是单次命令式的，跑完眼前这一步就停下了。如果这些后续链路都需要我人脑记着，过一会儿去刷一下页面，再把 CI 报错或者 Review 意见复制粘贴回终端让 Agent 改，那我其实就是一个忙碌的搬运工，在各种系统和 Agent 之间倒腾信息。

第二，我希望 Agent 可以像人一样，同时接受多项工作，但不要让我开太多窗口。

现在很多人习惯同时开好几个终端或 IDE 窗口并发跑 Agent。我也试过，但很快发现如果同时开多个窗口进行并行开发，窗口太多了后脑子会乱掉，严重影响深入思考。因为人类的注意力是单线程的，三四个窗口各自有不同的上下文和决策点，频繁在它们之间来回切换会让人非常疲惫。

所以我更希望的工作方式是：每天早上抽一两个小时，和 Agent 把方案讨论清楚，然后安排一系列任务给它，由它逐个去完成；如果中间某项任务遇到阻碍（比如等待 CI 运行、等待外部 Review），就先挂起切换到下一个任务；而我只需要定期去 review 它的进展。

虽然表面上看单任务推进比全并发的速度要慢一些，但只要它的连续性足够好，就能把人的注意力从无休止的多窗口切换中解脱出来。

第三，由于前两个需求，我需要管理远程长程运行的 Agent。

如果任务需要跨越较长时间等待和推进，Agent 的执行生命周期就必须和手上的设备解耦。我的台式机是 24 小时不关机的，我希望 Agent 直接常驻运行在台式机上，我的笔记本或手机只是远程连接的入口。这样不管我是去开会、出门在外还是晚上睡觉，都不影响 Agent 在后台继续工作。

Holon 是怎么设计的

Holon 主要就是围绕上面这三个需求来进行设计的：

首先，Holon 放弃了纯粹的 Session 模式，转向固定身份与专属工作区。

现在主流的 Agent 工具都是基于 Session 的，一次对话结束，上下文就扔了。但如果希望 Agent 成为长期的工作伙伴，它的习惯和职责就必须有地方沉淀下来。

在 Holon 中，每个 Agent 拥有一个固定的 ID 和专属的 AgentHome Workspace。它的工作规范（比如角色职责、权限范围、代码库约定）和长期记忆都维护在 AgentHome 里。这样你不需要每次开一个新对话，都对着输入框重复粘贴一大段人设和规则。

其次，Holon 引入了工作项（WorkItem）的概念。

一个工作项相当于 plan + todolist + 运行状态。对话流像是一条河，上下文窗口在这条河上滑动，而工作项像一条船，把目标、进展、证据和等待条件保存下来。

给 Agent 安排任务时，是以 WorkItem 为单位进行的。这样我才能一次性给它安排多个工作项。Agent 处理其中一个工作项时，如果遇到外部阻塞，就把这个工作项停在明确的状态上挂起，让出执行权去处理下一个就绪的工作项；等外部条件发生变化后，再恢复现场继续推进。

最后，Holon 采用 Server-Client 模式，用后台守护进程运行 Agent。

Agent 在后台 7x24 小时运转，提供 Web 端和手机端入口，同时内置了远程文件浏览能力。这不仅方便随时随地查看状态和介入确认，更重要的是提供了基于 Webhook 机制的事件驱动入口。外部系统的变化（比如 GitHub PR 的状态更新、CI 完成的通知）可以直接作为事件发送给 Holon，精准唤醒后台挂起的任务。

为什么不用已有的 Agent SDK 来搭建，而是从头开发？

有了上面的设想后，我也尝试过用一些现有的 Agent SDK 来搭建，但很快发现走不通。现在的 SDK 绝大部分都是围绕单次 Session 模式设计的，提供的扩展入口很有限，很难满足两个底层的系统要求：

第一，长期运行的 Agent，对上下文的压缩和筛选需要深度的自定义。

如果一个任务要跨越几天，期间经历多次工具调用、报错、等待和修改，以及工作项的切换，如果靠连续的压缩，上下文很容易腐坏。但工程任务中的上下文是有清晰层级结构的：命令输出、临时报错属于单步运行的短期上下文。但它会和 Workitem，Workspace 等中长期的对象产生关联，从而可以基于这些关联做筛选。如果底层框架只把输入看作平铺的聊天记录，就很难在上层灵活定制这种分层提取与动态压缩逻辑。

第二，WorkItem 的调度需要和 Agent 自身的调度机制紧密结合。

在 Holon 里，“等待”不是在单次会话里用代码 sleep 轮询，而是像操作系统管理进程一样：当任务需要等待外部事件时，主动挂起（Suspend），调度器把执行权切给其他就绪的工作项；事件到达后，再由调度器重新唤醒（Resume）。现有 SDK 大多建立在阻塞式的调用链上，如果只在外面包一层松散的脚本，根本做不到调度器与执行现场的深度协同。

因此，我决定直接从运行时本身从头开发，把 Agent 身份、WorkItem 状态机、事件驱动和调度器打通。

现在开发到什么程度了

现在最开始的目标基本已经达到了。经过几个月的打磨，我自己台式机上已经积累了 30G 的数据、跑着 40 个左右的 Agent，整体稳定性和可用性感觉已经可以拿出来和大家分享了。

下面是我和一个小的 Agent 开发小组协作的例子：

我每天早上花一两个小时，针对近期的需求和 Dev Agent 讨论清楚方案。方案对齐后，拆分成几个 WorkItem 扔给它。

随后我就可以去做别的事。Dev Agent 在后台按顺序拉起工作项，在干净独立的 workspace 或 Git worktree 里读代码、写实现、跑测试，然后提交 PR，并跟进 PR 的 CI 和反馈。

另外一个 Reviewer Agent 会监听 GitHub 的 PR 事件，及时 review，验证。比较复杂的 PR 还会邀请 GitHub Copilot 一起 review，最后通过后合并。这里有篇博客，记录了用 Holon 搭建常驻 Reviewer 的实践《不止审一次代码：用 Holon 搭建持续跟进 PR 的 Reviewer》。

还有一个 HolonOps Agent，会监听仓库的变化，来及时更新本机的 holon 进行真实环境验证，确认 Bug 是否修复，以及定时监控发现异常后提交 Bug。

我也把 Holon 部署给了我做技术支持的一个小团队，支持了 OIDC，作为团队共享的 Agent 平台。

每个人本地写代码依然用各自顺手的 AI 工具，共享 Agent 主要负责自动化内部协作：线上日志报错了，Agent 先排查并整理成 Issue，方便开发者接手；修复合并后，也是它继续盯部署和验收清单，最后再由人做真机确认。它替团队省掉了很多“这事后来谁在跟”的群里追问。详细实践见《从个人 AI 工具到团队协作：一个小团队的 Agent Native 实践》。

下一步与一些想法

Holon 做到了现在，从一个满足自用的小玩具，变成了我每天都在用的主力系统。但它离成熟的通用工具还有不少距离。

比如任务跨越更长时间时，调度系统如何更智能地根据任务语义唤醒和切换（这也是我最近在用 Jev 尝试的方向）；多个专职 Agent 之间如何像真实团队成员一样低摩擦地协作；以及怎样提供更平易近人的客户端，而不是像现在这样偏向开发者自建的后台服务。

我会持续把 Holon 迭代下去。虽然我一直关注 Agent 生态，但一个人的视野毕竟有限，很需要有类似痛点、或者在探索 Agent 长期工作流的朋友一起来用用看。如果你对这种长驻、异步、由工作项驱动的 Agent 感兴趣，非常欢迎体验并给我反馈。

Holon 的源码在 GitHub（holon-run/holon），官网和文档见 holon.run，后续进展我也会在 X（@holonrun）上同步。

可以在 X（Twitter，@jolestar）私信或回复我，也可以通过 Telegram（@jolestar）、微信（jolestar2）找我交流。