3.1 大脑：LLM 是 Agent 的决策核心#

LLM 在 Agent 里扮演的角色不是”回答问题”，而是做决策——决定下一步该调用哪个工具、该怎么拆解任务、该什么时候停下来。

这对模型的推理能力要求很高。早期用 GPT-3.5 跑 Agent 常常出现”幻觉工具调用”（调用了根本不存在的工具）、“死循环”（反复执行同一个动作）等问题。GPT-4、Claude 3 系列之后，这类基础可靠性才算过关。

从工程角度选模型，要考虑三件事：

1. Function Calling 支持质量：能不能稳定输出结构化的工具调用指令，不乱加东西、不漏字段？
2. 长上下文处理能力：Agent 运行多轮后，上下文会变得很长，模型在 10K~100K Token 的情况下还能保持注意力吗？
3. 指令遵循能力：你给了系统提示说”只在必要时才调用搜索工具”，模型会乱用吗？

不同场景选不同模型完全正常。代码相关任务 Claude 系列表现优秀，中文场景可以考虑 DeepSeek，成本敏感的场景可以用小模型做路由、大模型做最终决策。

3.2 记忆：Agent 怎么”记住”东西#

记忆是 Agent 工程里最容易被忽视、也最容易踩坑的部分。

按照存储位置和生命周期，Agent 的记忆可以分为四类：

3.3 工具：Agent 的手和脚#

工具（Tools / Functions）是 Agent 与外部世界交互的唯一通道。没有工具，Agent 只能在上下文里”空想”，无法真正执行任何操作。

常见的工具类型：

工具的设计直接影响 Agent 的行为质量。一个好的工具定义应该：

• 名称直观：search_web 比 tool_001 强一百倍
• 参数最小化：只暴露 Agent 必要的参数，复杂性留在工具内部
• 返回格式统一：永远返回结构化数据，不要让 Agent 去解析自由文本
• 包含错误信息：工具失败时返回清晰的错误描述，让 Agent 能做决策

3.4 规划：Agent 怎么拆解任务#

对于简单任务，Agent 可以边想边做（ReAct 模式）。但对于复杂任务，没有提前规划的 Agent 很容易走偏——做了十几步之后才发现方向错了。

规划能力的好坏，大致决定了 Agent 能处理多复杂的任务。后面会详细讲几种主流的规划架构。

4.1 ReAct：最经典的边想边做#

ReAct（Reasoning + Acting）是最广泛使用的 Agent 架构，来自 2022 年的同名论文。核心思路是让模型在行动之前先输出推理过程：

Thought: 用户想知道今天北京的天气，我应该先用天气工具查一下
Action: weather_tool(city="北京")
Observation: 晴，最高气温 22°C，最低气温 10°C
Thought: 已经拿到天气数据了，可以回答了
Final Answer: 今天北京天气晴，气温 10~22°C，适合外出。

ReAct 的优势：

• 推理过程透明，便于调试
• 灵活性强，适合动态决策
• 不需要预先确定任务步骤

ReAct 的陷阱（工程上必须处理）：

1. 无限循环：模型可能反复调用同一个工具，永远到不了终止条件

   • 解决：强制设置 maxIterations（建议 10~20），超过直接报错或强制结束

2. 幻觉行动：模型声称要调用工具，但输出格式不符合 function calling 规范

   • 解决：严格校验工具调用格式，格式错误直接返回错误提示让模型重试

3. 上下文膨胀：每一轮 Thought/Action/Observation 都在加长 Prompt

   • 解决：压缩中间结果，只保留关键信息

// LangChain ReAct 示例（核心代码）
const executor = await AgentExecutor.fromAgentAndTools({
  agent: createReactAgent({ llm, tools, prompt }),
  tools,
  maxIterations: 15,        // 必须设！
  returnIntermediateSteps: true,  // 调试用
  handleParsingErrors: true,      // 格式错误自动重试
});

4.2 Plan-and-Execute：先谋后动#

Plan-and-Execute 把任务分成两个阶段：

1. Planner：一次性生成完整的执行计划（步骤列表）
2. Executor：按计划逐步执行，每步可用工具

输入：写一份关于新能源汽车市场的调研报告

[Planner 生成计划]
Step 1: 搜索 2026 年新能源汽车全球销量数据
Step 2: 搜索国内主要品牌市场份额
Step 3: 搜索行业分析师对未来趋势的预测
Step 4: 整合以上信息，生成报告大纲
Step 5: 根据大纲撰写完整报告

[Executor 逐步执行]
执行 Step 1 → 得到结果 → 执行 Step 2 → ...

适用场景：

• 任务步骤相对固定，不需要根据中间结果动态调整
• 需要向用户展示执行进度（“正在进行第 3/5 步…”）
• 步骤之间有明确的依赖关系

缺点：

• 计划一旦生成，适应变化的能力弱
• Planner 的规划质量决定了整体效果，如果计划本身有问题，Executor 再努力也没用

现实中，很多工程师会把 Plan-and-Execute 和 ReAct 结合：用 Plan-and-Execute 做高层规划，每个步骤内部用 ReAct 动态执行。

4.3 Multi-Agent：让专家团队协作#

当单个 Agent 的能力或上下文窗口不够用时，就需要多个 Agent 协作。

典型场景：开发一个完整的软件功能，需要：

• Research Agent：调研需求、竞品分析
• Architecture Agent：设计系统架构
• Coding Agent：写具体代码
• Testing Agent：生成测试用例、运行测试
• Review Agent：代码审查、安全检查

每个 Agent 有自己的专属工具集和系统提示，分工处理不同子任务。

多智能体的五种协作模式：

Multi-Agent 的工程警告：

多 Agent 系统的调试难度是单 Agent 的好几倍。出了问题，你要追踪 Agent A 传给 Agent B 的是什么，B 又是怎么理解的，B 传给 C 时丢了什么——这条链路很痛苦，尤其是在生产环境下没有完整日志的时候。

建议：永远从单 Agent + 工具开始。只有在确认单 Agent 无法胜任时，才考虑引入多 Agent。

5.1 上下文压缩：怎么不让 Prompt 撑爆#

长任务的 Agent 会在上下文里积累大量的 Thought/Action/Observation，线性增长，很快超出模型的上下文限制（哪怕是支持 200K Token 的模型，在成本和延迟上也会越来越贵）。

几种压缩策略的对比：

策略一：滑动窗口
保留最近 N 轮交互，丢弃更早的内容
- 优点：实现简单
- 缺点：早期的重要信息会丢失

策略二：摘要压缩
每隔 K 轮，让模型对历史内容生成摘要，用摘要替换原始内容
- 优点：保留关键信息，大幅压缩 Token
- 缺点：摘要本身可能失真，额外增加 LLM 调用成本

策略三：重要性过滤
让模型或规则引擎标记每条信息的重要程度，只保留重要信息
- 优点：精准保留关键内容
- 缺点：重要性判断本身不可靠

策略四：外部化存储
把中间结果写入外部存储（数据库/文件），上下文里只保留引用
- 优点：理论上无上限
- 缺点：需要设计好检索机制，否则检索回来的内容不相关

实践中，摘要压缩 + 外部化存储的组合最常见：结构化的结果（搜索结果、代码输出）外部化，对话流程用摘要压缩。

5.2 记忆一致性：跨会话的状态管理#

单次对话的 Agent 不用考虑跨会话问题。但如果你要构建一个有”长期记忆”的 Agent（比如个人助理、持续运行的工作流），就要面对一个问题：怎么在多次会话之间保持状态一致？

几个实际场景：

• 用户上周说过”我不喜欢用 Python，我只用 TypeScript”，这周问代码问题时 Agent 应该记住这个偏好
• 一个跨天运行的数据分析任务，Agent 需要知道昨天已经处理了哪些文件
• 用户的历史决策和偏好应该影响今天的建议

工程实现路径：

1. 用户画像持久化：把用户的稳定偏好（语言偏好、风格偏好、背景信息）存入数据库，每次会话开始时加载到系统提示
2. 任务状态机：用明确的状态机记录长任务的进度，支持中断和恢复
3. 事件日志：记录所有重要操作的历史，为后续决策提供依据

6.1 幂等性设计#

如果 Agent 调用了一个”发送邮件”的工具，但因为网络超时没拿到响应，它可能会重试——结果用户收到了两封邮件。

所有会产生副作用的工具，必须设计幂等性。

常见实现方式：

• 请求中携带唯一的 requestId，服务端检测重复请求并直接返回上次结果
• 对于不可撤销操作（发邮件、转账），要求 Agent 先展示计划让用户确认，再执行

6.2 权限控制分级#

不是所有操作都应该让 Agent 无限制地执行。一个合理的权限分级：

Level 0 - 只读操作（自由执行）
  搜索网页、读取文件、查询数据库

Level 1 - 可逆写操作（自动执行，但记录日志）
  创建文件、修改草稿、写入缓存

Level 2 - 不可逆操作（需要用户确认）
  删除文件、发送邮件、提交代码、转账支付

Level 3 - 危险操作（默认拒绝）
  执行任意系统命令、访问敏感配置文件

6.3 工具失败的处理策略#

工具调用失败是常态，不是异常。网络超时、API 限流、返回格式变化……这些都会发生。

Agent 对工具失败的处理方式设计：

// 工具包装器：统一处理失败情况
async function callToolWithRetry(tool, args, maxRetries = 3) {
  for (let i = 0; i < maxRetries; i++) {
    try {
      const result = await tool.call(args);
      return { success: true, data: result };
    } catch (error) {
      if (i === maxRetries - 1) {
        // 最后一次失败：返回结构化错误让 Agent 决策
        return {
          success: false,
          error: error.message,
          suggestion: "工具调用失败，请考虑使用替代方案或通知用户"
        };
      }
      // 指数退避重试
      await sleep(1000 * Math.pow(2, i));
    }
  }
}

让 Agent 知道工具失败了，并提供足够的信息让它自行决策（重试、换工具、或者告知用户），而不是直接抛出异常终止任务。

7.1 LangChain / LangGraph#

LangChain 是目前生态最完整的 Agent 框架，主流 LLM 和工具基本都有集成。

LangGraph 是 LangChain 团队推出的有向图执行引擎，适合需要明确状态管理的 Agent 工作流：

from langgraph.graph import StateGraph, END

# 定义状态
class AgentState(TypedDict):
    messages: list
    next_step: str

# 构建图
workflow = StateGraph(AgentState)
workflow.add_node("planner", plan_node)
workflow.add_node("executor", execute_node)
workflow.add_node("reviewer", review_node)

workflow.add_conditional_edges(
    "executor",
    lambda state: state["next_step"],  # 根据状态决定下一跳
    {"review": "reviewer", "done": END, "retry": "executor"}
)

适用场景：需要精细控制执行流程的生产级 Agent，尤其是状态机型工作流。

7.2 AutoGen#

微软开源的多智能体框架，核心是让多个 Agent 像人类团队一样对话协作：

import autogen

# 定义两个 Agent
user_proxy = autogen.UserProxyAgent("user", human_input_mode="NEVER")
assistant = autogen.AssistantAgent("assistant", llm_config=llm_config)

# 启动对话
user_proxy.initiate_chat(
    assistant,
    message="帮我分析这份销售数据并生成可视化图表"
)

AutoGen 的特色是支持人机混合决策（可以在特定节点暂停等待人工确认），适合高风险操作场景。

适用场景：需要人机协作、或者多 Agent 辩论式决策的复杂任务。

7.3 CrewAI#

以”角色扮演”为核心概念，每个 Agent 有明确的 Role、Goal 和 Backstory：

from crewai import Agent, Task, Crew

researcher = Agent(
    role="市场研究员",
    goal="收集并分析目标市场的竞争数据",
    backstory="你有 10 年市场研究经验，擅长从海量数据中发现趋势",
    tools=[search_tool, scrape_tool]
)

writer = Agent(
    role="商业分析师",
    goal="将研究结论转化为清晰的商业建议报告",
    backstory="你擅长将复杂数据翻译为高管可读的决策建议",
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process="sequential"
)

result = crew.kickoff()

适用场景：需要快速搭建原型，任务分工明确，角色定位清晰的多 Agent 系统。

7.4 框架选型决策树#

需要 Claude 深度集成？
  ├── 是 → Claude Agent SDK
  └── 否 → 继续往下

单 Agent 还是多 Agent？
  ├── 单 Agent → LangChain（生态最全）
  └── 多 Agent → 继续往下

需要人工介入节点？
  ├── 是 → AutoGen
  └── 否 → 角色分工明确吗？
            ├── 是 → CrewAI（快速原型）
            └── 否 → LangGraph（精细控制）

原则 1：能不用 Agent 就不用#

这是最重要的原则。

很多场景其实不需要 Agent：如果任务步骤是固定的，直接写代码；如果只需要一次 LLM 调用，不要包装成 Agent。引入 Agent 意味着引入不确定性、延迟、成本和调试难度。

只有当任务需要动态决策、步骤不确定、需要自主使用工具时，Agent 才真正有价值。

原则 2：从最简单的架构开始#

单模型调用 → 单 Agent + 工具 → Plan-and-Execute → Multi-Agent

每升级一级，复杂度至少翻倍。从最简单的能解决问题的架构开始，有真实需要再升级。

原则 3：日志是你的生命线#

Agent 的执行过程是不透明的。生产中要记录：

• 每次 LLM 调用的输入/输出（含 Token 数）
• 每次工具调用的入参/出参/耗时/结果
• 每次 Agent 的决策推理（Thought 内容）
• 异常和错误信息

没有日志，出了问题根本没法排查。

原则 4：为每个工具设置超时#

工具调用不加超时，会让 Agent 卡在那里耗尽资源：

const result = await Promise.race([
  tool.call(args),
  new Promise((_, reject) =>
    setTimeout(() => reject(new Error("工具调用超时（30s）")), 30000)
  )
]);

原则 5：测试用例要覆盖边界情况#

Agent 的测试比普通代码难，因为 LLM 输出有随机性。但以下场景必须测试：

• 工具全部不可用时，Agent 怎么处理
• 用户输入极度模糊时，Agent 会做什么
• 任务无法完成时，Agent 会无限循环还是优雅退出

原则 6：用确定性代码替换能替换的部分#

Agent 的每一步决策都是不确定的。如果某个步骤的逻辑是确定的（比如”如果找到了数据就继续，否则报错”），用代码实现比让 LLM 决策可靠 100 倍。

把 LLM 用在真正需要推理的地方，确定性逻辑用代码写死。

原则 7：留意成本#

Agent 的 Token 消耗量远超普通 LLM 调用。一个运行 20 轮的 ReAct Agent，每次用户请求可能消耗数万 Token。

几个降本策略：

• 用小模型做工具选择和路由，大模型只做核心推理
• 工具返回内容做截断，不要把整个网页塞进 Prompt
• 对高频重复的子任务做缓存（相同输入 → 相同工具调用序列）

原则 8：失败要快，不要慢#

遇到无法解决的情况，Agent 应该立刻报告失败，而不是无限重试耗尽资源。

设置明确的终止条件：最大迭代次数、最大执行时间、最大 Token 消耗。任何一个触发，立刻停下来告知用户。

原则 9：人工介入点要设计好#

对于高风险操作，在执行前给用户一个确认机会：

Agent: 我计划执行以下操作：
  1. 删除 logs/ 目录下所有超过 30 天的文件（共 1,247 个）
  2. 压缩 backups/ 目录并上传到 S3
  
预计释放磁盘空间：23.4 GB
请确认是否继续？[yes/no]

这一步看起来打断了”自主性”，但在用户信任还没建立起来之前，这比出了事再后悔要好得多。

原则 10：监控 + 告警#

生产 Agent 需要监控：

• 成功率：任务完成率趋势
• 延迟：P50/P95/P99 的响应时间
• 成本：每次任务的 Token 消耗
• 异常：工具调用失败率、LLM 报错率

任何指标异常，第一时间告警。

9.1 MCP（Model Context Protocol）正在成为标准#

Anthropic 推出的 MCP 协议正在快速被主流工具和平台采纳。它解决的问题是：如何让 LLM 以标准化的方式连接各种工具和数据源，而不是每次都要写定制集成？

MCP 的本质是一个工具调用的标准协议，类似 Web 世界的 REST API 规范。如果它真的普及，Agent 的工具生态会大幅扩张。

9.2 Computer Use 打开了新维度#

Claude 的 Computer Use 能力让 Agent 可以直接操作桌面 GUI——看屏幕、移动鼠标、点击按钮、输入文字。这意味着任何有 GUI 的软件都可以成为 Agent 的”工具”，不再需要 API。

大量没有 API 的企业内部系统，突然变得可以被 Agent 自动化了。这对于对接老系统的工程来说很有意思，不过稳定性还有待观察。

9.3 Long-context vs. RAG 的边界在模糊#

2024 年大家都在说 RAG 是必选项。但随着模型上下文窗口从 4K 扩展到 1M，一个问题浮出水面：是不是直接把所有文档塞进 Prompt 比 RAG 更简单可靠？

现实答案是：取决于场景。文档量少、需要精确引用时，直接放进 Prompt；文档量大、需要动态更新时，RAG 依然必要。两者不是非此即彼，而是工具箱里的两种工具。

9.4 Agent 评估体系正在成熟#

早期 Agent 的评估主要靠”感觉”——跑几个样例看看对不对。现在开始有更系统的评估框架：

• 轨迹评估（Trajectory Evaluation）：评估 Agent 的每一步决策是否合理，不只看最终结果
• 工具使用效率：完成任务用了多少次工具调用，是否有冗余
• 鲁棒性测试：在工具失败、输入模糊等对抗性场景下的表现