ToB-LLMs：应用发展、技术路径、平台工具

在上篇文章大模型应用方案升级实践与思考中可以谈到大模型的应用升级之路Prompt -> RAG -> Copilot -> 单体/群体Agent。

在上文的基础上，本次聊聊针对ToB-LLMs的应用场景发展、技术路径展示和平台工具设计思路。

限于个人眼界、学识必定有缺陷、不足和错误，部分观点更是个人看法，仅供参考，欢迎交流指正。

先说结论：

• 在业务应用层面：实现由点到线，由线到面，由面到体构建企业全局业务Agent；
• 在技术实现层面：实现按照业务调用顺序搭建组件工作流，及工作流嵌套，进而上升到单体Agent、群体Agent、多个群体Agent，从而实现全面自动化和智能化；
• 在工具设计层面：实现原子化、组件化、通用化

LLMs应用场景变化趋势

由点到线，由线到面，由面到体构建企业全局业务Agent

目前大模型最主要的交互形态是对话形式，所以应用工具的建设思路还是围绕对话形式展开，在对话中管理业务场景任务，将任务执行组件融合在对话管理中，通过对话与改进技能进行交互。

通过业务技能组件流组装，选择合适的技能流创建一个对话，在对会话中，用户与改技能进行对话交互，从而获取目标结果。

在ToB领域中，应用场景升级可以分为3步走：私有知识库问答、业务流程报告生成、业务流程自动化：

• 私有知识库问答：从私有数据、文件等结构化、非结构化数据中提取关键数据，进而对用户的问题提供查询结果和推理分析结果，主要面向单点问题、持续深入类问题。如：企业年报问答指标提取、公司规章制度问答、产品使用说明问答、数据库查询、特定角色对话等场景。（单点业务场景）

• 业务流程报告生成：将有固定分析思路和维度的业务场景提炼，调用各类型的工具进行信息提取，设置业务流程，进行报告生成。如：营销策略和方案生成、项目合同生成、文件内容摘要生成、信贷调查报告和能成。（单链条业务场景）

• 业务流程自动化：涉及数据、知识的录入、规范化的流程处理和结果推理，当触发条件到来时，调用企业一系列数据、工具、系统进行自主自动规范操作。（全局业务场景）

LLMs应用技术迭代路线

按照业务调用顺序搭建组件工作流，及工作流嵌套，进而上升到单体Agent、群体Agent、多个群体Agent，从而实现全面自动化和智能化

为了达到业务目标，需要通过不同单元来处理不同的业务部分，那么就需要用到不同类型的数据、平台、工具、系统、计算等能力组件进行组装，是原子业务处理能力的组装。

通过组装实现业务工作流、工具链，涉及到复杂的业务甚至需要不同工作流的共同努力。业务目标是一个终极任务，需要对任务解析、方案制定、任务匹配、任务分发、结果整合、反馈循环形成闭环处理能力。

以上是对相对固定的业务场景进行处理，那么如果需要对流程相对不固定的业务场景如何处理？流程不固定的业务场景可能涉及的问题就非常多了，比如：问题分析、解决方案设计、资源协调、风险管理、沟通协调、决策制定、执行监控、合规检查、知识管理等。

单纯通过固定的工作流、工作链就难以处理了，需要上升到Agent层面，通过单角色的Agent来处理问题无法全面去考虑问题，比如：在软件产品设计工作中，产品经理更多的考虑产品的问题，无法深入考虑研发的问题、运维的问题，就需要引入团队式Agent，团队Agent中融入各种各样的角色来更全面的讨论问题，处理问题。

但是，一款软件产品的研发不只是产研团队的问题，还要考虑目标客户群体、公司决策层、销售团队、运营团队、财务团队等，那么为了最终目标达成，就需要引入多个团队式Agent，也就是多群体Agent的讨论制定方案，从而做出决策，获得最终结果。

所以，整体的发展路径从固定场景的精准可控工具链、工作流到单体Agent、群体Agent、多个群体Agent实现由点到线，由线到面，由面到体构建企业全局业务智能化

LLMs应用平台工具设计实现路径

在工具设计层面：实现原子化、组件化、通用化

通过对业务实现层面和技术实现层面讨论的基础上，再看平台工具层面设计框架，想要更快、更方便的搭建服务于给累业务场景的平台工具，要考虑几个方面：

首先，要解决的就是数据的加载、处理和存储，构建私有知识库。加载各类数据来源中的数据，包括：Word、PPT、Excel、PDF等等（数据装载器）；针对大模型上下文长度有限需要对文档进行分割，获取直接有效的背景信息（文本分割器）；对分割后的文本需要进行语义检索，所以要将文本转化成向量（文本嵌入器）；进而需要把转化后的向量进行存储（向量存储器）；

其次，需要集成各类LLMs和prompt结构，不同模型的优势能力不同，为了提供高效、高质量、低成本的应用效果，进而从调用单个大模型能力转为调用多个大模型能力（语言模型器）；Prompt是调用大模型生态能力的接口，所有被用于模型预测输出结果的内容，都是Prompt。为了更好的调用大模型生态的能力，设计优秀的prompt结构和策略，为应用提供良好稳定的性能表现（Prompt组装器）。

为大模型提供取用丰富的脚手架工具提高能力边界，不同的业务场景有不同的工具及外界环境，但所有的工具都是为了获取丰富准确的背景知识、多样化的内外环境系统交互能力。包括：私有知识检索器、脚手架工具器、实时数据获取器、内外系统交互器、交互信息记忆器。

以上都是处理组件，属于中间层，整体架构应该包含三层：输入层、中间层、输出层，当然还要涉及（输入输出处理器），用来接受文本输入和上传文件；以及（输出内容解析器），将模型输出流程中的内容解析为结构化数据，帮助数据流转过程中的机器识别。

最后就是针对任务进行处理的工作流/链以及Agent层，将整体的任务串联起来的任务解析、方案制定、任务匹配、任务分发、结果整合、反馈循环。按照指定顺序、流程调用不同的各环节组件（工作流/链组装器），还可用LLMs来决定如何调用不同的组件，能够自主完成多样化复杂问题的拆解规划与子问题的解决（Agent处理器：单体Agent、群体Agent、多个群体Agent）；

最后

最终通过平台工具层面的原子化、组件化、通用化，实现从调用单个大模型能力转为调用多个大模型能力、从调用单个工具到调用整个工具链，从调用单个Agent到调用整个Agent生态能力，从服务单个场景到服务整个业务链。