Agentic AI在企业流程中的生命周期

作者

 

1. 引言

关于ChatGPT（或者更广义的generative AI）的讨论，如今已经演变成了agentic AI。ChatGPT主要是个能生成文本回复的chatbot，而AI代理则能自主执行复杂任务，比如完成一笔销售、规划一次旅行、预订机票、雇佣承包商干家务活，甚至点个披萨。下面的图表展示了agentic AI系统的演变。



比尔·盖茨最近设想了一个未来：我们将拥有一个能处理自然语言、完成多种任务的AI代理。以旅行规划为例，传统上你得自己订酒店、机票、餐厅等。但AI代理能根据你的喜好，替你搞定这些预订和购买。

简单来说，AI代理之所以火爆，是因为它们理论上可以应用于任何目前靠人工执行的企业流程。

所以，我们基本上可以把从客户服务台到工业流程（比如HVAC优化），甚至用代理来构建底层的software、data和ML engineering pipelines，统统“代理化”。为了实现这种agentification（代理化），我们需要一门全新的综合学科，覆盖agentic AI的整个生命周期，从：

  • • 捕获agentic用例需求
  • • 到设计代理（一个好的代理层级结构长啥样？适用的agentic技能和工具又有哪些？）
  • • 到在agentic平台上实现安全、可扩展的部署
  • • 再到这些代理的治理和维护

在agentification过程中，有几点原则要牢记：

  • • 人们往往倾向于将手动流程一对一映射到agentic流程上，这其实效率不高。设计者得记住，代理不受限于HR流程之类的东西 🙂 所以软件代理能干不同的事，而且干的方式也跟人类不一样。
  • • 但与此同时，就像人类在安全链条中是薄弱环节一样，一个代理也可能搞砸整个执行流程。所以不能有例外，也不知道要是代理“叛变”了该怪谁、罚谁、开除谁。因此，建议对所有代理都以最高标准设计，配备logging、observability和responsible AI guardrails。

接下来，我们将深入探讨agentification流程。第2节会介绍agentic生命周期及其不同阶段。第3节会概述支持这些生命周期阶段的agentic AI平台的参考架构。第4节会展示两个案例研究，分别应用agentification来运行客户服务台（4.1节）和进行data platform management（4.2节，包括data cataloging和data engineering pipelines）。

2. Agentic AI生命周期管理

构建和运行AI代理的典型阶段如图2所示。


首先，得定义用例：包括明确问题陈述、理解业务背景、data requirements和availability，以及为agentic AI解决方案设定清晰的目标，量化return-on-investment (RoI)。

其次，我们需要一个reasoning models / large language models (LLMs)、代理和工具的市场。现成的企业工具整合和动态定义代理在实践中效果不太好 🙂

比如，Agent2Agent (A2A)协议提出了Agent Card的概念（一个JSON文档），就像代理的数字“名片”。它包含以下关键信息：

  • • Identity：名称、描述、提供者信息。
  • • Service Endpoint：A2A服务的访问URL。
  • • A2A Capabilities：支持的协议功能，比如streaming或pushNotifications。
  • • Authentication：与代理交互所需的认证方式（比如“Bearer”、“OAuth2”）。
  • • Skills：代理能执行的具体任务或功能列表（AgentSkill对象），包括id、名称、描述、inputModes、outputModes和示例。

客户端代理可以通过解析Agent Card来发现远程代理，判断是否适合某个任务，如何组织技能请求，以及如何安全通信。

类似地，Model Context Protocol (MCP)通过mcp:// URIs提供动态工具发现机制，代理可以解析并获取工具能力、需求和交互方法的元数据信息。

A2A和MCP都基于文本/自然语言描述的代理和工具。在我之前的一篇论文中，我提到这种方式可能不够，需要更正式的capabilities/constraints-based discovery model来实现精准、自动化的工具和代理发现。

第三步，设计agentic logic（实现目标的计划）。这里得区分deterministic和autonomous代理，它们的设计和执行方式差别很大。

对于deterministic代理，主要是静态定义一个orchestration schema，预先确定代理和工具。而autonomous代理只需将用例目标作为prompt给到LLM/reasoning model，planner会动态制定执行计划，并根据memory中的观察动态调整计划。

第四步，优化代理的部署用于inferencing。由于generative AI和LLMs的体量巨大，之前大家很关注优化/quantizing LLMs到small language models (SLMs)。但鉴于目前代理多聚焦于企业工作流，这块似乎被暂时搁置了。

我相信，一旦更多代理投入生产，cost optimization和power efficiency会重新成为焦点。

所以这一阶段得主动思考优化agentic部署，甚至让它们能跑在edge devices上。更多细节可以参考我之前的文章《Agentic AI Inference Sizing》。

最后，讨论governance layer。说实话，没有这一层，任何代理都不可能在企业中投入生产，也不应该被允许这样做。比如，JP Morgan的CISO在一封广为流传的信中就强调需要安全、弹性的agentic架构。

Guardrails也在agentic AI生态中成为一级公民，比如OpenAI的Agent SDK发布。总之，end-to-end observability不仅对代理卡壳的场景恢复至关重要，还得有rollback策略应对代理偏离剧本的情况。

简单来说，关键点是：在生产环境中构建可靠、可信的代理，远不止写几行代码那么简单 -:)

3. Agentic AI参考架构

图3展示了支持前述生命周期阶段的agentic AI平台的关键组件：

  • • 代理（和工具）marketplace
  • • Planner（推理层）
  • • Personalization layer
  • • Orchestration layer
  • • Observability layer（包含logging、checkpointing等）
  • • Integration layer（与企业系统整合）
  • • Shared memory layer（长期和短期记忆）


给定一个用户任务，我们会prompt一个LLM进行task decomposition——这跟generative AI有重叠。但这也意味着，当前agentic AI系统受限于LLMs的reasoning能力。比如，GPT4对以下prompt的分解如图4所示：

生成一个定制的email campaign，实现1个月内100万美元的销售。适用产品及其performance metrics在[url]中。连接到CRM系统[integration]获取客户姓名、邮箱和demographic details。

分解为：（分析产品）—（识别目标受众）—（创建定制email campaign）。


LLM会监控执行/环境，必要时自主调整。在这个例子中，代理发现无法实现销售目标，自主增加了任务：（寻找替代产品）—（利用客户数据个性化邮件）—（进行A/B testing）。

这就引出了personalization layer的需求。类似于fine-tuning LLMs到特定领域的SLMs，我们认为，针对企业特定context（适用用户persona和用例）对通用AI代理进行customization/fine-tuning，才能推动其企业采用。

图5展示了基于user persona fine-tuning AI代理的参考架构。更多细节见我之前的文章《Personalizing UX for Agentic AI》。


鉴于需要orchestrate多个代理，integration layer得支持不同的代理交互模式，比如agent-to-agent API、代理API为人类提供输出、人类触发AI代理、AI代理与人类的交互loop。这些模式需由底层的AgentOps平台支持。

值得一提的是，大多数用例都需要与企业系统（比如这里的CRM）整合。这可以通过MCP动态连接工具到企业数据所在系统来实现。

考虑到这类复杂任务的长期运行特性，memory management对agentic AI系统至关重要。初始email campaign启动后，代理需监控1个月。这涉及任务间context sharing和长期执行context的维护。

标准做法是将代理信息的embedding表示存储到vector store数据库，支持maximum inner product search (MIPS)。为快速检索，使用approximate nearest neighbors (ANN)算法，返回近似top k-nearest neighbors，牺牲一点准确性换取巨大速度提升。

图6展示了agentic AI系统的全面memory management，包括短期和长期记忆模块。更多细节见我之前的文章《Long-term Memory for Agentic AI》。


4. Agentification案例研究

4.1 客户服务台

本节展示如何用AI代理重新设计典型的客户服务台（见图7），通过更高效、个性化的服务为终端用户带来业务价值。


在今天的contact center，knowledge base (KB) article/standard operating procedure (SOP)定义了人类代理执行的系统化工作流程，基本上是一套预定义的、解决常见客户问题的逐步指令。

图8展示了第3节中的agentic AI平台参考架构，适配于执行客户服务台特定任务。用户和数据交互步骤都可以用augmented LLMs（结合scripts、APIs和UI/UX）自动化。


LLMs可以生成用户问题、解释用户输入、提取相关信息，并生成状态消息和确认。APIs可用于检索结构化和非结构化数据，reasoning LLM则利用数据决定下一步。

KB article/SOP可视为directed acyclic graph (DAG)，每个节点代表一个步骤，边代表可能的分支（结果/下一步）。

我们假设存在AI代理的KB article repository，每一步包含以下细节：

  • • action_id：要执行的步骤标识。
  • • action_type：动作类型，比如api_call、get_user_input、retrieve_ext_knowledge。
  • • action_metadata：对于get_user_input，包含用户预期输入或传达给用户的消息；对于api_call，包含API端点及所需输入参数。

基于LLMs的代理可以自主执行KB article中的步骤。相关的客户服务台代理包括：

  • • Customer Agent
  • • Product Agent
  • • SLA Agent
  • • Personalization Agent
  • • Responsible AI Agent
  • • Audio (Speech) Agent
  • • RAG based KB Retrieval Agent
  • • (Gen AI based) Email Response Generation Agent

4.2 数据管理/数据工程

本节展示如何将agentic AI应用于data platform management的两个核心流程：data cataloging和data engineering（warehousing），并概述相关任务特定AI代理。

图9展示了重新设计的agentic流程，捕获关键任务：

  • • 自动化data pipelines（ingestion、modeling、transformation）；
  • • 用AI驱动的政策执行实现governance & compliance；
  • • 启用实时业务决策的insights & predictions。


图10展示了适配于data platform management的agentic AI平台参考架构。关键data cataloging代理包括：

  • • Supervisor agent：扫描企业源系统以发现新数据，分配和调度代理任务。
  • • Data discovery agent：自主提取entities，检测关系并应用metadata enrichment。
  • • Data integration agent：与ERP、CRM等企业系统无缝整合，启用实时catalog更新。
  • • Metadata validation agent：执行metadata一致性检查，检测重复，确保关系映射准确。
  • • Data observability agent：持续跟踪data lineage，应用security和access control政策，确保compliance。


类似地，关键data engineering代理包括：

  • • Supervisor agent：调度batch和real-time jobs，自动化batch和streaming源的ingestion。
  • • ETL agents：提供data pipelines的端到端自动化，包括data ingestion、modeling和transformation。
  • • Data quality agent：执行data quality、integrity和consistency检查，deduplicate记录等。
  • • Data modeling and tuning agent：根据schema drift检测和用户查询趋势动态调整schemas和indexing，自动适配表结构。
  • • Data observability agent：持续监控data warehouse性能，auto-tuning数据管道以提升速度和成本效率。

5. 结论

Agentic AI是一个强大的范式，有潜力颠覆当今企业中普遍存在的许多业务流程。本文聚焦于“agentification”流程。

我们从一个高度依赖人工干预的手动流程开始，重新设想底层流程，利用autonomous AI代理实现高度自动化。然后识别并概述了与该流程相关的任务特定AI代理。最后展示了agentic AI平台的参考架构，以个性化的方式为终端用户orchestrate这些代理（层级）。

我们展示了两项案例研究，应用agentification交付IT流程：data platform management（包括data cataloging和data engineering pipelines）以及优化客户服务台。我们相信，鉴于企业流程的不断演变，agentification有潜力带来显著的业务价值。


 


（文：PyTorch研习社）

发表评论