企业 Agent 卡住的不是模型：1906 份问卷给出的答案

阿里云把 Agent 拆成架构、构建、运行、治理、调优五段，写成了 30 章。真正值得带走的是那组数据

一句话结论

企业 Agent 的瓶颈已经从"能不能做"移到了"能不能稳定跑"，而卡住的地方不是模型，是模型之外那套叫 Harness 的工程系统——上下文、状态、工具、沙箱、权限、观测、评估。手册里那组数据比任何架构图都有说服力：46% 的企业在做，18% 上了生产，持续迭代的不到 10%。

这份材料讲了什么

一份 1906 人的开发者调研，加上一本 30 章、6 篇的开源手册，按 Agent 的架构、构建、运行、治理、调优全生命周期组织。
核心命题：Agent = Model + Harness。模型提供智能，Harness 提供确定性。企业要设计的不再是一次模型调用，而是一个跨越认知、状态、执行、控制、改进的完整系统。
五种应用形态长期共存，不是新旧替代。Workflow 与 Agent 并存，单 Agent 与多 Agent 并存，人在回路（HITL）也被 15% 的企业当成架构原则而非审批开关。
最痛的三个点依次是：上下文与记忆、路由与成本、评估缺位。前两个是工程问题，第三个是能力问题——它决定了前两个能不能被验证。
手册给了一套"最低充分架构"的判断法：自主性要和任务风险匹配，不是越高越好。

几个必须先对齐的概念

Agentic Application：以任务交付为目标的 AI 应用，区别于"人判断、模型建议"的 Chatbot 与 Copilot。判断标准不是有没有对话界面，而是谁承担完成责任。

Harness：模型之外、让 Agent 能稳定跑起来的那一整套工程。包括上下文组织、任务状态、工具控制、环境隔离、失败恢复、结果评估、风险约束。这个词是这份手册的支点——它把"Agent 不行"这个模糊结论拆成了可逐项排查的清单。

L1–L4 成熟度：L1 辅助生成、L2 受控自动化、L3 Agentic Execution（只在部分场景成立）、L4 Managed & Optimizing（尚属少数）。手册的构建、运行、治理、调优四篇，本质上都在回答"怎么从 L2 走到 L3、L4"。

HITL（Human-in-the-Loop）：关键步骤必须由人确认。注意手册里的用法——它是一种架构选择，不是给不成熟的 Agent 打的补丁。

Trajectory（轨迹）：不只是调用日志，而是包含输入、决策、工具调用、中间结果、最终产出的完整行为证据。评估与调优都以它为原料。

LLM-as-Judge：用模型给模型的输出打分。便宜、可规模化，但有偏见，需要和人工抽查交叉校准。

黄金数据集：带输入、轨迹、结果和判据的高质量评估集。手册把它当成资产，而不是一次性的测试文件。

关键数据：生产化的真实分布

数据	数值	来源	怎么读
已开发完成或开发中	46%（去年 36%）	1906 份问卷	投入意愿已经不成问题
真正部署到生产	18%	同上	从"做出来"到"跑起来"，掉了 28 个百分点
持续迭代	不到 10%	同上	这才是真正的分水岭：能不能长期养
暂无开发计划	15%（去年 22%）	同上	观望的人一年少了 7 个点
单 Agent 为主	40%	同上	与多 Agent 几乎持平
多 Agent 为主	42%	同上	说明多 Agent 已不是"先进方案"，是常规选项
HITL 作为主要架构	15%	同上	少，但把它当原则而非开关
用通用 Agent 框架	78%	同上	框架层渗透率高
采购 Coding 工具	57%	同上	Coding 是唯一规模化付费的场景
同时用编程与通用 Agent	近 40%	同上	两条线在互相渗透
上下文与记忆有明确需求	90%	同上	几乎是共识级痛点
痛点：检索不准	54%	同上	排第一，且不是窗口能解决的
痛点：记忆更新与遗忘机制缺失	48%	同上	第二
上下文窗口限制	排第三	同上	这条最反直觉：大家都在喊窗口，实际问题排第三
多模型路由与自动降级	63%	同上	单项需求最高，超过任何单点能力
评估靠人工抽查	55%	同上	主流做法仍是人看
基于轨迹自动评估	6%	同上	缺口最大的一环
用公开 Benchmark	不到 5%	同上	榜单一度热，实际用于生产评估的极少
没有系统性评估体系	28%	同上	近三成企业无法证明改动有效
任务成功率 90% 以上	约一成	同上	少数派
任务成功率 70% 以上	约 55%	同上	及格线附近
从未量化过成功率	16%	同上	这些企业无法判断 Agent 是否在正常工作
有评估 vs 无评估的成功率	约 2 倍	同上	70%+ 成功率的比例对比
已上线并持续迭代者的成功率	84%	同上	形成正循环后的样子
已关注或落地 MCP	37%	同上	认知层已经铺开
完成企业内私有部署	9%	同上	从认知到工程，掉了 28 个百分点
成本归因需求	50%	同上	仅次于全链路追踪，高于审计合规
大企业 vs 小微上线率（上海）	45% vs 16%	同上	差距不在意愿，在工程能力储备

一句话读这张表：开发率的差距不大，上线率的差距很大。 手册的解释是，差别不在"愿不愿意投入"，而在"有没有持续演进 Agent 的工程能力"。

能用在什么地方

拿去当立项评审的尺子。 手册的架构篇给了一个很实用的问法：这项任务的确定性有多高、容错空间有多大、需要多高的自主性？三个答案决定你该用 Workflow、单 Agent、多 Agent 还是 HITL，而不是"先进就用哪个"。评审会上最常吵的"要不要上多 Agent"，用这个框架能十分钟收敛。

拿去给现有系统做体检。 把上面那张表里六项拉出来自测：有没有系统性评估、成功率量化了吗、成本能归因吗、多模型路由做了吗、上下文写入与淘汰策略是什么、MCP 有治理吗。六项里缺三项以上，基本可以判断还没到能上生产的阶段。

拿去排补短板的顺序。 数据给的优先级很明确：先补评估（因为它决定其他改动的效果能否被证明），再补路由与成本（63% 的单项最高需求），最后才是上下文策略（虽然呼声最高，但它是持续优化项而非阻塞项）。这个顺序和大多数团队的直觉是反的。

争议与局限

样本有偏差。 1906 份问卷来自北京、深圳、广州、上海、杭州的线下开发者沙龙，受访者以技术决策者、架构师、一线工程师为主。这群人本来就偏向"已经在做 Agent 的"，所以 46% 的开发率可能高于全行业真实水平。

数据是自报的。 任务成功率、评估方式、成本归因全靠受访者自述，没有交叉验证。特别是"成功率"这个指标，各家定义可能完全不同。

手册有立场。 这是阿里云主导的项目，运行篇里的 AI 网关、状态存储、资产注册中心，与它的产品线高度对应。读的时候要分清两类内容：哪些是行业共性判断（比如"Agent = Model + Harness"），哪些是厂商主张（比如"需要一个统一流量入口"）。后者有道理，但不是唯一解。

它是白皮书，不是教程。 30 章里概念框架和判断占大头，可直接抄的代码很少。想照着做出东西，得自己去补工程细节。

作者自己也承认时效问题。 前言里写得很坦白：这本书里的体系、判断、经验、教训，也许不久就会被修正甚至推翻。所以它是 2026 年 10 月的一份快照，不是定论。

还有一处内部口径不一致。 调研报告正文说"能基于运行轨迹自动评估的不足 8%"，另一处写"只有 6%"，同一份报告里两个数。差距不大，但说明这类自报数据的精度有限。

延伸问题

那 18% 上了生产的企业里，有多少是真的无人值守，多少其实是"人盯着跑"？
把成功率做到 84% 的那批企业，单位任务成本是多少？可靠性和成本之间有没有一个公认的平衡点？
Harness 这一层会不会像容器编排一样，最终收敛成少数几个事实标准？如果会，现在自建的东西有多少会作废？
手册把"评估"排在补课第一位。但如果一个团队连业务指标都没定清楚，评估该从哪一步开始？

怎么读这本手册

如果只读一部分，按身份选：

要做技术选型或立项：调研报告 → 第 1–3 章 → 实践篇 → 第 30 章
要把 Agent 接进生产：第 7–9 章 → 第 13–14 章 → 第 18–23 章
在搭多 Agent 系统：第 4–6 章 → 第 10–12 章 → 第 13、16 章
负责评估与持续优化：第 13 章 → 第 18–23 章 → 对应领域案例

手册原话是"可迁移的抽象比押注某个具体框架更有价值"。这句话在选型还没收敛的当下，比任何框架推荐都实用。