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

前言

通用智能体是开源AIP项目上进行的探索，这里是近段时间输出1.0初版本设计，另外所谓通用的意思不会约束在某一个场景上面。

概述

单智能体的限制还有chatbot的限制，这里主要参考扣子空间，OpenManus等设计。

原则依然是针对于业务深入，针对的是中小团队场景，私有数据和大模型结合，设计思路如下：

• 结果型交付，需要结合业务有真实可用的输出
• 结合内部真实场景，不要娱乐型AI，结果可用
• 中小团队都能内部部署，低成本运作
• 可以切换不同场景，多Agent通用场景和业务型场景
• 过程还可以修改，可控还有进一步调整
• …

执行过程通过规划-推理-执行-总结-结果这个流程，推理主要是使用ReAct设计，每个设计是思路不一，我有我思，也期望有兴趣的同学可以交流。

输出效果

我们可以来看看输出的规划文档输出效果，这里以一份短视频营销输出文档为示例（非内部数据）：

这里是数据分析输出的效果，结合内部数据直接导入分析的（内部数据库）：

还有网页版本的数据分析结果，这里会有比较直观的图形分析：

网页版本的分析展示在一定程度上效果较好，但是内容结构相对于Word版本来说，展示还需要进一步的提升。

产品设计

以下为产品设计思路。

交付型结果

出来的结果需要达到可用或是结合业务的，这里直接链接的内部数据资产平台，直接提供查询和全文检索：

以下为输出的电商数据分析例子：

整体效果内容较为丰满，如果有不同的要求，输出的内容方向，也会有不同的结果，这里是AI默认生成。

低成本部署和落地

考虑到低成本，中小团队可以内部私有化，去掉了虚拟机或是其它不一定需要的工具，在一些场景上可能无法实现，比如浏览器RPA操作。

考虑到稳定性，这里数据检索，我们通过数据资产套件来处理，另外结合搜索引擎网络数据检索来实现。

下面是数据抽取的简单流程：

实时部分我们通过Chatbot来做显示进度还有运行情况，如下图：

这样也可以显示效果，我们发现也是可以满足场景需求。

多Agent多业务场景

我们之前研究看到的，类似Manus，它的Agent协作是固定的，这些在输出结果精度，幻觉，检索等方面需要较高技术难度，内容可能不够聚焦。

在这里我们设计场景Agent可以自定义选择，每个场景，有专门的Agent有自己行业的知识库等，使得Agent还有结果聚焦在这个业务场景上面。

通过多种Agent的选择和自定义，我们可以灵活的选择和搭配不同的智能体能力。

结果可控可修改

我们需要规划的结果可以修改，每个规划阶段过程也可以修改，以下为整体的设计界面：

左边的规划结果是可以调整修改还有重新生成结果的，内容也可以编辑，达到更优的结果。

以下为输出的指定Agent来做报表输出，也可以不同场景切换不同的Agent来做输出：

报表输出的结果显示也是由AI生成，每个显示结果和报表都做了二次设计和定义不同的指令。

总结

以上为在通用场景上的研究情况，有一定惊艳的效果，主要是让我们的AI设计往交付行结果走了一步，前期跟客户进一步沟通的情况，假如说大家的设计架构是一样的，其它的就是Agent数据资产的优劣程度，数据质量的高低，行业数据资产和AI这部分将是我们下一步深入探索的部分。有兴趣的同学也可以交流。

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

背景

针对于刚出的扣子空间临时整理的笔记，同样，此只针对于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平台的升级和落地策略，推动相关技术在实际业务中的广泛应用和发展。