从 Copilot 到 Agentic Enterprise：为什么企业 AI 的下一场竞争在价值流？

过去几年，企业对 AI 的投入可谓前所未有。

从早期的 Chatbot，到基于大语言模型的 Copilot，再到如今能够自主规划、调用工具和执行任务的 AI Agent，企业 AI 正在经历一轮快速演进。

但一个问题始终没有得到充分解决：

为什么 AI 的能力越来越强，企业能够真正获得的商业回报却没有同步增长？

2026 年，IBM 商业价值研究院（Institute for Business Value，IBV）发布了《Redesign for Enterprise AI: Focus on Critical Value Streams to Drive Growth》报告。[1]

报告提出了一个值得关注的判断：

企业 AI 的价值，不应停留在单个任务或局部工作流的效率提升，而应该通过重构端到端的业务价值流（Value Stream），真正影响企业的收入、利润与竞争优势。

这与 McKinsey、Deloitte 等咨询机构近年来的研究结论形成了呼应。

企业 AI 的竞争，正在从模型能力的竞争，逐渐延伸为业务流程、组织架构、数据治理和智能决策体系的综合竞争。

而这背后，可能意味着企业软件架构正在进入一个新的演进阶段。

1. AI 投入越来越大，为什么企业回报却不明显？

先看几组数据。

IBM IBV 在 2026 年的研究中发现：

• 截至 2025 年底，仅有 37% 的 AI 项目实现了最高管理层预期的业务成果。
• 仅有 17% 的 AI 项目进入全面规模化生产。
• IT 与业务体系之间的内耗，造成了约 21% 的 AI 投资回报损失。
• 仅有 25% 的受访高管表示，其组织采用统一方式衡量 AI 的业务价值与投资回报率。[1]

这些数字揭示了一个现象：

企业并不缺少 AI 项目，而是缺少能够持续创造价值的 AI 系统。

类似的问题也出现在其他研究中。

McKinsey 在《The State of AI in 2025: Agents, Innovation, and Transformation》中指出，尽管 AI 已得到广泛应用，但只有 39% 的受访者表示 AI 对其组织的企业级息税前利润（EBIT）产生了一定影响，而且其中大多数组织的影响幅度仍低于 5%。[2]

Deloitte 的《The State of AI in the Enterprise 2026》同样指出，企业已经开始从 AI 效率提升走向业务变革，但真正重新构想业务运行方式的组织仍只有 34%。[3]

值得注意的是，这几份报告的调查对象、统计口径和指标定义并不相同，因此不能简单进行横向比较。

但它们共同反映出一个趋势：

AI 技术的普及速度，已经超过了企业业务体系的重构速度。

为什么会这样？

原因或许并不复杂。

很多企业最初采用 AI 时，选择的是阻力最小的路径：

让员工使用 AI 写邮件、总结会议、生成代码、分析文档，或者在客服系统中加入智能问答能力。

这些应用确实能提高效率。

但提高某个岗位的工作效率，并不必然意味着整个企业创造了更多价值。

假设一个企业的客户订单处理流程包含六个步骤：

客户提交订单 → 订单审核 → 库存检查 → 支付确认 → 物流履约 → 售后服务。

现在，企业引入 AI，将订单审核时间从 10 分钟缩短到 1 分钟。

看起来效率提高了 90%。

但如果库存检查仍然需要数小时，物流履约仍然依赖人工协调，客户等待时间可能并不会显著减少。

AI 只是加快了一个局部环节，瓶颈却转移到了下游。

这也正是 IBM 报告反复强调的问题：

局部最优，不等于全局最优。

如果企业只是把 AI 添加到原有流程中，却不改变流程本身，那么 AI 创造的价值就很容易被传统业务体系中的摩擦所消耗。

2. 从 Copilot 到 Agent：企业 AI 的演进逻辑

回顾企业 AI 的发展，可以将其概括为三个具有代表性的阶段。

需要说明的是，这是一种便于理解的技术演进划分，而不是所有企业都必须遵循的固定路径。

2.1 第一阶段：Copilot——辅助人完成任务

Copilot 模式的核心，是让 AI 成为人类工作的辅助工具。

典型场景包括：

• 程序员使用 AI 辅助编程；
• 销售人员使用 AI 生成客户邮件；
• 财务人员使用 AI 辅助分析报表；
• 法务人员使用 AI 总结合同；
• 管理者使用 AI 整理会议纪要。

在这种模式下，AI 主要负责提供建议、生成内容或辅助分析。

人类仍然负责发起任务、连接业务环节，并完成最终决策。

其核心价值是：

Human Productivity（个人生产力提升）。

Copilot 能帮助一个人完成更多工作，却不一定能让整个组织运行得更高效。

2.2 第二阶段：AI Agent——从生成内容走向执行任务

随着大语言模型的推理、工具调用及上下文处理能力不断发展，AI 开始从被动响应指令，转向主动完成多步骤任务。

Anthropic 在《Building Effective Agents》中对 Workflow 和 Agent 作出了区分。[4]

简单来说：

Workflow 通常通过预定义的代码路径组织模型和工具，而 Agent 则允许模型在一定范围内动态决定执行流程及工具使用方式。

例如，一个客服 Agent 不再只是回答：

“您的订单目前正在运输中。”

它还可以在授权范围内：

1. 查询订单系统；
2. 检查物流状态；
3. 判断是否存在配送异常；
4. 查询企业的补偿政策；
5. 生成处理建议；
6. 根据风险等级自动执行，或者请求人工审批。

此时，AI 的角色已经从信息提供者转变为任务执行者。

核心价值也从个人生产力提升，进一步扩展到：

Task Automation（任务自动化）与 Workflow Automation（工作流自动化）。

但问题也随之而来。

如果每个部门都部署自己的 Agent，会不会再次形成新的系统孤岛？

销售 Agent、客服 Agent、采购 Agent、供应链 Agent 各自拥有独立的数据、工具和业务逻辑，它们之间如何协作？

一旦跨部门执行出现异常，谁来负责？

这些问题并不能仅靠更强的大模型解决。

2.3 第三阶段：Agentic Enterprise——以智能体重构业务价值流

Agentic Enterprise 可以理解为一种以 AI Agent 为重要执行和决策能力的企业运行模式。

它不再只是让每个岗位拥有一个 AI 助手，也不仅是把若干 Agent 拼接起来。

更关键的是：

围绕完整业务目标，重新组织人、Agent、系统、数据和决策权限。

例如，在一个端到端的订单履约场景中：

销售 Agent 负责理解客户需求，库存 Agent 检查可用资源，调度 Agent 制定履约方案，风控 Agent 检查异常风险，客服 Agent 负责持续沟通。

这些 Agent 不应只是彼此孤立地完成局部任务。

它们需要共享可靠的业务状态，在统一的流程约束下协作，并由明确的业务责任主体对最终结果负责。

最终衡量的，也不再是某个 Agent 调用了多少次工具、节省了多少 Token。

而是整个订单履约过程是否更快、更准确、更经济，客户体验是否真正改善。

这就是从 Copilot 走向 Agentic Enterprise 的关键变化。

AI 不再只是增强员工的工具，而开始成为企业业务执行体系的一部分。

3. 为什么下一场竞争的关键是 Value Stream？

IBM 报告中有一个非常值得关注的概念：Value Stream，价值流。

报告明确区分了四个层级。[1]

这一区分为什么重要？

因为 AI 所作用的层级，往往决定了它能够影响的价值范围。

例如，在软件开发领域：

AI 可以帮助开发者提高代码生成效率，这是 Task 层面的优化。

AI 可以辅助编码、测试和代码审查，这是 Workflow 层面的优化。

但如果需求分析、研发排期、系统集成、发布审批和生产运维之间仍然存在大量等待与返工，即使代码生成速度提高数倍，业务需求的整体交付周期也未必明显缩短。

真正值得优化的，是从业务需求提出，到功能正式上线并产生用户价值的完整链条。

这一点也与软件工程中的价值流管理、精益思想和 DevOps 有着相似的底层逻辑。

优化一个步骤容易，优化多个步骤之间的依赖关系才更难。

3.1 从 Cost Saving 转向 Revenue Growth

长期以来，企业讨论 AI ROI 时，最容易想到的是降低成本。

例如减少客服人力、节省文档处理时间，或者提高代码开发效率。

这些收益当然重要。

但 IBM 报告强调，企业 AI 不应只关注成本削减，还应优先考虑那些直接影响客户价值和收入增长的核心业务流程。

报告以一家年营收约 170 亿美元的典型企业为例：

• 行政及一般费用降低 1%，约节省 2,400 万美元；
• 核心交付流程成本改善 1%，约节省 1.02 亿美元；
• 企业营收提高 1%，对应约 1.7 亿美元营收增长。[1]

报告据此指出，面向客户的价值流优化，可能带来远高于后台行政成本优化的经济影响。

当然，营收增长不能直接等同于利润增长。新增收入也可能伴随交付、运营及获客成本，因此实际 ROI 仍需完整核算。

但这一分析揭示了企业 AI 投资的一个重要方向：

与其只问 AI 能帮我们省多少钱，不如进一步思考，AI 能让我们创造哪些过去难以实现的业务价值。

例如：

过去由于复杂订单需要多部门人工协同，企业只能服务部分高价值客户。

如果 AI Agent 能够在风险可控的前提下完成需求识别、方案配置、资源匹配和报价协同，企业可能有能力以更低的边际成本服务更多客户。

这就不只是效率提升，而是商业能力的扩展。

4. 从 Agent Demo 到生产系统：企业架构需要怎样变化？

如果说 Value Stream 决定了 AI 应该优化什么，那么企业技术架构就决定了 AI 能否真正完成这些工作。

IBM 报告认为，要实现 Agentic AI 的规模化，企业需要同时改造四个方面：

架构、数据、决策权，以及业务与 IT 运营模式。[1]

从工程实施角度看，我认为可以进一步将这些要求映射为五项企业级 Agent 能力。

4.1 Agent Orchestration：从任务调用走向业务编排

企业 Agent 不可能永远只执行一次简单的工具调用。

真实业务具有长期运行、跨系统协作、多步骤依赖、异常恢复以及人工干预等特点。

因此，Agent Orchestration 不应仅仅被理解为多个 Agent 之间的消息传递。

它还需要考虑：

• 任务状态如何持续保存；
• 多个 Agent 如何共享上下文；
• 业务执行失败后如何重试或补偿；
• 哪些步骤必须等待外部事件；
• Agent 如何执行长时间运行的任务；
• 人类何时介入，以及如何恢复执行。

这与过去企业软件架构中的 BPM、工作流引擎、Saga、事件驱动架构等设计思想有很强的联系。

区别在于，传统业务编排大多基于预先定义的流程，而 Agent 可以在授权范围内动态选择执行路径。

这也带来了新的架构挑战：

如何在保持 Agent 灵活性的同时，确保业务执行过程可控、可恢复、可审计？

我的看法是，企业级 Agent 系统不应该追求一切决策都由模型自主完成。

对于确定性强、规则清晰的任务，传统程序依然具有成本、性能和可预测性优势。

对于需要理解复杂上下文、处理不确定性和动态选择执行路径的任务，Agent 才更可能体现价值。

因此，未来企业的工作流编排，很可能长期采用确定性程序与概率性智能决策相结合的混合架构。

这也符合 Anthropic 关于优先采用简单、可组合 Agent 模式的工程建议。[4]

4.2 Agent Memory：企业需要的不只是更长的上下文

随着 Agent 参与越来越复杂的业务流程，Memory 将成为一个重要的基础能力。

但 Memory 的核心问题，并不是单纯存储更多历史对话。

企业 Agent 需要区分多种信息：

• 相对稳定的业务规则与知识；
• 随业务运行不断变化的实时状态；
• 用户历史偏好与长期上下文；
• 当前任务的执行进度；
• 决策历史及其依据。

例如，一个采购 Agent 昨天获知某供应商具有较充足的库存。

但今天，库存系统已经显示相关商品缺货。

如果 Agent 仍然依据昨天的记忆作出采购承诺，就可能造成错误决策。

这实际上涉及 Memory 与实时业务数据之间的一致性问题。

IBM 报告提出了一个概念：Warm Data（温数据）。

它强调数据应持续更新、受到治理，并且能够在业务价值流中被实时访问。[1]

这一要求与企业级 Agent Memory 的发展方向高度相关。

未来需要重点解决的可能不只是 Memory Retrieval，而是：

Memory Governance。

例如：

当新旧记忆发生冲突时，系统应该相信哪一条？

当业务状态变化时，旧的记忆是否应该失效？

当不同 Agent 共享信息时，如何确保状态一致性？

当 Agent 做出错误判断时，能否追溯当时使用了哪些上下文？

这些能力会直接影响企业 AI 系统的可靠性。

需要说明的是，Warm Data 侧重实时业务数据的访问与治理，并不等同于 Agent Memory。两者是相互关联但职责不同的架构组件。

4.3 Governance：Agent 不能拥有无限决策权

Agent 与传统 Copilot 的一个重要区别，在于它可能直接执行会改变业务状态的动作。

例如修改订单、发起付款、调整价格、取消合同，或者变更生产环境配置。

这意味着 Agent 不能仅仅依赖模型的输出内容判断操作是否安全。

企业需要建立独立的授权与治理机制。

NIST 发布的《AI Risk Management Framework》及其生成式 AI 配套指南，为 AI 系统风险管理提供了重要参考。[5][6]

在实际架构中，可以考虑将 Agent 的决策权限划分为几个等级：

这里的 L0–L4 是一种工程示例，并非 NIST 或 IBM 发布的标准分级。

权限提升应基于可验证的运行表现，而不是模型能力宣传。

例如，决策准确率是否达到要求、异常处理是否可靠、系统是否具备完整审计轨迹，以及风险是否处于组织可接受范围内。

更重要的是，Agent 的决策权限应该由外部策略和业务治理体系约束，而不是由 Agent 自己决定。

4.4 Evaluation：Agent 的正确率不等于业务成功率

当前许多 Agent 测试仍然关注：

• 任务完成率；
• 工具调用正确率；
• 模型输出准确率；
• Token 使用量；
• 推理延迟。

这些指标很重要，但主要评价技术表现。

企业更需要回答的是：

Agent 是否真正改善了业务？

例如，一个订单处理 Agent 的任务执行准确率达到 98%，听起来不错。

但如果剩余 2% 的错误恰好涉及高价值订单，而且每次错误都需要多小时的人工补救，那么企业仍然可能承担高昂的运营成本。

因此，需要将 Agent Evaluation 与 Business KPI 连接起来。

从工程角度看，可以建立三层评价体系。

第一层是 Model Evaluation，评估模型的推理、工具调用以及内容生成能力。

第二层是 Agent Evaluation，评估任务完成、异常处理、执行可靠性和成本。

第三层是 Business Evaluation，评估整个价值流的成本、收入、质量、周期和客户体验。

对于生产系统，我认为第三层应该成为最终评价依据。

技术指标决定 Agent 能不能工作，业务指标决定 Agent 值不值得部署。

4.5 Platform Engineering：Agent 需要企业级运行基础设施

企业内部每增加一个 Agent，都可能引入新的模型、工具接口、数据权限和运行依赖。

如果缺乏统一的基础设施，企业可能很快出现类似早期微服务发展阶段的问题：

系统数量持续增长，但集成、治理和维护成本也不断增加。

因此，企业级 Agent 平台需要提供一些共性能力：

• 模型访问、路由与成本控制；
• 工具接入与身份权限管理；
• Agent 运行状态管理；
• 记忆与上下文服务；
• 执行日志、链路追踪与评估；
• 安全策略与审计；
• 异常处理与人工接管。

这些能力适合被沉淀为可复用的平台组件，而不是由每个业务团队重复开发。

IBM 报告所倡导的跨环境统一执行层，也可以从这一角度理解。

需要强调的是，统一不一定意味着所有 Agent 都必须使用相同的模型、框架或技术栈。

更合理的目标，是让不同 Agent 遵守一致的集成、治理、运行和观测规范。

5. 一个可能的企业级 Agentic Enterprise 架构

结合前面的讨论，可以将 Agentic Enterprise 抽象为以下逻辑架构。

这是一种概念性设计，并非 IBM 报告提供的标准架构。

第一层：Business Value Stream

定义订单履约、客户服务、供应链管理、软件交付等端到端业务目标。

这一层主要负责业务目标、价值流、KPI 和最终责任归属。

第二层：Agent Orchestration

负责将业务目标转换为可执行的任务，并协调多个 Agent 及人类参与者。

其核心包括任务编排、状态管理、任务依赖、异常恢复和人工审批。

第三层：Agent Runtime

提供模型调用、工具使用、上下文管理、Memory、任务执行及反馈机制。

这一层可以采用不同的 Agent 框架或运行环境。

第四层：Enterprise Integration

通过 API、事件流、消息系统和数据访问层连接企业现有的 ERP、CRM、WMS、OA、数据库及其他业务系统。

第五层：Infrastructure

提供计算、存储、网络、模型服务、可观测性和可靠性保障等基础设施能力。

此外，Governance、Security 和 Evaluation 应作为跨层能力，贯穿从业务目标到基础设施的整个执行链条。

在这个架构中，一个非常重要的原则是：

Agent 不应绕过企业既有的业务规则和安全机制直接操作核心系统。

即使底层模型具有较强的推理能力，业务状态变更、敏感数据访问以及高风险操作，依然需要受到明确的系统约束。

换个角度理解：

Agent Runtime 负责提供智能执行能力。

Agent Orchestration 负责协调智能执行过程。

Enterprise Integration 负责连接真实业务系统。

Governance 负责确保执行行为始终处于可控范围。

Value Stream 则决定这些能力最终要创造什么价值。

如果缺少最后这一层，企业即使搭建了复杂的 Agent 平台，也未必能够证明其商业价值。

6. 企业组织形态也需要改变：从项目团队到人机混合团队

技术架构并不是 Agentic Enterprise 面临的唯一问题。

实际上，企业现有的组织结构也可能成为 AI 规模化的阻力。

传统 IT 项目通常采用分阶段交付：

需求分析 → 方案设计 → 系统开发 → 测试上线 → 运维交接。

不同阶段由不同团队负责。

这种模式适合目标相对明确、交付边界清晰的系统建设。

但 Agent 系统在上线后，仍需要持续优化提示词、模型、工具、业务规则、记忆机制和风险策略。

同时，业务部门需要根据真实运行表现持续反馈。

如果团队在系统上线后就解散，很难形成长期改进机制。

IBM 报告建议，企业应该建立持续负责端到端业务价值的跨职能团队，而不是仅围绕短期试点组建项目团队。[1]

这种组织形态可以理解为：

Business + Engineering + Data + AI Agent + Governance 的持续协作体系。

人类员工与 Agent 各自承担不同职责。

Agent 负责处理适合自动化的任务、分析数据、执行被授权的动作。

人类则负责业务目标设定、重要决策、风险监督、异常处理和持续改进。

在这种组织中，管理者的角色也可能发生变化。

过去，管理者主要协调人与人之间的工作。

未来，还需要管理人类员工与数字执行单元之间的协作关系。

不过，这并不意味着 Agent 可以取代业务责任主体。

无论 AI 的自主程度多高，企业仍需要由明确的人员和组织承担最终责任。

7. 企业应该如何实施 Agentic AI？

谈论 Agentic Enterprise 容易，但真正落地并不简单。

IBM 报告提出了一个值得借鉴的实施路线：30 天、120 天和 360 天。[1]

结合工程实践，我认为可以将其理解为三个阶段。

7.1 前 30 天：找到真正值得优化的价值流

首先，不要急着部署更多 Agent。

企业应该优先识别那些具有明确业务价值、存在明显流程摩擦，且有一定数据基础的业务流程。

例如：

订单履约周期过长、客户服务跨部门交接频繁、供应链异常处理成本过高，或者研发需求交付存在大量等待时间。

接下来需要明确：

当前流程的端到端耗时是多少？

哪些步骤需要大量人工协调？

哪些决策具有不确定性？

AI 介入后，业务指标可能如何变化？

这一阶段最重要的交付物，不是 Agent Demo。

而是一条具有明确业务目标、现状基线和改进空间的价值流。

7.2 前 120 天：建立端到端 Agent 执行闭环

完成场景识别后，企业需要将 Agent 与真实业务系统连接起来。

但重点不是无限增加工具，而是建立完整、可验证的执行闭环。

一个成熟的闭环至少需要包括：

业务事件触发、上下文获取、任务规划、工具执行、结果验证、异常处理和审计记录。

对于风险较高的步骤，需要保留人工审批和回退机制。

同时，必须建立可量化的业务指标。

例如：

订单平均履约周期是否缩短？

异常订单处理成本是否下降？

客户满意度是否改善？

Agent 运行成本是否低于实际收益？

如果这些问题无法回答，那么项目即使顺利上线，也很难证明其商业价值。

7.3 前 360 天：从单个价值流扩展到企业级能力

当第一条价值流得到验证后，才适合逐步向更多业务领域扩展。

这时，企业应该将已经验证有效的工程能力沉淀下来。

例如：

统一 Agent Runtime、标准化工具接口、可复用的 Memory 服务、治理策略、评估体系和可观测平台。

同时，逐步消除影响 AI 扩展的技术债务。

IBM 报告建议，在这一阶段将统一执行架构扩展到 3–5 条高价值流，并围绕业务目标形成持续运营体系。[1]

需要注意的是，规模化不等于部署更多 Agent，而是能够以可控成本重复交付业务价值。

如果每增加一个 Agent，都需要重新设计整套运行环境和治理体系，那么企业很可能只是把传统系统复杂性复制到了新的 AI 架构中。

8. 更值得警惕的风险：不要把 Agentic Enterprise 变成新的技术泡沫

尽管 Agentic AI 具有很大的发展潜力，但我们也应该保持审慎。

Deloitte 2026 年报告指出，企业在积极探索 Agentic AI 的同时，自主 Agent 的治理成熟度仍然不足。其调查显示，只有约五分之一的企业建立了较成熟的自主 Agent 治理模式。[3]

这也意味着，Agent 的部署速度可能快于企业风险管理能力的建设速度。

尤其需要警惕三个问题。

第一，不是所有流程都需要 Agent

如果一个任务具有清晰、稳定的业务规则，传统代码和工作流系统可能更简单、更经济，也更容易验证。

Agent 更适合处理那些存在语义理解、复杂上下文和动态决策需求的问题。

因此，不能将 Agent 化当成技术目标本身。

第二，多 Agent 不一定比单 Agent 更好

多个 Agent 可能带来额外的通信、协调、状态同步和错误传播成本。

复杂的多 Agent 架构，也可能增加系统调试与责任追踪的难度。

企业应该从实际需求出发，而不是单纯追求架构复杂度。

第三，Agent 自主性越高，风险治理要求也越高

当 Agent 从生成建议升级为直接操作业务系统时，系统错误的影响范围可能明显扩大。

因此，权限管理、执行约束、数据隔离、可追溯性以及必要的人工监督，应被视为生产级 Agent 的基本要求。

企业需要的不是自主程度最高的 Agent，而是在特定业务场景下能够稳定、可靠、经济地创造价值的 Agent。

9. 结语：模型决定能力上限，价值流决定商业价值

回到文章最初的问题：

为什么企业 AI 投入越来越多，却依然难以获得相应的商业回报？

问题往往不在于模型不够强，而在于企业没有同步改变业务流程、系统架构和组织运行方式。

过去，企业通过 ERP、BPM、微服务和云原生架构不断推进数字化转型。

这些技术帮助企业实现了业务流程的信息化、系统化和自动化。

如今，Agentic AI 有机会进一步向其中引入动态理解、智能决策与自主执行能力。

但技术演进并不意味着过去的软件工程经验失效。

恰恰相反。

接口抽象、模块化设计、松耦合、状态管理、事务一致性、事件驱动、可观测性以及安全治理等思想，仍然是企业级 Agent 系统不可或缺的基础。

真正发生变化的，是软件系统开始拥有更多基于上下文进行判断和执行的能力。

这种变化既带来了新的可能性，也提高了系统治理的复杂度。

我认为，未来企业 AI 的竞争将逐渐体现为三个层次：

第一个层次，是模型能力。

谁能获得更强、更快、更经济的智能能力。

第二个层次，是 Agent 工程能力。

谁能把模型、工具、数据、记忆、编排和治理整合为稳定可靠的生产系统。

第三个层次，是价值流重构能力。

谁能将 AI 真正嵌入核心业务，持续改善客户体验、业务效率和经营成果。

其中，前两个层次决定技术能否发挥作用。

第三个层次，才最终决定企业是否能够构筑可持续的竞争优势。

因此，我更倾向于将 Agentic Enterprise 理解为一种新的企业运行范式，而不仅是一代新的 AI 应用。

从 Copilot 到 Agentic Enterprise，真正需要重构的，不只是技术架构，而是企业创造价值的方式。

模型会持续迭代，Agent 框架也会不断变化。

但无论技术如何发展，企业最终都要回答同一个问题：

我们究竟为客户创造了什么价值？

这可能才是企业 AI 下一场竞争最值得关注的主航道。

参考文献

[1] IBM Institute for Business Value. (2026). Redesign for Enterprise AI: Focus on Critical Value Streams to Drive Growth. IBM.
https://www.ibm.com/thought-leadership/institute-business-value/en-us/report/ai-process-redesign

[2] McKinsey & Company. (2025). The State of AI in 2025: Agents, Innovation, and Transformation.
https://www.mckinsey.com/featured-insights/artificial-intelligence/the-state-of-ai-2025

[3] Deloitte AI Institute. (2026). The State of AI in the Enterprise. Deloitte.
https://www.deloitte.com/us/en/what-we-do/capabilities/applied-artificial-intelligence/content/state-of-ai-in-the-enterprise.html

[4] Anthropic. (2024, December 19). Building Effective Agents.
https://www.anthropic.com/research/building-effective-agents

[5] National Institute of Standards and Technology. (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0).
https://www.nist.gov/itl/ai-risk-management-framework

[6] Autio, C., Schwartz, R., Dunietz, J., Jain, S., Stanley, M., Tabassi, E., Hall, P., & Roberts, K. (2024). Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (NIST AI 600-1). National Institute of Standards and Technology.
https://doi.org/10.6028/NIST.AI.600-1

[7] McKinsey & Company. (2025, March 12). The State of AI: How Organizations Are Rewiring to Capture Value.
https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value

本文基于公开行业研究报告与企业 AI 工程实践进行分析。涉及 Agent 架构、能力分级、评价体系及未来技术演进的部分内容属于作者的技术分析与观点，不代表所引用研究机构的官方立场。