【万字长文】深入解析AI Agent：架构、核心挑战与可扩展性全面探讨！-优快云博客

一、 What is agent？

目前 Agent 的定义比较模糊，甚至是混乱，有些人认为只有完全自主决策跟外部可以交互的系统才叫 Agent，有的人认为只要用了 llm 的功能/系统就叫 Agent，甚至有些人把传统的功能模块套个壳也拿来叫 Agent。

Openai 比较前沿，他们认为Agent就是那些能力独立完成任务的系统。

Anthropic 在《building effective agents》中搁置了 Agent 概念的争议，转而提出来“agentic system”的概念，用来统称完全自主的系统（包含使用工具完成复杂任务）及预定义的工作流。

在我看来，一定是在特定范围中包含足够自主可控能力的才能叫 Agent，否则也没有什么意义，当然这无关技术实现，只要在一定范围内自己能够思考决策以及与外界交互那便可以叫做 agent。

业界目前更靠谱更技术性的定义为 Agentic System。着重于系统，加上部分 agentic 的能力。这可能既包括 workflow 又包括 agent，以及二者之间的东西。它强调的应该是一定程度的智能，使用工具与外部环境交互，并可迭代直到达到结果/条件。以下不再严格区分 Agent/agentic 系统。

二、如何实现一个 agent

首先我们很自然的想到使用市面上的各种框架来支持我们，但当我们打开搜索引擎/AI 助手，映入我们眼帘的是各种五花八门的 agent 构建框架，它们经常会搞得眼花缭乱。但是从本质上来说目前主流的 agent 框架主要分两种模式：

• 1. role based agent abstract
比较直观；典型代表：CrewAI，MetaGPT
• 2. DAG/DG/ED based的架构，以下统称为类workflow架构通过声明式或者命令式编排的方式; 典型代表：LangGraph，BabyAGI

虽然可以将workflow和agent都划归agentic 系统，但从技术实现架构上来说他们又有明显的区别，这也是目前来说业会分化两种主流方式的原因之一。

Role based 架构

基于 role 的 agent 抽象的实现方式从使用的角度会更加的直观且可以和现实世界类比，通过给用户一个可以输入部分提示词的入口，整个过程自主控制系统提示词。其核心交互流程如下:

但是对于agent 执行过程中的上下文管理极其困难。这主要表现为，因为agent 完全自主运行，在系统执行的过程中如何保证每一步给模型输入恰当合适的提示词很难。

• 优点：灵活、自主性高、鲁棒性较强
• 缺点：性能效果很可能在某些场景下不够乐观

类 Workflow 架构

workflow的实现方式核心是通过抽象各种细粒度的组件，并通过图模型或者事件模型的机制来进行数据流动。

• 优点：职责清晰、一致性较强、可靠性（可预测性）、可控性更强
• 缺点：往往需要做小范围的定制

综合对比来说，目前来说两种方式各有利弊，其中最核心的区别主要在于可靠性及可控性。而这两者并不是可以兼得的，它们之间存在负相关的关系。

一直在更新，更多的大模型学习和面试资料已经上传带到优快云的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

在这里插入图片描述

实践中最优选择是workflow+抽象agent的结合体，也即小范围自主大范围编排，特定领域workflow通用自由度高领域agent，在可控性和自主性之间做一个 tradeoff。

总结

自主性与可靠性兼得

从上面的分析，我们可以得知构建一个agent很容易（无论使用框架还是自研），但是要一个可靠、性能达标的agent却很难，从 60 分到 90 分是比 0-60 更巨大的一步。

以下情况都会导致 Agent性能不佳：

• 1. 不完整或简短的系统消息
• 2. 用户输入模糊
• 3. 无法正确选择工具使用
• 4. 工具描述不佳
• 5. 上下文信息缺失或错误
• 6. 架构不适

上面我们说到要在自主性和可控性之间做一个权衡，其实如果要鱼与熊掌兼得话横亘在这里的唯一难点，就是如何确保 LLM 在每个步骤都有适当的上下文。这包括控制进入 LLM 的确切内容，以及运行适当的步骤来生成相关内容。

三、探究自主性

首先我们来看自主性是什么？

自主性 = 感知能力 + 决策能力 + 执行能力 + 学习能力

具体而言自主性是实时动态能力的涌现，这体现在上面四个要素动态的协同互动，不断递进，产生了类似生命的"自主性"特征。通俗来说就是基于模型对任务的理解，自己拆解，设计流程，并逐步完成，且不断迭代过程。

AI Agent 带来的自主性给我们的软件编程范式带来了巨大改变。从传统编程命令式到声明式再到如今 Agentic 决策再到动态能力扩展，不得不说我们的变成习惯和思维需要做出适应 Agent 时代的改变。

传统的软件需要我们特定的编码 if else 来处理现实世界中各种复杂的场景（需要预编写成各种业务代码），这种情况对程序员的需求和要求是巨大的。

各种 dag/dg/ed 框架或者低代码平台诞生之后，我们开始能够使用声明式的方式来动态控制我们的程序（各种模块），这对于我们的扩展性带来了部分的便利。

llm 给我们带来的是，可以在程序运行的过程中自己来思考如何编排或者协调我们定义的各种模块，这主要包括自主流程拆解，动态模块决策，实时决策调整，动态外部交互。

更进一步，如果有一个模块/功能我们的程序中尚未定义我们应该如何处理？答案是 llm 写程序，也就是在数字世界中动态创造我们的现实世界。这使得我们真正进入了元编程时代，也是 AI 在数字编程世界创造性的来源。

上面的 1 到 4 是一个递进的过程，AI agent的自主性演进代表了软件开发范式的根本性转变, 这个过程软件正变得不断自主可控。这其中支持这一切的主要是不断智能的模型，自我学习的增强，记忆和上下文理解的增强。

从"预定义一切"到"按需创造一切"，这种转变不仅改变了我们构建软件的方式，更重要的是重新定义了人与计算机的关系——从人指挥机器执行，到人与智能体协作解决问题。

塑造可控性
=========

前面我们已经介绍过自主性的本质，核心是要让整个系统拥有完全的自主决策能力（何时何地应该根据外界情况做什么），要实现这个目标会面临诸多的挑战，其中最主要的一点便来自于自主性与可控性的权衡困境。

自主性要求我们不得不强依赖于模型的决策，但我们都知道无论多么牛逼的模型都不可避免的会有失控的可能。这主要是因为一个 agentic 系统在运行的过程中尤其长时间运行的过程中，不可避免地外部环境变得复杂，内部状态变得越来越复杂，信息变多干扰噪点变多。种种原因会迫使我们的 Agentic 系统可能会不达预期。

另一方面，现实世界里，尤其一些 ToB 的场景里，我们对错误或者失控容忍度是极低的，并且大多时候我们甚至希望系统的每一个决策都能解释。

总之我们希望系统的高自主性也希望强可控性，沿着我们预期的路径自我发展。但事情总不可能是完美的，不可能既要又要，也即从目前的现状来说自主性与可控性还是不可调和的，我们只能在种种基础之上做一个平衡。

首先，我们来看一个 Agentic 系统失控的原因，这可能是多种多样的，小到注意力的不集中，上下文的污染；大到架构的不合理，模型推理失衡都会导致该问题的发生。归纳起来解决方法核心有两点，一是合理的架构适配，二是模型上下文/记忆的控制。做好这两点在可预测性方面基本上就能达到一个很好的目标。

模式

一个 agentic 系统的架构及模式对性能的影响是不言而喻的，目前业界流行的几种 agent 运行/设计模式。

ReAct 模式：

ReAct 模式的核心是增加了Observation，一种“碎碎念”的机制，让模型维持短期记忆，始终铭记当前的目标。

反思：通过自我评估进行改进。

反思的根本是为了避免模型跑偏，以便能够及时拉回目标。

工具：通过工具扩展能力

规划：先规划再处理。

这种模式会先思考想好自己的计划，然后逐步完成，相当于开始时候就给自己制定好需要完成的子目标，然后一个接一个开始干活。

无论采用哪一种模式，其本质都是为了为了给模型制造一种目标导向性，这个目标会一步一步不断牵引系统去完成。所以一个合理的 Agentic 系统的架构一定是目标导向型的，也即面向任务驱动的系统。

结构化/清晰化

我们都知道提示词是一个 Agent 应用核心中的核心，决定了我们系统的上限，如何设计提示词这里不多赘述，我们可以简单把提示词分成变得和不变的两部分，这里重点关注随着系统状态不断变化的部分应该如何设计。随系统变化的部分目前更流行的叫法为上下文，它是随 Agent 状态变更动态变化的部分。要始终维持一个良好的上下文，有 3 点需要密切关注：

• 1. 信息量合适，不过多不过少。
• 2. 内容清晰，结构分明
• 3. 始终明确目标，注意力集中

目前一些上下文工程上的一些实践主要包括：Agentic Rag，隔离，修剪，压缩。

分层记忆

通常的做法是利用LLM自身的能力，构建一个AI原生的、分层的、个性化的记忆系统。之所以要可能主要受限于两方面的瓶颈：

• 1. 模型窗口，成本和大小和精度控制
• 2. 信息组织方式

方案

总之，要实现一个高可靠高自主的 Agent 系统不是一件简单的事情，也不是一件一蹴而就的事情，需要我们投入精力持续精细化优化。核心就是在自主性中挖掘可控性/固定性的东西，加以控制，这其实就是上下文工程的本质，由此我们就可以获得性能的极限。

workflow + agentic 抽象

• 1. 切记人类不停的深入挖掘流程。交由模型，副作用：可能模型自己会尝试到多种解决方案
• 2. 规划机制+检查机制，记好 todo list（这应该是范式）
• 3. 硬规则也必不可少（防止）
• 4. 动态提升模型的知识/经验。

再次总结如下

• ● 架构上设计一个面向任务的Agent核心抽象也即任务是整个系统的一等公民，整个系统的驱动，流转都是以任务为介质。
• ● 结构化提示词，这是我们去做上下文工程和 prompt 演化的关键
• ● 分层记忆机制Todo List驱动的执行范式这个是已经被证明目前来说非常有用的实践。
• ● 多层规划机制与检查机制的实现多层的好处是可以逐层扩散，解耦。
• ● 动态知识/经验提升系统打造整个 agentic 的回路，自我学习纠正演化。

可扩展性
========

AI Agent 的可扩展性是一个综合性的系统设计目标。探究可扩展性本身就是一个复杂的课题，这里我们从以下几方面来考虑：

• 1. 能力的可扩展，具体主要包括工具的扩展性，知识的扩展性，模型的扩展性，及如何引入新的功能能力。
• 2. 结构的扩展性，这可能包括与已有 Agent/数据系统/业务系统的协作和集成，这种结构上或者叫边界上的 scale 也是重中之重。
• 3. 另外还包括性能或者叫规模的可扩展，如何水平扩展，均衡调度 Agent，尤其长任务 Agent 的执行更是关注的重点。

能力可扩展

上面的图标识了一个典型的生产级 Agentic System 所包含的基本组件/模块。这主要包含两部分：

• 1. 运行的基本组成要素
• 2. 观测的基本组成要素

我们也将基于这两部分设计一个完整可运行可观测的 Agentic 系统，要实现这个目标几个关键因素需要考虑：

框架的选择或者如果自研应该构建一个怎样的 Agent 框架或平台，我认为应该一样遵循软件设计的原则，首先框架是否可扩展（我们不应该只关注功能是否齐全，而首要的应该关注功能扩展是否友好，这对于日新月异的 Agent 技术发展来说尤为重要。），框架的可扩展性包含以下几方面：

a.  模块性，插件化，可以自由组合，按需加载。-可重用的标准化组件，也即每一部分都可以单独使用，而不是llm+tools+memory+context的打包。-模板化逻辑、对话流、集成适配器-组件的编排，无缝协调 agents、tools、和 memory 的逻辑层-无状态化，实现高效的水平扩展和方便的调试-可能涉及到的功能模块推理、规划、记忆管理，编排，管理模型的动态切换以及 fallbackb.合理的抽象层次划分，目前主流的Agent编排框架一般分为三层，第一层为模型的wrapper及adapter，第二层抽象为即用即建，用完销毁的program/node，第三层agent，面向角色的设计泛式/编排层c.模块/组件的深度，即应该仔细审视框架中的每一个功能模块，确保不是一些 demo 性质的。比如记忆模块需要综合语义、场景和长期记忆，实现丰富的上下文感知交互，或者允许我们深度定制。

工具/模型的集成，目前主流的框架对扩展工具/模型已经比较友好，尤其 MCP 的发展，已经构建起来足够繁荣的 Agent 工具生态，并且支持几乎市面上所有的模型，尤其很多模型厂商都会主动兼容 Openai/Anthropic 的协议，使这一部分并不复杂。但是我们需要关注的是我们的框架能否构建一个多种形态的工具调用模式，例如：Pipeline 模式（即 action 序列），Parallel 模式，Loop 模式（这种情况下，需要关注/等待外部信号的输入）
灵活持久性的记忆模块也是 Agentic 系统极为重要的一部分，记忆是持续学习的基础，通常来说业界将 Agent 记忆分成两部分：短期记忆（STM）：用于单个任务或会话期间。能保留临时的背景信息，例如近期的查询或用户操作。长期记忆（LTM）：存储历史性的见解——决策、偏好、事实——涵盖多个会话。这两部分分别有不同的技术进行支持。要构建这样一个完整记忆系统，一个完整的数据系统必不可少，数据可能包含 Agent 的 rollout，业务结果等。

一些可供探索的记忆解决方案：

• Zep：具有衰减功能的向量存储器，配有滤波器和带有时间戳的元数据。
• MemGPT：能够动态管理上下文窗口，并拥有可扩展的存储功能。
• Letta：支持实时学习和持久存储，适用于长时间运行的任务。

没有记忆， Agent 会忘记一切。有了记忆，它们能够适应并进化。

可扩展的 Agent 模式。目前主流生产化的模式主要有以下几种：

• 1）reflection模式：生成→评估，强调评估的作用。
• 2）ReAct模式：思考->执行，强调思考和执行的迭代进行。
• 3）Planner模式：先规划->执行，强调任务的统筹和拆解。
• 4）另外还有一些handoff等等模式。

要选择哪种没有固定的模式，并且这里的扩展性是必须的。我觉着是如何把 agent 开发的范式做到极致。

综上，我认为一个可扩展的 Agent 不仅仅只是能做出响应——它应当会思考、规划、执行和调整。并且这其中每步一步都应该是可适应插件化的，推理能力，记忆能力，工具能力，反馈能力，续写能力。

结构可扩展

结构的扩展性主要包括多 Agent 架构的扩展，及与已有系统的集成。

多 Agent 协作的架构模式

如图所示，目前主流的 Agent 协作模式主要有：

• 1：网络，对等都可以挂工具，相互之间可以通信，每个 Agent 都可以自主决策，容错性较高。
• 2：supervisor，agent之间不能独立通信，需要通过supervisor下发任务。典型框架：AutoGpt，LangGraph
• 3：supervisor as tools，调用方式跟单agent差不多，只是模块化增强。
• 4：多级多层次，一般会用在极其复杂的场景，主要体现了多层抽象/分治的思想。典型框架：基于 A2A 实现的系统
• 5: 自定义，适用于完全精细化自主控制的场景。

如何选择需要根据我们的场景和要求进行选择，我们需要业务流程的梳理，这是重中之重，分解任务，根据资源管理的要求，决策的要求，容错性的要求，及复杂性要求选型逻辑

另外我想澄清，现实世界复杂多样，多 agent 的架构一定是必须的，这必将不会存在争议。参考人类社会，协作方式的多种多样，问题的多样，分工的多样，投影到软件世界/Agent 世界，不会有本质的区别。

Agent 协作的通信协议A2A

A2A （Agent-to-Agent）专注于不同智能体之间的通信、任务分配和协作管理，允许它们将子任务委派给其他更专业的智能体。

A2A协议的设计遵循了几项关键原则：

● 基于现有标准：它建立在成熟的Web标准之上，例如使用HTTP/HTTPS作为传输层，采用JSON-RPC 2.0来封装消息体，并支持Server-Sent Events (SSE) 进行流式传输。

● 智能体优先：它专注于智能体之间的协作，允许它们以自然、非结构化的方式交换信息和任务，而不仅仅是将智能体视为简单的“工具”。

● 完善的安全机制：设计时考虑了企业级身份验证和授权，支持OAuth、JWT等认证方案，确保通信安全可信。

● long running 任务的支持：协议具有足够的灵活性，能够管理从快速查询到需要数小时甚至数天才能完成的长时间运行任务，并提供实时反馈和状态更新。

● 多模态支持：支持包括文本、音频、视频流在内的多种数据模式交换。

运作流程

一个典型的A2A交互流程包括几个阶段：

服务发现与认证：智能体首先通过“Agent Card”（一种结构化摘要，描述智能体的能力）发现彼此，并通过身份验证。
任务初始化：用户请求任务，一个客户端智能体（用户代理）将任务打包并分配唯一的任务ID。
任务处理：客户端智能体将任务委托给远程智能体（服务器代理），并通过任务ID跟踪状态。
任务完成：远程智能体处理任务并返回结果，支持同步或非同步模式。

通过A2A协议，AI智能体生态系统有望实现更高效、更强大的跨平台协作，推动AI应用从孤立的工具向集成、智能的协作系统发展。

与外部系统集成

在多 Agent 架构的基础上，进一步而言，将 Agent 系统与现有业务系统和数据系统有效集成是实现企业级应用的关键，Agent 连接到他们需要的工具和数据从根本上来说是一个分布式系统问题。做好与企业 CRM/数据系统chat、IVR、CRM及其它企业工具等无缝集成才是目前企业内 Agent 能够落地的根本。但显而易见当下与企业中现有系统集成存在着巨大挑战。这主要体现在以下几方面：

● 接口差异

• ○ REST API vs GraphQL vs gRPC：不同系统采用不同的通信协议
• ○ SOAP vs REST：遗留系统可能使用 SOAP，而新系统使用 REST
• ○ 自定义协议：部分企业系统使用专有通信协议

● 数据多样性/异构性

• ○ JSON vs XML vs CSV：不同系统使用不同的数据序列化格式
• ○ 字段命名不一致：同一业务概念在不同系统中使用不同的字段名（如 customer_id vs clientId vs 客户编号）
• ○ 数据类型映射：不同系统对相同数据类型的表示方式不同

● 业务逻辑差异

• ○ 业务流程不统一：同一业务在不同系统中的处理流程可能不同
• ○ 状态机差异：不同系统对业务状态的定义和转换规则不同
• ○ 验证规则差异：数据验证和业务规则在不同系统中不一致

企业内部存在众多业务系统，这些系统的接口、协议和数据格式差异显著，导致集成复杂度呈指数级增长，开发/维护/集成的成本都是巨大的。

此外 Agent 作为一种当前流行的支持业务的模式，也存在着自身特殊的挑战，比如实时协作需求引发的分布式状态同步问题，即 Agent 一般需要等待/同步外部系统的状态已进行下一步的决策。

要充分解决以上问题核心是我们需要做两件事

• 1. 构建统一的外部系统连接层/适配层；
• 2. 使用现代化松耦合可扩展的系统架构；

统一适配层能带来多方面的优势，比如风险隔离，统一治理（比如数据质量，安全合规，可观测方面），快速迭代（大部分情况只需要修改统一层），最重要的是带来较好的扩展性，可以平滑添加新工具和系统接入。

● 协议适配

• ○ 统一的内部接口（如统一的 REST API）
• ○ 到各种外部协议的适配（REST、SOAP、gRPC、自定义协议）
• ○ 协议转换和映射

● 数据转换

• ○ 数据格式转换（JSON、XML、CSV、二进制）
• ○ 数据模型映射（统一的数据模型）
• ○ 字段名称映射和转换

● 安全统一

• ○ 统一的认证接口（内部使用统一 Token）
• ○ 到各种外部认证系统的适配
• ○ 权限的集中管理和转换

● 统一连接管理

• ○ 连接池管理
• ○ 超时和重试机制
• ○ 熔断和降级策略

技术发展到目前，在分布式场景下，微服务架构仍旧是目前主流的选择，在 Agent 系统中我们仍旧可以使用微服务架构，与微服务一样，Agent 必须高效通信并确保其输出在更广泛的系统中有用。与任何服务一样，它们的输出不应该只是循环回 AI 应用程序，还应该流入其他关键系统，如数据仓库、CRM、CDP 和客户成功平台。

另外一种新的选择是我们可以通过事件驱动架构进行松散耦合。它允许 Agent共享信息、实时行动并与更广泛的生态系统集成的支柱，而无需担心紧密耦合的麻烦。EDA 不是紧密耦合的同步通信，而是使组件能够通过事件进行异步通信。服务不会相互等待，而是对正在发生的事情做出实时反应。这种方法使系统更具弹性和适应性，使它们能够处理现代工作流程的复杂性。这种架构的主要优势在于：

非常好的扩展性

• ● 低延迟，快速驱动业务流程
• ● 松散耦合，不依赖于直接通信
• ● 事件持久性，容易回溯，对于可靠性要求高的流程至关重要

此外无论使用哪种架构我们都还必须考虑agent 的特殊性，这主要是在分布式环境下供给推理、决策、和协作的上下文信息共享问题。这使得构建代理时对如何管理依赖关系和确保实时数据流产生了独特的需求。EDA 消除了这些限制。通过解耦工作流程并启用异步通信，EDA 允许系统的不同部分（代理、数据源、工具和应用程序层）独立运行。

微服务架构下通过共享存储，交互协议等来解决这些问题。EDA 则通过充当数据的“中枢神经系统”来解决这一挑战。它允许代理异步广播事件，确保信息动态流动而不会产生严格的依赖关系。这种解耦使代理能够自主作，同时无缝集成到更广泛的工作流程和系统中。两种方法都能做到解耦的同时保证上下文完整。上下文的完整、正确、简洁极其重要。

四、如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

一直在更新，更多的大模型学习和面试资料已经上传带到优快云的官方了，有需要的朋友可以扫描下方二维码免费领取【保证100%免费】👇👇

在这里插入图片描述