最近几年，“智能体（Agent）”和 “MCP” 频繁出现在 AI 产品和开发文档中。它们经常和大语言模型（LLM）一起出现，但三者并不是同一个概念：模型负责理解和生成，智能体负责围绕目标组织行动，MCP 则是一套让模型调用外部能力的通用协议。

本文从开发者的角度梳理这些概念，并用一个“查询订单并生成说明”的例子说明它们是如何协作的。

一、什么是智能体

智能体可以理解为：能够接收目标，结合上下文进行决策，并通过工具执行一系列动作，直到完成任务或明确需要人工介入的软件系统。

一个完整的智能体通常包含以下部分：

• 目标（Goal）：用户希望得到的结果，例如“找出本月金额最高的三个订单，并说明原因”。
• 模型（Model）：负责理解自然语言、拆解任务、选择下一步动作和组织结果。模型可以是云端 API，也可以是本地模型。
• 上下文与记忆（Context/Memory）：包括当前对话、用户偏好、历史任务、检索到的文档等。上下文是一次任务的工作记忆，长期记忆则需要单独存储和治理。
• 能力（Capability）：智能体可以调用的工具、知识和工作流，例如查询数据库、发送邮件、执行代码或检索企业文档。
• 运行时（Runtime）：负责循环调度、权限校验、超时重试、状态保存、日志和人工确认。

因此，调用一次模型接口并不一定是智能体。只有当系统让模型根据目标选择动作、观察结果，再决定下一步时，才具有智能体的基本特征。

1. 智能体的基本循环

常见的执行过程可以概括为：

接收目标
   ↓
理解上下文并制定计划
   ↓
选择并调用能力
   ↓
读取执行结果（观察）
   ↓
继续行动、调整计划，或返回最终结果

用伪代码表示，就是一个受约束的循环：

while not finished:
    decision = model(goal, context, available_capabilities)
    if decision is final_answer:
        return decision
    if decision needs approval:
        ask_human(decision)
    observation = runtime.invoke(decision.tool, decision.arguments)
    context.append(decision, observation)

这个循环也解释了智能体和普通聊天机器人的区别：聊天机器人通常只生成下一条回复，而智能体可以在回复前后执行真实动作，并根据结果修正计划。

2. 智能体、工作流和自动化的区别

三者并没有绝对的高低之分，关键在于决策权由谁掌握：

形式	下一步由谁决定	适合场景
固定自动化	代码中的规则	流程稳定、要求强确定性的任务
工作流	预先编排的节点和分支	审批、数据同步、批处理
智能体	模型根据目标和观察结果选择	输入变化大、步骤无法完全预先枚举的任务

实际系统往往是混合形态：把支付、删除数据等高风险步骤写成固定流程，让模型只负责分类、填充参数和处理非结构化内容。能用确定性代码解决的问题，不必强行交给模型。

二、什么是“能力”

在智能体语境中，“能力”不是模型的一句宣传语，而是智能体被允许并且能够可靠完成的一类动作。它至少包含输入约束、执行逻辑和输出约定。

1. 能力的四个层次

可以把能力分成四层：

1. 知识能力：知道什么，例如企业制度、产品文档和数据库字典。知识通常通过提示词、检索增强生成（RAG）或上下文注入提供。
2. 推理能力：能做什么判断，例如比较方案、拆解任务、识别异常。它主要来自模型本身，也受提示词和上下文质量影响。
3. 工具能力：能调用什么外部系统，例如 HTTP API、数据库、搜索引擎、文件系统和代码执行器。
4. 流程能力：能否按业务规则完成一组动作，例如“读取工单 → 查询库存 → 创建补货单 → 通知负责人”。流程通常需要运行时负责状态、重试和补偿。

这四层容易混淆。例如，模型“知道如何退款”属于知识能力；真正调用支付系统完成退款属于工具能力；按照审批、幂等和对账规则完成退款则属于流程能力。

2. 一个好的工具定义

工具要像稳定的 API，而不是给模型一段模糊说明。至少应明确：

• 名称和用途，避免一个工具承担多个不相关动作；
• 参数类型、必填项、枚举值和示例；
• 返回结构，以及业务错误和系统错误的区别；
• 权限范围、超时时间、幂等方式和副作用；
• 哪些情况必须先向用户确认。

例如，“查询订单”可以定义为只读能力：

{
  "name": "get_order",
  "description": "按订单号查询订单的状态、金额和商品摘要。只读，不会修改订单。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单号，例如 ORD-20260819-001"
      }
    },
    "required": ["order_id"],
    "additionalProperties": false
  }
}

能力的质量可以从三个维度评估：模型是否选得对、参数是否传得对、执行结果是否可验证。工具越多不代表智能体越强，重复、含义重叠或权限过大的工具反而会增加误调用的概率。

三、MCP 是什么

MCP（Model Context Protocol，模型上下文协议）是一套开放协议，用于标准化 AI 应用与外部数据源、工具和提示模板之间的连接。它解决的不是“模型如何思考”，而是“模型如何以统一方式发现和使用外部能力”。

没有统一协议时，每个 AI 应用都要为每个系统编写一套适配器：数据库一套、Git 仓库一套、浏览器又一套。MCP 把连接方式抽象出来，使同一个 MCP 服务可以被多个支持 MCP 的客户端使用。

1. MCP 中的角色

MCP 通常包含三个角色：

• Host：承载 AI 功能的应用，例如桌面助手、IDE 或企业客服系统。
• MCP Client：Host 中负责与某个 MCP 服务建立连接、协商能力并转发请求的客户端。
• MCP Server：对外暴露数据和动作的服务，可以是本地进程，也可以是远程服务。

关系可以简化为：

用户 ↔ Host（模型与运行时） ↔ MCP Client ↔ MCP Server ↔ 数据库/API/文件系统

一个 Host 可以同时连接多个 MCP Server。每个 Server 只负责清晰、有限的领域，例如代码仓库、工单系统或公司知识库。

2. MCP 提供的三类原语

MCP 的核心原语通常分为三类：

• Tools（工具）：可被模型调用的动作，例如查询订单、创建工单、执行搜索。工具可能产生副作用，因此需要权限和确认机制。
• Resources（资源）：可被客户端读取的上下文数据，例如文件、文档、数据库表结构或某个 URI 对应的内容。资源本身通常表示数据，不等同于“执行动作”。
• Prompts（提示模板）：服务端提供的、可复用的提示模板，用于规范某类任务的上下文组织方式。

除此之外，协议还包含初始化、能力协商、通知、错误处理等基础流程。底层传输可以根据部署方式选择本地标准输入输出（stdio）或远程 HTTP 等方式，具体以所使用的 MCP 版本和 SDK 为准。

3. 一次 MCP 工具调用发生了什么

以“查询订单”为例，调用链大致如下：

1. Host 启动 MCP Client，与订单 MCP Server 建立连接并完成初始化。
2. Client 获取 Server 暴露的工具列表和输入 Schema，将可用能力提供给模型。
3. 用户提出“查询 ORD-20260819-001 的状态”。模型决定调用 get_order，生成符合 Schema 的参数。
4. Client 将工具名和参数发送给 Server。Server 校验身份、权限和参数，再调用订单 API。
5. Server 返回结构化结果或结构化错误。Client 把结果交回 Host，模型据此生成给用户的说明。

MCP 只规定连接和消息交互的约定，并不替应用决定模型、数据库、权限策略或业务流程。协议统一了插座，具体接入什么设备仍由应用和服务端负责。

四、MCP 与函数调用、插件有什么区别

这些概念相关但不等价：

• 函数调用（tool/function calling）通常是某个模型 API 的调用格式，描述模型如何输出函数名和参数。函数真正如何执行，由应用代码决定。
• 插件是产品层面的扩展机制，可能包含 UI、认证、计费和发布流程，范围比协议更大。
• MCP是跨 Host 和 Server 的连接协议，规定如何发现工具、读取资源、调用工具和处理消息。它可以承载函数调用，但不替代模型 API 或业务插件体系。

可以把它们看成不同层次：模型 API 负责“表达调用意图”，MCP 负责“把意图传到标准化的能力提供方”，业务服务负责“真正执行并承担结果”。

五、一个最小的智能体架构

一个可落地的最小系统通常包括：

用户请求
  ↓
会话与权限层 ── 记录用户、租户、授权范围
  ↓
智能体运行时 ── 上下文、循环、预算、超时、重试、人工确认
  ↓
模型 ── 计划下一步或生成最终答案
  ↓
能力注册表 ── 内部函数、HTTP 工具、MCP 工具、检索器
  ↓
外部系统 ── 数据库、搜索、文件、企业 API

实现时建议先从单智能体和少量只读工具开始，给每次任务设置最大步数、Token 预算和超时时间，并保存完整的调用轨迹。等单个任务稳定后，再考虑多智能体协作；多一个智能体就多一组通信、权限和故障边界。

六、安全与可靠性

智能体能够调用外部系统后，风险会从“回答错误”扩大到“执行错误”。至少需要关注以下事项：

权限最小化

工具使用独立的服务账号和最小权限。读取订单的工具不应同时拥有修改订单的权限，MCP Server 也不应因为方便而直接暴露整个文件系统或数据库。

人工确认和副作用分级

把工具分为只读、可撤销写入、不可逆操作三类。删除、付款、发信、发布代码等操作应在执行前展示目标、参数和影响范围，并要求明确确认。

输入和输出校验

模型输出永远是不可信输入。运行时要按 Schema 校验参数，限制字符串长度、URL 域名、SQL 范围和文件路径；Server 返回的数据也应限制大小并过滤敏感信息。

可观测性与评估

记录每次任务的提示版本、模型版本、工具选择、参数、耗时、错误和最终结果。通过一组固定测试问题评估任务完成率、误调用率、平均步数和人工接管率，而不是只看回复是否“像人”。

防止提示注入

网页、文档和工具返回内容可能包含诱导模型越权的指令。外部内容应被标记为数据而不是系统指令；高风险动作必须由运行时策略再次判断，不能只依赖模型自觉。

七、从哪里开始实践

可以按下面的顺序做一个小项目：

1. 先选一个边界清楚、结果可验证的任务，例如“根据内部文档回答部署问题”。
2. 先用固定工作流或普通函数实现工具，明确输入输出和权限，再接入模型。
3. 加入一个只读 MCP Server，让模型完成资源发现和工具调用。
4. 为异常、超时、重复调用和权限拒绝设计测试用例。
5. 最后再开放写入能力，并增加人工确认、审计日志和回滚方案。

总结

智能体不是一个更大的聊天窗口，而是“模型 + 上下文 + 能力 + 运行时”的组合。模型提供理解和推理，能力让系统可以接触真实世界，运行时则负责把这些动作限制在可控的边界内。

MCP 的价值在于把能力连接标准化：Host 可以发现并使用不同 Server 提供的 Tools、Resources 和 Prompts，而不必为每个系统重复设计一套私有接口。但协议本身不会自动带来可靠性和安全性，权限、校验、确认、审计和评估仍然是应用开发者的责任。

当一个任务可以被清晰描述、动作有明确边界、结果能够验证时，它就适合成为智能体的第一个落地点。