ARTICLE · 1102262

阿里 62 页 AI Native 研发手册解读

发布时间：2026-09-30 09:33:02 最近访问：2026-09-30 09:33:02

大家好，我是玄姐。

PS：AI 越强大，人越需要哪些能力？点击预约直播。

刚刚的云栖大会上，阿里正式发布了《AI Native 研发范式实践手册》，62 页，三个真实业务案例、五个共性挑战、一整套企业级 Agent 基础设施方案，全是内部真实业务里踩坑踩出来的东西。
我第一时间读完，一句话感受：这本手册最值钱的判断是，Coding 已经不是瓶颈，环境与验证才是主战场。这篇文章不谈理念，把手册里的数据、案例、架构、打法全部榨出来，没时间读原文的，看这篇就够了。

PS：AI 研发范式跃迁更多案例深入免费学习去这里：

1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"AI 研发范式跃迁” 就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。

一、先说结论：写代码这件事，已经不配当瓶颈了

手册里有一组数据，建议所有做研发管理的朋友背下来：

截至 2026 年中，主流模型在 SWE-bench Verified 上的通过率，从两年前的不足 30% 爬到了 80% 左右。
在更贴近真实工程的 Terminal-Bench 2.1 上，Claude、GPT-5.6 Sol、Qwen3 这批模型都突破了 85%。
阿里内部粗略统计，生成代码本身只占整个研发链路的 20% 到 30%，甚至更低。

再看一个真实案例，特别扎心。一个端侧交互实验需求：编码加本地验证 1 小时搞定，但后面排着跨团队影响分析 1 到 2 天、联调环境准备 2 到 3 天、多平台联调 5 到 7 天、发布审批 3 到 4 天、灰度验证 2 到 3 天、封网期等待 7 到 10 天，总耗时约 3 周。编码占比不到 1%。

按照阿姆达尔定律，一个只占三成的环节被压缩到接近零之后，系统整体的收益是有明显上限的。Coding 被解决得越彻底，需求理解、环境构建、测试验证、发布运维这些占七成的环节，就越成为新瓶颈。

为什么偏偏是 Coding 最先被解决？手册给了一个很底层的解释：AI 总是优先解决那些反馈公开、验证可以规模化的问题。编译过不过、测试过不过，跑一下就知道，这是少数「对错机器自己就能判」的领域。而企业级生产环境里，答案藏在内部各个研发系统里，没有公开反馈，验证一次的成本还很高。

所以手册的判断非常明确：让 AI 更会写代码不再是主战场，主战场在验证与环境。价值重心正在从代码本身迁走，2024 年编码占研发价值比重的 50% 到 60%，到 2027 年以后编码会缩到 5% 到 10%，环境与验证会涨到 40% 到 50%。谁的环境与验证体系强，谁就能让每一代新模型释放出更大的价值。

二、两年走完的路：从 Copilot 到 Agentic 时代

手册开头把行业这两年的脉络捋得很清楚，我帮你压缩成一条时间线：

2024 年中，主流形态还是 Copilot。GitHub Copilot、Cursor、通义灵码，都是 IDE 内嵌补全加对话，解决单点编码效率。
2024 年 3 月，Cognition 发布 Devin，第一次提出「AI 软件工程师」，能力有限，但把行业叙事从辅助工具拉向了自主 Agent。
2024 年 11 月，Anthropic 发布 MCP，给 Agent 连接外部工具建立了开放标准。
2025 年初，Claude Code 以 CLI 形态面世，Agent Harness 框架走向前台。Agent 不再嵌在 IDE 里等指令，而是以「行动、验证、纠错」的闭环自主推进任务。
随后 OpenAI 推出 Codex CLI 并迭代到 Multi-Agent V2，Google 出了 Gemini CLI 和 Jules，Cursor 也转型 Agent 模式。行业从 Copilot 时代全面进入 Agentic 时代。
2026 年 5 月，Anthropic 推出 Claude Managed Agents，提供托管 Agent 运行时。Microsoft Entra 开始把 Agent 当作企业目录里的独立身份管理，MCP 授权规范纳入 OAuth 2.1，OWASP 专门整理了 Agentic AI 威胁模型。

一句话：Agent 的运行环境、身份权限、可观测与评测，正在从可有可无变成规模化落地的刚需。

阿里看得很清醒，手册里直接点破：从模型能力到大企业研发效能 10 倍提升，中间隔着三个 gap。第一，有没有一套完整的 Agent 基础设施，支持 Agent 安全可靠地访问内部系统。第二，有没有重塑工作流、整理历史知识，让 Agent 拿到围绕目标的清晰上下文。第三，有没有重塑组织文化、人才画像和激励机制。整本手册就是围绕这三个 gap 展开的。

三、案例一：AIDC 数字投手，从超级个体到云上 Scrum

第一个案例是 AIDC 数字投手智能营销助手，给 Alibaba.com 商家做广告诊断和投放优化。一个 6 人小队，走出了三个时期，这条演进路径我认为是所有团队都会经历的：

第一个时期，超级个体。团队统一用一款主流 Coding Agent，一个人指挥 3 到 5 个会话是常态，体感上一人干出原来两三人的活。但很快出现两个障碍：消化障碍，Token 烧出大量中间产物，同事讲不清设计，只能把问题抛回给 Agent；复用障碍，会话里沉淀的知识很难团队级复用。本质是一句话，Token 放大的是个人产能，产能锁在个人电脑和单个会话里。

第二个时期，数字员工。把本地会话改造成云上运行的数字员工，覆盖产品、研发、评测、数据分析，人的职责转为设目标、给输入、验收结果，实现每周多次交付。个人产能第一次变成团队产能。但新问题也来了：岗位孤立，串任务要靠人肉当调度员；质量不稳，验收耗的工夫不比执行省下的少；任务认领，没有谁主动接活，还得人来点名。

第三个时期，云上 Scrum。给数字员工建了自己的协作专线，按业务域组织。它们不需要排期，来了活就起线程；不用开日会，卡点随时沟通；不用总结会，每个任务完成都有反思。人的工作收拢到两件事：Loop 维护，管环境和验证；寻找真需求，用增长预估工具评估哪个需求对关键指标收益最大。

产品架构上有个设计很值得抄。团队刻意不用纯 ReAct 模式，而是把数字投手拆成「经验、手脚、头脑」三个组件加一套评测：投手经验把专业经验提前提炼成结构化结论；投手手脚把状态、权限、参数约束提前算好，给头脑一份明确的可操作清单；投手头脑只在预先限定的可控空间内推理取舍；投手评测用黄金用例加综合评分表，红线问题一票否决。本质是用预计算和工程收口，换 Agent 产出的可控性。

上线后效果低于预期，复盘发现技术架构只解决了「能不能做」，没解决「做得对不对」。于是转向数据闭环，建了两条云上供给线：经验 Loop 把策略挖掘和策略生产拆给两个数字员工协同，策略交付周期从约 10 天缩到 2 天；手脚 Loop 把线上失败轨迹直接转成能力建设需求，约 80% 的核心能力实现 Skill 化。

这个案例的反思我直接引用：AI Native 不是追求无人化，而是重新划分职责边界。系统负责状态、权限、规则这类高确定性事务；AI 负责分析、生成和长程执行；人负责目标设定、关键决策、风险取舍和最终责任。执行权逐步交给 AI，判断权和责任留在人手里。

四、案例二：千问用增 Agent，可靠交付就抓四件事

第二个案例是千问用增 Agent，用 Agent 重构用户增长体系，推行全栈 AI Coding。三个多月跑了三个阶段：第一阶段粗放探索，约 15 名服务端工程师分头试，部分场景代码生成速度达到传统方式的数倍甚至约 10 倍；第二阶段做标准化和存量工程适配，让 AI Coding 从个人技巧变成团队能力；第三阶段提升 SDLC 覆盖度，从编码扩展到需求理解、方案设计、联调排障。

这个案例最干的货，是把可靠交付聚焦到四个环节：

第一，让 AI 快速理解项目。构建可按需读取的项目文档和代码知识图谱。CodeDocs 解释模块职责和设计背景，Code Graph 精确查询代码定义、调用关系和影响范围，Rules 把团队经验固化成可执行约束。三者结合，Agent 能从业务语义快速定位到具体代码。

第二，让 AI 准确理解需求。不再假设需求描述是完整的，让 AI 主动追问隐含的业务和技术决策，沉淀成可追溯的 Spec 和 Tasks。人写需求时总会省略权限边界、并发处理、幂等策略这些默认知识，AI 没有组织记忆，只能猜。前置澄清是在开发成本最低的阶段暴露风险。

第三，让 AI 高效且可靠地编码。引入 TDD，把「代码是否正确」转化成可观察、可重复的执行反馈。注意手册里这个洞察：可靠性往往不是单点问题，比如并发场景下沙箱重复创建，真正要保证的是请求入口、数据库事务、消息发布和消费执行整条链路的幂等。测试重点覆盖需求边界、关键分支和已知故障模式，而不是单纯追覆盖率。

第四，让 AI 快速定位线上问题。用统一 TraceId 打通日志、上下游状态和代码调用关系。排障不从猜测根因开始，先收集 TraceId、结构化日志、调用关系这些事实证据，再基于完整请求链做判断。排障从个人经验变成可复用的工程流程。

三个多月的成绩单：平均交付周期缩短一半，千行代码缺陷率下降 70%，变更失败率下降 90% 以上。

这个案例最后有句话我特别认同：越来越少追求「让 AI 做更多」，更关注「如何让 AI 稳定做对」。上限靠模型，下限靠约束、规划、验证和工程兜底。

五、案例三：万有无界，让需求沿着事实推进

第三个案例是万有无界，一个企业级人与 Agent 协作平台。它的打法核心是一句话：一个研发任务，拆成上下文资产、工程执行环境、验证证据三个相互依赖的部分，形成首尾相接的闭环。

几个关键数字先看：近四个版本约 80% 的交互体验类需求用基于 Git 的可交互原型承接，视觉类问题一次修复成功率约 89%，线上千行代码缺陷率低至千分之 0.01。

各环节的做法：

评审环节，先把需求变成可操作方案。产品经理在评审前把业务目标做成基于真实项目代码、可以直接操作的交互原型。评审参与者直接进页面检查正常态、空态、异常态、权限和数据依赖，讨论对象从抽象描述变成真实行为。目前约 100 个需求、50% 以上的产品经理在用这种方式工作。

设计环节，在真实工程里完成交付。设计师在独立分支里用工程 Skill，基于真实页面入口、组件树、设计系统和设计 Token 完成可交互实现。研发直接继承这个分支，集中处理真实数据和业务逻辑。设计师从「交标注」变成「交可运行页面」，接入协作流程后单月近 20 个活跃日在参与代码协作。

开发与联调，从正确入口进入真实环境。统一工程工作区先判断目标端、改动类型和共享范围，公共能力变化先重建共享契约再让各端接入，避免在陈旧依赖上得出「已经修复」的错误结论。

测试与修复，从缺陷描述转向证据驱动。搭了一套 auto bug fix 流程，插件把版本、环境、页面入口、复现步骤、请求日志一起带进缺陷上下文，AI 在同一版本同一环境中复现、修改、回归验收。上下文充分的视觉类缺陷，一次修复成功率 89%。

但团队也很诚实：autobugfix 比例已经 60% 以上，bug 日清率却只从 53% 爬到最高 63%。原因分析得很到位，触发还依赖人或确定性流程，校验还依赖人。所以下一阶段的形态是个人执行节点加团队调度层，让任务能主动发现上下游状态、持续推进。

六、五个共性挑战，每个都是真金白银的坑

从这三个案例和阿里内部更多团队的实践里，手册提炼了五个共性挑战。这部分是全书的骨架：

挑战一，环境与验证驱动。沿着既有流程做 workflow 化改造只是过渡形态。类比电气化的历史，早期工厂只是用电动机替换蒸汽机，传动轴和布局不变，收效有限；真正的跃升来自单元驱动，每台机器有独立电机，整个生产系统被重新设计。对应到研发，就是让 Agent 获得独立完成研发闭环的能力，主动把内部研发工作流改造成有反馈、可验证的环境。具体要建五样东西：业务领域知识、可复现可调用的研发环境、分层验证体系（秒级编译测试、分钟级集成契约、人工判断只留机器判不了的）、端到端研发系统打通、Spec 新写法（区分长期约束和待验证假设）。

挑战二，平台能力亟须升级。像 Aone 这样的研发平台是围绕人设计的，Agent 模拟人去点 Web UI 会遇到三个问题：很难稳定进入系统，每次页面改版都可能中断任务；很难获得完整确定的上下文，当前仓库对应哪个应用、CR 该用哪个模块，这些对人隐式成立的事实，Agent 推断错一步就全盘皆错；工具只提供信息不推进任务，告诉你流水线失败了，但不告诉你下一步能干什么。阿里为此建了一个 CLI，给 Agent 做一层可以稳定进入、稳定理解、稳定推进任务的研发操作面，目前每天被数万工程的 Agent 使用。

挑战三，度量。只看「多少人用了 AI、AI 写了多少代码」，后面基本都会跑偏。AI 写了代码不等于进了提交，进了提交不等于发布成功，发布了不等于需求价值交付。度量对象正在从工具使用量转向研发生产系统的运行质量。做法是先把采集事件统一成研发事实，再沿 Session、Commit、Change、Workitem 做归因，最后沉淀成三层指标：L1 AI 效能层管用起来没有，L2 工程质量层管质量守不守得住，L3 价值交付层管业务结果有没有改善。三层合在一起才构成完整证据链，L1 证明 AI 进入过程，L2 证明风险守得住，L3 证明业务有收益。还有一类容易被低估的指标是上下文资产：Skill、MCP、Spec、Runbook 这些有没有被复用、被更新、被验证。

挑战四，数字员工如何实现自主性。人与 Agent 协同大致三个阶段：完全辅助、云端自主、多 Agent 协同。看起来是自动化程度在提高，实质是信任边界在不断外移。用实习生理解 Agent 很有帮助但只能用一半，Agent 需要导师、职责、权限边界和 Review，但它没有职业伦理和隐含常识，治理还得靠机器可执行的护栏。落地分三步：先让 Agent 可见可管理，再可控可复用，最后才谈自主性。

挑战五，组织能力如何配套。康威定律、人月神话、泰勒分工，过去所有组织设计的前提都是「以人形约束为前提」，而 AI 恰好和人形成镜像反面：人有沟通衰减，AI 没有；人有切换成本，AI 极小；人的记忆有限，AI 几乎无限。组织不能再被一张 org chart 描述，更像一张 execution graph，核心问题从「谁拥有这件事」转向「任务如何流转、能力如何组合、风险如何被控制」。手册给了五条具体方案：专业岗合并、3 到 5 人小团队、管理者定位转变、更大胆更高频的激励、新老业务分而治之。

最后这点很扎心但必须说：蒸馏焦虑是真实存在的。员工每写一份 SOP、每教 AI 一个流程，结构上接近一种替代关系。如果员工意识到「我说得越多，被替代得越快」，关键知识就会开始藏匿，而 Harness 工作恰恰需要员工说出隐性约定，转型就会失败。明确 AI 红利的分享方式、建设真实的接住机制、诚实分类哪些岗位在变，这不是情怀，是转型能不能成的必要条件。

七、企业级 AI 研发基础设施全景

手册第三部分把基础设施展开成了一张完整的技术全景图，这部分是工程含量最高的。整体架构以 Agent Harness 框架为核心，外围重点建设三个方向：工具体系打通内部系统，Sandbox 与 Coding 环境提供可靠运行基础，身份权限与 Guardrail 守住安全底线，再加一套可观测能力兜底。（此处插入总体架构黑板报图）

Agent Harness 是核心引擎。它的最小工作单元是一个持续运行的闭环：拿到目标后，组织模型获取上下文、规划下一步、调用工具、观察环境变化，验证不满足就把结果喂进下一轮，遇到歧义或高风险决策就转交人工。框架的四个核心职责：上下文管理（什么时候加载什么、什么时候裁剪压缩，上下文不是越多越好）；规划、状态与恢复（会话中断后能从最后一个可信位置继续）；工具、验证与纠错（构建失败不是终点，而是下一轮行动的输入）；人机协同。这里有个很有意思的数据：Anthropic 对约 40 万次 Claude Code 会话的分析发现，用户平均承担约 70% 的规划决策，Agent 承担约 80% 的执行决策。人管目标和取舍，Agent 管约束内执行，这就是现实的分工。

工具体系是手和脚。MCP 和 CLI 解决「如何查询、操作、验证外部世界」，Skill 解决「面对这类任务应该怎么做」。Skill 不是接口清单，是可复用的任务方法包，包含步骤、最佳实践、脚本和完成标准。工具和技能多起来之后，评测是规模化可用的前提，盯两个基础指标：命中率，面对任务有没有选对能力；成功率，选对之后有没有用正确的参数、顺序和权限完成操作。长期低命中低成功的能力，该拆拆该删删。

企业知识库是上下文供给线。它对 Agent 有四个本质作用：提供领域世界模型，把知识从模型参数中外置出来（可更新、可纠正、可撤回、可授权），为行动提供依据与约束，形成可共享可审计的组织记忆。落地是一条四环节链路：整理（推荐参考 Google 提出的 OKF 开放知识规范，Markdown 承载内容、YAML 描述元数据）、加工（切片、索引、保留结构）、治理（版本、权限、有效期，使用反馈回流）、供给（RAG、API、本地文件按需选择）。特别提醒，知识供给不只有 RAG。

Sandbox 与 Coding 环境解决「代码改对了但项目跑不起来」。阿里开源的 OpenSandbox 已经捐给 Agentic AI Foundation，是这块的代表性实现，四个设计边界值得抄：生命周期控制面（镜像、资源上限、TTL 到期回收，避免孤儿实例）；实例内执行面（结构化返回退出码和日志，Agent 不用猜）；网络边界（默认拒绝出站，按任务放行，防止提示注入和依赖投毒被放大）；凭据边界（Sandbox 只看到占位值，真实凭据由可信代理在请求匹配后注入，长期密钥永远不进入 Agent）。Coding 环境的核心主张是：仓库只是可运行项目的一部分，要把工具链、配置、数据、依赖、网络策略一起声明成可执行的环境定义，环境定义长期维护，实例随任务创建，验证通过的状态沉淀为新基线。交付物从一份代码修改，扩展为一条可以重新运行和检查的验证路径。

身份与权限是硬约束，不靠模型自觉。Agent 可以规划行动，但不能自行创造权限。五条原则：建立可验证的复合身份（稳定 Agent、运行实例、任务上下文三层主体）；权限只能逐级收敛，有效权限等于用户权限、Agent 能力上限、平台策略、本次委托范围和运行时约束的交集；允不允许由 PDP 这样的确定性系统判断，PEP 分布在 Runtime、网关、MCP Server 和资源服务多层执行；长期凭证不进 Agent，由 Credential Broker 代管或兑换短期凭证；权限必须可撤销、可追溯。还有一个关键设计：授权结果不该只有允许和拒绝，还要有第三种「需要补充授权」，资源服务返回结构化的授权要求，人在独立界面确认，模型只收到高层状态，接触不到授权码和 Token。

Guardrail 守住生产安全。以配置发布的批次恢复为例，核心机制叫 GuardrailRun：固定版本的 GuardrailSpec（规则）加不可变的 ChangeSet（本次动作快照）加 Agent 递增提交的 Submission（结果与证据）。Agent 按规范自主查日志、监控、告警，为每个检查项提交三态结果：PASS 证据充分、BLOCKED 发现明确阻断事实、UNKNOWN 证据不足无法可靠判断。Guardrail 不理解业务语义，只执行确定性协议：必检项缺失或存在 BLOCKED、UNKNOWN 就不能放行。Agent 可以优化调查方式，但不能修改已发布的检查口径。这套机制证明了，Agent 参与生产不必以放宽安全标准为代价。

可观测回答「Agent 为什么这样行动」。分两层：System 层看系统运行是否正常，指标、日志、Trace 那套沿用 OpenTelemetry；Behavior 层看行为是否符合预期，核心对象是 Trajectory，一次任务从输入意图到最终结果的完整执行记录，包含模型调用、工具调用、Skill 执行、状态变化。Trajectory 同时也是评测的核心数据资产，可观测和评测共享同一份数据，形成持续优化的闭环。

八、落地建议

榨完干货，给大家六条可以直接动手的建议：

第一，停止在代码生成上继续内卷。去盘点你的研发链路时间构成，找到那个「编码 1 小时、上线 3 周」的真实案例，把资源投向跨平台协同、联调、发布与验证的工具化。

第二，把内部工作流改造成有反馈、可验证的环境。AI 的边界由可验证的反馈决定。分层建验证体系，秒级反馈给高频自主迭代，分钟级反馈覆盖真实行为，人工判断只留机器判不了的。

第三，平台改造先做统一入口。与其让 Agent 模拟人点 Web UI，不如给它一层稳定的 CLI 操作面。身份登录、短期凭证、命令级权限、操作审计，要做成平台能力，别留给每个命令各自实现。

第四，度量从第一天就按三层建。L1 管用没用起来，L2 管质量守没守住，L3 管业务有没有变好。只看一层，要么鼓励为了 AI 而 AI，要么变成质量审计。别忘了把 Skill、Spec 这些上下文资产纳入度量。

第五，数字员工先当实习生管。有工号、有导师、有职责边界、有 Review，从边界清晰的小任务开始跑，每次任务结束把失败经验沉淀回知识库，再逐步扩大授权。

第六，组织上先跑出超级个体，再谈重组。别急着画新架构图。先让一部分人用新范式干出 10 倍的事，小团队冲锋，高频激励跟上，同时诚实面对蒸馏焦虑，把 AI 红利的分享方式说清楚。

九、结语

手册自己的总结很实在：过去几个月，团队的情绪经历了一条明显的曲线，从「软件研发很快就能托管给 AI」的兴奋，到环境搭不起来、上下文拼不全、验证跑不通、发布卡在流程上的务实。这种从兴奋到谨慎的过程，本身就是认知校准。

我的判断是，这本手册最珍贵的不是某个具体方案，而是它把行业共识往前推了一步：从模型及 Harness 的能力，到企业研发效能 10 倍提升，中间的 gap 靠模型自然溢出填不上，只能靠基础设施、知识资产和组织设计去填。今天建的环境与验证体系，决定了下一代模型能在你手里释放多大价值。

与其等更强的模型来拯救效能，不如这个周末就把第一个 Sandbox、第一张知识卡片、第一条度量链路建起来。

送个福利：

新一代 AI 原生学习伙伴 AITutor「www.aiaitutor.com」，4500+ 门多模态 AI 课程、7×24 小时 AI 导师已全面开放，快来免费体验吧。

PS：AI 越强大，人越需要哪些能力？点击预约直播。

十、加我微信

扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇

加星标★，不错过每一次更新！

⬇戳”阅读原文“，立即体验 AITutor