第3章 AI 原生业务系统：Agent 重塑企业软件¶
场景引入¶
一家企业已经给 BI、CRM、ERP 和工单系统都加上了 AI 功能。单看每个系统，问数、摘要、异常提示都比过去方便；但经营分析会前，负责人仍要在多个系统之间切换，自己拼数据、找原因、写材料。AI 被加进了旧页面，任务却仍然靠人串起来。AI 原生业务系统要改变的是这个分工。用户不再从某个页面开始操作，而是把“准备经营分析”“处理客户投诉”“生成报价材料”这类任务交给系统，由 Agent 编排底层工具。图 3-1 对比的正是旧系统加 AI 与任务中心系统之间的差别。
过去几年，很多企业软件都增加了 AI 入口。BI 页面多了自然语言问数，CRM 页面能总结客户近况，ERP 页面能提示库存异常，工单系统能自动归类投诉，知识库能做语义搜索。单看每个功能，它们都能节省时间，也确实改善了局部体验。但到了真实工作现场，用户仍然要自己决定先看哪个系统、再查哪张表、把哪个结论写进材料、哪些问题需要找人确认。经营分析会是一个典型例子。周五下午，运营负责人要准备下周一的材料。他先在 BI 里看销售和毛利，再到库存系统查缺货，再到客服系统看投诉，再翻上月促销复盘，最后把数据、图表和解释拼成一份 PPT。每个系统旁边都有 AI 助手，但这些助手只对自己所在页面负责。BI 助手不知道库存是否断货，工单助手不知道促销节奏，知识库助手也不会把查询结果写进会议材料。人还是那条任务链的编排者。
AI 原生业务系统要改的是这件事。用户从“打开某个页面并完成某个操作”，转向“提出一个任务并管理任务执行”。系统收到“准备华东区经营分析材料”以后，需要确认时间范围和指标口径，调用 BI、库存、客服、知识库等工具，发现冲突时暂停让用户选择，最后输出带证据的图表、结论和待办。旧系统没有消失，它们变成可调用的工具；用户也没有退出责任链，而是把精力放在目标、约束、确认和裁决上。这个变化容易被低估，因为界面上看起来可能只是多了一个对话框。但真正发生变化的是系统组织原则。传统企业软件以页面和模块为中心，把用户训练成系统操作者；AI 原生软件以任务为中心，把用户放到任务发起者和结果确认者的位置。设计对象也从“这个按钮放在哪里”扩展到“这个任务现在处于什么状态、用了哪些证据、哪里需要人工确认、失败后怎样继续”。
AI 原生不会把所有旧系统推翻重做。ERP、CRM、BI、工单和财务系统仍然承载事实、规则、权限和事务一致性。Agent 要在允许范围内调用这些系统，把原来由人手工串联的步骤组织成可观察、可接管、可审计的任务链。本章讨论 AI 原生业务系统，重点就在于这次分工变化：旧系统继续保存企业事实，Agent 负责围绕任务重新编排能力，用户负责给出目标和判断结果是否能进入业务流程。
图3-1：旧系统加 AI 与 AI 原生业务系统对比。来源：本书自绘。Alt text：左侧"旧系统加 AI"在原有页面旁挂一个助手、用户仍逐个操作功能，右侧"AI 原生"以任务为中心、用户提出目标后由系统编排多个旧系统完成，对比凸显交互入口从页面转向任务。
旧系统是在原有模块里增加局部智能，AI 原生业务系统则把业务任务作为入口，由 Agent 重新编排底层系统能力。读完这一章，读者应能区分 AI 增强和 AI 原生：前者让某个页面更聪明，后者让系统承担更完整的任务组织责任。也要理解一个更现实的判断：并非所有业务都适合立刻 AI 原生化。优先级通常来自任务是否跨系统、是否文档密集、是否需要反复诊断，以及风险能否被确认和审批控住。经营分析、合同审阅、客服质检这类任务往往更早受益；付款、签约、主数据删除这类强事务动作，仍然需要非常谨慎。
3.1 “旧系统加 AI”与 AI 原生的差异¶
一家多业务线企业的信息化并不落后。零售板块有 BI，制造板块有 ERP，客服中心有工单系统，财务共享中心有票据平台，总部有知识库。过去几年，这些系统都逐步加上了 AI 功能。BI 能做自然语言问数，CRM 能自动总结客户状态，ERP 能提示库存异常，工单系统能自动摘要与分类，知识库能做语义搜索。这些能力都是真实进步，但它们没有根本改变业务协作方式。例如，集团经营分析会前，运营负责人仍然需要重复同样的动作：打开 BI 看销售数据，打开库存系统查缺货，打开客服系统看投诉，打开知识库翻上月活动复盘，再把这些信息整理成一份材料。每个系统里的 AI 都在局部帮忙，但没有一个系统对“准备一份可开会使用的经营分析材料”这个任务整体负责。差别就在这里。AI 增强是在旧系统里增加更聪明的能力；AI 原生把“完成任务”重新放到系统中心。前者提升局部效率，后者改写系统分工。
3.2 从页面中心到任务中心的系统变化¶
很多团队一听“AI 原生”，第一反应是界面变化：按钮变成对话，表单变成聊天框。只停留在这个层面，很容易低估它对系统分工的影响。AI 原生业务系统至少改变四件事：入口从模块转向任务，流程从预设路径转向动态编排，责任从单系统模块转向端到端结果，协作从人工拼接转向人机共同约束。第一，入口从页面转向任务。传统系统要求用户先判断该进哪个模块，再在模块里完成操作；AI 原生系统则允许用户先提出目标，例如“准备华东区经营分析材料”，系统再决定需要调用哪些能力。第二，流程从预先写死的页面路径，变成围绕目标动态组织的步骤。第三，责任不再只停留在单个系统模块内，Agent 需要对一段任务结果负责，至少要解释自己调用了哪些工具、采用了哪些证据、在哪些节点等待人工确认。第四，协作方式发生变化。过去是人在系统之间切换和拼接结果，AI 原生阶段则是系统在工具之间切换，人负责补充约束、判断风险和确认结果是否进入业务流程。
在传统模式下，用户的工作是“自己去拼”；在 AI 原生模式下，用户的工作逐渐变成“定义目标、补充约束、判断是否采纳结果”。用户心智也随之从“操作系统”转向“管理任务”。还有一个更深层的变化常常被忽略：在传统系统里，页面是系统的第一组织原则；在 AI 原生系统里，任务开始取代页面。过去企业软件把人训练成“模块使用者”，AI 原生则在把人训练成“任务发起者”。这两种训练方式会反过来塑造产品设计、数据组织方式，甚至部门协作方式。这个变化会让企业软件的许多传统假设失效。过去，系统设计的核心问题是“用户在哪个页面完成哪个动作”；现在，系统设计开始转向“用户提出目标后，系统如何组织一条可控任务链”。产品经理仍要关心页面路径，但还要关心任务状态是否透明、证据是否充分、风险节点是否可确认、失败后是否能继续。
3.2.1 AI 原生与数字化、自动化、智能化的关系¶
企业过去已经经历过多轮系统升级：数字化、自动化、智能化。AI 原生接续了这些阶段的积累，并把任务组织方式推到前台。数字化先把业务对象和流程搬进系统，形成 ERP、CRM、OA、数据仓库等基础设施。它解决了“业务是否有系统记录”的问题，也留下了系统多、模块硬、用户需要自己拼接的现实。自动化进一步把稳定流程交给规则执行，Workflow、RPA 和审批流都属于这一阶段。它适合路径确定、规则清楚的场景，但遇到开放任务和模糊目标时就会变得笨重。智能化在局部功能里加入预测、推荐、生成和语义搜索，让单个系统更会理解用户，却仍然让人承担端到端组织任务的工作。AI 原生接过这些积累，把任务目标放到系统组织中心，用 Agent 工作台、任务型 Agent 和生成式界面重新连接底层能力。
这段演进并不否定前几个阶段。没有数字化，就没有可调用的数据和系统；没有自动化，就没有可嵌入的流程节点；没有智能化积累，就没有足够的局部能力。AI 原生是在这些基础上，把“任务”提升为新的组织中心。一家多业务线企业如果没有 ERP、BI、CRM、工单系统和知识库，经营分析 Agent 根本没有东西可调用；如果没有审批流，报价 Agent 也无法安全进入业务流程。AI 原生依赖过去的信息化资产，只是把任务入口和执行链路重新组织起来。
3.3 旧系统会被工具化和重新编排¶
谈 AI 原生时，还有一个常见误解：以为未来所有旧系统都会被一个对话入口替代。这个判断过于简单。ERP、CRM、BI、工单、财务系统不会因为 Agent 出现就消失。原因很直接：它们承载着企业事实、规则、权限、审计和事务一致性。Agent 要把这些系统变成可调用、可解释、可治理的工具，而非绕过它们另建一套事实。ERP 在过去主要由用户直接进入页面操作，到了 AI 原生阶段，它会更多提供订单、库存、采购、财务等工具能力。CRM 过去要求销售维护客户与机会，后续会向 Agent 提供客户上下文、沟通历史和动作建议。BI 过去让用户查看报表，后续还要提供指标查询、语义层和数据解释能力。工单系统仍然保存事件流和处置状态，只是部分状态变更和建议动作会被 Agent 调用。知识库也不会被聊天框替代，它要提供可引用的制度、案例和说明文档，让系统回答时知道依据来自哪里。
AI 原生系统要做的，是把旧系统从用户亲自操作的界面，逐渐改造成 Agent 可以在权限范围内调用的工具。做得好，用户体验会简化；做得不好，Agent 就可能绕过系统，带来权限失控和结果不可追溯。第二章讲平台边界时强调 Tool Registry、Policy、Trace，原因也在这里。旧系统工具化之后，工具的风险等级、调用权限和结果记录，都会进入平台管理范围。
3.3.1 用户心智的同步变化¶
很多企业低估了用户心智变化这一层。系统能力已经上线，用户却还在按旧方式使用，价值释放自然很慢。传统系统训练出来的用户心智是这样的：我应该先去哪个页面？这个字段该填什么？哪个按钮能进入下一步？我怎样导出结果再交给别人？AI 原生系统要求的是另一套能力：我到底想完成什么任务？我应该给系统哪些约束？这个任务现在进行到哪一步？结果是否可信，是否需要我在高风险节点确认？这是一次明显的角色变化。用户不再主要是“系统操作者”，而更像“任务发起者”和“结果裁决者”。如果企业不帮助用户完成这种心智迁移，AI 原生系统就会出现很典型的问题：技术上能跑，业务上却用不起来。
3.4 AI 原生化的场景排序与迁移优先级¶
各业务域不会同时进入 AI 原生阶段。现实中，最先被改造的往往是那些“跨系统、跨知识源、跨角色”的任务；高度结构化、强事务、一步到位的操作通常不会排在最前面。
表3-1：适合优先 AI 原生化的任务类型及企业内的例子。来源：本书整理。
| 任务类型 | 为什么适合优先改造 | 一家多业务线企业里的例子 |
|---|---|---|
| 跨系统信息整合 | 人工切换系统和拼接结果成本很高 | 经营分析、销售复盘、售后诊断 |
| 文档密集型任务 | 规则和依据散落在文档与知识库中 | 合规审查、投标响应、合同审阅 |
| 草稿型输出 | 结果可以先生成，再交由人确认 | 报价草稿、经营周报、客户回复建议 |
| 诊断型任务 | 需要逐步缩小问题范围，而非单点查询 | 毛利异常分析、库存异常追因 |
相反，完全结构化、一次性、强事务性的流程，通常不会最先被 Agent 化。付款、签约、主数据删除这类动作，不会因为“AI 原生”四个字就突然适合自动化。如果一家多业务线企业一年只能重点推进三到五个 AI 原生场景，排序依据不能只是哪个部门最积极。更可靠的做法，是同时看业务价值、任务结构、数据准备度和风险可控性。
表3-2：典型场景在价值、结构、数据、风险各维度的评分与建议。来源：本书整理。
| 场景 | 业务价值 | 任务结构 | 数据准备度 | 风险可控性 | 建议 |
|---|---|---|---|---|---|
| 经营分析材料生成 | 高 | 高 | 中高 | 高 | 优先试点 |
| 客服工单质检 | 中高 | 中 | 高 | 高 | 优先试点 |
| 报价草稿生成 | 高 | 中高 | 中 | 中 | 加强审批后试点 |
| 自动客户邮件回复 | 中 | 中 | 中 | 低 | 谨慎 |
| 自动付款审批 | 高 | 低 | 中 | 极低 | 暂不做 Agent 自动化 |
这个排序不追求绝对正确，重点是让决策透明。很多 AI 项目失败，并非因为场景没有价值，而是因为一开始选了一个价值高、风险也极高、数据又没准备好的场景，最终消耗了组织信任。
3.4.1 AI 原生系统的信任建立¶
AI 原生系统能否被业务采用，最终取决于信任。这里的信任指向一个具体判断：用户是否敢把真实任务交给系统，也不能只看觉得模型回答得聪明。企业用户的信任通常来自五个来源。
表3-3：建立用户信任所需的几类系统供给。来源：本书整理。
| 信任来源 | 系统需要提供什么 |
|---|---|
| 可见过程 | 用户知道系统正在做什么，而非黑箱等待 |
| 可查证据 | 结论能追溯到数据、文档、规则或工具结果 |
| 可控风险 | 高风险动作必须确认、审批或降级 |
| 可恢复性 | 失败后能重试、接管、回滚或继续 |
| 可持续改进 | 用户反馈能进入评估和版本迭代 |
如果一个 Agent 输出很漂亮，但不给证据，业务用户最多会觉得它“有启发”；如果它能给证据、给状态、给审批入口，用户才会开始把它当成工作系统。AI 原生工作台需要超出聊天框。聊天框擅长表达，但很难承载完整的信任机制。任务状态、证据区、审批控件、回放入口，这些看起来没有“智能感”的东西，反而决定企业是否愿意采用。
3.5 AI 原生产品形态：任务助手、嵌入式 Copilot 与 Agent 工作台¶
用一家多业务线企业的路径来概括，企业大致会经历三个阶段。第一阶段是 AI 增强。每个系统都加上一点智能能力，但系统边界和协作方式没有实质变化。BI 还是 BI，CRM 还是 CRM，只是它们更会理解自然语言、更会总结内容。第二阶段是 Agent 嵌入。这时会出现一些跨系统任务的 Agent，它们能够组织一小段任务链，超出单点功能的范围。经营分析 Agent、报价 Agent、客服质检 Agent，往往都属于这个阶段。
第三阶段才是 AI 原生业务系统。用户面对的是以任务为中心的工作台，而不再主要面对某个旧系统。系统自己组织步骤、生成中间结果、发起审批、沉淀证据，旧系统则逐渐退居工具层。多数企业会长期停留在第一阶段和第二阶段之间。第三阶段不会一次完成，也不会让所有部门同步进入。它通常从最适合的业务域开始，然后再逐步扩散。企业通常会从旧系统内的 AI 增强，走向跨系统 Agent 嵌入，最终形成任务中心的 AI 原生业务系统。
图3-2：AI 原生业务系统的三阶段迁移。来源：本书自绘。Alt text：从左到右三个阶段，数字化（业务搬进系统）、AI 增强（旧系统加助手）、AI 原生（以任务为中心重构），箭头表示能力逐级累积而非推倒重来。
3.5.1 AI 原生系统应走向任务工作台¶
一说到 AI 原生前端，常见误解是：把搜索框换成聊天框，就算 AI 原生。这样远远不够。一个可用的 AI 原生工作台，至少要让用户看到五类东西。
表3-4：任务工作台各要素的作用。来源：本书整理。
| 工作台要素 | 作用 |
|---|---|
| 任务状态 | 告诉用户系统是在规划、执行、等待审批还是失败 |
| 证据与引用 | 告诉用户结果来自哪些数据、规则和文档 |
| 结构化结果区 | 图表、表格、草稿、待办不应全部淹没在对话气泡里 |
| 人工接管入口 | 当系统不确定时，用户必须能接手、修改、继续 |
| 审批与确认控件 | 高风险动作不能埋在普通消息流中 |
AI 原生前端通常会变成“对话 + 任务流 + 结构化结果 + 审批控件”的组合，单个大输入框很难承载完整任务链路。用户输入“生成经营分析材料”之后，不该只是等待系统吐出一段长文。更好的体验是：系统先显示任务目标和范围，让用户确认本次分析聚焦华东区、毛利率、上周数据；随后展示它准备查询哪些指标、引用哪些数据源；中间如果发现某个指标口径有两个版本，系统暂停让用户选择；输出阶段给出图表、结论、引用和待办，并允许用户把结果提交给会议材料审批流。这类体验才接近 AI 原生工作台；单纯在聊天框里塞一份报告，还停留在旧交互模式里。企业级任务工作台需要同时呈现任务状态、执行过程、证据引用、结构化结果、人工接管和审批确认。
图3-3：AI 原生任务工作台结构。来源：本书自绘。Alt text：工作台分为任务目标、执行进度、证据来源、人工确认入口等区域，中间是系统调用多个工具推进任务的主流程，体现"任务"而非"页面"作为组织中心。
3.6 经营分析会案例：从手工拼材料到任务工作台¶
可以用经营分析会这个案例，看 AI 原生业务系统怎样改变工作方式。一家多业务线企业每周一上午开经营分析会。传统模式下，周五下午开始，运营负责人会让各区域提交数据，数据团队导出销售、毛利、库存、促销、客诉等报表，运营专员把多个系统里的结果整理到 PPT，再找区域经理确认原因。到周一开会时，材料通常已经有了，但它有三个问题：一是数据口径容易不一致；二是异常追因常常依赖人工经验；三是会议上的行动项和后续跟进容易散落在邮件和群消息里。如果只是 AI 增强，每个系统都会变聪明一点。BI 能回答“华东区上周毛利率是多少”，工单系统能总结投诉，知识库能检索促销复盘。用户体验会改善，但运营负责人仍然要自己拼接。
如果进入 Agent 嵌入阶段，经营分析 Agent 可以接管一段任务链。用户提出目标：“准备下周一经营分析会材料，重点看华东区毛利率异常。”系统会先确认分析范围：时间、区域、指标、会议模板。随后它查询销售、毛利、促销、库存、客诉等数据，发现毛利率下降主要集中在两个品类，并进一步检查是否与促销折扣、物流成本、缺货替代销售相关。如果某个指标口径存在冲突，系统暂停让用户选择口径。最终，它生成的是一组会议材料：异常摘要、图表、证据引用、可能原因、待确认问题、建议行动项。用户可以修改结论，也可以把行动项派给区域负责人。如果进一步发展成 AI 原生经营工作台，变化会更明显。经营分析从每周临时拼材料，变成持续运行的任务空间。系统平时监控关键指标，发现异常后生成任务、积累证据，并提醒相关负责人补充解释。会议前，材料汇总这一周的任务状态、证据和决策建议；会议后，行动项继续在同一个工作台里跟进。三个阶段的差别可以概括为：
表3-5：经营分析会从传统模式到任务工作台各阶段的人机分工。来源：本书整理。
| 阶段 | 用户主要做什么 | 系统主要做什么 | 会议材料如何形成 |
|---|---|---|---|
| 传统模式 | 手动查、手动拼、手动问人 | 提供报表和记录 | 人工整理 |
| AI 增强 | 在多个系统里问 AI | 各自回答局部问题 | 人工拼接 AI 输出 |
| Agent 嵌入 | 定义分析目标，确认关键节点 | 跨系统追因，生成材料草稿 | Agent 生成，人复核 |
| AI 原生工作台 | 管理持续任务和行动项 | 持续监控、归因、沉淀证据 | 工作台自动汇总 |
这个案例里，AI 原生改变的是经营分析的组织方式：它从一次临时材料准备，变成持续的任务管理过程。系统除了生成内容，还会重组数据、证据、会议和行动之间的关系。AI 原生系统把跨系统取数、异常追因、证据沉淀、报告生成和行动项跟进组织成连续任务链。
图3-4：经营分析会从手工拼材料到任务工作台。来源：本书自绘。Alt text：上方"传统模式"中运营人员在 BI、库存、客服等系统间手动查询拼接材料，下方"任务工作台"中用户提出分析目标、系统自动取数诊断并生成带证据的材料，对比两条路径的步骤数差异。
3.6.1 用户培训应转向任务模板¶
很多企业上线 AI 原生系统后，会立刻组织“提示词培训”。这当然有用，但如果只教用户怎么写 prompt，反而会把问题带偏。企业用户更需要学习的是如何把工作表达成可执行任务。比如“帮我分析一下华东区”这个输入太宽泛。更好的任务表达应包含范围、目标、约束和交付物：“分析上周华东区毛利率下降原因，重点比较促销、库存和物流成本影响，输出会议材料草稿，并标明需要区域经理确认的问题。”这里考验的是任务定义能力，不是提示词技巧。因此，AI 原生系统应提供任务模板。任务模板帮助用户表达目标，也帮助系统稳定理解边界，比空白输入框更适合高频业务任务。
表3-6：经营分析任务模板各要素的作用。来源：本书整理。
| 模板要素 | 作用 |
|---|---|
| 任务目标 | 明确要完成什么，而非泛泛提问 |
| 分析范围 | 限定时间、区域、品类、客户或流程 |
| 约束条件 | 指定口径、规则、风险边界 |
| 交付物 | 说明要报告、图表、草稿、建议还是行动项 |
| 人工节点 | 指明哪些地方需要确认或审批 |
一家多业务线企业可以为不同场景准备一组任务模板：经营分析模板、报价草稿模板、客服质检模板、票据异常模板、合同条款审阅模板。用户从业务任务开始，不必从空白对话开始。这样能降低使用门槛，也让平台更容易评估和治理。任务模板还有一个额外价值：它把组织经验固化下来。优秀运营经理如何准备经营分析会，资深销售如何判断报价风险，财务主管如何检查票据异常，这些经验都可以逐步沉淀进模板。AI 原生系统的长期价值，正是在这种沉淀中出现。AI 原生业务系统应围绕不同角色的高价值任务建立工作空间，并保留必要的功能模块入口作为支撑。
图3-5：从功能菜单到角色任务地图。来源：本书自绘。Alt text：左侧是按系统模块组织的功能菜单树，右侧是按运营、销售、客服等角色组织的高频任务地图，箭头表示产品组织方式从"功能优先"转为"角色任务优先"。
3.7 AI 原生迁移的评审方法¶
AI 原生迁移不能只看界面是否有对话入口，也不能只看模型是否能生成一段完整答案。更合适的评审对象是一条任务链。团队可以从三个角度判断一个现有流程是否适合迁移。第一，看任务是否存在明显的跨系统拼接。若用户每天都在 BI、CRM、工单、知识库和审批系统之间复制信息，说明任务入口已经有重组价值。第二，看任务是否需要解释和证据。经营分析、合同审阅、客服质检这类任务，用户不会只接受结论，还要知道依据来自哪里、哪些地方需要确认。第三，看任务是否能被分成自动、确认、审批和禁止几类动作。若所有动作都强事务、强合规、不可撤销，迁移时就应先停在辅助和草稿层。
评审还要识别旧系统的权威边界。AI 原生工作台可以组织任务，但不能替代系统 of record。客户主数据仍应由 CRM 管，订单和库存仍应由 ERP 管，指标事实仍应由数据平台和语义层管，合同版本仍应由合同系统或文档治理体系管。Agent 可以调用这些能力、解释这些结果、把它们组织成任务产物，但不能在旁边维护一套难以审计的影子事实。很多 AI 原生项目失败，原因常常在于团队为了追求体验流畅，绕开了原系统里的权威数据、审批责任和变更记录。
迁移评审最好输出一张“任务迁移说明”。它要写清楚当前人工流程有哪些步骤，哪些步骤保留在旧系统，哪些步骤变成工具调用，哪些步骤由 Agent 编排，哪些节点需要人工确认，哪些产物可以进入后续流程。这样产品、平台、数据和安全团队可以围绕同一份材料讨论，而不是分别讨论界面、模型、数据和权限。AI 原生迁移的目标，是把高频、高价值、可验证的任务链逐步移到可观察的系统里，而不是把所有操作一次性变成自动执行。
3.8 AI 原生系统的迁移路径¶
AI 原生业务系统不是把所有页面改成聊天框。更现实的迁移路径，是先识别哪些业务流程已经存在大量跨系统切换、人工复制、指标解释和审批等待，再把这些流程改造成任务入口。Agent 在这里承担的是任务协调角色：理解目标、调用工具、组织证据、等待确认、生成产物。界面形态可以是对话，也可以是工作台、报告页或嵌入式 Copilot。迁移时要保护既有系统边界。CRM、ERP、BI、数据仓库和工单系统仍然是权威系统。Agent 如果绕过它们直接维护另一套事实，后续对账、审计和权限都会出问题。AI 原生层更像一层任务编排和解释界面，把既有系统的能力组织成更顺的工作流。这样做的好处是风险可控：业务数据仍由原系统治理，Agent 平台负责意图、状态、证据和动作协调。这也是本书强调平台而非单个 Agent 的原因。单个 Agent 可以改善一个入口，但 AI 原生系统需要统一的模型路由、工具治理、语义层、状态机、可观测性和安全策略。没有平台，业务系统会出现许多孤立 Copilot；有了平台，企业才有机会把这些入口连接成可运营的任务网络。
3.9 迁移节奏与验证证据¶
AI 原生迁移要有节奏。第一步通常从原系统中的高频任务链开始，让用户在熟悉入口中看到 AI 如何减少查找、复制、解释和整理。比如在 BI 页面中加入异常解释 Copilot，在客服系统中加入质检摘要，在合同系统中加入条款审阅草稿。这一步应收集真实问题、真实样本和真实边界，暂时不追求完整自动化。用户是否愿意采用、哪些答案经常被修改、哪些数据口径最容易争议，都会成为后续平台化的材料。
第二步是把跨系统链路抽出来。若一个任务稳定地需要读取多个系统、组织证据、生成草稿并等待确认，就可以进入 Agent 编排。此时系统要明确状态：任务已创建、证据已收集、工具调用中、等待用户确认、等待审批、已生成产物、已提交下游流程或已失败。状态清楚后，产品和工程团队才能讨论恢复策略。比如经营分析材料生成失败时，是重新查数、降级为草稿、转给人工，还是推迟会议材料提交；这些判断都要写进任务链。
第三步是把重复任务沉淀成角色工作台。工作台把模板、状态、证据、结构化产物、审批、行动项和复盘放在同一个空间，承担的职责超过聊天窗口。到了这个阶段，AI 原生系统的价值来自生成内容，也来自任务知识的积累：哪些异常经常出现，哪些解释被业务接受，哪些行动项能真正改善指标，哪些审批节点总是阻塞。平台可以把这些记录反馈给语义层、评测集、模板和工具策略，让系统越用越贴近组织真实工作。
迁移是否成功，要看证据而非看演示。团队至少应保存四类材料：迁移前人工流程的步骤和耗时，迁移后任务链的状态记录，用户修改和退回的样本，进入下游流程的产物质量。若只看到模型生成了一份漂亮报告，却看不到数据口径、引用来源、人工确认和行动项执行情况，就不能说明迁移已经成功。AI 原生项目的验收应围绕工作是否被更稳定地完成，而不是围绕界面是否更像对话。
3.10 任务工作台的验收材料¶
AI 原生工作台的验收材料要面向真实工作，而非面向演示流程。第一类材料是任务前后的流程对比：原来用户要打开哪些系统、复制哪些字段、等待哪些人确认；迁移后这些步骤分别由工具调用、Agent 编排、人工确认还是审批流程承担。第二类材料是证据与状态记录：任务何时创建，哪些数据源被读取，哪些证据被引用，哪些节点暂停，谁确认了最终产物。第三类材料是用户改动样本：用户删掉了哪些结论，补充了哪些解释，退回了哪些行动项。这些样本能说明系统离真实工作还有多远。
工作台还要验证组织适配。一个经营分析工作台如果只让运营负责人生成材料，却不能把待确认问题发给区域经理，不能把行动项进入任务系统，不能把会议后的跟进状态带回下一次分析，就仍然停留在内容生成层。AI 原生迁移的价值，要体现在任务持续运行上：异常有负责人，证据有来源，决策有记录，行动有跟踪，下一次任务能复用这些历史。验收材料覆盖这些环节后，团队才能判断工作台是否真正改变了业务组织方式。
3.11 AI 原生系统的迁移边界¶
AI 原生业务系统并不要求企业推翻已有系统。更常见的路径，是先识别哪些任务需要自然语言理解、工具编排、证据引用和人工复核，再把这些任务从旧系统中抽出一条可管理的链路。订单、客户、合同、工单、报表、审批仍然可以留在原系统；Agent 平台负责在这些系统之间组织任务、保留证据和处理异常。这样迁移不会变成一次大规模重构，而是围绕具体任务逐步建立新的运行层。
迁移边界要写清楚读写责任。只读查询可以先进入 Agent；会改变业务状态的动作，需要 Tool Registry、Policy Engine、HITL 和 Trace 同时准备好；跨系统写入要先确定幂等、补偿和回滚方式。很多项目失败的原因不在模型能力，而在写操作接管过早：旧系统没有提供可恢复接口，业务团队也没有定义责任人。AI 原生系统的建设顺序应从证据充足、风险可控的任务开始。
迁移还要保留用户习惯。企业用户已经熟悉原系统里的筛选器、审批流、报表和字段名称。Agent 可以用自然语言降低入口门槛，但不能把所有原有操作都藏进黑盒。早期更适合让 Agent 解释当前任务、推荐下一步、调用受控工具，并把结果写回原系统的可审计位置。等运行证据稳定后，再逐步把更多流程改造成 AI 原生体验。
3.12 迁移后的组织验收信号¶
AI 原生迁移完成后，验收不能只看用户是否打开新入口。更有价值的信号来自任务是否真的改变：用户是否少在系统之间复制信息，异常是否能带着证据进入会议，行动项是否进入下游系统，人工修改是否被平台记录并回流。若用户仍然把 Agent 输出复制到文档里再手工处理，说明系统只是增加了一个生成入口，任务组织方式还没有改变。
组织验收还要观察责任是否更清楚。旧系统里，责任通常落在操作人身上；AI 原生工作台引入 Agent 后，责任会分散到数据 owner、工具 owner、审批人、报告 reviewer 和平台 owner。上线验收应检查每个关键节点是否能找到负责人，尤其是数据口径冲突、自动建议出错、审批超时和行动项未完成这些场景。责任不清时，体验越流畅，风险越容易被隐藏。
早期 AI 原生迁移可以设定少量可观察指标：任务完成时间、跨系统切换次数、用户改写比例、人工退回原因、证据点击率、行动项完成率和异常复盘次数。这些指标不会一次证明系统成功，但能让团队看到迁移是否沿着正确方向推进。AI 原生系统的成熟，不在于界面有多像对话，而在于组织是否开始围绕任务、证据和责任运转。
3.13 任务工作台的复盘材料¶
任务工作台上线后，应保留复盘材料。材料包括任务模板、用户输入、系统调用、证据引用、人工修改、行动项和最终状态。没有这些材料，团队只能评价界面是否顺手，无法判断 AI 原生迁移是否真的减少了跨系统复制、指标争议和会议后遗漏。
复盘材料还帮助产品持续收敛。用户反复删掉某类结论，说明报告模板或证据选择有问题；用户总是补充同一类解释，说明语义层或知识库缺内容；行动项长期没人接收，说明工作台没有接到真实组织流程。AI 原生迁移要靠这些运行记录逐步修正。
3.14 AI 原生迁移的反向修正¶
AI 原生迁移还需要反向修正机制。上线后的真实任务会暴露前期设计看不到的问题：某些工具被频繁绕过，说明任务链没有贴近用户习惯；某些报告经常被人工重写，说明模板或证据选择不稳定；某些行动项无人接收，说明工作台没有接入真实组织流程；某些审批节点长期超时，说明责任人和通知链路没有设计好。这些问题不能只归类为用户培训不足。它们应回写到任务设计、语义层、工具契约、审批流程和评测样本中。
反向修正要有固定入口。任务工作台可以每月抽样一批真实 Run，查看用户改写、工具失败、证据替换、审批退回和行动项关闭情况。产品团队据此修正工作台流程，数据团队补语义层和知识库，平台团队修 Runtime、Registry 和 Trace，安全团队补策略样本。这样 AI 原生迁移会形成持续改进，而不是一次上线后等待下一个大版本。
早期可以把反向修正控制在少量高频任务上。比如经营分析工作台只跟踪异常解释、证据引用、行动项分派和会议材料导出；客服工作台只跟踪质检摘要、知识引用、工单创建和人工接管。每类任务都有复盘样本、owner 和下一次修订计划。迁移的质量不在于一次把系统设计完整，而在于真实任务能不断修正平台能力。
3.15 AI 原生迁移后的运行校准¶
AI 原生迁移完成后，团队还需要做运行校准。原来的系统通常以页面、按钮和审批流为边界，迁移后则以任务、Run、工具调用和 artifact 为边界。用户可能觉得任务入口更自然，但也可能因为系统自动拆解步骤而看不清进度；业务 owner 可能看到交付速度变快，却发现责任记录、人工复核和异常恢复不够清楚。迁移验收不能只看新界面是否可用，还要看运行语义是否稳定。
运行校准应从真实任务样本开始。团队可以选择一组迁移前后都存在的任务，例如会议材料准备、合同条款查找、经营指标解释、工单分派和报告发布。比较时不只看完成时间，还要看用户输入是否变短、系统澄清是否合理、工具调用是否减少人工复制、证据是否完整、审批是否进入正确节点、异常是否能恢复。这样迁移收益会落到任务链路，而不是停留在“界面更智能”的主观感受。
校准也要处理用户习惯变化。AI 原生系统会把一些原先显式的操作藏到后台，用户可能失去控制感；也会把一些原先隐性的判断显式化，用户可能觉得流程变长。产品设计要把高风险动作、等待状态、证据引用和人工节点展示出来，让用户知道系统正在处理什么。对于低风险任务，可以减少中间确认；对于会改变业务状态的任务，则应保留明确确认和撤回路径。
早期可以在每个迁移场景上线后做一次 30 天复盘。复盘材料包括任务完成率、人工接管、用户取消、工具失败、报告退回、审批超时和用户反馈。若结果显示用户频繁绕回旧系统，说明任务入口或运行解释不足；若结果显示 Agent 完成率高但争议多，说明证据和责任记录不足。AI 原生迁移的质量，要通过运行校准持续验证。
3.16 AI 原生迁移的用户工作方式变化¶
AI 原生迁移最终会改变用户的工作方式。传统系统把用户带到页面、菜单和字段里，用户自己判断下一步；任务工作台则把目标、证据、工具和产物放在一个运行链路中。用户不再只是点击按钮，还会确认计划、补充证据、复核产物、处理异常和决定是否发布。若产品设计仍按页面功能组织，AI 能力只会变成新的入口，不能改变任务完成方式。
这种变化需要提前管理预期。用户需要知道哪些动作由 Agent 自动完成，哪些动作需要自己确认，哪些结论只是草稿，哪些输出已经进入正式流程。业务 owner 也需要知道系统会保存哪些证据、哪些反馈会进入评测、哪些错误会触发人工复核。AI 原生系统的可用性不只取决于模型能力，还取决于用户是否理解自己在任务链路中的位置。
早期迁移可以选择一个高频但可控的任务，例如经营分析材料准备、合同条款初审或客服知识问答。团队先把输入、工具、证据、审批和产物治理跑通，再扩展到更多流程。这样 AI 原生迁移会从“界面里加一个助手”推进到“围绕任务重组系统”，也能让读者理解后续平台工程章节为何必要。
3.17 AI 原生系统的工程判断¶
AI 原生业务系统进入生产后，新增能力不能只看功能是否可用，还要看运行证据能否被不同角色复用。平台需要把任务边界、数据契约、人工复核、系统反馈和运营指标记录成稳定字段，并和发布单、Trace、评测样本以及事故记录关联起来。这样一次线上问题发生后，团队可以沿着同一组事实判断影响范围、责任归属和修复顺序，而不是在模型日志、业务日志和人工说明之间来回拼接。
这类证据还要服务相邻章节的能力。它和第22章 Runtime、第32章 DataAgent 和第53章组织治理相连：上游能力提供输入假设，下游能力使用执行结果，治理能力负责保存证据和复审结论。若这些材料没有统一编号和版本，章节里讨论的工程能力在生产中会被拆散。业务 owner 只能看到用户投诉，平台 owner 只能看到系统错误，安全或合规团队只能看到事后说明，最后很难判断问题到底来自数据、模型、工具、流程还是组织责任。
生产环境中常见的风险包括把对话入口当成业务系统、把模型建议当成流程状态、缺少复核和撤回机制。这些问题在演示阶段不明显，因为演示通常只覆盖成功路径；上线后，用户会带来边界问题、重复请求、权限变化和长时间运行状态。平台团队应把失败样本纳入发布节奏，记录哪些样本需要阻断发布，哪些样本可以通过降级处理，哪些样本需要业务 owner 接受剩余风险。
AI 原生系统应从业务状态和责任链设计开始，再决定模型如何参与。这份记录不需要复杂，但要包含时间、版本、owner、样本、处置动作和下次复查条件。没有这些字段，复盘会停留在口头经验；有了这些字段，平台才能把一次问题转成后续发布、评测和培训材料。
早期平台可以从少量高风险场景开始。先选择调用量高、业务影响大或涉及敏感数据的路径，要求每次变更都留下证据包，再逐步推广到普通场景。这样章节里的能力不会停留在概念层，而会成为可运行、可解释、可退回的工程系统。
3.18 AI 原生业务系统的上线门槛¶
AI 原生业务系统的上线门槛应高于普通对话应用。系统如果会改变工单状态、生成经营报告、触发审批、调用外部工具或影响客户沟通，就已经进入业务流程。此时验收不能只看模型回答是否流畅，还要看状态是否可追踪、工具动作是否可撤回、人工复核是否有效、用户是否知道当前结果的可信范围。
上线门槛可以分成三层。第一层是任务边界，明确哪些请求能自动处理，哪些进入辅助模式。第二层是运行证据，确保每次 Run 有输入、计划、工具、输出、人工动作和最终 artifact。第三层是组织责任，确认业务 owner、平台 owner、数据 owner 和安全联系人都存在。三层缺一项，系统可以继续试点，但不应扩大到关键业务流程。
本章小结¶
本章把“AI 原生业务系统”拆回几个可判断的问题。AI 原生的核心变化，是系统开始围绕任务组织自己；页面仍然存在，但不再是组织业务流程的唯一中心。旧系统会退到工具层，但不会消失；它们仍然提供事实、规则、权限、审计和事务一致性。最适合优先进入 AI 原生阶段的，是那些跨系统、跨知识源、可生成草稿、可做诊断的任务。前端也应按任务工作台设计，让目标、证据、状态、风险确认和产物交付同时可见；单纯放大聊天界面，很难承载这些工作。AI 原生会牵动产品、数据、平台、安全与业务协作方式，按纯技术项目推进会很快遇到组织边界。下一章会把这些判断收束到一张完整地图中，说明本书为什么要按模型、数据、知识、平台、评估、安全这条路线展开。
参考文献¶
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.