AI Know · 技术研究笔记
工具调用协议正从函数调用走向标准化 Schema
权限边界要按工具粒度做最小授权与审批流；运行时日志是 Agent 可观测性的唯一真相来源；评测集必须覆盖越权、超时与长尾输入
三分钟读懂
先看结论，再决定是否深读
- 工具调用协议正从函数调用走向标准化 Schema
- 权限边界要按工具粒度做最小授权与审批流
- 运行时日志是 Agent 可观测性的唯一真相来源
- 评测集必须覆盖越权、超时与长尾输入
- 成本与延迟是工具链设计的一等约束
核心原理
2026 年的 Agent 系统早已跨过“能不能调用工具”的阶段。真正拉开差距的，是工具链的工程化程度：工具怎么描述、权限怎么收口、运行时怎么留痕、效果怎么评测。一个能演示的 Agent 和一个能上生产的 Agent，差别几乎全在这四件事上。
很多团队的工具调用还是散落的 if-else：模型输出一段文本，代码里正则匹配关键字，再手动分发。这种方式在 3 个工具以内勉强可用，超过 10 个工具就迅速失控——参数校验缺失、错误处理随意、权限形同虚设。工程化的第一步，就是把工具调用从“文本约定”变成“结构化契约”。
技术细节
输入侧：工具 Schema 与上下文注入。 工具描述不是写给人看的文档，而是模型选择与填参的依据。每个工具应有稳定的名称、语义清晰的描述、严格的 JSON Schema 参数定义，以及明确的返回值结构。描述里要写清适用场景和禁用场景，否则模型会在相近工具间反复摇摆。上下文注入要控制 token：只放当前任务相关的工具子集，配合“工具检索”机制，避免一次性塞入上百个工具定义。
推理/执行侧：协议层与运行时。 工具调用协议目前主流是三类：模型原生 function calling、MCP 这类标准化上下文协议、以及自研的中间层。无论哪种，执行侧都要统一处理：参数校验、超时控制、重试策略、并发限流、幂等设计。执行器应作为独立进程或服务存在，与模型推理解耦，这样工具崩溃不会拖垮整个会话。权限校验必须发生在执行器内部，而不是依赖模型“自觉遵守提示”。
输出/评测侧：日志与指标。 每次工具调用都应产生一条结构化运行时日志：会话 ID、工具名、入参、出参、耗时、token 消耗、是否命中缓存、是否触发权限拒绝。这些日志既是排障依据，也是评测数据来源。评测要分两层：离线用固定用例回归，在线用真实流量采样。指标至少覆盖任务成功率、工具选择准确率、平均调用轮次、P95 延迟、单任务成本。
一个容易被忽视的点是：工具调用的日志要能回放。把模型输入、工具选择、执行结果按时间线串起来，才能定位“为什么 Agent 选错了工具”这类问题。
工程实践
第一，把工具定义纳入版本管理。 工具 Schema 的每次变更都要走代码评审，并记录兼容性影响。模型侧的提示词与工具定义应同源生成，避免文档和实现漂移。上线前用固定评测集跑一遍回归，确认工具选择准确率没有下降。
第二，权限按“工具 + 参数 + 环境”三层收口。 不要只做工具级白名单。同一工具在不同参数下风险不同，比如查询和删除都走数据库工具。对高风险参数组合强制人工审批或二次确认，生产环境默认只读，写操作单独走审批通道。
第三，运行时日志默认全量采集，采样分析。 全量存储原始调用链，分析层再做降采样和聚合。日志字段要预留扩展位，方便后续加入新的成本、缓存、安全标签。配合告警：连续多次权限拒绝、单会话工具调用超过阈值、P95 延迟突增，都应触发通知。
风险边界
成本失控是最常见的坑。Agent 会为了一个简单任务反复调用工具，轮次越多成本越高。要在执行器层设置单会话最大调用次数和 token 预算，超限直接熔断并返回降级结果。
越权调用往往来自提示注入。攻击者通过网页、文档等外部输入诱导模型调用高权限工具。防御的关键是把权限判断放在执行器而非模型侧，并且对工具返回内容做净化，防止二次注入。
幻觉与工具误用表现为模型编造不存在的工具、填错参数、或忽略工具报错继续调用。执行器要严格拒绝非法参数，并把结构化错误返回给模型，而不是抛异常中断。
长尾输入与延迟同样致命。罕见格式的文件、超长上下文、第三方接口抖动，都会让工具链在边缘情况崩溃。做好超时、降级、缓存与异步化，才能让 Agent 在真实流量下保持稳定。
工具链工程化没有银弹，但有清晰的优先级：先把契约和日志做扎实，再谈权限和评测。一个能回放、能收口、能度量的 Agent 系统，才具备持续迭代的基础。