3 篇博文 含有标签「tooling」

一个工具调用返回了 142 KB 的 JSON 数据块。你的智能体框架丢弃了 8,192 字节之后的所有内容，将前缀交给模型，而模型根据一个它从未意识到是不完整片段的内容写出了一个自信的答案。三周后，一名客户升级了投诉。你翻看追踪记录（trace），看到“工具返回成功”，随后的复盘变成了寻找哪一步“忽略”了证据——然而没有哪一步忽略了它。证据在到达推理引擎之前就被裁剪掉了。

这并非假设。Codex 将工具输出截断硬编码为 10 KiB 或 256 行。Claude Code 的工具结果默认为 25,000 个 token，并且带有一个单独的显示层限制，曾在 2025 年短暂地将 MCP 响应裁剪到 700 个字符左右。OpenAI 的工具输出提交上限为 512 KB。每个框架都选择了一个看起来安全的数字，对于短工具调用确实如此。当单步输出越界时，故障模式就出现了——悄无声息地，没有异常，也没有模型可见的标记。

智能体用 400 毫秒回答了一个简单的问题，然后因递归限制错误（recursion-limit error）崩溃。Trace 显示了 25 次工具调用。从上到下阅读 Trace，工程师会得出结论：智能体糊涂了 —— 以略有不同的顺序反复调用那几个工具，始终无法收敛。这个结论是错误的。智能体并没有糊涂。它陷入了一个死循环：工具 A 调用了模型，模型选择了工具 B，工具 B 的实现再次调用模型来格式化其输出，而格式化程序又选择了工具 A。Trace UI 将四个嵌套调用渲染为扁平列表中的四个兄弟调用，导致唯一能发现问题的开发者也无法察觉这个循环。

这就是工具重入（tool reentrancy），这是一种你的函数调用层几乎肯定没有建模的 Bug 类别。并发安全的代码对此已有数十年的原语支持：记录同一线程嵌套获取次数的重入互斥锁（reentrant mutexes）、语言层面的递归限制、堆栈检查 API，以及一种文化共识：任何回调运行时的函数都需要一个明确的契约，规定允许何种重入。工具调用层默认采用“发后即忘”（fire-and-forget）模式。运行时没有可供检查的调用栈，调度前没有循环检测器，工具定义上没有重入属性，Trace UI 的形式像日志而非图。结果就是，任何超过十几个条目的工具目录都会悄悄变成框架无法察觉的递归。

智能体自信地报告：“我已将会议改至周四下午 3 点。”用户却盯着原本周二上午 10 点的时段发呆，因为在智能体制订计划到提交更改的这段时间内，用户自己编辑了该事件。“最后写入者胜”（Last-write-wins）策略让自动化的操作覆盖了人类的修改，而用户对助手的信任也因这一次事故而崩塌。这就是双写竞争（dual-writer race），也是智能体工具链从未专门设计应对的 bug 类别。

大多数智能体平台都无意中继承了这一问题。工具层将 update_event 视为一个简单的函数调用：获取 ID，获取新字段，返回成功。底层的提供商 API 十多年来一直提供乐观并发原语（optimistic concurrency primitives）——ETags、版本令牌（version tokens）、If-Match 前提条件——但几乎没有人将它们贯通。模型无法知道它一分钟前所推理的世界已不再是现状，因为由于它所获得的抽象层静默地丢弃了这些信息。