AI代理需理解企业真实运作：从流程知识到业务上下文的跃迁

仅了解标准的财务、采购和供应链流程，尚不足以让AI代理可靠地执行这些流程。它们还需要理解企业的配置、政策、数据关系以及例外情况。

SAP Business AI产品工程副总裁兼首席产品官Ted Way表示，这需要同时理解代理所作用的业务对象与关系，以及约束其行为的规则与管控措施。

Way表示：“代理可以理解IFRS 15或美国通用会计准则（US GAAP）等全球会计实务。但要实际执行工作，它还需理解该公司的收入确认配置、相关计算、过账历史、单据流及合同。”

代理还必须考虑企业特定的流程步骤、业务例外情形以及任何行业相关的监管要求；这些因素共同决定了日记账分录或付款是否被正确执行。随着企业在可审计工作流中提升代理的自主性，这些代理所需理解的上下文也随之增长。

AI代理在执行多步骤企业工作流之前所需具备的条件

代理要么仅能生成答案，要么可采取行动并交付成果。后者需要将业务上下文与治理机制相结合。

Way表示：“基础代理可能仅能告诉用户，‘我认为您应该做X’。而我们正迈向一种能够声明‘我获授权执行X。我知道涉及哪些系统。我可在保留该流程相关管控的前提下完成此项操作’的代理。”

针对单笔付款，代理需追踪的业务对象可能包括客户、供应商、产品、合同、发票及订单，而管控措施则涵盖审批、访问权限、合规性要求，以及代理所执行每一项操作的审计记录。代理首先报告审批状态，继而推荐付款，再准备付款供人工执行，最终在严格政策约束下、由人工参与监督的情况下完成付款并进行对账——Way将这一阶段称为‘受管控的执行’（governed execution）。

潜在回报不仅在于获得更优答案，更在于缩短从答案到结果之间的操作耗时。据SAP称，其客户普华永道（PwC）采用Business AI后，一项复杂的开票任务耗时从35分钟减少至5分钟，同时提升了准确性。

AI代理需要跨应用实现数据对账

代理所需的大部分上下文分散于各个应用之中。例如，同一供应商可能以不同标识符和属性存在，因此一条记录可能显示为‘IBM’，另一条为‘International Business Machines’，第三条则指代‘IBM Inc.’。

Way表示：“在我公司，‘关键供应商’的定义可能与贵公司完全不同。正因如此，本体论（ontology）、知识图谱（knowledge graph）以及数据协调（data harmonization）才如此重要。我们绝不想采取‘寄希望于大语言模型（LLM）碰巧自行解决’这种策略。”

向代理提供更大量数据并不足够；它还需理解数据的含义以及各条记录之间的关联关系。解决方案是在原始数据之上构建一个上下文层，该层将每个实体分散的记录整合为一个可信档案，并向代理阐明该实体如何与其他实体相连接。

保持AI代理业务上下文的时效性

企业持续新增数据并变更流程，因此代理所依赖的上下文可能迅速过时。维持其时效性需持续对记录进行对账，并判定哪些数据源最值得信赖且最新。这也意味着需监控业务流程及代理工作流的实际运行状况。

当代理抵达其不应单独逾越的阈值时，便会发送通知请求人工审核或批准。客户自行定义这些阈值及代理所遵循的规则。对于受监管的财务流程，客户还可要求对必须每次以相同方式执行的步骤设定固定工作流。

Way表示：“出于合规性或监管原因，某些步骤必须每次都以完全相同的方式执行，我们在此处并不需要代理发挥创造性。而在有空间解决问题之处，代理便可发挥作用。客户划定这条界限。”

上下文必须随工作流转

当企业特定上下文能够伴随业务流程跨越不同应用、系统与职能时，其价值方得以最大化。这正是SAP全新升级的Joule助手（Joule Assistants）背后的理念：它们围绕某一业务目标协调多个专业化代理，而非围绕单一软件展开。

Way表示：“Joule助手遵循的是业务流程，而非软件的组织架构图。每位助手均编排多个Joule代理，而每位代理则在SAP及非SAP系统中执行既定流程。”

以物流异常为例：若订单所需库存未处于应有位置，解决问题便不止于识别替代货源。代理可能需要了解各仓库中可用库存、该库存是否已被承诺用于其他订单、适用的保质期规则、可选的替代运输方式，以及哪些决策需经审批。

Way表示，一家为制造商供应天然原料的SAP客户采用此方法，将原本多步骤的物流“救火式”应急响应转变为一键式流程，从而挽回了团队约三分之一的时间。

同一原则亦适用于财务领域。SAP收入确认助手（Revenue Recognition Assistant）在依据IFRS 15和美国通用会计准则（US GAAP）对交易进行分类时，会调用企业自身的配置、计算逻辑、过账历史及单据流。由SAP旗下公司Tereina提供支持的SAP Pay则将该模式进一步推向受管控的执行层面，在保留流程相关管控的同时完成已获批付款并进行对账。

其影响可超越单个任务的自动化。SAP表示，戴姆勒卡车北美公司（Daimler Trucks North America）将其车队合同投标中标率从约10%提升至逾40%，在12个月内产生约7000万美元的财务影响。

在这些工作流底层，Joule依托SAP Business Data Cloud中的SAP Reltio及SAP Knowledge Graph，调用已对账的业务实体与语义关系。SAP Reltio利用其所谓“动态幸存者选择”（dynamic survivorship）机制，持续对记录进行对账，该机制通过权衡数据源的可信度、时效性与聚合程度来确定最优记录；而SAP Signavio则可实时跟踪业务流程及代理工作流的实际运行状况。

Way表示：“客户常说，‘哦，我们只有一套采购到付款（procure-to-pay）流程。’我们运行Signavio后却发现，‘实际上，你们拥有400套采购到付款流程。’”

业务上下文必须跨越供应商边界

当工作流延伸至单一供应商的应用与代理之外时，问题将变得更加复杂。SAP正采用Agent2Agent（A2A）协议，使Joule能够与SAP以外的代理交互；Way表示，其与Microsoft Teams的双向集成即为绝佳范例。

但更根本的问题并非两个代理能否通信，而是支撑某项操作可信性的业务上下文——即数据含义、实体间关系、企业政策与管控措施——也必须在工作跨越不同系统时保持完整。

韦（Way）承认，很少有公司完全在单一技术栈内运营。这使得互操作性不仅仅是一个集成问题。如果智能体要在SAP系统和非SAP系统之间执行任务，那么它们所依赖的业务含义、关系、策略与控制机制也必须随之迁移。

因此，企业级智能体面临的挑战，不仅仅是学习某项业务流程本应如何运作，更在于始终立足于该企业实际的运作方式——即便该企业的运作方式本身正在发生变化。