1.和Agent的区别

2.Agent框架选择

以核心依赖为依据, 考量Star数, 顾及市场热度, 在此基础上综合起来, 从中选取5款Agent框架:。

1.： 17.8w Star

2.：  13.1w Star

3.Dify：  11.2w Star

4.： 3w Star

5.：微软开源 5w Star

3.各Agent框架对比结论

Agent框架适合场景优势不足

各类通用任务

1.完全自主执行2.任务分解与多步执行3.记忆和持续学习

1.2. 高成本这一状况, 以及效率方面存在的问题, 3. 操作具备的可控性表现为较低的程度 分别提及另外还有复杂任务场景前后文一致这一问题。

可明确拆解任务步骤

1.灵活多样的多步骤操控, 原生得以支持短长期的记忆, 简便易于调试且构成全链路可进行观测。

1.自主性有限2.Agent模式不成熟

Dify

可明确拆解任务步骤

1.低代码，易用性与低门槛2.强大的模型与工具能力

1.功能广而不精2.需在简单和复杂场景之间找到平衡

任务步骤不固定，需让Agent自己探索

1.工具和生态集成2.灵活性与深度定制

1.特定功能支持有限（如代码沙盒）

1.原生多代理支持2.灵活的对话流程控制3.可观察调试支持

1.社区生态尚处于起步阶段

4.为什么需要使用Agent框架

结论: 只要存在“问题没办法进行完全的穷举, 要跨越多个系统去查证, 并且还需要在对话当中进行澄清或者协商或者决策”这种情况, 那就更应当采用Agent框架, 而不是单纯的。

为什么？用一个真实的ToC场景客服链路来说明。

4.1 纯 在智能客服里的“天花板”

（不管是Dify的可视化编排, 亦或是那状态机来讲）极其契合步骤明确加上条件受限的流程, 诸如:

1.查询订单 → 格式化答复

2.退货→生成标签→发通知

3.FAQ 检索→返回片段

一旦进入长尾问题， 就会遇到“分支爆炸”：

还是“包裹没至收货处”这样的诉求, 也许得全面考量, 其一为承运商的状态情形, 其二是发货方面的SLA标准, 其三是节假日所施行的相关政策, 其四针对因地址而引发的异常状况, 其五关乎是否属于会员身份, 其六涉及是否已经报告货物缺货这一情况, 其七考量是否已经有部分货物被签收, 其八考虑是否叠加了优惠券或者存在补发某物等具体情形。

如果你用固定分支描述：

假设有五个意图, 有六种物流状态, 有三种用户等级, 存在三个政策时段, 分别是平日、大促、假期, 还有三种地理区域, 如此说来, 会得出共 5×6×3×3×3 =810 条潜在路径。

这尚未计算异常（报损、拒收、欺诈信号）以及“对话澄清”的分支, 维护成本会被拖垮, 上线速度也会被拖垮, 此外, 对对话中的“澄清—再决策—再行动”并非天然友好, 需要将每一步提问、回答、重试都画成节点, 复杂且脆弱。

4.2 Agent 框架解决的核心问题

像 / 这种 Agent 框架, 拿它当例子来说, 它们将“于对话之中进行动态规划以及调用工具”视为首要的能力 , 能力:

下单时间是8月1号, 到今天还没收到, 收件地址实际上要变更, 并且我遇到了重复扣费的情况。

一个合格的客服 Agent 团队会做什么？

1.意图识别 + 澄清

Agent: 将多意图拆出来, 这多意图是物流异常、改址、计费异常, 先去询问关键需要澄清的内容, 这关键需要澄清的内容是订单号、新地址、扣费凭证。

2.跨系统取证

​ OMS/物流工具：查轨迹与 SLA；

​ 计费/支付工具：核对重复扣款交易；

​ CRM：看是否 VIP、是否有历史补偿记录。

3.政策推理与合规

使用“假期延误 + VIP + 改址”的组合条款, 对可给予的补偿区间进行评估, 判断是否能够免费改址, 查看是否会触发风控人工复核。

4.方案生成与协商

给出一种可行的方案, 该方案是提出“改址 + 走加急补发 / 或原包裹拦截、 + 退款差额、 + 账单冲正 “这些内容, 并且要在对话里, 按照用户反馈, 实时进行调整。

5.执行与闭环

运用工单与票据工具, 进行落账操作, 开展发券行为, 实施改单举措, 完成寄件流程, 将相关信息写入 CRM 备注。

​ 生成总结，告知时限与跟踪号；

​ 若任一步失败，自动选择备选策略或升级人工。

在这些动作当中, 存在着许多步骤，这些步骤没办法在事先“画”成固定分支, 而是需要在对话所处的上下文当中去进行决策, 同时还需要跨工具进行动态组合, 并且还需要“问一句, 接着查一下, 之后再做决定”, 而这恰恰就是Agent所擅长的强项之处。

5.各Agent详细介绍 4.1 

简而言之, 它是首个突然走红的自主AI Agent架构, 能够提供一整套工具, 以此供应给使用者, 继而构建并运用自治代理人。它的功能包含代理创建部分“Forge”, 具备性能评测的标准, 还有排行榜, 以及易于使用的用户界面和命令行界面接口。

核心特性为, 支持一种“思考, 而后行动, 接着反馈, 最后学习”这样的循环模式, 以此使得代理能够持续不断地生成子任务, 进而执行它们。并且, 该事物有着丰富多样的插件以及工具接口, 这便允许代理去访问诸如浏览器、文件系统、API等之类的资源, 借此达成复杂的链式任务。

关键应用情形: 存在要使名为Agent的事物自行分解目标然后予以落实的情况, 这类情况像市场调研、行程规划、代码编写等。

优势与不足：

优势不足

自动性以及少量人力介入: 只要给出最终目的, 就能够自行规划流程并且持续实施, 不需要逐个指令引导, 进而明显减少人力投入与运营成本。

对于对话以及上下文一致性这方面而言, 当任务执行的步骤数不断加以增加的时候, Agent就有可能会渐渐地偏离原本确定下来的目标状态, 进而产生出和任务没有关联关系的输出内容。在模型之中增添了记忆模块之后, 能够在一定的程度范围内对于此类问题起到缓解的作用, 然而依旧无法做到完全彻底地避免上下文出现丢失以及输出产生偏移这样的现象。

可执行子任务的逐一完成, 是通过将复杂目标划分达成的, 且此划分具备ReAct机制，该机制被内置。多种工具被集成, 像文件操作、网络搜索、代码执行等, 这使得在同一框架之下, 不同能力能够被调用, 以此解决问题。

在这当中存在着高成本以及效率方面的问题, 于执行的进程里, 需要频繁地去调用大型模型的 API, 每一个步骤所做出的决策, 都极有可能耗费大量的计算资源以及费用, 除此之外, 采用循环试探这样的方法来执行任务, 相比于人类那种直接朝着主题去处理的方式, 或许会显得效率较为低下。并且一些简单的任务, 在执行期间呈现出迂回冗长的态势, 花费的时间也是比较多的。

记忆机制跟持续学习相关联, 它融合了短期记忆模块以及长期记忆模块, 在对话期间, 能够留存上下文, 在操作进程当中, 还可以调用先前学到的信息；在连续任务执行之际, 会把每一步的结果增添到记忆里面, 并且依据这个来调整后续行动, 进而提升任务完成的连贯性以及智能性；这种自我改进能力对 Agent 在长流程任务中的表现具有促进作用, 使之表现得更好。

操作具备可控性, 这是因为, 用户仅仅设定初始目标的时候, 在这一过程里, Agent的具体操作路径并不具透明度, 很有可能出现偏离期望的行为, 比如说, 它有可能搜索到不相关的信息, 或者尝试去执行不恰当的动作, 但是自身却浑然不知, 尽管通常情况下, 会提供每步执行之前让用户确认的选项, 然而, 在开放的连续模式之下, 缺乏监督这件事, 可能会使得错误不断蔓延。

使用示例：基于让Agent帮我写一篇介绍的文章

1.创建Agent及配置名称、角色以及目标

2.Agent 自主思考、规划、执行

3.最终输出

4.2 

简介: 是团队推出的某个框架, 这个框架具备有状态、能持久运行、用于多智能体应用的编排特性。其核心把Agent构建模拟成一个图, 也就是Graph, 在这里面每个像节点一样的部分是计算步骤, 计算步骤包含LLM调用、工具函数以及任意代码等, 而边起到控制流转作用, 控制流转包含条件与循环, 最终达成既定目标。并且在今年6月给出了预构建模式, 针对常见的多智能体场景做了抽象封装, 然后在这种情况下开发者只要定义少量参数, 就是举例说那种参与的子智能体、主体提示词等, 便能够快速生成完整的多Agent协作系统。

Graph和预构建模式的示意图：

重要特性为, 支持图式编排, 能够进行人工干预, 具备可中断以及续跑的能力。可以构建出可控的分支或者循环流程, 能够于各个节点里增添人工干预的环节, 适宜那种需要人工审批或者修订的业务场景, 而且依据持久化状态能够便利地中断、续跑还有回溯。

典型应用场景是, 场景中任务步骤能够被明确拆解, 像那些属于RAG类的场景, 还有文章生成场景, 以及日程助手场景等。

优势与不足：

优势不足

能够灵活进行多步骤流程控制, 其最大优势在于具备高度灵活的工作流编排能力, 借助图结构这种逻辑, 可让开发者针对特定需求去定制非线性的执行路径, 从而实现从对话分流、复杂工具调用, 至错误重试等各类流程。

自主性存在着一定局限性, 所强调的乃是由开发者进行显式控制的Agent流程, 这种流程在某种程度上对Agent的自主性造成了限制。和追求高度自我驱动的框架相互比较而言, 其中的智能体基本上依照预先设计好的图谱去执行相应任务, 而不会自己主动生成全新的高层次目标或者策略。

把共享 State（状态）的概念给引入了, 让数据在工作流的各个节点之间进行持久化、共享。将这个共享态用于每个节点的出入入、输数出, 让该共享状态得以写入。这样一来, 后续的一些节点就能够去访问在前步骤中所存的信息。借助这种内存机制, Agent 可以拥有一种短期的记忆, 也就是关于当前对话或者当前任务进展情况的记忆, 还能够通过外部数据库去实现长期的记忆哟。

预构建模式缺乏成熟度: 当下, 预构建模式里头的内部交互, 对用户可不是透明的状态, 在框架之外精准插入自定义逻辑或者中间步骤, 是难以实现的。与此同时, 处在失败状况下要做特殊处理的时候, 或者并行去执行多个任务情形时, 预构建模式缺少显式机制, 复杂流程控制很难为之达成。预构建模式当前没有内建的重试、降级以及提示机制, 得靠开发者在外部进行捕获并处理, 不然的话, 对话说不定就会中断或者出现不一致的情况。

易调试以及具备高可观察性, 因采用显式的图结构, 工作流的执行路径是透明的, 其状态变化也是透明的且可追踪, 开发者能够轻松地插入日志、检查点, 可以观察数据在各个节点的流动情况, 还能利用调试工具来定位问题, 与所提供的等监控、调试工具进行深度集成, 能够针对每次LLM调用、工具使用展开详尽跟踪以及可视化, 助力开发者快速调试复杂链路。

使用示例：基于让Agent帮我写一篇介绍的文章

1.构建工作流（）

附工作流运行逻辑：

2.最终输出

4.3 Dify

介绍一下, Dify（也就是Do It For You）, 它是个开源的低代码的平台, 其目的在于把大模型（LLM）驱动的AI应用开发以及部署进行简化。它将“后端即服务 (BaaS)”和概念融合到一起, 给出了包含模型接入、提示设计、知识库检索、智能代理、数据监控等方面的一站式解决办法。凭借直观的可视化界面以及预构建组件, 不管是开发者还是非技术人员, 都能够迅速构建像聊天机器人、内容生成、数据分析等各种各样的生成式AI应用。

其主要具备的特点有, 低代码构成, 可视化的工作流得以构建, 检索增强生成的管道存在, 开放的工具市场现形。

具有典型性的应用场景是, 那种能够清晰进行任务步骤拆解的场景, 像RAG类场景, 还有文章生成场景, 以及日程助手场景。

优势与不足：

优势不足

易用性以及低门槛方面: Dify最大的亮点当中的一个便是上手极其简单, 它那可视化的操作界面使得用户基本上不需要具备编码技能便能够搭建AI应用, 预构建的节点还有模板减少了繁杂的配置, 在几小时之内就能够完成以往需要数周进行开发的原型, 相较于诸如等要求编程的框架, Dify降低了AI应用开发的门槛, 从而让更多的业务人员能够直接参与。

它的功能覆盖面极为广泛, 然而在某些专业领域的深度层面, 或许比不上专门化的工具, 这就是对其的一种评价, 这种评价展示出功能广而不精的状况。比如说, 它内置了知识库RAG功能, 可是在复杂文档理解、细粒度检索参数这些方面, 比不上专注RAG的框架。像诸如 等框架。

具备强大的让模型跟工具互相结合的能力, Dify从一开始就着重突出“对模型不偏向特定一方”以及能够按照人的心意灵活拓展, 一开始用就算支持几十家模型供应商所提供的上百种基于语言的学习及模型塑造工具, 其中包括比如像那样的厂商、还有、还有Meta以及各种各样本地范围里开放出来源泉进行再塑造的模型等等。在工具这一大类别里, 包括了一些十分一般性的网络条件跟可以起到工具意义的类似通过AI塑造得出那种条件, 可以依靠外部所展现能力去完成一些包含环节比较多、过程艰难的任务。

选择“重量级”工具这件事: 要是仅仅做个极为简单的问答机器人或者具备单一功能, 选用Dify会让人觉得是在“大材小用”, 缘由在于它具备的众多高级功能根本用不着, 反倒还增添了系统复杂性。与此同时, 企业要是存在诸多特殊需求, 通常也得对Dify展开二次开发才能够满足。所以, Dify最为契合的实则是中等复杂度的场景: 太过简单的情况可直接运用现成API, 太过复杂的情形或许得进行深度魔改, 在这些处于极限状态的情况下, 就得权衡使用Dify的性价比。

使用示例：

1.工作流类型

2.Agent类型（ Call）

4.4 

介绍: 它属于多智能体编排框架, 其核心观念是使多个有着特定角色的AI代理, 协同合作, 也就是组成“crew”团队, 进而完成复杂任务。每个代理都被给予特定角色、目标以及背景知识, 借助相互分工与配合, 自动开展任务委派和问询, 最终以团队形式达成用户交付的工作。

主要特点：多工具及生态集成、支持和AI Agent两种模式

优势与不足：

优势不足

工具与生态集成, 起初是借鉴并构建于生态之上, 所以天然支持运用生态所提供的大量工具集合, 像是搜索、数据库查询、API接口等。与此同时, 自身以及社区提供了诸多内置工具, 当前已内置超过40种工具接口, 涵盖常用的LLM、云服务、数据库等, 供代理直接使用。

特定功能的支持具备局限性, 相较于某些十分专精的框架, 在特定的能力方面, 或许比不上对手那般完善。比如说, 以“AI编程助手”这一具体场景来讲, 并没能内置如同 那样成熟的代码执行以及自我纠错循环。要是需要达成让代理编写代码并且执行代码以完成任务的目的, 则必须要手动去集成额外的工具, 像是运行代码的工具。当下 并没有直接提供沙箱执行代码的内置模块, 这使得它于代码自动生成跟执行的任务上略微显得有所不足。

以下这般改写: 灵活性以及深度定制之处在于, 现所处高层模式的状态下面, 其仍然留存有相当大程度的极为灵活之特性。对于开发者而言, 能够进一步深入去定制每一个代理的用于提示的内容、所使用的工具以及内部呈现出的行为表现。甚至还能够自行去定义处于较低层次的提示模板以及代理自身的行为。它具备支持同时去结合自主代理也就是 Crews 以及精确流程也就是 Flows 这两种不同范式的能力, 以这样的方式来允许在同一个应用程序里面, 既存在有着自主探索的那一部分内容, 又存在有着确定顺序的流程环节, 进而能够实现毫无缝隙地融合自治以及精确控制这样的效果。

使用示例：研究AI agent领域的最新进展

4.5 

介绍部分: 它是微软所开源的, 一个针对AI（也就是代理式人工智能）的编程框架, 用途是构建AI智能体, 并且推动多个智能体共同协作, 以此来完成复杂的任务。它支持事件驱动的分布式架构, 具备良好的可扩展性以及弹性, 能够被用于搭建可以自主行动, 或者在人类监督之下运行的多代理AI系统。

主要特点：微软开源、原生多Agent支持、灵活对话控制

优势与不足：

优势不足

原生具备有多代理支持特性, 此框架是专门为多智能体协作而设计的, 它从一开始就支持多个 Agent 之间展开通信以及并行开展工作, 它还提供了用于创建以及编排多代理对话的高层抽象, 凭借这一抽象, 多个 AI 模型能够借助自然语言消息实现动态交互, 进而共同完成任务。

近年才推出的框架于 2024 年末发布重构版 v0.4, 该框架所属的社区生态尚处于起步阶段, 其相对别的成熟框架的生态系统仍在成长之中。微软虽说提供诸多详细文件并称社区支持完备, 然而因版本递新甚速, 文档有时候较代码滞后, 出现文档与实际功能不符的状况。当今针对此框架的第三方教程、案例以及工具库数量有限, 大部分资源均来源于官方团队。这表明, 当碰到非常规问题之际, 开发者可借鉴的社区经验比较少, 更多得依靠官方渠道的支持, 是件如此这般的事情。

一种具备灵活性的对话流程控制方式, 它采用的是利用异步消息来驱动的架构模式, 在这种架构下, 代理之间展开的通信能够以异步的形式来进行, 不会被限定于固定不变的顺序之中。而这所蕴含的意义在于能够实现可进行高度特定化定制的对话流程, 具体表现为代理之间的对话能够依据上下文的情况自由自在地实现分支、暂停以及恢复, 甚至在人类进行干预的状况下还能够再次规划。

支持可观察调试: 框架内部装设了齐全的可观测性以及调试工具。具备消息跟踪、日志记录以及集成这类功能, 便利开发者监控代理之间的交互进程, 排查出现的问题。而且, 准许把代理生成的代码提交至沙盒（像是容器）进行安全执行, 并且支持实时查看代理行为、可视化消息流等。

Swarm模式下的机票退订助手示例：

6.总结

这篇文章着重于阐述当下与Agent之间的差异, 也说明了何时应当运用Agent框架, 即当问题具备复杂、长尾以及多变这些特性时, Agent才会成为主要力量。并且还简略介绍了当前的几类框架, 像、、Dify、、, 期望能够在技术路线的抉择以及框架进行选型这两方面, 为各位读者提供助力。