工具调用协议是 Agent 的接口契约，决定扩展性

Agent 从演示走向生产，最难的不是模型能力，而是工具链的工程化。一个能调用搜索、数据库、代码执行、内部 API 的 Agent，本质上是一个分布式系统：它有输入解析、有远程调用、有权限控制、有失败重试、有可观测性要求。区别在于，它的“调用方”是概率模型，而不是确定性程序。

这就带来三个结构性难题。第一，工具调用协议如何设计，才能让模型稳定地产出可解析、可校验的调用意图。第二，权限边界如何划定，才能既让 Agent 完成任务，又不让它越权访问敏感资源。第三，运行时日志与评测如何打通，才能在出错时回答“是模型选错了工具，还是工具本身失败了”。

输入侧：工具描述与参数约束。 模型看到的不是函数签名，而是自然语言描述加 JSON Schema。描述质量直接影响工具选择准确率。实践中，工具名要动词化且唯一，参数要区分必填与可选，枚举值要穷举，避免模型自由发挥。输入侧还要做一层预校验：类型检查、范围检查、敏感字段拦截。很多越权调用不是模型恶意，而是参数没约束好，模型填了一个不该填的 ID。

推理/执行侧：调用编排与权限校验。 模型输出工具调用意图后，执行层要做三件事：解析并校验参数、按调用者身份做权限判定、执行并捕获异常。权限判定不能只放在提示词里，必须落在工具网关。常见做法是给每个工具标注所需 scope，Agent 运行时携带用户身份，网关按 scope 放行。执行侧还要处理超时、重试和幂等，否则一次网络抖动可能导致重复下单或重复写库。

输出/评测侧：结果回灌与日志埋点。 工具返回结果要截断、脱敏、结构化后再回灌给模型，否则长结果会挤爆上下文。评测侧要记录完整轨迹：模型输入、工具选择、参数、权限判定结果、工具输出、最终回答。没有这条轨迹，评测只能看最终答案对错，无法定位是选错工具、传错参数，还是工具本身超时。运行时日志应支持按 trace ID 回放，这是 Agent 调试的刚需。