Agent跑6小时不跑偏，靠一张200项未完成清单

Kaiju 在 X 上整理了一份 Harness Engineering 的笔记，核心公式很短：Long-Running Harness = Short Sessions + State on Disk。长任务被拆成多个短会话，状态落在磁盘上。视频里给了完整拆解。

Anthropic 的测试里，agent 主要栽在两种行为上：一次建完所有东西；后来的会话看到一点进展，就宣布完成。Kaiju 在推文里说，Anthropic 用 3 页 PDF 把 OpenAI、Anthropic、LangChain 的公开做法收在一起，其中一条公式替换了 prompt engineering。

Harness 管 agent 能看见、触碰、检查的东西：会话启动文件、工具、权限、保存状态、输出检查。Codacy 的解释被 Kaiju 引用：harness engineering 决定 agent 能碰什么，以及什么在检查输出。

Kaiju 给出的五步 playbook：

先跑一个 initializer session，不写功能代码。
让它写 feature list，JSON 格式，200 条以上，每一条都标 passes 为 false。
加一个 progress 文件、一个 init.sh、第一次 git commit。
之后每个会话固定启动：pwd，读日志，挑一个失败功能，跑 smoke test。
建一个功能，在真实浏览器里测，commit，更新笔记。

OpenAI 报告同一套 harness 思路下，单 agent 能跑 6 小时以上。

看起来笨。多代理图像发布会，harness 像便利贴。Kaiju 的排序相反：harness、loop、graph。Harness 让一个会话可靠，loop 让会话收尾，graph 在两者成立后分担工作。LunarResearcher 的判断被引用：完美的 graph 救不了弱 harness。

Anthropic 的记忆实验更直接：并行 agent 写同一张共享表，只保住 57 条合同事实里的 41 条；每个 agent 一页，57 条全在。只改共享状态，属于 harness 工作。

判断顺序有三个问题：

新会话能不能几分钟接上昨天的工作？
能不能用一条命令证明 done？
任务是否需要多个 context window？

第一个 no 建 harness，第二个 no 建 loop，只有三个 yes 才配 graph。

复制粘贴层面，Kaiju 给了四件套：feature_list.json、init.sh、claude-progress.txt、CLAUDE.md。feature 每一条一开始都是 passes 为 false。Anthropic 选 JSON 的原因：模型比较不容易不恰当地改 JSON 文件。规则包括每个会话只做一个功能，只改 passes 字段，不能删测试，端到端检查跑过才能标 passing，结束要有 commit 和 3 到 5 行进度。

工具是请求，hook 才是保证。Kaiju 引用 Codacy 这句话，并建议在 .claude/settings.json 放 PostToolUse hook：Edit 或 Write 之后跑测试，失败就 exit 2。只有 exit 2 的错误会回传给 Claude。

Loop 用 /goal。条件要能测，要有 turn cap。例子：/goal 前 3 个 passes 为 false 的 feature 变成 true，每个都由 ./init.sh 和端到端检查验证，不能改测试文件，更新 claude-progress.txt，或者 25 轮后停。跑过夜时加 stream-json，否则终端看起来像卡死。

Graph 最后。先 subagents，再 teams，再 workflows。teams 建议 3 到 5 个 teammate，两个 agent 改同一个文件会覆盖。超过 25 个 agent 或 150 万 token 会出现 Large workflow 警告。

第一周可以这样排：Day 1 跑 initializer，砍掉 feature list 里含糊的条目。Day 2 手动跑三次会话，每次都读进度文件，以 commit 结束。Day 3 用 /goal，N 设为 1。Day 4 到 5 把 N 提到 3。Day 6 到 7 再决定要不要 review fan-out。一个 reviewer 够用，就别上 team。

最花钱的错误：第一天就上 team；goal 里没有数字；无人值守却停在 manual mode；让 agent 改测试；两个 agent 写一个文件。

Kaiju 的完整拆解在这条推文，长文在这里。