H9Harness for Agent Harness：管住一群 Harness

OpenAI 有一个叫 Symphony 的编排规范，2026 年 3 月在 GitHub 上开源，4 月底官方又写了一篇文章介绍它。文章里有一个很朴素的观察：多数工程师同时能舒服管理的 Codex 会话，大概只有三到五个，再多，上下文切换就开始痛苦。

做 Yoda 之前我也卡在这里。Claude Code、Codex 各自已经是一个 harness，模型、工具、权限、记忆都装好了。可我同时开着好几个，我的脑子就成了它们之间唯一的调度器：哪个在跑，哪个卡住了，上周那个问题是在哪个会话里解决的。

管住一群 harness 的那一层，我叫它 Harness for Agent Harness。Yoda 的 README 开头写的就是 Harness for your Agent Workspace。

什么时候需要这一层

如果你只用一个客户端、一次只做一件事，前面几节就够用了。你的 CRUD 项目也许根本不需要几百个 Agent 并行，也不需要一个 Agent 连跑六个小时。出现下面这些情况，再往上加一层：

• —同时开着三个以上的会话，开始记不清谁在干嘛；
• —同一个需求，想让两个客户端各做一遍比一比；
• —一个任务要跑几个小时，中途你得离开电脑；
• —你总在翻聊天记录，找上一次的结论。

这一层要管的四件事

让每个任务有自己的位置

Yoda 管正在跑的那部分：32 种客户端在一个工作区里，每个任务可以开独立的 git worktree，compare、review、team 几种模式让多个客户端同时干活、互相审查、按角色分工。0.20.1 加了一个独立的 Agent 看板窗口，卡片直接显示每个 Agent 的终端画面，可以按状态和项目筛选。看板只观察、不接管，不会改动主窗口终端的尺寸。

Symphony 的思路是把 Linear 看板当作控制台：每个打开的工单有自己的 Agent 工作区，Agent 一直跑到工作完成，挂了或者卡住了就重启。人的动作从“写 prompt、触发”变成了“写工单、拖状态”。仓库里有一份 SPEC.md 和一个实验性的 Elixir 参考实现，README 给的第一个建议，就是把这份规范交给你常用的编码 Agent，让它用你选的语言实现一个。

我读 Cursor 在 2026 年初公开的两篇多 Agent 实验记录时，记下了一条很实用的经验：一个 Agent 行为诡异时，先查是不是给它塞了太多互相矛盾的目标。规划、派活、审查、合并全压在一个上下文里，人会摸鱼，Agent 会抽风。

让过去的工作重新可用

AI 编程里真正有价值的答案，经常已经出现过：一次故障排查、一条关键命令、一个架构取舍。可它们散在不同 Agent 的本地会话文件里，靠记忆和目录名很难找回来。

Ataru 就是为这个做的。它最早是 2025 年 12 月我做的一个 Claude Code 聊天记录查看器，后来长成了本地会话的检索内核加一个桌面应用，2026 年 8 月发到 0.41.6。它把 Claude、Codex 等来源的会话统一建索引，可以用关键词或自然语言找，在 Turn、Run、Session、Project 四种粒度之间切换，命中之后能回到原始会话和行号。默认离线运行，语义检索可选，没配或者超时就退回关键词检索。

这一层也会骗人。2026 年 10 月 31 日，在 Ataru 里搜“超越之旅”，返回 0 条，磁盘上却有 167 个会话包含这个词。索引其实停在了 8 月 29 日，状态却一直显示 ready。当天，检索 Skill 就加了一条规矩：0 命中、而且索引过期的时候，不准说“没有”，先补索引再搜。

谁来判断做对了

如果所有 Agent 都读同一段模糊需求，用同一种模型，给出同一种乐观答案，那只是把噪音放大。Yoda 的 review 模式本来就是一个客户端干活、另一个客户端审查。

Skill 也需要评测。Skill 会漂移，上个月好用的，这个月可能开始写死 localhost、漏掉注册步骤，或者在参考文件里越读越深。2026 年 4 月我给自己的 Skill 写过一个评测 harness：从真实发生过的失败里写出黄金场景，断言要生成哪些文件、哪些内容不能出现、哪些命令必须跑过；有场景失败，就派一个修复 Agent 去改 Skill 文件，跑、改、再跑，最多五轮。

最便宜的一道评测是 Stop Hook：Agent 一停，Hook 就检查，没过就继续。它简单直接，可验收条件写得太机械，就容易变成无限套娃；让一个裁判 Agent 结合上下文和证据来判断，更接近真实的组织。不管哪种，Agent 可以提出证据，但不能自己批准证据，批准权留在人手里。

保护人的注意力

并行的 Agent 越开越多以后，我才意识到，人的注意力同样是一种需要被调度的稀缺资源。这一层既要管 Agent 的上下文，也要保护人的上下文：任务状态集中在一处，完成通知送到桌面或手机，需要人拍板的节点放在最显眼的位置，其余过程尽量安静地跑。我给自己的 Claude Code 挂过一个最简单的 Stop Hook，任务一结束就推一条带声音的 macOS 通知。

Agent 在跑的时候，人最不该做的是刷短视频，那等于把验收一个复杂系统的上下文清空一次。这段时间应该拿去想判断、做验证、维护关系、照顾身体。

你在解哪个维度？

Harness engineering 这个词这一年很火，但不同的人在解不同的问题。鸭哥把它拆成三个维度：时间、空间、交互（A15 讲过）。下次有人跟你聊 harness，可以先问一句：你在解哪个维度？点开卡片，背面是我的做法。

前两个维度的难题，大多出在很复杂的系统里。对超级个体来说，最先撞上的通常是第三个：人管不过来。

我踩过的坑

• —把多开窗口当成多智能体。一个人同时开三台车，不叫车队，要有分工和不同的验收口径。
• —相信上层的状态灯。索引说 ready，未必是最新的。
• —只管现在，不管过去。没有会话检索，上周的结论只能靠记忆去翻。
• —上层越做越重。Yoda 自己也在做减法，0.20.3 把任务和会话合成了一个东西。
• —追求一个 session 永远不断。更可靠的长跑，是中断之后还能接上。