你的工具链缺乏“Schema 级逻辑”，具体指什么
1️⃣ 考察意图
面试官想考察你是否理解工具调用（tool_calling）不仅是“给模型一个函数签名”，而是设计一套完整的“协议”。刁钻点在于：很多候选人只关注参数名和类型，忽略了语义边界、输入校验、错误码、重试策略等“Schema 级逻辑”。答好了能展示你对 Agent 系统稳定性的工程思维，知道如何防止模型误调用、乱传参、死循环，这是大厂生产级 Agent 的硬门槛。
2️⃣ 标准答
“Schema 级逻辑”指工具定义不仅仅是函数签名（函数名 + 参数列表），而是一套完整的协议，涵盖以下五个层面：
- 语义边界：每个工具必须明确“能做什么”和“不能做什么”。例如，一个“发送邮件”工具，Schema 中要写明“仅支持内部域名（@company.com）”，否则模型可能调用它发外部邮件。实际落地中，我在工具 description 里用自然语言写清楚约束，比如“参数
to必须是公司邮箱，否则返回错误码 4001”。这比靠模型自己推理更可靠。 - 参数约束与校验：OpenAPI Schema 中，除了类型（string/number），必须定义枚举值、正则、最小值/最大值。例如，一个“查询订单”工具，参数
order_id必须是 12 位数字字符串（pattern: "^\\d{12}$"），status只能是["pending", "shipped", "delivered"]。坑：模型有时会传空字符串或非法值，所以我在工具调用前加一层输入校验（用 Pydantic 或 JSON Schema validator），校验失败直接返回“400 Bad Request”并附带可读错误信息，而不是让模型重试。 - 输出规范与错误码：工具返回值必须结构化，包含
status、data、error字段。例如：
{ "status": "error", "code": "ORDER_NOT_FOUND", "message": "订单 ID 123456789012 不存在，请检查输入" } 这样模型能根据错误码决定下一步：是重试、换参数、还是放弃。没有错误码，模型会陷入“重试-失败-重试”死循环。实际落地中，我定义了 5 个通用错误码（4001 参数非法、4002 资源不存在、5001 服务内部错误等），每个工具再扩展专属错误码。
- 重试策略与幂等性：工具必须声明是否幂等（idempotent）。例如，“创建订单”不是幂等的，重试会导致重复下单，所以 Schema 中要加
idempotency_key参数，模型第一次调用时生成一个 UUID，服务端去重。而“查询订单”是幂等的，模型可以安全重试。坑：模型有时会忽略幂等性，所以我在工具 description 里显式写“此操作非幂等，请勿重复调用”，并在校验层强制要求idempotency_key。 - 工具间依赖与顺序：Schema 级逻辑还包括工具调用的顺序约束。例如，“支付”工具必须在“创建订单”之后调用。我在工具 description 里写“请先调用
create_order获取order_id，再调用此工具”，并在服务端做状态机校验，如果顺序错了返回“PRECONDITION_FAILED”。这避免了模型乱点工具导致业务异常。
工程取舍：更严格的 Schema 会增加开发成本（每个工具多写 50% 的校验代码），但能减少 80% 的模型误调用。在大厂生产环境中，我们选择“严格校验 + 可读错误”，因为模型重试一次的成本远高于校验成本。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，语义边界，工具 description 要写清能做什么不能做什么，防止模型越权；第二，参数约束与校验，用 OpenAPI Schema 的 pattern、enum 等限制输入，加一层 Pydantic 校验；第三，输出规范与错误码，返回值必须结构化，包含 code 和 message，让模型能根据错误码决定重试还是放弃。总结一句：工具不是函数，是协议，Schema 级逻辑就是把这个协议写死、校验死。”
4️⃣ 高频追问 & 应对
追问 1：如果模型不遵守 description 里的约束，比如传了非法参数，你怎么处理？
首先，不要依赖模型自觉。我在工具调用前加一层输入校验（用 JSON Schema validator 或 Pydantic），校验失败直接返回 400 错误，附带可读信息如“参数
status必须是 pending/shipped/delivered 之一，你传了 cancelled”。其次，在工具 description 里用“必须”“禁止”等强约束词，比如“参数to必须是公司邮箱，否则返回错误”。最后，如果模型频繁犯错，考虑在 system prompt 里加 few-shot 示例，展示正确和错误的调用。
追问 2：工具返回错误后，模型一直重试，怎么打破死循环？
在错误码中加一个“重试上限”字段，比如
retry_after: 0表示不要重试。同时，在 Agent 框架层实现重试计数器，同一个工具连续失败 3 次后，强制模型换策略（比如调用其他工具或向用户求助）。另外，对于非幂等操作，在 Schema 中要求idempotency_key，服务端去重，这样即使重试也不会产生副作用。
追问 3：你怎么设计工具间的依赖关系？比如必须先 A 再 B。
在工具 description 里显式写顺序约束，比如“请先调用
create_order获取order_id，再调用此工具”。服务端做状态机校验，如果顺序错了返回“PRECONDITION_FAILED”错误码。更高级的做法是，在 Agent 框架层维护一个“工具调用图”，用 DAG 表示依赖，模型调用时自动检查前置条件。但这样会增加复杂度，通常只在关键业务链（如支付、下单）中使用。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“Schema 级逻辑就是定义好参数类型和描述，模型会自己理解” → ✅ 正确切入：模型不是人，不会推理隐含约束，必须用正则、枚举、校验器显式限制，否则 10% 的调用会出错。
- ❌ 说“错误码不重要，模型能看懂自然语言错误信息” → ✅ 正确切入：自然语言错误信息模型可能误解，结构化错误码（如 4001、5001）让模型能精确判断下一步，避免死循环。
- ❌ 说“工具间依赖关系不用管，模型会按顺序调用” → ✅ 正确切入：模型经常乱序调用，必须在 description 和服务端双重约束，否则业务异常（如未下单先支付）。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“工具 Schema 类似 RAG 中的 query 校验”切入，对比两者都需要输入约束和错误处理，展示你对系统稳定性的理解。
- 如果你只做过传统 NLP：用“API 设计中的契约测试”类比，工具 Schema 就是契约，模型是客户端，必须严格遵循，否则返回 400 错误。
- 如果你是校招无项目：聚焦“OpenAPI Schema 规范”和“Pydantic 校验”的 demo 实现，展示你读过相关论文（如《Toolformer》《Gorilla》）并动手写过校验代码。
- 《Toolformer: Language Models Can Teach Themselves to Use Tools》 - 理解工具调用的基础范式
- 《Gorilla: Large Language Model Connected with Massive APIs》 - 工具 Schema 的语义理解
- OpenAPI 3.0 Specification - 参数约束（pattern, enum, min/max）的官方文档
- Pydantic V2 文档 - 输入校验的 Python 实现
- 《Building Production-Ready LLM Agents》 - 错误码设计和重试策略的工程实践