从五份行业报告看 AI 产品的六层能力演进
自2025 年以来，Agent 几乎成了 AI 行业最热门的词。
产品发布会在讲 Agent，创业公司在讲 Agent，企业数字化方案也从 Copilot、RAG 迅速转向 Agentic AI。仿佛只要给大模型接上几个工具，再增加一段循环逻辑，一个更高级的 AI 产品就诞生了。
但行业报告呈现出的现实，比宣传复杂得多。
McKinsey 2025 年全球 AI 调查显示，88% 的受访者表示所在组织已在至少一个业务职能中经常使用 AI，62% 的组织至少开始试验 AI Agent；但真正表示已经扩展部署 Agent 的只有 23%，而在任何一个具体业务职能中，规模化使用 Agent 的比例都不超过 10%。McKinsey《The State of AI 2025》
Capgemini 对14个国家约1,500名高管的调查更加谨慎：只有2%的组织表示已经全面规模化部署 AI Agent，12%实现部分规模化，更多企业仍停留在试点和探索阶段。与此同时，受访者对完全自主 Agent 的信任率在一年内从43%下降至27%。Capgemini《Rise of Agentic AI》
这些数据共同揭示了一个事实：
企业并不缺少 AI Demo，真正稀缺的是能够进入业务流程、获得用户信任并长期稳定运行的 AI 系统。
因此，理解 AI 产品不能只问“用了哪个模型”“有没有 Agent”，而应该追问：
AI 在产品运行过程中究竟承担了什么职责？系统又为这种能力提供了怎样的控制、评估和运行环境？
从当前主流技术框架和行业报告中，可以归纳出一套 AI 产品的六层能力栈。
它不是行业统一标准，也不是层数越高越先进，而是一张帮助我们理解 AI 产品深度的地图。
先区分：AI 辅助开发与 AI Runtime
今天，一个人可以使用 Cursor、Claude Code、Lovable 等工具快速做出网页、插件和 SaaS 原型。
但用 AI 写出来的软件，不一定是 AI 产品。
假设开发者使用 AI 完成了一个普通日历工具的80%代码，用户运行它时，系统仍然只是执行传统的增删改查。AI 只参与了开发，没有参与产品运行。
这属于：
AI-assisted building
AI 帮助人开发软件另一个日历产品可以理解“帮我找一个下周大家都有空的下午”，自动读取参会者日历、比较空档、生成候选时间，并在用户确认后发送邀请。
这属于：
AI runtime
AI 在用户使用产品时承担理解、判断和行动因此，判断一个产品是不是 AI 产品，不能看开发阶段使用了多少 AI，而要看：
用户使用产品时，AI 是否在系统内部承担了任务执行的一部分。
这是理解后续六层能力的起点。
第一层：生成——AI 是一个内容功能
第一层是最常见的 AI 应用：
用户输入
→ Prompt 模板
→ 大模型
→ 返回结果典型产品包括：
标题生成器
邮件润色器
简历优化器
文案生成器
文章总结器
简单聊天机器人
这一层经常被称为 Prompt Wrapper。
模型在产品中扮演的是一个文本或多媒体处理功能：输入内容，生成内容，然后结束。
这种产品并不天然低级。如果一个单次生成动作可以高频、低成本地解决真实问题，它完全可能创造很高的商业价值。
问题在于，这类产品通常：
不理解用户的真实环境；
不知道企业内部数据；
无法验证输出依据；
不能改变外部系统状态；
每次都依赖用户重新提供背景。
它会生成，但还不了解用户所在的世界。
在微软 2025 年 Work Trend Index 中，这种形态接近“Human with assistant”：每个人拥有一个 AI 助手，AI 主要帮助人提高单项工作的速度和质量。微软调查了31个国家的31,000名工作者，并预测组织将逐步从个人助手走向人机团队和由人领导、Agent 执行的业务流程。Microsoft《2025 Work Trend Index》
第二层：Grounding——AI 开始根据事实工作
通用大模型不知道企业的最新制度、客户记录、实时订单和项目状态。
第二层解决的是：
在模型回答之前，先为它提供当前任务需要的事实。
常见结构是：
用户提问
→ 识别意图
→ 检索文档或数据库
→ 筛选和重排资料
→ 将相关上下文提供给模型
→ 生成带来源的答案这就是 Grounded AI。RAG，也就是检索增强生成，是其中最常见的实现方式。
典型产品包括：
企业知识库
客服问答
课程助教
法律文档助手
产品资料助手
内部制度查询
数据问答系统
例如，用户询问“去上海出差的住宿标准是多少”，普通模型只能根据常识推测；Grounded AI 会检索企业差旅政策，再结合员工级别、城市和日期回答。
这一层的真正门槛并不是“接入一个向量数据库”，而是：
检索到的资料是否真正相关；
使用的是不是最新版本；
用户是否有权读取；
答案能否指出来源；
多份资料冲突时如何处理；
没找到证据时是否承认不知道。
Google Cloud 将 Grounding、Tools、Data Architecture、Orchestration 和 Runtime 并列为 AI Agent 的核心组成部分，并强调 RAG 的作用是把模型连接到可验证和实时的数据，而不是让模型只依赖训练知识。Google Cloud《Core Concepts of AI Agents》
第二层让 AI 从“凭印象回答”走向“根据证据回答”。
但它通常仍然只是回答者。
知道得更多，不等于能替用户做事。
第三层：工具——AI 开始影响外部世界
第三层发生了一个关键变化：
AI 不只生成内容，还可以调用工具采取行动。
工具可能是：
查询日历
读取邮件
搜索网页
查询订单
更新 CRM
创建文档
运行代码
修改数据库
发送消息
生成文件
典型运行过程是：
用户提出目标
→ 模型判断需要什么工具
→ 生成结构化参数
→ 系统调用 API
→ 返回执行结果
→ 模型继续处理例如用户说：“看看我下周二下午有没有空。”
模型本身无法知道答案。它需要调用日历工具，提交正确的时间范围，读取结果，再向用户解释。
这一层让 AI 拥有了“手脚”，但也第一次让 AI 的错误可能直接产生外部后果。
于是，产品设计必须回答：
用户是否授权了这个动作；
模型生成的参数是否合法；
写操作能否撤销；
系统会不会重复执行；
高风险动作是否需要确认；
工具失败后如何恢复；
每次操作是否留下审计记录。
“查询余额”和“发起转账”都属于工具调用，但两者显然不能采用相同的权限策略。
NIST 对 Agent 工具权限的讨论也采用了类似思路：需要区分只读、受限制写入和完整写入，并结合工具所处的可信或非可信环境评估风险。NIST《Tool Use in Agent Systems》
因此，Tool Use 的核心不只是给 AI 能力，而是：
在授予能力的同时，为能力建立清晰、可执行的边界。
第四层：Workflow——AI 进入稳定业务流程
会调用一个工具，不等于能够完成一项工作。
真实业务通常由多个步骤、规则和人工节点组成。例如客服退款可能需要：
识别用户诉求
→ 查询订单
→ 检查退款政策
→ 判断风险
→ 生成处理建议
→ 等待人工确认
→ 调用退款接口
→ 通知用户
→ 记录结果这就是 LLM Workflow。
程序提前规定主要路径，模型在部分节点负责分类、抽取、判断或生成。
典型场景包括：
客服退款
销售线索筛选
合同初审
报销审核
候选人筛选
Bug 分类
舆情日报
投资研究流程
这一层关注的不是“模型有多聪明”，而是流程能否：
重复执行；
保持相对稳定；
检查中间状态；
设置人工审批；
在失败后恢复；
对结果进行评估。
Anthropic 将 Workflow 定义为模型和工具沿着预先确定的代码路径运行；而 Agent 则由模型动态决定流程和工具使用方式。Anthropic 同时建议：能够用简单调用、RAG 或固定 Workflow 解决的问题，不应为了追求 Agent 而增加不必要的复杂性。Anthropic《Building Effective Agents》
这可能也是当前企业 AI 落地最重要的一层。
McKinsey 2025 年报告发现，大部分组织虽然已经使用 AI，但接近三分之二仍没有进入企业级规模化阶段。真正获得较高价值的企业，更倾向于重新设计完整工作流，而不只是向原有流程添加零散的 AI 功能。
换句话说：
企业 AI 的价值通常不是来自“多了一个聊天框”，而是来自一项工作被重新组织。
第五层：Agentic Control——AI 动态决定下一步
Workflow 与 Agent 最重要的区别是：
下一步由程序预先规定 → Workflow
下一步由模型根据情况决定 → AgentAgent 接收的通常不是一组固定步骤，而是一个需要完成的目标。
例如：
调查这家公司利润下降的原因，并生成一份有证据支持的报告。
Agent 可能先阅读财报，发现毛利率下降；然后查询竞争对手，发现行业价格战；接着搜索管理层电话会，确认成本变化；最后判断证据是否充分，再决定继续调查还是完成报告。
它执行的是一个循环：
理解目标
→ 分析当前状态
→ 选择下一步
→ 调用工具
→ 观察结果
→ 更新计划
→ 继续、停止或请求人工帮助OpenAI 将 Agent 的关键特征概括为：模型负责管理工作流、做出决策、动态选择工具、判断任务是否完成，并在失败时停止或把控制权交还给用户。OpenAI《A Practical Guide to Building Agents》
因此，判断一个产品是不是 Agent，不能只看它调用了多少工具。
一个固定调用十个 API 的系统可能仍然是 Workflow；一个只使用两个工具、但会根据执行结果动态调整计划的系统，反而更接近 Agent。
Agent 更适合：
软件开发
深度研究
复杂故障调查
多来源信息核查
难以穷举规则的客户问题
但自主性也会带来新的代价：
更高的成本；
更长的运行时间；
更难预测的行为；
多步骤错误累积；
更大的测试空间；
更复杂的权限风险。
这正是为什么行业对 Agent 的兴趣增长很快，但全面规模化仍然缓慢。
Deloitte 对2,773名直接参与生成式 AI 项目的商业和技术领导者进行调查，26%的组织表示正在较大程度探索自主 Agent，42%表示正在一定程度探索；但超过三分之二的受访者预计，未来三至六个月能够全面规模化的生成式 AI 实验不超过30%。Deloitte《State of Generative AI in the Enterprise》
热度与规模化之间的差距，说明 Agent 最难的部分不是让它“跑起来”，而是让它可以被信任。
第六层：Runtime——AI 成为产品的智能运行层
一个能动态规划和调用工具的 Agent，仍然可能只是一个 Demo。
它可能成功运行过几次，却没有处理：
用户身份；
数据权限；
长期记忆；
运行监控；
失败恢复；
成本控制；
结果评估；
人工接管；
主动触发；
数据安全。
因此，第六层不是“更自主的 Agent”，而是：
将前面的 AI 能力变成一个可以长期运行、被用户和组织信任的完整系统。
这需要三类基础能力。
低摩擦交互
AI 不一定表现为聊天框，而应该进入用户原来的工作位置：
邮件中的建议回复；
文档里的行内修改；
浏览器侧边栏；
业务系统里的审批界面；
操作前后对比；
撤销与回滚；
人工接管入口。
好的 AI 产品不会要求用户每次重新学习怎样写 Prompt。
上下文与记忆
系统能自动获得完成任务所需的信息：
用户身份和偏好；
当前工作区和项目背景；
会话与任务状态；
文档、邮件和日历；
CRM 与工单；
长期记忆；
历史操作记录；
数据访问权限。
真正的记忆系统还必须回答：
什么值得保存；
保存多长时间；
谁可以读取；
用户能否修改和删除；
错误记忆如何纠正；
敏感信息是否允许进入模型上下文。
主动运行
系统可以由事件触发，而不是永远等待用户提问：
每天早上生成工作简报；
会议前自动整理资料；
收到重要邮件时提醒；
项目指标异常时主动调查；
客户长时间未回复时建议跟进；
供应链异常时生成应对方案。
但主动性必须与权限和信任一起设计。
Capgemini 的调查显示，组织对完全自主 Agent 的信任率从43%下降到了27%。这不是企业不再需要 Agent，而是企业正在意识到：
自主性本身不是价值；可理解、可控制的自主性才是价值。
在高风险场景中，成熟的 AI 产品未必追求完全自动执行。它可能选择收集证据、生成建议、标记风险，然后把最终决定交给人。
六层不是排行榜，而是可组合的能力栈
现实产品很少只属于某一层。
一个企业客服系统可能同时包含：
普通问题：RAG
订单查询：只读工具
标准退款：固定 Workflow
复杂投诉：Agent 动态调查
大额退款：人工审批因此，与其问“这个产品属于第几层”，不如从四个维度评估它。
这四个维度不能互相替代。
一个简单的 RAG 产品，可能已经具备稳定运行和明确商业价值；一个复杂的多 Agent 系统，也可能没有权限控制、评估机制和真实用户。
为什么不同报告的 Agent 普及率差异很大？
值得注意的是，各行业报告给出的 Agent 普及率并不一致。
McKinsey：23%的受访组织表示已经在某些地方扩展部署 Agent；
Capgemini：只有2%实现全面规模化，12%实现部分规模化；
Microsoft：46%的领导者表示所在组织正在使用 Agent 全面自动化某些流程；
LangChain 2026 年面向1,300多名技术和产品从业者的调查中，57.3%的受访者表示已有 Agent 在生产环境运行。
这些数字不能直接横向比较。
原因包括：
“使用”“生产”“部分规模化”和“全面规模化”的定义不同；
调查对象不同，有的是企业高管，有的是技术社区；
一个团队上线 Agent，不代表整个企业完成规模化；
厂商和技术社区的样本通常对 AI 更积极；
企业自报的“Agent”可能只是带工具的 Workflow。
但差异本身也提供了一个重要洞察：
“Agent 是否进入生产”还不是一个标准化指标。
LangChain 的技术调查还显示，质量是 Agent 进入生产的主要障碍之一；约89%的受访团队已经配置某种可观测能力，但采用评估体系的只有约52%。这意味着很多团队已经能看到 Agent 怎样运行，却还不能系统判断它运行得好不好。LangChain《State of Agent Engineering》
可观测性回答的是“发生了什么”。
评估回答的是“结果是否足够好”。
两者缺一不可。
企业真正应该追求什么？
从这些报告中，可以提炼出五条比“尽快做 Agent”更重要的原则。
第一，从业务结果开始，而不是从 Agent 开始
先确定需要改善的指标：
处理时间；
人工成本；
错误率；
转化率；
客户满意度；
收入或利润。
如果没有明确结果，系统越复杂，浪费可能越大。
第二，选择足够简单的架构
单次生成能解决，就不要先做 Workflow。
RAG 能解决，就不要先给写权限。
固定流程能解决，就不要先做动态 Agent。
单 Agent 能解决，就不要先做多 Agent。
第三，工具权限必须与风险匹配
读取和写入应当采用不同的权限等级。
高风险动作应该具备：
最小权限；
参数验证；
用户确认；
幂等控制；
审计记录；
撤销或补偿机制。
第四，评估能力要早于规模化
上线前就应该知道：
什么叫正确；
怎样构造测试集；
如何衡量任务完成；
如何检查工具调用；
如何发现幻觉；
人工应该抽查什么。
没有评估的 Agent，只是一个无法量化风险的自动化系统。
第五，人机关系要在产品阶段设计
不要等 Agent 出错后，才考虑人工接管。
产品一开始就应该明确：
AI 负责什么；
人负责什么；
哪些节点需要审批；
哪些异常必须升级；
用户怎样理解和推翻 AI 的判断。
结语：AI 产品正在从功能走向运行系统
AI 产品的演进，可以概括为：
生成内容
→ 获得事实
→ 调用工具
→ 进入流程
→ 动态规划
→ 成为长期运行的智能层但这不是一条必须走到底的升级路线。
更高的自主性不一定带来更高的价值，更复杂的架构也不等于更成熟的产品。
McKinsey、Deloitte 和 Capgemini 的报告共同说明：企业已经广泛开始 AI 实验，但从试点走向规模化价值依然困难。市场真正缺少的不是更多 Agent 演示，而是能够处理权限、评估、信任、流程和责任边界的系统能力。
未来，模型会继续变强，工具调用会越来越标准化，搭建 Agent 也会越来越容易。
真正难以复制的，将是：
对真实工作流的理解；
独有的数据和上下文；
明确的业务判断标准；
合理的人机责任分配；
让 AI 长期可靠运行的工程体系。
AI 产品的分水岭，最终不是它调用了哪个模型，也不是它拥有多少个 Agent。
而是：
它能不能在真实世界里，被持续使用、被可靠控制，并稳定地把事情做成。