ai / 20260727
05. 模型调用工具之后,运行时发生了什么
模型输出工具调用不是动作已经完成,而是向运行时提交了一份执行请求
Kimi 的第一轮模型响应包含两个 Bash 调用。此时模型只表达了“希望执行什么”,命令尚未在本机发生。
从模型响应到下一次模型请求,中间至少经过六个阶段:
| 阶段 | 输入 | 输出 |
|---|---|---|
| 解析 | 模型响应 | 工具调用对象 |
| Schema 校验 | 名称与参数 | 合法或参数错误 |
| 权限判断 | 主体、动作、资源 | 允许、拒绝或询问 |
| 执行 | 已授权调用 | 标准输出、错误与退出码 |
| 事件记录 | 执行结果 | 可追踪事件 |
| 结果回填 | 调用记录与结果 | 下一轮模型输入 |
调用标识贯穿整个过程
一次调用至少需要 tool_call_id、工具名称和参数。权限结论、执行结果和下一轮回填都要引用同一个标识。
如果并行发起两个调用却只按完成顺序追加文本,先完成的第二个调用可能被误配给第一个。Kimi 使用 Bash_0 和 Bash_1 分别关联结果,说明调用标识不是日志装饰,而是并发归并条件。
权限判断不能相信模型自报
模型可以在参数中写“这是只读命令”,但运行时不能据此授权。策略引擎要根据解析后的动作重新计算:
- 当前主体是谁。
- 调用什么工具。
- 访问哪个路径或域名。
- 是否写入、执行或联网。
- 授权持续到本次调用还是整个会话。
模型负责提出动作,运行时负责决定动作是否可以发生。
执行结果要区分四种状态
| 状态 | 含义 | 是否适合自动重试 |
|---|---|---|
completed | 工具完成 | 不需要 |
failed | 工具返回确定错误 | 视错误类型 |
denied | 权限策略拒绝 | 不应原样重试 |
unknown | 中断后无法确认结果 | 先查询或恢复 |
把拒绝也表示成退出码 1,会让模型误以为修改参数即可继续;把未知结果表示成失败,可能导致有副作用的操作重复执行。
本次两条成功轨迹有什么差异
Codex 把读取路径和列目录组合到一条 Shell 调用里,Kimi 将其拆成两个调用。前者减少一次工具边界,后者让每个结果更容易单独记录和重试。
本次任务中两个动作均为只读,两种方式都能完成目标。若其中一个动作具有副作用,组合命令会增加恢复难度:运行时只能看到整条命令的退出状态,未必知道前半段是否已经完成。
事件顺序比最终文本更重要
一条可调试轨迹至少应出现:
model.completed
tool.requested
tool.authorized
tool.started
tool.completed
model.started
model.completed
turn.completed
事件需要统一的轨迹标识、轮次标识、调用标识和递增序号。最终回答只能说明用户看到了什么,事件链才能说明运行时做过什么。
模型调用工具之后,Agent 的主要工作暂时离开模型,进入确定性的运行时流程。这里的任何一步缺少校验或记录,后面的回答即使正确,也无法证明过程符合约束。
版权声明: 如无特别声明,本文版权归 sshipanoo 所有,转载请注明本文链接。
(采用 CC BY-NC-SA 4.0 许可协议进行授权)
本文标题:05. 模型调用工具之后,运行时发生了什么
本文链接:https://www.sshipanoo.com/blog/ai/agent-runtime-lab/05-工具调用后的运行时/