我对智能体和业务场景结合设计

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

前言

目前大模型能达到的场景和优化的效果，基本上能达到专家的效果。在微调试下回复和表达可以已经可以达到中高级产出，这里主要针对的是行业深度场景结合的设计方案。

概述

这里的设计原则依然是定位在辅助人的角色上，核心节点需要人工的确认。目前遇到的或是可以看到的基本上很多是概念视频展示不做结合参考，以市面上结果稳定输出的大模型为主。

在结合，某一行业或是场景上，需要比较大的定制化和数据调试，有成本的投入可以是三方或是自己训练行业针对性的场景，这个的成本不言而喻，中小团队无法或是很难承接。

针对这样的情况，通用大模型已经具备很强的推理能力，结合的这个来做针对话的业务场景定制，一个是降低成本，简单可维护，以提高落地能力。

阐述从这几个维度进行，分别是【业务_智能体_产品_原型】这样的思路：

1. 业务场景结合设计方案

2. 定制化智能体自我演化方案

3. 智能体产品设计方案 4. 通用智能体平台产品化演示

不同的接触层面会带来不一样的设计思路， 技术需要结合场景才有更大的意义和价值体现，每个设计人员思路不一，我有我思。

场景结合

业务本身的探索已经有多个不一样的团队在探索有很多年，一个是对行业和先前人员的努力的敬畏，结合这块并不是说要取代，而是进一步的加强，利用新技术提高和加强行业产品的服务和质量。

业务场景结合设计方案

以下是整体的业务赋能设计方案，以智能体结合业务整合作为基本设计方向：

整体的流程说明和过程设计，这里从上到上的分析：

1. 数据采集层：这个是企业或是团队的核心，也是输出推理结果的主要推理数据来源，数据的采集不仅是互联网还有团队经验，这些会形成特有的知识库；

2. 数据治理层：这些服务从数据治理的角度支持了数据的标准化、集成、开发和实时处理，确保了数据在整个生命周期内的质量、一致性和可用性，从而提升了智能体决策的准确性和业务运营的效率。

3. 智能体推理层：逻辑推理是大模型的优势之一，在大部分情况下，数据加上大模型推理会给出很理想的结果建议和方案，会比人工快得多，针对每个不一样的业务流程节点上，针对性的定制化不同业务场景的智能体，由数据采集再到逻辑的推理，给出初步的结果方案或是执行方式；

4. 业务逻辑层：以基础的智能体平台为依托，它是一个类似于员工的角色来不停的为业务的每个节点切入，不停的在业务里面深入了解和学习，还有不停的进行执行。

我们可以把上面的过程理解成雇佣关系，岗位上不停的招聘工作人员。这里的流水线就是业务场景，人员是智能体员工，它会一直吸收经验和不停作业，团队不停的招聘智能体员工，通过不断优化和增加智能工具，可以达到更高效的工作流程，直到这里的项目上最快最好的输出。

解放出来的人力就可以更加深入流程和场景结合，进一步的提高服务和产出质量。

比如工程师在开发一个功能，在设计阶段的思路提交给大模型，它就能给你产出各个模块的代码，然后我再拼凑，效率和质量都不错。这样的过程你会发现，你会更加专注于设计思考，而不是编码上。难道还为变量命名、接口测试数据、单元测试、注释等这些烦恼或是思考？工程师能够更专注于设计和创新，从而提升开发效率和代码质量，减少低级错误和重复工作。

定制化智能体自我演化方案

假如我们发现智能体员工可以处理一部分工作，那要怎么建立智能体。目前很多平台都有智能体，比如星火、千问等，你会发现做一个智能体很简单，定义 Prompt 场景和投喂数据。

目前的大模型发展上面，推理能力成熟度比较高，主要在数据上的清洗处理。我们要给智能体对应的感知能力，推理能力还有执行，仅仅是简单的向量数据是不够的。另外数据质量要求，大模型本身的限制等都是问题。

数据的采集也包含很多，包括网络的，视频，音频，日志，行为，企业数据等多种感知数据，这些过程再进一步交互采集和加工处理，针对特定数据处理，形成智能体的数据资产。

在业务逻辑上需要的是更稳定、更可控的结果。包括记忆能力，分析和自动的结合，以下为智能体演化的过程：

设计说明：

1. 数据清理：针对性的智能体员工，所采集的数据，质量，检索等都需要比较高的要求，这就对数据治理上，数据服务还有分类上面下点功夫，幸运的是，行业数据治理给了很好的基础，这个应该来说问题不大。

2. 分析能力：分析逻辑推理这个是大模型的强项，过程规避掉针对性的模型训练，使用通用大模型解决这个分析推理的问题，通过数据挖掘和推理，获取到我们想要的计划和执行要求。

3. 执行能力：执行过程工具比较多，这个也是基于研发技术，属于比较成熟的方式，结合业务场景做开发调用即可。

4. 记忆反思：在这个过程，所以的问题和记录，三方感知等会进一步的消化成经验数据，进行总结和为下一次执行做好基础，而不是海量知识库，提炼出精准知识库，为智能体发展作准备。

在这个过程你会发现，演化体系会慢慢形成，而通用大模型不断发展，也会有更好的推理能力，两者结合起来，形成特定的智能体员工，不断的积累加深。

比如写方案的场景，制定出方案目录编辑的智能体员工，专门针对不同的主题，场景定制方案目录。在初期第一个方案目录出来之后，不断的人工确认评审，修改意见收集，这些都会形成数据经验不断的积累。

下次再写类似场景方案，可以直接出对应的结果，规避掉前期的低级错误和问题，包括一些特定的要求等。

智能体产品设计方案

结合上面的设计方案，针对性的整理出来的智能体产品设计。这里产品设计思路，只要包括几个点，实现功能数据采集、处理、推理、服务、运维、运营等一套智能体平台产品，需要的是可结合生产实践的平台。

目标也是针对于中小型团队的产品能力，低成本，可维护，能落地，能见效果。以下为产品的设计方案图：

设计描述，这里从上到下的进行产品说明：

1. 数据处理层，这里可以立即成感知服务，用于多平台数据的收集，接入，清洗，分析，资产，服务等，相对来说，基本上属于中小团队的数据方法论实现。

2. 模型推理层，大模型的接入，还有 prompt 的管理优化，流程管理，智能体管理，多智能体交互，还有数据接入验证等，数据标注等一套标准平台。

3. 软件开发层，可以理解成开发层的内容，包括不限于平台的开发，接口开发调用等，主要提供软件和执行层的技术规范和方案。

4. 运营管理层，整个平台的管理体系，比如各个节点的管理和 SaaS 化，对人员提供产品力的表现，对整体智能体平台的管理。

以上是智能体平台的产品设计和研发过程总结，这个也是在研究智能体过程中的实践总结。

拿一个上面写目录的智能体来说例子，收集数据的来源可以是团队内部的规范和要求，另一个是会议纪要和记录，这些通过采集之后进入到数据仓库，在进一步的分析得到数据资产和服务，形成一个简单的 DataOps 流程。

在逻辑推理部分获取到特定的目录结果和数据格式，这些就是出来的版本。有了目录的数据针对性的开发出模版解析能力和工具，生成文档目录结构，输出发给对应人员，人员可以进一步的审批验证完善等。这些过程智能体平台会记录，进一步记录分析形成经验记录。

以下为多 Agent 协作的设计思路：

当然，也可以考虑建立一个是审核的智能体角色。

通用智能体平台产品化演示

以下为智能体平台产品的原型设计，前期是一边设计一边编码，大部分也是使用 AI 开发，这个过程你会发现，效率会快很多，基本上所想即所得的代码。

1. 智能体门户设计，包含管理入口，SaaS 化管理和组织管理。

1. 推理管理平台，形成模型的管理和角色推理逻辑和分析。

1. 数据治理体系，针对于中小型团队的数据治理方法论的落地和实践。

1. 数据资产服务，提供数据资产管理和服务管理。

1. 软件开发体系，技术研发框架和自动化设计。

这些整合在一起，主要是形成一个平台管理的概念，一套 SaaS 来进行管理。过程设计每个模块会设计成单独的服务，也就是这样的，方便形成积木类似的软件组合，其他缺少的，按接口和规范引入即可。

以下为智能体团队：

每个产品设计人员和架构师有不同的见解和思路， 这里针对的是中小团队，低成本，方便维护为主。针对结合数据整合模块，进行数据元数据和主数据的抽取上报，集中到数据仓库和数据湖，形成数据资产能力。平台能力和业务架构的体现从开放平台和新平台对外门户，形成行业业务+智能体团队沉淀，形成核心业务能力资产

同时相比于传统人员，智能体员工在业务场景中的优势包括：

1. 专注复杂任务：使人类工程师能够更多地专注于创造性和战略性的任务，而不是日常的重复性工作

2. 高效率：智能体可以快速处理大量任务，不受时间和体力限制，能够 24/7 不间断工作。

3. 一致性：智能体执行任务时能保持高度一致，减少了人为因素导致的误差。

4. 学习与优化：智能体能够通过机器学习不断提高自身性能，优化工作流程。

5. 成本效益：一旦部署完成，智能体的边际成本较低，长期来看可以节省人力成本。

6. 可扩展性：可以根据需求轻松增加或减少智能体的数量，灵活应对业务量的变化。

7. 减少人为错误：避免了因疲劳、疏忽等人类常见原因导致的错误，提高了工作的准确性。

通过高效、一致且持续优化的工作特性，能够在降低成本的同时提升业务处理的速度和准确性，使人类工程师更专注于创造性任务。

总结

以上是我在大模型结合业务场景的设计思路，在结合，某一行业或是场景上，需要比较大的定制化和数据调试，有成本的投入可以是三方或是自己训练行业针对性的场景，这个的成本不言而喻，中小团队无法或是很难承接。

这里从小团队结合场景的整体的结合思路，产品设计，还有一些建设经验，目前也是在不断的开发验证，希望可以给一些同学参考和思路。