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

背景

此为针对于AIP在项目团队上在Agent上的研究成果参考

随着大模型越发的能力增强，而由原来的AI Workflow模式，出现了比较大的弊端，传统的AI工作流方式：

• 思维的限制，不是AI限制，工作流排版是个人能力的限制
• 现在的大模型比绝大部分人更专业（或者说”聪明”）

AI 工作流程（非 Agentic）虽使用 AI，但只做一次推理，没有反复调整能力。而Agentic 工作流程整合 LLM、工具与记忆，可进行规划、执行、反思，是最具智慧与弹性的流程。

这个能力会更加强悍，会更加能体现出Agent的能力。

下面是集成的几个场景，主要是做输出型的场景：

• 单Agent智能体问答：不同场景下的单智能体的问答能力。
• DeepSearch深度检索：不同领域级别的智能体自定义DeepSearch深度检索
• 通用智能体场景：不同专业级别智能体组成的专业团队，可切换的场景

上面三种场景的使用，主要集成的Agentic工作流方式。当然，在集成Agentic的同时，并不代表会放弃到传统的AI工作流，而是可以有多种Agent的配置能力。

以上为AIP在技术团队管理场景上的一些探索，每个设计师有不一样的设计，我有我思。

集成场景分析

这里主要是目前在AIP能力上集成的场景分析，这里的MCP指的是并不是MCP协议，而是类似于MCP架构，基于AIP自己实现的类似于MCP的能力，需要自定义的扩展接口。

单智能体问答

这里是最常见的，调用MCP远程工具能力，集成推理能力，根据目标，调用工具来集成，过程不断的反思，总结，经过一次或者多次的思考，得到结果，而且往往得出的结果会更加符合要求。

以下为校园场景为示例，推理出学生班级的学生分析情况：

以下为分析出来的结果，会显示出每个班级的情况：

这里也会类似于纳米AI的MCP工具集，其实思路都差不多，只是结果并没有做一定的二次制作，比如网页、Word等，这个倒是可以考虑进一步加进去，这里可以集成更多的执行工具调用，包括一些执行型的结果。

DeepSearch深度检索

这里的深度检索集成，通过规划-推理-执行-总结几个步骤，但是会更加的深入场景分析，规划能力更强一些，同时对结果做了一步的格式化，是针对于单智能体上的一个提升点，你会发现，这个跟Manus有些类似，其实原理是一样的，只是缺少工作的，这也是下一步集成MCP服务服务的需要，在智能体框架初定的情况下，进一步的集成MCP能力。

智能体会规划和分析，还有进一步的去搜索，调用对应的工具去实现目标。

在这里我们做了输出的总结和优化，进行了结果的二次总结输出：

包括各类型的Word、Excel、PDF、网页等，这个时候会发现，这些规划能力总结起来确实效果不错。

针对于不同的专家类型，不同的场景，会有不同的知识库，不同的工作，接入不同的场景，这些相对来说，纳米AI做得更为平民化，这里考虑到适配不同的场景，可以定义多种不同的DeepSearch智能体，以下是配置界面：

这个是针对于不同领域专家输出的结果。

通用智能体场景

总的来说，上面是还是单智能体的交互情况，配置起来的效果可能还会有一些场景局限，然后增加了自定义多智能体结合起来的场景，这里我们定义为通用智能体，做为输出结果，我们需要更为专业的智能体来做专业的事情。

定义两个协同的智能体来配合完成一个事情，这里流程上我们配置引用不同的智能体来完成一个任务，下面是智能体的场景选择：

形成团队的能力来实现这个，更为灵活的控制每个环节实现这个目标，比如形成分析形结果输出，也以校园场景为示例：

团队能力的补充会在某个任务安排上更专业，效果更为突出，通过每个角色的能力来完成他需要完成的事情。

总结

通过智能体与工具的深度协同，实现从单一问答到复杂任务处理的全面覆盖。单智能体问答提供基础交互能力，DeepSearch 深度检索深化专业领域应用，通用智能体场景则突破个体能力局限，构建高效协作体系。
在保留传统 AI 工作流的同时，方案强调多 Agent 配置的灵活性，满足不同用户、不同场景的差异化需求。未来，可进一步探索智能体间的动态协作机制，优化工具集成与数据交互效率，推动 AI 工作流向更智能、更高效的方向发展，为各行业提供更具价值的 AI 解决方案。

以上为Agentic 工作流上的一些探索，也期望有兴趣的同学可以互相交流。

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

概述

此为针对于AIP在项目团队上在Agent多项目团队上的研究成果参考，所有名称已做脱敏处理

团队管理是工程师在上一层提升需要的主要能力，团队管理不好会使工程师面临工作效率低下、职业发展受限、工作氛围压抑、人际关系紧张、工作压力过大等一系列不良影响，阻碍其个人成长与价值实现。

此主要为团队研发人员的能力情况，成长建议，个人能力，团队梯度等，更加有助于工程师团队的成长和管理，以图文形式做展示分析。因为是技术人员，这里主要接入的是Git的项目代码能力分析结果，当然，如果你用的是禅道，获取分析的结果会更加详细，但是可能偏重于项目管理上，主要使用的AIP多Agent能力在两个方面：

• Agent问数：直接Agent问出结果，为通用型场景，为单Agent问答层面
• Agent报告分析：更加为详细的成员报告分析情况，为多Agent协作层面

我需要具体获取到团队的整体能力分析情况，还有个人的能力分析，同时具体人员还有每周每月的工作量情况等，形成更详细的情况报告，以下为几个维度来做团队能力情况的展示：

• 整体团队代码编写情况分析
• 低产出成员个人能力分析及建议
• 整体团队报告分析及概述情况

单Agent主要是ChatBot上的问答，整体分析报告是代码质量、沟通协作、个人发展、团队平衡等整体分析报告情况，分析更全面、结论更具指导性。

以上为AIP在技术团队管理场景上的一些探索，每个设计师有不一样的设计，我有我思。

团队情况分析

能力分析主要为团队提供更全面的能力画像，还能基于数据驱动制定针对性改进方案，推动技术团队向高效、可持续的方向发展，获取的提问如下:

• “所有团队成员的能力情况及代码提交量情况分析”
• “个人能力情况分析，更详细的找出个人问题的短处还有提升建议，给出详细图文报告”
• “最近开发的功能是什么，列出最近一个月的工作情况，还有分析出这个段时间工作内容的饼图”
• “请设计一份针对C/D级成员的技术培训计划，明确培训内容和考核标准。”

我们会以黄涛（为虚名）为示例做为分析，更好的进行数据展示。

整体团队代码编写情况

我需要了解到团队成的整体能力还有提交情况，以找出团队问题，以下为获取到的整体分析报告：

本评估基于代码提交量维度，完整能力评估需结合代码审查得分、缺陷率、架构设计贡献等综合指标。

低产出成员个人能力分析及建议

我们很明确了解获取到E级的成员，这里以暂时标注为低产出，我们需要了解到【黄涛】的最近工作情况分析，会特别关注到，以下为产出的分析报告:

很快我们便获取到技术深度不足、架构参与度低、代码质量缺陷的问题，这个分析是正确的。我们再继续找出黄涛最近一个月的工作内部情况分析，然后做为获取到最近工作情况及分析。

在这块上确实是工作参与上，编码上涉及到主要模块的偏少一些。

针对于部分成员的能力提升建议

团队的大体情况分析已了解，我们需要了解和获取到一些分析建议，提升团队成员能力。我们问Agent，设计一份针对C/D级成员的技术培训计划，明确培训内容和考核标准。

这里的提升建议是根据团队本身的实际情况来做的考核标准分析及提升建议，以符合团队实际情况为主。

整体情况分析

其实我们需要了解团队的实际情况还比较多，整体分析报告是代码质量、沟通协作、个人发展、团队平衡等整体分析报告情况，能为团队提供更全面的能力画像，还能基于数据驱动制定针对性改进方案，推动技术团队向高效、可持续的方向发展。

以下为整体情况分析的目录情况：

此为长文本的团队情况报告参考，会给出更为细致的报告分析，这里分析情况。

包括现状、技术、领导力、管理、平衡、激励、知识共享等多个维度的分析报告，会更加明确的给团队管理和成长更好的建议，更好的协作团队、个人的成长。

总结

此次探索多 Agent 技术在技术团队管理场景中的独特价值：其高效的数据处理与智能分析能力，打破了传统管理依赖经验判断的局限，推动团队管理向精细化、数据化、智能化转型。后续可进一步拓展分析维度，整合代码审查、缺陷修复时效等更多数据，完善评估模型。

以上为Agent在团队管理上的一些探索，也期望有兴趣的同学可以互相交流。

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

前言

通用智能体是开源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平台的升级和落地策略，推动相关技术在实际业务中的广泛应用和发展。