ARTICLE · 1294135
AI Agent 干活,模型其实不碰工具
你问 AI 一句「昨晚订单服务报错为什么变多，出个趋势图」，几十秒后拿到一段结论和一张图。看上去是模型查了日志、画了图、写了答案。
其实模型一个工具都没碰。我按 MCP 2026-07-28 版规范，把这次任务拆成 19 步，逐步记下每一步是谁发出的：Host 9 步，MCP Server 4 步，模型 3 步，用户 2 步，业务系统 1 步。
核心判断：模型只决定下一步做什么。能不能做、怎么做、做完能不能交，是 Host 的事。MCP 只管把调用按标准送到。
这篇按顺序讲四件事：模型这 3 次输出了什么；开工前它怎么知道有哪些工具；两圈调用里每一步发生了什么；出错往哪走、上线前查什么。文中的服务名、数据和工具名都是示例。
本文看点
01
模型 3 次输出了什么
02
新版 MCP 的三处变化
03
上线前五问
01
RESULT
模型这 3 次，输出的全部内容
上图下半部分就是模型 3 次输出的原文。第 3 步是一个 tool_use，要查订单服务昨晚 20 点以后的报错；第 10 步又是一个 tool_use，要画每小时报错趋势；第 18 步是一段文字，也就是最终回答。
它不连日志平台，不发网络请求，也不判断这次调用该不该放行。它输出的只是一段「我想调哪个工具、填什么参数」的结构化文字，真正去调的是 Host。
Host 指承载 Agent 的那个应用。接了 MCP 的 Claude Code、Codex，各家的 Agent 平台，都在扮演这个角色。名字不一样，干的是同一份活。
02
PREP
开工前：模型会用哪些工具，是 Host 每次告诉它
一个 Server 配一个 Client。Host 每接一个 MCP Server，就在自己内部建一个 Client，一对一。Client 不是单独部署的服务。
先问会什么。Client 发 tools/list，拿回每个工具的名字、用途和参数格式。新版规范给清单加了有效期 ttlMs，过期再取；服务端也可以按调用方的权限，只返回其中一部分工具。
{"resultType": "complete",
"tools": [{
"name": "query_errors",
"description": "按服务和时段查报错",
"inputSchema": {
"type": "object",
"properties": {
"service": {"type": "string"},
"since": {"type": "string"}},
"required": [
"service", "since"]}}],
"ttlMs": 300000}
首图里模型填的 service、since，就是这份定义规定的。
每个请求都自报家门。2026-07-28 版取消了开场握手和协议级会话。每个请求都在 _meta 里带上协议版本和客户端能力，哪台服务器接到都能处理。
模型那一侧也一样不记事。以 Claude API 为例，工具定义放在每次请求的 tools 参数里，带着工具结果的下一次请求还要再带一遍。
模型能看到的工具，只有 Host 给它的那一份。
03
ROUND 1
第 1 圈：查日志
第 1—2 步：用户提问，Host 把问题、历史和工具定义一起发给模型。
第 3 步：模型决定调 query_errors，参数是订单服务、昨晚 20 点起。它只出主意，自己不执行。
第 4 步：Host 把关。参数合不合格式，这个工具用户授权过没有。这次是只读查询，按事先授权放行。
第 5—8 步：Host 里的 Client 发出 tools/call；Server 核对输入和权限后去日志平台取数；结果分两份回来，content 是给人和模型读的文本，structuredContent 是按约定格式的结构化数据。
第 9 步：Host 把结果写回上下文，交还模型。工具结果只当数据，不当指令。
要是用户没说查哪个服务呢？第 3 步应该先别调工具，由模型反问「查哪个服务」，补完再回到第 2 步。Claude 的官方文档写得很直白：必填参数缺失时，有的模型会反问，有的会自己猜一个值填进去，这一点不保证。
所以「查哪个服务、超时算不算报错」这类口径，最好在提问时说清楚。MCP 只管调用格式，口径它不管。
04
ROUND 2
第 2 圈：缺信息就退回，带答案重发
第 2 圈的调用、把关、写回都和第 1 圈一样，只多一件事：画图服务要先问一句「存个人空间还是团队空间」。
旧版规范里，服务端可以主动发请求问客户端。2026-07-28 版取消了这种做法，这是一处不兼容旧版的改动。现在的流程是：
服务端在 tools/call 的结果里返回 input_required，附上要问的问题和一份办理状态 requestState，这次请求到此结束。
Host 弹表单问用户，用户选「个人空间」。
客户端带着答案和原样的办理状态，再发一次 tools/call，请求编号换新的。
为什么这么绕？因为没有会话，服务端不把请求挂着等人。重发的请求自带全部信息，哪台服务器接到都能接着办。
代价落在办理状态上：客户端只能原样带回，不能看也不能改；它要是影响权限或业务逻辑，服务端必须校验，校验不过就拒绝。
第 17—19 步，图表写回模型，模型不再调工具，给出最终回答。注意，这只是候选答案。
我的判断是：模型可以说「我做完了」，能不能交付由 Host 决定。原因是任务的要求和每一步的执行记录都在 Host 手里，对照要求核对有没有做完，只有它做得了。
05
CHECK
出错往哪走，上线前查什么
错误分两类，去处不同。
执行错误：日期格式不对、接口失败、业务规则不允许。服务端在结果里标 isError: true，写清原因。规范要求客户端把这类错误交给模型，让它改参数重来。
{"resultType": "complete",
"isError": true,
"content": [{
"type": "text",
"text":
"since 格式应为 2026-10-29T20:00"}]}
协议错误：工具不存在、请求格式不对，走 JSON-RPC 报错。模型多半修不了，由 Host 处理。
{"error": {
"code": -32602,
"message": "Unknown tool: query_error"}}
兜底的是 Host：每次调用有超时，整轮最多转几圈，到了就停。
上线前，问 Host 一侧五句：
每次调用工具，人能拒绝吗？
写操作之前，参数先给人看了吗？
工具结果交给模型前，校验过吗？
每次调用都有超时，整轮有圈数上限吗？
每次调用都留了审计日志吗？
Server 一侧，规范写的是必须做：校验输入、控制访问、限流、清洗输出。
06
LIMITS
什么时候不适用
这个例子是一次只读查询加一次画图，流程最短。带写操作的 Agent，Host 至少还要多一步：把参数给人看，批了才发。
不是所有 Agent 都走 MCP。很多工具直接写在 Host 里，模型照样只输出 tool_use，由 Host 去执行。MCP 解决的是「工具由别人提供时，怎么按标准接进来」。
19 步、模型 3 步，是这个例子的数。换一个要多调几次工具的任务，数字会变；分工不变。
MCP 统一了怎么接，没替你决定谁能调什么。
下次评估一个 Agent，先别问它用的是哪个模型，先看 Host 这一侧那 9 步做得怎么样。
完整 19 步放在下面这张长图里。
