21 点过，我坐下来复盘白天在仓库里踩的那些坑。这些是我自己在研发里犯过的错。
手头的事其实很具体：给一个开源仓库做端到端测试，再叠一层自动研发。有了这些手段，怎么知道这个仓库的 Harness 设计得好不好、工程会不会腐化？
理想里我想设一个目标就走人。token 够了，就不用管它。公开产品里最接近的是 Claude Code 的 /goal：写一个完成条件，它自己一轮轮干。
这件事要跑很长时间的实验。Agent 会夯在那边等。你做错了，下一轮远远没有那么快。
Agent 一次都没成功闭环过，工作的上下文 Harness 就不健全。必须人带着干完一次，再谈抽象的长程目标。
从三种小事量起
评估 Harness，我认的入口就三件：总结架构、做一个小需求、查一个问题。
这三件都能当场看见结果。Agent 跑完，你知道它读了哪些文件、花了多久、吃了多少 token。一个简单需求为什么要花这么长时间，优化之前和优化之后对着同一组活比，多次实验把方差去掉。类型要覆盖这个仓库真实会遇到的，不能只挑会做的。
Benchmark 怎么设，要参考 Coding Agent 那些公开榜，把符合这个仓库合理范围的类型抽出来。SWE-bench 就是这种抽法：任务来自真实仓库的 issue，每条都绑在那个仓库当时的提交上。自己的题从自己仓库里抽，别把别人的题库整份搬过来。
长程任务要能看、能快失败
设一个目标然后走开，token 充足的时候特别诱人。可你面对的就是长程任务的观测和优化。我认为要让长程任务本身可以渐进式地被看见，Fast fail 快速失败，允许分布式去做。
夯住之后，账单先落在等待上。做错了再来一轮，间隔会拉得很长。
Anthropic 写过一篇 长程 Agent 的 Harness：只给一句很高的目标，前沿模型也会一次做太多，在窗口中间断掉。方向和我这边踩过的坑是同一类。我是自己放养过一次之后才认的。
一次都没闭环的时候
有个教训：不要一次性把目标说得过于抽象。
当 Agent 一次都没有成功完成过，它这个工作的上下文 Harness 其实是不健全的。「你必须带领他干完一次」，它才能够充分理解工作的方式。
一次都没有闭环的时候，要从简单、可拼凑的小任务开始。太复杂，你无法分布，人也无法验收，更无法规定质量好坏和那些边界 case。
人带着干一次，是把这件事怎么算做完第一次写进仓库里：测什么、失败了怎么停、日志落在哪。Agent 下一回才能顺着这些路灯走。路灯还没有的时候，给它一个抽象目标，等于让它在空房子里过夜。
先把能看见的铺上
我认为一个顶级的 Harness、一个顶级的工程，一定还是需要有工程师的，因为 AI 做不到。质量谁来定、边界 case 谁来带、防腐怎么做，复杂项目要完成一些事情，一定有这么一个逻辑。
测试层的目的是让开发变得更快。所以要有很多手段，低成本地收集核心反馈，更快打通链路。这是我比较认可的一件事。
未来做复杂项目，必须从数据层、可观测层、可回滚失败开始。把这一部分工具交代清楚：它能够验证，它能够看到过程。第一个是看结果，第二个是过程的效率优化。这两步都能做了，再基于任务系统把所有环节打通，把它做得更快、更好。
不要一上来就变得非常复杂。那样很难得到好结果。日常工作就是要循序渐进。
Building effective agents 里也有相近的话：先找最简单的方案，复杂度只在能证明改善结果时再加。那是后来对上的，不是我当晚推出来的。
下一圈先做一件能看见的
下一个还没做成过的仓库自动化，我先只挑一件能当场看见结果的小事。总结架构、改一个小需求、查一个具体问题，三选一。人坐在旁边带着 Agent 走完。
这一圈转完，再设大目标。
已经带着做成过、观测和回滚都在的仓库，可以加大目标。当场能验收的小改动不必再拆。人带着干一次，测试还是要的。质量还是工程师定。
参考
- SWE-bench（查阅 2026-09-21）— 公开 Coding Agent 榜从真实仓库 issue 抽出任务实例；自己的 Bench 要落在本仓库的合理范围。
- Effective harnesses for long-running agents（查阅 2026-09-21）— 只给高层目标时，长程 Agent 会一次做太多、在窗口中间断掉。
- Keep Claude working toward a goal（查阅 2026-09-21）—
/goal把完成条件交给会话去放养。 - Building effective agents（查阅 2026-09-21）— 先用最简单的方案，复杂度只在能证明改善结果时再加。
