我构建多Agent平台的探索与愿景

术语

• ReAct是结合推理和行动以提升智能体决策能力的框架
• Handoffs机制是指多Agent系统中任务在不同Agent之间平滑转移的过程

概述

最近会遇到跟dify或是fastGPT的对比问题，会同类对比，AIP是目前在维护的开源多Agent平台，类似于crewAI平台。

每个设计师思路不一，Agent平台的概念容易与同类产品类比，其实不然。这里为了方便AI助手或是应用统称为Agent。这也是为什么会从零搭建Agent平台的原因，而不是使用现有dify或是fastGPT，前期设计大概以下几个场景：

• 类似 Agent来协助或承担工作，而不仅仅是聊天窗口而是工作台，需要针对很多场景的AI助手；
• Agent之间可以交互，过程可以审核，一定可以在生产业务结合解决问题；
• 跟现有业务的Agent场景闭环，从数据/工具/业务/推理形成闭环，业务高度定制化；
• 通过积累形成类似于业务自动驾驶，对某个业务场景的自动处理，形成业务超自动化；
• …

这些定位上，跟dify或是fastGPT会有比较大的设计差异，虽然在某些部分上，看起来类似，但总的差异还是比较大，每个产品的设计不一样，针对场景不一样，我有我思。

差异阐述

我所理解的Agent，是可以结合和解决到工作生活方方面面的，而不仅仅是chatbox（也许现阶段是这样），比如家居，会有一个家庭管家来管理生活方方面面。工作场景，应该是类似工作管家，根据我的情况完成我的工作。目前的AI结合貌似还不能达到这样，那退而求次，使用多个Agent来处理，下面我们从上往下阐述，体现差异点：

1.多个Agent来协助我的工作

可以使用现成平台来形成多个Agent角色，通过ReAct或是flow等方式，或是特定场景插件，比如Cursor，形成比较强的自动化，他可以分担我一部分工作了，下面形成Agent团队能力。

2. Agent之间可以交互

再建立很多Agent之后，角色开始变得很多。会发现有重复的或是需要协作，另一个是结果的不准确性，需要结合工作流审批，人工确认等，这个时候希望它可以进一步交互，类似Swarm的handoffs 机制（交接），让对话之间可以转移，还可以有上下文，但是又不能过于自由，因为我想交接到指定角色，就会发现有审批修改需求，如果能融入现有工作流就更好。
这个时候会发现，类似产品的无法形成上面的工作，或是比较难，他的设计场景不是为了这个而设计的。
这里的处理方式是拉入到同一个频道中，多Agent间共享上下文，另外可以相互交互。

上面的Agent修改和调整还是为同一个，这样内容更为灵活和自定义，结合业务起来更加方便。

3. 需要感知业务环境推理执行

环境的感知执行是Agent能力体现之一。

前期一直疑惑Agent跟城市大脑的区别，城市大脑需要N多的感知数据，触点采集，给模型推理，结果之后给人做参考执行，前期城市大脑、小脑的方法论，业务场景都比较全面，这里参考同样的设计。
LLM的推理能力相对于以前的城市大脑AI能力已经是非常超越，可以运用在各个场景下面形成大脑推理模块。
同类的，我们给每个业务场景都加一个大脑，会不一样，会形成每个行业业务场景都有一个贾维斯，即钢铁侠的人工智能，这将是一个业务场景的改变，个人觉得还是有可能的。
好了，如何做这个推理大脑套件，类城市大脑设计，做了压缩版本或是轻量级的，如下图：

这里我们统一叫工作区，从业务的数据感知-推理-工具执行形成一个套件，这样在很多业务场景结合大脑推理套件，提高业务服务能力。
模块式分开的，非耦合性，大模型在这里的作用是推理能力，协调各个业务线进行。按理解，大模型的能力还为提高，类似o1，不断提升，后期业务也会随着科技的发展，AI的发展更加智能。

4.形成业务超级自动化

类似于一种期望，但是实现路径比较明确。

我们发现，结合Agent能力的业务场景，它会不断的学习（如果有LLM DevOps结合就更好），感知，成长。随着业务数据和推理的成熟，每个业务场景自动化智能化总会有最优点或是最高点，Agent在这个业务场景下的数量也同样有范围，形成一套Agent角色来支撑业务的运行。

这个时候达到超自动化的水平，或者换另一种说法，更接近于AGI，虽然不太喜欢这个词，但是概念上会更好符合场景，这个也是一个愿景和方向。
按当前的AI发展，推理能力的不断增强，业务场景的不断切入，路径会更加清晰，类似于汽车的L4级别发展历程，相对于汽车，业务场景上的成本会低很多，开发路线也会明确很多。