第3章 AI 原生业务系统：Agent 重塑企业软件¶
场景引入¶
一家企业已经给 BI、CRM、ERP 和工单系统都加上了 AI：BI 能自然语言问数，CRM 能总结客户状态，ERP 能提示库存异常，工单系统能自动摘要和分类。单看每个功能，效率都在提升；但经营分析会前，负责人仍然要自己在多个系统之间切换，查数据、找原因、拼材料、找人确认。
问题不在“AI 功能不够多”，而在于任务仍然由人手工串起来。旧系统里的 AI 往往只对当前页面负责：BI 助手不知道库存是否断货，工单助手不知道促销节奏，知识库助手也不会把结果继续写入会议材料。用户依然是整条任务链的编排者。
AI 原生业务系统要改变的是这个分工。用户从“先进入某个系统，再完成一组操作”，转向“先提出一个业务任务，再管理任务执行”。例如用户提出“准备华东区经营分析材料”，系统需要确认范围和指标口径，调用 BI、库存、客服和知识库，遇到冲突时暂停确认，最后生成带证据的图表、结论和待办。
图3-1：旧系统加 AI 与 AI 原生业务系统对比。来源：本书自绘。Alt text：左侧"旧系统加 AI"在原有页面旁挂一个助手、用户仍逐个操作功能，右侧"AI 原生"以任务为中心、用户提出目标后由系统编排多个旧系统完成，对比凸显交互入口从页面转向任务。
旧系统不会因此消失。ERP、CRM、BI、工单和财务系统继续承载企业事实、规则、权限、审批和事务一致性；Agent 在允许范围内调用这些系统，把过去由人手工串联的步骤组织成一条可观察、可接管、可审计的任务链。
AI 原生的核心，不是把聊天框放到更多页面里，而是让“任务”逐渐取代“页面”成为系统组织业务的中心。 用户负责提出目标、补充约束和裁决关键结果，Agent 负责组织执行，既有系统继续提供权威事实和事务能力。
3.1 从页面中心到任务中心：系统分工发生了什么变化¶
传统企业软件以模块和页面为中心。用户先判断该进入哪个系统，再完成字段填写、查询、导出、复制和提交。AI 增强可以让这些局部操作更聪明，但并没有改变端到端任务由谁组织。
AI 原生业务系统至少带来四个变化：
- 入口从模块转向任务。 用户先表达“要完成什么”，系统再决定需要调用哪些能力。
- 流程从固定路径转向动态编排。 系统可以根据中间结果调整步骤，而不是只沿预设页面流转。
- 责任从单模块输出转向端到端任务。 系统需要说明使用了哪些证据、调用了哪些工具、在哪里等待确认。
- 人机协作从人工拼接转向共同约束。 系统负责跨工具推进，人负责目标、约束、高风险判断和最终裁决。
用户角色也会从“系统操作者”转向“任务发起者和结果裁决者”。 因此产品设计的核心问题不再只是“按钮放在哪里”，还包括任务当前处于什么状态、用了什么证据、哪里需要人工确认、失败后怎样继续。
AI 原生并不是凭空出现的第四代系统。它建立在企业过去的数字化、自动化和智能化基础上：数字化把业务对象搬进系统，自动化把稳定流程交给 Workflow 和 RPA，智能化在局部环节加入预测、推荐和生成；AI 原生则进一步把这些既有能力围绕“任务”重新组织。
没有 ERP、CRM、BI、知识库和审批流，Agent 就没有可靠工具可以调用。因此，AI 原生不是推翻过去的信息化资产，而是重新安排这些资产在人机任务链中的位置。
旧系统会被工具化，而不是被绕过¶
ERP 仍然保存订单、库存和财务事实，CRM 仍然维护客户和机会，BI 和语义层仍然提供指标口径，工单系统仍然保存事件与状态，知识库仍然提供可引用的制度和案例。变化在于，这些能力除了被人通过页面直接操作，还会被 Agent 以受控工具的方式调用。
Agent 如果绕开这些系统另建一套“影子事实”，短期体验可能更顺，长期却会在权限、对账、审计和版本一致性上出问题。系统 of record 仍然是事实来源，Agent 是任务编排与解释层，不应成为第二套未经治理的事实系统。
3.2 哪些业务值得优先 AI 原生化：价值、任务结构与风险¶
并非所有业务都应该同时进入 AI 原生阶段。优先级通常来自一个共同特征：人正在为跨系统、跨知识源、跨角色的任务付出大量组织成本。
表3-1：适合优先 AI 原生化的任务类型及企业内的例子。来源：本书整理。
| 任务类型 | 为什么适合优先改造 | 一家多业务线企业里的例子 |
|---|---|---|
| 跨系统信息整合 | 人工切换系统和拼接结果成本很高 | 经营分析、销售复盘、售后诊断 |
| 文档密集型任务 | 规则和依据散落在文档与知识库中 | 合规审查、投标响应、合同审阅 |
| 草稿型输出 | 结果可以先生成，再交由人确认 | 报价草稿、经营周报、客户回复建议 |
| 诊断型任务 | 需要逐步缩小问题范围，而非单点查询 | 毛利异常分析、库存异常追因 |
相反，付款、签约、主数据删除等强事务、不可逆、高责任动作，即使业务价值很高，也不应因为“AI 原生”而直接自动化。
场景排序至少要同时考虑业务价值、任务结构、数据准备度和风险可控性：
表3-2：典型场景在价值、结构、数据、风险各维度的评分与建议。来源：本书整理。
| 场景 | 业务价值 | 任务结构 | 数据准备度 | 风险可控性 | 建议 |
|---|---|---|---|---|---|
| 经营分析材料生成 | 高 | 高 | 中高 | 高 | 优先试点 |
| 客服工单质检 | 中高 | 中 | 高 | 高 | 优先试点 |
| 报价草稿生成 | 高 | 中高 | 中 | 中 | 加强审批后试点 |
| 自动客户邮件回复 | 中 | 中 | 中 | 低 | 谨慎 |
| 自动付款审批 | 高 | 低 | 中 | 极低 | 暂不做 Agent 自动化 |
场景价值高，不等于适合高自动化。 很多项目失败，不是因为场景没价值，而是第一步就选择了高价值、高风险、数据又不成熟的任务，最终消耗业务对 AI 的信任。
信任来自系统供给，而不是模型“看起来聪明”¶
用户是否敢把真实任务交给系统，通常取决于五类能力：
表3-3：建立用户信任所需的几类系统供给。来源：本书整理。
| 信任来源 | 系统需要提供什么 |
|---|---|
| 可见过程 | 用户知道系统正在做什么，而非黑箱等待 |
| 可查证据 | 结论能追溯到数据、文档、规则或工具结果 |
| 可控风险 | 高风险动作必须确认、审批或降级 |
| 可恢复性 | 失败后能重试、接管、回滚或继续 |
| 可持续改进 | 用户反馈能进入评估和版本迭代 |
一个 Agent 即使输出非常漂亮，如果没有证据、状态、确认和恢复机制，也更像“有启发的助手”，而不是可以承接真实工作的业务系统。
3.3 产品形态：从 AI 增强到 Agent 工作台¶
企业通常不会一步跨到完整 AI 原生系统，而会经历三个阶段。
第一阶段是 AI 增强：BI、CRM、ERP 等原系统增加问数、摘要、推荐等能力，但系统边界基本不变。第二阶段是 Agent 嵌入：出现经营分析、报价、客服质检等跨系统 Agent，开始接管一段任务链。第三阶段才是 AI 原生业务系统：用户主要面对的是任务工作台，系统负责组织步骤、生成中间结果、等待审批和沉淀证据，旧系统更多退居工具层。
图3-2：AI 原生业务系统的三阶段迁移。来源：本书自绘。Alt text：从左到右三个阶段，数字化（业务搬进系统）、AI 增强（旧系统加助手）、AI 原生（以任务为中心重构），箭头表示能力逐级累积而非推倒重来。
多数企业会长期处于第一和第二阶段之间，这并不是失败。AI 原生更适合从少数高价值任务开始逐步形成，而不是要求所有部门同步重构。
任务工作台不等于一个更大的聊天框¶
一个真正面向任务的工作台，至少需要呈现以下内容：
表3-4：任务工作台各要素的作用。来源：本书整理。
| 工作台要素 | 作用 |
|---|---|
| 任务状态 | 告诉用户系统是在规划、执行、等待审批还是失败 |
| 证据与引用 | 告诉用户结果来自哪些数据、规则和文档 |
| 结构化结果区 | 图表、表格、草稿、待办不应全部淹没在对话气泡里 |
| 人工接管入口 | 当系统不确定时，用户必须能接手、修改、继续 |
| 审批与确认控件 | 高风险动作不能埋在普通消息流中 |
图3-3：AI 原生任务工作台结构。来源：本书自绘。Alt text：工作台分为任务目标、执行进度、证据来源、人工确认入口等区域，中间是系统调用多个工具推进任务的主流程，体现"任务"而非"页面"作为组织中心。
用户提出“生成经营分析材料”后，系统不应只在对话框里吐出一篇长文。更合理的体验是：先展示目标和范围，说明准备查询哪些指标和数据源；遇到指标口径冲突时暂停确认；最后以图表、结论、引用、待办等结构化形式交付，并允许用户提交审批或继续修改。
AI 原生前端的基本形态更接近“对话 + 任务流 + 结构化结果 + 人工接管 + 审批”，而不是“一个全屏聊天窗口”。
3.4 经营分析案例：从手工拼材料到持续任务空间¶
经营分析是理解 AI 原生价值的一个典型场景。传统模式下，运营负责人需要从销售、毛利、库存、促销、客诉等系统取数，再把多个结果拼成 PPT，找区域负责人补充原因，并在会后用邮件或群消息跟进行动项。主要问题包括口径不一致、异常追因依赖经验，以及行动项容易散落。
如果只是 AI 增强，BI 可以回答毛利率，工单系统可以总结投诉，知识库可以检索促销复盘，但运营负责人仍然需要自己拼接这些输出。
Agent 嵌入后，用户可以直接提出：“准备下周一经营分析会材料，重点看华东区毛利率异常。”系统先确认时间、区域、指标和模板，再查询销售、毛利、促销、库存、客诉等数据，进一步分析异常可能来自促销折扣、物流成本还是缺货替代销售；遇到口径冲突则暂停确认，最后输出异常摘要、图表、证据、待确认问题和建议行动项。
进一步进入 AI 原生工作台后，经营分析不再只是每周临时生成一次材料，而会成为持续任务空间：平时监控异常、积累证据，会议前自动汇总，会议后继续跟进行动项。
表3-5：经营分析会从传统模式到任务工作台各阶段的人机分工。来源：本书整理。
| 阶段 | 用户主要做什么 | 系统主要做什么 | 会议材料如何形成 |
|---|---|---|---|
| 传统模式 | 手动查、手动拼、手动问人 | 提供报表和记录 | 人工整理 |
| AI 增强 | 在多个系统里问 AI | 各自回答局部问题 | 人工拼接 AI 输出 |
| Agent 嵌入 | 定义分析目标，确认关键节点 | 跨系统追因，生成材料草稿 | Agent 生成，人复核 |
| AI 原生工作台 | 管理持续任务和行动项 | 持续监控、归因、沉淀证据 | 工作台自动汇总 |
图3-4：经营分析会从手工拼材料到任务工作台。来源：本书自绘。Alt text：上方"传统模式"中运营人员在 BI、库存、客服等系统间手动查询拼接材料，下方"任务工作台"中用户提出分析目标、系统自动取数诊断并生成带证据的材料，对比两条路径的步骤数差异。
AI 原生真正改变的不是报告生成速度，而是把取数、追因、证据、会议、行动项和后续复盘组织成同一条持续任务链。
用户培训应从“Prompt 技巧”转向“任务定义”¶
企业用户更需要学会表达一个可执行任务，而不是记忆提示词技巧。“帮我分析华东区”过于宽泛，而“分析上周华东区毛利率下降原因，重点比较促销、库存和物流成本影响，输出会议材料草稿，并标明需要区域经理确认的问题”已经包含目标、范围、约束、交付物和人工节点。
表3-6：经营分析任务模板各要素的作用。来源：本书整理。
| 模板要素 | 作用 |
|---|---|
| 任务目标 | 明确要完成什么，而非泛泛提问 |
| 分析范围 | 限定时间、区域、品类、客户或流程 |
| 约束条件 | 指定口径、规则、风险边界 |
| 交付物 | 说明要报告、图表、草稿、建议还是行动项 |
| 人工节点 | 指明哪些地方需要确认或审批 |
经营分析、报价、客服质检、票据异常、合同审阅等高频任务都可以形成模板。模板既降低使用门槛，也把优秀业务人员的经验逐步固化成组织资产。
图3-5：从功能菜单到角色任务地图。来源：本书自绘。Alt text：左侧是按系统模块组织的功能菜单树，右侧是按运营、销售、客服等角色组织的高频任务地图，箭头表示产品组织方式从"功能优先"转为"角色任务优先"。
3.5 迁移方法：从局部增强到跨系统任务，再到角色工作台¶
AI 原生迁移不应以“把哪些页面改成聊天框”为问题起点，而应先识别已有流程中哪些地方存在大量跨系统切换、人工复制、指标解释和审批等待。
一个现有流程是否值得迁移，可以先看三件事：
- 是否存在明显的跨系统拼接；
- 结论是否需要证据和解释；
- 动作是否可以明确划分为自动、确认、审批和禁止。
如果所有动作都强事务、强合规、不可撤销，就应先停在辅助或草稿层，而不是直接追求 Agent 自动执行。
迁移可以分三步：
- 第一步：在原系统中增强高频任务。 用 Copilot 或局部 Agent 减少查询、复制、解释和整理，同时收集真实问题、真实样本和真实边界。
- 第二步：抽出稳定的跨系统任务链。 当一个任务长期需要读取多个系统、组织证据、生成草稿并等待确认时，将它纳入 Agent 编排，并明确创建、执行、等待、审批、完成、失败等状态。
- 第三步：沉淀为角色工作台。 把任务模板、状态、证据、结构化产物、审批、行动项和复盘放进同一个工作空间，让高频任务形成持续运营能力。
迁移过程中必须保护旧系统的权威边界：客户主数据仍由 CRM 管，订单与库存仍由 ERP 管，指标口径仍由数据平台和语义层管，合同版本仍由合同系统或文档治理体系管。只读任务可以较早进入 Agent；涉及写操作时，则需要 Tool Registry、Policy、HITL、Trace、幂等、补偿和回滚等能力同步准备。
更稳妥的迁移顺序是：先让 Agent 解释和建议，再让它调用受控工具，最后才逐步扩大写入和自动执行范围。
迁移前最好形成一份“任务迁移说明”，写清原人工流程、保留在旧系统的步骤、转为工具调用的步骤、由 Agent 编排的步骤、人工确认节点和最终产物去向。这样产品、平台、数据和安全团队才能围绕同一条任务链讨论。
3.6 如何验收 AI 原生系统：看任务是否真的被重组¶
AI 原生项目最容易出现的假成功，是界面更智能、报告生成更快，但用户仍然需要把结果复制出去继续手工处理。真正的验收对象应是任务链，而不是一次对话。
至少要保存四类材料：
- 迁移前后的流程步骤和耗时；
- 每次任务的状态、数据来源、工具调用、证据和人工动作；
- 用户修改、退回、接管和证据替换样本；
- 最终产物是否真正进入会议、工单、审批或其他下游流程。
组织层面还要观察责任是否更清楚。AI 原生工作台会把责任分散到业务 owner、数据 owner、工具 owner、审批人、报告 reviewer 和平台 owner。数据口径冲突、建议错误、审批超时和行动项无人接收时，都必须能找到明确责任人。
可以从少量可观察指标开始：任务完成时间、跨系统切换次数、用户改写比例、人工退回原因、证据点击率、行动项完成率、工具失败率和异常复盘次数。指标本身不能一次证明成功，但能判断系统是否真的在减少任务摩擦。
上线后要持续做运行校准¶
真实用户会暴露原型阶段看不到的问题：某些工具总被绕过，说明任务链不符合实际习惯；某类结论频繁被重写，说明模板、数据或证据不稳定；行动项无人接收，说明工作台没有接进真实组织流程；审批长期超时，说明责任和通知链存在问题。
这些问题不应简单归结为“用户不会用”，而应回写到任务设计、语义层、工具契约、审批流程和评测样本。团队可以定期抽样真实 Run，检查人工修改、工具失败、证据替换、审批退回和行动项关闭情况，再由产品、数据、平台和安全团队分别修正对应环节。
AI 原生系统的成熟度，不在于界面多像对话，也不在于模型一次能做多少事，而在于任务、证据、责任和反馈能否形成稳定闭环。
3.7 上线门槛：先定义业务状态和责任链，再决定自动化程度¶
AI 原生业务系统的上线门槛应高于普通对话应用。系统一旦能够改变工单状态、生成正式经营报告、触发审批、调用外部工具或影响客户沟通，就已经进入真实业务流程。
上线至少要检查三层：
- 任务边界：哪些请求可以自动处理，哪些只能辅助，哪些默认禁止。
- 运行证据：每次 Run 是否保留输入、任务状态、工具、证据、人工动作和最终 artifact。
- 组织责任：业务 owner、平台 owner、数据 owner、安全联系人和审批责任人是否明确。
还需要确认用户是否知道当前结果处于“建议、草稿、待审批还是已正式写入”的哪一种状态，以及失败后是否可以撤回、重试、降级或人工接管。
AI 原生业务系统应从业务状态和责任链设计开始，再决定模型参与到什么程度。 如果三层门槛尚未满足，系统可以继续试点，但不应因为演示顺畅就直接扩大到关键业务流程。
本章小结¶
AI 原生业务系统不是“旧软件 + 聊天框”。它把业务任务提升为新的系统组织中心，由 Agent 负责跨工具协调和中间状态推进，用户负责目标、约束和关键裁决，ERP、CRM、BI、工单等系统继续承担权威事实、规则和事务能力。
最适合优先 AI 原生化的，是跨系统、文档密集、草稿型和诊断型任务；高风险、不可逆的强事务动作则应谨慎自动化。产品形态也应从聊天入口走向任务工作台，把状态、证据、结构化结果、人工接管和审批一起展示出来。
AI 原生是否成立，最终要看企业工作的组织方式有没有改变：用户是否少在系统之间复制信息，任务是否能持续推进，证据是否可追踪，责任是否清楚，失败是否可以恢复。 下一章将把前三章的判断收束为一张全书地图，说明这些任务、平台、数据、模型和治理能力如何组成完整的企业级 Agent 工程体系。
参考文献¶
Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR.
Schick, T. et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS.
Model Context Protocol. (n.d.). Specification and documentation.
NIST. (2023). AI RMF 1.0.