AI_Agent核心机制_ReAct_MultiAgent_记忆系统

Mon, 13 Apr 2026 10:00:00 +0800

前言

从只会"被动回答"的闲聊机器人，到现在能自主查资料、写代码、甚至操作电脑的 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 的三大核心组件

┌─────────────────────────────────────────────────────────────┐
│                     AI Agent                                │
├─────────────────────────────────────────────────────────────┤
│  🤖 大脑 (LLM)        │ 感知环境、推理、决策                │
│  🔧 工具 (Tools)      │ 调用外部系统、执行动作               │
│  📝 记忆 (Memory)     │ 保存上下文、积累经验                 │
└─────────────────────────────────────────────────────────────┘

1.3 Agent Loop 运转机制

Agent 的核心是一个循环：

┌─────────┐    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 缺乏实时信息和容易产生幻觉的缺陷。

工作流程：

用户问题 → 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 反思自己的输出，不断改进。

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 机制

3.1 Tool Calling 原理

Tool Calling 允许 LLM 调用我们定义的 Java 方法：

`1`	`用户问题 → LLM 判断需要调用工具 → 返回工具名称+参数 → 执行工具 → 返回结果 → LLM 生成回答`

3.2 工具定义

{
  "name": "queryDatabase",
  "description": "查询数据库获取用户信息",
  "parameters": {
    "type": "object",
    "properties": {
      "sql": {
        "type": "string",
        "description": "SQL 查询语句"
      }
    },
    "required": ["sql"]
  }
}

3.3 Java 实现

@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 专注于特定角色或职能。

┌─────────────────────────────────────────────────────────────┐
│                   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 状态持久化

长任务需要状态机持久化：

// 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 断点续执行

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 多租户隔离

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 成本监控与控制
记忆质量管理与检索优化

MCP on Zell Blog