## 一、什么是Agent（智能体） 大模型上知天文下知地理，你问它什么它答什么，但是它有个最大的缺陷，就是没有“手”不能干活。 而Agent（智能体）相当于是给大模型装上了“手”，让它可以感知外部世界、思考并采取行动。 **LLM** 用户输入指令→模型检索知识后回答 **Agent** 用户输入指令→Agent自主识别可用的工具进行调用，给用户交付结果 传统编程、Workflow和Agent 的区别： - **传统编程：**程序员在做决策，把所有可能的情况都提前想好，写成代码； - **Workflow：**产品/开发在做决策，设计固定的流程路径； - **Agent：**AI 在做决策，根据实际情况动态调整策略； ## 二、Agent核心原理 目前，Agent 基本采用 ReAct 模式。该模式由姚顺雨等人于 2022 年在《[ReAct: Synergizing Reasoning and Acting in Language Models](https://blog.csdn.net/weixin_44191845/article/details/148403313)》一文中提出，其核心思想是将推理（Reasoning）与行动（Acting）相结合。CoT 思维链主要提升 LLM 的推理能力，但由于缺少与外部世界的交互，难以获得外部反馈来拓展知识空间；ReAct 在一定程度上弥补了这一不足。 ReAct Agent 的工作方式很像人类解决问题的过程：在整体目标明确的前提下，边做边调整。具体来说，它会先观察当前情况，再思考下一步行动，随后执行动作并观察结果，最后根据结果决定下一步。上述过程不断循环，直到任务完成。 - **思考**（Reasoning）：帮助模型分解任务、制定计划、跟踪进度、处理异常、识别信息需求。这本质上是LLM的内部"独白"或元认知。 - **行动**（Action）：允许模型与外部世界（如知识库API、交互式环境）交互，以获取当前思考步骤所需的信息，或执行计划中的某个具体操作。 - **观察**：（Observation)：行动的结果，反馈给模型，作为下一步思考的依据。 ReAct 的实现主要依赖于精心设计的 `Few-Shot Prompting`[https://github.com/ysymyth/ReAct。Prompt](https://github.com/ysymyth/ReAct%E3%80%82Prompt) 中包含若干个“思考-行动-观察”的完整轨迹示例，指导 LLM 在新的任务实例上生成类似的交错序列。 对于 Agent 应用开发者而言，无需在提示词中额外加入这些示例来引导模型生成。大多数模型厂商已在 API 内部进行了处理，一般通过 **Function Calling** （\*\*函数调用）\*\*的方式实现。 ## 三、Agent运行流程 ![](../.resources/image-1778904762459.png)![](../.resources/image-1778904772586.png) 工具调用具体过程 以天气查询为例，用户指令：今天上海天气怎么样？ 1. **初始化：**Agent 接收用户指令初始化上下文，并定义一个天气查询工具 `get_weather` ```python # 初始化上下文 messages = [ { "type": "message", "role": "user", "content": "查询北京今天的天气" } ] # 定义工具 tools = [ { "type": "function", "name": "get_weather", "description": "根据城市名称查询该城市当日天气（含温度、天气状况）", "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "城市名称，如北京、上海（仅支持国内地级市）" } }, "required": ["location"] } } ] ``` 2. **第一轮请求：**将上下文和工具定义发送给大模型，大模型返回 `function_call` \*\*\*\*类型指令，包括工具名`name`和参数`arguments`，告诉Agent需要调用工具。 ```python { "created_at": 1756980000, "id": "resp_02175698000123456789abcdef0123", "model": "doubao-seed-1-6-251015", "object": "response", "output": [ { "arguments": "{\\"location\\":\\"北京\\"}", "call_id": "call_abc123def456ghi789jkl0", "name": "get_weather", "type": "function_call", "id": "fc_02175698000abcdef0123456789gh", "status": "completed" } ], "status": "completed", "store": true, "expire_at": 1757239200 } ``` 3. **执行工具调用：**Agent `响应控制器`中解析响应数据，发现返回了 `function_call` \*\*\*\*类型指令，然后根据工具名和参数去调用外部的天气API获取天气数据。获取后将模型响应数据和查询到的天气数据存入上下文。 ```python { "city": "北京", "date": "2025-10-13", "temperature": "18~28℃", "condition": "晴转多云", "wind": "东北风2级" } ``` 4. **第二轮请求：**将上下文发送给模型生成最终响应。 ```python curl \\ -H "Authorization: Bearer $ARK_API_KEY" \\ -H "Content-Type: application/json" \\ -d '{ "model": "doubao-seed-1-6-251015", "previous_response_id": "resp_02175698000123456789abcdef0123", # Associate with the previous request "input": [ { "type": "function_call_output", # Return tool results "call_id": "call_abc123def456ghi789jkl0", # Consistent with the call_id of the instruction "output": "{\\"city\\":\\"北京\\",\\"date\\":\\"2025-10-13\\",\\"temperature\\":\\"18~28℃\\",\\"condition\\":\\"晴转多云\\",\\"wind\\":\\"东北风2级\\"}" } ] }' ``` 最终响应如下，响应控制器解析响应发现没有 `function_call` \*\*\*\*指令了，说明本次指令模型完成处理了，则可以直接返回模型的结果：北京今天（2025-10-13）的天气为晴转多云，气温在18~28℃之间，东北风2级。否则继续执行工具调用。 ```python { "created_at": 1756980100, "id": "resp_02175698010abcdef0123456789gh", "model": "doubao-seed-1-6-250615", "object": "response", "output": [ { "type": "message", "role": "assistant", "content": [ { "type": "output_text", "text": "北京今天（2025-10-13）的天气为晴转多云，气温在18~28℃之间，东北风2级。" } ], "status": "completed", "id": "msg_02175698010abcdef0123456789ij" } ], "status": "completed", "store": true } ``` ## 四、MCP
对于产品经理来说，不需要了解MCP协议具体是如何实现的、如何开发一个MCP。 只需要了解：MCP概念、交互流程、判断是使用已有MCP还是自己开发、以及MCP需要什么参数和返回什么响应数据。 就像我们只需要了解前后端是什么、前后端是如何交互的、判断是使用外部现成 API 还是自己开发一样、以及API需要什么参数和返回什么响应数据一样，便于我们和技术更好的沟通。
### 1\. MCP解决了什么问题 **Function Calling** 解决了核心问题：让LLM能够稳定地输出结构化的工具调用请求，实现了"非结构化→结构化"的转换。这是AI Agent工具能力的基础。 但在实际应用中，开发者很快发现了几个新的问题： 1. 每个工具的API接口都不一样，需要特殊适配。 2. 在A应用里做了适配，B应用里又得适配一遍，无法复用。 这时候，MCP（Model Context Protocol 模型上下文协议）作为一个连接应用和工具的桥梁就派上用场了。 举个例子： 我们的AI应用是台笔记本电脑，每个工具是外接设备（摄像头、显示器、鼠标、键盘…）。 - **MCP出现之前：**每个外接设备都使用不同的端口（HDMI、Type-C、VGA….），每台笔记本电脑都要适配各种端口，不仅端口特别多，而且出现了新的设备又得进行适配。另外，不同品牌适配的端口也可能存在差异。 - **MCP出现之后：**MCP相当于Type-C设备端口，不同外接设备厂商只要支持Type-C端口，就可以在所有支持Type-C端口的电脑上使用，而不同笔记本厂商只要支持Type-C端口，也就可以使用所有支持Type-C端口的外接设备。 ![](../.resources/image-1778904815118.png)![](../.resources/image-1778904822749.png) ### 2\. Agent、大语言模型和MCP是如何交互的 - **Agent**：整个系统的编排中心（如 Claude Desktop、Cursor 或自定义 App），负责管理用户交互、协调大语言模型调用与 MCP 客户端 通信，进行权限管理。Agent 内部包含 MCP 客户端 和 大语言模型调用逻辑。 - **大语言模型**：Agent 内部调用的推理引擎，负责理解用户意图、决策是否调用工具，并生成结构化的工具调用请求（function\_call）或最终回答。 - **MCP 客户端**：Agent 内部的通信模块，负责与 MCP 客户端 建立连接、发现能力、转发工具调用请求并接收结果。 - **MCP 服务端**：独立运行的外部服务，提供具体的工具和资源（如 Google Drive 读取器、SQLite 数据库接口等），响应 MCP 客户端 的请求并返回执行结果。 ```mermaid sequenceDiagram autonumber actor User as 用户 (User) participant Host as Agent participant LLM as 大语言模型 participant Client as MCP 客户端 (内部模块) participant Server as MCP 服务端 Note over Host,Client: Agent 集成了 MCP 客户端 %% ================= Phase 1: 连接与初始化 ================= Note over Client,Server: 阶段一：连接 Host->>Client: 1. 读取 MCP 配置，启动 Client Client->>Server: 2. 请求连接 Server-->>Client: 3. 连接成功 %% ================= Phase 2: 能力发现 ================= Note over Client,Server: 阶段二：能力发现 Client->>Server: 4. 拉取可用工具列表、资源列表 Server-->>Client: 5. 返回工具、资源清单 Client-->>Host: 6. 将发现的工具、资源返回给Agent %% ================= Phase 3: 核心交互与执行 ================= Note over User,Server: 阶段二：用户交互与任务执行 User->>Host: 7. 发送自然语言指令
(例如: "分析服务器日志资源并总结") Host->>LLM: 8. 用户指令 + 工具定义 Note over LLM: 9. 推理决定是否需要调用工具 LLM-->>Host: 返回 function_call 指令
(工具名 + 参数) Host->>Client: 10. 解析指令，转发工具调用请求 Client->>Server: 11. 发送工具调用请求 Server-->>Client: 12. 返回工具执行结果 Client-->>Host: 13. 返回执行结果 Host->>LLM: 14. 将工具结果注入上下文，再次请求 LLM Note over LLM: 15. 综合上下文生成最终回答 LLM-->>Host: 返回最终文本响应 Host-->>User: 16. 输出最终结果 ``` ### 3\. 如何使用MCP 阿里魔塔（[https://modelscope.cn/mcp）上集成了近万个MCP，可以搜索和筛选需要的MCP。](https://modelscope.cn/mcp%EF%BC%89%E4%B8%8A%E9%9B%86%E6%88%90%E4%BA%86%E8%BF%91%E4%B8%87%E4%B8%AAMCP%EF%BC%8C%E5%8F%AF%E4%BB%A5%E6%90%9C%E7%B4%A2%E5%92%8C%E7%AD%9B%E9%80%89%E9%9C%80%E8%A6%81%E7%9A%84MCP%E3%80%82) ![](../.resources/image-1778904851109.png) 在MCP详情中有个服务配置，就是MCP配置数据，可以通过Remote或者stdio进行调用。 | 对比项 | Remote（远程调用） | Stdio（本地进程标准输入输出） | | --- | --- | --- | | 连接方式 | 通过网络请求连接远程服务器上的 MCP Server，只需填一个 URL 地址即可。 | 在本地启动一个进程，通过标准输入（stdin）和标准输出（stdout）与 MCP Server 通信，MCP Server 和你的应用运行在同一台机器上。 | | 优点 | 不需要本地安装任何依赖，配置简单，填个地址就能用。 | 本地通信开销小，通常更低延迟 | | 缺点 | 受网络、带宽影响，可能更高延迟 | 需要在本地安装对应的运行环境（如 Node.js、Python 等）和相关依赖包，配置相对复杂。 | | 适用场景 | 适合快速体验、轻量集成、不想管理本地环境的场景。 | 适合对性能和安全性要求较高、需要频繁调用的生产环境。 | ![](../.resources/image-1778904872406.png)![](../.resources/image-1778904888142.png) ## 五、Skill **Skill 是由 Anthropic 于 2025 年 10 月提出的一种开放标准**，核心思想是把指令、脚本和资源打包成一个标准化的文件夹（"技能包"），让 AI Agent 能够按需动态加载和执行特定任务。 ### 1\. Skill 解决了什么问题 **Function Calling** 让 LLM 能调用工具，**MCP** 统一了工具接口标准。但在实际应用中，还有一个问题没解决： 1. Agent 虽然通用能力很强，但缺乏特定领域的专业知识和流程。 2. 每次都要在 System Prompt 里塞入大量指令，导致上下文污染、复用性差。 这时候，**Skill（代理技能）** 就派上用场了。Skill 由 Anthropic 于 2025 年 10 月提出，是一种开放式构建标准，核心是将复杂的业务逻辑、操作指令和外部知识封装为标准化的模块，让 AI Agent 能像调用"技能包"一样，按需动态加载和执行特定任务。 举个例子： Agent 就像一个刚入职的新员工，虽然综合素质很强（大模型能力），但对公司业务流程一无所知。 - **Skill 出现之前：**每次给新员工布置任务，都要口头从头讲一遍完整流程（把所有规则塞进 System Prompt），不仅费时费力，而且容易遗漏。 - **Skill 出现之后：Skill 相当于给新员工准备了一套标准化的岗位 SOP 手册**，需要做什么任务就翻对应的手册，里面有详细的操作指令、脚本和参考资料，按需查阅即可。 ### 2\. Skill 的组成 一个 Skill 本质上就是一个包含 `SKILL.md` 的文件夹，结构如下： ``` my-skill/ ├── SKILL.md # 入口文件：技能描述、触发条件、基本指令 ├── scripts/ # 可执行脚本（Python、Shell 等） ├── templates/ # 模板文件（报告模板、代码模板等） └── resources/ # 参考资料（文档、数据、示例等） ``` - [**SKILL.md**](http://SKILL.md)**（入口文件）**：描述这个技能是做什么的、什么时候触发、基本操作指令 - **scripts（脚本）**：可执行的代码，让 Agent 从"建议者"变为"执行者" - **templates（模板）**：标准化的输出模板 - **resources（资源）**：参考文档、数据等辅助材料 ### 3\. 核心机制：渐进式披露 Skill 采用**渐进式披露**（Progressive Disclosure）机制，信息按需分级加载，而不是一次性全部塞入上下文： **传统 System Prompt** 所有规则一次性全量塞入上下文→Token 浪费、注意力分散、指令漂移 **Skill 渐进式披露** Agent 按需加载技能片段→Token 高效利用、执行精准 具体分为三个层级： 1. **目录层（低成本）**：Agent 平时只知道有哪些 Skill 可用（相当于只看手册目录） 2. **摘要层（按需加载）**：当用户请求匹配某个 Skill 时，加载该 Skill 的详细指令 3. **执行层（深度加载）**：需要执行具体操作时，加载脚本、模板等完整资源 ### 4\. Skill vs MCP | 对比项 | Skill（工作手册 📖） | | --- | --- | | 定位 | 教 Agent **怎么做**：封装流程、知识、指令 | | 组成 | [SKILL.md](http://SKILL.md) • 脚本 + 模板 + 资源 | | 加载方式 | 渐进式披露，按需加载 | | 关系 | **互补关系**：一个 Skill 内部可以调用 MCP 提供的工具来完成任务。Skill 定义"做什么、怎么做"，MCP 提供"用什么工具做"。 | 简单来说：**Skill 是 SOP 手册，MCP 是工具箱。** 手册里会写"第三步用扳手拧螺丝"，而扳手就是通过 MCP 提供的。 ### 5\. 应用场景 Skill 特别适合需要**标准化、流程化**的企业任务： - **客户服务**：封装投诉处理、退换货等特定流程的 SOP - **数据分析**：根据文件类型自动选择分析方法并生成报告 - **文档编辑**：如 Claude 的 PDF 编辑功能，就是通过 PDF Skill 实现的 ### 6\. 如何使用 Skill Skill 目前已获得多个平台的支持： | 平台 | 支持状态 | 使用方式 | | --- | --- | --- | | Claude Code | 完整支持 | 原生集成 | | [Claude.ai](http://Claude.ai) | 完整支持 | 设置上传 | | VS Code | 完整支持 | chat.useAgentSkills | | Cursor | 完整支持 | 文档支持 | | GitHub Copilot | 完整支持 | 原生集成 | | OpenAI Codex | 完整支持 | 官方支持 | Anthropic 官方 Skill 仓库：[https://github.com/anthropics/skills](https://github.com/anthropics/skills) Agent Skills 开放标准官网：[https://agentskills.io](https://agentskills.io) ## 六、Harness ![](../.resources/image-1778904905130.png) Agent = Model + Harness。 图中最核心的位置是 Model——那个蓝色芯片图标，代表 Claude 的大语言模型。但模型本身只是一个推理引擎，它不能独立行动。真正让它变成 Agent 的，是包裹在它周围的五个 Harness 组件。 - **Tools（工具），**模型的手脚。Read、Write、Edit、Bash、Grep……这些工具赋予模型与文件系统、终端、网络交互的能力。没有工具，模型只能说，不能做。 - **Context（上下文）**，模型的记忆加载器。[CLAUDE.md](http://claude.md/)、系统提示词、对话历史、工具定义——这些上下文在每一轮循环中被注入模型，决定了模型看到什么、知道什么。上下文管理的精妙之处是，它不仅是被动的信息传递，还包括主动的压缩和重注入策略。 - **Memory（记忆）**，模型的长期存储。跨会话的记忆持久化，让模型能“记住”你的偏好、项目规则和历史决策。[CLAUDE.md](http://claude.md/) 是显式记忆，自动记忆（~/.claude/memory/）是隐式记忆。没有 Memory，每次对话都从零开始。 - **Hooks（钩子）**，模型的神经反射。事件驱动的自动化机制，在工具执行前后触发自定义逻辑。比如每次保存文件前自动格式化，每次提交前自动运行 lint。Hooks 让 Harness 有了“条件反射”的能力——不需要模型主动决策，某些行为会自动发生。 - **Permissions（权限）**——模型的安全围栏。哪些工具可以自由使用，哪些需要人工审批，哪些完全禁止——权限系统是 Harness 的安全底线。它解决了一个核心矛盾：你希望 Agent 足够自主以提高效率，但又不希望它自主到失控。 注意图中的空间关系：Model 在中心，五个组件围绕它排列，整体被一个名为 Harness 的边框包裹。这不是随意的布局，它精确表达了一个架构事实：模型不直接接触外部世界，所有交互都通过 Harness 的组件中转。Harness 是模型和现实之间的唯一接口。 这五个组件也不是孤立的。Tools 的执行结果变成 Context 的一部分；Hooks 在 Tools 执行前后触发；Permissions 决定哪些 Tools 可以被调用；Memory 用于跨会话保留 Context 中的关键信息。它们构成了一个协同运转的系统，少了任何一个，Agent 的能力都会大打折扣。