Capt Pascal @captpascal - Twitter Profil

我想做一个自己好用的协作工具。起因很简单。我平时跟 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 的特点和能力边界，了解得还不够深。真正了解了，设计的时候、分配角色的时候就会更精准，很多问题在前面就能避开，用不着事后一层层叠甲去补。这些了解相对来说没法从文档里读出来，只能一次次撞出来、积累出来。通用的、看似正确的东西，学到六七十分不难，学好很难。敬畏专业，可能是这段时间最大的收获。我现在比较确定它应该长成什么样，也大概知道它不该长成什么样。

2

1

0

1K

0

4

Capt Pascal

@CaptPascal

7 menit yang lalu

@zifanersuo 抓大放小这句同感，AI 时代也管用

0

1

0

4

Capt Pascal

@CaptPascal

sekitar 22 jam yang lalu

防得认真和防对地方，是两件事。层层叠甲容易给人“已经很安全”的感觉，最致命的风险往往出在没人想到的地方。与其加第十层，不如先问最坏的那一下会从哪里来。

Capt Pascal

@CaptPascal

7 hari yang lalu

我想做一个自己好用的协作工具。起因很简单。我平时跟 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 的特点和能力边界，了解得还不够深。真正了解了，设计的时候、分配角色的时候就会更精准，很多问题在前面就能避开，用不着事后一层层叠甲去补。这些了解相对来说没法从文档里读出来，只能一次次撞出来、积累出来。通用的、看似正确的东西，学到六七十分不难，学好很难。敬畏专业，可能是这段时间最大的收获。我现在比较确定它应该长成什么样，也大概知道它不该长成什么样。

2

1

0

1K

14

22

0

294

Capt Pascal

@CaptPascal

9 menit yang lalu

@lser88 按盲区、板块、角色或阶段分，具体看项目。

0

2

Capt Pascal

@CaptPascal

sekitar 5 jam yang lalu

More reviewers only help if each one checks something different. Copies of the same model reading the same diff tend to miss the same thing.

Surge AI

@HelloSurgeAI

sekitar 6 jam yang lalu

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.