46% 的团队在造 Agent，18% 敢让它碰生产

阿里云开源了一本《AI Agent Handbook》，30 章，GitHub 仓库 Apache 2.0 协议，也有在线阅读站。内容围绕 Agent 的架构、构建、运行、治理、调优整个生命周期，外加一份 2026 年开发者调研和一批企业案例。

仓库地址：https://github.com/aliyun/ai-agent-handbook

前言解释了为什么重写。去年 9 月他们发过《AI 原生应用架构白皮书》，讲的是怎么快速构建智能体。一年过去，市场的关注点挪了位置，落成三句话：让概率智能变成能扛关键任务的可靠生产力；把稳定、安全、性能、成本做成能大规模部署的基础设施；让 Agent 进核心业务流程，而不是停在孤岛试点。顺带还统一了一批术语，Harness、Runtime、Agent、Workflow 各自指什么，先对齐再说，因为同一个词各说各话，被模型放大后会更乱。

调研数据里有几组值得单独拿出来。

已开发完成或开发中的合计约 46%，去年这个数是 36%。真正部署到生产的约 18%。持续迭代的比例更低。形态上单 Agent 约 40%，多 Agent 约 42%，以 HITL 为主要架构约 15%。自主度是可调参数，跟新旧无关。编码是最先规模化的场景，通用 Agent 框架采购约 78%，Coding 工具约 57%，近四成两样并用。

构建之后的难点集中在两处：上下文和记忆的需求约 90%；多模型路由与成本治理约 63%。评估上，人工抽查约 55%，基于轨迹的自动评估不足 8%。成功率到 90% 以上的约一成，还有约 16% 根本没量化过成功率。MCP 关注或落地合计约 37%，企业内私有部署只占 9%。

46% 和 18% 之间的落差，评论区讨论得最多。有网友说看那行看愣了，因为对得上：demo 演完全场鼓掌，真接上业务全靠人肉盯着兜底。后来被逼出一条土规矩，没写清楚过没过，不准进核心流程。笨是笨点，比再搭一套测试管用。

评估那组数的问题更隐蔽。90% 的团队喊要上下文和记忆，不到 8% 有基于轨迹的自动评估。很多团队在改 prompt，但答不出这次改动成功率变了多少。多 Agent 占到 42% 之后会更难，人工抽查只看得到最终输出，哪一步交接把上下文丢了根本看不出来。有网友顺着这点追问，治理章节讲成本归因时，有没有按 trace 把 token 花费拆到单个 Agent、单次工具调用这一级。这是个好问题，也是企业真正要算账的地方。

手册把治理单独拉成了一块，13 到 16 章，可观测与成本归因、安全（注入、鉴权、高危授权、出域）、Prompt/Skill/MCP/Agent 资产管理、上线前仿真与质量验证。社区反馈里对这块评价最高。有网友的总结是：企业 Agent 难的从来不是 demo，是权限、审计和出错后谁背锅。另一位网友的做法是进场先搭私有网关，把工具调用绑死在审批流和身份鉴权上，上线前拿固定样本测返工率，拿不出审计日志，风控不签字。还有个更朴素的三条：每个 AI 能碰什么写清楚，做完有人验收，碰到不可恢复的操作先停下问人。

也有质疑。有网友直接问阿里云有没有成功的 FDE 案例，没有的话看文档意义何在。这个问题手册没正面回答。另一位翻过仓库的网友提到，实践篇 18 个案例里研发效能占 9 个，剩下的包括吉利汽车、塔斯汀这类运维落地，以及设计工程、客户运营方向。

手册目录大致这样：架构（1-2 章）定义 Agentic Application 的边界和企业成熟度；构建（3-6 章）以 Harness 为核心，讲任务编排、长程推进、上下文与状态、Memory/Knowledge/Skill、受控行动；运行（7-12 章）Runtime 与沙箱、状态存储、AI 网关统一 LLM/MCP/Agent 三类流量、异步任务、Multi-Agent、分布式通信；治理（13-16 章）；调优（17-24 章）分模型侧和 Agent 侧两条线，模型侧是 SFT、Agentic RL、蒸馏，Agent 侧是从 Trace 到 Trajectory 的数据飞轮、黄金数据集、Badcase 回归、受控自进化；实践（25-29 章加两个专题）；展望（30 章）从 Agentic Application 走向 Agentic OS。

成熟度分了 L1 到 L4：辅助生成、受控自动化、Agentic Execution、Managed & Optimizing。全书后半部基本在回答怎么从 L2 往 L3、L4 走。

手册不短，30 章，适合当参考书翻，不适合从头读到尾。真正有信息量的判断藏在两处：一句是自主度是可调参数，另一处是那组调研数。投入在涨，评估没跟上，治理还没成建制。这三件事不同时推进，46% 和 18% 之间的缺口不会自己合上。