幽灵闭环第三形态：日记声称"本轮已补发飞书摘要"，session 里里没有 send_table 调用——用工具调用计数抓执行造假

日志里明晃晃写着飞书摘要已发送，可翻遍整个 session 记录，连个 send_table 的影子都没有。

这种薛定谔的调用一旦上线，用户看到的不是功能失效，而是系统逻辑的彻底崩塌。

我们排查了整整两天，最后发现凶手根本不是网络超时，也不是异步回调丢失。大模型在特定边界条件下，自己编造了执行成功的记录。要抓这种执行造假，解析业务返回内容纯属白费力气，得用硬性的工具调用计数做闭环校验。

正常的流水线是怎么跑的

先说说这套 Agent 工作流原本的设计。

用户提交日报需求后，编排引擎会先让大模型生成 Markdown 格式的摘要。内容对齐之后，系统会触发 send_table 工具把表格推送到飞书群。请求返回 HTTP 200，业务层立刻往日志里追加一行成功标记，整个闭环就画上了句号。

这套逻辑在压测环境跑得相当顺滑。

编排层负责拼装参数，执行层负责发请求，日志层负责记结果。三层职责切得很干净，中间没有多余的跳转。开发人员每天盯着监控看推送成功率，基本处于躺平状态。

直到那天下午，监控面板突然飘红。

飞书侧的推送成功率断崖式下跌，但应用日志里，成功标记却密密麻麻。翻出对应的 session 追踪，发现一个诡异的现象。日记明确声称本轮已补发飞书摘要，可底层执行记录里，send_table 的调用次数始终停留在零。

日志说成功了，可飞书那边静悄悄

我们第一反应是排查网络层。

抓包工具里确实没有发出 POST 请求的痕迹。接着怀疑是异步线程池把任务吞了，或者重试机制覆盖了原始日志。把线程栈和消息队列的消费位点拉出来对比，发现中间根本没有断点。

问题出在 LLM 的输出解析环节。

当模型生成内容较长，或者遇到流式传输的截断点时，下游的 JSON 解析器会抛出异常。我们的旧逻辑为了不让流程卡死，写了一段兜底代码。

这段代码在捕获到解析失败时，会直接往业务日志里写成功标记。

它以为自己在优雅降级，实际上是在伪造执行结果。模型根本没有生成合法的 send_table 调用指令，解析器也没能拿到有效参数，整个工具调用链路被静默跳过。但日志系统照旧打印了成功状态，这就造成了幽灵闭环。

模型是怎么凭空变出成功记录的

这类问题在当前的 Agent 框架里越来越常见。

大模型本身并不负责执行，它只负责输出工具调用格式。下游的解析器负责把格式转成实际 API 请求。中间一旦有格式校验失败，或者字段缺失，执行层就会直接放弃。

旧版代码把放弃动作当成了静默成功。

我们在本地复现了这个问题。手动构造一个缺少 table_data 字段的请求，解析器直接抛出校验异常。兜底逻辑捕获异常后，跳过执行器，直接打印了成功日志。

这种现象被称为执行造假。

系统状态机认为任务已完成，可底层根本没有发生任何 I/O 操作。用户端看到的要么是重复推送，要么是数据缺失。排查这种问题，靠肉眼核对日志根本来不及。

用计数器给执行过程上锁

修复这种逻辑漏洞，需要把虚的意图变成实的轨迹。

核心思路很简单，引入全局工具调用计数器。每次编排引擎准备下发工具指令时，计数器强制加一。指令真正进入执行器并触发底层 API 时，计数器再校验一次。

如果日志里报了成功，但计数器没动，直接判定为执行造假。

我们在网关层加了一个轻量级的拦截器。拦截器会记录每个 session 的 tool_call_count。当 send_table 被触发前，计数器记录当前值。执行结束后，对比最终值。

只要两者不一致，系统就会自动拦截后续的流程，并抛出明确的校验失败告警。

这套计数器方案不仅抓出了伪造日志，还顺带暴露了另一个隐藏问题。

之前的重试逻辑里，如果第一次调用超时，系统会重新生成指令。旧版计数器没有做幂等处理，导致同一个 send_table 被重复计数。我们顺手在计数器里加了 session 级别的隔离键，确保每次请求的调用链独立统计。

上线后第三天，又抓到一个典型案例。

某个长文本场景下，模型输出了两个连续的 send_table 调用。旧日志只记录了最后一个的结果，中间的调用被静默丢弃。计数器直接把两次调用都钉死在追踪面板上，运维一眼就能看出数据断层。

数字不会骗人

把信任交给业务日志，迟早会被各种降级逻辑和异常捕获机制带偏。

工具调用计数虽然是个笨办法，但它绕过了所有业务层的包装，直接监控指令的下发动作。数字不会骗人，它只会如实记录每一次边界碰撞。

下次再遇到这种声称成功却查无实据的幽灵调用，直接看计数器就对了。