2024 年是 AI Agent 爆发的元年，2025-2026 是 Agent 走向工程化、生产化的两年。经历了从"用一个 prompt 做 Agent"到"用多个 Agent 协作"的转变，这篇文章梳理 AI Agent 的系统设计。
什么是 AI Agent
很多人把 Function Calling 的接口调用就叫做 Agent。我觉得不对。
Agent 的核心特征：它不只是"调 API 的聊天机器人"，而是能自主地规划、执行、观察、调整的智能体。
LLM 调用（普通的 Chat Completion）：
用户问 → LLM 回答 → 结束
Function Calling（调用工具的 LLM）：
用户问 → LLM 决定调工具 → 执行工具 → LLM 回答 → 结束
AI Agent（真正的智能体）：
用户给目标 → Agent 规划 → 执行第一步 → 观察结果
→ 调整计划 → 执行第二步 → 观察结果
→ ... → 达成目标 → 总结 → 结束
区别在于：Agent 有一个循环——规划、执行、观察、再规划。
Agent 三大件
一个完整的 Agent 系统由三个核心组件组成：
┌─────────────────────────────────────┐
│ AI Agent 系统 │
│ │
│ ┌───────────┐ ┌───────────────┐ │
│ │ Planning │ │ Memory │ │
│ │ (规划) │ │ (记忆) │ │
│ │ │ │ │ │
│ │ · 任务分解 │ │ · 短期记忆 │ │
│ │ · 反思 │ │ · 长期记忆 │ │
│ │ · 工具选择 │ │ · 向量存储 │ │
│ └───────────┘ └───────────────┘ │
│ │
│ ┌───────────┐ │
│ │ Tool Use │ │
│ │ (工具) │ │
│ │ │ │
│ │ · 工具注册 │ │
│ │ · 工具调用 │ │
│ │ · 结果处理 │ │
│ └───────────┘ │
└─────────────────────────────────────┘
Planning（规划）
规划是 Agent 区别于普通 LLM 调用最核心的能力。
ReAct（推理+行动循环）
最基础的 Agent 模式：
思考：用户问巴黎天气，我需要查天气 API
行动：query_weather("Paris")
观察：{"temp": "22°C", "condition": "sunny"}
思考：得到了天气数据，组织回答
回答：巴黎现在 22°C，晴天
ReAct 的「思考」和「行动」必须交替出现。如果 Agent 连续两次"思考"而没有"行动"，说明它在空转。
任务分解
对于复杂的目标，Agent 需要把任务分解成子任务：
用户目标："帮我分析这个季度的销售数据并生成报告"
Agent 计划：
Plan:
1. 连接数据库，获取 Q2 销售数据
2. 分析数据趋势，计算同比/环比
3. 生成分析图表
4. 撰写分析报告
5. 保存报告到指定位置
任务分解有两种方式：
- 自上而下：一次性输出完整计划，按顺序执行（适合确定性强的任务）
- 动态分解：执行一步后再决定下一步（适合不确定性强的任务）
反思与修正
Agent 执行过程中可能出错，需要能自我修正：
执行步骤 2 时出错：
数据库返回错误 → Agent 观察到错误
→ 反思："查询语句可能有语法错误"
→ 修正：重写查询语句 → 重试
这与"重试"不同。重试是机械地重新执行，反思是在理解错误后调整策略。
Memory（记忆）
LLM 本身是无状态的——每次对话都是全新开始。Agent 需要记忆系统来维持状态。
短期记忆
短期记忆 = 当前会话的上下文。通常就是对话消息历史。
关键问题：Token 溢出。当对话历史太长时，需要做上下文窗口管理。
饱和前的消息历史：
[系统提示词] + [用户问题1] + [助手回答1] + [工具调用1] + ...
→ 检查总 token 数 → 不超过模型限制 → 全部保留
饱和后的消息历史：
[系统提示词] + [摘要] + [用户问题5] + [助手回答5] + [工具调用5] + ...
→ 前 N 轮对话被压缩成摘要
→ 只保留最近的几轮完整消息
上下文管理的实现策略：
def trim_context(messages: list, max_tokens: int = 32000) -> list:
"""裁剪上下文到指定 token 数"""
system_prompt = messages[0] # 系统提示词始终保留
history = messages[1:]
# 从后往前保留
while count_tokens(history) > max_tokens - count_tokens([system_prompt]):
# 压缩最早的一轮对话为摘要
history[0] = summarize_turn(history[0])
# 如果还是太长，移除最早的
if count_tokens(history) > max_tokens - count_tokens([system_prompt]):
history.pop(0)
return [system_prompt] + history
长期记忆
长期记忆 = 持久化的、跨会话的信息。通常存为向量嵌入，用语义检索召回。
用户："上周我说要查的那个订单现在怎么样了？"
Agent 检索长期记忆：
→ 找到上周某次对话中用户提到的订单号
→ 拿到订单号，执行查询
→ 回复用户
长期记忆的检索需要解决一个问题：什么时候去检索？
- 方案 A：每次用户消息都检索（简单但浪费，90% 的检索用不上）
- 方案 B：让 LLM 判断是否需要检索（加一个决策步骤）
- 方案 C：用分类器判断（低开销，精确）
项目实践下来，方案 B 的效果最好——让 Agent 自己决定是否查询记忆。
Tool Use（工具使用）
工具是 Agent 与外部世界交互的接口。它的设计质量直接决定 Agent 的能力边界。
工具设计的最佳实践我在《Function Calling 机制》那篇文章里详细写了，这里只强调几个核心点：
- 工具是边界，不是累赘——精确控制 Agent 能做什么、不能做什么
- 工具描述决定调用质量——名字自解释、描述说明使用场景
- 错误处理闭环——工具执行失败时把错误信息传回给 Agent
四种 Agent 架构模式
2025-2026 年，Agent 架构形成了四种主流模式：
模式 1：单 Agent + 工具（Single Agent + Tools）
用户 → Agent LLM → 工具1 / 工具2 / 工具3 → 结果 → 用户
最简单的模式。一个 LLM 实例负责所有规划、推理、工具调用。
适合场景：任务边界清晰、工具数量少（< 15 个）、不需要多步协作。
代表框架：直接 OpenAI SDK + 自定义代码。
优点：简单、调试容易、成本低。
缺点：信息都挤在一个上下文里，工具多时选择准确率下降。
模式 2：结构化多 Agent（Graph-based）
┌──────────┐
│ Supervisor│
│ 路由/编排 │
└────┬─────┘
┌────┼────┐
▼ ▼ ▼
┌────┐┌────┐┌────┐
│A-1││A-2││A-3│
└────┘└────┘└────┘
Agent 之间的交互是预定义的 DAG（有向无环图）。Supervisor Agent 负责分发任务，子 Agent 执行后返回。
适合场景：工作流确定、需要审计追溯、金融/医疗等强监管。
代表框架：LangGraph。
优点：可预测、可审计、便于调试。
缺点：灵活性差、固定路径可能导致低效。
模式 3：事件驱动多 Agent（Event-driven）
Agent A ──(事件)──→ Agent B ──(事件)──→ Agent C
↕ ↕
Agent D ←──(事件)── Agent E
Agent 之间通过事件通信。Agent A 完成工作后发出事件，订阅该事件的 Agent B 自动启动。
适合场景：客服系统、分布式系统中高扩展性需求。
代表框架：AutoGen v0.4+。
优点：扩展性好、松耦合。
缺点：调试困难、非确定性行为可能带来问题。
模式 4：层级角色多 Agent（Hierarchical/Role-based）
Supervisor
/ | \
Writer Reviewer Editor
| | |
└───────┼───────┘
Output
Agent 被赋予角色（写手、审查员、编辑），有明确的层级关系。
适合场景：内容创作流水线、研究分析、需要质量把关的工作。
代表框架：CrewAI。
优点：角色定义清晰、输出质量高。
缺点：架构固定、不适合动态场景。
模式选型
你的场景 推荐模式
────────────────────────────────────────────────────
工具少、任务单一 单 Agent + 工具
业务流程固定、需要审计 LangGraph (图结构)
客服对话、QPS 大、需要灵活扩缩 AutoGen (事件驱动)
写作、研究、内容类 CrewAI (角色分层)
前期不确定、快速验证 单 Agent 起步
Agent 架构的演进路径
不要一开始就上 Multi-Agent。从简单到复杂的路径：
第 1 步：单 Agent + 工具
验证场景是否真的需要 Agent
验证 LLM 是否能正确处理核心工具
第 2 步：加 Memory
短期记忆（会话内）
长期记忆（跨会话）
第 3 步：拆成多 Agent（如果单 Agent 不够）
→ 可以按功能拆分
→ 可以按角色拆分
→ 可以按流程拆分
第 4 步：加编排层
Supervisor Agent
事件总线 / 路由层
监控和日志聚合
大部分场景在第 1 步就够了。Multi-Agent 不是目的，是手段——当单 Agent 的上下文窗口、工具选择准确率、模块化需求成为瓶颈时，才考虑拆分。
Agent 系统的陷阱
陷阱 1：All-in-One Prompt
"一个 prompt 搞定所有事"——这是最危险的陷阱。把所有的角色定义、工具描述、任务规则、输出格式塞到一个 prompt 里，结果是模型在多个目标之间"精分"。
好做法：分层 prompt（系统层、任务层、工具层各司其职）。
陷阱 2：过度自动化
让 Agent 自主决策一切（包括删除、修改、提交）。不加人工审核的 Agent 就像没人审核代码的 CI——迟早出事。
好做法：关键操作前加「人工确认门」，比如删除前必须用户二次确认。
陷阱 3：忽略失败路径
测试 Agent 时只测"顺利路径"。但 Agent 在真实环境中的大部分时间在跟错误打交道——工具调用失败、参数缺失、超时。
好做法：测试用例包括 3 种失败场景（工具报错、LLM 输出格式错误、网络超时），验证 Agent 是否能优雅处理。
陷阱 4：没有监控
Agent 不是传统的 API——同样的输入可能产生完全不同的行为路径。没有 trace 根本不知道 Agent 在哪里出问题。
好做法：每个步骤都记录（LLM 调用、工具调用、路由决策），用 Langfuse 或类似工具做可视化 trace。
总结
AI Agent 的设计，核心是在三个维度上做平衡：自主性 vs 可控性、能力 vs 成本、灵活性 vs 可预测性。
2026 年的共识是：Agent 的能力天花板已经非常高（前沿模型可以自主工作近 5 小时），真正的挑战在于如何让 Agent 的自主行为在复杂场景中保持可靠和安全。
未来的 Agent 不会只有一个。不同的 Agent 负责不同的事，通过标准的通信协议（MCP / A2A）协作。工程挑战从"如何让一个 Agent 做更多事"转向了"如何让多个 Agent 可靠地协作"。
评论