Agent 架构的演化逐渐分化出了四条最主要的路径：“Single Agent → Multi-Agent → Agent Skills → Agent Teams”
Agent架构为什么需要演化，就是因为我们在 基础大模型无法完美内化“领域知识”和高效复用“长期记忆” 的背景下，不断尝试“外挂”出这些能力的。
本质上就是大家对大模型如何更好的注入领域知识和记忆管理这两方面的需求，不断促进了Agent架构的演化。
Single Agent架构
Single Agent指的是“狭义的”基于ReAct的自主Agent概念，使用System Prompt驱动、串行调用工具的原生Agent运行模式
核心逻辑
既然大模型无法直接内化我们特定的领域知识，那我们就通过System Prompt的方式，将这些知识“无脑”地注入到大模型的上下文中，期望它能基于这些注入的信息生成符合预期的答案。
你只需要将领域知识整理好，配合清晰的指令写入系统级指令的System Prompt中，再使用基础模型原生的ReAct模式自主调用工具、记录上下文并解决问题。
对于生成简单的代码段、写文案、执行某类标准化输出等场景，这种串行调用的单Agent模式往往能跑出最流畅的体验，是验证想法、ROI最高的原型方案
优势
实现简单、开发快、运行效率高，适合快速验证和简单场景。
劣势
上下文窗口易爆炸：注入海量知识会导致“关键信息遗忘”（Lost in the Middle）问题
长上下文并不等于长记忆。当输入数据量达到一定阈值时，模型极易出现“Lost in the Middle”问题，也就是“注意力缺失”或者“关键信息遗忘”的现象，导致其无法精准定位到所需的领域知识，最终输出的结果偏离预期
解决方案
行业普遍采用的解决方案是引入 RAG（检索增强生成）
[[RAG是什么]]
RAG 可以看作是在Single Agent基础上的一次重要演进。它的核心逻辑是“先搜后答”：在将知识注入大模型之前，先利用搜索工具进行一轮召回（Recall），仅将与用户问题相关度最高的那部分片段提取出来，作为上下文提供给 Agent。
这在一定程度上巧妙规避了 Context Window 的长度限制，让 Agent 能够“按需获取”知识，而非“全量吞咽”。然而，RAG架构的效果存在一个致命的依赖链——“垃圾进，垃圾出”（Garbage In, Garbage Out）。Agent 的 最终表现高度依赖于前置搜索环节的准确率。如果检索阶段未能召回正确的知识片段，无论后端的大模型能力多强，都无法生成正确的答案
flowchart TD
A["用户问题
（例如：ECS远程连接失败？）"] --> B["嵌入模型
（小模型）"]
B --> C["将问题转化为
向量"]
C --> D["向量数据库
（存储着海量领域知识）"]
D --> E{"相似性检索"}
E --> F["召回 Top-K 个
最相关的知识片段"]
F --> G["提示词组装"]
G --> H["将问题 + 召回片段
组合成最终提示词"]
H --> I["大语言模型
（LLM）"]
I --> J["生成最终答案"]
style A stroke-width:2px
style B fill:#e1f5fe,stroke:#01579b
style I fill:#fff9c4,stroke:#fbc02d
style J stroke-width:2px