Session 0003

Tool Calling 生产化

Tool calling 的本质不是“模型能调用函数”，而是把模型意图转成受控、可校验、可审计、可回滚的工程动作。训练重点是 schema、权限、幂等、审批、错误恢复和工具结果进入上下文的方式。

1. 训练目标

本页要练会：把任何工具按 read/write/side-effect 风险分层，设计可验证 schema、服务端权限、幂等键、dry-run、确认、审计和 eval。

可靠依据：OpenAI function/tool calling / Anthropic tool use / OWASP LLM tool risks。本页把官方能力和生产工程约束转成面试题，而不是堆概念定义。

题量标准：5 个中大型深题 + 7 个知识广度题。深题用于系统设计和追问承压，广度题用于查漏补缺。

2. 五个深题

深题 01

你要设计一个付款 tool，让 agent 能根据用户请求创建付款单。schema 和执行链路怎么设计？

考察点：考副作用控制。模型可以提出 intent，但不能绕过权限、校验、审批和审计。

7+ 分回答骨架：schema 只接受 payee_id、amount、currency、invoice_id、reason、idempotency_key，不接受 tenant_id、role、approval_status。服务端从 auth context 注入身份并校验金额、收款方、发票状态和权限。先 dry-run 生成付款摘要和风险等级，高风险进入审批；确认后使用幂等键执行并写 audit log。

继续追问会衍生：衍生知识点：schema validation、auth context、dry-run、approval、idempotency、audit log。

知识展开

概念是什么工程落点面试表达 / 常见坑
schema validationschema validation 只保证字段类型、必填和枚举合法，不保证业务动作安全。在 tool adapter 入口做 JSON schema 校验，然后进入业务校验和权限校验。面试表达：schema 是第一道门，不是安全系统。
auth contextauth context 是服务端可信身份上下文，包括 user_id、tenant_id、role、scope，不应由模型传入。工具执行时从 session/JWT/server context 注入身份，再查 RBAC/ACL。常见坑是让模型传 user_role 或 tenant_id，等于让不可信输入决定权限。
idempotency幂等保证同一个业务请求重复执行不会产生重复副作用。写工具接收 idempotency_key，后端以 key 查询已有结果或锁定执行。强回答要把幂等和 retry 连起来：没有幂等就不能安全重试写操作。
深题 02

工具调用参数通过 schema 校验了，为什么仍然可能危险？

考察点：考 schema 与业务校验的边界。

7+ 分回答骨架：schema 只能约束类型和必填字段，不能证明 payee 存在、用户有权限、金额合理、发票未被支付、操作符合风控。业务校验必须在 tool adapter 或后端服务执行；模型输出永远只是候选请求。

继续追问会衍生：衍生知识点：syntactic validation vs semantic validation、server-side authorization、business invariant。

知识展开

概念是什么工程落点面试表达 / 常见坑
semantic validation语义校验验证业务事实是否成立，比如收款方存在、金额在范围内、发票未支付。调用业务服务或数据库检查 resource 状态、owner、金额、时间、风控规则。面试里要区分语法合法和业务合法，否则答案会停在 demo 层。
server-side authorization权限判断必须在服务端执行，模型和用户只能提出请求，不能决定能否执行。后端用 auth context、resource owner、tenant、role、policy 共同判断。常见坑是让模型“判断用户是否有权限”，这在安全设计上不合格。
business invariant业务不变量是无论模型怎么请求都不能破坏的规则，如已支付发票不能再次付款。写在业务服务或 tool adapter 中，作为执行前的硬校验和测试用例。强回答要说清不变量由代码保护，而不是靠 prompt 约束。
深题 03

支付 API 超时后 agent 想重试，你如何避免重复付款？

考察点：考幂等和外部状态查询。

7+ 分回答骨架：写工具不能盲目 retry。先用 idempotency key 或 payment_request_id 查询外部系统状态：已成功则返回成功，处理中则等待或告知用户，未创建或明确失败才可重试。所有重试要绑定同一个幂等键，trace 中记录 retry reason。

继续追问会衍生：衍生知识点：idempotency key、external state reconciliation、retry policy、at-least-once effects。

知识展开

概念是什么工程落点面试表达 / 常见坑
idempotency key幂等键标识同一次业务意图，不是每次 retry 都生成新 key。由客户端或 runner 为 tool request 生成，和用户、业务对象、动作摘要绑定。如果每次重试生成新 key，就可能绕过幂等导致重复付款。
external state reconciliation外部状态对账是在超时或不确定结果后先查真实状态，再决定下一步。支付超时后查询 payment_status，而不是马上 retry；邮件发送也要查 message id 或 outbox 状态。面试表达：不确定不是失败，先 reconcile 再恢复。
retry policy重试策略要按错误类型区分，不是所有失败都重试三次。transient 可指数退避，validation/permission 不重试，business conflict 需要用户或人工处理。强回答要把 error taxonomy 和 retry policy 绑定。
深题 04

工具返回 200 条搜索结果，如何给模型使用而不污染上下文？

考察点：考 tool adapter 与 context packing。

7+ 分回答骨架：工具层先分页、过滤权限、排序、摘要、保留 source ids；context builder 只传当前决策需要的 top items 和引用。原始结果保存到 state，不全塞 prompt。若模型需要更多，显式调用分页工具。

继续追问会衍生：衍生知识点：result shaping、pagination、citation id、state vs context。

知识展开

概念是什么工程落点面试表达 / 常见坑
result shapingresult shaping 是把工具原始返回整理成模型可用、用户安全、上下文经济的结果。adapter 做字段裁剪、摘要、排序、分页、脱敏和 source id 保留。常见坑是直接把数据库结果给模型，带来泄露、噪声和高 token 成本。
pagination分页让模型按需请求更多结果，而不是一次把所有候选塞进上下文。工具返回 items、next_page_token、total_estimate、query_summary。面试里要说分页还能降低延迟和避免上下文污染。
state vs contextstate 是完整可恢复事实，context 是本轮给模型看的裁剪视图。原始工具结果进 state，context 只放 top items 和必要引用。强回答要说明为什么“存在 state 里”不等于“全放 prompt 里”。
深题 05

如何给 tool calling 做专项 eval？

考察点：考不是只看最终回答。

7+ 分回答骨架：拆工具选择是否正确、参数是否正确、权限是否被拦截、审批是否触发、错误恢复是否正确、最终业务状态是否一致。对 side-effect tool 使用 sandbox 或 dry-run eval，不能在真实环境跑破坏性测试。

继续追问会衍生：衍生知识点：tool-call eval、argument accuracy、policy eval、sandbox eval、state assertion。

知识展开

概念是什么工程落点面试表达 / 常见坑
tool-call eval工具调用评测关注中间动作，而不只看最终文本答案。检查是否选对工具、参数是否正确、风险动作是否审批、错误是否恢复。面试里说“最终答对了”不够，工具路径错可能线上造成副作用。
policy eval策略评测验证越权、审批、敏感动作和拒绝逻辑是否按规则触发。构造禁止场景、边界金额、跨 tenant 资源、prompt injection 请求。强回答要说安全 eval 必须有红线 case，失败不能发布。
sandbox evalsandbox eval 用隔离环境测试写工具和危险工具，避免评测本身造成真实副作用。支付、邮件、删除等工具使用 dry-run、mock service 或测试租户。常见坑是只在真实工具上小流量试，风险不可控。

3. 七个广度题

编号问题准确回答
广度 01Read tool 和 write tool 最大区别是什么？write tool 会改变外部状态，必须有幂等、审批、审计和补偿策略。
广度 02tool description 写得越详细越好吗？要足够让模型正确选择，但不能把安全策略只写在 description；策略要在应用层执行。
广度 03模型能不能决定用户有没有权限？不能。权限由服务端根据 auth context 和资源 ACL 判定。
广度 04为什么工具错误要分类？模型和 runner 需要知道是 transient、validation、permission、business rule 还是 unknown，恢复策略不同。
广度 05什么是 dry-run tool？只计算将要执行的动作、风险和摘要，不产生最终副作用。
广度 06工具返回自然语言可以吗？可以给人看，但机器判断应返回结构化字段、状态码、错误类型和引用 id。
广度 07如何防 prompt injection 诱导工具调用？检索内容视为 data，工具 allowlist、参数校验、权限检查和高风险审批都在模型外执行。

4. 知识索引

schema validation

schema validation 只保证字段类型、必填和枚举合法，不保证业务动作安全。

auth context

auth context 是服务端可信身份上下文，包括 user_id、tenant_id、role、scope，不应由模型传入。

idempotency

幂等保证同一个业务请求重复执行不会产生重复副作用。

semantic validation

语义校验验证业务事实是否成立，比如收款方存在、金额在范围内、发票未支付。

server-side authorization

权限判断必须在服务端执行，模型和用户只能提出请求，不能决定能否执行。

business invariant

业务不变量是无论模型怎么请求都不能破坏的规则，如已支付发票不能再次付款。

idempotency key

幂等键标识同一次业务意图，不是每次 retry 都生成新 key。

external state reconciliation

外部状态对账是在超时或不确定结果后先查真实状态，再决定下一步。

retry policy

重试策略要按错误类型区分，不是所有失败都重试三次。

result shaping

result shaping 是把工具原始返回整理成模型可用、用户安全、上下文经济的结果。

pagination

分页让模型按需请求更多结果，而不是一次把所有候选塞进上下文。

state vs context

state 是完整可恢复事实，context 是本轮给模型看的裁剪视图。

tool-call eval

工具调用评测关注中间动作，而不只看最终文本答案。

policy eval

策略评测验证越权、审批、敏感动作和拒绝逻辑是否按规则触发。

sandbox eval

sandbox eval 用隔离环境测试写工具和危险工具，避免评测本身造成真实副作用。

5. 巩固训练

练习要求自检
8 分钟口述任选一个深题，先给架构，再讲风险、指标、恢复和上线。是否覆盖状态、权限、失败、eval、成本或延迟。
追问压缩把每个深题的回答压缩成 5 句话。每句话必须包含一个工程事实，不能是空泛判断。
反例修正先故意给一个弱回答，再补齐缺失模块。能否说出弱在哪里，以及如何验证强答案。

6. 弱回答红线