工具描述是接口契约，模糊描述等于埋下隐患

工具调用协议决定 Agent 与外部世界的交互质量。当前主流做法是把工具以结构化 schema 暴露给模型，由模型输出调用意图，运行时负责校验与执行。问题在于，很多团队把 schema 当成“给模型看的说明书”，写得含糊其辞，参数命名随意，缺少边界说明，模型只能靠猜，错误率自然高。

权限边界则是另一个被低估的环节。Demo 阶段往往给 Agent 一把“万能钥匙”，能读能写能删；生产环境里，这种设计一旦遇上提示注入或模型误判，后果就是数据泄露或误操作。真正可用的权限模型，需要把“这个工具能做什么”和“这次调用允许做什么”分开，前者是静态定义，后者是运行时动态判定。

评测与运行时日志构成闭环。没有日志，评测只能看结果对不对，看不到过程为什么错；没有评测，日志堆成山也无法转化成改进。二者必须一起设计。

输入侧：工具定义要写成契约而非说明。每个工具需明确：必填与可选参数、参数类型与取值范围、幂等性、失败返回结构、调用前置条件。建议给每个工具附 2 到 3 个正例和反例，直接进系统提示。输入侧还要做意图归一化，把用户自然语言里的模糊指代（“那个订单”“上次的文件”）解析成确定标识，否则模型会在参数里编造 ID。

推理/执行侧：执行层要独立于模型。模型只输出“调用哪个工具、传什么参数”，执行层负责参数校验、权限判定、超时控制、重试与降级。建议采用三段式：先静态校验（类型、必填、枚举），再权限校验（主体、资源、动作三元组），最后沙箱执行。任何一段失败都返回结构化错误给模型，让它有机会自我修正，而不是直接抛异常中断。

输出/评测侧：输出要区分“工具返回原文”和“模型转述”。前者进日志存档，后者进用户回复。评测集应包含四类样本：正常调用、参数缺失、权限不足、工具超时。每类都要有期望行为定义，比如权限不足时期望模型向用户说明原因而非反复重试。评测指标建议用“任务完成率 + 无效调用率 + 平均调用轮次”三者组合，单看完成率会掩盖效率问题。