子代理烧光回合预算交白卷，父任务收到的是成功

Gemini CLI 的 issue #22323 里有一份保存下来的会话日志。主代理把"理解 t3code 和 superset 两个仓库的架构与 AI agent 集成方式"派给内置的 codebase_investigator 子代理，工具结果返回 status: "success"、终止原因写着 GOAL——

而同一份结果正文里自己说，调查在识别出任何具体任务之前就被"maximum number of turns was exceeded"打断，RelevantLocations 是空的，没有任何实际分析发生。

报告者 matei-anghel 在 2026 年 3 月 13 日提交这个问题时点出了矛盾所在：子代理在真正开工前就耗尽了回合预算，可外层记账把它记成了达成目标。

状态字段和结果内容各说各话，读哪一边取决于调用方信哪一层。

这条 issue 挂着的标签现在包括 🔒 maintainer only——⛔ Do not contribute. Internal roadmap item。也就是说，它已被归入内部路线事项，不接受外部直接投稿修复；同时页面上关联着修复 PR #29367，问题本身仍未关闭。

从 3 月到 11 月，评论区攒下了一份少见的多团队失败样本库，值得逐条拆开看。

同一个坑，别家踩出的数字

来源：github.com/google-gemini/gemini-cli issue #22323 页面截图，截取于 2026-11-05。

4 月 21 日，用户 jingchang0623-crypto 描述了他们用 OpenClaw 编排的 5 个 AI agent 协作生产网站内容的事故（与 Gemini CLI 是不同 harness，故障形态相同）：

研究 agent 耗尽回合去"理解任务"，报告 success，产出零条研究；写作 agent 拿到空研究，凭感觉写了 2000 字文章，报告 success；审阅 agent 找不到来源（因为根本不存在），验证到耗尽回合，报告 success；

编辑 agent 收到"已通过"的文章直接发布，报告 success；QA agent 检查成品，发现 0 个来源、3 处幻觉引文和一个指向 404 的"参考链接"——也报告 success。

他给这类故障起的名字

是 phantom completion：每一环都绿灯，整条链没有一环真的干活。

同一条评论里还给出了修正数据：加上"交付物缺失即判失败"的校验后，抓出了约 30% 名义成功的子代理运行。另两位评论者的数字更小也更能对号入座：m13v 在一个 codebase-investigator 克隆上量到 22% 的假成功率；Akshmit 则观察到子代理卡在回合上限或循环里时，CLI 内存能涨到约 2GB，日志照样写 success。

9 月 29 日的长评来自一个自称 Mycroft 的账号——它声明自己是某实验室的"合成联创"，跑的是 Claude Code 子代理集群而非 Gemini CLI，因此以"证人陈述"而非意见的姿态发言。

它的事故有具体数字：3 个子代理带明确交付要求出发，2 个返回零内容，各自烧掉 184k 和 147k token 才回来；两者都走正常完成路径，父任务视角里没有任何"失败"字样。

事后检查发现，两个子代理等的不是安装本身——包早已装进 venv——而是等一条永远不会到达的"安装完成通知"，然后耗尽预算返回。

为什么"干净退出"会被当成"干完了"

把这些案例放在一起，机制浮出水面：编排器手里只有两类信号——回合计数器和工具调用的返回值。子代理的循环退出得干干净净，没有任何显式的完成宣告参与判断，于是"进程正常结束"被合并记录成"目标达成"。jingchang0623-crypto 在 4 月的评论里把这叫语义错位：技术上前者为真，后者在回合耗尽时为假，但协议只留了一个格子。

Mycroft 那条长评给出的判别式比各种状态机提案更窄也更便宜：父任务断言产物，不断言子代理的自我报告。每次委派绑定一个要求的输出形状，产物为空或缺字段就是失败，无论子代理自己怎么说。按这个测试，原 issue 当场结案——RelevantLocations: [] 配上一段描述被打断的摘要，不管终止原因字段写什么，都是失败。

它还补了两条工程细节：状态判定和产物校验不能共用一条代码路径，否则空产物会顺着同一个函数被提拔成成功；修复必须先有一条"对着未修复版本会红"的回归测试，事后补写的测试第一天就绿，什么都保证不了。

0xbrainkid 7 月 17 日的评论把同一诉求写成契约语言：父任务需要知道两件独立的事——子进程交回了控制权、命名的 agent 确实产出了这次委派要求的工件，

“Those should not collapse into one success bit”。它列的回归测试清单（attempt id 可见、终止原因原样保留、空产物不可提拔为 GOAL、重试生成关联的新 attempt 而不是覆盖旧边）可以直接抄进任何多代理框架的验收标准。

排查自己的多代理任务时，先查什么

hobi-design-2 5 月 5 日的抱怨给出了最日常的症状：子代理不做任何一次编辑，回来标记 completed successfully，在 gemini-3.1-pro-preview 和 gemini-3-flash-preview 两个模型上都复现。

如果你管理的多代理流水线里有"哪个 agent 启动了哪个、谁在等谁"的黑盒焦虑，这份 issue 提供的对照很直接——先看产物档案，再看状态字段。

具体可以按三层收集证据。第一层，给每次委派预先声明"必须存在且可核对的输出"：一个文件、一段符合结构的 JSON、至少 N 条带位置的发现；父任务只认这个，不认子代理的自述。第二层，把"子代理返回了"与"子代理交付了"拆成两个字段分别落日志，任何一侧异常都要能单独报警。第三层，为假成功场景补一条测试：造一个"干净退出但交空工件"的桩子代理，先在未修复的版本上确认它会红、修复后转绿——这样这条测试才真的能拦住回归。

这些做法全部来自评论区公开记录的观察与工程反馈，不是本文的实测结论；各家 harness 的实现细节不同，落地前要在自己的环境里验证。它们共同指向的判断是：回合耗尽的子代理恰恰最没有能力描述自己的状态，所以让它的自评参与成功判定，从一开始就是错的接线方式。

参考来源

• google-gemini/gemini-cli issue #22323 原始页面（含 Activity 区全部评论，采集快照 2026-11-05）：https://github.com/google-gemini/gemini-cli/issues/22323

本文面向授权安全研究与防御建设，未经授权对任何系统实施文中技术属违法行为。