AI Native 时代,如何让企业原有系统为 AI 所用?

未来企业建设 AI 原生能力，关键是把已有系统中的知识、规则和业务动作，转化为可被授权调用、可被组合、可被审计的企业能力。对员工而言，入口可能是对话、工作台、IM 或原有业务页面；对企业而言，真正需要长期建设的是入口背后的能力网络。

一、企业缺的不是又一个聊天框

设想一个政企客户经理提出：“这个客户下周能否按合同价格采购这批商品？如果可以，准备报价并发起审批。”这不是一次知识问答。AI 需要识别客户和合同，读取商品可售范围与库存，核对价格政策、授信额度和交付区域，生成报价，按权限发起审批，并把结果写回相关系统。任何一个环节缺失，最终都只能得到一段看似完整的文字，后续仍要人去各系统执行。

因此，AI 原生平台至少要回答三个问题：它知道什么，即企业上下文；它能做什么，即可调用的业务能力；它被允许做什么，即贯穿全过程的身份、权限与治理。模型负责理解任务、规划与表达，业务系统仍负责事实、规则、交易和记录。

近期千问办公发布“企业上下文”，说明业界正在重视让 Agent 理解组织知识和业务信息。与此同时，Salesforce 已提供面向 AI 应用的 MCP 接入，微软围绕 Copilot 建设企业连接器与 MCP 管理能力。这些产品侧重点不同，但共同指向一个变化：企业软件的价值正在从“用户必须进入我的页面”，扩展到“我的能力能在被授权的工作场景中发挥作用”。

二、先把业务系统变成可调用的能力

企业过去已有大量 API，但“有 API”不等于“Agent 能可靠地工作”。传统接口往往按系统内部对象划分，调用方必须知道字段、状态、先后顺序和异常处理。面向 AI 的能力应进一步封装为语义清楚的业务动作，例如“查询客户可用授信”“校验商品是否可按合同销售”“生成报价草稿”“提交审批”，并声明输入、输出、适用条件、权限、风险级别及错误后的处理方式。

这并不要求一夜之间给所有老系统制作 CLI 或 MCP 服务。合理的顺序是：先建立稳定的业务 API 或服务层，再按使用环境提供 MCP 工具、插件、SDK 或 CLI。MCP 适合让智能体发现和调用工具；CLI 适合开发者、自动化任务及有受控执行环境的 Agent；插件适合特定宿主生态。它们是能力的接入形式，底层业务规则与授权应尽量共用，避免形成几套互不一致的真相。

开放的粒度也很重要。直接开放“修改订单数据库记录”会绕过业务规则；封装“在满足签收、售后与账期条件时生成对账单”则把系统已有的校验、幂等和审计一并保留下来。优先开放那些跨部门反复使用、规则清晰且效果可衡量的动作，再逐步扩展。

三、企业上下文是一套有边界的工作记忆

仅把文档放进向量库，无法让 AI 理解一笔订单为什么被阻断。上下文至少包括五类：组织与人员（谁在执行、属于哪个组织）；业务对象（客户、合同、商品、订单、项目）；规则与状态（价格、审批、额度、生命周期）；过程证据（沟通、变更、操作与决策依据）；实时环境（库存、履约、系统可用性）。

建设时应为关键对象建立统一标识与关系，让合同能关联客户、报价、订单和授信；同时标记来源、更新时间、有效期和数据责任人。检索只能返回当前用户有权看到的内容，行动前还要重新读取实时状态。历史对话可以帮助理解意图，却不能代替正式系统里的合同条款和余额。所谓“懂企业”，最终表现为能在具体任务中取到正确、及时、可追溯的上下文。

四、权限要约束每一步行动

智能体不能因为持有一个平台账号就拥有跨系统的通行证。平台需要同时识别发起人、代理它行动的 Agent、目标系统和具体业务对象。一个人有权查看客户订单，并不意味着他可以改价格；有权准备报价草稿，也不意味着可以代表财务放款。

可采用分层控制：读取按源系统权限过滤；低风险动作按岗位与场景授权；涉及金额、外发、删除和不可逆操作时设置确认或审批；执行前再由目标系统校验业务条件。每次调用记录身份、参数、依据、结果及关联任务，支持追责和回放。对于长链路任务，还需要超时、重试、幂等、补偿和人工接管机制。安全治理不是智能体上线后的补丁，而是能力开放时就要定义的契约。

五、入口变了，系统的价值不会因此消失

企业软件厂商可能担心：用户不再登录 CRM，入口被通用 AI 抢走，产品就失去了价值。这个担忧有现实基础。注意力、交互数据与分发确实可能转向新的入口，产品界面也可能变得不那么高频。

但企业客户购买 CRM 的根本目的，并不是访问某个页面，而是管理客户关系、销售流程、权限、预测和交易结果。只要核心对象、规则、协作和记录仍由 CRM 承载，它就能在更多入口中被使用，甚至进入过去因操作成本过高而没有覆盖的工作流程。真正需要重新设计的是商业模式与产品指标：从登录量、页面访问量，增加到能力调用量、业务闭环率、结果质量和客户留存。

因此，企业应同时掌握两件事：把自身高价值能力开放到客户常用的工作入口；在关键流程中保留适合复杂审核、异常处理和专业判断的原生界面。开放并不自动带来竞争力，能力质量、数据质量、权限可信度及商业关系才决定谁能持续创造价值。

六、如何启动：从一条链路建设共同底座

“先建完整底座再找场景”容易变成长期基础设施工程；“每个场景各做一套”又会造成权限、连接器和上下文重复建设。可选择一条跨系统、高频、有明确负责人与结果指标的链路，边跑通场景边沉淀共用能力。

第一阶段，绘制任务地图：列出员工完成任务所需的业务对象、系统、动作、授权和人工决策点，找出最耗时的交接。第二阶段，开放一组可靠能力：先做查询、校验和草稿，再逐步增加审批提交和交易执行；所有动作都要有版本、测试样例和异常码。第三阶段，打通上下文与权限：统一对象标识，建立按身份读取与按动作执行的策略。第四阶段，用真实任务评估：统计完成率、人工接管率、错误率、处理时长和单位任务成本，持续调整能力契约。

对一个拥有商品、订单、物流、发票与售后等系统的企业，可以先选“从客户采购需求到可执行订单”作为试点。员工用自然语言提交需求，平台识别客户与商品，读取合同价格和供应范围，校验库存、额度与配送条件，生成待确认订单；员工确认后调用现有下单能力，后续继续查询物流、处理异常和对账。第一条链路跑通后，同一套身份、客户对象、商品工具和审计能力可以复用到客服、售前和运营。

七、未来的架构判断

未来的企业 AI 原生平台，不会仅仅是一组智能体的展示页。它更像一层可治理的任务运行环境：上层承接自然语言和专业工作台，中间层组织上下文、规划任务与调用能力，下层连接企业原有的系统和数据；身份、权限、评估、日志贯穿所有层。系统不必被全部重写，但必须逐步变得可理解、可调用、可验证。

今天我们应当问的，不只是“这个场景能不能加 AI”，还包括：这个场景依赖的企业能力能否被其他场景安全复用？如果答案是肯定的，每落地一个场景，就在为下一批场景铺路。企业的数字化资产也将从分散的系统功能，逐步成为能够被人和智能体共同使用的能力网络。