智能体｜Agent 架构演进与选型

大模型能力一般具有“通用性”而非“专业性”，为了弥补专业的领域知识，Agent 架构应运而生，并经历了一场清晰而深刻的演进。

从独立工作的 Single Agent，发展到相互协作的 Multi-Agent，再进化到具备模块化专业技能的 Agent Skills，最终形成有机协同的 Agent Team。

架构的演进并非简单的功能堆砌，而是一场针对核心痛点持续的、系统性的 “补全”计划。

本文主要从 Agent 架构面临问题，四种 Agent演进方向和架构选型的角度进行展开。

1，架构演进的驱动力和方向

推动Agent架构演进的核心驱动力是什么?

本质上：

Agent架构的演进，是在基础大模型无法完美内化 “领域知识” 和高效复用 ”长期记忆” 的背景下，不断尝试”外挂”出这些能力的探索和尝试。

就像人一样，无法同时成为一个“通才” 和 “专才”，特定的领域知识也需要外挂”经验知识库”。如果想拥有长期的记忆，就需要借助“笔记本”回忆下。

因此，Agent 架构演进的核心线索始终围绕两大需求展开：

• • 如何更高效、精准地为大模型注入领域知识 - 解决“专业经验“问题
• • 如何更智能、持久地管理大模型的记忆与状态 - 解决“个人笔记本“

问题收敛到两个方面：

领域知识注入和记忆管理问题。

如何做？有两种思路：

向内—通过改变模型参数提升能力；向外—通过工程外挂能力。

首先能力向内求。

“预训练-微调“范式，已经很熟了，这套流程一直走到了大模型时代。将基础模型作为底座，通过SFT、DPO等模型微调，再加上RLHF、GRPO等强化学习方式，试图将领域知识“刻录“进模型的参数中。

图1，传统知识注入方式。

传统的预训练范式的问题也很明显：

• • 训练成本高且周期长。数据清洗，测试集构建，GPU资源等都是人力和资源的持续投入。“烧钱～”
• • 效果评测与泛化难题：模型的后训练可能带来，“灾难性遗忘”的问题，导致模型在垂类某些特定任务上相对有效，但在其他任务上却很容易失去泛化效果。
• • 基座迭代速度远超训练周期：还没等到训练好的旧模型上线，发现新一代开源模型轻松超越训练后的旧版模型，辛苦努力全白费，之前投入打水漂。

以上问题说明了，“向内”修改模型参数的路走不通，或者性价比太低。那自然开始转向“向外“寻求解决方案。

问题再次收敛：

如何在不改变模型权重的前提下，通过架构设计更高效地注入领域知识。

这正是Agent架构演化的逻辑起点，我们不得不在大模型外围构建层层叠叠的结构与工具，通过“工程化”的手段来辅助其完成知识的检索、上下文的组装以及记忆的维护。这也正是当前各类Agent架构百花齐放的最本质的原因。

我们不再执着于让模型“记住”所有知识，而是转而设计一套机制，让模型能够“找到”并“理解”所需的知识。

基于这一思路，Agent 架构的演化逐渐分化出了四条最主要的路径：

“Single Agent - Multi-Agent - Agent Skill - Agent Team"。

图2，Agent 架构演进路线。

2，Agent 架构的演进

2.1，Single Agent 单智能体

单智能体运行逻辑非常简单。

通过System Prompt的方式，将知识“无脑“地注入到大模型的上下文中，期望它基于注入的信息生成满意的答案。

比如，想基于一个文档的内容进行问答，就把这个文档丢给模型，同时进行提问。这种暴力注入，直觉上肯定不OK。

主要问题有两个：

长上下文的注意力缺失和上下文窗口长度限制。

• • 注意力缺失是指，“关键信息遗忘”的现象，当输入数据量达到一定阈值时，模型极易出现“Lost in the Middle"问题，导致其无法精准定位到所需的领域知识，最终输出的结果偏离预期。
• • 上下文窗口有的限制，并不一定装下所有的知识，并且长上下文并不等于长记忆。

为解决这两个主要问题，探索出了RAG。

即 ”在prompt中该放的放，不该放的不放"!

但是，“放与不放”这种能力的实现强依赖于前置的检索过程。

现在的检索能力与大模型的能力存在“失配”，这种”小模型前置辅助大模型”的模式，往往会导致关键信息的漏召或误召，成为制约 Agent 效果的瓶颈。

所以RAG 并不是一种最终的完美解决方案。

总结来说，单Agent优势和劣势非常明显：

• • 优势：最原生的架构、开发链路最短、运行效率极高，适合快速构建Demo或处理知识依赖较少的场景。
• • 劣势：极度依赖上下文窗口的质量与长度。一旦涉及大量领域知识的注入，极易引发上下文爆炸，导致模型注意力分散，稳定性大幅下降。

有单 Agent 必定会有多 Agent，最直接的想法是，将一个任务拆分成多个子任务，让不同的Agent 承接。

2.2，Multi-Agent 多智能体

多 Agent 就是如此，将复杂的宏观问题拆解为微观的子住务，由不同的Agent承接。

典型的多agent拆分方式包括：Planner（规划者）、Reasoner（推理者）、Executor（执行者）等角色。

此种架构设计带来了显著的优势：

• • 降低单体复杂度：将庞大的领域知识打散，进行领域隔离，避免了单个Agent 上下文爆炸的可能性。
• • 独立调优：针对性优化一个子Agent的提示词或工具链，而不影响其他模块，极大提升了维护的灵活性。

也带来了问题：

• • 路由准确率压力：主 Agent 需要在有限的上下文中，决定将任务分给那个 sub-Agent，如果分类不准，将会导致结果的南辕北辙。
• • “局部最优”导致的上下文割裂：这是Multi-Agent架构中最隐蔽也最致命的痛点。由于子Agent往往只关注自身任务的局部最优路径，缺乏对全局上下文和用户完整意图的感知，极易出现，相同子任务被重复执行，或者基于局部信息得出的结论，前后矛盾结论冲突的现象。

所以：

Multi-Agent架构虽然解决了知识隔离问题，却将复杂度转移到了Agent之间的通信带宽与协同上。

如果想要保证Agent效果，就需要投入巨大的人力成本去打磨每一个Agent节点、通信协议、设计精细的摘要策略，以及处理各种边界Case。

随着Agent数量增加，系统整体的稳定性保障难度呈非线性上升，而效果的提升却越来越依赖繁琐的人工干预。这是一个典型的边际效应递减过程。

引入Multi-Agent的初衷，本质上是为了解决领域知识的隔离与高效注入问题，但是却带来了复杂的上下文管理和通信机制。

如果有一种机制能在不牺牲上下文稳定性的前提下实现知识的动态加载，那么沉重的Mulit-Agenti间通信或许就不再是必须的选项。

2.3，Agent Skill 专业技能

面对multi-Agent 中复杂的通信损耗、路由误判以及高昂的维护成本，Agent skill 提出不再盲目堆砌 Multi-Agent 而是转向构建基于文件系统的可复用能力包。

Agent Skill 模式其实是回归到了Single Agent 的架构本体，但它有极强的动态扩展能力。

• • 能力封装复用：将复杂的领域知识、操作规范、最佳实践封装成独立的“Skills文件包”，使得这个能力可以在不同Agent中快速复用。
• • 按需调度：主Agent不再需要预加载所有知识，而是在运行过程中，根据当前任务需求，动态地“读取“并加载对应的Skills文件。
• • 渐进式披露 (Progressive Disclosure) ：这是Agent Skills模式的精髓。Agent 先通过目录概览定位所需技能，再逐步深入阅读具体步骤。如果在执行中发现缺少知识，它可以主动触发下一个Skills的加载来补全信息。

这种模式让单个Agent具备了“局部专业化”的能力。

它在宏观上保持统一的记忆和状态，微观上却能像调用工具一样灵活掌握成千上万种垂直领域的专业知识。

因此，Agent Skills 架构带来了显著的收益：

• • 低成本的知识注入：真正实现了将海量领域知识“说明书化”，模型按需阅读，无需全量预加载，比Multi-Agent更轻量，而且也比RAG精准。
• • 全局上下文一致性：由于始终由同一个主Agent来执行，它完整知晓已执行的步骤、已读取的Agent Skills以及当前的任务状态，彻底消除了Multi-Agent中的信息割裂和重复劳动问题。
• • 规避Context爆炸：通过“读一点、做一点、再读一点”的流式处理，有效控制了瞬时上下文长度

从Multi-Agent的“分而治之”到 Agent Skills 的“聚而用之”，是一种Agent回归本质的、更加优雅的工程演进。

它用文件系统的结构化能力替代了复杂的网络通信协议，用渐进式的信息披露替代了暴力的全量注入。

2.4，Agent team

Agent Team 是一种面向复杂未知问题的多智能体协作范式。

核心是：

放弃固定流程与预设路径，通过一组智能体并行协作、多元探索，解决传统方案难以处理的 “无明确路线图” 问题。

主要解决：

• • 问题本身无固定解法、无标准流程的复杂任务
• • 单智能体能力、串行执行逻辑无法覆盖的高不确定性场景
• • 多因素交织、信息不完备、需要试错与发散探索的难题

Agent Teams其实代表了一种新的工程哲学：

在未知面前，并行的多样性优于串行的确定性。

Agent Teams也不是完全都是走并行运行的，主Agent会根据任务要求会进行分解，从而判断哪些子任务需要并行，哪些子任务是有前后串行依赖关系的，这种并行化的探索以及上下文的共享机制的确带来了不一样的质变。

Agent Team 主要的核心逻辑和上文中Multi-Agent架构里的 ”独立(Independent)“ 或者 ”去中心化(Decentralized)“ 比较像，但又不完全一样。

核心差异是：

Agent Team 目标是解决复杂未知问题，而非单纯提升并发或分布式执行效率。

Agent Team 虽然避免了串行等待的时间损耗，但并行也意味着算力成本的成倍增加。同时，如何设计高效的“共享Task List"机制，让多个Agent在读写共享状态时不产生冲突、不陷入死循环，也是落地的一个关键难点。

3， 架构选择建议

Agent架构的演化遵循“从简单到复杂、从单一到多元、从固定到灵活”的核心思路。不同的场景需要按需抉择，可以参考奥卡姆剃刀原则，“如无必要，勿增实体”！

• • Single Agent 适配简单明确任务，追求低成本高效；
• • Multi-Agent 突破单智能体能力上限，代价是协同复杂；
• • Agent Skills 平衡稳定性与维护成本，适配企业级常规需求；
• • Agent Team 聚焦复杂未知场景，以并行多样性探索突破任务边界。

相信通过以上四种Agent 的介绍，大家心里都有一个初步架构选型判断。

从工程化角度，先快速的实现一个Agent的原型，再逐步的迭代，直到实现项目目标，即为最优架构的选择。没有必要开始就上“难度”，徒增烦恼。

选型的核心逻辑是：

匹配需求复杂度与成本预期

无需追求“高大上”，贴合自身任务边界、成本预算及稳定性要求，选择最适配的形态，才是Agent架构落地的最优路径。

参考： arXiv: 2512.08296 Blog: 阿里《Agent/Skills/Teams 架构演进过程及技术选型之道》