Capt Pascal

Remember the era of fancy prompt engineering? Do elaborate coding agent harnesses actually make agents better? We benchmarked popular coding setups on 100 real-world software engineering tasks using sudo L7. The results: ➡️ Best harness additions: +2–3 points ➡️ More thinking: +11.3 points! ➡️ One coding agent setup: 8× the cost, no improvement In one case, a harness spawned 17 agents to review a simple email change, and all 17 still missed a critical issue. Sometimes smarter thinking beats more agents.

HelloSurgeAI's tweet photo. Remember the era of fancy prompt engineering? Do elaborate coding agent harnesses actually make agents better?

We benchmarked popular coding setups on 100 real-world software engineering tasks using sudo L7.

The results:
➡️ Best harness additions: +2–3 points
➡️ More thinking: +11.3 points!
➡️ One coding agent setup: 8× the cost, no improvement

In one case, a harness spawned 17 agents to review a simple email change, and all 17 still missed a critical issue.

Sometimes smarter thinking beats more agents.

364

Capt Pascal

@CaptPascal

about 3 hours ago

@aiclaw404 哪有，两边都还在摸索

Capt Pascal

@CaptPascal

about 3 hours ago

@Kenny357zb +10086

Capt Pascal

@CaptPascal

about 14 hours ago

了解你的团队，比管住你的团队更前置。不管是人还是 agent，足够了解每位的特点和能力边界，设计和分配角色时就会更精准，很多问题在前面就避开了，用不着事后靠流程去补。

Capt Pascal

@CaptPascal

7 days ago

我想做一个自己好用的协作工具。起因很简单。我平时跟 Claude、Codex 一起干活，体感很好：交代清楚，它就去干，我睡觉了它也在干。我想要的，就是这种体验的多人版、多 agent 版。 Codex、Claude、Cursor、Grok、Grok Bot，各自带着自己的 harness，在同一个群里分工协作。有人执行，有人审核，有人 challenge。我负责定方向、定目标、验收结果。方案里写的定义是：关系感知的跨 harness 多主体协作系统。方案里有一句话，后来我反复想起：治理层不接管每个 agent 自己的 harness。接下来很长一段时间，版本一路往前推。每一阶段都有 closeout，有审计，有复核，有指纹。按计划，我本人正式上手验收，要排在所有阶段过关之后。当时我觉得这样挺对。东西要稳，要安全，要能恢复，这些都没错。按道理，一层层收口下来，这时候应该是它最稳的时候。可我第一次真的用它，交代了一件事，想着关掉页面，睡一觉，醒来结果就在那儿。结果它大概只干了 15 分钟就停了。查下来，工作流被写死成 900 秒，最多只允许纠正一次，碰到任何“需要人来决定”的地方就停下来等我。一个本来要在我睡觉时干活的工具，被自己的保护措施限成了只能干 15 分钟。没过几天，一个 Codex agent 在里面干活失败了。原因是我自己装的 MCP 工具被系统拒绝了。同一个 agent，单独用的时候好好的，放进来就用不了自己的工具。我让三个 AI 各自独立审了一遍，结论相对来说比较一致：这套系统里很多“安全”，是靠关掉 agent 本来就有的能力换来的。说好不接管 agent 自己的 harness，做出来恰恰接管了。而且真出事的时候，这么多层也没拦住。 10 月初，一个 agent 执行删除命令时，路径变量是空的。命令本来只想清空一个文件夹，结果删掉的是它当时所在的整个目录。主要的工作目录、项目代码和工具后来都救回来了，丢了的 Git 工作树也恢复了。前后回填了大约 11.7 万个文件，跟事故前的快照比，还差 9 万多个，里面有不少是缓存和依赖，但部分没提交的修改、配置和脚本确实缺了。聊天记录就没那么幸运。七百多份 Codex 会话文件受损，一半以上没能找回完整记录；Claude 和 Grok 的旧会话，大多只剩片段。最后，可用的快照停在出事前大约 54 分钟。那 54 分钟里的新东西，基本没有地方找回来。代码丢了还能重写。真正补不回来的，是那些只存在于聊天里、没有另存成文档的讨论、决定的来由，还有一起走过的那段经历。从那以后，每个 agent 的删除命令都套上了防误删的保护。各种防御，各种叠甲，各种 SHA256，严谨是真的严谨。可最该防的那一下，是从一个没人想到的地方漏过去的。一边加水，一边漏水。然后我去数了一下。整个项目大概 128 万行：后端 45.9 万，测试 60.3 万，前端 13.9 万，脚本 7.8 万。测试比产品代码还多，最近这段时间，测试的增长速度是产品代码的 2.8 倍。后端 45.9 万行里，真正跟 AI 工具打交道的只有 6% 左右，剩下的都在管理、记录、校验、防御。有一个状态文件，一个文件 4.9 万行，677 个函数，两周又长了大概 4000 行。 17847 个测试，628 个是红的，其中 500 多个说不清为什么红。一个 4 行的 bug，来来回回修了好几轮。中间我是想过重写的。Claude 一开始建议先整理，后来又建议先把 V1 做完。我问了一个问题：为什么要等？在这样的结构上收 V1，比较确定给不出收口日期，额度几乎都花在给要退役的结构打补丁上。从头写一个新核心，工作量反而是有边界的。于是决定重写。接着就是第一个问题：要不要先让 AI 把旧代码读一遍？不读。旧代码里的每一层防御，单独看可能都有道理，但 AI 一旦读进去，大概率会被带着走，又把那套结构原样搬回来。所以这次用伪净室的办法：新核心只根据需求和黑盒验收来写，旧的巨型文件一律不看。验收也换了。不按阶段、按 closeout 算，按我自己真实会走的路算。排在第一条的，就是当初只干了 15 分钟就停下来的那件事：交代一次，关掉页面，睡一觉，结果在对话里。这条路走不通，别的验收过了，相对来说也不太算数。新核心的目标，是旧后端的五分之一到六分之一。这段时间也不全是白折腾。为了让 agent 之间少靠我人肉转话，我做了电话线：一个 agent 当 Lead 派活，其他 agent 执行和审核，Lead 派完就休息，等回执把它叫醒，项目自己往前推。为了不用每来一个新 agent 都从头讲一遍公司是干嘛的，我做了 Onestead，算是公司的 OS 底座，手册、项目、决定这些公司事实放在一处，agent 自己读、自己写。为了知道同时开着的几个 agent 谁在干活、谁在等我、谁刚交了卷，我做了 AI娘研究室，把她们画进同一间会动的小屋子，抬头看一眼就知道。还有一个意外收获：顺手把 Claude 的防封号问题也解决了。很多 insight 和体感，都是在这个项目里撞墙撞出来的。know-how 留下来了，重写需要的 context 也够了。这次不急，宁愿多等几周，用上完整的版本。回头看，agent 们没做错什么，它们是照着定义一丝不苟地干。问题可能在于，我对身边这几位 agent 的特点和能力边界，了解得还不够深。真正了解了，设计的时候、分配角色的时候就会更精准，很多问题在前面就能避开，用不着事后一层层叠甲去补。这些了解相对来说没法从文档里读出来，只能一次次撞出来、积累出来。通用的、看似正确的东西，学到六七十分不难，学好很难。敬畏专业，可能是这段时间最大的收获。我现在比较确定它应该长成什么样，也大概知道它不该长成什么样。