从 RAG、记忆到规划、反思和知识图谱，这些模式支撑着 ChatGPT、Claude Code、Cursor、GitHub Copilot 以及各类企业级 AI 助手。
Agent 不是一段提示词。它是分布式系统：检索信息、调用工具、记住上下文、做多步推理、验证自己的输出，再把一堆专业组件协调起来。今天做 AI 应用，理解这些架构模式已经和懂 REST API、数据库、微服务一样重要。
大多数教程把 Agent 讲成一条直线：用户 → LLM → 响应。这条链路应付简单问答没问题。一旦问题需要公司知识库、外部 API、长期记忆或多步推理，它就开始露馅：产生幻觉、忘掉之前的对话、超时，或者在复杂任务上直接失败。
原因是，生产环境里的 AI 系统是架构设计出来的，不是靠提示词堆出来的。现代 AI 应用正是把多种模式组合在一起，才做到可靠、可扩展、智能。下面逐一介绍这七种。
1. 检索增强生成（RAG）
问题所在
LLM 只知道自己训练时见过的东西，不会自动了解：
- 你公司的文档
- 内部 API
- 客户合同
- 源代码
- 数据库
- 最新的产品变更
文档一变就去微调模型不现实，所以生产系统选择在推理时动态检索相关信息。
架构流程
用户查询 → 查询重写（可选）→ 向量嵌入 → 混合搜索（向量 + BM25）→ Top-K 检索 → 重排序 → 上下文压缩 → LLM → 最终答案
工作原理
典型的生产 RAG 流水线分七步：
- 把用户查询转成向量嵌入（Embeddings）。
- 在向量数据库里搜语义相似的内容。
- 把词法搜索（BM25）和向量搜索结合起来。
- 用交叉编码器（Cross-encoder）对检索结果重排序。
- 压缩掉冗余信息。
- 组装最终 Prompt。
- 生成回答。
每一步都在提升回答质量，同时省 Token。
现实案例
GitHub Copilot
Copilot 不会把你的整个仓库塞给 LLM。它只检索附近的文件、导入的模块、引用符号和当前打开的编辑器标签页，只把相关代码放进 Prompt。
Amazon Q
你问"为什么我的 Lambda 访问不了 DynamoDB？“时，Amazon Q 会先检索 IAM 策略、AWS 文档、CloudFormation 模板和配置示例，再生成答案。
企业知识库助手
20,000 页 Confluence 当然不能全扔给模型。流水线先取前 20 个候选，重排序、去重压缩，最后只给 LLM 约 8K Token。幻觉少了，响应也快了。
生产环境注意事项
一个成熟的 RAG 系统通常包含：
- 混合搜索（Hybrid Search）
- 元数据过滤
- 重排序
- 分块优化
- 上下文压缩
- 引用生成
- 查询重写
适用场景
- 内部聊天机器人
- 客户支持
- 企业级搜索
- 文档助手
- AI Copilot
2. 规划者-执行者模式（Planner-Executor）
问题所在
任务一大，LLM 就招架不住。比如用户要"构建一个包含身份验证、API、图表、测试、部署和文档的分析仪表板”，这不是一项任务，是二十项。人会下意识地把问题拆开，Agent 也该这样。
架构流程
规划者代理先把目标拆成一组子任务：前端 UI、数据库、单元测试是一路，后端 API、身份验证、部署是另一路，各路并行推进，最后由结果聚合器收拢所有输出，拼成最终响应。
为什么有效
规划者把一个大 Prompt 拆成一堆小任务，每个子任务目标明确、上下文窗口小、思维链聚焦，准确率自然高。
现实案例
Claude Code 收到的指令不会只是"修复我的项目"。内部它实际执行的是：
理解代码库 → 定位受影响的文件 → 搜索依赖项 → 生成代码 → 运行测试 → 修复失败项 → 运行代码检查（Linting） → 更新文档 → 提交更改
每个阶段都为下一阶段提供输入。
实现框架
常见的编排框架：
- LangGraph
- CrewAI
- AutoGen
- Semantic Kernel
- OpenAI Agents SDK
大多数生产级代码助手都跑在这套架构上。
权衡利弊
优势：
- 推理能力更强
- 更容易调试
- 工作流模块化
- 幻觉率更低
代价：
- API 调用更多
- 延迟更高
- 编排逻辑更复杂
3. 工具调用模式（Tool Calling）
问题所在
LLM 自己干不了这些事：
- 执行 SQL
- 调用 GitHub API
- 发 Slack 消息
- 部署应用
- 查询 Kubernetes
它需要外部工具。
架构流程
用户请求 → LLM 判断需要哪个工具 → 生成 JSON 函数参数 → 工具执行器去调 GitHub、SQL、Slack 或 API → 拿回结构化结果 → 交还 LLM → 最终响应
示例
用户说"总结昨天 GitHub 的活动"，Agent 会走一遍：GitHub API → Pull Requests → Reviews → Issues → Commits → 总结。与其瞎猜，不如直接拉实时数据。
现代工具调用
现在的系统用结构化函数调用（Structured Function Calling），例如：
{
"tool": "get_weather",
"arguments": {
"city": "London"
}
}
应用在执行前会先验证 Schema。
生产环境最佳实践
- JSON Schema 验证
- 重试策略
- 权限检查
- 超时处理
- 并行工具执行
- 工具版本控制
现实案例
- ChatGPT
- Claude Code
- Cursor
- GitHub Copilot
- OpenAI Agents SDK
4. 记忆模式（Memory）
问题所在
没有记忆，每次对话都从零开始，等于和一个每五分钟就失忆的同事结对编程。记忆让系统能记住偏好、延续对话、跑完长流程。
架构流程
对话历史 → 记忆提取器按重要性打分 → 分存长期记忆和情景记忆 → 需要时用语义搜索召回 → 提示词构建器组装 → LLM
记忆类型
短期记忆（Short-term Memory）
维持当前会话的上下文。比如用户说"用 React，不用 Vue"，模型在本次对话里一直记着这个偏好。
长期记忆（Long-term Memory）
跨会话持久化用户偏好：首选编程语言、编码风格、时区、项目偏好。
语义记忆（Semantic Memory）
存事实性信息：仓库用的是 GraphQL、后端跑在 Node.js 上、数据库是 PostgreSQL。
情景记忆（Episodic Memory）
存经验。比如处理过一次生产故障：原因是 Redis 超时，修复方案是加大连接池。下次再排查同样的故障，就快多了。
生产环境注意事项
有效的记忆系统按重要性、置信度、近期程度、相关性给记忆打分。什么都存只会拖垮检索质量，好的记忆系统是有选择的。
现实案例
- ChatGPT Memory
- Claude Projects
- GitHub Copilot Workspace
- 企业级 AI 助手
5. 反思模式（Reflection）
问题所在
人很少交第一稿就完事，AI 也不该这样。反思就是在给出最终答案之前，多走一轮自我检查。
架构流程
生成方案 → 批评代理挑毛病 → 识别问题 → 改进答案 → 最终响应
代码生成示例
生成代码 → 编译 → 运行测试 → 分析错误 → 修复 Bug → 再次运行测试 → 交付
系统不信任第一版输出，而是迭代到满意为止。
反思适用的场景
- 代码生成
- 数学计算
- 报告撰写
- SQL 生成
- 研究分析
- 任务规划
权衡
质量是用推理时间换的，所以多数生产系统只在任务复杂度高时才开启反思。
6. 多智能体模式（Multi-Agent）
问题所在
一个 Agent 不可能样样精通。现在的 AI 系统越来越多地把复杂任务交给一群各司其职的专用 Agent 协作完成。
架构流程
协调员分派任务 → 研究、编码、测试三个 Agent 并行干活 → 审核 Agent 把关 → 最终响应
协作模型
顺序模式（Sequential）
规划者 → 研究 → 编码 → 测试
并行模式（Parallel）
研究、文档编写、安全检查、性能优化同时跑。
层级模式（Hierarchical）
经理 Agent 分派任务 → 专家 Agent 干活 → 审核员把关
黑板架构（Blackboard）
Agent 之间不直接传消息，而是通过共享内存协作，适合大型工作流。
现实案例
- Devin
- Claude Code
- CrewAI
- AutoGen
- 企业自动化平台
7. 知识图谱 + RAG（Knowledge Graph + RAG）
这是不少下一代 AI 系统正在演进的方向。传统 RAG 回答的是"哪些文档相似？"，知识图谱回答的是"这些实体怎么连接？"。两者一结合，系统就能推理，而不只是检索。
架构流程
用户问题 → 向量搜索和知识图谱多跳遍历并行 → 上下文融合层 → LLM → 智能答案
现实案例
开发者问"如果我改了 BundleOverview.tsx，可能会影响什么？"。传统向量搜索只会返回 5 个相似的 React 文件；知识图谱则沿着依赖链一路追下去：
BundleOverview.tsx → GraphQL 查询 → Bundle 解析器 → 后端服务 → 数据库表 → 契约测试 → 下游消费者
系统不是在找相似文档，而是在连通的实体之间做推理，由此可以得到：
- 影响分析
- 根因分析
- API 血缘关系
- 数据库血缘关系
- 依赖分析
- 安全爆炸半径
- 智能代码导航
这是图数据库 + LLM 在企业场景里最大的价值。
模式对比
整合所有模式
能力最强的 AI 系统不会只用一种模式，而是把几种拼进同一套架构：
用户请求 → 规划者代理 →（混合检索 | 工具发现）→ 知识图谱多跳推理 → 上下文构建器 → LLM → 反思引擎 → 记忆更新层 → 最终响应
注意看：LLM 只是整个系统里的一个组件。检索、规划、记忆、工具、编排、验证、推理这些围绕它的部分，才决定应用在生产环境里能不能站住。
结语
五年前做后端，要学的是 REST API、缓存、数据库、队列和微服务。今天做 AI，工具箱里又多了编排语言模型、检索系统、工具、记忆和推理这一整套。
最好的 AI 应用不是靠一条提示词跑出来的，是靠架构：多种模式协同，产出可靠、可扩展、可信的结果。看得懂这些基石的工程师，做的就不只是 Agent，而是下一代智能软件。
