工具调用和函数 Schema 应该怎么设计

先说结论

• 好的函数 Schema 不是字段越多越好，而是让模型更不容易误用
• 工具职责越单一，调用越稳定，排障也越容易
• 真正影响效果的往往不是模型能力，而是参数设计、返回结构和失败边界

一、Schema 本质上在帮模型做什么

它不是单纯把接口文档换个格式，而是在告诉模型：

• 这个工具是干什么的
• 什么时候该调
• 需要哪些参数
• 哪些参数不能乱填

如果 Schema 设计得太宽、太模糊，模型就更容易：

• 乱调工具
• 传错参数
• 把多个动作混成一次调用

二、一个更稳的设计原则

1. 一个工具尽量只做一件事

比如：

• 查询订单
• 取消订单
• 创建工单

最好分开，不要做成“订单操作总入口”。

2. 参数名尽量直接

优先用业务上本来就清楚的名字，比如：

• order_id
• user_id
• city

少用语义模糊的名字，比如：

• data
• payload
• params

3. 把约束写进 Schema，不要只靠说明文字

比如：

• 枚举值
• 必填项
• 数值范围
• 日期格式

这些越明确，模型越不容易自由发挥。

三、返回结构也要为模型服务

很多人只关注入参，其实出参同样关键。

更稳的做法通常是：

• 返回结构固定
• 成功和失败格式统一
• 错误原因尽量结构化

比如不要只返回一句“执行失败”，而要让模型知道：

• 是参数不合法
• 是资源不存在
• 还是权限不足

这样模型后续才知道该重试、补参，还是直接换路。

四、最容易踩的坑

1. 一个函数承载太多动作

看起来方便，实际模型特别容易选错动作或漏填参数。

2. Schema 很宽，但校验很弱

模型传什么都能进来，最后业务层到处兜底，维护成本会很高。

3. 把前端页面模型直接照搬成工具 Schema

页面字段往往很多，但模型真正需要的只是完成动作所需的最小集合。

总结

工具调用和函数 Schema 的核心，不是“把接口暴露给模型”，而是把工具边界收窄、参数约束收紧、返回结构做稳。工具越单一，Schema 越清楚，模型调用通常就越稳定。