企业官网建设流程全解析

数据来源：aliyun/ai-agent-handbook 仓库根目录下的2026-agent-survey-report.md。
在北京、深圳、广州、上海、杭州举办多场线下开发者沙龙，回收有效问卷 1906 份，受访者以企业技术决策者、架构师、一线工程师和产品经理为主。
本文件是《AI Agent Handbook 精读》系列的配套独立报告解读篇，另外三篇精读分别讲 Harness 工程、运行与治理、调优案例与 Agentic OS。

这份调研最有用的地方，是它把"Agent 落地难"这句空话拆成了可定位的具体缺口。下面按报告原有结构逐节拆开，保留全部原始数字。

一、六个核心发现

图：六个核心发现与各自的关键数字。

补充两条解读：

• 发现 1 里的"36% → 46%"和"18%"是理解全篇的钥匙：开发率在涨，上线率没跟上。白皮书自己的判断是，卡点不在意愿也不在模型，而在能优化 Harness 层、且开箱即用的工程配套。
• 发现 4 与发现 6 是一组因果：评估基建不成熟 → 成功率无法量化 → 无法定位问题也无法证明改动有效 → 长期停在试点。报告原文说得很直接，16% 从未量化过成功率的企业，实际上无法判断自己的 Agent 是否在正常工作。

二、Agent 开发进程与生产化水平

2.1 投入已成共识，生产化仍是少数派

明确表示暂无开发计划的受访者从去年的 22% 降到15%；正在调研和计划开发的从 47% 降到25%；已开发完成或开发中的合计46%（去年 36%）。但真正部署到生产环节的只有 18%。

图：三城样本的开发状态分布。以广州为例（n=394）：已上线并持续迭代 17.5%，开发中 27.7%，计划开发 38.1%，暂无计划 16.8%，实际开发或已开发的合计 45.2%；上海（n=234）为 48.3%，深圳（n=342）为 47.1%。

2.2 受阻的不是意愿，而是工程能力储备

上线率的差距普遍大于开发率的差距。上海大型企业已上线率 45%，小微企业 16%；深圳则是 38% 和 17%。

图：同一城市内，大型企业与小微企业的上线率差距接近三倍。

差异的来源被归结为一句话：是否具备持续演进 Agent 的工程能力——包括 Agent 的组织和协作、治理、优化和沉淀。

三、Agent 架构的选型分布

3.1 新旧形态是共存，不是替代

以单 Agent 为主要架构的企业占40%，开始引入多 Agent 的占42%，另有15%把 Human-in-the-Loop（关键步骤交由人确认）当作主要架构原则来设计，而不只是附加的审批开关。

图：多 Agent 协作 39.3%–44.4%、单 Agent 35.9%–39.8%、Agent+人类协作 9.1%–16.7%、Agentic RAG 2.0%–3.2%（三城口径）。

结论很明确：自主度是一个可调参数，混合形态会长期存在。Chat/RAG、Workflow、Copilot、Agent 与 Managed Agent 在同一家企业内部往往同时存在，选择取决于任务的确定性程度与容错空间，而不是技术新旧。

3.2 构建之后的三大痛点

受访者反馈的最大痛点是状态与上下文在多 Agent 协作中衰减，占 60%；第二和第三是死锁雪崩与成本失控——报告指出这两者的本质也是调用链与状态缺乏约束的后果。

被问到最希望补齐哪些能力时，两项诉求比例更高：研发—测试闭环 65%、端侧与开源运行底座 73%。前者说明多 Agent 的验证成本已被感知为主要负担，后者说明企业对运行底座的自主可控有明确诉求。

图：左为多 Agent 落地瓶颈，右为最期待补齐的能力。

四、优先落地场景与工具链渗透

4.1 编码先行，但竞争激烈

企业采购 Claude Code、Codex、Cursor、Qoder 等编程 Agent 的占57%，使用通用 Agent 框架的占78%，近四成企业同时在用两者。

图：编程 Agent 与通用 Agent 框架的渗透率。

三条判断：

1. Coding 是目前唯一实现规模化落地的付费场景。原因很具体——反馈信号明确（能否编译、测试是否通过）、环境边界清晰（代码仓库与工作区）、错误代价可控（可回滚）。这三项恰好是 Agent 稳定运行的前提条件。
2. 还没有出现事实标准。前十位呈平缓下降而非陡峭长尾，多数企业仍在多框架并行试用，围绕单一框架构建企业内部标准的做法风险较高。
3. 能力正在互相渗透。从编程 Agent 沉淀出的工程范式——Skill 的组织方式、工作区隔离、工具调用的权限约束、上下文的分层加载——正在被迁移到企业办公场景。随着办公 Agent 普及，编程 Agent 与通用 Agent 的边界越来越模糊。

4.2 优先落地容错空间大、能人工兜底的场景

最广泛的落地场景是员工效能、代码工程、数据分析；将 Agent 引入企业核心业务流程的不到 40%。

图：Agent 落地场景分布，核心业务流程占比明显偏低。

这个排序与上线的分布是自洽的：Agent 优先进入可人工兜底的场景；要进入核心业务流程这类严肃场景，需要更完整的治理配套。

五、上下文、工具与协议层的能力瓶颈

这是整份调研里对工程实践指导最直接的一节。

5.1 上下文的问题不在窗口大小，而在写入、淘汰与检索策略

在记忆与上下文、工具的痛点调研中，表示无明显痛点的不到 10%。排在前两位的是：

• 检索不准 54%
• 记忆更新与遗忘机制缺失 48%

窗口限制只排第三。也就是说，扩大上下文窗口解决不了排在前两位的痛点。

图：记忆/上下文与工具侧的痛点分布。

工具侧的结构类似：工具过多、选择困难 52%，幻觉调用 50%。报告的结论是——工具的组织方式与描述质量，比工具数量更决定调用成功率。

对应的白皮书章节：运行篇第 8 章《Agent 状态存储与语义资产》讲持久化、向量索引与检索；治理篇第 15 章《AI 资产的发现与管理》讲工具描述、版本与按需发现的组织方式。

5.2 MCP 差的是企业级配套，不是协议理解

已经关注或已经落地 MCP 的企业合计 37%，而真正完成企业内私有部署的只有 9%。

图：MCP 的关注度与落地率之间存在明显落差。

落差的原因被列得很清楚：要在企业内真正跑起 MCP，需要私有注册中心、统一身份与鉴权、版本与灰度管理、审计留痕，以及与网关的集成——这些都不是协议规范本身提供的。

同时有28%的受访者明确提出 MCP 服务管理与注册中心的需求，这一比例与已落地比例接近，说明需求正从认知转向工程实施。

六、运行底座与网关层的能力诉求

6.1 多模型并用已成既定事实，需要统一入口承接

多模型路由与自动降级被 63% 的企业列为最需要的网关能力，是本次调研中比例最高的单项需求。具体场景是：不同任务匹配不同模型、主模型不可用时降级、按成本与延迟动态选择。报告强调——这类需求无法在应用代码里逐个解决，需要一个统一的流量入口来承接。

6.2 成本归因比合规更早成为观测重点

在可观测能力的诉求里，端到端全链路追踪排第一（52.1%–56.9%），成本归因排第二（47%–53%），高于审计合规与语义质量监控。

图：左为 AI 网关能力需求，右为可观测性能力诉求。

报告对这条的解读值得注意：多数企业 Token 用量还不算大，却已经在为成本的可见性与可分摊做准备。这更接近一种预防性诉求——在规模上来之前先建立成本的观测与约束能力，而不是等账单失控后再补。

其它网关需求按热度依次是：语义缓存（43.6%–48.0%）、Token 级流控与配额、异步与批量任务调度、内容安全风控、Prompt/Agent 版本管理与灰度、MCP Server 注册中心。

白皮书的回应是把 AI 网关从"流量入口"扩展为"统一治理入口"，集中承接工具注册与检索、参数校验、模型路由、熔断重试、链路追踪与成本标签。

七、调优是智能体落地的重难点，但缺少高效的执行框架

7.1 越来越多团队开始做评估，但普遍停留在人工抽查

被问到用什么方法评估 Agent 效果时：

把 LLM-as-Judge、A/B 实验、离线数据集回归这三类常见手段里用上任一种的企业，合计34%。

7.2 评估目标不明确的后果，直接体现在成功率上

• 任务成功率达到90% 以上的企业仅约一成
• 成功率70% 以上的约55%
• 16% 的受访者根本没有量化过成功率

7.3 评估能力是提升生产可靠性的必经之路

图：左为评估手段使用率，右为生产任务成功率 70% 以上者占比——使用任一高级评估手段的企业 63.0%，缺乏系统性评估体系的企业 30.0%，已上线并持续迭代的企业 88.3%。

一句话概括：使用了评估手段的企业，任务成功率 70% 以上的比例，是没有评估体系企业的约两倍；而在已上线并持续迭代的企业里，这一比例达 84%。

三者相互关联：评估能力支撑迭代，迭代提升可靠性，可靠性才使持续进行评估成为可能。反过来，缺乏评估的团队既无法定位问题，也无法证明改动有效，容易长期停在试点阶段——这与"近一半在开发、仅约五分之一上线"的分布形成呼应。

八、总结：从可行性验证转向可靠性与成本

投入侧已经越过验证期——近一半受访企业在做 Agent，但只有约五分之一部署到生产环境，持续迭代的不到 10%。

卡点不是企业意愿，也不是模型能力，而是能优化 Harness 层、开箱即用的工程配套。

三个长期判断：

1. 形态碎片化是长期状态：单 Agent 与多 Agent 体量接近，Hybrid 不是过渡阶段而是长期状态。
2. 工具与框架选型没有收敛：这意味着可迁移的抽象，比押注某个具体框架更有价值。
3. 三件事必须先补齐：统一路由与成本治理、上下文与记忆的优化、不成熟的评估基建。