《AI Native 研发范式实践手册》是阿里团队 2026 年出的一份 68 页内部复盘，主编许晓斌，署名作者 19 人（含主编）。它记录的是一件事：当模型已经会写代码，为什么研发效率没有同比提升，以及要让 Agent 从「能写代码」走到「可靠交付」，企业还需要补什么。
上一篇拆了它的核心判断——编码只占研发链路的两三成，主战场移到环境与验证。这一篇按手册自己的结构往下走：三个案例给出机制，五个挑战划出问题域，八类基础设施给出工程边界，最后落到它自己承认没解决的问题。
先说清楚这份手册的坐标系
手册分四章：研发范式实践案例、实践中的挑战、企业级 AI 研发基础设施、总结。它的写作动机写在开头：从模型和 Harness 框架的能力，到一家大型企业研发效能的 10 倍提升之间，存在三个 gap——企业有没有建成完整的 Agent 基础设施；有没有通过重塑工作流和整理知识，让 Agent 拿到围绕目标的清晰上下文；有没有重塑组织文化、人才画像、激励机制和协同模式。
手册对自己的定位很克制。它写明这不是成熟方法论，更谈不上标准答案，很多做法仍在验证中，有些方向看得到趋势但还没跑通；技术架构可能半年后就需要重新审视。它甚至把团队的情绪曲线写进去了：最初模型能力跃升时，不少人认为软件研发很快能完全托管给 AI。实践一深入，环境搭不起来、上下文拼不全、验证跑不通、发布卡在流程上，大家逐渐从兴奋转向务实。
这句自我评价决定了怎么读它。它的可用部分在机制和问题域，不在数字外推——案例全部来自一家公司的内部业务，数据是内部统计。
三个案例：三条路径，同一个结论
手册挑了三个切入点完全不同的团队。
AIDC 数字投手：一支 6 人小队，为 Alibaba.com 商家做广告投放。他们的路径是组织协作，经历了三个阶段。
超级个体期，单人指挥 3~5 个会话，夜间也能交付长程任务，但遇到两个障碍：一是产物消化不了，团队消耗大量 Token 产出中间产物，评审和理解跟不上，同事讲不清设计只能把问题抛给 Agent；二是复用不了，一个会话里沉淀的代码梳理、数据分析、流程知识很难变成团队资产，最高效的方式反而是保留整个会话和工作区。
数字员工期，他们把本地会话改造成可自验证、可并行、可推进流程的数字员工，人的职责转为设定目标、提供输入、验收结果，但新问题是岗位孤立、质量不稳、任务认领靠人点名。
云上 Scrum 期，他们自建人机沟通专线，按业务域组织数字员工，形成了两条 Loop：经验 Loop 把策略挖掘和策略生产分给两个数字员工，用结构化契约交接，策略交付周期从约 10 天缩短到 2 天；手脚 Loop 把线上失败轨迹转成能力建设需求，约 80% 的核心能力实现 Skill 化。
技术上他们没有走纯 ReAct，因为广告投放对确定性、可解释性和执行安全要求很高。
他们把数字投手拆成四块：投手经验（把数据和运营沉淀提炼成「存在什么问题、证据是什么、建议什么处方、在什么条件下成立」）、投手手脚（把状态、权限、参数约束交给最接近事实的系统预计算，输出一份可操作清单）、投手头脑（只在预先限定的可控空间内推理取舍）、投手评测（黄金用例加综合评分表，红线一票否决）。
这套设计的本质是用预计算收拢复杂度，让 Agent 只处理需要判断的部分。
千问用增 Agent：走的是工程流程。项目由五种角色构成，其中全栈工程师对单个需求从设计到上线端到端负责。三个多月里，他们先让约 15 名服务端工程师分头探索，每周分享；再解决存量工程适配问题，因为单纯靠代码生成的边际收益开始下降，真正的难题变成让 AI 在已有代码库里准确理解项目结构和工程约束；最后把 AI Coding 扩展到更完整的研发流程。
他们把能力收到四个环节。项目理解靠三样东西：Code Docs 解释模块职责和设计背景，Code Graph 精确回答「具体在哪里、谁调用谁、改动影响什么」，Rules 把团队经验固化成可执行约束。
需求理解不假设需求已经完整，而是让 AI 主动追问隐含决策——比如「生成公开分享链接」背后其实涉及撤销机制、访问控制和数据一致性——再把确认结果沉淀成可追溯的 Spec 和 Tasks。
可靠编码引入 TDD，把「代码是否正确」变成可观察、可重复的执行反馈；他们还发现可靠性往往是链路问题，并发场景下 Agent 沙箱重复创建，需要保证的不只是接口幂等，还有请求入口、数据库事务、消息发布和消费执行共同组成的链路幂等。
线上排障统一 TraceId，打通日志、上下游状态和代码调用关系，先收集事实证据再判断，证据不足就交给有完整代码上下文的 Agent。
2026 年 5 月到 8 月，他们的平均交付周期缩短一半，千行代码缺陷率下降 70%，变更失败率下降 90% 以上。团队自己的总结是：AI Coding 的上限，很大程度取决于基础设施是否 AI 友好；相比追求更强的模型，持续建设高质量上下文、明确约束和可验证反馈更能提升稳定性。
万有无界：做的是需求与验证链路。平台型产品一个复杂需求横跨身份权限、消息协作、任务与资产管理，还要在 Web 端和桌面端保持一致，经过多次交接后需求和约束容易失真。
他们的做法是让需求沿着事实推进：评审前，产品经理用基于 Git 的可交互原型套件交出一个能点的方案，评审者可以直接检查正常态、空态、异常态、权限和数据依赖，系统整理产品文档、会议听记、讨论截图与标注、可操作原型、设计稿和历史材料这些多模态输入时，重点保留「人已经作出的决策」；设计阶段，设计师在真实工程里基于真实页面入口、组件树和设计 Token 完成可交互实现，评审后研发直接继承这个分支；
开发和联调阶段，统一工程工作区判断改动归属和影响面，公共能力变化时先处理共享契约，再确认页面实际消费了本次构建；测试阶段做现场采集，把版本、环境、入口、复现步骤、请求和关键日志、测试数据一起带进缺陷上下文，修复时在同一环境复现、修改并回到相同页面状态验收。
数据上，近四个版本约 100 个交互体验类需求，50% 以上的产品经理开始用这种方式工作，约 80% 的交互体验类需求用可交互原型承接；在手册限定的「上下文充分的视觉类缺陷样本」中，自动修复的一次成功率约 89%，当前统计范围内的线上千行代码缺陷率是千分之 0.01；协作工作区积累了 30 余项共享技能和 8 类专项 Agent 工作流，2026 年 6 到 8 月调用累计超过 2 万次。
但他们也写了一个诚实的数字：当自动修复比例到了 60% 以上，bug 日清率没有明显变化，从 53% 到最高 63%。原因在于整件事的触发仍然依赖人或其他确定性流程。这一句比前面所有漂亮数字都更值得记住——单节点已经能被 AI 打穿，全局推进还没有。
挑战一与挑战二：环境与验证，以及平台为什么不够用
五个挑战里的第一个是环境与验证驱动。把它当总纲是本文的归纳——后四个挑战都建立在它之上。
它的论证链条和上一篇一致：编码只占链路两三成；按阿姆达尔定律，非瓶颈环节被优化带不来数量级收益；AI 优先解决反馈公开、验证可规模化的领域，而企业内部环节缺少这样的反馈。结论是主动把内部研发工作流改造成有效反馈、可验证的环境。
具体包括五项建设：业务领域知识构建；可复现、可调用的研发环境，把「只有人会操作的内部系统」翻译成「AI 可调用的工具」，让 Agent 能独立构建项目、启动服务、准备数据、调用接口、看日志和调用链、读监控指标；分层验证体系，秒级反馈（编译、类型检查、单元测试）、分钟级反馈（集成测试、契约测试、浏览器自动化）、人工判断只留给机器判不了的部分；
端到端研发系统打通，把发布平台、实验平台、监控平台改造成 AI 友好的形态；Spec 的新写法，区分约束和假设，约束长期保存并尽量自动检查，假设允许 AI 按运行反馈调整。
第二个挑战更贴近现实：平台能力升级。
大中型企业都有一套统一研发基础设施，手册举的例子是阿里的 Aone。统一平台的价值很实在——研发范式能标准化、可规模化，几百人到几万人的组织都能保持效率，资产管理、度量、可信供应链这类横切能力可以集中解决。
问题出在 Agent 想用这套平台的时候。人通过 Web UI 操作，靠经验知道该登录哪个系统、点哪个入口、跳转之后下一步在哪；Agent 没有这个能力。手册列了三个具体障碍。
一是 Agent 很难稳定进入研发系统。不同系统有不同的认证方式和权限模型，系统之间大量跳转，很多操作依赖浏览器 Session、页面状态和工程师长期积累的使用经验。如果让 Agent 通过 Web UI 模拟人操作，每次页面改版、状态变化甚至登录流程调整都可能让任务中断。
即使把能力包装成 OpenAPI 或 MCP，认证、授权、环境选择、资源定位仍然要解决。手册的结论是：对 Agent 来说，首先需要的不是更多 API，而是统一稳定的系统访问方式。
二是 Agent 很难获得完整而确定的研发上下文。很多关键事实在人看来是隐式的：当前代码仓库对应哪个应用、当前目录属于哪个项目、工作项挂在哪个项目空间、应用关联哪个代码模块、默认 trunk 是什么、创建 CR 用哪个 codeModuleId。
人靠页面、目录、命名、经验和组织关系把这些补齐，Agent 一旦把某个关键事实推断错，后续所有操作都会在错误上下文里继续，而且往往很晚才被发现。手册对 MCP 的评价切中要害：MCP 解决了「模型如何调用工具」，并不天然解决「模型是否知道自己应该操作哪个对象」；没有统一的资源模型和可靠的上下文解析机制，工具越多，Agent 面临的选择空间反而越大。
三是现有工具能提供信息，却不一定能推进任务。很多研发工具本质是面向人的信息展示工具：它能告诉你流水线失败了，返回 stage、job、task 和日志地址，但不会告诉你失败在哪一层、该看哪段日志、下一步能做什么。人可以自己接手这些判断，Agent 不行。所以面向 Agent 的工具不应只返回「现在发生了什么」，还要给出「这个状态意味着什么」和「下一步可以做什么」，工具设计的单位要从单个 API 演进为完整的任务操作能力。
手册提到他们为此建了一个内部 CLI，目标不是把网页能力或 OpenAPI 搬进终端，而是给 Agent 一层能稳定进入、稳定理解、稳定推进任务的研发操作面，目前每天被数万工程的 Agent 使用。
挑战三到挑战五：度量、数字员工与组织
后三个挑战超出了技术工具范畴，手册仍然把它们当工程问题处理。
度量（挑战三）。手册点名了最常见的两个指标：有多少人用了 AI、AI 写了多少代码。它同时写明这两个数当然要看，问题出在只围着它们转。反对理由是一条完整的链：AI 写了代码不等于代码进了提交；进了提交不等于变更成功发布；发布了不等于需求价值交付；交付了还要看缺陷、返工、回滚、恢复和业务收益。工具视角的指标各有硬伤——安装率会把装了但没产生有效研发行为的人算进去，Session 会把临时问答当成生产力，AI 代码占比会反过来激励无效生成。再往个人排名上走，团队就开始优化指标本身。
他们的做法是先建一条采集链路：适配 40 多个主流 AI 工具，用户侧只做轻量 Hook 记录，解析、去重、归因和上报交给后台；再把事件统一成研发事实，沿 Session、Commit、Change、Workitem 做归因，这条链断掉指标就失真。
最后落到三层指标：L1 AI 效能层（覆盖率、Session、Token、AI 行、Skill、MCP、上下文资产），作用是牵引团队用起来并定位工具与上下文问题；L2 工程质量层（AI 缺陷率、回滚返工、自修复缺陷、风险事件），作用是约束 L1 的增长不能以质量恶化为代价；
L3 价值交付层（需求交付周期、变更周期、发布频率、AI 与非 AI 交付对比），作用是验证业务是否真的更快更稳。
三层不能拆开看：只看 L1 会变成「为了 AI 而 AI」，只看 L2 会变成质量审计，只看 L3 只能看到结果、解释不了变化来自哪里。
手册还单独拎出一类容易被低估的指标：上下文资产。他们把 Skill（方法）、MCP（接口）、SPEC（约束）、README 和 runbook（入口与排障）、模板和 checklist（评审发布回滚）五类资产放进度量体系，理由是决定 Agent 能否稳定工作的，不是单次 prompt 写得好不好，而是组织有没有把高质量上下文沉淀成可复用资产。这句话的推论很直接：可规模化的组织不是让每个人都更会提问。
数字员工（挑战四）。叙事从 Copilot 走到 Agentic Workforce，变化的关键不是 AI 能做更多任务，而是 Agent 开始成为企业系统里的独立行动主体。
手册列了四个外部信号：Microsoft Entra Agent ID 把 Agent 当企业目录里的新型身份管理；OpenAI Agents SDK 把 HITL、handoff、guardrail、tracing 下沉到运行时；MCP 授权规范纳入 OAuth 2.1 和授权服务器发现机制；OWASP 整理 Agentic AI 威胁模型。
平台要回答的问题因此变了：过去是「这个人有没有权限」，现在是「哪个 Agent、在什么运行时、代表哪个用户、基于哪个任务、访问哪个资源、做什么动作、是否需要人批准」。手册把人与 Agent 的协同分成三个阶段，每个阶段都在外移信任边界：本地辅助（信任边界在人＋本地工具）、云端自主（信任边界扩展到人＋云端运行时＋仓库/任务系统）、多 Agent Team（扩展到 Agent 身份、工具链、任务状态和跨系统授权），每一阶段平台要补的能力都不同。
手册对「把 Agent 当实习生」这个流行比喻的评价是：只能用一半。它提醒我们 Agent 需要导师、职责、权限边界、Review 和成长路径；但 Agent 不是人，它没有职业伦理、组织归属感和隐含常识，行为来自模型、上下文、工具、指令和运行时状态，所以治理不能只靠「像人一样管理」，还要靠机器可执行的护栏。
权限设计上，他们指出了最硬的一处：主体模型变了。传统权限体系围绕人、应用、服务账号三类主体设计，Agent 同时踩中三类——像人一样理解任务，像应用一样持续运行，像服务账号一样调用接口。复用人的账号，审计上分不清人还是 Agent 在操作；复用服务账号，组织上分不清谁负责谁授权；只当应用，又表达不出「代表某个人完成某个任务」的委托语义。
手册给了两条路线：一条是把 Agent 做成组织里的虚拟员工，有工号、有导师、有职责和权限边界，可以加入团队和项目空间；另一条是为 Agent 定义原生身份与授权体系，用复合身份令牌和请求证明访问资源，需要目标系统凭证时通过 Credential Broker 兑换短期凭证，高风险场景走渐进式授权。
落地路径是三步：先让 Agent 可见可管理，再让它可控可复用，最后才谈更高自主性。
组织（挑战五）。手册先摆出几个老结论的前提：康威定律说组织结构等于系统结构，因为团队内沟通成本低于跨团队；Brooks 说加人无法加速延期项目，因为沟通成本随人数指数增长；Taylor 拆分专业岗位，因为人的注意力稀缺；manager 评价制和强制分布存在，因为员工产出不可观测。这些设计的共同前提都是「以人为约束」。
AI 进来之后，这个前提开始失效。手册列了一组镜像特征：人有沟通衰减，AI 没有；人需要激励，AI 不需要；人会疲劳有情绪，AI 不会；人有上下文切换成本，AI 极小；人的记忆和注意力有限，AI 几乎无限。于是组织设计的核心问题从 ownership（谁拥有这件事）转向 routing 和 governance（任务如何流转、能力如何组合、风险如何被控制）。
手册里最有价值的一段是对人的双重角色的观察：人既是瓶颈也是兜底。会议太多、沟通成本高、信息传递失真，这些被抱怨了几十年的问题都指向人；但一份不完整的需求、一段没注释的代码、一个不一致的接口约定、一句口头传达的潜规则，之所以系统还能正常运转，是因为人用灵活性、推理能力和沟通能力把缺口悄悄补上了。
「开个会问一下、走过去问老王、凭经验猜一下、跑去预发环境试一下」，这些动作自然到不被看作工作，但它们是人扛在肩上的隐性成本。Agent 接管越多，失败信号越丰富，优化越快，这会形成一个开始之后只会加速的飞轮。
组织建议给了五条：专业岗合并，不再严格区分产品、设计、前后端甚至语言栈；快速组织 3~5 人小团队，有清晰负责人，冲向具体问题，可以以项目形式组织而不必反复 re-org；管理者定位转变，激励、辅导、招聘、退出、文化建设仍必须由人完成，另外新增了意图教练、身份重建、虚无对抗三类以前不需要做的工作；激励方式变化，一年一两次的考核跟不上行业节奏；分而治之，新业务要速度，老业务要稳定，管理变革程度要区分。
但手册没有回避代价，写了三件事。第一是培养断裂：旧路径是从 day1 写简单代码到几年后写复杂代码再到设计系统，新路径里 day1 已经由 AI 在写代码，入门岗位本身面临挑战；每家公司不招 day1 是局部最优，全行业都不招，三五年后 senior 池开始枯竭。
第二是蒸馏焦虑：员工每写一份 SOP、教 AI 一个流程，都是在把知识导出到组织资产，感觉是合作，结构上接近替代；一旦员工意识到「我说得越多，被替代得越快」，关键知识就会藏匿，而 Harness 工作恰恰需要员工说出哪些隐性约定要被结构化，员工不说，转型基本失败。
第三是行业级负反馈环：当有公司开始用 AI 替代而不是放大人时，竞争压力会让其他公司跟着收缩，senior 池被慢慢消耗，架构储备越来越薄，整个行业在 death of expertise 的方向上互相加速。
基础设施主干：Harness、知识库、工具体系
第三部分是全书技术密度最高的一章。它的起点是一个判断：软件交付效率远不等于 AI 生产代码的速度，在阿里内部，编码只占研发生命周期约 20%~30%，代码写完之后的持续集成、测试、发布、运维都需要提效，否则就是一堆 AI 写完的代码堵在流水线上。
手册把基础设施要解决的问题归纳成五条：让 Agent 持续完成长任务；把企业知识和操作能力变成 Agent 可用的上下文；提供可执行、可复现的软件运行环境；把权限和生产安全变成系统硬约束；让 Agent 的行为可解释、可评测、可持续改进。围绕这五条，架构以 Agent Harness 框架为核心，往三个方向铺开：外围的 Tool、Skill、MCP 扩展；沙箱与软件环境；安全建设。
Agent Harness 是这套架构的组织者。它的定位可以用一个例子说清：让 Agent 修复一个构建失败，它要先读错误日志、找到相关模块、结合项目规则判断改哪里，改完跑构建和测试，出现新错误就继续分析；如果修复涉及升级依赖、改公共接口或执行高风险命令，还要停下来交给人。模型负责理解和生成，真正把任务组织起来的框架负责四件事。
一是上下文管理。研发任务需要的上下文远不止一句话，代码、构建日志、项目文档、架构约束、编码规范和过去的执行结果都会影响判断。框架要决定何时加载什么，并在任务变长时检索、裁剪或压缩。手册的判断是上下文不是越多越好：无关内容会分散注意力，长期驻留的旧规则可能与当前代码冲突。他们的做法是项目规则稳定加载、实现文件按需读取、大段工具输出落盘只留摘要。
二是规划、状态与恢复。框架要记录当前目标、已完成步骤、尚未验证的假设和下一步计划，让会话中断、模型切换或环境重启后能接上。规划不是任务开始时写一份永不变化的长计划，而是维护一个能随反馈调整的任务状态。手册特意点出状态的两重价值：不只是让 Agent 记住，也让人知道任务进行到了哪。
三是工具、验证与纠错。工具设计要明确输入、输出和副作用，尤其要区分只读操作、可逆修改和影响外部系统的写操作。验证是研发 Agent 与普通内容生成应用最重要的区别：一次修改是否满足完成条件，不应只由模型自己判断，而应尽量由编译、测试、静态检查和运行结果提供证据。构建失败不是终点，而是下一轮行动的输入。任务完成时应该返回代码变更、执行过的验证命令、验证结果和仍未消除的风险，而不只是「已经修复」。
四是人机协同。需求含义不清、多方案存在业务取舍、操作会影响外部系统、多次尝试仍无法通过验证时，人进入循环。手册引用了 Anthropic 2026 年对约 40 万次 Claude Code 交互式会话的隐私保护分析：用户平均承担约 70% 的规划决策，Agent 承担约 80% 的执行决策。这是单一产品样本，但它反映的分工很清楚——人负责目标、边界和关键取舍，Agent 负责在约束内执行。
手册还强调了两件事。一是企业定制的重点不是重写一个 Agent，而是围绕它建外层 Harness：用 Rules、AGENTS.md 提供指引，用 CLI、脚本、MCP 工具提供行动能力，用构建、测试、Lint、Review Agent 提供检查反馈。其中必须严格执行的安全和质量门禁应由程序控制，不能只靠提示模型「记得遵守」。
二是这些能力要版本化管理：规则会过期，工具接口会变化，Skill 和 Plugin 可能引入新权限或依赖，企业需要知道一项能力来自哪里、适用于哪个版本、能访问什么、出问题怎么回退。
企业知识库 解决的是事实供给。手册给了四个作用：提供领域世界模型；把知识从模型参数中外置，让它可更新、可纠正、可撤回、可分级授权；为行动提供依据与约束——工具决定 Agent 能做什么，知识库决定它在什么条件下应当做、依据什么做、何时停止或升级给人；形成可共享、可审计的组织记忆。
落地是一条四段链路：知识整理（建立统一知识规范，每条关键知识说明它是什么、适用于什么范围、来自何处、由谁负责、何时更新）、知识加工（解析、索引、切片、关系构建）、知识治理（管版本、责任、权限和安全边界，并把使用反馈回流）、知识供给（RAG 召回、API 或结构化查询、本地文件检索、实时查询并存）。
手册在这里提到一个公开规范值得记一下：Google 提出的 Open Knowledge Format，用 Markdown 承载内容、YAML frontmatter 描述类型和元数据，价值不在文件格式，而在于人和 Agent 能用一致的方式理解知识的结构、类型和来源。
工具体系 的分工很清楚：MCP 和 CLI 是执行接口，Skill 是任务方法。
手册对 CLI 有一个容易被忽略的观察：Agent 特别擅长调用 CLI，输入参数明确、标准输出可被后续步骤消费、退出状态可判断成败，甚至能从输出里学会参数怎么组装；但 Agent 没有主动发现 CLI 的机制，所以 CLI 往往需要配套 Skill 告诉它什么时候该调用。
手册还点出 MCP 和企业 CLI 体系的关键差异在授权：MCP 已经有基于 OAuth 2.1 的授权流程，CLI 目前没有统一标准，所以企业 CLI 除了业务逻辑，还必须解决谁在调用、可调用什么、凭证怎么获取和更新、操作怎么审计。
工具本身也要评测，两个基础指标是命中率和成功率：命中率看 Agent 面对任务时有没有触发或选对能力，成功率看能力被选对之后有没有以正确的参数、顺序和权限完成任务。评测结果用来反向调整能力设计——拆分过大的 MCP 服务、改工具名称和描述、补 Skill 的步骤与边界、删掉长期低命中低成功的能力。
运行环境与安全：四个模块的边界
这一层回答的是「Agent 真正动手时，边界画在哪」。
Sandbox。传统研发环境默认操作者是可信的人：开发者知道哪些命令危险，遇到异常会停下来，也能识别网页里的恶意指令。Agent 不具备这些前提，它可能误删文件、启动失控进程，也可能把网页、代码注释或依赖包里的内容当指令执行。
所以把 Agent 放进容器只解决了「在哪里运行」，一个能用于生产的 Sandbox 还要回答六个问题：每次任务的镜像、CPU 内存和销毁时机；能执行哪些命令、读写哪些文件、过程怎么实时返回；能访问哪些外部地址；调用仓库和模型服务时怎么避免把真实凭据交给它；任务中断后能不能暂停、恢复或从快照重建；出错时能不能还原过程。
手册把 Sandbox 拆成四个边界。
生命周期控制面负责校验镜像、入口命令、资源上限、网络策略和超时，状态语义要包含 Running、Pausing、Paused、Resuming、Terminated、Failed，而不是只有「容器存在或不存在」；TTL 由服务端负责到期回收，避免 Agent 失去管理者后留下孤儿实例，长任务可以显式续期，需要保留现场就用暂停或快照。
实例内执行面需要一个轻量执行服务，提供命令执行、文件操作、持久会话、交互式终端和资源指标，用结构化协议返回退出码、日志和执行状态，让 Agent 不用猜。网络与访问边界默认应该拒绝出站，再按任务放行代码仓库、依赖源和必要 API，入站也要鉴权，凭据在网关处校验并剥离。
凭据边界的做法是让 Sandbox 只看到占位值，真实凭据留在可信的侧车或代理里，等出站请求匹配域名、路径和方法时再注入认证头；凭据状态不应进入快照，恢复后由可信控制面重新注入。
手册举的实现是阿里捐献给 Agentic AI Foundation 的 OpenSandbox，它把公开协议、生命周期控制面、运行时和沙箱数据面分开，为 Coding Agent、GUI Agent、代码执行和评测提供统一隔离环境。
Coding 环境。这一节的出发点很朴素：仓库只是可运行项目的一部分。一个干净的工作空间不知道应该用哪个版本的运行时和构建工具、有没有关联仓库、私有依赖从哪来、启动需要哪些配置、数据库结构和基础数据怎么准备、哪些外部请求要走真实上游、哪些需要测试替身、依赖还在初始化还是应用已经启动失败、失败后该先看什么。
手册用一个虚构的电商服务说明后果。任务是「订单创建十分钟内且尚未发货时，用户可以自行取消」。Agent 改完代码、补了单元测试，测试通过；启动服务跑接口测试时连续遇到三个问题：缺少订单取消窗口的配置项，人工临时补了一个值；数据库表结构里没有发货时间字段，人工手工执行迁移脚本；释放库存的请求被网络策略拒绝，人工在本机起了 Mock Server。开发者可以逐项修好，但修复只留在当前机器，下一个 Agent 进到新实例，还会重复这三次失败。
有运行上下文时链条会不一样。项目维护一份可执行的环境定义，记录运行时、仓库、初始化步骤、资源和网络边界，以及与当前代码版本匹配的数据基线；Agent 从定义和基线创建独立实例；测试中发现的新外部请求由环境记录目标、路径和处理结果，Agent 据此判断用服务桩还是走授权流程；明确的拒绝记录比长时间超时更有用，因为它直接指出缺了哪项环境处理。
测试通过后的配置、数据库变化和服务桩规则只是候选状态，要经过测试或人工确认才能进入新基线。想确认结果是否依赖临时现场，可以销毁实例、从相同定义和候选基线重建，再跑同一组验证，第二个实例结果一致才算留下了可复现的路径。
这一节的四条设计原则可以当成评审清单：环境定义长期维护、实例随任务创建；依赖通过稳定接口接入；状态边界放在任务上（同一任务内保留现场，任务结束回收，通过验证的才成为候选基线）；环境反馈也是接口（原始退出码、输出、实例与依赖的生命周期状态、配置和数据库查询结果、外部请求的拦截放行记录、验证报告和构建产物）。
Identity & Policy。当 Agent 只能生成文本时，错误停留在答案层；当它能检索代码、查数据、调工具、执行命令、改外部系统时，错误会变成真实操作。系统因此必须回答五个问题：请求来自哪个 Agent、哪个运行实例；它是否代表某个用户行动、委托范围是什么；它可对哪些资源做哪些动作；缺少权限时谁能确认或审批；权限撤销后多久能在所有执行点真正失效。
传统应用权限模型不够用，是因为调用路径不再是设计时确定的：选哪个工具、按什么顺序、访问哪个资源、是否继续，都可能到运行时才定。一次调用可能同时涉及发起任务的用户、稳定的 Agent、实际运行的沙箱、工具服务和被改变状态的资源服务，只记一个用户 ID 或共享应用账号，没法回答「哪个程序、以哪个 Agent 的名义、基于谁的委托执行了操作」。
手册区分了四个不能合并的对象：身份认证证明谁在请求，委托说明 Agent 为什么可以代表用户，策略授权决定当前条件下允许什么，凭证让下游能验证这次访问已获准。它们不能合并成一张万能 Token。工程上有四个角色：可信 Runtime 持有身份并发起请求；PDP 做允不允许的最终判断；PEP 分布在调用链各处落实决策；Credential Broker 代管长期凭证、按需兑换短期凭证。
五条原则值得抄进方案评审：建立可验证的复合身份，区分稳定 Agent、运行实例和任务上下文三层主体；权限只能逐级收敛，有效权限等于用户权限、Agent 能力上限、平台策略、本次委托范围和运行时约束的交集，多 Agent 协作时每一跳都要建立自己的调用者身份，子委托范围只能比上游更小；
由确定性系统决策并在靠近资源的地方执行，模型可以提出工具和参数，但允不允许必须由 PDP 判断，越靠近资源的执行点越不能省略鉴权，MCP 解决了协议互通但不自动解决授权；长期凭证不进入 Agent，优先级是代理调用优于注入短期凭证、优于注入长期凭证；
权限必须可撤销、可追溯，短期 Token 只缩短风险窗口，不能替代撤销机制，审计要把用户意图、委托、工具、资源、策略决策、凭证兑换和最终结果串成一条链。
授权结果也不该只有允许和拒绝两种。手册提出第三种：需要补充授权。它不是一段让模型去猜的 403 报错文本，而是资源服务返回的结构化授权要求，说明需要谁确认、以什么方式、有效期多久；可信 Runtime 在独立界面展示「哪个 Agent 想对哪个资源做什么」，确认后自动重试，模型只收到「等待确认」或「审批拒绝」这类高层状态，接触不到授权码和 Token。
Guardrail。生产发布的原则没变——可观测、可灰度、可回滚；变的是保障方式。Agent 一次任务可以连续组合多项生产操作，速度和密度超出人工流程的设计尺度：绕开人工环节会让原有安全约束失效，每个关键节点都回到人工检查又会损失效率。手册的方案是把人的经验转成 Agent 可读的规则、可复核的证据，以及执行前必须满足的协议，目前已经用在阿里内部代码发布和配置发布的批次恢复链路上。
为什么需要它，手册给了一个很具体的解释。人主导流程时，工程师带着完整上下文走完操作，靠记忆知道为什么要改、要检查什么、已经检查过什么；Agent 参与后，任务可能跨会话接续、在多个工具之间切换，原来跟随操作者自然流转的上下文很容易断开。生产状态又一直在变，同一个动作此刻具备条件，过一段时间未必适合执行。所以要把当前事实、观测证据和目标动作绑定起来：任何关键状态发生变化，原有结论都应失效并重新检查。
一次批次恢复的完整链路有六步：发布系统创建或复用一次 Guardrail 运行，提交不可变的动作上下文；Guardrail 选定固定版本的检查规则，把运行信息和规范投递给 Agent；Agent 按规范自主选择工具查日志、监控、告警和诊断信息，为每个检查项搜集证据并提交结果；
Guardrail 验收提交是否覆盖必检项、是否符合协议，按各项结果机械聚合出最终门控结果，它不解释证据的业务含义；发布系统在执行前主动查询门控结果，同时重新校验最新发布状态、用户权限、目标、请求摘要和动作防重；只有门控和发布系统自身校验都满足，才执行真实动作。
这套机制里最值得记住的是三态协议。每个检查项只能落到三种结果之一：PASS 表示证据充分、满足通过条件；BLOCKED 表示发现明确的阻断事实；UNKNOWN 表示查询失败、证据不足或事实无法解释。必检项缺失，或者存在 BLOCKED 和 UNKNOWN，都不能形成可放行结果；只有所有必选检查都提交 PASS，最终门控才可能为 PASS。
Agent 发现规则无法同时满足、证据覆盖不全或事实解释不了时，必须提交 UNKNOWN，不能自己选一个更宽松的解释；而 Guardrail 的职责就是保证 UNKNOWN 不会被当作 PASS。
规则和上下文也做了版本化：检查规则是版本化的配置文件，发布后生成不可变的 revision 和 digest，运行中的实例始终绑定当时选中的版本，后续规则更新不会改变历史判断依据；动作上下文是不可变快照，进入运行后不能被覆盖，目标或上下文一变就必须新建一次运行。手册还强调证据只保存脱敏摘要和受原系统权限保护的引用，不复制访问凭证、完整日志和大段业务数据。
可观测：从系统指标到轨迹
Agent 的执行路径从提前编排变成运行时动态生成，同一个任务在不同上下文、模型状态和环境反馈下可能形成完全不同的轨迹。传统可观测仍然观测延迟、吞吐、错误率和资源利用率，但它主要回答「系统运行是否正常」，回答不了「Agent 为什么这样行动、是否完成任务、行为是否符合预期」。
手册列了三类场景：性能与成本分析，多步规划和多智能体协同带来成本归因困难、上下文膨胀、无效重试和长尾性能问题；行为与效果分析，模型推理本身是非确定性的，即使没有显式错误，行为也可能偏离设计意图，需要结合评测判断任务是否完成、行为是否合理；安全与合规，审计对象从数据和访问延伸到行为和执行链，埋点要覆盖全链路并细化到内容级。
能力上分两层。System Observability 观测 Agent 运行时系统的健康、性能、资源与成本，对象模型与 OpenTelemetry 一致，指标包括请求速率、首 Token 时延、每 Token 时延、端到端时延、Token 吞吐、GPU 利用率、工具时延、错误率、成本和缓存命中率。
Behavior Observability 观测 Agent 如何行动，核心对象是 Trajectory——一次任务从输入意图出发，经历规划、推理、模型调用、工具调用、Skill 执行、多 Agent 协作等动态行为，最终形成结果的完整执行记录；
Trajectory 和 Trace 通过统一的 Trace Context 关联起来，系统执行和行为语义才连成一条。
Trajectory 的对象模型在手册图里编号排到十，但实际命名并定义了九类：Session、Task、Trajectory、Step、Model Call、Tool Call、Skill Execution、State Change、Outcome（编号 9 空缺）。这套模型的用处有三处：定位失败可以精确到某一步的某次工具调用；成本可以归因到具体任务和模型调用；轨迹本身可以作为评测数据。
架构上有四个做法。全链路采集基于 OpenTelemetry 的 GenAI 语义约定，把 Sandbox、Skill、CLI 这些外围执行环境用统一的上下文传播纳入同一条链路，跨 Agent 则用统一的轨迹协议交换，手册提到 ATIF（Agent Trajectory Interchange Format）在评测和训练场景已经成为重要格式。
行为分析用级联漏斗控制成本：先用确定性规则全量筛查，再由模型筛出灰区样本，最后只对灰区做意图达成度、推理合理性、工具调用恰当性和检索相关性的分析。可观测与评测共享数据：Trajectory 经用户反馈关联、评估筛选和标注后进入评测系统，变成优化 Agent 的数据资产。
Skill Runtime 自动化观测：把观测契约封装在 Skill 的执行环境或 SDK 里，让 Skill 自动产生遥测并继承上游 Agent 的上下文，业务开发者不需要重复埋点。
最值得记住的四个细节，和手册没回答的问题
把这份手册读完，真正能直接搬走的是四个设计细节，而不是那些数字。
第一个是 Guardrail 的三态协议：把「不知道」写进协议。大多数自动化系统的门禁只有通过和不通过，信息不足时要么卡死要么放行；手册明确要求 UNKNOWN 不能被当作 PASS，并把「规则无法同时满足」「证据覆盖不全」「事实解释不了」都归到 UNKNOWN。这一条可以直接用在自己的发布门禁上。
第二个是授权三态里的 Challenge：缺少权限时返回的不是报错，而是结构化的授权请求，说明需要谁确认、以什么方式、有效期多久，确认后自动重试。它把「卡住」变成了一个可恢复的状态。
第三个是环境定义与任务实例分离：定义长期维护，实例随任务创建，通过验证的配置和数据才成为候选基线。这条原则解决的是「修复只留在当前机器」这个几乎所有团队都会遇到的问题，而且不依赖任何 Agent 技术就能用。
第四个是把 Trajectory 作为跨系统、跨 Agent 的行为记录，并与评测共享。它把「失败能不能解释、成本能不能归因、效果能不能改进」变成同一份数据。
手册自己也写了三个没答案的问题。最后一公里：构建、集成测试、灰度发布、生产验证、故障恢复涉及真实环境、真实数据和真实用户，容错空间极小，对沙箱隔离、凭证管理、门禁机制和可观测能力的要求远超当前水平，基础设施本身的工程复杂度可能不亚于 Agent 应用层。
知识还没做到 Agent 友好：大量组织知识散落在文档、口头传递、个人经验和内部系统里，即便整理进知识库，也往往停留在「人能查到」的阶段，距离被 Agent 高效检索、准确理解和可靠引用还有很大差距。组织设计更难：岗位合并、超级个体、小团队协作这些方向都还没有成熟路线，而蒸馏焦虑是真实的——当贡献知识可能加速自身被替代时，转型需要的知识沉淀就会遇到阻力。
还有一个态度值得单独拎出来。手册说，过去两年主流模型几乎每隔数月就有一次能力跃升，新的模型族、推理范式和交互协议不断涌现，今天设计的技术架构、工具体系和工作流程很可能半年后就需要重新审视。它的建议是接受这种不确定性、保持架构的适应弹性，但不要因为「等更好的模型」而推迟必要的基础设施建设。
（本文解读的《AI Native 研发范式实践手册》由阿里团队编写，主编许晓斌，2026 年，署名作者 19 人（含主编）。文中案例数据均为其内部统计，不代表行业基准。同系列上一篇讲的是手册的核心判断：编码被解决之后，瓶颈在哪里。）
系列导航
- 系列：AI 原生研发范式（第 02 篇，共 2 篇）
- 上一篇：阿里 68 页手册：编码 1 小时，上线 3 周
- 公开系列页尚未创建；如需回看上一篇，可在站内按「体系」分类检索。
参考资料
- 《AI Native 研发范式实践手册》，阿里团队编写，主编许晓斌，2026 年，共 68 页、署名作者 19 人（含主编）。本文基于该 PDF 的逐页 OCR 文本整理，手册未提供公开链接。
信息边界
本文采用 source-only 模式，只基于该手册整理。手册自述不是成熟方法论，其中案例数据均为其内部统计，不代表行业基准；文中标注为「趋势判断」「本文归纳」的部分是观点或转译，不是已验证结论。