Agent 的上下文比人长了，debug 只能交给 agent

Sarah Wooders 在 X 上问了一句：当 agent 的上下文长度超过我们自己的，我们怎么 debug 它们。

Sydney Runkle 转了这个帖子，附一句：现在的现实是需要 agent 去 debug agent。

问题不新，被摆到台面上的时机有意思。过去一年 agent 从单轮调用变成跑几十分钟甚至几小时的任务，trace 动辄几万 token。人读不完。读不完，“审阅”这个动作就名存实亡。

回复区基本是一份民间方案清单。

Alex Strick van Linschoten 说自己一直在想 agent swarm 的可观测性，还放了一段工具演示。他的判断很实在：没有可视化工具，或者没有 agent 替人做代理解释，人很难跟上 swarm 里发生的事。

Sreeuday 想要一个按钮，叫 shrink this failure。把失败复现到最小上下文，缩到人能读懂为止。这个提法比“加更多日志”聪明，方向是减信息，不是加信息。

Steven Zimmerman 说 decomposition。Abinash Karki 说建系统，定期或随机抽查，他自称这是自己博弈论的极限。

suka 的回复最刺：就像 review 一个 4000 行的 PR，扫一眼前面，点通过。

Dave Birnbaum 提了个更工程化的做法：手工做 5% 到 10% 的工作，再用一个外层循环对比人工输出和 agent 输出，据此生成 harness 的修改建议。

Michael Hogers 说用更多 agent。Theodore Gavriilidis 说 agent 的上下文比人长，听起来挺好。

Aman 只问了一句：我们需要吗。

这句值得停一下。debug 的前提是有人能判断对错。如果 agent 的推理链长到人无法验证，“debug”这个词的含义就变了。它不再是找出错误的原因，而是找出哪个环节的输出偏离了预期。前者需要理解，后者只需要比对。

Sydney 那句“need agents to debug agents”听着像投降，其实是在描述一条正在形成的委托链：人定标准，agent 产出，agent 检查，人抽查。每一层都往下退一步。退到最后，人负责的事情只剩下定义什么叫失败。

这活儿不轻松。定义失败比修复失败更难，也更少人愿意干。