Holon 是一套可部署在个人电脑或团队服务器上的 Agent 工作台。它要解决的不是“怎么跟模型聊天”，而是：一件需要跨时间、跨事件、跨人跟进的工作，怎样在你关掉终端之后仍然接着做，并且随时能被看懂、被接手。
官网一句话是「为需要持续跟进的工作而建」。GitHub 上的定义更硬一点：Holon 本身不是 Agent，它是给多个 Agent 用的本地工作环境。Agent 负责理解目标和推进执行；Holon 负责把“工作”做成一等对象，保存状态、组织上下文、记录等待和唤醒，条件满足后再回到对应工作区继续，最后把结果交还给人。当前推荐版本是 v0.48.0，Apache-2.0，核心运行时用 Rust 写。
它在补哪一类产品空缺
现有 Agent 产品大多停在三种形态里。
聊天型产品以一次会话为边界。上下文、计划和“还在等什么”都埋在对话里，窗口一关，工作就断了。编码型产品（Claude Code、Cursor 这类）擅长在仓库里把一轮任务做完，但默认仍是人在场、会话驱动。自动化平台能定时、能 webhook，但流程是预先画好的图，Agent 的判断、记忆和临时分工塞不进去。
Holon 卡在这三者中间：工作要持续，但路径不能事先画死。邮件要等回复，订单异常要等仓库回传，PR 要等修复和 CI，故障调查要等日志和人的判断。这些事的共同结构是“做一步、等一个条件、再接着做”。产品把这个结构显式化了，而不是指望模型在下一次对话里自己想起来。
产品对象：工作从对话里拆出来
官网和概念文档把运行时收成四个对象，这是理解产品的最短路径。
| 对象 | 回答的问题 | 产品含义 |
|---|---|---|
| Agent | 谁在负责 | 长期身份。有自己的主目录、AGENTS.md、技能、记忆和工作队列，按 ID 寻址，可以睡、可以醒 |
| WorkItem | 在做什么 | 一项可持续的目标：计划、待办、进度、阻塞、等待条件、完成标准。跨会话、跨模型调用都还在 |
| Task | 怎么做的 | 一次可监督的执行：命令、后台操作、子 Agent。能看状态、读输出、送输入、停掉 |
| Trust / Origin | 信息从哪来 | 操作者输入、webhook、子 Agent 输出、网页内容各自带来源和信任级别，不压成一条无差别 prompt |
关系是：Agent 持有 WorkItem，WorkItem 通过 Task 推进，所有进入上下文的内容先过信任边界。
这套模型和聊天产品的差别很具体。你不必翻完整段 transcript 才知道做到哪一步；Agent 可以在你离开后继续；外部事件不会和你的指令混成同一种权威；子 Agent 的产出可以被监督，而不是直接当成事实。
WorkItem 的标准循环是：定目标 → 记进展 → 等变化 → 接着做 → 交结果。等待不是“对话卡住了”，而是显式的 WaitFor：等命令结果、等外部事件、等你的确认。条件满足就唤醒，回到原来的工作和工作区。
四块能力怎么拼成产品
持续跟进，而不是一轮问答。 后台 daemon 开着，Agent 就还在。TUI 断开、浏览器关掉，工作不重置。你从 Web（默认 http://localhost:7878）或 holon tui 回来，看到的是进度，不是一段需要重新解释的聊天记录。
事件和定时，是唤醒条件，不是另一套自动化。 Webhook 接外部系统，cron 做定时。工作中途也可以挂起，等回复、等 CI、等人工反馈，再从同一项 WorkItem 继续。产品承诺的连续性依赖一件现实条件：跑 Holon 的电脑或服务器，以及后台服务，必须开着。
职责和记忆绑在 Agent 上，不绑在这次对话上。 每个 Agent 单独配职责、Skills 和指令，记忆也各自保留。下次还是找同一个 Agent 处理它负责的事。这是“岗位”而不是“会话”：审阅的人、查故障的人、跟订单的人可以是不同 Agent。
多 Agent 是分工，不是群聊。 调查、审阅、测试可以拆给子 Agent 并行做，父级跟踪各项任务，收齐结果再推进整体工作。工作区按项目隔开文件和产物；编码任务可以用托管 worktree，避免直接在主工作区里改。
个人和团队走的是同一套运行时。部署到团队服务器后，成员可以向同一个 Agent 派任务、补反馈、沿已有进度继续。多个工作区用来分项目。
一条典型路径
从模板创建 Agent，写清职责，派第一项任务。然后按需要接 webhook 或定时。之后的日常不是重新开聊，而是三件事：看 WorkItem 到了哪一步、在需要时补一句判断、等它把结果交回来。
官网和博客把这条路径落在几个反复发生的场景上。
- 持续审 PR。用模板做出带规范的 Reviewer，订阅仓库 PR，审完后等修复和 CI，而不是每推一次就新开一轮对话。
- 邮件和订单异常。接系统事件，等对方回复或状态变化，再回到同一项工作。
- 设备故障调查。多个 Agent 分头查，结果汇回一项 WorkItem，人在关键节点介入。
- 仓库里的开发任务。Prompt 结束后 Agent 还在本地仓库、shell、worktree 里继续，你回来验收。
模型是外挂的。holon onboard 或 Web 设置里配 Provider，支持 Anthropic、OpenAI、DeepSeek、OpenRouter、Qwen、GLM、Xiaomi、Kimi、MiniMax 等。产品卖的是工作运行时，不卖模型。
安装路径也符合这个定位：brew tap holon-run/tap && brew install holon，然后 holon onboard、holon daemon start。也有 GitHub Release 二进制、macOS dmg（菜单栏应用和 CLI 共用同一个 daemon），以及 Docker。容器要配 control token，工作目录挂到 /workspace，当前发布镜像只支持 Linux amd64。
产品边界：它故意不是什么
官方把边界写得很清楚，这比功能列表更说明定位。
它是运行时、控制面、本地工作区执行层、任务编排层、事件驱动的睡醒系统。它不是聊天 UI，不是大而全的 Agent 平台，不是连接器市场，不是画流程图的自动化工具，也不是完整的 VM 或容器沙箱。
Agent 能用哪些文件和工具，取决于你的配置。它在真实本地环境里执行，不是默认隔离沙箱。这对开发机和内网服务器是优点，也意味着权限和信任边界要自己管。信任分级是产品机制，不是安全托管服务。
版本号还在 0.48，项目处于活跃开发，对象模型（WorkItem、WaitFor、trust）比界面完成度更值得看。Product Hunt 上 2026 年 9 月以 “AI agents that act and follow through” 发布，标签是 Developer Tools，免费、本地优先。
适合谁，不适合谁
适合已经有固定职责、而且这些职责不会在一轮对话里结束的人或小团队：要一个 Reviewer 长期盯仓库，要一个值班 Agent 接 webhook，要几个人共用同一台机器上的同一批 Agent，随时接手而不是重讲背景。
不太适合只想要一个聊天窗口、希望开箱即用的 SaaS 连接器、或者要求每次执行都在强隔离沙箱里的场景。它也不解决“电脑关机之后云端继续跑”；连续性的前提就是这台机器或这台服务器还开着。
一句话概括产品判断：Holon 把 Agent 从“会回答的会话”改成“有岗位、有工单、会等待、能被唤醒的本地同事”。差异化不在模型，而在 WorkItem、WaitFor 和信任边界这三件被做成了一等对象。