软件工程师罗小东，拥有多年架构和平台设计经验，目前专注于平台与新技术的融合研究。

背景

针对于刚出的扣子空间临时整理的笔记，同样，此只针对于AIP多Agent平台的升级阐述，临时笔记，略有口语化。

前期一篇手稿[我对多Agent平台的进一步升级和落地范式]刚出了一版本范式论，如果说Manus是一个引子（还不成熟），但是扣子空间的出现，将多Agent协作的思路做好了定调方向，明确了多Agent协作的未来方向和决心，还有形态体现，在目前看极有可能（只是有可能）是Agent的未来2-4年形态）。

概述

所设的加速，就是不用再过于探索性的设计预研，产品形态思考，还有技术预研等，针对于AIP来说，设计部分是最耗时的部分，下面是前期23年的整体架构设计：

明显，到现在25年的今天，这个架构在一定的程度上，会有一些落后，以前是单Agent的架构，现在需要的是多Agent协作的架构。

需要足够或者成型的参考和探索，前需要做两个定调，也是之前一直觉得迟疑或者未考虑好的基调，定调的是两个：

• 产品形态：明确产品输入到输出结果交互形态的设计
• 工具包：工具包的抽取或者规范及与大模型的结合（MCP）
• 数据资产：行业数据或者通用数据资产与大模型的结合

这两项的定调会让直接编码，进入开发和测试阶段，而且弯路不会那么大，技术方案和技术路线也是比较明确，这也是原来的定位，简单而且容易结合本身业务，结合企业级场景，小型而且可以私有。每个设计师都有自己的看法和思路，我有我思。

定调内容

所设的定调不是无设计思路，只是具体使用的场景还有必要性，投入成本，周期是否可以达到预期，原来的考虑是先梳理方法论，一确定好思路和方向，很快就会出现产品的形态和进行投入场景使用优化。

产品形态

场景的闭环形态，任务场景的闭环形态是输入和输出的目标和结果，比如写文档场景，写爱情小说是目标，输出小说则是结果，这个形成闭环，而发布小说，则是另一个场景，由此来进一进的落地一个个场景。

多Agent智能体结合与不同行业Agent结合形态，在进入场景时，针对于不同的场景选择不同的Agent智能体，以解决通用Agent和业务Agent的区别。

场景交互形态以规划、执行、实时输出，结果整合，最终形态为路线，形成场景处理思路，此处确实是参考了Manus的交互设计，以下为两个示例，右边的实时的Agent执行输出。

数据分析的示例：

文档审核的示例：

以上为多Agent协作产品形态的体现，此形态后期还有很大的优化空间，路径也比较明确，当前会考虑先落地为主。

工具包结合

工具包是前期做Agent的痛点，也是开发的痛点，通过API调用解决了一部分问题，原来的接口架构也已经处理好了，之前的定位是在数据资产模块提供接口能力，但是始终觉得并不是最优解。

而MCP的出现貌似可以解决这个问题，但是不确定性还有技术框架的成熟等，还需要再等待，是否能成为行业规范，也有一定的观望态度，而目前在多个大厂的推广和使用形态下，明确定了MCP的结合思路，但是要需要服务，而client框架要自定义结合的方式，以解决智能体平台和工具平台分离的问题，还有规范问题，具体MCP的实现只是另一个方式。

工具的结合很快就可以将前期Agent和使用各方工具包的统一形成标准（需要的就是这个标准规范），可以更明确工程关系还有总体设计，也有利于市场推广，预计会在2个月左右完成MCP服务的搭建和适配。

数据资产结合

通过智能体和行业专家型智能体的区分，是否有价值性，在模型能力都差不多的情况下，通用的结果会出现可看而不能可用，或者说针对于行业业务，或者本身业务来说关联不大，结果不是直接交付型方向，

数据资产与Agent落地的结合如下:

• 通用Agent智能体: 这些是看得到的或者是常用的逻辑思维，比如目前的大模型就具备。
• 业务Agent智能体： 这个是针对于业务性的，大到公司多年数据，小到一张表，或者一张Excel数据。

当中会包含数据标注，评分，采集，清理，输出，训练等等过程，当前的目标性是给Agent场景，比如报表会有数据分析Agent输出，工作周日报会从工作Agent输出，这些会形成新的交互形态，还有输出形态，形成明确规范（需要的也是这个规范），从而形成工程化和系统化。

总结

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

参考

• Manus
• 扣子空间
• AI小镇

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

整体概述

此只为针对 AIP 开源多Agent平台，且为临时手稿，带有口语化，仅以参考为主。

在本地化的沟通过程中，我们遇到了一系列实际问题，并在此基础上进行了总结与产品能力的提升。

鉴于当前在相关领域缺乏明确的范式可供参考，本文旨在提出适用于下一步的落地范式。整个升级过程紧紧围绕 “聚焦” 二字展开，在于实现 ToB 业务的拓展以及向 ToC 场景化的延伸。

由于概念过快，业务大模型对技术的探索性，前期重点会放在ToC，能力体现是私有化和SaaS化，使得Agent落地范式更加明确，具体而言，将在以下几个关键方面进行优化：

1. 明确场景结合方式：使多Agent与各类场景的融合方式更加清晰明了，从而提高系统在不同场景下的适用性和效率。
2. 降低成本与增强私有化：紧密结合业务场景，实现更低成本的运作模式，同时强化私有化部署的能力，满足客户对数据安全和个性化定制的需求。
3. 引入原生大模型应用思维：摆脱传统软件开发思维的束缚，充分利用原生大模型的优势，构建更加智能、高效的应用体系。
4. 深入探索业务场景：将更多精力投入到对业务场景的深度挖掘中，精准把握客户需求，提供更贴合实际业务的解决方案。
5. 提升通用场景的通用性：在切入通用场景时，进一步增强系统的通用性，让用户能够直接便捷地使用，减少复杂的配置和调整过程。

以下为通用法律AI场景，智能体角色：

更为具体的场景结合：

为确保升级方向的正确性和落地范式的有效性，我们遵循以下基本原则：

1. 场景明确性：Agent 必须针对特殊且明确的场景进行设计，避免多业务场景的混合应用。即使不同Agent的工作流看似相似，也应严格区分，以保证系统在特定场景下的高效运行和精准服务。
2. 场景深度：Agent 需要深入特定场景，简单的Agent往往能力有限，难以充分发挥作用。应避免构建能力过低的Agent，确保其能够在相应场景中体现出足够的价值。
3. 技术主导与客户反馈结合：Agent 由技术团队负责建立，客户主要负责提出需求以及提供使用反馈。通过这种分工模式，有效避免Agent在设计和功能上出现鸡肋的问题，确保其能够切实满足客户需求。
4. 业务专家参与：Agent 的建立需经过业务专家的充分讨论。对于非专家参与构建的 Agent，暂不考虑纳入应用范围，始终将重点放在能够体现高价值的Agent构建上。
5. 符合大模型原生应用：Agent 应充分契合大模型原生应用的特性，避免局限于传统的单一输入框工作流思维模式。要积极探索和构建符合原生大模型特点的应用形式，充分发挥大模型的强大功能。

每个设计师有不同的设计，我有我思，期望有兴趣的同学多交流。

平台形态

平台基础形态通过SaaS化的形式对外提供能力，直接提供场景化的Agent能力。

单Agent向多Agent延伸

去掉ChatBox思维，一个输入框架是不能解决业务问题，而是需要结合业务场景框架。

在传统的交互模式中，ChatBox 思维存在一定的局限性，仅仅依靠一个输入框架往往无法有效解决复杂的业务问题。我们需要结合具体的业务场景框架，构建更加灵活和高效的交互体系。在实际业务场景中，单个Agent常常难以独立完成所有任务，因此，将多个Agent组合起来协同工作，形成协作模式，成为必然的发展趋势。

例如，在 AIP 编写文档和文档审核的场景中，可分别设置负责内容创作的Agent和专注于文档审核的 Agent。

负责编写文档的Agent能够根据给定的主题和要求，快速生成高质量的文本内容；而负责审核的Agent则可以从语法、逻辑、专业性等多个维度对文档进行全面审查，提出修改建议。

在频道（群）场景下，多Agent协作也能发挥巨大优势。不同的Agent可以分别承担信息收集、话题引导、答疑解惑等不同职责，共同营造一个活跃且有序的交流环境。

传统软件思维要去掉

大模型的出现，极大地拓展了软件应用的边界，其能力远远超出了传统软件形态的范畴。我们不能再将思维固化在传统软件模式中，而应积极探索更加丰富多样的形态。这种丰富性不仅体现在语音交互等常见形式上，更体现在整体交互模式的创新上。

例如，传统软件可能主要依赖于用户手动输入指令来执行操作，而基于大模型的应用可以通过对用户行为、语言习惯、历史数据等多方面的分析，实现更加智能化的主动服务。

用户无需明确输入指令，系统便能根据对用户需求的理解，提前准备相关信息或提供合适的建议，从而为用户带来更加流畅和便捷的使用体验。

业务场景需要要明确

大模型的能力是超出了传统软件形态的模式，不要固化在传统软件形态，会显示更加丰富的形态，而不仅是指语音，而是交互模式。

在实际推广和应用过程中，不能给客户一种 “什么都能做” 的模糊印象。因为这种宽泛的表述往往意味着在实际操作中可能什么都做不好。

我们必须明确系统所针对的具体场景，以 RAG（检索增强生成）技术为例，其在不同领域和业务流程中可能衍生出 N 多个具体场景，以下为AIP不同场景工作台：

只有将这些场景明确界定，才能让客户清楚了解系统的适用范围和实际能力，从而增强客户对产品的信心，避免陷入 “看似全能，实则无力” 的尴尬境地。

比如，在医疗领域，RAG 技术可应用于辅助医生进行疾病诊断，通过检索大量的医学文献和病例数据，为医生提供诊断建议和参考依据；而在金融领域，RAG 技术可用于风险评估，通过对市场数据、企业财务报表等信息的检索和分析，帮助金融机构评估投资风险。

Agent需要要专业

Agent 要具备更高的专业性，深入到特定场景的核心环节。这不仅体现在其具备强大的交互能力，还体现在其能够整合记忆、数据以及模型训练等多个方面，并将这些环节实现交付工程化。模型并非一成不变，Agent 也需要不断进化。它应具备自主学习能力，能够根据每次对话和任务执行过程中积累的数据和经验，进行自主训练。同时，Agent 还应具备反思和总结的能力，能够对过往的工作进行复盘，分析其中的优点和不足，从而为下一次对话和任务做好更充分的准备。

将这些过程形成标准化的工程流程，有助于提高Agent的性能和稳定性。以 AIP 在Agent到记忆、反思的过程为例，Agent 在与用户交互过程中，会将用户的问题、提供的信息以及自身的回答等数据进行记录和存储，形成记忆。

以下为AIP的Agent设计模块和反思演化架构：

在后续的交互中，Agent 能够检索这些记忆，更好地理解用户需求和提供更准确的回答。

同时，Agent 会定期对这些交互数据进行分析和总结，反思自己在回答过程中存在的问题和不足之处，然后通过自主训练优化自身的模型和策略，以提升下一次交互的质量。

Agent需要搭配数据

Agent 作为最终与用户交互的形态，其背后离不开强大的数据支持。在后台，需要对原始数据进行一系列的处理流程，包括数据收集、清洗、整理等。

通过这些步骤，将杂乱无章的原始数据转化为有价值的信息，最终形成Agent的知识库。这个知识库不仅包含了丰富的知识内容，还融入了业务思维，能够帮助Agent更好地理解业务场景和用户需求，从而提供更符合实际业务的解决方案。

例如，在电商领域，Agent 的知识库中应包含商品信息、用户购买历史、市场趋势等数据，通过对这些数据的分析和利用，Agent 能够为用户提供个性化的商品推荐、解答用户关于商品的疑问，并协助商家进行市场分析和决策制定。

总结

以上内容是基于前期在客户场景下与多Agent沟通的实践经验，总结得出的业务落地范式。我们衷心期望对该领域有兴趣的同学能够积极参与交流，共同探讨，进一步完善和优化多Agent平台的升级和落地策略，推动相关技术在实际业务中的广泛应用和发展。

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

背景

大模型的发展超出预期，南宁本地各行业、包括政务系统也在接入Deepseek等国产模型，生成和推理的能力，给了更多想象空间。

AIP是一个基于Apache2.0的开源多Agent平台，你能虚拟出多个Agent员工或者成员，通过指挥助理，指挥总经理，或者部门经理，实习生等多个角色去做事情，Agent之间也可以交互，比如实习Agent可以提交结果给组长Agent审核。

概述

25年前年后的国内大模型发展一下如雨后春笋，Deepseek在南宁本地各行业切入，给大模型结合业务打下基础，AIP将进一步结合深度场景。

主要给大模型接上“眼”和“手”，由大模型“中枢”进行调度，下一步的输出计划如下：

• 进一步完善多Agent交互和自动化功能
• 实时数据治理套件，集成AI采集能力等
• 与前端商务接入和深入场景优化结合。

这里不再阐述Agent的设计，偏于应用实现，愿景是集成细化场景Agent闭环，体现AGI能力，每个设计师都有不同的设计，我有我思。

场景例子

以下为演示的例子，后期会深入其他场景。

目前集成的一个简单场景整合起来的效果，以AIP研发进度、周报、成员能力为例子，主要是采集到资产，再到Agent的场景，输出进度、周报、宣传文案、报表、还有成员能力数据。

数据资产

主要包括成员信息，每个成员开发进度分析，每天具体代码模块采集，进度采集，进行总结，还有每个人员的能力指标，开发情况等。

数据的采集，清洗，还有形成数据资产。

通过这些分析，由Agent进一步获取到内容，判断出每个问题还有成果，比如代码能力、任务完成情况，可以分析出成员能力模型，这些指标都由Agent作初步分析。

这些经过采集，清洗之后形成数据资产，同时提供出接口能力。

角色设计

结合的Agent能力，便于后期的运营查询，设计以下Agent角色：

• 研发进度专员：分析获取进度情况。
• 报表分析专员：获取一些统计报表。
• 产品公告专员：进度形成公告对外。
• 内容运营专员：形成对外的产品宣传输出。
• 能力评估专员：成员的能力分析。
• …

还有其他的，这里就不过多列出，以下为角色编排和定义工具，分类形成Agent团队能力:

为了更好的管理运营，我们分成不同的频道（群）来进行分类管理，作为不同的功能，一个Agent可能在不同的频道里面。

生成报表分析和管理：

形成产品研发进度情况角色：

输出内容运营界面：

人员能力模型，这块目前还在做界面，但是大概的原型会参考NBA成员能力界面，形成能力判断指标：

以上为简单的场景结合Agent能力，其实还可以有很多优化，也是下一步的事情，比如目前是人主动去用 Agent，更合理的是Agent主动去给人结果，比如每周五发周报或是计划给人审核，这样离AGI会更加接近。

结尾

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

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

概述

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）二次开发调试，以方便接入大模型规范。

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

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

临时笔记，会有一些口语化。

术语

• 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的优化。

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