软件工程师罗小东，拥有多年架构和平台产品设计经验，以下为开源项目AIP集成超大文本的设计思路。

术语

• 超大型文本：指的是超过100多页、超10万字的文档，比如解决方案、技术方案、招投标书
• Agent编排：这里的编排不是工作流，而是针对业务场景的编排，类似于团队人员工作的安排
• 多Agent技能：每个有自己的技能和擅长部分，每个Agent解决自己的擅长的点

概述

下面处理出来的一般是初稿，然后再进一步的调整，目前的Agent定位为辅助

常会接触过超大型文本，如解决方案、技术方案、招投标书等，通常超过100多页、10万字。处理这类文档时。多Agent系统提供了一种新的解决方案，通过多个智能体（Agent）的协同工作，可以高效地处理复杂任务。

一般超大型文本具有以下特点：

• 信息量大：包含大量的技术细节、业务流程、管理计划等内容。
• 专业性强：涉及多个领域的专业知识，需要高度的专业性和准确性。
• 一致性要求高：文档各部分需要保持一致性和连贯性。

处理超大型文本时面临的主要问题：

• 效率低下：人工编写和审核耗时长，容易出错。
• 一致性难保证：多人协作时，容易出现
• 质量难以控制：文档质量依赖于个人能力和经验，难以标准化。

为了更好的表达，下面以招投标场景为示例来进行阐述。

设计思路

多Agent系统是由多个智能体（Agent）组成的协作系统。每个Agent具有独立的技能和专长，能够处理特定的任务，从过去的项目中抽取成功案例和技术文档，形成一个结构化的知识库。将这些知识库分别导入给单个Agent，使其在编写文档时能够参考和借鉴。

协作机制

通过合理的编排，这些Agent可以高效地协同工作，完成复杂的任务。

任务分配：根据任务的性质和复杂度，将任务分配给最合适的Agent。例如，在招投标场景中，大纲编写Agent负责整体框架，技术方案编写Agent负责技术细节。
责任矩阵：建立责任矩阵，明确每个Agent的职责和任务边界。这有助于避免任务重叠和遗漏。
通信共享：Agent之间需要有效的通信机制，确保信息的及时传递和共享。
动态调整：系统应具备动态调整能力，根据任务进展和环境变化调整Agent的工作状态。

设计多Agent系统的协作机制需要综合考虑任务分配、通信机制和动态调整等多个方面。

场景设计

会有不同的大文本场景，不同的大文本场景可以非常丰富多样，涵盖各种领域和用途。

比如是每个场景都适用于不同的用途：

2. 解决方案 – 提供针对特定问题的综合解决方案，包括技术、管理、市场等方面。
3. 技术方案 – 设计详细的技术实施方案，如系统架构设计、软件开发计划、硬件配置方案。
4. 论文编写 – 学术论文、研究报告、文献综述、实验结果分析。
5. 项目管理 – 项目计划书、进度报告、风险管理报告、项目总结报告。
6. 市场分析 – 市场调研报告、竞争分析、消费者行为分析、市场趋势预测。
7. 产品手册 – 产品介绍、使用说明、技术参数、维护保养指南。
   ….

这里尽量针对于每个场景设计出不同的Agent，以进行更精细化，更贴近的效果，因为每个输出在与团队路径最短的，只有团队自己或者此场景下最熟悉的人了解。

Agent设计

以招投标场景为示例。

大概会设计下面的Agent，细化可以更精准化，还有知识库更符合团队本地场景，每个场景有自己的知识库，同时每个Agent又有自己的知识库。

• 负责大纲编写的Agent：会有多个角色编写大纲，然后将大纲合成一份。
• 负责编写技术方案部分的Agent：注于技术实现方案的撰写，确保技术方案的准确性和创新性。
• 负责编写概要部分的Agent：编写文档的概要部分，确保整体连贯性。
• 负责编写项目管理的Agent：负责项目实施计划的制定，确保项目的可执行性。
• 负责编写商务服务的Agent：关注商务条款和服务承诺，提升客户满意度。
• 负责编写安装部署的Agent：负责安装部署方案的编制，确保方案的实用性。
• 负责编写售后服务的Agent：编写售后支持策略，提供全面的售后服务方案，增强客户的信任感。
• ….

上面的Agent可以理解成一个团队，然后针对这个团队的人员安排，我们这里暂时称这种为场景编排。合理的协作机制可以确保各个Agent高效地协同工作，提高系统的整体性能和可靠性。

过程中每个Agent可以替换和重新更换更好更合适的Agent，比如张三设计的更出，在实践中体验较佳，便可以切换。

集成效果

以下是一个简单的多Agent系统界面设计设计演示，首先选择和分配Agent角色，进行大纲编写，可以选择多个Agent。

编写出大纲之后，如果不符合，针对大纲进行调整或者可调整微调目录结构及符合的场景。进行内容人员编写人员选择。

内容编写界面和文档导出，167页，近10万字文本导出。

当然，也可以添加在这个场景下的特定的文档知识库，然后给各个Agent共享使用。

总结

通过合理的设计和编排，各个Agent可以高效地协同工作，提高文档的质量和一致性。特别是通过历史知识库的利用，可以有效控制文档质量，减少对个人能力和经验的依赖。

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

术语

• Agent员工指提大模型Agent，比如需求编写的智能体，现在需要进一步的结合真实业务场景
• 数据资产是为企业或个人带来经济利益的数据资源。它不仅包括数据本身的质量和特征，还涉及数据的应用场景和使用方式。

概述

在找到更合适的方法论前，暂时以此方法论进行结合落地

随着企业数字化转型的不断推进，智能体在提高工作效率、降低运营成本方面展现出巨大潜力。数据资产作为企业的核心资源之一，正逐渐成为提升竞争力的关键因素。

以下为员工能力复制过程:

本文旨在更好地结合Agent员工与数据资产来克服现有挑战，以及这种结合能够带来的价值。每个架构思设计不一，我有我思。

为什么要结合一起

在实Agent员工落地过程中，尽管已有自定义的智能体平台支持数字员工或Agent的落地，但其在真实业务场景中的表现并不尽如人意，遇到的比如：

1. 落地思路模糊：很多企业尚未形成一套成熟的方法论指导Agent员工的应用，其作用发挥受限。
2. 应用场景贴合度不高：部分解决方案过于通用化，未能充分考虑到具体行业的特殊需求。
3. 执行效果欠佳：由于缺乏足够的数据资产或者不恰当的设计，某些Agent可能无法准确理解用户意图或完成复杂任务。

现阶段已经有自定义的智能体平台，进行一步的数字员工或者说Agent落地。

1. Agent员工落地思路不够明确，执行结果不理想，与真实业务场景结合不理想
2. 需要更统一的结合思想，Agent员工落地的指导思想，需要更明确的落地思想。
3. Agent与数据资产结合，同岗位结合很产生数据价值

大致的设计流程如下:

• 构建经验沉淀知识库：收集并整理各个岗位上的宝贵经验，将其转化为结构化的信息存储起来。例如，在IT运维领域内，关于不同规模服务器集群的最佳实践指南便属于此类资源。
• 数据资产化处理：利用先进的数据分析技术对积累下来的知识进行深加工，提炼出其中蕴含的价值点，从而形成真正意义上的“数据资产”。
• 整合进Agent体系：把这些经过精心准备的数据资产融入至Agent员工的核心逻辑之中，使其能够更好地服务于特定行业或职能领域内的用户群体。

以体现Agent员工的价值和意义，也体现数据资产的价值(甚至能形成以Agent为载体的数据交易)。

从经验到数据资产

需要考虑将Agent员工同数据资产管理相结合的方法论。这样不仅可以优化现有的工作模式，还能进一步释放数据背后隐藏的巨大潜力。通过这种方式，
我们可以构建一个更加灵活高效的运营体系，使得企业在快速变化的市场环境中保持竞争优势。

知识库建设

• 经验积累：首先，需要收集并整理各个岗位上的实践经验。这些信息通常以文档形式存在于企业内部，比如最佳实践手册、故障排除指南等。
• 结构化处理：接着，通过自然语言处理（NLP）、机器学习等技术手段将非结构化的文本资料转化为易于理解和检索的形式。
• 建立关联：为每条记录添加适当的标签或元数据，便于后续查询时能够快速定位相关内容。
• 持续更新：确保该数据库随着时间推移得到及时维护，反映最新的技术和行业趋势。

比如一个简单的场景：

现在需要系统部署规划角色，要求是针对于某个业务场景下：

• 针对简单服务器的划分怎么处理
• 针对内网外网，中间安全网络怎么划分
• 针对百万、千万、分布式服务器资源怎么划分
• 针对高并发、单机、信创网络非容器场景怎么划分
• 针对于k8s、容器化场景下怎么划分资源
• ….

将上面经验中形成数字化，资产化，将前期的经验形成资产化进行沉淀，梳理形成数据资产，再进一步的结合Agent，形成原岗位角色的能力复制（或者说分身）。

数据资产建设

在将Agent员工与业务场景紧密结合的过程中，构建一数据资产体系。以下是数据从采集到加工再到输出为数据资产的主要步骤。

1. 数据采集

• 多源整合：确定并整合来自不同渠道的数据源，包括内部系统（如ERP、CRM）、日志文件、外部API以及公开可用的数据集等。这些数据可以涵盖操作记录、用户反馈、性能指标等多个维度。
• 自动化收集：利用ETL工具或其他数据集成解决方案实现数据的自动收集和同步。确保数据能够定时更新，并且保持最新状态，以便于后续处理和分析。

2. 数据清洗与预处理

• 质量保证：对收集到的数据进行清洗，包括去除重复项、填充缺失值、修复错误信息等。通过设定数据清洗规则来保证数据的一致性和准确性。
• 标准化处理：将数据转换成统一的格式，例如日期时间戳的格式化、数值范围的归一化等。同时，对文本数据执行分词、停用词过滤等自然语言处理任务，使其更适合后续使用。

3. 知识库建设

• 经验积累：整理各个岗位上的实践经验，将文档形式的最佳实践手册、故障排除指南等信息纳入知识库中。
• 建立关联：为每条记录添加适当的标签或元数据，便于快速定位相关内容。同时，利用图数据库等技术表达知识点之间的关系，增强搜索的相关性。
• 持续更新：定期维护知识库，确保其反映最新的技术和行业趋势。设立专门团队负责知识库的管理和更新工作。

4. 数据资产管理平台

• 集中存储：构建一个中央数据仓库或数据湖，用于存储经过处理后的所有数据资产。这有助于提供一个统一的数据访问入口，方便管理和查询。
• 权限管理：设置不同的访问权限，确保敏感信息的安全。根据不同角色的需求分配相应的读写权限，以保护数据资产不被滥用。
• 资产管理：维护详细的元数据信息，包括数据来源、处理过程、更新频率等。这有助于提高数据透明度，便于审计和合规检查。

智能化应用开发

• 定制化服务：基于构建好的知识库开发出符合特定需求的服务模块。例如，针对IT运维部门可提供故障诊断、性能优化等方面的辅助决策支持。
• 交互界面设计：创建友好直观的用户界面，让用户能够轻松地与系统互动，获取所需的信息或完成相关任务。
• 自我进化机制：引入强化学习算法让Agent能够在实际使用过程中不断学习改进，从而提供更精准的服务。
• 安全性考量：考虑到敏感数据的安全性问题，在整个过程中采取严格的数据保护措施，防止未授权访问或泄露事件发生。

产品原型

由于界面有限，这里只是展示部分设计界面。

下面是针对于运营需要的产品原型，建立的各个Agent角色，这里主要是为了更好的进行产品演示。

多Agent角色之间的交互模式，通过进一步的驱动业务推进

从数据采集到数据加工再到数据资产的输出。

调试串起来的结合情况，下面以内容输出产品运营示例，建立内容运营频道，由Agent员工输出内容：

添加调整数据之后，进一步的发布到内容运营平台，结合自媒体做运营管理。

总结

以上为通过加强Agent员工与数据资产之间的联系来促进前者在业务环境中的运用思路和设计，当前在进行Agent员工的调试和设计中，也期待能有机会与其他同学就此话题展开讨论。

软件工程师罗小东，多年架构和平台产品设计经验，以下为做开源智能体平台(AIP)的构建工具选型过程。

概述

自动化过程中，持续集成工具一直是扮演着核心的位置，是软件的基础设施之一，类似于称手的工具还有习惯会影响效率，以下为研发AIP智能体平台过程中，CICD工具的考虑和迁移情况。
这里工具的使用有一个背景，并不是每个团队都合适，以下为当前的背景：

• 稳定性：基础设施之一，要求稳定性高
• 微小团队：使用人数少
• 低成本：成本尽量最小化，薅羊毛思维
• 敏捷：构建速度要快，效果快
• 兼容性：可以在不同CICD工具兼容
• 可复制：微服务拆分，大同小异
• ….

总的来说，就是稳定、减少成本、构建快、快速迁移快。

这里使用的工具对比主要从以下三个工具使用情况的迁移还有对比：

• Jenkins: 开源持续集成工具
• GithubAction: Github持续集成工具
• CodeUp流水线：阿里Codeup中的流水线

项目从1-3的迁移过程中的一些使用经验及总结，当然还有其它工具(比如gitlab），每个团队工具使用不一，而且场景不一，得到的总结效果也不一，这里偏于客观中带有主观经验分享。

使用过程

经验以直接说明为主，从过程中体验和优势和劣势进行阐述说明。

Jenkins使用

这个是开始的选择，接触的公司也一直在使用这个。
但是随着项目过程构建工程的变多，服务器要求也会更高，稳定性还有维护成本更高，成本支出是一项问题。当前构建任务大概是接近百个（工程、运维、备份等），而且随着自动化程度的集成，会更多构建任务。

兼容性

以下为构建前后端的脚本：

这里执行流程尽量简单。

优势

• 私有化程度高：可以在内部服务器上完全私有地部署，这意味着你可以全面控制数据的存储位置以及如何处理这些数据。这对于那些需要遵守严格数据保护法规或希望保持知识产权安全的企业来说非常关键。
• 工具集成度高：拥有一个庞大的插件生态系统，几乎可以与任何你想要集成的开发工具进行对接，比如Git、Docker、Maven等。这使得它非常适合用于构建复杂的CI/CD流程。
• 分布式构建支持：支持分布式构建环境（即Master-Slave架构），允许在多台机器上并行执行任务，从而显著提高大型项目的构建速度和效率。

劣势

• 维护成本：尽管Jenkins是开源且免费使用的，但它的安装、配置、升级及日常维护工作可能相对复杂，特别是对于小型团队而言，可能需要专门的技术人员来负责管理。
• 升级成本高：随着新版本不断发布，为了获取最新的功能和修复已知的安全漏洞，定期更新Jenkins变得必要。然而，升级过程有时并不简单，尤其是在高度定制化的环境中，可能会遇到兼容性问题。
• 安全性考量：虽然Jenkins本身提供了许多安全设置选项，但由于其开放性以及广泛使用的插件体系，如果没有妥善配置安全策略，则存在被攻击的风险。此外，一些第三方插件的质量参差不齐，也可能成为潜在的安全隐患。

总结

适合那些对定制化需求较高、愿意投入资源进行管理和维护的大中型企业。其广泛的社区支持和丰富的插件库使其能够满足大多数自动化测试、构建、部署等方面的需求。

但对于AIP微小团队人员一说并不想持续工具上投入过多，连维护都不想考虑，研发人员最好忘记有这个工具的存在更好。

Github Action 使用

这里暂时不考虑搭梯子的情况。

大公司维护的产品，功能还有稳定性上是满足，插件工具集成也高，对开源项目免费，比较符合。自动化的构建及邮件通知，多种安全代码检测都有，这些针对于开源项目都是免费的，很长一段时间，只需要同步代码即可，CICD的事情基本上不用过于考虑。

兼容性

以下为构建前后端的脚本：

工程基本上可以做到不动，调整CICD脚本即可。

优势

• 大公司维护：由GitHub官方支持和维护，这意味着它能够得到持续的更新和技术支持。对于依赖稳定性和可靠性的项目来说，这一点尤为重要。
• 使用体验良好：界面直观友好，文档详尽且易于理解，即使是CI/CD新手也能快速上手。
• 高稳定性：作为GitHub的核心服务之一，其性能表现相当稳定，减少了因平台问题导致构建失败的可能性。
• 丰富的集成选项：拥有大量的预定义Actions（动作），可以直接用于常见的开发任务，如代码质量检查、自动化测试等，并且很容易与各种第三方服务集成。
• 对开源项目友好：对于公共仓库或开源项目，GitHub Actions提供了免费的执行分钟数，这对于促进开源社区的发展非常有利。

劣势

• 速度较慢：国内环境下，可能会遇到队列等待时间较长的问题。此外，由于服务器分布在全球各地，某些地区的网络延迟也可能影响整体运行效率。
• 隐私与安全：虽然GitHub本身采取了多种措施来确保数据的安全性，但是你很难确保人为的不安全性行为，长期久了总会有人为疏忽概率。

总结

GithubAction有很多集成的好的工具，包括GithubPage等，但是有两个致命的因素一个是慢，另一个是安全，首先慢这个是体验性最为困难的。
另外的安全性并非说工具的安全，而是人为的操作不小心，导致日志或者其它地方的不安全因素（至少有个安全处理的过滤阶段）。

CodeUp流水线

这个是新迁移工具的使用，还有迁移中，没迁移完成，

兼容性

以下为构建前后端的脚本：

脚本会有一些较大的改动，可能使用还不熟悉，但是总的来说，使用体验会比GithubAction好一些，稳定性还在验证和体验。

优势

• 国内环境友好：网络环境进行了优化，可以提供更加稳定的连接和服务，这对于位于中国的团队来说是一个显著的优势。
• 私有化支持：允许在阿里云上创建私有的代码仓库和构建环境，确保敏感信息不会泄露到外部，适合对数据安全有较高要求的企业使用。
• 免费额度：对于小规模或初创团队而言，CodeUp提供了基本的免费服务层级，有助于减少初期投入成本。
• 与阿里云生态集成：能够无缝对接其他阿里云服务（如对象存储OSS、ECS等），简化了从开发到部署整个流程中的操作步骤。

劣势

• 工具集成度有限：相比于Jenkins或GitHub Actions，CodeUp提供的预置Action数量较少，可能需要更多自定义脚本来实现特定功能。这增加了学习曲线，并且在某些情况下可能导致效率降低。
• 文档和支持资源相对不足：由于推出时间较晚，关于CodeUp流水线的文章、教程以及社区讨论内容还不够丰富。用户往往需要自行探索如何最佳利用该平台的各种特性，这可能会影响到快速解决问题的能力。

总结

适用于那些希望在国内拥有良好性能表现同时又注重隐私保护的小型至中型企业。它在工具多样性和全球范围内可用的支持材料方面尚存在局限性，但对于已经采用或考虑迁移到阿里云生态系统中的组织来说，不失为一个值得探索的选择。

针对于目前的团队来说，国内网络环境会更好符合情况，体验会更好，目前也还在探索，Github转变成当前备份的环境。

总结

虽然每种工具都有各自的特点，但最终的选择应当根据团队的具体情况而定。在构建智能体平台的过程中，选择合适的持续集成/持续部署(CI/CD)工具是至关重要的。基于团队对稳定性、成本控制、敏捷性以及兼容性的需求，经历阶段都有其独特的优势与局限。

每个团队工具使用不一，而且场景不一，得到的总结效果也不一，这里偏于客观中带有主观经验分享，期望有兴趣的同学可以多交流。

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

背景

智能体平台是从原来的研发平台，再到超自动化平台演化而来的，在新产品升级设计超自动化过程中，结合LLM技术而进而定位。

阐述主要是给对应的合作伙伴更加的了解AIP产品的使用场景，新来的团队成员更加清楚这个是做什么的。

概述

智能体让原来的平台进行自动的演化成长，基础能力包括以下部分：

1. 感知能力：通过传感器或其他方式获取环境信息。
2. 决策能力：基于获取的信息和内置算法进行决策。
3. 行动能力：根据决策结果采取相应行动。
4. 学习能力：从经验中学习，不断优化自身的行为策略。
5. 适应性：能够适应环境变化，调整自己的行为模式

新的智能体思路相近，为了更加明确和定位，进而形成智能体平台方向发展。以下为智能体平台的整体产品架构：

这里结合了平台思想、数据治理、技术研发、自动化运维等一系统平台结合起来。

针对场景和愿景

主要定位还是在中小微型团队，中小微团队情况比较多的是有开发能力和商务能力，给团队提供基础平台建设、架构设计和解决方案能力，以提升市场竞争能力。

业务上赋能上层业务智能体化，可结合业务定制化多种场景的智能体，在原来的业务智能化，提升业务的服务能力。

智能体平台产品设计

产品设计主要包括几大模块，用于不同的场景使用：

1. 智能体平台
   1. 智能体交互
   2. 管理平台
2. 技术底座平台
   1. 开发平台
   2. 数据治理
   3. 运维管理
   4. AI平台
   5. 运营管理

产品设计原型

整体的管理面貌，理解与智能体交互需要不断的匹配场景的工具。

智能体平台

我们先定一下术语：

1. 频道：多智能在一起是一个频道，类似于群的概念
2. ChatBot：聊天交互界面

智能体交互是对外的最终体现，也是与人交互的方式，界面相对比较简单，这里只设计了三个界面：

1. 频道市场
2. 智能体市场
3. 聊天交互

以下原型界面，这里参考了扣子的界面设计，集成多智能体交互：

这里主要还是参考的其他平台的界面设计，再点击最后进入交互界面。

智能体管理平台

这里用和管理分开。

场景是内部团队和企业，智能体的定义由管理员（或是部门/成员）进行管理。

形成统一归纳，统一建设，统一使用。

管理平台主要是智能体的设置和管理，这里跟互联网产品有些不一样，定义智能体以专业人员或是管理员为为主，每一个智能体进行优化处理。

一定要以解决业务场景为主（有用才行）。

智能体的管理由内部研发团队做管理或是外部人员管理，对团队或是企业内部以实用为主。

每个智能体会带有以下特点：

• 明确细分场景
• 明确输入输出

这样以形成交互，另外形成内部有效管理，规避发散和不统一性。

以下是智能体管理平台，包含智能体的Prompt定义和流程定义，这里主要还是以Groovy脚本为定义，还有多引用自定义工具为主，这里主要考虑的是针复杂的综合业务场景，可能更加灵活：

技术底座平台

底座机智来支撑智能体平台运作，这里涉及数据、技术、工具等，出来的智能体需要符合团队，场景，能提升效率，解放人力，提高服务水平。

底座的产品设计：

底座的设计集成包括

• 技术平台设计
• 中台架构设计
• 数据治理设计
• 智能AI集成
• DevOps设计
• 微服务设计等。

以简单为主，容易为辅，高扩张性。行情因素，同时支持国产，信创路线。

• 技术平台设计

开发平台是无法缺少的，这个主要是用于结合业务场景的对接框架，编程接口，智能体需要与各个综合治理业务系统衔接，整合。

• 数据治理平台

企业数据的处理，知识库，还有系统数据，业务数据等，数据服务输出，需要数据治理管理思维，形成企业数据资产，提供业务、智能体平台进行使用。

• 运维管理平台

系统运维管理，自动化运维机制，智能体交互，年报周报，报表，工单等，由智能体进一步的优化提升过程问题处理，处理质量，处理建议，问题自动处理等，提升服务体验。

• AI平台

这里主要是对数据采集，流媒体、NLP、OCR、开发平台等多个数据识别采集，做一些模型训练使用，便于统一管理，同时提供物理世界上的交互，比如流媒体识别，空间识别，包括一些用户画像等。

• 运营管理平台

整个智能体平台运营管理，使用管理还有各种文档输z出，教程材料等，使用情况，产品的对外综合管理等，用于平台的总体输出管理。

总的来说，底座平台提供了智能体平台的感知能力、数据能力、执行能力、反思能力、自动化能力等，综合为上层提供能力。

总结

从最初的研发平台逐步演变，并引入了先进的LLM技术，为用户带来了前所未有的智能化体验。这一平台的核心在于通过感知、决策、行动、学习以及适应等基础能力的构建，实现了平台自身的不断进化与发展。

专为中小微型团队量身定制，提供了一套完整的解决方案，从基础平台建设到架构设计，再到具体的业务场景应用，均覆盖其中。通过赋能上层业务，平台不仅能够实现业务流程的智能化改造，还能显著提升服务质量，增强企业的市场竞争力。

平台以其灵活的设计，为中小企业提供了提升效率、降低成本、优化服务的有效途径。它不仅是一个工具集，更是推动企业向智能化转型的重要力量。

软件工程师罗小东，多年架构和平台设计经验，以下为大模型交互设计，带有一定编码设计。

前言

这里针对的场景是中小型团队，尽可能低成本运用大模型提升效率的，另一个是中小团可以使用智能体团队结合业务。

目前看到的和遇到的大模型交互大部分都是聊天助理类，另一种是类似斯坦福AI小镇或是AutoGPT模式的，其他的可能就是应用型嵌入，还有概念视频类。在使用过程中发现，不稳定性，不确定结果等，很难达到自己想要的生产稳定形式。斯坦福AI小镇和AutoGPT类型原来是自己最为期望的效果，但是生产上落地还有一定的距离。

见识有限，也期望可以了解同行多一些实用性案例。

概述

原来接触大模型本身是为了解决本身遇到的问题，本身的AIGC能力和推理能力刚好符合自身的需求，这里结合了AIGC、交互、推理、自动化、大数据、RAG、微服务等作为基础，有结合ChatOPS设计思路，整合到一个频道里面。以下结合单智能体和多智能体交互通过进行整合。阐述从交互例子到智能体角色来进行说明：

1. 智能体角色定义和输入输出设计
2. 单个智能体交互和产出
3. 多智能体之前交互和产出
4. 智能体角色开发模式和例子
5. 下一步的愿景和规划设计

例子和代码统一上传到github基线，有兴趣同学可以互相交流。我有我思。

https://github.com/alinesno-infrastructure

智能体交互设计

原来设计的思路是需要灵活的设计能力满足不同场景，能结合现成的业务提升，满足自身工作需求，另一个是把自我抽取出来。

以下会结合【我】这个个体来进行例子编写，以达到更好的表达效果。

这里的我只是通用型例子

1. 智能体角色定义和输入产出设计

角色设计是基础，思想以辅助人的设计为主，形成个人的经验团队，体现超级个体的初期。

目前设计的智能体主要能力包括：

1. 针对业务场景自动生成和推理能力
2. 输入输出还有交互能力
3. AIGC的内容可以支持修改调整
4. 执行能力和输出能力
5. 长期和短期记忆还有反思能力
6. 业务频道场景调用结合能力

自动生成和推理主要是结合Prompt工程，团队RAG能力，结合LLM一起，这部基本上属于市面上比较成熟技术。

这里生成内容可以修改，明确的输入和输出，这样节点之间才可以互相通信和交互，这也是麻烦点（不是难点）之一，为了确保结果一定可用，同步需要可以修改。

执行和输出能力本身属于智能体的内部和外部的交互，这里主要是做产出设计，也是结果的体现。

角色的设计基本上大同小异，每个智能体都有自己的知识库，这里叫做记忆库，长期的保存向量库，短期保存数据库，这里还加了全文检索库。短期库会定时做反思保存长期库。

业务场景是必须项，结合解决自己或是业务场景的能力，才能真正用起来。这里增加频道的结合，可以针对这个聊天频道进行结果输出，每个频道也有自己的知识库或是记忆库。

2. 单个智能体交互和产出

单个角色的交互以结合培新题目作为例子，来进行一个简单的演示。

业务场景：

我需要出面试题目、业务题目、还有技术题目给对应的人员参考然后各个负责人做为参考，以提升团队能力。

工作痛点：

题目收集难，历史题目材料多，我找麻烦，给新人不知道在哪儿，而且一般经验人员还无法出符合不同团队，不同水平，不同经验的题目，还需要结合市场或是新的政策出题目，出来之后评审困难，文件整理麻烦，一般来来去去需要周期长，单独开发个系统过于鸡肋。

愿景期望：

1. 想要大部分都可以做这个工作
2. 快速产出结果进入评审阶段

智能体需求：

1. 能结合团队业务知识库
2. 生成各种场景题目和答案
3. 导出Excel然后下载

下面演示例子，假设我们已经导入智能体知识库，然后进一步提问智能体。

开发这里不做过多阐述，后面章节会提到

提问智能体角色，这里使用json作为交互媒介，这也是为什么说麻烦的地方，后期考虑过界面优化以体验更好一些。

不符合再进一步修改和调整，假如完成90%，也可以自己手动修改达到目标。

最后生成Excel下载：

这个时候你会发现，这些过程就会变成了一个节点，智能体他代替了我的部分工作角色。当然，如果结果不错可以给个好评，这个结果会影响到智能体反思的部分。

3. 多智能体之前交互和产出

好了，我们发现单个智能体已经可以做标准输出，多个智能体交互通信就方便了。

也考虑过类似AI小镇自然语言的进一步识别，但是考虑稳定性效率成本等

多智能体交互需要环境（可以理解成世界），频道的定义就是类似于这个环境，它一样有自己的知识库，再结合智能体本身知识库一起，也可以上传资料库。

这里的演示以自动化运维场景作为例子。

业务场景

我平时需要运维管理项目的发布，还有数据库备份，代码备份，查看项目运行情况，还有统计项目等有了这些之后，每周客户例会还要汇报各种结果，每日运行情况等。

工作痛点

项目Jenkins任务多，上千个任务项目需要找，另一个是文档导出麻烦格式编写不一，问题处理建议和历史工单需要很高经验工程师才能结合。

愿景期望

运维部分已经自动化

1. 可以理解意图，自然语言获取到制定的项目
2. 结合经验导出相关文档和处理建议

智能体需求

1. 获取到想要处理的项目
2. 获取到制定报表
3. 历史工单经验结合

这里主要为了演示多Agent效果，这里虚拟出项目管理的角色、数据库备份的角色、代码备份角色、k8s巡检角色这4个。

先将多个角色拉入到同一个频道中。先理解意图获取到指定的项目：

将任务提交给不同的角色执行，获取到报告结果

多智能体交互主要依赖json标准格式，上下文内容上需要设定和输出，其他的自动化能用原有的就使用原有的。

4. 智能体角色开发模式和例子

智能体角色开发，这里针对的场景是偏向于多业务场景。目前大概做的流程和方式：

1. 合适的业务场景梳理和细化
2. 数据采集整理
3. 智能体角色开发

前面两步各有差异，这里不做阐述。

听过智能体平台设置角色，包括基础信息，还有知识库等。

角色的开发定义了三个方法，每个角色开发类继承一个主类，下面是定义的方法类：

1. 交互
2. 修改
3. 执行

实现对应的方法即可，以下为例子：

每个场景写好自己的角色包既可以，最后进行界面调试。

每个智能体角色也可以单独对外引用，作为客服之类的，比如：

这个开源的官网集成的例子，在开源代码库中也可以找到。

5. 下一步的愿景和规划设计

这步还在验证阶段

到这步，会发现，单个和多个智能体就已经可以结合起来，也同步可以运作。我的角色变成了设计规划，还有任务安排，还有审核角色等，到这步会发现，这个更加类似于OA审核。

如果集成层智能体是执行，那下一步建设和形成的目标就是上层智能体角色，用于整体智能体角色的协调。

在多个角色场景形成自动化之后，下一步就是集成类似的智能体产出计划和任务安排给多个智能体执行，输出到结果汇合到OA系统，回退和集成。

这也是为什么不用三方类似dify等平台的原因，做可控自定义平台的原因，主要不是推翻现有业务，而是提升现有业务，场景过多和复杂，需要针对业务场景多、细、稳。

超级自动化或是全自动化这也是对下一步的愿景和期望。

总结

以上为接触大模型为了解决本身遇到的问题的整合思路和产品设计思路，每个设计师有自己的设计思路，以上为个人经验分享，期望有兴趣的同学可以多交流。