fade/aipm_firstbook

一、什么是Agent（智能体）

大模型上知天文下知地理，你问它什么它答什么，但是它有个最大的缺陷，就是没有“手”不能干活。

而Agent（智能体）相当于是给大模型装上了“手”，让它可以感知外部世界、思考并采取行动。

LLM

用户输入指令→模型检索知识后回答

Agent

用户输入指令→Agent自主识别可用的工具进行调用，给用户交付结果

传统编程、Workflow和Agent 的区别：

传统编程：程序员在做决策，把所有可能的情况都提前想好，写成代码；
Workflow：产品/开发在做决策，设计固定的流程路径；
Agent：AI 在做决策，根据实际情况动态调整策略；

二、Agent核心原理

目前，Agent 基本采用 ReAct 模式。该模式由姚顺雨等人于 2022 年在《ReAct: Synergizing Reasoning and Acting in Language Models》一文中提出，其核心思想是将推理（Reasoning）与行动（Acting）相结合。CoT 思维链主要提升 LLM 的推理能力，但由于缺少与外部世界的交互，难以获得外部反馈来拓展知识空间；ReAct 在一定程度上弥补了这一不足。

ReAct Agent 的工作方式很像人类解决问题的过程：在整体目标明确的前提下，边做边调整。具体来说，它会先观察当前情况，再思考下一步行动，随后执行动作并观察结果，最后根据结果决定下一步。上述过程不断循环，直到任务完成。

思考（Reasoning）：帮助模型分解任务、制定计划、跟踪进度、处理异常、识别信息需求。这本质上是LLM的内部"独白"或元认知。
行动（Action）：允许模型与外部世界（如知识库API、交互式环境）交互，以获取当前思考步骤所需的信息，或执行计划中的某个具体操作。
观察：（Observation)：行动的结果，反馈给模型，作为下一步思考的依据。

ReAct 的实现主要依赖于精心设计的 Few-Shot Promptinghttps://github.com/ysymyth/ReAct。Prompt 中包含若干个“思考-行动-观察”的完整轨迹示例，指导 LLM 在新的任务实例上生成类似的交错序列。

对于 Agent 应用开发者而言，无需在提示词中额外加入这些示例来引导模型生成。大多数模型厂商已在 API 内部进行了处理，一般通过 Function Calling （函数调用）的方式实现。

三、Agent运行流程

工具调用具体过程

以天气查询为例，用户指令：今天上海天气怎么样？

初始化：Agent 接收用户指令初始化上下文，并定义一个天气查询工具 get_weather

# 初始化上下文
messages = [
{
   "type": "message",
   "role": "user",
   "content": "查询北京今天的天气"
}
]
# 定义工具
tools = [
{
    "type": "function",
    "name": "get_weather",
    "description": "根据城市名称查询该城市当日天气（含温度、天气状况）",
    "parameters": {
        "type": "object",
        "properties": {
            "location": {
                "type": "string",
                "description": "城市名称，如北京、上海（仅支持国内地级市）"
            }
        },
        "required": ["location"]
    }
}
]

第一轮请求：将上下文和工具定义发送给大模型，大模型返回 function_call ****类型指令，包括工具名name和参数arguments，告诉Agent需要调用工具。

{
"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
}

执行工具调用：Agent 响应控制器中解析响应数据，发现返回了 function_call ****类型指令，然后根据工具名和参数去调用外部的天气API获取天气数据。获取后将模型响应数据和查询到的天气数据存入上下文。
```
{
"city": "北京",
"date": "2025-10-13",
"temperature": "18~28℃",
"condition": "晴转多云",
"wind": "东北风2级"
}
```

第二轮请求：将上下文发送给模型生成最终响应。

curl <https://ark.cn-beijing.volces.com/api/v3/responses> \\
-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级。否则继续执行工具调用。

{
    "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工具能力的基础。

但在实际应用中，开发者很快发现了几个新的问题：

每个工具的API接口都不一样，需要特殊适配。
在A应用里做了适配，B应用里又得适配一遍，无法复用。

这时候，MCP（Model Context Protocol 模型上下文协议）作为一个连接应用和工具的桥梁就派上用场了。

举个例子：

我们的AI应用是台笔记本电脑，每个工具是外接设备（摄像头、显示器、鼠标、键盘…）。

MCP出现之前：每个外接设备都使用不同的端口（HDMI、Type-C、VGA….），每台笔记本电脑都要适配各种端口，不仅端口特别多，而且出现了新的设备又得进行适配。另外，不同品牌适配的端口也可能存在差异。
MCP出现之后：MCP相当于Type-C设备端口，不同外接设备厂商只要支持Type-C端口，就可以在所有支持Type-C端口的电脑上使用，而不同笔记本厂商只要支持Type-C端口，也就可以使用所有支持Type-C端口的外接设备。

2. Agent、大语言模型和MCP是如何交互的

Agent：整个系统的编排中心（如 Claude Desktop、Cursor 或自定义 App），负责管理用户交互、协调大语言模型调用与 MCP 客户端通信，进行权限管理。Agent 内部包含 MCP 客户端和大语言模型调用逻辑。
大语言模型：Agent 内部调用的推理引擎，负责理解用户意图、决策是否调用工具，并生成结构化的工具调用请求（function_call）或最终回答。
MCP 客户端：Agent 内部的通信模块，负责与 MCP 客户端建立连接、发现能力、转发工具调用请求并接收结果。

MCP 服务端：独立运行的外部服务，提供具体的工具和资源（如 Google Drive 读取器、SQLite 数据库接口等），响应 MCP 客户端的请求并返回执行结果。

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. 发送自然语言指令<br/>(例如: "分析服务器日志资源并总结")
Host->>LLM: 8. 用户指令 + 工具定义
    
Note over LLM: 9. 推理决定是否需要调用工具
    
LLM-->>Host: 返回 function_call 指令<br/>(工具名 + 参数)
    
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。

在MCP详情中有个服务配置，就是MCP配置数据，可以通过Remote或者stdio进行调用。

对比项	Remote（远程调用）	Stdio（本地进程标准输入输出）
连接方式	通过网络请求连接远程服务器上的 MCP Server，只需填一个 URL 地址即可。	在本地启动一个进程，通过标准输入（stdin）和标准输出（stdout）与 MCP Server 通信，MCP Server 和你的应用运行在同一台机器上。
优点	不需要本地安装任何依赖，配置简单，填个地址就能用。	本地通信开销小，通常更低延迟
缺点	受网络、带宽影响，可能更高延迟	需要在本地安装对应的运行环境（如 Node.js、Python 等）和相关依赖包，配置相对复杂。
适用场景	适合快速体验、轻量集成、不想管理本地环境的场景。	适合对性能和安全性要求较高、需要频繁调用的生产环境。

五、Skill

Skill 是由 Anthropic 于 2025 年 10 月提出的一种开放标准，核心思想是把指令、脚本和资源打包成一个标准化的文件夹（"技能包"），让 AI Agent 能够按需动态加载和执行特定任务。

1. Skill 解决了什么问题

Function Calling 让 LLM 能调用工具，MCP 统一了工具接口标准。但在实际应用中，还有一个问题没解决：

Agent 虽然通用能力很强，但缺乏特定领域的专业知识和流程。
每次都要在 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（入口文件）：描述这个技能是做什么的、什么时候触发、基本操作指令
scripts（脚本）：可执行的代码，让 Agent 从"建议者"变为"执行者"
templates（模板）：标准化的输出模板
resources（资源）：参考文档、数据等辅助材料

3. 核心机制：渐进式披露

Skill 采用渐进式披露（Progressive Disclosure）机制，信息按需分级加载，而不是一次性全部塞入上下文：

传统 System Prompt

所有规则一次性全量塞入上下文→Token 浪费、注意力分散、指令漂移

Skill 渐进式披露

Agent 按需加载技能片段→Token 高效利用、执行精准

具体分为三个层级：

目录层（低成本）：Agent 平时只知道有哪些 Skill 可用（相当于只看手册目录）
摘要层（按需加载）：当用户请求匹配某个 Skill 时，加载该 Skill 的详细指令
执行层（深度加载）：需要执行具体操作时，加载脚本、模板等完整资源

4. Skill vs MCP

对比项	Skill（工作手册 📖）
定位	教 Agent 怎么做：封装流程、知识、指令
组成	SKILL.md • 脚本 + 模板 + 资源
加载方式	渐进式披露，按需加载
关系	互补关系：一个 Skill 内部可以调用 MCP 提供的工具来完成任务。Skill 定义"做什么、怎么做"，MCP 提供"用什么工具做"。

简单来说：Skill 是 SOP 手册，MCP 是工具箱。 手册里会写"第三步用扳手拧螺丝"，而扳手就是通过 MCP 提供的。

5. 应用场景

Skill 特别适合需要标准化、流程化的企业任务：

客户服务：封装投诉处理、退换货等特定流程的 SOP
数据分析：根据文件类型自动选择分析方法并生成报告
文档编辑：如 Claude 的 PDF 编辑功能，就是通过 PDF Skill 实现的

6. 如何使用 Skill

Skill 目前已获得多个平台的支持：

平台	支持状态	使用方式
Claude Code	完整支持	原生集成
Claude.ai	完整支持	设置上传
VS Code	完整支持	chat.useAgentSkills
Cursor	完整支持	文档支持
GitHub Copilot	完整支持	原生集成
OpenAI Codex	完整支持	官方支持

Anthropic 官方 Skill 仓库：https://github.com/anthropics/skills

Agent Skills 开放标准官网：https://agentskills.io

六、Harness

Agent = Model + Harness。

图中最核心的位置是 Model——那个蓝色芯片图标，代表 Claude 的大语言模型。但模型本身只是一个推理引擎，它不能独立行动。真正让它变成 Agent 的，是包裹在它周围的五个 Harness 组件。

Tools（工具），模型的手脚。Read、Write、Edit、Bash、Grep……这些工具赋予模型与文件系统、终端、网络交互的能力。没有工具，模型只能说，不能做。
Context（上下文），模型的记忆加载器。CLAUDE.md、系统提示词、对话历史、工具定义——这些上下文在每一轮循环中被注入模型，决定了模型看到什么、知道什么。上下文管理的精妙之处是，它不仅是被动的信息传递，还包括主动的压缩和重注入策略。
Memory（记忆），模型的长期存储。跨会话的记忆持久化，让模型能“记住”你的偏好、项目规则和历史决策。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 的能力都会大打折扣。

2.4 Agent.md 19 KB Байнгын холболт Түүх Анхны өгөгдөл