1.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 系统。2.如何实现一个 agent首先我们很自然的想到使用市面上的各种框架来支持我们但当我们打开搜索引擎/AI 助手映入我们眼帘的是各种五花八门的 agent 构建框架它们经常会搞得眼花缭乱。但是从本质上来说目前主流的 agent 框架主要分两种模式• 1. role based agent abstract比较直观 典型代表CrewAIMetaGPT• 2. DAG/DG/ED based的架构以下统称为类workflow架构 通过声明式或者命令式编排的方式; 典型代表LangGraphBabyAGI虽然可以将workflow和agent都划归agentic 系统但从技术实现架构上来说他们又有明显的区别这也是目前来说业会分化两种主流方式的原因之一。Role based 架构基于 role 的 agent 抽象的实现方式从使用的角度会更加的直观且可以和现实世界类比通过给用户一个可以输入部分提示词的入口整个过程自主控制系统提示词。其核心交互流程如下:但是对于agent 执行过程中的上下文管理极其困难。这主要表现为因为agent 完全自主运行在系统执行的过程中如何保证每一步给模型输入恰当合适的提示词很难。• 优点灵活、自主性高、鲁棒性较强• 缺点性能效果很可能在某些场景下不够乐观类 Workflow 架构workflow的实现方式核心是通过抽象各种细粒度的组件并通过图模型或者事件模型的机制来进行数据流动。• 优点职责清晰、一致性较强、可靠性可预测性、可控性更强• 缺点往往需要做小范围的定制综合对比来说目前来说两种方式各有利弊其中最核心的区别主要在于可靠性及可控性。而这两者并不是可以兼得的它们之间存在负相关的关系。实践中最优选择是workflow抽象agent的结合体也即小范围自主大范围编排特定领域workflow通用自由度高领域agent在可控性和自主性之间做一个 tradeoff。总结自主性与可靠性兼得从上面的分析我们可以得知构建一个agent很容易无论使用框架还是自研但是要一个可靠、性能达标的agent却很难从 60 分到 90 分是比 0-60 更巨大的一步。以下情况都会导致 Agent性能不佳• 1. 不完整或简短的系统消息• 2. 用户输入模糊• 3. 无法正确选择工具使用• 4. 工具描述不佳• 5. 上下文信息缺失或错误• 6. 架构不适上面我们说到要在自主性和可控性之间做一个权衡其实如果要鱼与熊掌兼得话横亘在这里的唯一难点就是如何确保 LLM 在每个步骤都有适当的上下文。这包括控制进入 LLM 的确切内容以及运行适当的步骤来生成相关内容。3.探究自主性首先我们来看自主性是什么自主性 感知能力 决策能力 执行能力 学习能力具体而言自主性是实时动态能力的涌现这体现在上面四个要素动态的协同互动不断递进产生了类似生命的自主性特征。通俗来说就是基于模型对任务的理解自己拆解设计流程并逐步完成且不断迭代过程。AI Agent 带来的自主性给我们的软件编程范式带来了巨大改变。 从传统编程命令式到声明式再到如今 Agentic 决策再到动态能力扩展不得不说我们的变成习惯和思维需要做出适应 Agent 时代的改变。传统的软件需要我们特定的编码 if else 来处理现实世界中各种复杂的场景需要预编写成各种业务代码这种情况对程序员的需求和要求是巨大的。各种 dag/dg/ed 框架或者低代码平台诞生之后我们开始能够使用声明式的方式来动态控制我们的程序各种模块这对于我们的扩展性带来了部分的便利。llm 给我们带来的是可以在程序运行的过程中自己来思考如何编排或者协调我们定义的各种模块这主要包括自主流程拆解动态模块决策实时决策调整动态外部交互。更进一步如果有一个模块/功能我们的程序中尚未定义我们应该如何处理答案是 llm 写程序也就是在数字世界中动态创造我们的现实世界。这使得我们真正进入了元编程时代也是 AI 在数字编程世界创造性的来源。上面的 1 到 4 是一个递进的过程AI agent的自主性演进代表了软件开发范式的根本性转变, 这个过程 软件正变得不断自主可控。这其中支持这一切的主要是不断智能的模型自我学习的增强记忆和上下文理解的增强。从预定义一切到按需创造一切这种转变不仅改变了我们构建软件的方式更重要的是重新定义了人与计算机的关系——从人指挥机器执行到人与智能体协作解决问题。4.塑造可控性前面我们已经介绍过自主性的本质核心是要让整个系统拥有完全的自主决策能力何时何地应该根据外界情况做什么要实现这个目标会面临诸多的挑战其中最主要的一点便来自于自主性与可控性的权衡困境。自主性要求我们不得不强依赖于模型的决策但我们都知道无论多么牛逼的模型都不可避免的会有失控的可能。这主要是因为一个 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 的回路自我学习纠正演化。5.可扩展性AI Agent 的可扩展性是一个综合性的系统设计目标。探究可扩展性本身就是一个复杂的课题这里我们从以下几方面来考虑• 1. 能力的可扩展具体主要包括工具的扩展性知识的扩展性模型的扩展性及如何引入新的功能能力。• 2. 结构的扩展性这可能包括与已有 Agent/数据系统/业务系统的协作和集成这种结构上或者叫边界上的 scale 也是重中之重。• 3. 另外还包括性能或者叫规模的可扩展如何水平扩展均衡调度 Agent尤其长任务 Agent 的执行更是关注的重点。能力可扩展上面的图标识了一个典型的 生产级 Agentic System 所包含的基本组件/模块。这主要包含两部分• 1. 运行的基本组成要素• 2. 观测的基本组成要素我们也将基于这两部分设计一个完整可运行可观测的 Agentic 系统要实现这个目标几个关键因素需要考虑框架的选择或者如果自研应该构建一个怎样的 Agent 框架或平台我认为应该一样遵循软件设计的原则首先框架是否可扩展我们不应该只关注功能是否齐全而首要的应该关注功能扩展是否友好这对于日新月异的 Agent 技术发展来说尤为重要。框架的可扩展性包含以下几方面a. 模块性插件化可以自由组合按需加载。-可重用的标准化组件也即每一部分都可以单独使用而不是llmtoolsmemorycontext的打包。-模板化逻辑、对话流、集成适配器-组件的编排无缝协调 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 模式。目前主流生产化的模式主要有以下几种• 1reflection模式生成→评估强调评估的作用。• 2ReAct模式思考-执行强调思考和执行的迭代进行。• 3Planner模式先规划-执行强调任务的统筹和拆解。• 4另外还有一些handoff等等模式。要选择哪种没有固定的模式并且这里的扩展性是必须的。我觉着是如何把 agent 开发的范式做到极致。综上我认为一个可扩展的 Agent 不仅仅只是能做出响应——它应当会思考、规划、执行和调整。并且这其中每步一步都应该是可适应插件化的推理能力记忆能力工具能力反馈能力续写能力。结构可扩展结构的扩展性主要包括多 Agent 架构的扩展及与已有系统的集成。多 Agent 协作的架构模式如图所示目前主流的 Agent 协作模式主要有• 1网络对等都可以挂工具相互之间可以通信每个 Agent 都可以自主决策容错性较高。• 2supervisoragent之间不能独立通信需要通过supervisor下发任务。典型框架AutoGptLangGraph• 3supervisor as tools调用方式跟单agent差不多只是模块化增强。• 4多级多层次一般会用在极其复杂的场景主要体现了多层抽象/分治的思想。典型框架基于 A2A 实现的系统• 5: 自定义适用于完全精细化自主控制的场景。如何选择需要根据我们的场景和要求进行选择 我们需要业务流程的梳理这是重中之重分解任务根据资源管理的要求决策的要求容错性的要求及复杂性要求选型逻辑另外我想澄清现实世界复杂多样多 agent 的架构一定是必须的这必将不会存在争议。参考人类社会协作方式的多种多样问题的多样分工的多样投影到软件世界/Agent 世界不会有本质的区别。Agent 协作的通信协议A2AA2A 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 则通过充当数据的“中枢神经系统”来解决这一挑战。它允许代理异步广播事件确保信息动态流动而不会产生严格的依赖关系。这种解耦使代理能够自主作同时无缝集成到更广泛的工作流程和系统中。两种方法都能做到解耦的同时保证上下文完整。上下文的完整、正确、简洁极其重要。大规模 Agent 带来的其它挑战1通信前面我们已经介绍过 A2AMCP 等内容但当大规模 Agent 到来时这仍旧是不够的不仅仅涉及到 Agent 跟 Agent 之间Agent 和工具之间。现实情况远比我们预想的要复杂比如可能还包括 Agent 和 网关之间 Agent 和 各种场景下的 UI流式的异步的长时间执行的。这里一个是涉及到效率一个是涉及到交互。2 容错与故障容忍当我们面对越来越多的 Agent状态的持久checkpoint容错故障容忍各种问题都会摆到我们眼前。3Agent 的集中管理观测问题是否需要中心化管理注册、发现、删除。负载均衡。调度。重试。切换。scale。等扩展到数百个 agent 可能会带来的一些问题。如何设计合理的观测指标跟传统微服务的区别除了关注性能、健康、结果外还应该关注哪些。agent 的长链路long time可能会给 trace 带来的问题。最后为什么要学AI大模型当下⼈⼯智能市场迎来了爆发期并逐渐进⼊以⼈⼯通⽤智能AGI为主导的新时代。企业纷纷官宣“ AI ”战略为新兴技术⼈才创造丰富的就业机会⼈才缺⼝将达 400 万DeepSeek问世以来生成式AI和大模型技术爆发式增长让很多岗位重新成了炙手可热的新星岗位薪资远超很多后端岗位在程序员中稳居前列。与此同时AI与各行各业深度融合飞速发展成为炙手可热的新风口企业非常需要了解AI、懂AI、会用AI的员工纷纷开出高薪招聘AI大模型相关岗位。最近很多程序员朋友都已经学习或者准备学习 AI 大模型后台也经常会有小伙伴咨询学习路线和学习资料我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频全系列的学习资料这些学习资料不仅深入浅出而且非常实用让大家系统而高效地掌握AI大模型的各个知识点。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】AI大模型系统学习路线在面对AI大模型开发领域的复杂与深入精准学习显得尤为重要。一份系统的技术路线图不仅能够帮助开发者清晰地了解从入门到精通所需掌握的知识点还能提供一条高效、有序的学习路径。但知道是一回事做又是另一回事初学者最常遇到的问题主要是理论知识缺乏、资源和工具的限制、模型理解和调试的复杂性在这基础上找到高质量的学习资源不浪费时间、不走弯路又是重中之重。AI大模型入门到实战的视频教程项目包看视频学习是一种高效、直观、灵活且富有吸引力的学习方式可以更直观地展示过程能有效提升学习兴趣和理解力是现在获取知识的重要途径光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。海量AI大模型必读的经典书籍PDF阅读AI大模型经典书籍可以帮助读者提高技术水平开拓视野掌握核心技术提高解决问题的能力同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说阅读经典书籍是非常有必要的。600AI大模型报告实时更新这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。AI大模型面试真题答案解析我们学习AI大模型必然是想找到高薪的工作下面这些面试题都是总结当前最新、最热、最高频的面试题并且每道题都有详细的答案面试前刷完这套面试题资料小小offer不在话下这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】 大模型时代的Agent开发：从概念到实践的完整指南，建议收藏学习
1.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 系统。2.如何实现一个 agent首先我们很自然的想到使用市面上的各种框架来支持我们但当我们打开搜索引擎/AI 助手映入我们眼帘的是各种五花八门的 agent 构建框架它们经常会搞得眼花缭乱。但是从本质上来说目前主流的 agent 框架主要分两种模式• 1. role based agent abstract比较直观 典型代表CrewAIMetaGPT• 2. DAG/DG/ED based的架构以下统称为类workflow架构 通过声明式或者命令式编排的方式; 典型代表LangGraphBabyAGI虽然可以将workflow和agent都划归agentic 系统但从技术实现架构上来说他们又有明显的区别这也是目前来说业会分化两种主流方式的原因之一。Role based 架构基于 role 的 agent 抽象的实现方式从使用的角度会更加的直观且可以和现实世界类比通过给用户一个可以输入部分提示词的入口整个过程自主控制系统提示词。其核心交互流程如下:但是对于agent 执行过程中的上下文管理极其困难。这主要表现为因为agent 完全自主运行在系统执行的过程中如何保证每一步给模型输入恰当合适的提示词很难。• 优点灵活、自主性高、鲁棒性较强• 缺点性能效果很可能在某些场景下不够乐观类 Workflow 架构workflow的实现方式核心是通过抽象各种细粒度的组件并通过图模型或者事件模型的机制来进行数据流动。• 优点职责清晰、一致性较强、可靠性可预测性、可控性更强• 缺点往往需要做小范围的定制综合对比来说目前来说两种方式各有利弊其中最核心的区别主要在于可靠性及可控性。而这两者并不是可以兼得的它们之间存在负相关的关系。实践中最优选择是workflow抽象agent的结合体也即小范围自主大范围编排特定领域workflow通用自由度高领域agent在可控性和自主性之间做一个 tradeoff。总结自主性与可靠性兼得从上面的分析我们可以得知构建一个agent很容易无论使用框架还是自研但是要一个可靠、性能达标的agent却很难从 60 分到 90 分是比 0-60 更巨大的一步。以下情况都会导致 Agent性能不佳• 1. 不完整或简短的系统消息• 2. 用户输入模糊• 3. 无法正确选择工具使用• 4. 工具描述不佳• 5. 上下文信息缺失或错误• 6. 架构不适上面我们说到要在自主性和可控性之间做一个权衡其实如果要鱼与熊掌兼得话横亘在这里的唯一难点就是如何确保 LLM 在每个步骤都有适当的上下文。这包括控制进入 LLM 的确切内容以及运行适当的步骤来生成相关内容。3.探究自主性首先我们来看自主性是什么自主性 感知能力 决策能力 执行能力 学习能力具体而言自主性是实时动态能力的涌现这体现在上面四个要素动态的协同互动不断递进产生了类似生命的自主性特征。通俗来说就是基于模型对任务的理解自己拆解设计流程并逐步完成且不断迭代过程。AI Agent 带来的自主性给我们的软件编程范式带来了巨大改变。 从传统编程命令式到声明式再到如今 Agentic 决策再到动态能力扩展不得不说我们的变成习惯和思维需要做出适应 Agent 时代的改变。传统的软件需要我们特定的编码 if else 来处理现实世界中各种复杂的场景需要预编写成各种业务代码这种情况对程序员的需求和要求是巨大的。各种 dag/dg/ed 框架或者低代码平台诞生之后我们开始能够使用声明式的方式来动态控制我们的程序各种模块这对于我们的扩展性带来了部分的便利。llm 给我们带来的是可以在程序运行的过程中自己来思考如何编排或者协调我们定义的各种模块这主要包括自主流程拆解动态模块决策实时决策调整动态外部交互。更进一步如果有一个模块/功能我们的程序中尚未定义我们应该如何处理答案是 llm 写程序也就是在数字世界中动态创造我们的现实世界。这使得我们真正进入了元编程时代也是 AI 在数字编程世界创造性的来源。上面的 1 到 4 是一个递进的过程AI agent的自主性演进代表了软件开发范式的根本性转变, 这个过程 软件正变得不断自主可控。这其中支持这一切的主要是不断智能的模型自我学习的增强记忆和上下文理解的增强。从预定义一切到按需创造一切这种转变不仅改变了我们构建软件的方式更重要的是重新定义了人与计算机的关系——从人指挥机器执行到人与智能体协作解决问题。4.塑造可控性前面我们已经介绍过自主性的本质核心是要让整个系统拥有完全的自主决策能力何时何地应该根据外界情况做什么要实现这个目标会面临诸多的挑战其中最主要的一点便来自于自主性与可控性的权衡困境。自主性要求我们不得不强依赖于模型的决策但我们都知道无论多么牛逼的模型都不可避免的会有失控的可能。这主要是因为一个 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 的回路自我学习纠正演化。5.可扩展性AI Agent 的可扩展性是一个综合性的系统设计目标。探究可扩展性本身就是一个复杂的课题这里我们从以下几方面来考虑• 1. 能力的可扩展具体主要包括工具的扩展性知识的扩展性模型的扩展性及如何引入新的功能能力。• 2. 结构的扩展性这可能包括与已有 Agent/数据系统/业务系统的协作和集成这种结构上或者叫边界上的 scale 也是重中之重。• 3. 另外还包括性能或者叫规模的可扩展如何水平扩展均衡调度 Agent尤其长任务 Agent 的执行更是关注的重点。能力可扩展上面的图标识了一个典型的 生产级 Agentic System 所包含的基本组件/模块。这主要包含两部分• 1. 运行的基本组成要素• 2. 观测的基本组成要素我们也将基于这两部分设计一个完整可运行可观测的 Agentic 系统要实现这个目标几个关键因素需要考虑框架的选择或者如果自研应该构建一个怎样的 Agent 框架或平台我认为应该一样遵循软件设计的原则首先框架是否可扩展我们不应该只关注功能是否齐全而首要的应该关注功能扩展是否友好这对于日新月异的 Agent 技术发展来说尤为重要。框架的可扩展性包含以下几方面a. 模块性插件化可以自由组合按需加载。-可重用的标准化组件也即每一部分都可以单独使用而不是llmtoolsmemorycontext的打包。-模板化逻辑、对话流、集成适配器-组件的编排无缝协调 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 模式。目前主流生产化的模式主要有以下几种• 1reflection模式生成→评估强调评估的作用。• 2ReAct模式思考-执行强调思考和执行的迭代进行。• 3Planner模式先规划-执行强调任务的统筹和拆解。• 4另外还有一些handoff等等模式。要选择哪种没有固定的模式并且这里的扩展性是必须的。我觉着是如何把 agent 开发的范式做到极致。综上我认为一个可扩展的 Agent 不仅仅只是能做出响应——它应当会思考、规划、执行和调整。并且这其中每步一步都应该是可适应插件化的推理能力记忆能力工具能力反馈能力续写能力。结构可扩展结构的扩展性主要包括多 Agent 架构的扩展及与已有系统的集成。多 Agent 协作的架构模式如图所示目前主流的 Agent 协作模式主要有• 1网络对等都可以挂工具相互之间可以通信每个 Agent 都可以自主决策容错性较高。• 2supervisoragent之间不能独立通信需要通过supervisor下发任务。典型框架AutoGptLangGraph• 3supervisor as tools调用方式跟单agent差不多只是模块化增强。• 4多级多层次一般会用在极其复杂的场景主要体现了多层抽象/分治的思想。典型框架基于 A2A 实现的系统• 5: 自定义适用于完全精细化自主控制的场景。如何选择需要根据我们的场景和要求进行选择 我们需要业务流程的梳理这是重中之重分解任务根据资源管理的要求决策的要求容错性的要求及复杂性要求选型逻辑另外我想澄清现实世界复杂多样多 agent 的架构一定是必须的这必将不会存在争议。参考人类社会协作方式的多种多样问题的多样分工的多样投影到软件世界/Agent 世界不会有本质的区别。Agent 协作的通信协议A2AA2A 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 则通过充当数据的“中枢神经系统”来解决这一挑战。它允许代理异步广播事件确保信息动态流动而不会产生严格的依赖关系。这种解耦使代理能够自主作同时无缝集成到更广泛的工作流程和系统中。两种方法都能做到解耦的同时保证上下文完整。上下文的完整、正确、简洁极其重要。大规模 Agent 带来的其它挑战1通信前面我们已经介绍过 A2AMCP 等内容但当大规模 Agent 到来时这仍旧是不够的不仅仅涉及到 Agent 跟 Agent 之间Agent 和工具之间。现实情况远比我们预想的要复杂比如可能还包括 Agent 和 网关之间 Agent 和 各种场景下的 UI流式的异步的长时间执行的。这里一个是涉及到效率一个是涉及到交互。2 容错与故障容忍当我们面对越来越多的 Agent状态的持久checkpoint容错故障容忍各种问题都会摆到我们眼前。3Agent 的集中管理观测问题是否需要中心化管理注册、发现、删除。负载均衡。调度。重试。切换。scale。等扩展到数百个 agent 可能会带来的一些问题。如何设计合理的观测指标跟传统微服务的区别除了关注性能、健康、结果外还应该关注哪些。agent 的长链路long time可能会给 trace 带来的问题。最后为什么要学AI大模型当下⼈⼯智能市场迎来了爆发期并逐渐进⼊以⼈⼯通⽤智能AGI为主导的新时代。企业纷纷官宣“ AI ”战略为新兴技术⼈才创造丰富的就业机会⼈才缺⼝将达 400 万DeepSeek问世以来生成式AI和大模型技术爆发式增长让很多岗位重新成了炙手可热的新星岗位薪资远超很多后端岗位在程序员中稳居前列。与此同时AI与各行各业深度融合飞速发展成为炙手可热的新风口企业非常需要了解AI、懂AI、会用AI的员工纷纷开出高薪招聘AI大模型相关岗位。最近很多程序员朋友都已经学习或者准备学习 AI 大模型后台也经常会有小伙伴咨询学习路线和学习资料我特别拜托北京清华大学学士和美国加州理工学院博士学位的鲁为民老师给大家这里给大家准备了一份涵盖了AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频全系列的学习资料这些学习资料不仅深入浅出而且非常实用让大家系统而高效地掌握AI大模型的各个知识点。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】AI大模型系统学习路线在面对AI大模型开发领域的复杂与深入精准学习显得尤为重要。一份系统的技术路线图不仅能够帮助开发者清晰地了解从入门到精通所需掌握的知识点还能提供一条高效、有序的学习路径。但知道是一回事做又是另一回事初学者最常遇到的问题主要是理论知识缺乏、资源和工具的限制、模型理解和调试的复杂性在这基础上找到高质量的学习资源不浪费时间、不走弯路又是重中之重。AI大模型入门到实战的视频教程项目包看视频学习是一种高效、直观、灵活且富有吸引力的学习方式可以更直观地展示过程能有效提升学习兴趣和理解力是现在获取知识的重要途径光学理论是没用的要学会跟着一起敲要动手实操才能将自己的所学运用到实际当中去这时候可以搞点实战案例来学习。海量AI大模型必读的经典书籍PDF阅读AI大模型经典书籍可以帮助读者提高技术水平开拓视野掌握核心技术提高解决问题的能力同时也可以借鉴他人的经验。对于想要深入学习AI大模型开发的读者来说阅读经典书籍是非常有必要的。600AI大模型报告实时更新这套包含640份报告的合集涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师还是对AI大模型感兴趣的爱好者这套报告合集都将为您提供宝贵的信息和启示。AI大模型面试真题答案解析我们学习AI大模型必然是想找到高薪的工作下面这些面试题都是总结当前最新、最热、最高频的面试题并且每道题都有详细的答案面试前刷完这套面试题资料小小offer不在话下这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】