导语：MCP（Model Context Protocol）正在成为 AI 应用连接外部工具、数据源与业务系统的重要协议。对开发者来说，真正的难点不只是“让模型能调用工具”，而是如何在工具调用前后注入正确上下文，并在多轮对话中安全、可控地管理会话状态。🚀

一、为什么工具调用需要上下文注入

在 MCP 中，工具通常由服务端暴露，客户端或宿主应用负责发现并调用。官方规范将工具描述为可被模型调用的能力，例如查询数据库、调用 API 或执行计算，并要求工具具备名称、描述和输入 schema 等元数据 [1]。这意味着工具本身不应依赖“模型猜测”，而应通过结构化参数获得完成任务所需的信息。

所谓上下文注入，并不是把整段聊天记录无差别塞进工具参数，而是在调用工具前，把与当前任务相关的身份、权限、业务对象、环境变量和用户意图整理成最小必要数据。比如调用“创建工单”工具时，理想参数应包括用户 ID、问题摘要、优先级、关联产品和授权范围，而不是把几十轮聊天原文全部传入。这样既能降低 token 消耗，也能减少敏感信息泄露风险。🔐

二、上下文注入的三类来源

1. 用户显式输入

用户在当前对话中直接给出的内容，是最可靠的上下文来源。例如“帮我查一下订单 1024 的物流状态”，其中“订单 1024”就是工具调用的核心参数。实践中应优先从当前轮输入提取参数，并在缺失关键字段时让模型或前端引导用户补充，而不是自动推断。

2. 会话内短期状态

多轮对话中，用户可能先说“查一下我的订单”，随后补充“就是昨天买的那台显示器”。此时系统需要维护短期会话状态，将“订单查询”这个任务、候选订单、用户补充描述等信息关联起来。短期状态适合保存任务进度、临时选择、上一步工具返回摘要等内容，但不适合长期存储敏感凭据。

3. 外部业务上下文

外部上下文通常来自账号系统、CRM、工单平台、代码仓库或知识库。MCP 还定义了 resources、prompts 等能力，用于向 AI 应用提供数据和可复用提示结构；而 tools 更偏向“动作”，resources 更偏向“可读取上下文” [1]。因此，设计时应避免把所有能力都做成工具，静态资料、只读文档和配置说明更适合做成资源。

三、工具调用上下文注入的实践步骤

1. 定义工具边界：先明确工具是读操作还是写操作，是否会产生副作用。查询余额、读取文档属于低风险操作；删除数据、发起付款、发布代码则必须增加确认机制。
2. 设计最小参数：为每个工具定义清晰的 input schema，只接收完成任务所需字段。不要让工具接收“任意 prompt”或“完整会话文本”，否则很容易扩大攻击面。
3. 建立上下文组装层：在模型决定调用工具后，由宿主应用或中间层负责把当前用户输入、会话状态和业务上下文合并成结构化参数。
4. 加入权限校验：工具执行前应再次验证用户身份、租户、角色和资源访问范围，而不是只相信模型生成的参数。
5. 返回可压缩结果：工具返回结果应包含必要字段和可读摘要，避免返回海量原始数据。对于大型结果，可返回分页、引用 ID 或资源 URI。

四、会话状态管理的核心原则

会话状态管理的目标，是让 AI 在多轮交互中“记得该记的，忘掉该忘的”。一个推荐做法是把状态拆成四层：当前轮输入、短期任务状态、用户偏好状态和持久业务状态。当前轮输入用于立即解析意图；短期任务状态用于完成连续操作；用户偏好状态需要明确授权后保存；持久业务状态则应始终放在业务系统中，而不是放在模型上下文里。

对于 MCP 工具调用，状态不应只存在于模型记忆中。更稳妥的方式是使用 requestId、sessionId、taskId 或 workflowId 追踪任务，并在服务端保存状态快照。这样即使模型输出发生偏差，系统也可以通过确定性的状态机判断当前处于“待补充参数”“待用户确认”“工具执行中”还是“已完成”。⚙️

五、安全与可控性：不要把 Roots 当权限系统

MCP 中曾有 Roots 机制，用于让客户端向服务端暴露相关文件夹或工作区。根据 2026-07-28 版本规范，Roots 已被标记为 deprecated，新实现不建议继续采用；规范也明确说明 Roots 只是信息性指导，并不是访问控制机制 [2]。因此，如果工具需要访问文件、目录或代码仓库，仍应在工具服务端实现真实的鉴权、路径校验和操作审计。

同样，Sampling 机制允许服务端请求客户端模型生成内容，早期规范强调应有人类参与审核，用户应能查看、编辑和拒绝采样请求 [3]。在业务场景中，这提醒我们：凡是会触发外部调用、生成关键内容或改变状态的动作，都不应完全交给模型自动执行。

六、推荐的状态结构示例

一个实用的会话状态可以包含：sessionId、userId、currentIntent、requiredFields、collectedFields、lastToolCall、lastToolResultSummary、pendingConfirmation、expiresAt。这样既能支持多轮补全，也方便做超时清理、审计追踪和失败恢复。

例如用户要“帮我申请退款”，系统可以先识别 currentIntent 为 refund_request，再检查 requiredFields 是否包括订单号、退款原因和退款方式。如果订单号缺失，系统进入待补充状态；如果金额超过策略阈值，则进入 pendingConfirmation；如果用户确认，再调用退款工具。整个过程由状态驱动，而不是依赖模型自由发挥。

七、常见误区

• 误区一：把完整聊天记录传给工具。这会增加隐私风险，也会让工具行为难以测试。更好的做法是传结构化字段。
• 误区二：把权限判断交给模型。模型可以辅助判断意图，但最终权限必须由确定性代码和业务系统控制。
• 误区三：状态永久保存。短期任务状态应设置过期时间，敏感字段应加密或不落库。
• 误区四：工具返回越多越好。工具结果应服务于下一步决策，必要时返回摘要、分页和引用标识。

总结

MCP 工具调用的价值，在于把 AI 从“只会回答”扩展到“能够执行”。但要让执行可靠可控，关键不在于暴露更多工具，而在于做好上下文注入、参数约束、权限校验和会话状态管理。✅

实践中可以遵循一个简单原则：模型负责理解意图，系统负责组装上下文，工具负责执行动作，服务端负责验证权限，状态机负责管理流程。只有把这几层边界划清，MCP 才能真正支撑企业级 AI 应用，而不是停留在演示级工具调用。