主题
第 7 章 智能体与自动化：AI 的手脚
预计阅读 22 分钟 · 全文约 6,504 字
本章产出：一个能真正干活的智能体、一次编程智能体的实战记录，以及一套"让 AI 干活不伤本体"的权限方案。
开场：会聊天的 AI 和会干活的 AI，差在哪
你让聊天机器人帮你做这件事：
"帮我看看我电脑 D 盘里那个'项目'文件夹，里面有个 main.py，帮我找出里面的语法错误，改好，然后跑一下看看能不能正常运行。"
聊天机器人的回答会是：
"抱歉，我无法访问你的电脑文件。你可以把代码复制粘贴给我，我帮你看看。"
它没撒谎——它真的碰不到你的文件。 它只有一张嘴。
智能体的回答会是：
"好的。我先读一下 D:\项目\main.py。（调用文件读取工具）……发现第 12 行少了个冒号，第 27 行变量名拼错了。我改一下。（调用文件写入工具）……改好了，现在跑一下。（调用命令执行工具）……报错了，是第 35 行少了个 import。我再补上。（再跑）……跑通了，输出是 Hello World。"
差别不在脑子，在手。
这一章讲的就是：怎么给 AI 装上手脚——它需要的工具、它自己推进的循环、以及"怎么让它干活但别把家拆了"的权限控制。
7.1 Agent 原理：循环、规划、工具、记忆
一句话定义
智能体 = 模型 + 工具 + 循环 + 记忆。
四个部分缺一不可。缺工具 → 只会说不会做；缺循环 → 干一步就停；缺记忆 → 干到第三步忘了第一步。
图 7-1：ReAct 循环——智能体的心脏
循环：Agent 的心脏
普通程序是"输入→处理→输出"，一条直线。
智能体是循环：
┌─────────────────────────────────────┐
│ 1. 看当前状态（任务是什么、做到哪了） │
│ 2. 想下一步该干什么 │
│ 3. 调用工具去做 │
│ 4. 看工具返回的结果 │
│ 5. 判断：完成了吗？ │
│ ├─ 没完成 → 回到第 1 步 │
│ └─ 完成了 → 输出结果 │
└─────────────────────────────────────┘这个循环叫 ReAct（Reasoning + Acting），是绝大多数智能体的基本结构。
为什么需要循环？ 因为真实任务很少一步完成。修一个 bug 可能要读文件、改代码、跑测试、看报错、再改——这是五六步，而且每一步的结果决定下一步。
规划：想清楚再动手
简单任务靠循环就够了。复杂任务需要规划：
- 把大任务拆成小任务
- 排出执行顺序
- 边做边调整（发现某步做不了，改计划）
举个例子："帮我做一份竞品分析报告"
规划可能是：
1. 确定竞品清单（可能需要搜索）
2. 逐个收集信息（搜索 + 读网页）
3. 整理成表格（数据处理）
4. 分析差异（推理）
5. 写成报告（写作）
6. 检查数据准确性（核对）规划能力弱的智能体，会在复杂任务上"迷路"——做着做着忘了目标，或者陷入死循环。
工具：Agent 的手
工具就是函数。模型不直接执行，它输出"我要调用 X 工具，参数是 Y"，外面的程序替它执行，把结果还给它。
常见工具类型：
| 类型 | 例子 |
|---|---|
| 文件操作 | 读文件、写文件、列目录、搜索 |
| 命令执行 | 跑 shell 命令、跑 Python 脚本 |
| 网络 | 搜索、抓网页、调 API |
| 数据库 | 查询、插入、更新 |
| 专业工具 | 图像处理、PDF 解析、代码分析 |
记忆：Agent 的笔记本
短期记忆：当前任务的上下文（对话历史、工具返回结果）。
长期记忆：跨会话的信息（用户偏好、历史任务、知识库）。
为什么记忆重要：没有长期记忆，每次对话都从零开始；没有短期记忆管理，任务做到一半上下文就满了。
记忆管理的核心问题：上下文窗口有限，怎么在有限空间里装下最重要的信息。
常见做法：
- 摘要：把历史对话压缩成摘要
- 检索：需要时从长期记忆里查
- 分层：重要信息常驻，次要信息按需加载
7.2 function calling 协议详解
它是什么
function calling（函数调用）= 模型输出结构化指令，告诉程序"我要调用哪个函数、参数是什么"。
这是智能体"动手"的技术基础。
完整流程
第一步：你告诉模型有哪些工具可用
json
{
"tools": [
{
"type": "function",
"function": {
"name": "get_weather",
"description": "查询指定城市的天气",
"parameters": {
"type": "object",
"properties": {
"city": {"type": "string", "description": "城市名"}
},
"required": ["city"]
}
}
}
]
}第二步：模型判断要不要用工具
用户问："北京今天天气怎么样？"
模型输出：
json
{
"role": "assistant",
"tool_calls": [
{
"id": "call_abc123",
"function": {
"name": "get_weather",
"arguments": "{\"city\": \"北京\"}"
}
}
]
}第三步：你的程序执行工具
python
result = get_weather("北京") # 返回 {"temp": 25, "condition": "晴"}第四步：把结果还给模型
json
{
"role": "tool",
"tool_call_id": "call_abc123",
"content": "{\"temp\": 25, \"condition\": \"晴\"}"
}第五步：模型基于结果生成回答
"北京今天晴，气温 25 度。"
关键理解
模型不执行任何东西。 它只是"说要调用什么"。真正执行的是你的代码。
这意味着：安全性、权限、错误处理，全在你的代码里。模型说"删除所有文件"，你的代码可以选择不执行。
工具描述为什么重要
模型靠 description 判断"什么时候该用这个工具"。
描述写得烂：模型不知道什么时候用，或者用错。
描述写得好：明确说清"干什么、什么时候用、参数是什么"。
例：
差：查询天气
好：查询指定城市当天的天气情况，包括温度、天气状况、湿度。
当用户询问天气、气温、是否下雨时使用。并行调用
现代模型支持一次调用多个工具：
json
{
"tool_calls": [
{"function": {"name": "get_weather", "arguments": "{\"city\":\"北京\"}"}},
{"function": {"name": "get_weather", "arguments": "{\"city\":\"上海\"}"}}
]
}好处：一次问多个城市，不用来回好几轮。
7.3 MCP 协议：工具的 USB-C 接口
为什么需要 MCP
在 MCP 之前，每个 AI 客户端接工具的方式都不一样：
- ChatGPT 有插件体系
- Claude 有它自己的工具格式
- 各种客户端各有各的 MCP 前身
结果：工具开发者要为每个平台写一遍适配。
MCP（Model Context Protocol） 就是来解决这个的——统一标准，写一次，到处能用。
图 7-3：MCP 的客户端-服务器模型
MCP 的架构
┌─────────────┐ ┌─────────────┐
│ MCP 客户端 │ ◄─────► │ MCP 服务器 │
│ (AI 应用) │ 标准协议 │ (工具提供方) │
└─────────────┘ └─────────────┘- MCP 客户端：Cherry Studio、Claude Desktop、各种 AI 应用
- MCP 服务器：提供工具的程序（文件系统、数据库、浏览器、搜索……）
类比：客户端是电脑，服务器是外设，MCP 是 USB 协议。
MCP 能提供什么
MCP 服务器可以提供三类东西：
- Tools（工具）：能执行的动作（读文件、查数据库）
- Resources（资源）：能读取的数据（文件内容、数据库表）
- Prompts（提示词模板）：预设的提示词
常见 MCP 服务器
| 服务器 | 能力 |
|---|---|
| filesystem | 读写本地文件 |
| fetch | 抓取网页 |
| browser | 浏览器自动化 |
| sqlite/postgres | 数据库操作 |
| github | 操作 GitHub |
| memory | 长期记忆存储 |
| sequential-thinking | 结构化思考 |
怎么用 MCP
在客户端里配置（以 Cherry Studio 为例）：
- 打开设置 → MCP 服务器
- 添加服务器（填命令或配置文件）
- 启用
- 在对话里，AI 就能调用这些工具了
配置文件长这样（不同客户端格式略有差异）：
json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/dir"]
}
}
}注意那个路径参数——它限定了这个 MCP 服务器能访问的目录范围。这就是权限控制的入口。
MCP 的安全提醒
MCP 服务器是"给 AI 装的手"，装了什么手，它就能干什么。
- 装了 filesystem，它能读写你指定的目录
- 装了 browser，它能操作浏览器（包括你的登录状态）
- 装了命令执行，它能跑任意命令
原则：只装你信任的、只开你需要的、只给它该有的范围。
7.4 搭第一个智能体（以 Cherry Studio 为例）
智能体的三个组成部分
- 人设（系统提示词）：它是谁、怎么说话、有什么规矩
- 工具（MCP）：它能干什么
- 知识（知识库）：它知道什么
实战：搭一个"文档助手"
目标：能读你指定文件夹里的文档，回答问题，还能帮你整理成摘要。
步骤一：建智能体
- 打开 Cherry Studio → 智能体 → 新建
- 名字："文档助手"
- 系统提示词：
你是我的文档助手。你的任务是帮我理解和整理本地文档。
工作方式：
1. 当我说"读一下 XX 文件"，用 filesystem 工具读取
2. 回答问题时，优先基于读到的文档内容，不要凭空编造
3. 如果文档里没有相关信息，明确说"文档里没有提到"
4. 整理摘要时，用要点列表，每条不超过两句话
限制：
- 只读取我指定的目录，不要访问其他位置
- 不要修改任何文件，除非我明确要求
- 遇到不确定的内容，先问我步骤二：装工具
- 设置 → MCP 服务器 → 添加 filesystem
- 配置允许访问的目录（比如
D:\文档） - 启用
步骤三：测试
- 问："读一下 D:\文档\项目说明.md，总结三个要点"
- 看它是否调用工具、是否读到内容、总结是否准确
- 再问一个文档里没有的问题，看它会不会编
步骤四：迭代
- 发现它总结太啰嗦 → 在提示词里加"每条不超过 30 字"
- 发现它乱读文件 → 收紧目录权限
- 发现它爱编 → 加"没有就说没有，不许猜"
一个好智能体的特征
- 目标清晰：它知道自己该干什么
- 边界清晰：它知道什么不该干
- 工具够用：不需要太多，够完成任务就行
- 会承认不知道：不确定时会问，而不是硬编
常见错误
- 人设写太长：几千字的提示词，模型记不住，还费 token
- 工具装太多：装十个工具，它反而不知道用哪个
- 没有边界：什么都能干，结果什么都干不好
原则：小而专，胜过大而全。
7.5 Codex / Cline 接管真实项目
编程智能体和普通智能体的区别
普通智能体：能调工具，但主要工作是"回答问题"。
编程智能体：专门为"改代码"设计——读文件、改代码、跑测试、看报错、再改。
核心差异：编程智能体有验证闭环。改完能自己跑测试，看有没有改坏。
Codex CLI 实战
安装：
bash
npm install -g @openai/codex配置（接自己的 API）：
toml
# ~/.codex/config.toml
model = "gpt-5"
model_provider = "my-provider"
[model_providers.my-provider]
name = "My Provider"
base_url = "https://your-api.com/v1"
env_key = "OPENAI_API_KEY"使用：
bash
cd 你的项目目录
codex然后输入任务，比如：
这个项目里有一个 bug：用户登录后偶尔会 500 错误。
帮我找到原因并修复，修完跑一下测试。它会做什么：
- 读项目结构
- 找相关代码
- 分析可能的原因
- 提出修改方案（diff）
- 你确认后应用
- 跑测试
- 失败就再改
Cline 实战（VS Code 插件）
安装：VS Code 扩展市场搜 "Cline"。
配置：填 API key 和 base_url（支持 OpenAI 兼容接口）。
使用：
- 打开你的项目
- 侧边栏打开 Cline
- 输入任务
- 它会一步步：读文件 → 提议修改 → 你点"同意" → 应用 → 跑命令
Cline 的特点：每一步都给你看 diff，你确认了才改。适合"我想盯着它改"的人。
用编程智能体的三条铁律
铁律一：项目必须有 git。
它改坏了，git checkout . 一键回滚。没有 git，改坏了只能哭。
铁律二：读懂 diff 再确认。
不要一路点"同意"。它可能改错地方、删掉重要代码。
铁律三：先小任务试水。
别一上来就让它"重构整个项目"。先让它修一个小 bug、加一个小功能，看它靠不靠谱。
一个真实的工作流
1. git status 确认工作区干净
2. 新建分支：git checkout -b ai-fix
3. 让智能体干活
4. 它改完，你 review diff
5. 跑测试确认
6. 没问题：git commit
7. 有问题：git checkout . 重来这个流程能让你放心让它干活——因为它干坏的成本被 git 兜住了。
7.6 沙箱与权限：让 AI 干活不伤本体
为什么需要沙箱
智能体会真的执行。
- 它跑
rm -rf就是真删 - 它跑
curl就是真发请求 - 它改文件就是真改
沙箱就是"给它划一块活动区"，让它在里面随便造，造坏了也只坏这一块。
图 7-2：三层隔离的取舍
沙箱的三种实现
① 目录隔离（最简单）
限定它能访问的目录：
json
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/project"]
}
}
}它只能动 /home/user/project，碰不到别的地方。
② 容器隔离（更彻底）
把智能体跑在 Docker 容器里，容器只能看到挂载进去的目录，网络可以限制，进程隔离。
③ 虚拟机隔离（最彻底）
整个系统隔离，它做什么都影响不到宿主机。适合跑不可信的任务。
权限模式：分级授权
编程智能体通常有几种权限模式：
| 模式 | 能干什么 | 适合 |
|---|---|---|
| 只读 | 只能看，不能改不能跑 | 让它分析代码 |
| 询问模式 | 每次操作都要你确认 | 日常使用（推荐） |
| 工作区可写 | 能改项目文件，能跑命令 | 信任它的时候 |
| 全权限 | 整台机器随便造 | 只在自己搭的隔离环境里用 |
推荐：默认用"询问模式"，它每次要动手都问你。信任建立起来后，再逐步放开。
五个安全习惯
- 重要文件先备份（或者用 git）
- 敏感目录不给权限（比如
~/.ssh、浏览器配置目录） - 危险命令要确认（
rm、format、curl | bash） - 网络访问按需开（不需要联网的任务就别给网络）
- 定期检查它干了什么（看日志、看文件变更）
一个真实的风险案例
有人在智能体里装了"浏览器自动化"工具，让它"帮我登录某个网站查资料"。
智能体拿到了浏览器的控制权，也拿到了已登录的 cookie。后来这个智能体被一个恶意网页的内容"带偏"，把账号信息发到了一个外部地址。
教训：给了浏览器权限，就等于给了它你所有的登录状态。 这类权限要慎给，或者用独立的浏览器配置（无登录状态）。
7.7 工作流编排：n8n / Dify 入门
什么时候用工作流，什么时候用智能体
记住一句话：流程固定的用工作流，变数大的用智能体。
| 工作流 | 智能体 | |
|---|---|---|
| 流程 | 固定 | 自己规划 |
| 稳定性 | 高 | 低 |
| 成本 | 低（可预测） | 高（可能反复试错） |
| 调试 | 容易（看哪步错了） | 难（不知道它为什么这么想） |
能用工作流解决的，别用智能体。 这是省钱省心的铁律。
n8n 入门
n8n 是什么：开源的自动化工具，节点式画布，拖拖拽拽就能搭流程。
核心概念：
- 节点：一个动作（发 HTTP 请求、读文件、调 AI、发邮件）
- 连线：数据流向
- 触发器：什么时候开始跑（定时、Webhook、手动）
一个例子：每日资讯简报
[定时触发 每天8点]
↓
[HTTP 请求 抓取 RSS]
↓
[AI 节点 总结]
↓
[格式化 转成邮件正文]
↓
[发邮件]部署（Docker）：
bash
docker run -d --name n8n \
-p 5678:5678 \
-v n8n_data:/home/node/.n8n \
n8nio/n8n访问 http://localhost:5678，开始搭。
Dify 入门
Dify 是什么：AI 应用开发平台，内置模型接入、知识库、工作流、智能体。
适合：想快速搭一个"能用的 AI 应用"（带界面、带 API），不想从零写代码。
核心功能：
- 提示词编排
- 知识库（RAG）
- 工作流（可视化）
- 智能体（带工具）
- 对外提供 API
选型建议
| 需求 | 工具 |
|---|---|
| 纯自动化（不涉及 AI 也行） | n8n / Zapier |
| AI 应用（有界面、有知识库） | Dify / Coze |
| 深度定制 | 自己写代码 |
7.8 多智能体协作入门
什么是多智能体
多个智能体分工合作，完成一个复杂任务。
比如做一份研究报告：
- 研究员：查资料
- 分析师：分析数据
- 写手：写报告
- 审稿人：挑毛病
四个智能体，各干各的，最后汇总。
两种协作模式
模式一：流水线（串行）
研究员 → 分析师 → 写手 → 审稿人 → 成品简单、可控，但前面出错会传导到后面。
模式二：辩论/评审（并行）
┌→ 智能体A →┐
问题 → ├→ 智能体B →┼→ 汇总/评审 → 答案
└→ 智能体C →┘多个智能体各答一遍，然后对比、投票、综合。
适合：需要多视角、需要提高准确率的任务。
多智能体的坑
坑一：成本翻倍。 四个智能体干一个活，token 消耗是四倍起。
坑二：错误传导。 前一个智能体理解错了，后面全错。
坑三：通信开销。 智能体之间传递信息，本身也消耗上下文。
坑四：复杂度失控。 调试一个智能体已经够难，调试四个互相通信的，难度翻几倍。
建议：先用单智能体 + 工作流，真不够用了再上多智能体。
7.9 实战案例：从零搭一个"售后客服智能体"
需求
一个卖小家电的商家，每天收到 200 条售后咨询，80% 是重复问题：怎么退换、保修多久、怎么报修、发票怎么开。
目标：让智能体处理常见问题，答不了的转人工。
第一步：整理知识
把售后政策整理成结构化文档：
退换货政策
- 7 天无理由：未拆封、不影响二次销售
- 15 天质量问题：免费换新
- 超过 15 天：走保修流程
保修
- 整机 1 年，主要部件 2 年
- 保修需提供订单号
报修
- 客服登记 → 48 小时内安排上门
- 需要提供：订单号、故障描述、地址
发票
- 下单后 30 天内可申请
- 电子发票发邮箱关键：文档要"一句话能查到"，别写成营销软文。
第二步：写系统提示词
你是某小家电品牌的售后客服。
工作规则：
1. 只回答售后政策相关问题，其他问题礼貌说明"这个我不太清楚，帮您转人工"
2. 回答基于知识库，不要编造政策
3. 涉及金额、时限，必须准确引用政策原文
4. 用户情绪激动时，先安抚，再解决
5. 需要人工介入的情况：投诉、赔偿、法律纠纷、要求特殊处理
输出格式：
- 结论（一句话）
- 依据（引用政策条目）
- 下一步（用户要做什么）第三步：配知识库
把售后文档切块入库，检索 top-3 拼进上下文。
测试：
| 问题 | 期望 |
|---|---|
| "买了三天能退吗？" | 引用 7 天无理由条款 |
| "保修多久？" | 整机 1 年、主要部件 2 年 |
| "你们老板是谁？" | 答"这个我不清楚，帮您转人工" |
| "我要投诉！" | 安抚 + 转人工 |
第四步：加上"转人工"这个动作
智能体光会说话没用，要能"做事"：
json
{
"name": "transfer_to_human",
"description": "当用户要求投诉、索赔、法律纠纷，或问题超出知识库范围时，转人工客服",
"parameters": {
"type": "object",
"properties": {
"reason": {"type": "string", "description": "转人工原因"},
"summary": {"type": "string", "description": "对话摘要，方便人工接手"}
},
"required": ["reason", "summary"]
}
}这一步是智能体和聊天机器人的分水岭：它不只是回答，还能触发业务流程。
第五步：上线后看什么
- 拦截率：多少问题被智能体解决了（目标 70-80%）
- 误答率：答错的占比（必须人工抽检）
- 转人工原因分布：哪类问题它搞不定（用来补知识库）
一个真实数据：上线两周，拦截率 76%，误答率 2.3%（主要是"政策理解偏差"），转人工集中在"索赔"和"物流损坏"。
结论：知识库补了 20 条"物流损坏处理"的细则后，转人工率降了一半。
7.10 智能体的五种失败模式
模式一：工具饥饿
表现：明明有工具，它就是不用，直接编答案。
原因：系统提示没要求用工具；或者工具描述太模糊。
对策：系统提示写死"必须先查再答"；工具描述写清"什么时候必须用"。
模式二：工具滥食
表现：什么事都要调工具，简单问题也绕一大圈。
原因：工具太多、描述太宽泛。
对策：减少工具数量；描述里写清"只在 X 情况下用"。
模式三：循环打转
表现：反复调同一个工具，参数几乎一样，拿不到结果也不换思路。
原因：没有失败处理；错误信息不明确。
对策：错误信息里写清"为什么错、下一步该试什么"；系统提示要求"同一错误两次就停"。
模式四：目标漂移
表现：任务做到一半，忘了最初要干什么，开始做别的。
原因：上下文太长，早期指令被冲淡。
对策：每几轮注入一次"任务摘要"；把目标写在最后一条消息里。
模式五：过度自信
表现：任务没完成，它说"已完成"，还编一个结果给你。
原因：没有验证环节。
对策：要求它"执行后自己检查一遍，并说明检查了什么"；关键任务加独立校验步骤。
一张排查表
| 症状 | 先查什么 |
|---|---|
| 不用工具 | 系统提示 + 工具描述 |
| 乱用工具 | 工具数量 + 描述边界 |
| 打转 | 错误信息 + 停止条件 |
| 漂移 | 上下文长度 + 目标复述 |
| 假完成 | 验证环节 |
行业观察：客服智能体上线第一个月，被问最多的十个问题
某小家电品牌上线售后智能体后，后台统计的词频前十：
- "我的订单到哪了"（物流查询，占 31%）
- "怎么退"（退换流程，18%）
- "保修几年"（12%）
- "发票怎么开"（9%）
- "坏了找谁"（8%）
- "能便宜点吗"（6%）
- "有货吗"（5%）
- "能不能加急"（4%）
- "你们是不是正品"（3%）
- "转人工"（2%）
关键发现：排名第一的"物流查询"根本不该由 LLM 回答——它需要查数据库。
于是他们改了架构：物流类问题直接调订单系统接口，不经过模型。响应从 3 秒降到 0.3 秒，准确率从 82% 升到 100%。
行业经验：能用规则解决的，别用模型；能查数据库的，别让模型猜。
踩坑实录
坑一：给智能体装了太多工具
场景：有人给智能体装了文件、浏览器、搜索、数据库、邮件、日历……十几个工具。结果它经常选错工具，或者在一个简单任务上反复横跳。
为什么：工具太多，模型要在众多选项里选，选错的概率上升；而且工具描述都塞进上下文，占用大量 token。
怎么爬出来：一个智能体只装 3-5 个必需工具。 需要更多能力，拆成多个智能体。
坑二：没开权限控制，智能体删了文件
场景：有人让智能体"清理临时文件"，它把整个 temp 目录删了，包括里面还没处理完的数据。
为什么：给了全权限，指令又模糊，它按"最彻底"的方式执行了。
怎么爬出来：开沙箱、限目录、危险操作要确认；指令要具体（"删除 /tmp/xxx 目录下超过 7 天的文件"）。
坑三：以为智能体能自己纠错
场景：有人让智能体做数据分析，它算错了，还基于错误结果写了一大段分析。它自己没发现错。
为什么：智能体只会"检查它想到要检查的东西"。它没想到要验算，就不会验算。
怎么爬出来：在提示词里明确要求"完成后验算关键数字"；或者设计独立的校验步骤。
坑四：让智能体处理超出上下文的任务
场景：有人让智能体"读整个代码库然后重构"，它读了十几个文件后开始胡言乱语。
为什么：代码库太大，上下文装不下，它开始"记不清"。
怎么爬出来：把任务拆小（一次重构一个模块）；用支持代码索引的工具；给它明确的"只看这几个文件"的指令。
Lab 7-1｜搭一个能干活的智能体
难度：⭐⭐⭐☆☆ 预计耗时：60 分钟
目标：从零搭一个能调工具、能干活的智能体
步骤：
- 装 Cherry Studio（或你已有的客户端）
- 配置一个模型（API 或本地模型）
- 建一个智能体，取个名字，比如"文件管家"
- 写系统提示词：
你是我的文件管家。 任务：帮我整理和查询指定目录的文件。 规则： - 只操作我指定的目录 - 修改文件前必须先问我 - 不确定时先说"我需要确认"- 装 filesystem MCP，限定一个测试目录（新建一个空目录，放几个测试文件）
- 测试三个任务：
- "列出这个目录里有哪些文件"
- "读一下 xxx 文件，告诉我它讲了什么"
- "把这个目录里的文件按类型分类"（看它会不会动手改）
- 观察：它调了哪些工具？有没有越界？回答准不准？
验收标准：
- [ ] 智能体能正常调用工具
- [ ] 三个任务都完成
- [ ] 能说出"它在哪一步可能越界"
- [ ] 有一份自己的智能体配置（提示词 + 工具清单）
卡住了怎么办：
- MCP 装不上 → 检查 Node.js 版本，或换一个 MCP 服务器试
- 智能体不调工具 → 在提示词里明确写"必须使用 filesystem 工具"
- 它乱改文件 → 立刻收紧目录权限，只给空目录
本章自检清单
- [ ] 智能体的四件套是什么？
- [ ] ReAct 循环的五个步骤是什么？
- [ ] function calling 的完整流程是什么？模型负责哪一步？
- [ ] MCP 解决的是什么问题？
- [ ] 装 MCP 服务器时，权限控制在哪个参数上？
- [ ] 编程智能体和普通智能体的核心差异是什么？
- [ ] 用编程智能体的三条铁律是什么？
- [ ] 沙箱的三种实现方式是什么？
- [ ] 什么时候该用工作流，什么时候该用智能体？
- [ ] 多智能体的四个坑是什么？
学习进度：0 / 13 章
📝 本章小测验（3 题）
1. 智能体的四件套是？
2. function calling 中，真正执行工具的是谁？
3. 最常用的沙箱实现方式是？
一句话记住
智能体 = 脑子 + 手脚 + 循环 + 记忆；给它手脚的同时，别忘了给它围栏。
延伸阅读
- MCP 官方文档——协议规范、服务器列表
- Codex / Cline 官方文档——配置和用法
- n8n / Dify 官方模板——抄现成的工作流最快
最后更新：2026-10