企业语义层建好以后，Agent 到底怎么用

随着大模型技术深入企业应用场景，构建统一的企业语义层已成为行业共识。所谓「统一」，核心在于确保同一业务概念在明确适用范围内拥有权威定义，并能够被不同 Agent 共同访问和复用。然而，当语义层建设完成后，一个更实际的问题随之浮现：Agent 究竟如何调用这些语义来高效完成业务任务？

为什么不应该把企业定义都塞进提示词

以采购场景为例。当 Agent 收到「找出本周交付风险最高的采购订单，对符合条件的供应商发送催办」这类任务时，其背后依赖的是企业内部对业务对象的定义、指标计算口径以及业务规则。这些知识对于通用大模型而言，仅凭参数中的预训练信息难以稳定获取。

业务语义解析的核心机制

在 AI 应用开发日益普及的今天，快速构建一个 Agent Demo 并不困难。大多数项目的惯常做法是将业务定义直接写入提示词——定义「延期订单」的计算规则、高风险延期的阈值条件、订单状态与催办权限的对应关系。这种做法在单一 Agent 场景下完全合理，但问题往往从第二个、第三个 Agent 出现时开始显现。经营分析 Agent 需要使用「延期采购金额」，供应商风险 Agent 需要理解采购订单与供应商的关联关系。当每个项目、每个 Agent 都维护各自的提示词时，企业内部很快就会出现多个版本的「高风险延期」定义。这与过去企业信息化建设过程中产生的数据烟囱问题如出一辙——早期各系统各自保存客户、订单数据，系统越建越多，企业又不得不通过主数据治理、数据平台、指标平台等方式重新整合散落的数据和口径。Agent 时代同样如此。如果每构建一个 Agent，就在提示词和工作流中重复定义客户、订单、指标和规则，那么这次散落的将是对业务的理解深度。企业已为数据烟囱付出过治理成本，没有必要再制造一批新的「语义烟囱」。

共享语义的多 Agent 协作价值

将用户语言映射到企业正式业务定义的过程，可称为「业务语义解析」（Semantic Resolution）。这个环节的关键在于：把自然语言中模糊的业务概念，精准绑定到企业已维护的机器可读定义上。以采购人员的「高风险延期采购订单」为例，Agent 需要将其解析为：PurchaseOrder 对象、overdue_days 指标、CRITICAL_DELAY 规则定义，以及 supplier_followup_policy 策略。这些定义并不要求物理存储在单一系统中——指标可来自指标平台或数据平台，业务对象和关系可维护在本体库中，业务规则可置于规则引擎内，权限校验继续由身份认证和业务系统负责。共享语义强调的是逻辑层面的统一，而非物理存储的集中。解析完成后，Agent 依次执行：读取 PurchaseOrder 实例数据，根据 CRITICAL_DELAY 规则筛选符合条件的订单，沿已定义的关系链路找到对应供应商，最后判断可执行的动作。整个过程中，语义层负责「把业务含义讲清楚」，而 MCP（Model Context Protocol）、API 和现有业务系统继续负责连接与执行。这种分工意味着

当企业部署多个 Agent 后，共享语义的价值愈发凸显。假设采购 Agent、经营分析 Agent 和供应商风险 Agent 都在使用 PurchaseOrder、delayed_purchase_amount 和 CRITICAL_DELAY 这些定义，一旦采购部门将「高风险延期」标准从 7 天调整为 5 天并规定生效日期，语义分散在各提示词中的团队只能逐个手动修改。而如果 CRITICAL_DELAY 是统一维护的企业定义，只需发布新版本，所有引用该版本的 Agent 在生效日自动采用新规则；仍需运行旧流程的应用可暂时保留旧版本，完成测试验证后再行升级。这种机制也承接了语义层的持续运营特性——业务规则会演进，指标口径会调整，组织架构和权限体系也会变化，Agent 每次执行时需要获取的是当前有效版本，而非固化的历史快照。

如有侵权，请联系删除。