2023年,大模型与生成式人工智能(Gen AI)席卷全球。如果你一直关注大模型,那么你一定会注意到AI Agent已经成为下一个AI前沿领域,也被普遍认为是人工智能走向AGI(通用人工智能)的必经之路。在层出不穷的大模型加持下,AI Agent已经成为众多科技巨擎布局与发力的关键领域,比如领头羊企业OpenAI刚发布不久的GPTs Builder与Assistants API正是其在AI Agent领域的最新布局,也彰显了其在这个领域的信心与野心。

尽管目前ToC领域的GPTs已经百花齐放,但暂时也没有出现颠覆式的杀手级应用以体现其潜在价值。而在2B领域,在互联网时代已经完成数字化转型的众多企业,也正在面临着新一轮的技术变革,即为生成式AI做好准备:大模型将成为企业IT中的基础设施之一,并在一系列的业务场景中得以应用并发挥潜力;而具备自主的感知、规划与工具使用能力的AI Agent智能体或许有着更强大的应用价值。

AI Agent在企业应用的场景分析

AI Agent对于企业应用的价值体现在哪里,更具体的说其在企业的应用场景在哪里?由于各个行业自身的业务特征、应用环境千差万别,很难简单罗列所有的应用场景。我们首先从价值体现、应用领域、使用对象三个不同角度去对AI Agent的企业应用场景做简单的分类:
30100732-2023-12-30T02:07:56.png
接下来我们从这几个不同的角度看未来AI Agent在企业的落地。

【价值体现】

毫无疑问,从AI Agent在企业应用的价值体现上看,都应该是围绕降本提效、改善服务、优化体验这几个核心价值点,否则也就丧失了应用的意义,所以这本身没有太多可探讨的。在这个角度,最值得关注的也是最具有不确定性的或许是如何科学衡量AI项目在企业落地与应用的真正价值与ROI?特别是在目前阶段,由于不同技术与应用的成熟度仍在发展,存在差异;而不同组织的成本敏感度、人才储备、客观条件(比如知识管理与现有IT应用的成熟度)也千差万别,因此很难单一直接的去判断一个AI场景的价值。但是在当前的技术成熟度仍然处于上升与快速迭代的阶段,我们建议的最佳实践应该是:

综合衡量并选择从应用价值明显、技术成熟度较高、工程实施简单、初期成本最可控的领域与场景开始,并保留系统架构上的扩展性,预留未来的演进空间。

【应用领域】

这里从应用领域对AI Agent在企业的常见应用作简单的总结。由于各行各业有各自的领域特征,因此这里只是选择一些目前有代表性、有原型或者实施案例的场景用作介绍与参考。这些不同的AI Agent场景,由于以下几个方面的差异,会导致企业在落地该场景的AI项目时的成熟度与风险有区别:
30100750-2023-12-30T02:08:15.png

  • 所依赖的模型能力不同。比如:
    基于私有知识的问答需要依赖于向量模型、语义检索。
    数据分析则需要依赖于大模型的代码生成、Text2SQL等能力。
    与企业应用集成的Agent需要依赖于模型自身规划与使用API/工具的能力。
  • 对企业自身数据与应用的要求不同。比如:
    基于私有知识的问答应用很大程度上要依赖企业自身知识管理的完备性。
    自动化业务流程的Agent则要求企业应用有完备的API接口体系。
    办公助理Agent需要企业的协同办公平台具有开放的接口或插件支持。
  • 场景的业务流程复杂度不同。比如:
    简单知识问答形态的Agent几乎不涉及很复杂的业务流程。
    一次销售/服务Agent的流程中则可能需要和CRM等应用作多次交互。
    市场研究与分析的Agent则可能需要借助外部平台来获取最新数据。
  • 工程化要求(性能、准确性等)不同。比如:
    在辅助创作与生成的场景中对大模型输出的容忍度相对更高。
    在数据分析场景中则要求模型输出结果具有最高的准确性。
    在应用集成时则要求模型能准确推理工具使用需求并提取输入参数。

基于这些差异性,我们对企业常见的Agent场景做总结,并简单区分其实施成熟度用作参考:
30100910-2023-12-30T02:09:33.png

【使用对象】

与AI Agent在企业中产生直接交互的对象可以分成三类:
一类是直接面向企业的外部客户等服务对象。这类场景下,使用者通过自然语言与AI Agent对话,Agent完成任务给出响应。比如在线智能客服、在线咨询等。
一类是直接面向公司内部使用者,包括普通员工、数据分析员、决策管理人员等。同样,使用者通过自然语言UI与Agent协作交互并完成任务。比如内部办公助手、交互式数据分析等。
还有一类特殊的Agent使用方式,是将Agent的能力嵌入与集成到其他应用之中。在这类场景中,Agent不直接与“人”产生交互,而是由其他企业应用来触发,并借助Prompt完成自动化任务。比如:在CRM系统中发现一条新的销售线索后由Agent自动创作个性化的营销方案并推送;线上商店产生一条订单后由Agent自动审核并完成物流下单等后续流程。

从使用对象角度看,为了尽量降低对企业生产的影响与风险,AI Agent应用的落地可以优先考虑从后两种类型的部分场景开始。

AI Agent在企业应用的整体架构

从前面的场景分析中我们也能看到,企业中AI Agent的落地通常不是一个独立的简单工具项目(这是与ToC的AI Agent的最大区别)。因此,也给现有企业IT的基础设施与架构带来了新的挑战:

  • 可能需要部署与连接多种不同规模、能力的AI基础模型
  • 必须与企业当前的数据与应用做标准化的、可扩展的集成
  • 为了拓展Agent能力,可能需要借助开放API扩展其工具库
  • 需要引入新的基础设施,比如向量库用以实现语义检索
  • 面临新的大模型设施的运维管理需求

我们用两个具体场景来认识企业Agent应用的复杂性与对架构的要求。比如下面是一个设想的HR简历筛选助手的场景,可以看到,这样一个自动化处理的流程中,Agent需要能够灵活借助外部工具完成整个过程。
30100935-2023-12-30T02:10:00.png
再比如下面这个在线销售助手的场景,借助于大模型的能力,并与现有的CRM模块、企业知识库等集成,可以智能的完成在线产品咨询与预订过程。
30100941-2023-12-30T02:10:06.png
显然,你的IT架构需要升级以将大模型与企业内部应用、开放工具等集成起来,构建Agent访问企业内部数据的管道,并能具备足够的弹性满足未来扩展的需要。好在随着大模型的发展,相关的配套框架与工具也在不断演化与成熟,这些大模型的开发设施可以显著的帮助减少工作量,并应用最佳实践以降低风险。我们构建一个相对通用的AI Agent在企业应用的总体架构:
30100949-2023-12-30T02:10:14.png
在这个总体架构中的引入的新的关键要素包括:

1. 大模型

包括大语言模型、嵌入模型以及逐渐发展的多模态模型,这些基础模型作为企业的AI基础设施与能力而存在。具体可以分为商业闭源大模型(比如ChatGPT,Gemini,通过API访问)、开源大模型(可以借助Model-hub平台进行部署与API访问,比如Llama)、私有大模型(借助开源模型做微调并私有化部署,首次投入成本较高)。由于不同Agent对模型能力要求的差异,单个模型很可能无法满足更多场景使用要求,构建一个统一的大模型访问API层,实现多模型统一访问并可灵活切换是有必要的。

2. 数据管理

区分于企业现有应用的生产数据,Agent的独立数据区用于存取Agent管理与运行过程中的各种中间与持久数据,包括结构化与非结构化知识文档、向量数据库、分析数据、消息历史、日志数据等,并提供必需的数据维护与管理工具,如私有知识数据的清洗、向量化、导入导出等。

3. 大模型运维管理

具体来说应该包括LLM以及构建在LLM之上的各类Agent的运维管理,这包括了在应用生命周期不同阶段的管理工作。包括:

  • 配置:比如LLM输入的Prompt提示词、外部工具配置、Agent工作流配置、环境配置等。
  • 测试:大模型与Agent应用的测试。模型连通性、向量搜索测试、Agent状态测试、Agent性能测试等。
  • 评估:由于输出的不确定性,在大模型应用投入生产之前的评估非常重要,借助于一些框架可以对AI输出的准确性、相关性、合规性等做综合评估。
  • 部署:对模型与Agent的构建、部署与升级流程做自动化管理的过程。
  • 监控:对模型与Agent运行状态与结果进行跟踪监控。包括连通性、响应性能、数据安全性等。还有一个很重要的优化工作,即通过用户反馈搜集与分析来持续优化大模型或者提示工程。

4. Agent智能体

开发框架层:用于大模型应用开发的一系列开源的开发与编排框架、工具与平台。借助于这些工具,可以大大简化上游AI Agent构建的复杂度与工作量,并降低风险。常见的开发框架包括:LangChain、LLmaIndex、AutoGen、SuperAGI等。

AI Agent层:基于开发框架之上构建的真实投入应用的AI Agent。一方面,Agent通过API或代码解释器与内外部应用协作完成任务,另一方面,Agent本身通过API向前后端企业应用开放接口,以嵌入与集成到企业业务流程中,比如你可能需要集成一个AI Agent到企业微信/钉钉群来解答员工或者客户的问题。

这里我们根据常见企业应用中AI Agent的不同技术特点,把他们分成几类助手(由于内容创作与生成类的助手相对独立,更多时候体现ToC特征,这里我们不再列出):
30101014-2023-12-30T02:10:39.png
这里不同类型的助手在技术特征与实现工具上都有较大的区别,有的依赖向量技术,有的依赖大模型的Tools能力,有的需要借助代码解释器等,我们将在后续的文章中继续探讨。