AI Agent 什么时候该用 Agent？
从 Claude Skills 到 Manus 三文件系统的思考
January 8, 2026·15 min read·Yimin
#AI#Agent#Claude Code#Skills#Manus
不是所有任务都需要 Agent。简单任务用简单方式，复杂任务才需要复杂架构。
🎯 一个核心问题
"帮我写个 commit" 和 "帮我调查 AI 市场报告"，这两个请求有本质区别：
- 前者：套用格式，一步完成
- 后者：搜索、分析、整合，步骤未知
AI 怎么知道该用哪种方式处理？
这是我在研究 Claude Code Skills 和 Manus 三文件系统时思考的核心问题。本文不是教程，而是一些思考和想法。
一、Claude Code Skills：给 AI 的说明书
1.1 什么是 Skills？
打开 Claude Code，输入一个问题，AI 就能帮你写代码、读文件、执行命令。但如果你想让它遵循特定的代码规范，或者了解你公司的技术栈，怎么办？
Skills 就是答案。
Skills 是存放在 ~/.claude/skills/ 目录下的 Markdown 文件，每个文件定义了一个"技能"——可以是代码规范、工作流程、领域知识，或者任何你希望 AI 知道的信息。
~/.claude/skills/
├── emoji-helper/
│ └── SKILL.md # Emoji 使用指南
├── git-commit-helper/
│ └── SKILL.md # Git 提交规范
└── time-helper/
└── SKILL.md # 时间格式帮助
1.2 Skills 的工作原理：渐进式披露
Claude Code Skills 采用了一种叫做**渐进式披露（Progressive Disclosure）**的架构设计。这个概念来自用户体验设计领域——不要一次性把所有信息扔给用户，而是根据需要逐步展示。
Skills 系统将每个技能分为三个层级：
┌─────────────────────────────────────────────────────────────┐
│ Skills 三层架构 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第一层：元数据（Metadata） │ │
│ │ ────────────────────────── │ │
│ │ • 技能名称、描述 │ │
│ │ • 启动时加载 │ │
│ │ • 让 AI 知道"有哪些技能可用" │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ 任务匹配时 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第二层：指令（Instructions） │ │
│ │ ────────────────────────── │ │
│ │ • 具体的操作指南和流程 │ │
│ │ • 当任务与某个 Skill 匹配时加载 │ │
│ │ • 告诉 AI "这个技能怎么用" │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ 需要执行时 │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第三层：资源（Resources） │ │
│ │ ────────────────────────── │ │
│ │ • 可执行脚本、模板、参考资料 │ │
│ │ • 按需加载和执行 │ │
│ │ • 实际的"工具" │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
为什么要这样设计？
想象一下，如果你有 50 个 Skills，每个 Skill 都有详细的指令和资源。如果启动时全部加载，上下文窗口会被塞满，AI 反而会"信息过载"。
渐进式披露的好处：
- 节省上下文空间：只加载当前任务需要的内容
- 提高响应速度：减少不必要的 token 处理
- 保持专注：AI 只看到相关的知识，不被无关信息干扰
渐进式披露的实现逻辑
渐进式披露的核心是分阶段加载，整个过程分为四步：
┌─────────────────────────────────────────────────────────────┐
│ 渐进式披露流程 │
│ │
│ 第一步：启动时 - 扫描元数据 │
│ ───────────────────────────── │
│ 遍历 ~/.claude/skills/ 目录，只读取每个 SKILL.md 的 │
│ YAML 前言部分（名称、描述），缓存起来。 │
│ 此时 AI 知道"有哪些技能可用"，但不知道具体内容。 │
│ │
│ 第二步：用户提问时 - 匹配技能 │
│ ───────────────────────────── │
│ 把用户问题 + 元数据列表发给 AI，让它判断： │
│ "这个问题需要用到哪些技能？" │
│ AI 返回相关技能的名称列表。 │
│ │
│ 第三步：按需加载 - 读取指令 │
│ ───────────────────────────── │
│ 只加载匹配到的技能的完整内容（指令部分）， │
│ 其他不相关的技能不加载，节省上下文空间。 │
│ │
│ 第四步：执行时 - 加载资源 │
│ ───────────────────────────── │
│ 如果技能包含脚本、模板等资源，在实际需要执行时才读取。 │
│ │
└─────────────────────────────────────────────────────────────┘
关键点：
- 启动时只加载"目录"（元数据），不加载"内容"
- 用 AI 来判断需要哪些技能，而不是简单的关键词匹配
- 只加载需要的，不需要的永远不会占用上下文
- 资源（脚本/模板）是最后才加载的
组合能力的实现
组合能力的核心在于匹配 + 拼接 + AI 理解：
┌─────────────────────────────────────────────────────────────┐
│ 组合能力原理 │
│ │
│ 用户问题: "帮我写个 commit，带时间戳和 emoji，修复了 bug" │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第一步：匹配 │ │
│ │ AI 扫描元数据，判断需要： │ │
│ │ → emoji-helper（涉及 emoji） │ │
│ │ → git-commit-helper（涉及 commit） │ │
│ │ → time-helper（涉及时间戳） │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第二步：拼接 │ │
│ │ 把三个技能的指令内容合并到一起： │ │
│ │ │ │
│ │ ┌─────────────────────────────────────────┐ │ │
│ │ │ ## emoji-helper │ │ │
│ │ │ 开发相关: 🐛 Bug, 🔧 修复, ✨ 新功能 │ │ │
│ │ │ │ │ │
│ │ │ ## git-commit-helper │ │ │
│ │ │ 格式: <type>(<scope>): <description> │ │ │
│ │ │ │ │ │
│ │ │ ## time-helper │ │ │
│ │ │ 格式: [ts:1234567890] │ │ │
│ │ └─────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第三步：AI 综合理解 │ │
│ │ AI 看到所有相关知识后，自然会综合运用 │ │
│ │ │ │
│ │ 输出：🐛 fix(auth): 修复用户登录验证错误 [ts:xxx] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
核心洞察：
组合能力不是靠复杂的编排算法，而是靠 AI 的理解能力。
你不需要写代码告诉 AI "先用 emoji-helper 选个 emoji，再用 git-commit-helper 格式化，最后用 time-helper 加时间戳"。你只需要把相关的知识放到它面前，它就会自动综合运用。
这就是为什么 Skills 系统如此简单却如此强大——模块化设计 + AI 理解能力 = 无限组合可能。
1.3 资源层：Script 的执行与结果传递
前面提到的三层架构中，第三层是"资源"——包括脚本、模板、配置文件等。这些资源如何被执行？执行结果如何传递给后续步骤？
资源的类型
┌─────────────────────────────────────────────────────────────┐
│ Skills 可以包含的资源类型 │
│ │
│ 📜 脚本（Scripts） │
│ - Shell 脚本：获取系统信息、执行命令 │
│ - Python 脚本：数据处理、API 调用 │
│ │
│ 📄 模板（Templates） │
│ - 代码模板：React 组件、API 接口 │
│ - 文档模板：README、报告格式 │
│ │
│ 📋 配置（Configs） │
│ - 规则配置：ESLint、Prettier 规则 │
│ - 参数配置：API 端点、默认值 │
│ │
└─────────────────────────────────────────────────────────────┘
Script 的执行流程
以 time-helper 为例，假设它包含一个获取时间戳的脚本：
┌─────────────────────────────────────────────────────────────┐
│ Script 执行流程 │
│ │
│ 1. AI 理解任务 │
│ 用户问: "当前时间戳是多少？" │
│ AI 判断: 需要执行 time-helper 的脚本 │
│ │
│ 2. AI 生成工具调用 │
│ AI 输出一个"工具调用请求"： │
│ → 调用 run_command，参数：date +%s │
│ │
│ 3. 系统执行 │
│ Claude Code / Agent 框架捕获这个请求， │
│ 在终端执行命令，获取输出：1767856455 │
│ │
│ 4. 结果返回给 AI │
│ 执行结果被追加到对话上下文： │
│ "命令 date +%s 的输出是：1767856455" │
│ │
│ 5. AI 继续处理 │
│ AI 看到结果后，继续生成回答或执行下一步 │
│ │
└─────────────────────────────────────────────────────────────┘
结果如何传递给下一个 Skill？
这是一个关键问题。答案是：通过上下文传递。
┌─────────────────────────────────────────────────────────────┐
│ 多 Skill 协作的结果传递 │
│ │
│ 用户: "获取当前时间戳，然后帮我写个 commit" │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第一轮：time-helper 执行 │ │
│ │ │ │
│ │ AI 思考: 先获取时间戳 │ │
│ │ AI 调用: run_command("date +%s") │ │
│ │ 系统返回: 1767856455 │ │
│ │ │ │
│ │ 上下文现在包含: │ │
│ │ [...之前的内容..., "时间戳结果: 1767856455"] │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 第二轮：git-commit-helper 使用结果 │ │
│ │ │ │
│ │ AI 思考: 现在用获取到的时间戳写 commit │ │
│ │ AI 看到上下文中有 "1767856455" │ │
│ │ AI 生成: fix(auth): 修复登录bug [ts:1767856455] │ │
│ └─────────────────────────────────────────────────────┘ │
│ │
│ 关键：结果通过【上下文】自然传递 │
│ AI 能"看到"之前的执行结果，并在后续步骤中使用 │
│ │
└─────────────────────────────────────────────────────────────┘
三种结果传递方式
| 方式 | 描述 | 适用场景 |
|---|---|---|
| 上下文传递 | 结果留在对话历史中，AI 自然能看到 | 简单任务、单次对话 |
| 文件传递 | 结果写入文件（如 notes.md），后续读取 | 复杂任务、需要持久化 |
| 变量传递 | 结果存入环境变量或状态对象 | 编程框架、需要精确控制 |
为什么上下文传递能工作？
因为 AI 具有理解上下文的能力。它不需要显式的"变量传递"或"函数返回值"，只要信息在上下文中，它就能理解并使用。
这也是 Skills 系统简单却强大的原因：
- 不需要复杂的数据流编排
- 不需要定义输入输出接口
- AI 自动理解上下文，自动关联信息
局限性
当然，这种方式也有局限：
- 上下文有长度限制，信息太多会丢失
- AI 可能"忘记"早期的结果（注意力失焦）
- 不适合需要精确数据传递的场景
这就是为什么 Manus 的三文件系统如此重要——它用文件来补充上下文的不足，让结果传递更可靠。
二、Manus 三文件系统：20 亿美元的简单
2.1 AI Agent 的"注意力失焦"困境
AI Agent 在执行复杂任务时，本质上是在与自己的"短期记忆"作斗争。
想象一下这个场景：
用户: "帮我分析 5 个竞品，然后写一份市场报告"
AI 的上下文窗口变化：
├── 第 1 步: [系统提示] [用户问题] ← 清晰
├── 第 5 步: [系统提示] [用户问题] [搜索结果×3] ← 还行
├── 第 15 步: [...] [网页内容×5] [分析×3] [错误×2] ← 开始乱
├── 第 30 步: [...×50] 早期目标被淹没 ← 迷路了
└── 第 50 步: AI 开始做无关的事情（目标漂移） ← 完全失焦
这就是"注意力失焦"：上下文窗口中的信息不断堆积，早期设定的目标被淹没在工具调用、中间结果和错误信息的海洋中。
2.2 三文件的精妙设计
Manus 的解决方案简单到令人难以置信——只用三个 Markdown 文件：
┌─────────────────────────────────────────────────────────────┐
│ 📋 task_plan.md - 认知锚点 │
│ ─────────────────────────── │
│ - [x] 收集竞品列表 │
│ - [x] 分析竞品 A │
│ - [x] 分析竞品 B │
│ - [ ] 分析竞品 C ← 当前进度 │
│ - [ ] 整合数据 │
│ - [ ] 撰写报告 │
│ │
│ 🎯 每次决策前重新读取，强制"认知重置" │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 📝 notes.md - 外部记忆库 │
│ ───────────────────────── │
│ ## 竞品 A │
│ - 价格: $99/月 │
│ - 用户数: 10 万 │
│ - 优势: 界面简洁 │
│ │
│ ## 竞品 B │
│ - 价格: $149/月 │
│ - ... │
│ │
│ 📦 按需读取，不占用上下文窗口 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ 📄 deliverable.md - 最终产出 │
│ ───────────────────────── │
│ # 竞品分析报告 │
│ │
│ ## 1. 市场概述 │
│ ... │
│ │
│ ## 2. 竞品对比 │
│ ... │
│ │
│ 🎁 与中间过程分离，确保输出一致性 │
└─────────────────────────────────────────────────────────────┘
2.3 边执行边规划：ReAct 模式的精髓
Manus 不是一个"先规划、后执行"的系统，而是边执行边规划的 ReAct 模式。这才是它真正强大的地方。
传统规划 vs ReAct 模式
传统方式：先想好再做
───────────────────────────────
1. 收到任务
2. 制定完整计划（步骤 1-10）
3. 按计划执行
4. 遇到问题？重新规划...
问题：现实很少按计划进行
ReAct 模式：边做边想
───────────────────────────────
1. 收到任务
2. 思考（Thought）：下一步该做什么？
3. 行动（Action）：执行一个操作
4. 观察（Observation）：看看结果如何
5. 根据结果，回到步骤 2
优势：实时适应，灵活调整
三文件如何支撑 ReAct 模式
task_plan.md 不是一个"一次性制定"的计划，而是动态演化的路线图：
初始状态：
- [ ] 分析竞品（具体有哪些？先搜索看看）
执行一步后：
- [x] 搜索竞品列表
- [ ] 分析竞品 A: Cursor
- [ ] 分析竞品 B: Copilot ← 搜索后才知道有这些
- [ ] 分析竞品 C: Cline
- [ ] 整合报告
遇到问题后：
- [x] 搜索竞品列表
- [x] 分析竞品 A: Cursor
- [ ] 分析竞品 B: Copilot（官网打不开，换个数据源）← 自主调整
- [ ] 尝试从 GitHub 获取 Copilot 信息 ← 新增的替代步骤
- [ ] 分析竞品 C: Cline
- [ ] 整合报告
Manus 的自主决策能力
| 特性 | 描述 |
|---|---|
| 自主判断错误 | 工具调用失败？记录错误，分析原因，尝试替代方案 |
| 动态调整策略 | 发现新信息？更新 task_plan，调整后续步骤 |
| 多路径探索 | 一条路走不通？尝试其他方法，直到找到可行方案 |
| 实时学习 | 把经验写入 notes.md，后续步骤可以参考 |
这意味着什么？
- ✅ 更灵活：不会死板地执行预定计划，能应对意外情况
- ✅ 更智能：能从错误中学习，越做越聪明
- ⚠️ 更不可预测：同样的任务，可能走不同的路径
- ⚠️ 需要护栏：自主决策需要边界，否则可能跑偏
ReAct 循环 + 三文件 = 有记忆的自主 Agent
┌─────────────────────────────────────────────────────────────┐
│ 每一轮决策循环 │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 1. Thought（思考） │ │
│ │ 读取 task_plan.md → "我现在该做什么？" │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 2. Action（行动） │ │
│ │ 执行操作：搜索/分析/调用工具/写文件... │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 3. Observation（观察） │ │
│ │ 成功？失败？有新发现？ │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ 4. Update（更新状态） │ │
│ │ - 更新 task_plan.md（标记完成/调整计划） │ │
│ │ - 更新 notes.md（记录发现/经验） │ │
│ │ - 必要时写 deliverable.md │ │
│ └─────────────────────────────────────────────────────┘ │
│ ↓ │
│ 回到步骤 1 │
│ （直到任务完成或需要人工介入） │
└─────────────────────────────────────────────────────────────┘
2.4 三文件的正交性
这三个文件的美学在于它们的正交性——每个文件解决一个独立的问题：
| 文件 | 在 ReAct 中的角色 | 类比 |
|---|---|---|
| task_plan.md | 认知锚点 + 动态路线图 | 🗺️ 可以随时修改的地图 |
| notes.md | 外部记忆 + 经验积累 | 📓 越写越厚的笔记本 |
| deliverable.md | 产出容器 + 边界标志 | 📦 最终要交付的包裹 |
2.5 为什么这么简单却价值 20 亿？
因为它解决了 AI Agent 的根本性挑战——让 AI 能够像人一样"边做边想、边想边调整"，而且：
- 零训练成本：不需要微调模型，任何 LLM 都能用
- 普适性强：可以部署到任何 AI 平台
- 效率提升显著：上下文长度减少 30-50%，响应更快、成本更低
- 自主性提升：AI 不再是"执行者"，而是"问题解决者"
对于像 Meta 这样需要服务数十亿用户的企业，这种能力提升直接转化为产品差异化和用户价值。
三、核心问题：AI 如何判断任务复杂度？
这是构建 AI Agent 时最关键的问题之一。
3.1 两种截然不同的任务
┌─────────────────────────────────────────────────────────────┐
│ "帮我写个 commit" │
├─────────────────────────────────────────────────────────────┤
│ 复杂度: ★☆☆☆☆ │
│ 响应方式: 直接回答 │
│ 需要: git-commit-helper skill │
│ 步骤: 1 步 → 套用格式，输出结果 │
└─────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────┐
│ "帮我调查 AI 编程助手的市场报告" │
├─────────────────────────────────────────────────────────────┤
│ 复杂度: ★★★★★ │
│ 响应方式: ReAct + 三文件系统 │
│ 需要: 多轮搜索、分析、整合 │
│ 步骤: N 步 → 动态规划，边做边调整 │
└─────────────────────────────────────────────────────────────┘
问题来了：AI 怎么知道该用哪种方式？
3.2 复杂度判断的信号
AI 判断任务复杂度，主要依赖这些信号：
| 信号 | 简单任务 | 复杂任务 |
|---|---|---|
| 步骤数 | 1-2 步可完成 | 需要多步、未知步数 |
| 信息完整性 | 用户已提供所有信息 | 需要搜索/收集信息 |
| 结果确定性 | 结果格式明确 | 结果需要动态生成 |
| 依赖关系 | 无依赖 | 后续步骤依赖前面结果 |
| 时间跨度 | 即时完成 | 可能需要多轮交互 |
3.3 实现思路：复杂度路由
一个可行的实现方式是在 System Prompt 中加入"复杂度判断规则"：
当收到用户请求时，先评估复杂度：
【简单任务】直接响应
- 格式转换（写 commit、转换时间戳）
- 知识查询（解释概念、推荐 emoji）
- 单步操作（创建文件、修改配置）
【复杂任务】启动三文件系统
- 涉及"调查"、"分析"、"报告"、"对比"
- 需要多次搜索或外部信息
- 用户无法一次性提供完整需求
- 预计超过 3 个独立步骤
3.4 一个观点：让 AI 自己判断
有趣的是，现代 LLM 本身就具备一定的复杂度判断能力。
Claude Code 的做法是：不显式判断，而是通过 Skills 的组合让 AI 自然选择。
- 如果你安装了
git-commit-helperskill，AI 遇到 commit 请求时自然会用它 - 如果你安装了
task-plannerskill 并说明"复杂任务时使用"，AI 会自己判断何时启动
这其实是一种隐式路由：通过 Skill 的 description 字段，AI 自己匹配最合适的处理方式。
3.5 我的想法
如果要构建一个更可控的系统，可以考虑：
- 显式分层：用户可以手动选择"快速模式"或"深度模式"
- 预判 + 确认：AI 先判断复杂度，向用户确认后再执行
- 渐进升级：从简单响应开始，发现需要更多步骤时自动升级到三文件模式
这是一个开放问题，没有标准答案。不同的应用场景可能需要不同的策略。
四、融合架构：一个简单的框架
把前面的内容整合起来：
┌─────────────────────────────────────────────────────────────┐
│ AI Agent 框架 │
│ │
│ 用户请求 → [复杂度判断] → 简单？→ Skills 直接响应 │
│ ↓ │
│ 复杂？ │
│ ↓ │
│ 启动三文件系统 │
│ ┌─────────────┐ │
│ │ task_plan │ ← 规划 + 追踪 │
│ │ notes │ ← 外部记忆 │
│ │ deliverable │ ← 最终输出 │
│ └─────────────┘ │
│ ↓ │
│ ReAct 循环执行 │
│ Think → Act → Observe → 重复 │
│ │
└─────────────────────────────────────────────────────────────┘
核心思想：
| 层面 | 回答的问题 | 何时使用 |
|---|---|---|
| Skills | AI 知道什么 | 始终加载（静态知识） |
| 三文件 | AI 怎么记住 | 复杂任务时启用 |
| ReAct | AI 怎么执行 | 复杂任务时启用 |
五、总结
这篇文章讨论了三个层面的问题，但最关键的其实是：
不是所有任务都需要 Agent。简单任务用简单方式，复杂任务才需要复杂架构。
Manus 的三文件系统很巧妙，但它是为复杂、长周期、多步骤的任务设计的。如果只是"帮我写个 commit"，一个 Skill 就够了。
构建 AI Agent 系统时，记住这个原则：
复杂度匹配：任务复杂度 ≈ 系统复杂度
希望这篇文章能给你一些启发。
参考资源
- Claude Code 官方文档
- Manus 技术解析 - 三文件系统详细分析
- ReAct 论文 - Reasoning + Acting 的原始论文