Agent 如何真正完成任务：从模型、MCP 到 Skill

模型负责推理，MCP 负责连接能力，Skill 负责加载方法，执行轨迹负责让整个系统持续变好。

最近我连续和团队聊了几次 Agent 工程。从 Agent 为什么能写代码，到 MCP 到底解决了什么问题，再到 Skill 为什么会成为新的上下文组织方式，讨论里出现了很多概念，也出现了很多容易混在一起的说法。

但把这些名词都拿掉以后，最值得追问的其实是一个非常朴素的问题：

大模型本质上只是接收信息、生成文字，它凭什么能够读取文件、查询数据库、操作浏览器，甚至替我们生成一份业务报告？

这篇文章想把这条链路完整讲清楚。

我同时做了一份配套交互演示。文章是主体，网页只是把其中的关键关系做成了 20 页可交互的视觉说明。阅读过程中遇到抽象概念时，可以打开相应页面对照查看，但不打开网页也不影响阅读全文。

先把“大模型”和“Agent”分开

理解 Agent 的第一步，是不要把它和大模型混为一谈。

大模型本身可以被理解成一个刚毕业的全科研究生：知识面广，能够理解语言、拆解问题、推理和生成内容。但是这个人刚来到公司时，没有账号、没有电脑权限、不知道项目代码在哪里，也不了解公司的业务流程。

它很聪明，但它还没有工作环境。

Agent 工程做的事情，就是在模型外面搭建一套工作台：

• 给它可以使用的工具；
• 告诉它每个工具的用途和参数；
• 把工具执行结果重新交给它；
• 为高风险操作设置边界；
• 在需要时加载当前业务的知识和流程；
• 记录整个过程，方便发现和修正问题。

因此，大模型和 Agent 可以看成两个层次：

大模型：理解、推理、判断、生成
Agent：工具、权限、状态、反馈、规则、上下文

模型决定能力上限，工程决定它能不能稳定到达这个上限。

同一个模型，放在不同的 Agent 环境里，最终效果可能相差很大。工具定义不清楚、上下文塞得太满、错误信息无法行动，都会让一个原本很强的模型表现得像在乱试。

配套图示：模型能力与 Agent 工程

Agent 的核心不是“一次回答”，而是一个闭环

普通聊天更像一次问答：用户提出问题，模型生成答案。

Agent 则需要反复经历一个循环：

理解目标
  ↓
选择工具
  ↓
生成结构化调用
  ↓
宿主程序执行工具
  ↓
把成功结果或错误返回模型
  ↓
模型修正、继续调用或完成任务

例如，我们给 Agent 一个专利检索工具，然后问它：“帮我查一下锐捷网络有哪些专利。”

模型可能先生成这样的调用意图：

{
  "company_name": "锐捷网络",
  "page_index": 1,
  "page_size": 100
}

真正请求专利系统的并不是模型，而是 Agent 外层的宿主程序。工具执行以后，可能返回 284 条记录、当前页数据和下一页信息，也可能返回“缺少必填参数”之类的错误。

这些结果会再次进入模型的上下文。模型再判断：

• 是否需要继续翻页；
• 是否应该按年份缩小范围；
• 是否需要询问用户具体目标；
• 是否已经具备生成汇总或报告的条件。

这就是 Agent 能够“做事”的关键：模型不只是输出最终答案，它还在持续观察环境反馈，并决定下一步。

所谓智能体，不只是智能，而是智能加上行动和反馈闭环。

配套图示：Agent 的工具调用闭环

模型没有直接“按按钮”，它输出的是结构化意图

我们经常说模型“调用了工具”，这个说法容易让人误以为模型真的在电脑中点击了某个按钮。

实际上，模型看到的是一份工具定义。例如：

{
  "name": "search_patents",
  "description": "按企业名称与年份检索专利",
  "inputSchema": {
    "company_name": "string",
    "year": "number?",
    "page_index": "number",
    "page_size": "number"
  }
}

模型根据工具定义和当前任务，生成一个结构化的 tool_call。外层程序识别这个调用以后，才会真正执行 HTTP 请求、数据库查询、文件读取或命令行操作。

所以工具定义并不是一份给开发者看的普通接口文档，它其实是模型的操作界面。

人使用一个设计糟糕的软件会迷路，模型面对一个含糊的工具定义也会迷路。

工具叫什么、描述是否准确、参数是否容易混淆、错误能不能指导下一步，这些细节都会直接影响 Agent 的准确率。

MCP 解决的是“怎样连接”，不是“怎样完成业务”

在没有统一协议时，每为模型接入一种外部能力，都要重新定义一套工具说明、参数格式和执行方式。

今天接天气接口，写一套；明天接数据库，再写一套；后天接文档系统，还要重新适配。不同团队提供的工具也很难直接复用。

MCP 的价值，是让这些外部能力以相对一致的方式被发现、描述和调用。

Agent
  ↕
MCP 提供的标准化连接层
  ↕
数据库 / 浏览器 / 文档 / 内部系统 / 远程 API

从 Agent 的角度看，它不需要知道一个专利工具内部使用 REST API、浏览器自动化还是本地脚本。它只需要知道：

• 这个工具能做什么；
• 什么时候应该使用；
• 需要传入哪些参数；
• 会返回怎样的结果。

因此，MCP 不是让模型变得更聪明，而是让模型能够以一致的方式连接外部世界。

它解决的是“我能访问什么、我怎样调用”，而不是“这个业务应该按照什么方法完成”。后一个问题会在 Skill 部分出现。

配套图示：MCP 是 Agent 与外部能力之间的桥梁

工具工程的质量，往往藏在参数名里

协议统一，并不意味着工具自然就好用。

假设一个分页接口提供两个参数：

page
size

这里马上会产生很多问题：

• page 从 0 还是从 1 开始？
• size 是总数量还是每页数量？
• 有没有最大值？
• 不填时使用什么默认值？

如果接口本身没有说明，模型只能猜。猜错以后再根据错误重试，不仅增加失败率，也会持续消耗上下文。

更清楚的定义可能是：

page_index：从 1 开始的页码
page_size：每页返回数量，范围为 1–100
company_name：企业工商全称

错误信息同样重要。

“请求失败”对 Agent 没有行动价值；“缺少 company_name”或者“page_size 必须处于 1–100”则能让模型立即修正。

这不是在限制模型，而是在规范输入输出，减少不必要的歧义。

很多时候，Agent 准确率的提升并不来自更长的提示词，而是来自更清楚的接口、更稳定的返回结构和更容易行动的错误信息。

好规则不是想出来的，而是从执行轨迹里长出来的

成熟 Agent 的系统规则里，经常能看到一些很细的要求：

• 搜索文件时优先使用专用搜索工具；
• 读取文件前先检查文件大小；
• 创建文件前确认目标路径和已有内容；
• Git、删除和移动等操作需要额外边界；
• 不要把大量无关输出直接塞进上下文。

这些规则不应该来自开发者的想象，而应该来自真实的执行轨迹。

一个更可靠的迭代过程是：

观察失败
  → 定位原因
  → 增加最小规则
  → 再次验证
  → 回归测试

例如，命令行当然能够读取文件。但如果模型习惯性地使用命令把一个大型文件完整输出，结果可能是上下文瞬间被占满。于是工程上会增加一个专用读取工具：先判断大小和类型，再按行读取、提取结构或摘要。

这条规则不是因为“命令行不能读文件”，而是因为真实实验表明，专用工具能够带来更稳定的体验。

规则的价值来自它解决过具体失败，而不是因为规则数量很多。

当工具越来越多，真正的瓶颈会变成上下文

用户在聊天框里只输入了一句话，不代表模型这一轮只看见了这一句话。

模型实际接收到的上下文可能包括：

• 系统规则；
• 所有工具的名称、描述和参数；
• 已经发生的历史对话；
• 读取的文件内容；
• 数据库或 API 返回结果；
• 当前任务需要的专业知识。

这些内容共同消耗上下文窗口。

如果让工具原样返回一个 1.8 MB 的文本文件或者大型 JSON，即使没有直接超过模型上限，大量无关信息也会稀释模型对当前任务的注意力。

因此，好的工具不会简单地“把所有数据交给模型”，而会先做一层工程处理：

• 检查文件大小与类型；
• 只读取相关行或片段；
• 对 JSON 提取结构；
• 对长内容分块；
• 必要时先摘要，再让主模型继续判断。

上下文有限，真正稀缺的不是信息本身，而是与当前决策有关的信息。

这也解释了为什么最近大家越来越多地讨论“上下文工程”，而不只是“提示词工程”。

提示词工程关注一句话怎样写；上下文工程关注整个任务中，什么信息应该在什么时间进入模型。

配套图示：上下文成本

Skill：不是再加一个工具，而是让 Agent 学会一类工作

假设我们已经通过 MCP 接入了专利检索系统。

Agent 现在可以查询企业、年份和专利列表，但这并不代表它已经会写专利查新报告。

“能拿到数据”和“知道怎样完成业务”是两个不同问题。

一份专业报告可能还要求 Agent 理解：

• 应该先确认哪些用户条件；
• 怎样设计检索策略；
• 如何对结果去重；
• 怎样判断相似性；
• 什么时候需要公开网络补充证据；
• 报告应该采用什么结构；
• 输出前需要做哪些校验。

这些内容不是某个 API 的参数，而是业务知识、流程和经验。

Skill 的作用，就是把“会做这件事”的方法组织成一个可以复用、按需加载的模块。

它可以包含三类内容：

专业知识：术语、规则、判断标准
业务流程：先做什么、何时询问、失败怎样处理
资源与脚本：模板、示例、校验器、确定性辅助程序

Skill 不只是告诉模型“知道什么”，还要告诉它：在什么条件下，按照什么顺序，把事情做到什么标准。

Skill 的目录为什么要分层

一个典型 Skill 可以采用这样的结构：

patent-novelty-report/
├─ SKILL.md
├─ references/
│  ├─ report-format.md
│  └─ search-strategy.md
├─ scripts/
│  └─ validate_report.py
└─ assets/
   └─ report-template.docx

其中，SKILL.md 是入口。文件前部通常包含名称和描述，用来帮助 Agent 判断当前任务是否应该使用这个 Skill；正文则保留核心流程和资源路由。

更详细的报告规范、检索策略和领域知识放在 references 中。稳定、重复、结果确定的步骤可以放在 scripts 中。模板等非文本资源则放在 assets 中。

这里的关键并不是目录看起来整齐，而是它支持渐进式加载。

第一层：name + description
        用于发现和选择 Skill

第二层：SKILL.md
        命中任务后加载核心方法

第三层：references / scripts / assets
        只有实际需要时才继续读取或执行

如果当前任务只需要了解检索流程，就不必加载完整报告模板；如果没有进入校验阶段，也不必执行验证脚本。

这比把所有专业知识永久放在系统提示中更节省，也能减少不同领域内容之间的相互干扰。

配套图示：Skill 的渐进式加载

文档需要理解，脚本通常只需要执行

Skill 中的参考文档和脚本，还有一个非常重要的区别。

报告结构、行业规则和判断标准，需要模型阅读、理解并结合场景进行推理。这类内容适合放在 Markdown 文档中。

格式校验、批量转换、固定计算等步骤，结果通常是确定的，更适合写成脚本。

模型不一定需要阅读脚本的全部源码。它只需要知道：

• 什么时候执行；
• 输入参数是什么；
• 输出结果代表什么；
• 失败以后应该怎样处理。

这样既能减少上下文消耗，也能避免模型每次临时重写一段代码，导致行为不稳定。

一个简单的判断方式是：

需要理解和权衡的内容交给模型；需要稳定、重复执行的内容交给脚本。

MCP 与 Skill 的边界

MCP 和 Skill 有时会让人觉得很接近，因为两者都可能向 Agent 提供新的能力，Skill 中也可能带有可执行脚本。

但从职责上看，两者的边界仍然比较清楚：

只有 MCP，没有 Skill，Agent 可能拥有很多工具，却不知道业务的正确方法。

只有 Skill，没有 MCP，Agent 可能理解流程，却拿不到数据，也无法完成外部操作。

两者组合，才会形成一套完整的业务能力。

配套图示：MCP 与 Skill 的分工

把两者组合成一套专利查新报告 Agent

把前面的概念放到同一个业务场景中，可以得到这样一套架构：

用户需求
主题 / 公司 / 时间范围 / 输出要求
        ↓
专利查新 Skill
澄清条件 → 制定检索式 → 证据去重 → 相似性对比 → 生成报告
        ↓
多个 MCP 工具
内部专利库 / 公开检索 / 文档写入
        ↓
最终交付
可追溯证据 + 结构化报告 + 校验结果

用户首先提供主题、公司、时间范围和交付要求。如果信息不足，Skill 的第一步应该主动澄清，而不是让模型自行猜测。

接着，Skill 按业务顺序编排多个 MCP 工具：从内部系统获得专利数据，通过公开检索补充证据，把结果去重并进行相似性对比，最后调用文档能力生成报告。

最终交付不能只是一份“看起来像报告”的文件。它还应该包含能够回溯的证据、关键判断依据和校验结果。

只有这样，Agent 才能从一个演示效果不错的聊天机器人，变成可以复核的业务工具。

配套图示：专利查新报告 Agent 架构

真正落地时，我会按照这个顺序推进

如果要从零开始构建一个业务 Agent，我更倾向于按照下面的顺序：

1. 人先把业务做清楚

收集真实输入、真实报告和真实失败案例，明确什么叫合格。自己都说不清楚的流程，无法指望模型自动替我们定义正确标准。

2. 梳理数据源与动作

确认系统接口、认证方式、字段、分页、错误结构和权限边界。区分哪些只是查询，哪些会修改真实数据。

3. 把杂乱 API 封装成清晰工具

工具名称应该容易判断，参数含义明确，返回值支持下一步决策，错误信息可以直接指导修正。

4. 把专业方法沉淀为 Skill

只在入口文件保留核心流程，把详细知识、模板和确定性脚本按职责拆开。不要把所有内容塞进同一个巨大的提示文件。

5. 观察真实执行轨迹

逐步检查模型选择了什么工具、传了什么参数、收到了什么结果、为什么继续或者停止。

6. 只为真实失败补规则

找到可以稳定复现的问题，再增加最小约束并做回归测试。不要在没有证据时无限增加系统规则。

这套过程的重点不是“一次把提示词写完”，而是建立一个能够持续观察和改进的工程循环。

最后，记住这条链路就够了

回到文章开头的问题：一个只会生成文字的模型，为什么能够真正完成任务？

答案并不是某一个神奇功能，而是一整套协作关系：

MODEL：理解目标并推理下一步
MCP：连接外部数据和操作能力
SKILL：按需加载专业知识与工作流
TRACE：记录过程，让失败可见、可验证、可修正

好的 Agent 不是提示词更长，也不是工具越多越好。

它应该具备清晰的能力边界、规范的输入输出、克制的上下文和完整的反馈闭环。每一步发生了什么都能够被看见，每一个失败都能够转化成下一轮工程改进。

这才是 Agent 从“看起来很聪明”，走向“真正能够稳定完成工作”的过程。

配套交互演示怎么查看

文章配套网页：

https://www.jjput.com/fjfhyjy-ai/agent-mcp-skill-course/index.html

网页将本文的核心关系整理成 20 页交互式视觉内容，可以作为阅读辅助、转发预览或现场分享材料。

基本操作

用于现场分享

如果需要把这篇文章改成现场分享，可以在网页中按 S 打开演讲者视图。原窗口继续显示给观众，新窗口会显示当前页、下一页、讲稿和计时器；两个窗口可以同步翻页。

如果浏览器拦截弹窗，允许该网站打开弹出式窗口后刷新即可。只有一个屏幕时，可以按 N 临时查看当前页的补充说明。

重点页面直达

• 模型与 Agent 的两层结构
• Agent 的执行闭环
• MCP 标准化桥梁
• 上下文成本
• Skill 渐进式加载
• MCP 与 Skill 的分工
• 专利查新报告 Agent 架构

网页是文章的视觉补充，文章本身则保留完整的解释、推导与实践思路。两者可以独立阅读，也可以配合使用。