智能体越会干活，企业越要有一套共同语言

同一个客户问“这单今天能不能发”，CRM知道客户是谁，ERP知道库存，合同写着承诺，财务系统握着信用额度，客服记录里还有一次特殊约定。每个系统都有一部分答案；让智能体把这些答案拼成可执行的判断，才是真正困难的部分。9月11日，Salesforce提出“企业AI Harness”，把上下文、行动、治理、安全和模型放进可组合的共同架构；它传递的信号很清楚：企业AI的竞争正在从“谁先做出一个Agent”，转向“所有Agent是否说同一种业务语言”。

连接系统，不等于理解业务

把接口接通只是第一步。真正会制造事故的，往往是系统间那些默认没写下来的定义：什么叫“可用库存”？是仓库里有货，还是扣除了已承诺订单后的可售量？什么叫“高价值客户”？按合同金额、毛利、续约概率，还是按当前投诉风险？若销售Agent、客服Agent和数据Agent各自从不同表里取数、各自解释，答案即使都“有依据”，也可能彼此冲突。

企业的难题不是给每个智能体更多数据，而是让它们在同一套定义、权限和例外规则下使用数据。

这一周的产品动向恰好形成印证。OpenAI在9月10日发布的 Data agent 强调接入企业既有的业务术语、指标定义、计算规则和语义层，并沿用表、行、列级权限；Genesys在9月2日升级虚拟智能体时，则把跨CRM、ERP、计费与知识系统的连接、MCP工具访问、A2A协作和审计能力一起推进。三家公司产品不同，却都在补同一层：让AI能读到“企业如何定义自己”，而不只是读到一堆字段。

把共同语言拆成三份可运营资产

我建议企业别把“统一语义”当成一次性数据治理大项目，而先为一个真实场景建三份轻量资产。第一份是业务词典：关键对象、指标和状态的唯一解释，例如“成交”“有效线索”“可承诺交期”分别由谁定义、来自哪里、多久复核。第二份是行动词典：每种判断能触发什么操作，哪些只能建议、哪些需要人批、哪些可以自动执行。第三份是例外词典：遇到数据冲突、超权限、低置信度或客户特殊情形时，应该暂停、转交给谁、留下什么证据。

这三份资产让“会回答”变成“能协作”。它也避免了常见误区：先做一个很聪明的智能体，等推广到第二个部门才发现同一指标有三种口径；或者先给Agent极宽权限，再靠事后日志追责。共同语言应先于规模化，且必须跟着业务变化持续版本化。

真正可积累的，不是提示词而是语义资产

Salesforce把客户、知识、语义、记忆、流程和历史称为企业独有的上下文，并指出模型会持续变化，专属上下文却会积累。这个判断很值得重视：模型可以换，单个智能体也会迭代，但被确认过的业务定义、权限边界和例外处理，会随着每次工作被不断补全。它们才是企业不必从零开始的部分。

对STARBOX而言，组织层应该明确谁有权定义词典与审批边界；BOX不只存材料，更保存经过确认的业务语义、工作流和异常处理记录；智能体层据此读取、判断、行动，并把冲突和人工修订回流。DDABC闭环里的 Define，不只是写需求，而是把一段业务翻译成所有人和所有Agent都能复用的共同语言。

接下来要问的，或许不再是“我们还能上线多少个智能体”，而是“当两个智能体对同一客户采取不同动作时，我们能否说清它们依据的是哪一个定义、哪一条权限、哪一次例外？”能稳定回答这个问题的企业，才真正拥有可扩张的AI工作方式。