智能体越多，企业越该搭一层公共底座

最近一周，几家企业软件厂商不约而同地在补同一种能力。Salesforce把上下文、行动、治理、安全、模型等能力收进“企业AI底座”；Cisco把智能体表现、运行时护栏和Token消耗放到同一个观测面；OpenAI新发布的Agents API则把长会话、工具使用、子智能体协调与运行环境打成一套托管能力。表面上它们卖的是不同产品，背后却在回答同一个问题：当企业已有不止一个智能体时，哪些东西不该再让每个团队从头造一遍？

这比“再做一个更聪明的Agent”更难，也更接近企业AI能否规模化的分水岭。因为智能体可以按场景各自生长，但客户定义、权限、动作接口、成本归属和运行记录，必须能被多个智能体共用。否则企业得到的不是智能体团队，而是一批看起来会干活、实际上彼此失忆又彼此失控的自动化孤岛。

问题不在“连上系统”，而在“理解的是不是同一件事”

Salesforce在9月11日用一个“今天能否履约”的客户问题说明了这种复杂性：CRM里有客户关系，ERP里有库存和履约，合同里有承诺，分析系统里有业务定义，政策又规定了什么能答应。把接口接通并不等于智能体能可靠行动；它必须在那个客户、那个时点，按企业对“可用”“可承诺”的共同定义来判断。

这恰好解释了为什么许多企业越做智能体，业务口径反而越乱。客服智能体把“高价值客户”定义成近30天消费额，销售智能体按年度合同额，运营智能体又按毛利贡献；每个定义单独看都说得通，组合起来却会让同一位客户收到相互矛盾的动作。模型不是根因，缺少被共同维护的语义、上下文和规则才是。

智能体可以按岗位分工，企业对客户、业务与边界的理解不能按智能体分裂。

公共底座至少要共用三样东西

第一是共同上下文：不是把所有资料塞进同一个知识库，而是为关键对象保留统一的身份、数据来源、业务定义、历史状态与适用范围。第二是共同动作边界：哪些系统能调用、什么权限能执行、何时必须升级人工，不应写散在几十段提示词和临时脚本里。第三是共同运行账本：每个智能体做了什么、效果怎样、花了多少、由谁负责，要能在同一视图里追到。

Cisco 9月15日发布的更新很有代表性：它将智能体和模型的行为、性能、运行时拦截，以及Token花费归因放在一起，并试图把支出与业务结果关联。这里最值得注意的不是“Tokenomics”这个新词，而是成本终于被放回行动现场。一个智能体花了多少Token并不天然说明价值；只有同时看它完成了哪类工作、在哪一步反复失败、是否触发人工接管，成本才有业务含义。

别等到第十个智能体再补“地基”

这并不意味着企业第一天就要采购一套庞大的控制平台。更实际的启动方式是：当第二、第三个智能体开始读取同一批客户数据、调用同一类业务动作时，就把重复出现的内容抽出来。先统一一个对象的业务口径，再给一个高风险动作补身份和审批，最后让两个智能体把结果写回同一份运行记录。能被第二个场景复用的，才值得沉淀成底座；仍然高度场景化的，留在智能体内反而更灵活。

这也给STARBOX的“组织 → BOX → 智能体”三层架构提供了一个更具体的落点。组织层不只审批项目，而要维护那些跨场景不能分叉的业务定义、权限和责任；BOX不只是存放资料，更应成为可复用上下文、动作规范与运行证据的工作台；智能体则在这个底座上各自完成专业任务。DDABC闭环里的Benchmark也不应只比较单个Agent的准确率，而要比较：复用之后，口径冲突是否变少、人工接管是否更可解释、单位业务结果的成本是否下降。

智能体时代最稀缺的资产，可能不是又一个模型账号，而是企业已经验证过、能让不同智能体共同使用的那部分“办事常识”。它越早被从个人提示词和单点流程中抽出来，后面每新增一个智能体，才越像是在添一名新同事，而不是另起一套小公司。

来源：Salesforce《Trusted Enterprise AI Harness》（2026-09-11）；Cisco《Trusted AI at Scale》（2026-09-15）；OpenAI《Introducing the Agents API》（2026-09-10）。产品能力与客户数据均按各发布方公开材料表述。