本节是本站对 阿里巴巴《AI Native 研发范式实践手册》 的对照补充，由杨正武撰写。原 Playbook 的卷一解释规约和验证，卷二处理并行执行，卷三讨论团队治理。阿里手册把这些原则推进到企业研发系统：Agent 能否独立准备环境、拿到受限权限、完成生产前检查，并留下可复核的证据。
先把运行条件交给 Agent
仓库和任务说明不足以组成一个可运行项目。工具链版本、私有依赖、关联仓库、配置、数据库结构、测试数据、上游服务和网络策略，常常只存在于工程师的电脑或经验里。阿里手册在 Coding 环境一节提出，把这些条件做成可执行、可维护的项目运行上下文。环境定义长期保存，任务实例按需创建；一次任务发现的新配置或服务桩，经过验证后才能进入基线。
这和跨会话持久化相接，但持久化对象还要扩展到环境。一次修改的交付记录至少应包含：
| 对象 | 应记录的内容 | 验证方式 |
|---|---|---|
| 代码版本 | 仓库提交、关联仓库版本 | 从指定版本重新检出 |
| 环境定义 | 镜像、工具链、依赖、资源和网络规则 | 在新实例重建 |
| 数据基线 | Schema、测试数据、服务桩 | 从基线运行同一组测试 |
| 执行证据 | 命令、退出码、日志、服务状态 | 复跑并比较关键结果 |
如果只能在原会话里通过，换一个干净实例就失败，验证链路还没有闭合。这是对验证前置的进一步要求。
每个任务有自己的执行边界
多 Agent 并行需要隔离的范围超过 Git 分支。手册的 Sandbox 一节把文件系统、进程、资源、网络、凭据和生命周期一起纳入任务边界。任务开始时声明镜像、资源上限、出站地址和存活时间；执行中返回结构化退出码与日志；任务结束提取补丁和报告，随后回收实例。长任务需要暂停、续期或快照，异常退出也要保留足够的现场。
这补足了并行隔离在企业运行时的细节。工作区隔离解决并发修改，沙箱隔离进一步限制不可信代码和依赖的影响。真实密钥应留在可信代理侧，由代理在匹配目标域名、路径和方法时注入；环境快照不应带走凭据。
权限要随任务逐级收敛
Agent 执行一次操作，系统需要区分发起任务的用户、稳定的 Agent 身份、当前运行实例和本次委托。用户能访问某个资源，不代表 Agent 自动获得相同权限。有效权限应取用户权限、Agent 能力上限、平台策略、本次委托和运行约束的交集。子 Agent 接手时，权限范围只能继续收窄。
模型可以提出工具调用，授权决定必须由独立的策略系统完成，并在实际资源侧再次校验。缺少授权时返回结构化的待确认状态，让可信界面展示资源、动作和有效期。任务结束或委托撤销后，停止签发凭证，清理缓存并终止仍在运行的会话。用机制替代人际协调若要进入真实企业系统，这些执行点就必须成为协作协议的一部分。
生产检查绑定当前现场
阿里手册给出配置发布批次恢复的 Guardrail 实践。规则版本和本次动作快照先固定下来；Agent 查询日志、监控与告警，为每项检查提交证据和 PASS、BLOCKED、UNKNOWN 三态结果。必检项缺失，或任何一项为 BLOCKED、UNKNOWN，都不能自动放行。发布系统在真正执行前还要重查目标、权限、发布状态和动作防重。
这比一次性“测试通过”多了时间与范围约束。证据只覆盖被观察的目标和时刻；目标、批次或规则变化后，旧结论失效。人负责定义规则和处理无法可靠判断的情况，Agent 负责收集事实，门控系统执行确定性聚合，发布系统负责最终动作。
落地时可以从一个动作开始，例如预发部署后的自动回归或灰度批次继续。先固定动作上下文和检查清单，再接入 Agent 搜证，最后让执行系统校验门控结果。不要把模型的一句“看起来安全”当成生产授权。