阿里云云原生 2026 年 9 月 28 日发布 1906 份 Agent 开发者调研：46% 的企业在做 Agent，真正进生产的只有 18%。 这份调研落在企业级 Agent 从原型走到生产这一段。前置部署 Forward Deployed Engineer（FDE）在客户现场最常被追问的是「你们的 Agent 到底上没上生产」，而这份问卷把回答这个问题的自我判断口径量化了，可以直接拿来对齐交付范围与验收标准。 报告由阿里云云原生在掘金发布，标题是《2026 Agent 开发者调研报告》，发布日期为 2026 年 9 月 28 日。它是《Alibaba Cloud AI Agent Handbook》的配套调研，该 Handbook 于 2026 年 9 月 23 日开源，在 2026 云栖大会（AgentCore 分论坛）同步发布。 样本为 1906 份有效问卷，取自阿里云在北京、深圳、广州、上海、杭州等城市举办的线下开发者沙龙。受访者以企业的技术决策者、架构师、一线工程师和产品经理为主，也就是说这份数据反映的是动手搭 Agent 的人的自报口径，不是纯管理层的口径。 一、开发率与上线率之间的剪刀差是这份数据最硬的约束 问卷把「已开发完成或开发中」合并统计，2026 年为 46%，2025 年为 36%，一年抬升 10 个百分点。 明确表示暂无开发计划的受访者从 2025 年的 22% 降到 2026 年的 15%。 正在调研和计划开发的从 2025 年的 47% 降到 2026 年的 25%，两端的中间态被挤向「已经在做」。 但真正部署到生产环境的只有 18%，报告在总结部分给出的另一个口径是持续迭代的不到 10%。 把 46%、18% 与不到 10% 三个数字放在一起，投入意愿已经不缺这个结论是成立的，缺的是把 Agent 送进生产并保持迭代的工程能力。 报告对此的表述是：卡点不是企业意愿，也不是模型能力，而是能优化 Harness 层开箱即用的工程配套。 前置部署 Forward Deployed Engineer（FDE）在客户现场遇到的场面与此吻合：Agent 演示能跑通，评估却只有人工抽查，没有人能回答改动之后系统是变好还是变坏。 二、同城大企业与小微企业的差距，比城市之间的差距更大 报告给出两个城市按企业规模的分层。上海的大型企业已上线率为 45%，小微企业为 16%。 深圳的大型企业已上线率为 38%，小微企业为 17%。 上海同城内大小企业相差 29 个百分点，深圳相差 21 个百分点，而两个城市对应规模的数字差距只有 7 个百分点与 1 个百分点。 报告据此判断差异不在是否愿意投入，而在是否具备持续演进 Agent 的工程能力，这份能力被拆成 Agent 的组织与协作、治理、优化和沉淀四项。 报告同时引入 L1 到 L4 的成熟度分级：L1 是辅助生成，L2 是受控自动化，L3 的 Agentic Execution 只在部分场景成立，L4 的 Managed & Optimizing 尚属少数。 三、架构选型与工具链都还没收敛，混合形态是长期状态 以单 Agent 为主要架构的企业占 40%，已开始引入多 Agent 的企业占 42%，两者体量接近。 把人在回路 Human-in-the-Loop（HITL，关键步骤必须由人确认后才继续执行）当作生产环境架构原则而非附加审批开关的企业占 15%。 报告据此给出一个明确判断：单 Agent、多 Agent 与人在回路是长期共存的三种选择，自主度是一个可调参数，混合形态不是过渡阶段。 40% 与 42% 的接近程度说明还没有出现事实标准，报告因此给出的选型建议是可迁移的工程抽象比押注某个具体框架更有价值。 工具链侧同样碎片化。采购编程类 Coding 工具（Claude Code、Codex、Cursor、Qoder）的企业占 57%。 使用通用 Agent 框架的企业占 78%，接近四成的企业同时使用编程 Agent 与通用 Agent 框架。 报告给出的解释是：Coding 是目前唯一实现规模化落地的付费场景，因为反馈信号明确（能否编译、测试是否通过）、环境边界清晰（代码仓库与工作区）、错误代价可控（可回滚），这三项恰好是 Agent 稳定运行的前提条件。 四、上下文与工具层的痛点，不是靠扩大窗口能解决的 在记忆与上下文的痛点调研中，表示无明显痛点的受访者不到 10%。 排第一位的是检索不准，占 54%；排第二位的是记忆更新与遗忘机制缺失，占 48%；上下文窗口限制只排第三。 报告据此给出的结论是，上下文的问题不在窗口大小，而在写入、淘汰与检索策略。 工具侧的结构类似，工具过多、选择困难占 52%，幻觉调用占 50%。 报告对工具侧的判断是，工具的组织方式与描述质量比工具数量更决定调用成功率。 协议层的缺口更具体。已经关注或已经落地 MCP 的企业合计 37%，但真正完成企业内私有部署的只有 9%。 这 28 个百分点的落差来自企业级配套：私有注册中心、统一身份与鉴权、版本与灰度管理、审计留痕，以及与网关的集成，这些都不在协议规范本身提供的范围内。 需求侧有 28% 的受访者明确提出 MCP 服务管理与注册中心的需求，报告认为这一比例与已落地比例接近，说明需求正在从认知转向工程实施。 前置部署 Forward Deployed Engineer（FDE）在现场最有价值的动作，是把这 28 个百分点的落差拆成五个可以逐项验收的交付物：注册中心、统一鉴权、版本与灰度、审计留痕、网关集成，每一项都能单独定验收标准，也都能单独计价。 五、63% 的企业把多模型路由与自动降级列为最需要的网关能力 多模型路由与自动降级被 63% 的企业列为最需要的网关能力，是整份调研中比例最高的单项需求。 这条需求的三个动作是：不同任务匹配不同模型、主模型不可用时降级、按成本与延迟动态选择。 报告对这条需求的定位是，这三件事无法在应用代码里逐个解决，需要一个统一的流量入口来承接。 可观测诉求里，成本归因占 50%，排位仅次于全链路追踪，高于审计合规与语义质量监控。 报告把成本归因解释为一种预防性诉求：多数企业 Token 用量还不算大，但已经在为成本的可见性与可分摊做准备，而不是等账单失控后再补。 报告给出的落地位置是把 AI 网关从流量入口扩展为统一治理入口，集中承接工具注册与检索、参数校验、模型路由、熔断重试、链路追踪与成本标签。 六、评估环节的数字最刺眼：人工抽查 55%，运行轨迹自动评估 6% 被问到用什么方法评估 Agent 效果时，人工抽查以 55% 稳居第一。 基于运行轨迹 Trajectory 自动评估的只有 6%，使用公开 Benchmark 的不到 5%。 另有 28% 的受访者还没有建立系统性的评估体系。 把 LLM-as-Judge、A/B 实验、离线数据集回归这三类常见手段放在一起，用上其中任意一种的企业为 34%。 任务成功率的结果与评估能力直接相关。Agent 任务成功率达到 90% 以上的企业仅约一成，70% 以上的约 55%，而 16% 的受访者根本没有量化过成功率。 报告对最后那 16% 的判断是，这部分企业实际上无法判断自己的 Agent 是否在正常工作。 报告给出的相关性结论是：使用了评估手段的企业，任务成功率达 70% 以上的比例是没有评估体系的企业的约两倍；在已上线并持续迭代的企业里，这一比例达 84%。 三者互为因果：评估能力支撑迭代，迭代提升可靠性，可靠性才使持续进行评估成为可能。 报告对反面情形的描述是，缺乏评估的团队既无法定位问题，也无法证明改动有效，容易长期停在试点阶段。 前置部署 Forward Deployed Engineer（FDE）在报价阶段可以直接引用这组数字：把成功率门槛定在 70% 以上，落点已经高于报告里约 55% 的分布，而把 90% 以上写进合同则会落进只有约一成企业达到的区间。 七、把数字翻成生意：采购语言已经从「有没有 Agent」变成「生产环境里有没有数字」 第一层含义是交付内容的位移。46% 的开发率与 18% 的生产部署率之间的剪刀差，意味着客户的预算重心正在从「做一个 Agent」转向「把已有的 Agent 弄上生产」，交付物也就从功能开发变成可靠性与治理工程。 第二层含义是卖点的位移。上海大型企业 45% 与小微企业 16% 的上线率差说明，客户之间的差距不在模型选型，而在能否长期维持一支持续演进 Agent 的队伍。 前置部署 Forward Deployed Engineer（FDE）的定价含义因此变得更清楚：按能力补齐与治理配套计价，比按模型调用量或人天计价更贴近客户实际拿到的价值。 第三层含义是最贵的工作不在搭建而在配套。 MCP 私有部署 9% 对关注或落地 37%、运行轨迹自动评估 6% 对人工抽查 55%，这两组数字指向同一件事：企业对协议的认知已经完成，缺的是注册、鉴权、版本、审计、网关、评估这一整套生产配套。 第四层含义是竞争格局。40% 对 42% 的架构选择分布与接近四成的双框架并用比例，说明客户侧还没有既成标准，交付方如果把方法论绑死在单一框架上，下一次客户换框架时整套交付资产会被一起换掉。 报告自述的四个变化，与上面四层含义互为印证 报告在总结部分把 Agent 的走向概括成四个变化：概率智能走向可靠生产力，粗放使用走向精细化使用，单点试验走向智能基础设施，Agent 孤岛走向智能组织。 这四个变化分别对应本文引用的四组数字：18% 的生产部署率对应可靠生产力，50% 的成本归因需求对应精细化使用，63% 的网关需求对应智能基础设施，9% 的 MCP 私有部署率对应 Agent 孤岛。 对应关系不是报告的原文写法，是按数字含义做的归类，但它解释了为什么 63% 与 50% 这两项跟治理相关的需求，会比功能类需求排得更前。 八、这份调研的局限与未覆盖的场景 第一，样本来自五个城市的线下开发者沙龙，到场者本身是对 Agent 有兴趣的人群，存在自选择偏差，46% 的开发率不能外推到全部企业。 第二，全部为自报口径，没有第三方核验，任务成功率与痛点排序都依赖受访者的自我判断。 第三，46% 与 18% 的分母并不一致，前者是「已开发完成或开发中」，后者是「部署到生产环节」，两者相减得到的 28 个百分点只能当作趋势，不能当作精确的转化率。 第四，报告没有给出金额、岗位数、行业切分与 Day 2 运维时长，因此无法据此推算单个 Agent 项目的预算区间或驻场人力规模。 第五，L1 到 L4 的成熟度分级来自 Handbook 自建框架，不是行业标准，跨厂商对比时需要重新对齐定义。 第六，样本城市全部在中国境内，且受访者以阿里云生态内的开发者为主体，结论对境外企业与国产框架之外的栈需要重新验证。 第七，报告把「无明显痛点不到 10%」与「28% 没有系统性评估体系」并列呈现，但没有给出这两组人群的重叠度，因此无法判断痛点缺失是能力成熟还是尚未进入深水区。 九、实用结论：该行动的两种人，以及一份可照抄的交付清单 该行动的是两类人。前置部署 Forward Deployed Engineer（FDE）与解决方案架构师是一类，他们正在为客户报价下一步的 Agent 交付。 客户方平台团队是另一类，他们已经做完 PoC，正要决定要不要把 Agent 推进核心业务流程。 第一步，在 Discovery Call 阶段先问五个问题。这个 Agent 的任务成功率量化过吗，分母是什么？评估手段是人工抽查还是运行轨迹？MCP 服务有没有私有注册中心，鉴权怎么统一？多模型路由与降级做在哪一层？成本标签打在哪个环节？ 这五个问题分别对应 55%、6%、9%、63%、50% 五组数字背后的缺口，回答含糊的那一项就是本次交付的主战场。 第二步，把交付范围写成能力缺口到交付物的映射。评估体系对应运行轨迹采集、LLM-as-Judge 打分与离线黄金集回归三件套。 协议治理对应私有注册中心、统一鉴权、版本与灰度管理、审计留痕，以及与网关的集成五项配套。 运行底座对应 AI 网关承接工具注册与检索、参数校验、模型路由、熔断重试、链路追踪与成本标签。 上下文对应写入、淘汰与检索策略，而不是单纯扩上下文窗口。 第三步，验收口径建议按报告的数字设门槛。以任务成功率达 70% 以上为主要 gate，不要承诺 90% 以上，因为报告里做到 90% 以上的企业只有约一成。 同时把运行轨迹自动评估的覆盖率、成本归因覆盖的调用占比写成可验收指标，这两项在报告里的基线分别是 6% 与 50%，起点明确、增量可量化。 适用条件是客户已有 10 个以上 Agent，或者 12 个月内有上到 100 个的计划，并且客户自建平台队伍少于 3 人。 如果客户已有 5 人以上的平台团队并且自己写过评估流水线，那么这套交付的边际价值会明显下降，此时应把范围收窄到协议治理与网关两项。 落地顺序建议照报告的场景排序走：先进入员工效能、代码工程、数据分析这类容错空间大、能人工兜底的场景。 报告显示把 Agent 引入企业核心业务流程的占比不到 40%，这个顺序不是保守，而是与上线率自洽。 回滚与退出方式要写进 SOW。保留人在回路 Human-in-the-Loop（HITL）对关键步骤的人工确认，这是报告里 15% 的企业已经在用的架构原则，也是最直接的降级开关。 若 90 天内运行轨迹自动评估的覆盖率没有建立起来，就停止向核心流程扩展，退回可人工兜底的场景。 若客户拒绝开放评估数据，按能力补齐计价的部分延期结算，把风险留给不愿提供验证条件的环节。 十、三个可核验的时间点与四条自查 2026 年 9 月 22 日，阿里云在 2026 云栖大会（AgentCore 分论坛）发布 AgentCore 与《阿里云企业级智能体手册》白皮书。 2026 年 9 月 23 日，《Alibaba Cloud AI Agent Handbook》开源。 2026 年 9 月 28 日，这份基于 1906 份有效问卷的调研报告在掘金发布。 自查第一条：正文里出现的每一个任务成功率，是否标明了分母是「开发中」还是「已上生产」。 自查第二条：MCP 相关交付物是否包含私有注册中心与统一鉴权两项，缺一即无法进生产。 自查第三条：评估方案是否包含运行轨迹采集，只做人工抽查等于把基线停在 55%。 自查第四条：成本归因标签是否覆盖模型路由与降级链路，报告里 63% 的网关需求与 50% 的成本归因是同一件事的两面。 原始来源： - https://juejin.cn/post/7690358995769868298 - https://developer.aliyun.com/article/1761911 - https://www.news.cn/tech/20260922/6bd1c77079d74175a692fca1b3f13edd/c.html - https://github.com/pierpaolo28/Awesome-FDE-Roadmap