在 Agent 小知识系列第一季，我们搭起了 Agent 持续工作的内部骨架。现在进入第二季，我们把视角移向外部：这些 Agent 怎样连接工具、业务系统，以及其他 Agent？

MCP（模型上下文协议）提供了一套标准方式，让 Agent 应用发现并使用外部系统提供的上下文和能力。上一期关心的是复杂任务怎样在主 Agent 与子 Agent 之间分工；这一期沿用代码仓库场景，转而观察同一任务需要的资料、模板和操作，应该怎样通过 MCP 分别接入。

先看一个常见的接入问题：某个团队为代码仓库开发了 MCP Server，希望 Agent 能排查持续集成测试失败。为了让模型“什么都能调”，团队把读取服务说明、获取测试日志、加载排查模板、搜索代码、运行测试和修改文件全部注册成 Tool。接口虽然都能调用，但资料、任务入口和外部操作被压进了同一张 Tool 清单，客户端无法针对不同职责采用合适的交互方式。要重新分工，可以用 Resources 承接上下文数据，用 Prompts 组织任务入口，用 Tools 发起操作。

一张图概览 MCP 的三类能力分工

图 1. 从全部塞进 Tool 到 Resources、Prompts、Tools 各归其位

把所有能力都做成 Tool 会混淆职责

理解上面那张图里的 Tool 清单前，只需先看 MCP 中的三个角色。

MCP Host 是承载模型或 Agent 体验的宿主应用。Host 内的 MCP Client 负责与某个 MCP Server 进行协议交互。Server 通过能力声明，向客户端提供 Tools、Resources、Prompts 中的一项或多项。一个 Server 可以只提供 Tools，也可以同时提供 Resources 和 Prompts；协议没有要求每个 Server 必须集齐三类能力。本文统一依据 MCP 2026-07-28 稳定规范，旧版初始化与会话流程不进入本期讨论。

回到测试失败案例，最初的 Server 暴露了这样一组 Tools：

get_service_readme
get_ci_log
get_debugging_guide
start_failure_diagnosis
search_code
run_tests
apply_patch

第四期 「Agent 小知识｜让 Agent 调对工具：输入输出契约的设计」讨论过 Tool 的输入输出契约：清楚的名称、描述、参数和返回结果能帮助 Agent 准确调用工具。现在继续往前一步，判断一项能力是否应该被设计成 Tool。

上图中，服务说明和测试日志属于可读取的上下文数据，排查模板属于可复用的任务入口，代码搜索、测试运行和补丁写入则需要发起调用。把它们压进同一种接口后，客户端难以直接利用 MCP 为资源浏览、上下文装载和模板选择提供的不同交互路径。

重新分工可以先从需要发起调用的能力开始。

Tool：让客户端调用外部能力

Tool 表示一项可以被客户端调用的操作或计算能力。客户端通过 tools/list 发现 Server 提供了哪些 Tool，再使用 tools/call 发起调用。

Tool 以名称作为标识，并通过必需的 inputSchema 声明参数；没有业务参数时，也要使用有效的空对象结构。标题、描述和 outputSchema 可以按需提供。调用结束后，Server 返回结果，或者报告协议层与执行层错误。Host 再决定怎样把结果呈现给用户、交给模型或用于后续步骤。

在 payment-service 的排查任务里，下面三项适合继续以 Tool 的形式提供：

这组例子说明，Tool 不能直接等同于“有副作用的动作”。数据库查询、代码搜索和格式转换都可以通过 Tool 提供，即使它们不修改外部状态。

判断某项能力是否适合成为 Tool，可以先看客户端是否需要发起一次调用，并接收这次调用产生的结果。调用会不会改变状态，还要根据具体 Tool 的行为继续区分。不过，排查任务不只需要发起操作，还要读取服务说明、测试规范和日志。如果这些内容继续包装成 Tool，“调用操作”和“取得上下文”就会混在一起。MCP 用 Resource 承接后一类需求。

Resource：让上下文数据可以被寻址

Resource 表示 Server 通过 URI 暴露的可读取数据。客户端可以用 resources/list 发现固定资源，用 resources/templates/list 发现带参数的 URI 模板，再通过 resources/read 读取具体内容。

案例中的服务说明、测试规范和持续集成日志可以这样组织：

repo://payment-service/readme
repo://payment-service/testing-guide
ci://runs/{run_id}/log

前两项是地址明确的资料，第三项使用资源模板，不同的 run_id 对应不同日志。Resource 的内容既可以来自文件，也可以来自数据库、API 或应用内部生成的数据；读取结果可以是文本，也可以是以 blob 承载的二进制内容。URI 为资源提供明确的标识和读取入口，因此 Resource 不只代表静态文件。

Resource 与返回数据的 Tool 确实存在交叉地带。 search_code 也会返回代码片段，但它表达的是“按条件执行一次搜索”。 repo://payment-service/readme 表达的是“读取这个已经被标识的上下文对象”。前者围绕调用和参数组织，后者围绕标识、发现和读取组织。

Tool 与 Resource 的边界不必按“读和写”机械划分。更实用的判断方式是看：客户端面对的究竟是一项需要执行的操作，还是一份可以被寻址、选择和装载的数据？

Resource 还有一个重要边界：出现在资源列表中，只表示客户端知道它存在。Host 仍要决定是否读取、何时读取、展示给谁，以及是否把内容加入模型上下文。资源发现、资源读取和进入上下文是三个不同动作。

图 2. Resource 从被发现到进入上下文，列出不等于读取，读取不等于自动进入上下文

Resource 解决了资料怎样被寻址和读取，但排查任务还需要一个可复用的入口，用来收集参数、组织目标和说明输出要求，这个职责落在 Prompt 上。

Prompt：提供可复用的任务入口

MCP Prompt 是 Server 提供的可发现、可参数化消息模板。客户端通过 prompts/list 发现模板，再通过 prompts/get 传入参数并取得带有 user 或 assistant 角色的消息内容。

案例中的 start_failure_diagnosis 更适合改成一个 Prompt：

diagnose_test_failure(service, run_id)

用户选择这个任务入口并填写服务名与运行编号后，Server 可以返回一组消息，说明排查目标、建议查看的资料、需要验证的假设以及最终输出要求。Prompt 也可以在消息中包含 Resource 内容或资源链接，帮助 Host 找到相关上下文。

第三期「 Agent 小知识：把动态 Prompt 做成一个系统组件 」讲过动态 Prompt：Agent 运行时拿到的完整输入可能由系统规则、当前任务、状态、外部资料、工具说明和对话历史共同拼装。MCP Prompt 只是其中一个可被发现和取得的消息模板。它不等同于 Host 自己维护的系统提示词，也不意味着 Server 能绕过客户端直接向模型注入指令。

官方通常把 Prompts 描述为“用户驱动”，指用户一般决定何时使用某个模板。具体呈现和消息使用方式仍由 Host 设计。

到这里，操作、上下文数据和任务入口已经各自归位，可以回到同一条排查链看它们怎样协作。

三类原语在同一任务中协作

完成重新分工后，测试失败排查可以沿着下面这条任务链推进。

用户选择 diagnose_test_failure Prompt，并提供 payment-service 与运行编号。
客户端取得模板消息，Host 根据任务需要读取测试规范和对应的持续集成日志。
模型结合 Prompt 与 Resource 内容形成排查假设，再调用 search_code 定位相关代码。
模型调用 run_tests 验证判断，Tool 返回测试结果。
如果结果体量较大，Tool 可以返回资源链接，客户端需要时再读取对应内容；这类链接不一定预先出现在资源列表中。Tool 也可以直接返回嵌入式资源或结构化结果。
需要修改文件时，Host 根据权限和确认策略决定是否允许调用 apply_patch。
Host 汇总证据、执行结果和状态变化，完成最终验收。

这条链路用于展示三类能力怎样配合，并非协议规定的固定时序。有些任务只需要 Resources，有些 Server 只提供 Tools，也有些 Prompts 不引用任何 Resources。具体怎样组合，取决于 Server 提供了哪些能力，以及 Host 的产品策略。

图 3. Prompts、Resources、Tools 在一次测试失败排查中接力协作

下面这张表集中比较三类原语：

表中的“模型驱动、应用驱动、用户驱动”是一组典型交互模型，不是权限规则，也不是所有 MCP 产品必须采用的固定界面。模型提出 Tool 调用后，Host 仍可以要求确认；应用可以自动选择 Resource，也可以让用户手动选择；Prompt 同样可以被搜索和推荐。

三类原语的职责边界不意味着彼此隔绝。Prompt 消息可以包含或引用 Resource，Tool 结果可以返回资源链接或嵌入式资源。客户端和 Host 负责协调这些内容怎样被读取、调用和加入上下文，并落实用户确认与应用策略。

重新分工后，Host 可以分别采用资源浏览、按需装载、用户选择和操作调用等交互路径，模型也不必在同一张 Tool 清单里辨认所有职责。

三类能力对应不同风险

Tools、Resources 和 Prompts 都来自 Server，客户端不能因此默认它们可信。

Tool 的描述、输入结构和行为注解可能不准确，调用参数与返回结果需要校验。查询型 Tool 可能读取敏感信息或触发高成本计算，修改型 Tool 还会改变外部状态，两类风险都需要相应的权限约束。

Resource 可能包含过期数据、越权内容或针对模型编写的恶意指令。Host 需要判断来源、读取范围和进入上下文的位置。Prompt 本身也可能夹带不合适的要求，因此“用户选择了模板”不能替代内容审查和系统规则。

结语

面对一项 MCP 能力，可以先判断它提供的是一份可寻址的数据、一个可复用的任务入口，还是一次需要调用的操作。对应关系分别指向 Resource、Prompt 和 Tool。

清楚的分工让 Host 更容易选择上下文、组织交互并控制外部操作。MCP 负责提供这些协议接口，Agent 系统仍要决定何时读取、何时调用、何时确认，以及怎样验收结果。

本期先划清三类能力的职责，下一期继续讨论 Agent 接入这些能力后，用户授权、凭证、输入校验、操作确认和执行隔离应该怎样设计。

参考资料

Model Context Protocol, The 2026-07-28 Specification：blog.modelcontextprotocol.io/posts/2026-07-28/
Model Context Protocol, 2026-07-28 Architecture Overview：modelcontextprotocol.io/docs/2026-07-28/learn/architecture
Model Context Protocol, Tools：modelcontextprotocol.io/specification/2026-07-28/server/tools
Model Context Protocol, Resources：modelcontextprotocol.io/specification/2026-07-28/server/resources
Model Context Protocol, Prompts：modelcontextprotocol.io/specification/2026-07-28/server/prompts
《Agent 小知识｜把动态 Prompt 做成一个系统组件》
《Agent 小知识｜让 Agent 调对工具：输入输出契约的设计》
《Agent 小知识｜别让过程挤垮主 Agent：子 Agent 的隔离、回传与验收》

#Agent小知识 #MCP #Agent #Tool #Resource #Prompt #Agent开发

ITPub博客

Agent 小知识｜MCP 里的 Tools、Resources、Prompts 有什么区别