453 次代理会话暴露的自动化陷阱

让 AI agent 写代码不难，难的是它说「完成」时，线上真的生效了，消息没有重复发送，后台任务也没有悄悄烧掉预算。Tobo 联合创始人 Camille 把自己交给 Claude Code 的工作逐项复盘，整理出九类故障，以及每次故障留下的规则。

作者只有 16 岁，没有员工。他统计了 453 次会话后给出的结论是：agent 出问题，往往出在验收、重试、等待和协作的边界。对已经用 AI 处理开发、部署和日常自动化的程序员，这些失败比一份能力演示更有参考价值。

为什么终端在忙，工作却没有推进

作者在 2026 年 11 月 11 日统计了笔记本上的 Claude Code 记录：10 月 7 日至 11 月 11 日，共 453 次会话、17,050 次工具调用，工具耗时合计 38.3 小时。更早的事故来自当天留下的笔记。

其中最明显的问题是等待。10 月 7 日至 27 日，工具耗时为 22.5 小时，运行至少一分钟的前台命令占了 13.4 小时，即 60%。构建、推送，以及 1,286 次 sleep、until 小循环，都让会话停在那里，最长一次等了 68 分钟。

他的规则是：可能超过一分钟的任务放到后台；等待期间，agent 继续处理别的工作或回应用户；前台不执行 sleep；超时过一次的脚本，不能原样重跑。10 月 28 日之后，相应占比降到 27%，最长等待降到 19 分钟。

这些数字有改善，但还不能证明规则产生了多少效果，因为前后处理的工作也变了。

自动化还有另一种空转。一个后台进程因缺少模块，在 19 天内重启了 37,714 次，另两个分别重启了 13,411 次和 5,956 次。一个遗忘的游戏进程连续 14 天占满一个 CPU 核心，电脑电池只能撑两小时。清理后，空闲功耗从 12.4 瓦降至 4.7 瓦。其中一个叫「助手」的任务，已经三周没有产出。

所以，自动化需要留下带日期、有人会看的产出记录。进程还活着，不能证明任务有价值。

agent 说完成，应该拿什么作证

工具返回成功，只能作为线索，不能代替结果验收。

作者遇到的部署事故很典型：命令打印成功提示，并以退出码 0 结束，但实际上有一个文件被拒绝。agent 只读最后两行，漏掉了其他位置的报错，导致三次推送没有真正生效。本地已经修好的内容，线上仍然旧着，排查却绕去了其他方向。

他补上的规则有两层：扫描完整输出中的错误，再从服务器读回文件。对于前端发布，真正需要回答的是目标资源是否已经更新。

消息发送则暴露了重试的风险。平台把换行转成空格，agent 用原始文本与平台返回文本直接比较，多行消息便全部校验失败。它判断发送失败，又发了一遍，最终三位供应商收到了重复消息。

这里缺的是对真实状态的确认。第二次执行对外操作之前，应该重新读取平台上的发送记录，而不是继续相信第一次调用的输出。原文没有给出具体平台或幂等 API，不能据此假定所有发送系统都有统一的防重机制。

监控也可能「按要求工作」，却没有帮到人。一个站点在 8 月 1 日宕机，监控记录了状态变化，之后再没通知，因为故障状态一直没变。作者直到 9 月 3 日才发现，已经过去 33 天。

他的修正是持续告警，并标明故障天数：沉默应该表示正常，不能表示没有新变化。轮询是否成功，与故障是否被处理，是两回事。

技能、多 agent 和预算，为什么都要做减法

作者安装了 148 个 skills，也就是供 agent 按需加载的指令包。但 453 次会话只触发过其中 17 个，总计加载 81 次，前三个占 54%。

他在 9 月就发现过类似情况：106 个 skills 里只有 16 个被用到。后来把描述改成「什么时候使用」，并采用自己实际提问的措辞，唤醒了一部分技能，大多数仍然没动静。

全部描述只占约 1% 的上下文，因此作者认为，主要损失是自己误以为 agent 掌握了那些流程。他的处理方式是：一个月没有触发的 skill，重写或删除。

多 agent 同样没有自动带来收益。他安排八个 agent 每天提出内容选题，第一次完整运行消耗了相当于 5.58 美元的 API 调用，还挤掉了当天上午需要的额度，选题质量却普通。之后，他禁止自动任务使用大模型，设置每日 0.80 美元硬预算，只在有新输入时重新运行，并先判断普通脚本能否完成任务。

并行协作的问题则是沟通。三次会话分别汇报进度，让委派变成了持续监督。作者认为，会话之间的沟通通道会随数量平方级增长。他改用项目内的 BOARD.md：每条工作线一行，记录负责人、状态和下一步；开始时读，结束时更新。分工按主题、API、图片等实际修改资源划分，避免编辑同一文件。会话之间只在被对方阻塞时发消息，最多三行。

最后，估算也需要测量。他原以为产品里的中等任务要花 0.90 美元，五个真实任务测下来只需 0.15 至 0.23 美元。另一次，agent 靠试错摆放物体花了 25 分钟，先测量后，同样的工作只需四次工具调用。准备开发一个工具前，三分钟搜索又发现已有一个获得 629 stars 的实现。

这些经历让他要求每个任务第一行写 Done =，后面接可观察的完成条件，并主张花二十分钟确认问题，避免贸然投入两天。

我的判断

我认同作者把重点放在验收和约束上。规则都能落到动作：部署后读回、重试前查状态、支出设硬上限、任务写明完成条件。它们也能约束普通脚本和人工流程。

但这些是个人经验，不能直接包装成普遍收益。样本只有一个人、一台笔记本、五周记录；按作者的说明，Claude Code 默认只保留约一个月的记录。工具耗时按调用到返回的间隔统计，并行调用分别全额计时，不包括模型思考时间，所以 38.3 小时不能当成人工时间损失。

同样，60% 降至 27% 只是规则实施后的变化，没有对照实验。长前台命令也未必浪费，关键在于等待期间是否存在可推进的其他工作。

有些规则需要按团队调整。简单任务用脚本，确实更容易控制成本；但禁止自动任务使用大模型，作者没有给出跨模型的质量与成本对照。删除一个月未触发的 skill，也可能误删低频但重要的发布或事故流程。BOARD.md 适合轻量协调，却没有说明如何处理两个会话同时写这个文件的竞争。

作者同时在开发 Tobo，并把这些规则作为产品方向，包括完成前核验、不可逆操作前询问、硬预算和任务回执。这提供了产品动机，尚不能证明产品已经解决了上述问题。

能拿来做什么

• 给 AI 编程任务补上 Done =。例如修复部署问题时，写明要从服务器读回哪个文件、看到什么内容；让完成条件能被检查。
• 给对外发送和发布流程补一次真实状态查询。文本格式变化不能直接触发重发，退出码 0 也不能成为部署验收的唯一依据。
• 给长期运行的 agent 加预算和产出记录。先检查有没有新输入、近期有没有结果，再决定是否启动下一轮；固定规则能处理的步骤可以交给脚本。
• 用作者提供的脚本检查自己的 Claude Code 使用记录。按原文说明，它只有一个 Python 文件，仅使用标准库，不调用模型，也不上传数据：

curl -sO https://raw.githubusercontent.com/tobo-team/agent-audit/main/audit.py
python3 audit.py --by-month

第二行的 --by-month 用来按月查看统计。第一行下载的是远程脚本，执行前应先阅读内容；解释结果时，也要记住工具耗时包含等待，并行调用会分别计入。