都在做 Agent，到底谁在做 Harness？
最近一直在琢磨一件事：能不能自己做个 Agent 的运行底座？
模型已经这么强了，围着它把工具、上下文和执行流程组织好，让它真正干活，这件事听起来就很适合后端程序员。
然后开始看项目。
看到了 Pi，又看到了各种个人 AI 助手，再去看 Muse 的执行流程。项目越看越多，问题也跟着变了：大家好像都需要这层东西，那我想做的，到底是哪一层？
尤其看 Muse 那张图的时候，很容易冒出一个直觉：是不是把 Agent 放到云电脑里，外面再加一圈权限控制，就能变成私人助理？
如果只看箭头，确实挺像那么回事。
可惜，架构图里的箭头一般不负责值班。
先把这几个名字放回各自的位置
先说 Harness。这个词看着有点陌生，做的事倒不全是新问题。
你让助手整理周报，它得知道去哪里找提交记录，调用工具把数据取回来，再判断资料够不够。缺了东西就继续查，齐了就开始写。
模型负责判断下一步，外面的程序负责准备上下文、接住工具调用、执行并收回结果，让这个循环继续下去。运行到哪一步、哪些调用还在等，也需要管理。
可以先把 Harness 理解到这里。长期记忆、审批、定时任务要不要放进来，做到什么程度，各个项目有自己的选择。
Pi的选择比较明确：核心保持精简，留出扩展空间。它既有 coding CLI，也提供 SDK 和 RPC 接入。想把一个运行核心接进自己的东西里，这类项目值得仔细看。
但再看 OpenClaw，关注点就变了。它把 Gateway、聊天渠道、工具、会话和记忆组织成一套个人助手，用户可以直接拿来用，也可以自己部署和扩展。
这就解释了为什么项目看多了会混：我们把“一个能嵌进去的运行核心”和“一套已经能使用的助手”，放在同一排比较了。
它们当然有交集。不过，能改源码、能装插件、能作为 SDK 接入，得分别看。开源仓库里有代码，不代表每一块都适合拆下来当积木。
使用 Harness、提供 Harness、做完整助手，是可以同时存在的几件事。做产品的人完全可以复用底座，再去处理身份、渠道、权限和交互。每家公司都需要数据库，也没见大家上来先写一个 MySQL。
再把几个开源项目摆在一起看
有了这层区分，比较项目时就可以同时看它提供了哪些能力，以及自己还要补哪一层。模型接口、运行核心、用户入口分别落在哪里，往往比“支持多少功能”更能帮助判断接入成本。
概念分层，不表示任何具体产品依赖 Pi；Pi 仅作为 coding harness 的例子。
下面按 2026-10-08 读取的官方 README 与 LICENSE 整理。定位和功能来自项目自述，第二列是我建议继续阅读源码的位置；它不是性能排行，也没有包含恢复能力的实测评分。
| 项目与定位（官方 README 自述） | 可以重点看什么 | 许可证 / 官方文件 |
|---|---|---|
| OpenClaw：多渠道个人助手 | Gateway 怎样连接聊天渠道和会话 | MIT |
| Hermes Agent：个人 Agent | 跨会话记忆、技能积累与定时任务 | MIT |
| nanobot：Python 个人助理框架 | 小型执行循环怎样接工具、记忆和渠道 | MIT |
| NanoClaw：容器化个人助手 | 会话容器和挂载目录怎样安排 | MIT |
| ZeroClaw：Rust 个人助理运行时 | 模型提供方、渠道和工具怎样替换 | 仓库提供 MIT 与 Apache-2.0 文件 |
这些项目覆盖的产品层各有取舍。nanobot 自称个人 Agent 框架，ZeroClaw 强调个人助理运行时，把它们放进清单，是为了比较运行和接入方式；不能由此推导出它们已经替你完成全部产品工作。
选择时可以顺着一次请求找：谁收消息，谁组织上下文，谁执行工具，谁保存任务进度，谁在重启后决定继续。再看这些边界能否接进自己的系统。README 提供的是入口，代码和任务验证才能回答后面的具体问题。
图上多一层 代码里可不止一层
再回头看 Muse，就容易看出一些之前忽略的地方。
Meta 的公开说明里，Hatch 是 Muse 在代码中的内部名称，其 daemon 是核心 Harness，运行在用户专属云 VM 的隔离环境里。连接器操作和网络出口交给独立的 Sentinel 判断权限，主 Agent 接触不到真实凭据。
依据 Meta 公开资料整理的简化示意，非完整官方架构
所以“加一层权限”可以描述图上的位置，却省略了不少工作：执行部分被网页里的恶意指令带偏以后，谁还能拦住它？凭据由谁保存？它能不能绕过检查直接出去？
这些边界，光靠提示词里的一句“请谨慎操作”，显然不够让人睡得踏实。
云电脑也是类似。它给助手一个放文件、跑工具的环境，方便后台做事。至于模型在哪里推理，是另外一个部署问题，不能看到“每人一台 VM”就理解成“每人一份模型”。
名字越来越多，后端程序员的老问题一个没少。
接口超时怎么办？进程重启后任务还在不在？邮件发送没拿到回执，到底是没发，还是发了但不知道？
最后这个尤其要命。助手很积极，重试也很积极，收件人突然收到三份周报。工作量没变，存在感先翻倍了。
所以涉及发送、提交这类操作，得先核实状态，再决定重试还是请人处理。有幂等能力的接口就用起来。恢复和重试也都要实际验，不能因为项目名字里有 Agent，就默认这些问题已经解决。
本文建议的可靠执行流程，不代表表中项目均已实现，也没有把它当作故障实测结论。
可以先把状态分清：动作前保存 pending，取得成功回执后保存结果并确认完成；超时后记为 unknown，先只读查询实际状态。只有确认动作未发生，且权限与重试条件仍满足，才考虑重新执行。查询后仍然未知，就停止并交人工。
安全配置同样如此。OpenClaw 的安全文档要和默认值一起读：主会话工具默认在宿主机运行，沙箱需要配置。审批和隔离解决的是不同问题，一个确认按钮承担不了整套安全设计。
那个人开发者还能做点什么
绕了一圈，最开始那个问题还在：底座值不值得自己做？
现在至少可以把问题问得小一点。到底是现有方案接不上自己的业务，还是它在某类任务里总恢复不好？又或者，缺的只是一个合适的入口，根本没必要动运行核心？
拿一个任务试，比继续收藏十个项目更容易找到答案。
比如就做周报整理。先用现成方案跑通，再故意让接口超时一次，让资料缺一项，中途重启一下。看看它会在哪里卡住，能不能接着做，会不会重复操作。
同时记下几个朴素的数字：成功了几次、需要人工救场几次、中断后恢复了几次，以及每次到底花多少钱。比较方案时尽量用相同的任务、模型和权限，免得最后把模型升级的功劳算到底座头上。
如果同一个坑在多个场景里反复出现，填上以后确实省事，再考虑把它抽成通用能力。要是问题只发生在某个业务里，留在应用层也没什么不好。
先让一份周报在超时之后还能好好交出来。做到这一步，再聊“支撑所有 Agent”，话里会多一些底气。
