Agent = LLM + 记忆 + 工具 + 规划。从被动回答到主动行动的质变。
一、什么是 AI Agent
定义
AI Agent = 一个能自主感知环境、做出决策、采取行动、并根据反馈调整行为的AI系统。
与普通 ChatBot 的区别：
| 维度 | ChatBot | Agent |
|---|---|---|
| 交互模式 | 一问一答 | 自主规划、多步执行 |
| 工具使用 | 无 | 调用外部工具/API |
| 记忆 | 当前对话 | 短期+长期记忆 |
| 决策 | 被动响应 | 主动推理和规划 |
| 典型场景 | 聊天/问答 | 自动化任务/复杂工作流 |
Agent 核心循环
┌──────────────────────┐
│ Perceive (感知) │ ← 接收用户输入/环境信息
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Think (思考) │ ← LLM推理+规划
│ • 分析当前状态 │
│ • 决定下一步行动 │
│ • 选择工具 │
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Act (行动) │ ← 执行工具调用/生成输出
└──────────┬───────────┘
↓
┌──────────────────────┐
│ Observe (观察) │ ← 获取行动结果
└──────────┬───────────┘
↓
循环 or 结束二、Agent 设计模式
模式1：ReAct (Reasoning + Acting)
论文 ：Yao et al., 2022
核心：推理和行动交替进行
Thought: 用户想知道今天北京天气，我需要调用天气API
Action: get_weather(city="Beijing")
Observation: 北京今天晴，25°C，东南风3级
Thought: 已获取信息，可以回答了
Answer: 北京今天晴天，气温25°C，东南风3级，适合户外活动。优点 ：简单直观，最广泛使用
缺点：串行执行，没有全局规划
模式2：Plan-and-Execute（规划-执行）
核心：先制定完整计划，再逐步执行
Task: 帮我做一份竞品分析报告
Plan:
1. 确定竞品列表（3-5家）
2. 收集各竞品的产品特性数据
3. 收集各竞品的定价策略
4. 分析差异点和竞争优势
5. 生成对比表格
6. 撰写分析结论和建议
Execute:
Step 1: [执行] → [结果]
Step 2: [执行] → [结果]
...
Replan (if needed): 根据中间结果调整计划优点 ：有全局视角，适合复杂任务
缺点：初始计划可能不准确，需要Replan能力
模式3：Reflexion（反思）
论文 ：Shinn et al., 2023
核心：执行后自我评估，存储反思到记忆中，下次避免同类错误
Attempt 1: 执行任务 → 结果不佳
Reflection: "我犯了什么错？上次我忽略了边界条件"
Memory: 存储反思 → "检查边界条件"
Attempt 2: 执行任务（参考反思记忆）→ 结果改善优点 ：持续自我改进
适用：代码生成、推理任务
模式4：Multi-Agent（多Agent协作）
核心：多个专业化Agent分工协作
Orchestrator Agent（编排者）
├── Researcher Agent（研究员）→ 信息收集
├── Writer Agent（写手）→ 内容生成
├── Reviewer Agent（审核者）→ 质量检查
└── Coder Agent（程序员）→ 代码实现典型架构：
- 层级式：一个Boss Agent分配任务给子Agent
- 对等式：多个Agent互相讨论达成共识
- 流水线式：Agent A的输出是Agent B的输入
框架：
| 框架 | 特点 | 适用 |
|---|---|---|
| CrewAI | 角色定义+任务分配，简单易用 | 内容生成/研究类 |
| AutoGen (Microsoft) | 多Agent对话，灵活 | 复杂推理/辩论 |
| LangGraph | 状态图，可控流程 | 生产环境工作流 |
| MetaGPT | 软件公司角色模拟 | 代码生成 |
模式5：Tool-Use Agent（工具使用型）
核心：LLM决定何时调用什么工具
可用工具：
- search(query) → 搜索互联网
- calculator(expression) → 数学计算
- code_execute(code) → 执行代码
- database_query(sql) → 查询数据库
用户：上个月销售额同比增长多少？
Agent思考：需要查数据库获取本月和去年同期数据，再计算增长率
Action 1: database_query("SELECT SUM(amount) FROM sales WHERE month='2025-02'")
Action 2: database_query("SELECT SUM(amount) FROM sales WHERE month='2024-02'")
Action 3: calculator("(result1 - result2) / result2 * 100")
Answer: 上个月销售额同比增长23.5%三、工具调用 (Function Calling / Tool Use)
原理
模型不是"执行"工具，而是生成工具调用的JSON描述，由外部系统执行后将结果返回模型。
模型输入：用户问题 + 可用工具列表(JSON Schema)
模型输出：{"tool": "search", "arguments": {"query": "OpenAI revenue 2024"}}
系统执行：调用search API
系统返回：搜索结果文本
模型继续：基于结果生成最终回答Function Calling 定义格式
json
{
"name": "get_weather",
"description": "获取指定城市的当前天气信息",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "城市名称，如'北京'"
},
"unit": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "温度单位"
}
},
"required": ["city"]
}
}工具设计最佳实践
- 名称清晰：工具名和参数名要自描述
- 描述详细：description要告诉模型"什么时候用、怎么用"
- 参数精确：用enum限制取值范围，用required标记必填
- 粒度适中：不要太粗（一个工具干太多事）也不要太细（100个微工具）
- 错误处理：返回结构化错误信息，让模型知道失败原因并重试
- 幂等性：读操作幂等，写操作要谨慎
四、Agent 记忆系统
四种记忆类型
| 类型 | 对标人类记忆 | 作用 | 实现方式 |
|---|---|---|---|
| 工作记忆 | 工作记忆(Working Memory) | 当前任务的中间状态 | 当前对话上下文/Scratchpad |
| 短期记忆 | 短时记忆 | 近期对话内容 | 对话历史（滑动窗口） |
| 长期记忆 | 长时记忆 | 跨会话的用户信息/知识 | 向量数据库/文件系统 |
| 程序性记忆 | 程序性记忆 | 学会的技能/模式 | Skills/Prompt模板/习得的规则 |
记忆管理策略
┌─────────────────┐
新信息 ──→ │ 工作记忆 │ ← 容量有限（上下文窗口）
│ (当前任务) │
└────────┬────────┘
│ 重要信息沉淀
┌────────▼────────┐
│ 短期记忆 │ ← 对话历史（摘要压缩）
│ (近期对话) │
└────────┬────────┘
│ 跨会话持久化
┌────────▼────────┐
│ 长期记忆 │ ← 文件/数据库（永久存储）
│ (用户画像/知识) │
└─────────────────┘OpenClaw 的记忆架构（实例）
| 层 | 文件 | 记忆类型 |
|---|---|---|
| IDENTITY.md | 身份定义 | 程序性记忆（我是谁） |
| SOUL.md | 思考框架+行为准则 | 程序性记忆（我怎么思考） |
| MEMORY.md | 长期记忆库 | 长期语义记忆 |
| memory/日期.md | 每日记忆 | 情景记忆（发生了什么） |
| KNOWLEDGE-MAP.md | 知识图谱索引 | 长期语义记忆 |
| knowledge/*.md | 专业知识文件 | 长期语义记忆 |
| USER.md | 用户画像 | 长期记忆（关于用户） |
五、Agent 规划与推理
规划能力
| 策略 | 描述 | 适用 |
|---|---|---|
| 任务分解 | 将复杂任务拆成子任务 | 所有复杂任务 |
| 顺序规划 | 线性步骤执行 | 依赖关系明确的任务 |
| 并行规划 | 独立子任务并行执行 | 无依赖的信息收集 |
| 条件规划 | if-then分支执行 | 需要根据中间结果决策 |
| 迭代规划 | 执行→评估→重新规划 | 不确定性高的任务 |
常见失败模式与对策
| 失败模式 | 原因 | 对策 |
|---|---|---|
| 无限循环 | Agent重复相同动作 | 设置最大步数限制 |
| 工具误用 | 选错工具或参数错误 | 改进工具描述、增加示例 |
| 目标偏移 | 执行中偏离原始目标 | 每步检查与目标的对齐度 |
| 过度规划 | 花太多时间规划不执行 | 限制规划深度，快速迭代 |
| 幻觉行动 | 假装调用了工具实际没调用 | 严格验证工具调用结果 |
六、Agent 框架对比
| 框架 | 语言 | 核心理念 | 优势 | 劣势 |
|---|---|---|---|---|
| LangChain | Python/JS | 组件化链式调用 | 生态丰富，社区大 | 抽象层过多，调试难 |
| LangGraph | Python | 状态图驱动Agent | 流程可控，适合生产 | 学习曲线陡 |
| CrewAI | Python | 角色扮演多Agent | 简单直观 | 功能相对单一 |
| AutoGen | Python | 多Agent对话 | 灵活，微软背书 | 配置复杂 |
| Semantic Kernel | C#/Python | 微软企业级AI框架 | 企业集成好 | 生态较小 |
| Dify | Python | 低代码AI工作流平台 | 可视化编排 | 自定义受限 |
| Coze | 平台 | 字节跳动Bot平台 | 零代码快速搭建 | 灵活度低 |
选型决策
你的需求：
├── 快速原型/Demo → Coze / Dify（零代码）
├── 内容/研究类Agent → CrewAI（角色扮演）
├── 复杂工作流/生产环境 → LangGraph（状态图）
├── 多Agent辩论/推理 → AutoGen
├── 需要最大灵活度 → 直接调API + 自己写循环
└── 企业级/C# → Semantic Kernel七、Agent 评估
评估维度
| 维度 | 指标 | 衡量方式 |
|---|---|---|
| 任务完成率 | 成功完成任务的比例 | 自动化测试集 |
| 步骤效率 | 平均需要多少步完成 | 日志统计 |
| 工具调用准确率 | 是否选对工具和参数 | 日志审计 |
| 成本 | 每任务消耗的Token/API调用 | 监控面板 |
| 延迟 | 端到端响应时间 | 性能测试 |
| 安全性 | 是否执行了危险操作 | 红队测试 |
| 鲁棒性 | 面对异常输入的表现 | 边界测试 |
八、未来趋势
- Computer Use Agent：能操作电脑GUI（Claude Computer Use、Operator）
- 自主编程Agent：Devin、SWE-bench上的自主修Bug
- 具身Agent：连接机器人/IoT设备
- Agent-to-Agent通信：Agent之间用协议直接协作
- 长期自主Agent：7×24小时运行，自主学习和适应