月度归档:2025年01月

我对大模型Agent推理能力的设计方案

软件工程师罗小东,多年架构和平台设计经验,目前在研究平台与新技术结合中。

概述

DeepseekR1使用之后,发现推理能力效果比较突出,费用也比较低,之前是基于普通大模型的推理方式估计也要升级,这里写的是前期的设计思路,留个复盘稿。

推理过程主要使用的是ReAct和Cot两个方式,另外加上交互形式使用约定思维修改模式(Thinking Claude开源项目),也达到一定的推理效果,Cot相对比较简单,这里主要介绍的是ReAct的结合,从下面的维度和例子进行阐述:

1.对话结合方式和Prompt设计
2.框架设计和代码设计及工具设计
3.频道对话效果演示

原来基于一些论文和开源项目的参考,每个架构师设计不一,我有我思。

设计思路

这里考虑到通用型,不会使用过多的大模型特性FunctionCall,只是基于Prompt和大模型的推理,前期也会有一些的限制(解析准确性),但是目前的模型发展、推理能力的加强和使用情况,基本上限制微乎其微。

对话结合方式和Prompt设计

看过crewAI的同学会看到使用的是langchian,开始也是考虑使用这个,但是发现langchian4j这方面机制还不怎么成熟,另外解析方式也不是自己想要的类型,基于 java和groovy自己写了框架,主要是:

1.对话解析
2.工具使用
3.对话结合

下面是对话的Prompt设计,初始模版稿:

过程会根据对话结果进行不断的内容调整,以下为处理逻辑:

思考模式放在through字段,以finalAnser作为结果字段输出,循环按约定次数或是自定义次数。
工具也一样的解析注解形式,通过groovy编写工具然后提交给Prompt,下面是工具的例子:

大部分目前基本上都是类似,只是说使用哪种语言作为主要设计语言和方案。
那最后结合起来的方式,形成角色设计界面,做目标和初始设计,然后结合自定义工具。

在这个过程,基本上可以定义好我们想要的角色。到这步很多情况下对话推理已经达到了。
但考虑更偏向于人类思维,结合了Claude开源项目的约束设计,这里主要放在 promp的system中,这个是一个固定的模式,达到接近于人类的思维逻辑,加与不加效果目前没做过对比,是先加上。

框架设计和代码设计及工具设计

下面是一些设计的思路和代码,会包含有chatbox框,还有ReAct的解析类,还有工具类的设计约束。工具类的注解类设计,还有方式设计:

一个关于查询订单、演示demo,客户时间预约的工具类的例子,下面是客户预约的代码:

角色过程中还会接入记忆能力和知识库,这个是跟其他有些不一样的地方,关于记忆处理方式,这里不做过多的介绍。

这里偏向设计,代码部分不做过多的阐述。

频道对话效果演示

我们这里设计了两个角色:

  • 通用查询的角色:可以通过搜索引擎来查询实时内容,比较常见的例子。
  • 产品导购的角色:引到客户预约演示和查询订单的角色,也是通用型场景。

下面是通用查询的角色的查询方式,会自动去网络查询内容并返回结果分析:

定义了两个角色之后,把他们拉到一个频道做验证,下面是角色拉入频道 ,下面是导购的交互模拟:

从演示效果上的情况看,这个基本上能达到交互的效果,也有推理的场景,对话上还是有一定的推理体现。

总结

目前在使用的是qwen大模型,在测试过程中使用的是最为通用plus版本的模型能力,但是查看目前的o1和deepseek R1明显会有更好的效果,目前在研究接入和适配,也同样基于开源项目Agents-Flex(类似SpringAI)二次开发调试,以方便接入大模型规范。

以上为学习和研究大模型推理的应用场景和设计的一些思路参考,精力和思路有限,也期望有兴趣的同学可以互相交流。

我构建多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团队能力。


比如写文案得出初稿,市场分析,代码编写之类的,形成一版本,你会发现,你开始形成大量的prompt,提升效能,按使用体验来说,如果使用熟练的,从个人或是团队角度,这个时候效能已经提高很多。
可以透过聊天窗口,调用Agent角色完成工作,然后再进一步的结合自动化一起。

2. Agent之间可以交互

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


我们需要融合业务场景,需要开发工具给Agent或是提供对应的API接口,在业务场景上来说,就需要很多定制化开发,能结合很多场景,这里给每个Agent保留了对话、审批、执行接口,可以根据业务灵活定制处理场景需求。
比如下面的Agent编写文案,然后内容重写、扩写场景:

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

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

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

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


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

4.形成业务超级自动化

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

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


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

总结

以上为从设计到建设还有后期方向的说明,包括产品形态等,会跟当前的社区类Agent平台有一定的差异,当前在研发感知服务能力上,也就是上面的第3点,同时做Agent的优化。

每个设计思路不一,以为上个人设计的一些思路参考,有兴趣的同学欢迎交流。