前言
从只会"被动回答"的闲聊机器人,到现在能自主查资料、写代码、甚至操作电脑的 AI Agent,各种新概念(如 ReAct、Plan-and-Execute、Reflection、Multi-Agent、MCP)层出不穷。
AI Agent 代表了软件工程的一次范式转移。过去我们需要穷举边缘情况,把规则写死在代码里;现在则将决策权交给 AI,换取处理复杂场景的灵活性。
一、AI Agent 基础概念
1.1 什么是 AI Agent
**AI Agent(人工智能智能体)**是一种能够感知环境、进行决策并执行动作的自主软件系统。它以大语言模型(LLM)为"大脑",代表用户自动化完成复杂任务。
与传统编程的对比:
| 方式 |
遇到预设外的情况时… |
| 传统编程 |
报错或走默认分支,需重新开发 |
| Workflow |
走预设兜底路径,无法真正理解情境 |
| Agent |
AI 实时分析情境,动态调整策略 |
1.2 Agent 的三大核心组件
1
2
3
4
5
6
7
|
┌─────────────────────────────────────────────────────────────┐
│ AI Agent │
├─────────────────────────────────────────────────────────────┤
│ 🤖 大脑 (LLM) │ 感知环境、推理、决策 │
│ 🔧 工具 (Tools) │ 调用外部系统、执行动作 │
│ 📝 记忆 (Memory) │ 保存上下文、积累经验 │
└─────────────────────────────────────────────────────────────┘
|
1.3 Agent Loop 运转机制
Agent 的核心是一个循环:
1
2
3
4
5
6
7
8
9
10
11
12
|
┌─────────┐ Think ┌─────────┐
│ LLM │ ──────────▶ │ Agent │
└─────────┘ └─────────┘
▲ │
│ ▼
│ ┌─────────┐
│ │ Tool │
│ │ Calling │
│ └─────────┘
│ │
│ ▼
└───────────────── Observe
|
Loop 三大步骤:
- Think:分析当前状态,决定下一步行动
- Act:调用工具或执行动作
- Observe:获取执行结果,更新状态
1.4 Agent vs 传统编程
| 维度 |
传统编程 |
Workflow |
Agent |
| 技能要求 |
编程语言 + 算法 + 系统设计 |
编程原理 + 图形化编排 |
自然语言描述意图 |
| 修改成本 |
数天至数周 |
数小时至数天 |
分钟级 |
| 适用场景 |
逻辑固定、高性能 |
流程清晰、步骤有限 |
动态决策、不确定步骤 |
二、Agent 调度范式
2.1 ReAct 范式
ReAct = Reasoning + Acting
将"思维链(CoT)推理"与"外部环境交互行动"相结合,弥补单纯 LLM 缺乏实时信息和容易产生幻觉的缺陷。
工作流程:
1
2
3
4
|
用户问题 → Think(分析) → Act(调用工具) → Observe(观察结果)
↑ │
└───────────────────────────────────────────────────┘
循环往复直至任务完成
|
ReAct 示例(排查线上服务变慢):
| 步骤 |
动作 |
结果 |
| 1 |
Think:需要先了解系统状态 |
- |
| 2 |
Act:调用监控工具查询 CPU/内存 |
CPU 飙升至 98%,有慢 SQL 告警 |
| 3 |
Think:CPU 高可能是数据库问题 |
- |
| 4 |
Act:调用日志工具查询慢 SQL |
发现语句未命中索引 |
| 5 |
Think:需要通知负责人 |
- |
| 6 |
Act:调用邮件工具发送通知 |
邮件发送成功 |
2.2 Plan-and-Execute 范式
LangChain 团队于 2023 年提出,先全局规划再逐步执行。
与 ReAct 的对比:
| 维度 |
ReAct |
Plan-and-Execute |
| 规划方式 |
动态、逐步规划 |
静态、全局预规划 |
| 适用场景 |
动态环境、需实时纠偏 |
步骤明确的长期复杂任务 |
| 容错能力 |
强(每步可动态修正) |
弱(环境变化需重新规划) |
| 上下文管理 |
随迭代持续增长 |
执行步骤相对独立,更可控 |
2.3 Reflection 范式
自我纠错闭环:让 Agent 反思自己的输出,不断改进。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public class ReflectionAgent {
public String solve(String problem) {
String solution = llm.generate(problem);
// 自我评估
EvaluationResult eval = evaluator.evaluate(problem, solution);
if (!eval.isSatisfactory()) {
// 反思改进
String reflection = llm.reflect(problem, solution, eval.getFeedback());
solution = llm.improve(problem, reflection);
}
return solution;
}
}
|
2.4 多范式对比总结
| 范式 |
核心思想 |
适用场景 |
| ReAct |
边推理边行动,动态纠错 |
工具调用、复杂推理 |
| Plan-and-Execute |
先规划后执行 |
长任务、多步骤 |
| Reflection |
自我反思改进 |
代码生成、内容创作 |
Tool Calling 允许 LLM 调用我们定义的 Java 方法:
1
|
用户问题 → LLM 判断需要调用工具 → 返回工具名称+参数 → 执行工具 → 返回结果 → LLM 生成回答
|
3.2 工具定义
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
{
"name": "queryDatabase",
"description": "查询数据库获取用户信息",
"parameters": {
"type": "object",
"properties": {
"sql": {
"type": "string",
"description": "SQL 查询语句"
}
},
"required": ["sql"]
}
}
|
3.3 Java 实现
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
@Bean
public ChatClient chatClient(ChatClient.Builder builder) {
return builder
.defaultFunction("queryDatabase", new QueryDatabaseFunction())
.defaultFunction("sendEmail", new SendEmailFunction())
.build();
}
public class QueryDatabaseFunction implements Function<DatabaseRequest, DatabaseResponse> {
@Override
public DatabaseResponse apply(DatabaseRequest request) {
return jdbcTemplate.queryForObject(request.getSql(), DatabaseResponse.class);
}
}
|
3.4 MCP 协议
MCP(Model Context Protocol) 是 Anthropic 提出的新兴标准化协议,统一工具调用接口。
MCP 原语类型:
| 类型 |
作用 |
示例 |
| Tools |
可执行的函数 |
查询数据库、发送邮件 |
| Resources |
只读数据资源 |
本地文件、数据库记录 |
| Prompts |
可复用的提示模板 |
代码审查模板、故障报告模板 |
3.5 安全防护
| 风险 |
防护措施 |
| Prompt Injection |
用户输入清洗、XML 标签隔离 |
| 权限控制 |
基于 Token/Session 的权限校验 |
| 超时熔断 |
CompletableFuture + Timeout / Sentinel |
四、Multi-Agent 系统
4.1 什么是 Multi-Agent
Multi-Agent 系统是指多个独立 Agent 通过协作完成单一复杂任务的架构,每个 Agent 专注于特定角色或职能。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
┌─────────────────────────────────────────────────────────────┐
│ Multi-Agent 系统 │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Agent A │◀──│ 通信 │──▶│ Agent B │ │
│ │ (搜索) │ │ (队列) │ │ (写作) │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ │ │ │ │
│ └──────────────┼──────────────┘ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Agent C │ │
│ │ (审核) │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
|
4.2 Agent 间通信
| 方式 |
实现 |
适用场景 |
| 消息队列 |
Kafka / Redis Stream |
松耦合、异步处理 |
| 接口调用 |
REST / gRPC |
紧耦合、同步调用 |
4.3 吴恩达的 Multi-Agent 范式
这是人工智能先驱吴恩达倡导的宏观概念,是上述所有范式的终极整合。
核心思想:让不同的专业 Agent 各司其职,通过协作完成复杂任务。
五、记忆系统
5.1 为什么需要记忆
LLM 的上下文窗口有限,Token 成本高昂。每次对话结束后,所有交互信息都会随 Session 消失。
记忆系统的价值:
- 让 Agent 在单次对话中保持连贯性
- 跨越多个 Session 积累用户偏好
- 从"一次性工具"进化为"长期协作伙伴"
5.2 记忆的三种类型
| 类型 |
说明 |
存储方案 |
| 短期记忆 |
当前对话的上下文 |
Redis(滑动窗口) |
| 长期记忆 |
用户偏好、历史知识 |
Neo4j / 向量库 |
| 工作记忆 |
当前任务相关的信息 |
动态加载 |
5.3 记忆存储形式
| 形式 |
说明 |
典型实现 |
| 外部化存储 |
自然语言存储在外部数据库 |
向量库中的文本块 |
| 参数化存储 |
编码进模型参数 |
LoRA 适配器、SFT 微调 |
| 隐式存储 |
承载在模型内部表示中 |
KV Cache、激活值 |
5.4 记忆生命周期
1
2
3
|
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ 写入 │───▶│ 读取 │───▶│ 压缩 │───▶│ 遗忘 │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
|
| 操作 |
说明 |
工程实现 |
| 写入 |
将原始交互转化为可存储的结构化信息 |
LLM 提取事实三元组 |
| 读取 |
根据上下文检索相关记忆 |
向量检索 + BM25 |
| 压缩 |
将短期记忆转化为长期记忆 |
对话摘要 |
| 遗忘 |
淘汰低价值或过时记忆 |
权重衰减 |
5.5 记忆检索优化
混合检索策略:
| 索引类型 |
作用 |
示例 |
| Vector |
捕捉语义相似性 |
“Java” 和 “Spring” 语义相关 |
| Graph |
捕捉关系 |
实体之间的关联 |
| Keyword |
捕捉专有名词 |
精确匹配 “Java 21” |
5.6 生产级记忆系统产品
| 产品 |
核心思想 |
技术亮点 |
| Mem0 |
两阶段记忆流水线 |
实体提取 → 关系生成 |
| Letta |
操作系统虚拟内存分页 |
Main ↔ External Context 动态交换 |
| Graphiti |
时间感知知识图谱 |
情景/语义/社区三层子图 |
六、工程实践
6.1 Agent 开发框架
| 框架 |
说明 |
| LangChain4j |
Java 版 LangChain,支持 Agent 编排 |
| Spring AI |
与 Spring 生态集成,工具调用支持 |
| Agent-Flex |
专注于 Agent 编排 |
6.2 状态持久化
长任务需要状态机持久化:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
// Spring State Machine
@Configuration
public class AgentStateMachineConfig {
@Bean
public StateMachine<AgentState, AgentEvent> stateMachine() {
// 定义状态转换规则
}
}
// 状态节点持久化
public class AgentTask {
Long id;
AgentState currentState;
Map<String, Object> context;
List<AgentStep> completedSteps;
}
|
6.3 断点续执行
1
2
3
4
5
6
7
8
9
10
11
12
|
public class AgentExecutor {
public void resume(Long taskId) {
AgentTask task = taskRepository.findById(taskId);
// 从上一断点继续
AgentState lastState = task.getCurrentState();
Map<String, Object> context = task.getContext();
// 继续执行
executeFrom(task.getNextStep(), context);
}
}
|
6.4 多租户隔离
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
public class TenantContext {
// 通过 ThreadLocal 或 MDC 传递租户 ID
public static String getCurrentTenantId() {
return MDC.get("tenant_id");
}
}
// 在检索时自动注入租户过滤
List<Document> results = vectorStore.similaritySearch(
SearchRequest.builder()
.query(question)
.filterExpression(
MetadataFilterExpression.builder()
.eq("tenant_id", TenantContext.getCurrentTenantId())
.build()
)
.build()
);
|
七、常见挑战与解决方案
| 挑战 |
具体问题 |
解决方案 |
| 上下文截断 |
长任务中历史信息被截断导致"遗忘" |
记忆压缩 + 分层上下文 |
| 幻觉传播 |
工具调用结果并不总能纠正错误推理 |
Reflection 自我纠错 |
| 成本失控 |
多轮迭代 + 工具调用 Token 消耗极高 |
Token 监控 + 阈值告警 |
| 安全风险 |
Prompt Injection 攻击 |
输入清洗 + 权限校验 |
| 规划瓶颈 |
深度多步推理容易陷入局部最优 |
Plan-and-Execute 全局规划 |
八、总结
AI Agent 代表着从"被动工具"向"自主执行的数字实体"的演进:
- ReAct:边推理边行动,动态纠错的循环机制
- Plan-and-Execute:先全局规划再逐步执行的静态规划
- Reflection:自我反思改进的闭环机制
- Multi-Agent:多 Agent 协作完成复杂任务
- 记忆系统:短期记忆 + 长期记忆支撑持续上下文
- MCP 协议:标准化的工具调用接口
构建 Agent 系统需要关注的工程问题:
- 状态持久化与断点续执行
- 多租户隔离与安全防护
- Token 成本监控与控制
- 记忆质量管理与检索优化