模块 4 架构师问答题 — 工具使用

每题先自己答，再看参考要点。场景题格式：Scenario / Constraints / Options / Best choice / Why / Why others are weaker / Tradeoffs / What would change the answer。

Q1. 场景题：客服 agent 误删生产数据

Scenario：客服 agent 有 delete_order_record 工具。某天 Claude 在多轮上下文里"自作主张"调了它（用户只说"帮我清理一下我的订单页面"）。事后复盘。 Constraints：不能取消工具（业务需要）；要杜绝未授权删除。 Options：(a) system prompt 加"未经明确用户确认不得删除" (b) 工具改名为 dangerous_delete 吓退模型 (c) 应用层人审门：删除类 tool_use 进审批队列 (d) 移除工具，改人工流程 Best choice：。仅对删除等不可逆动作生效——审核延迟可接受。 Why：唯一的强制点。LLM 指令不是授权机制——prompt 约束是概率性的（可被 prompt injection 绕过），代码拒绝是确定性的。人审拒绝后以 is_error 回传，Claude 能向用户解释。 Why others are weaker： 单靠概率约束，注入/长上下文漂移即可击穿； 名字工程不改变权限模型； 牺牲了 agent 化收益。 Tradeoffs：删除类操作延迟从秒级到分钟级；要设计审批 UI 与超时策略（默认拒绝）。 What would change the answer**：若删除有 30 天回收站（可逆），可降级为"执行+审计日志"。

Q2. "什么由 Claude 决定，什么由代码决定"——给出你的分界线与原则。

参考要点：

• Claude：工具选择（auto 下）、参数生成、结果综合、错误后的改道决策——判断类
• 代码：权限与审批、参数校验（schema/strict）、执行与重试、结果裁剪、审计——强制与执行类
• 原则：判断交给概率组件，强制交给确定性组件；凡是"违反了会出事故"的规则，必须落在代码（模块 11 的 LLM instruction vs application enforcement）

Q3. 工具报 500 时，三种处理方式的后果分别是什么？

参考要点：

1. 只打日志、向上抛异常：用户看到系统错误，Claude 失去改道机会（最差）
2. 应用层静默重试：可能恢复（瞬时故障），但 Claude 不知道在重试；重试烧钱
3. 回传 is_error: true + 指导性错误消息：Claude 能换工具/告知用户/调整参数（官方推荐）；错误消息质量直接决定恢复效果（"failed" vs "HTTP 500, retry after 60s, 或改用 forecast 工具"）

（来源: https://platform.claude.com/docs/en/agents-and-tools/tool-use/handle-tool-calls（访问于 2026-08-30））

Q4. 你的 agent 每轮工具调用都重新生成 tools 数组的 JSON（字段顺序不同）。有什么隐患？

参考要点：

• 缓存的是完整前缀（tools → system → messages 顺序）；tools 内容变化 → 前缀 hash 变 → 每轮 cache miss，多花 0.9x 输入费 + 占 ITPM（模块 3）
• 正确做法：工具定义序列化后冻结（同 ID 同字节），版本化变更
• 附带：tool_choice 切换也作废 messages 段缓存

Q5. 什么时候用 server tools 而不是自建 client tool？

参考要点：

• Server tools（web_search/web_fetch/code_execution/MCP connector）：Anthropic 执行、结果直接进响应、无需你写执行器与重试——没有自有系统依赖的通用能力首选
• 自建：需要访问你的数据与系统（订单库、内部 API）、需要自定义权限门/审计、需要把结果裁剪成高信号
• 混合注意：同轮 client tool_use + 未完成 server tool 的回传规则（只能回传 tool_result block）

（来源: https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview（访问于 2026-08-30））

Q6. 多步 agent 回路里，如何防止"无限调工具"？

参考要点：

• 应用层最大步数与token 预算（模块 1：每轮全历史都计费）
• 观察重复调用模式（同工具同参数连续出现 → 干预）
• system prompt 给出停止引导，但停止条件必须代码兜底（又是"判断 vs 强制"）
• stop_reason 状态机：只有 end_turn/stop_sequence 是自然终点

（模块 08 展开完整 agent loop）

Q7. 描述字段写"当用户问天气时使用此工具"为什么还不够？

参考要点：

• 官方要求描述涵盖：做什么、何时用、何时不用、参数含义、行为限制、返回内容——至少 3–4 句（来源: define-tools，同上）
• 反面后果：不该调时调（把"天气"隐喻当字面）、该问参数时瞎猜（Sonnet 更容易 infer 缺参）
• description 是给模型看的 API 文档，质量 = 选择准确率

Q8. 为什么说"把网页内容搬进 system prompt"是安全反模式？

参考要点：

• 官方明确：tool_result 中不可控内容（网页/邮件/上传/第三方 API）是间接 prompt injection 载体；应留在 tool_result block，不要进 system 或用户 text（来源: handle-tool-calls Warning，同上）
• system prompt 位置权重高，注入指令更易被当作权威指令执行
• 纵深防御：来源标记 + 权限门（执行层）+ 模块 11 的注入缓解