入门教程里说"模型输出 JSON，你的代码执行"。现在把抽象拆掉，看真实 API 层面到底发生了几次 HTTP 往返、每条消息长什么样。关键认知：所谓"一次工具调用"，其实是两次完整的模型调用夹着一次你自己的代码执行——模型与外部世界之间永远隔着你的程序。点击"下一步"逐帧播放👇
① 无状态：API 不记得上一次请求，所以请求 ② 必须把全部历史（包括模型自己的 tool_use）原样带上；② id 配对：tool_result 靠 tool_use_id 和调用一一对应，这是并行调用不串线的关键；③ stop_reason：你的循环就是在判断它——是 tool_use 就执行工具再发一轮，是 end_turn 就把文字给用户。Agent 框架的核心就这一个 while 循环。
工具定义是模型唯一的"使用说明书"。Schema 里每个字段都在影响模型行为——description 影响"何时调用"，类型与约束影响"怎么传参"。点击左侧代码里的高亮字段，看它分别起什么作用👇
Schema 的语法是死的，描述的写法才是手艺。同一个查订单工具，两种写法对比👇
t 是谜语：time？type？模型会按概率乱猜一个把工具描述给一个没看过你代码的新同事读：如果 ta 能仅凭描述正确使用这个接口，模型大概率也能。反过来，模型反复用错的工具，先别怪模型——回头读一遍自己的 description。
当几件事互相不依赖（查北京天气 + 查上海天气），模型可以在同一条回复里输出多个 tool_use 块，你的代码并发执行，再把多个结果一次性塞回去——往返次数和延迟都省一半。看报文怎么写👇
有依赖关系的调用没法并行：得先 search_flights 拿到航班号，才能 book_flight。模型一般能自己判断依赖，但写操作要格外小心——并行发两个"扣款"就是事故。常见护栏：写操作强制串行、一轮只允许一个高危调用。
每个工具定义都常驻上下文，几十个工具就是几千 token，而且职责重叠的工具会让模型选错。三个缓解思路：① 合并同类（一个 search 带 type 参数，胜过五个 search_xxx）；② 按任务动态挂载工具子集；③ 分层——前面没用的工具这轮就别给。
工具会超时、会 404、会被传错参数。Agent 工程的妙处在于：错误信息本身也是观察结果——把它作为 tool_result（标记 is_error: true）喂回模型，模型往往能自己纠错。逐步看一个真实的自愈过程👇
模型能不能自愈，取决于错误信息的质量。"Error 500" 没法自愈；"商品名不存在，可用的相近商品：iphone-17-pro, iphone-17"就能。把错误消息当成给模型的提示词来写：说清哪里错了、合法值长什么样、下一步可以试什么。
自愈也可能变成死循环：同样的调用反复失败、模型反复重试。生产环境必须有：① 步数/花费上限；② 重复检测（连续 N 次相同调用直接熔断）；③ 幂等设计——重试"创建订单"不应创建两单，给写操作带去重键（idempotency key）。
前面的一切都有个隐含成本：每个工具都要你亲手写定义、写执行代码。M 个 Agent 应用 × N 个工具 = M×N 次重复集成。MCP 把它变成 M+N：工具方实现一次 Server，任何支持 MCP 的应用都能即插即用。点击下面三个角色，看各自负责什么👇
MCP Server 暴露的能力不止工具一种，协议定义了三类原语（primitives）：
create_issue、run_queryfile:///readme.md、数据库 schema/summarize-pr 带好了最佳实践提示词接入第三方 MCP Server，等于把它的工具描述和返回内容都放进你的上下文——恶意 server 可以在描述里藏注入指令，或在返回里夹带"忽略之前的指示"。接 server 前像审计依赖库一样审计它，高危工具保持人工确认。
5 道题。答错没关系，解析比答案重要。