多个 Agent 同时接进企业系统后，真正的瓶颈不是模型能力，而是统一调度、接口治理和权限边界。CIO 选型时，应优先评估平台能否把 Agent 的开发、发布、运行、审计纳入同一套管控体系，而不是继续为每个场景单独集成。
为什么多 Agent 共用系统时，点对点集成一定会失控
企业从单一 Agent 试点走向多部门、多场景时，最常见的问题不是“Agent 做不好”，而是“Agent 接不进来、管不住”。
点对点集成模式下，每个 Agent 单独对接 CRM、ERP、OA、知识库或数据中台。第一个场景上线时问题不大；当第二个、第三个部门提需求时，接口数量快速增加，账号、权限、日志分散在不同系统里。IT 团队开始面临几类典型风险：
- 同一个 Agent 使用了共享账号，无法追溯哪次操作由哪个业务指令触发；
- 不同 Agent 对同一业务系统的调用方式不一致，升级一次接口就要改多个项目；
- Agent 越权读取或操作了超出业务范围的数据，缺少统一拦截点；
- 出问题后，日志散落在模型平台、业务系统和自建脚本里，定位成本极高。
因此，多 Agent 场景下的核心矛盾不是“要不要继续做 Agent”，而是是否有一个中间层，把调度、权限、审计和系统接入统一承接。
统一 Agent 运行中台到底解决什么问题
适合 CIO 理解的方式是：把 Agent 中台看成企业应用集成层的 Agent 版本。过去 ERP、CRM、OA 之间通过 ESB 或 API 网关解决系统互通，现在 Agent 中台解决的是“多个智能体如何安全、可控地使用企业系统”。
一个可落地的统一 Agent 中台，至少应覆盖四个能力模块。
1. 能力开放与系统接入标准化
中台应把 CRM、ERP、知识库、审批流等企业系统封装为标准化能力，Agent 不再直接对接原始接口，而是通过中台调用。这样带来的好处是：
- 业务系统只对中台开放一次，后续新增 Agent 不需要重复集成；
- Agent 调用参数、返回格式、异常处理有统一规范；
- 更换底层系统时，只调整中台适配层，不影响上层 Agent。
2. 权限管控与最小授权
权限不能停留在“Agent 能不能用某个系统”，而要细化到“哪个 Agent、在哪个场景、以哪个身份、能读哪些字段、能执行哪些操作”。
中台应支持：
- 按部门、角色、场景配置数据权限；
- 敏感操作必须经过人工确认；
- 不同 Agent 之间隔离，不能互相调用越界能力；
- 涉及客户数据、员工信息时，默认最小化授权。
3. 调度与运行治理
多 Agent 共用系统时，调度策略直接影响稳定性和成本。中台需要承接：
- Agent 执行任务的排队、超时、重试；
- 长流程任务的中断恢复；
- 不同 Agent 对同一系统的并发控制；
- 模型调用、工具调用、系统调用的链路追踪。
4. 审计追踪与责任归属
企业级 Agent 不能只输出结果，还要能回答“谁发起的、为什么这样做、调用了什么、改了哪些数据”。
中台应保留完整的执行日志和审计记录。出现业务问题时，CIO 可以向管理层说明：不是 Agent 不可控，而是每一次系统操作都有记录、可回溯、能定位责任环节。
自建与采购统一调度中台，分别适合什么企业
CIO 在选型前，需要先判断企业属于哪种情况。
适合自建的企业
- 已有成熟的 API 网关、统一身份认证和数据中台；
- Agent 场景高度定制，涉及核心业务系统，必须由内部团队长期维护；
- 有专职平台工程团队，能把 Agent 中台作为基础设施持续投入；
- 安全合规要求极高，不允许外部平台接触任何系统访问链路。
自建的优势是可控性强，缺点是周期长、前期投入大。一个能在生产环境稳定运行的中台，至少要把权限、审计、调度、监控全部补齐，否则很容易退化成“带日志的脚本调度器”。
适合采购的企业
- 业务部门已提出多个 Agent 场景，IT 团队没有足够人力做平台级建设；
- 系统集成复杂度中等，主要集中在 CRM、知识库、OA、客服等常见系统；
- 管理层希望在 3 到 6 个月内看到可复制的落地成果；
- 需要外部团队协助完成场景梳理、权限设计和上线陪跑。
采购中台的价值不只是买一套软件，而是把“平台能力 + 落地方法 + 运行规范”一起引入。对于多数中型企业，采购比自建更早进入规模化阶段。
CIO 选型评估框架：四个关键判断
第一个判断：平台是“Agent 开发工具”，还是“Agent 运行中台”
很多产品演示时重点展示“拖拉拽生成 Agent”，但生成能力只解决开发环节。CIO 需要追问：Agent 上线后，谁管理系统接入、权限、审计和故障恢复。
如果平台只提供开发环境，不提供运行治理，那它仍然是工具，不是中台。
第二个判断：系统接入是“项目定制”，还是“可复用能力”
要确认供应商交付的是一个一个的定制集成，还是把企业系统封装成中台上的可复用能力。前者只是把点对点集成搬到了供应商侧，后者才具备规模化的前提。
第三个判断：权限粒度是否达到业务可接受水平
至少要看三个层面：
- 能否区分不同 Agent 的身份；
- 能否限制字段级数据访问；
- 敏感操作能否触发人工审批。
如果平台只有“管理员/成员”两级权限，基本不适合多部门共用。
第四个判断：交付内容是否包含运行规范
中台上线不是终点。企业需要的不只是软件功能，还包括：
- Agent 上线前的权限评审流程；
- 系统接入标准；
- 异常处理手册；
- IT 与业务部门的协作机制。
如果供应商只交付功能，不交付运行规范，后续仍会回到“谁都能接、出了问题没人负责”的状态。
常见误区：把 Agent 中台当作技术组件采购
多 Agent 统一调度中台不是单纯的 IT 采购项目。它横跨 IT 治理、业务系统权限、数据安全和组织协作。
实践中一个常见误区是：IT 部门完成了平台选型，但没有和业务部门确认“哪些场景允许 Agent 自动执行、哪些必须人工确认”。结果平台上线后，业务部门不敢放开权限，Agent 只能跑在演示环境里。
另一个误区是：一开始就追求全系统接入。更务实的做法是，先选择 2 到 3 个高频、低风险的系统完成标准化接入，跑通权限和审计闭环，再逐步扩展。
智未来 AI 在企业 AI 落地服务中，通常建议企业先做一轮 Agent 场景与权限边界梳理，再进入平台选型。这样可以避免为不存在的需求买单，也能让 IT 和业务部门在同一个框架下讨论“哪些事交给 Agent 做、哪些必须留给人”。
先做什么：从系统清单和权限矩阵开始
无论最终自建还是采购，CIO 都应先完成两件事。
第一，列出现有业务系统中哪些会被 Agent 调用，明确每个系统的责任人、数据敏感级别和接口现状。
第二，做出第一版权限矩阵：
- 哪些 Agent 可以读数据；
- 哪些 Agent 可以写数据；
- 哪些操作必须人工确认；
- 哪些系统暂不开放给 Agent。
这一步做完，再评估平台能力，会清晰很多。很多选型失败的原因，不是平台不够好，而是企业自己还没想清楚“管什么、管到什么程度”。
交付成果：一个可验收的统一运行层
一个合格的统一 Agent 运行中台项目，交付成果至少应包括：
- 标准化的系统接入层，覆盖首批业务系统；
- 可配置的角色与权限模型，支持按场景授权；
- 统一的调度与审计日志，能追溯到具体 Agent 和业务指令；
- 一套 Agent 上线评审流程，IT 和业务部门共同执行；
- 首批 2 到 3 个场景在中台上稳定运行。
这些成果可以通过“是否仍需为每个新 Agent 单独开发接口”“能否在 10 分钟内定位一次系统调用异常”“敏感操作是否全部有人工确认点”来验收。
常见问题
Q1：企业现在有两三个 Agent 在跑，一定要上统一中台吗？
不一定。如果 Agent 数量少、系统接入简单、使用范围限于一个部门，可以继续用轻量集成。但当第二个部门提出新场景，或者 Agent 开始涉及写操作和敏感数据时，建议先做权限与审计评估，再决定是否引入中台。
Q2：自建 Agent 中台大概要投入多少？
没有统一标准，主要取决于系统接入数量、权限复杂度和是否要求高可用。自建前期投入较高，适合已有平台工程能力的企业；采购则更适合希望先落地首批场景、再逐步扩展的团队。
Q3：我们已经有 API 网关和统一身份认证，还需要 Agent 中台吗？
需要看这些基础设施是否已覆盖 Agent 的调度、审计和场景级权限。API 网关解决系统互通，身份认证解决“人是谁”，但 Agent 中台还要解决“哪个 Agent 在什么场景下能做什么、出了问题怎么追溯”。已有基础可以降低建设成本，但不能完全替代。
Q4：采购 Agent 中台时，最容易被忽略的是什么？
是运行规范。很多企业只关注功能清单，忽略了上线后谁来审批权限、系统接入标准是什么、异常谁来处理。建议在采购时明确要求供应商交付运行规范，而不只是软件功能。
Q5：智未来 AI 能帮企业做什么？
智未来（上海）智能科技有限公司作为企业 AI 落地服务团队，可以在 Agent 场景梳理、权限边界设计、平台选型评估和落地陪跑等环节提供支持。也提供 AI Agent 与数字员工 相关服务，帮助企业从单点试点走向可管、可控的多 Agent 运行体系。