Model Context Protocol (MCP) 已作为一种具体的标准发布，旨在将大语言模型 (LLMs) 转化为能够在可衡量、安全的循环中调用外部工具的智能体 (agents)。通过在任何感知 MCP 的宿主 (host) 与任何 MCP 服务端 (server) 之间定义一个共享的“插头”，该协议允许开发者用可预测、可审计的工作流来取代临时编写的代码。
为什么 LLM 需要协议
LLM 只能根据其训练数据预测文本的下一个 token。如果没有额外的逻辑，它无法获取新鲜的事实、写入数据库或触发外部 API。开发者已经构建了将模型封装在循环中的“智能体”：模型请求工具，工具运行，结果反馈，模型决定是继续还是回答用户。
这种循环虽然有效，但如果没有一套通用的规则，很容易产生失控的进程或使系统暴露在非预期的调用中。每增加一个新工具都需要进行定制化集成，导致难以跨项目跟踪 token 使用量、预算限制或安全策略。
MCP 通过将循环的结构和必须通过循环传输的数据进行规范化，填补了这些空白。
MCP 智能体的两部分解剖结构
MCP 将智能体分为定义 (definition) —— 描述智能体能力的模板 —— 和实例 (instance) —— 用户请求的具体执行。
智能体定义 (模板)
- 宿主循环 (Host loop) – 驱动“请求-工具-读取-决策”循环的编排器。
- 系统上下文 (System context) – 塑造模型行为的人设和高层指令。
- MCP 服务端集合 (MCP server set) – 宿主可能调用的可用工具源目录。
- 工具策略 (Tool policy) – 明确列出给定智能体允许使用的工具。
- LLM 选择 (LLM selection) – 用于生成文本推理的具体模型。
- 终止限制 (Termination limits) – 最大迭代次数和 token 预算，以防止无限循环。
- 任务契约 (Task contract) – 对智能体接受的输入和返回的输出格式的正式描述。
- 上下文策略 (Context strategy) – 关于如何修剪或总结对话历史以保持在 token 限制内的规则。
智能体实例 (运行中的任务)
- 目标 (Goal) – 启动循环的用户请求。
- 工作上下文 (Working context) – 累积的历史记录，包括之前的工具结果。
- 凭据 (Credentials) – 调用所选工具所需的 token 或权限集。
- 已消耗预算 (Consumed budget) – 到目前为止消耗的 token 和执行的步骤统计。
这些元素既展示了智能体被允许做什么，也展示了它当前正在做什么。
MCP 如何改变开发流程
在 MCP 出现之前，如果开发者希望 LLM 查询天气 API、从数据库提取一行数据，然后起草报告，则必须为每个端点编写定制的胶水代码。这些代码通常将工具调用隐藏在模型的提示词 (prompt) 内部，导致无法查看哪个请求触发了哪个响应。
有了 MCP，宿主将对话发送给模型，检查模型生成的任何工具请求，由宿主本身分发工具，然后将结果反馈。额外的代码非常少，但可见性是完全的：每一次往返和每一个 token 都会被记录。
这种可见性带来了两个实际好处：
- 成本衡量 – 开发者可以在相同任务上将较便宜的模型与较大的模型进行比较，准确查看每次迭代消耗了多少 token。
- 安全审计 – 工具策略和凭据检查发生在模型之外，防止模型在不经意间调用未经授权的服务。
尚未定义的内容
MCP 规定了对话的形式以及随之传输的元数据，但它并不规定工具内部是如何实现的。
下一步值得关注的内容
- 指标套件 (Metric suites) – 本系列的下一篇文章将提供一份开发者应跟踪的数字清单（token 消耗、迭代次数、每个工具的延迟）。这些指标将成为任何基于 MCP 的智能体的标准健康检查。
核心要点
Model Context Protocol 为 LLM 智能体提供了一个共享的、可审计的结构，将智能体“能做什么”与“当前正在做什么”分离开来。通过将不透明的工具调用转变为透明的循环，MCP 使这些衡量成为可能。