alibaba-aone-agentic-rd-mode-xiangbangyu¶

Ch04.045 alibaba-aone-agentic-rd-mode-xiangbangyu¶

📊 Level ⭐⭐ | 24.0KB | entities/alibaba-aone-agentic-rd-mode-xiangbangyu.md

一、在 Agent 时代，传统的"协作"和"分工"是效率的阻碍¶

2025 年，AI 编程助手已进化为"AI 软件工程师"，但"Vibe Coding"生产力悖论正在浮现：Agent 生成代码的速度呈指数级增长，组织的整体研发效率却提升有限。问题不在于 AI 的能力，而在于我们仍用工业时代的协作模式来组织 AI 时代的研发。

传统的协作和分工旨在提升效率，但在 Agent 时代，这种传统分工反而成为了效率的阻碍。前端与后端、产品与开发、开发与测试的分离，在人力时代支持了专业化与规模化，而在 AI 时代则意味着上下文中断、信息损耗和协作摩擦。

"约束不再是代码生产的速度，而是软件组织的结构。"

1.1 传统协作模式的结构性低效¶

传统软件工程将研发流程划分为多个专业领域：前端开发、后端开发、数据库管理、DevOps、测试等。每个领域由专门的团队或人员负责，通过接口契约进行协作。这种模式在人力主导的时代有其合理性——人类需要专业化来积累深度知识。然而，对于AI Agent而言，这种分工构成了严重的效率障碍：

上下文碎片化：当AI需要完成一个端到端的功能时，它必须在多个团队、多个工具、多个代码库、多个文档系统之间来回切换，每次切换都意味着上下文的丢失和重建成本。
接口摩擦：前后端之间的API契约定义、联调、变更管理，在AI时代成为了不必要的摩擦点。AI完全有能力理解完整的数据流并自动生成一致的前后端代码。
知识孤岛：每个专业领域的知识被隔离在特定的团队或文档中，AI难以获得全局视角来做出最优的技术决策。

1.2 研发阶段带来的信息断层¶

在传统的软件开发生命周期中，需求分析（由产品经理/PD负责）与代码实现（由开发负责）是两个明确分离的阶段。这种分离基于一个假设：需求必须被人理解和转化为技术规格后，才能进入实现阶段。而在 Agent 时代，这个假设正在被打破：

自然语言即代码：AI可以直接理解自然语言描述的需求并生成实现，不再需要人工的"翻译"过程。
需求即测试：好的需求描述本身就包含了验收标准，这些标准可以直接转化为自动化测试用例，由AI自动验证实现是否符合预期。当 AI 可以直接从Spec开始生成可用代码时，传统的分工和协作模式就是效率的阻碍。

1.3 协作带来的沟通成本¶

传统协作模式的核心是"人与人的沟通"。无论是站会、需求评审、技术方案讨论还是代码审查，本质上都是人类之间的信息交换。这种协作方式的成本随着团队规模呈几何级数增长。在AI时代，这种协作模式暴露出了根本性的局限：

沟通带宽限制：人类处理信息的速度远远落后于AI生成信息的速度，导致AI的产出在等待人类反馈的过程中被闲置。
信息损耗：每一次人与人之间的信息传递都会引入噪声和失真，多次传递后原始意图可能面目全非。在采用AI编程助手的团队中，开发者报告的主要痛点不再是AI生成代码的速度和质量，而是"等待人类反馈"和"协调多人协作"，这说明协作本身已经成为了新的瓶颈。

二、在Agent时代，传统的"研发资源组织形式"也是效率的阻碍¶

2.1 代码和代码是分离的¶

当一个 Agent 需要实现一个端到端的功能时，它面临的第一个挑战不是"如何写代码"，而是"代码在哪里"。客户端代码在一个仓库，前端代码在另一个仓库，后端服务分散在多个微服务仓库，SDK 又有独立的版本管理。每个仓库都有自己的分支策略、CI 流程、代码规范。Agent 必须在这些仓库之间来回切换，每次切换都意味着上下文的丢失和重建。更关键的是，这些仓库之间的依赖关系往往没有显式声明，Agent 无法通过程序化的方式理解"修改这个 API 会影响哪些前端页面"。

2.2 代码和文档是分离的¶

信息的碎片化不仅存在于代码层面，更存在于研发基础设施的各个角落。需求文档可能在语雀上，API 说明书可能在 Swagger 里，技术方案的讨论记录在钉钉聊天记录中，代码注释散落在各个文件里，Bug 历史躺在 Issue 系统中。这些信息实体之间没有关联，没有统一的索引，没有机器可读的元数据。真正的面向 Agent 的研发范式，需要重构信息的组织方式：

代码仓库应该按产品或者能力而非按技术栈划分
文档应该是机器可读的结构化数据而非针对人去优化过的UI
知识应该集中存储而非分散在各个孤岛中
上下文应该能够被程序化地收集注入而非依赖人工整理只有当信息基础设施为 Agent 优化时，AI 的自主执行潜力才能真正释放。

2.3 文档的主要维护者还是人¶

传统研发文档的另一个根本性问题是：它们由人编写、由人维护。这意味着文档的更新总是滞后于代码的变更，文档的质量依赖于个人的责任心和写作能力，文档的一致性无法被自动验证。如果我们将文档视为一种特殊的"代码"，代码可以由 Agent 生成、修改、验证，文档同样可以。当 Agent 修改了一个 API 的实现，它可以同时更新 API 文档；当 Agent 重构了一段业务逻辑，它可以同步更新架构说明；当 Agent 修复了一个 Bug，它可以自动记录到变更日志中。文档不再是代码的附属品，而是与代码一起被版本控制、一起被审查、一起被自动化测试验证的公民。

三、Agent 在交付和稳定性链路中的缺席¶

传统发布流程是 Agent 能力被系统性限制的典型场景。从代码提交到生产部署，整个链路充满了为人类设计的审批节点、手工验证步骤和断点式协作。Agent 可以生成代码、运行测试，却无法直接触发构建；构建通过了测试，却无法自动部署到预发；预发验证通过了，却无法推进到生产。权限被分散在不同的系统和角色手中，每一个环节都需要人类介入。更深层的问题是发布流程中的信息不透明。CI 日志、测试报告、性能指标、灰度数据散落在不同系统中，没有统一接口供 Agent 程序化访问。当发布失败时，Agent 无法自动分析原因、自动回滚、自动重试，只能等待人类处理。真正的面向 Agent 的发布流程，应该让 Agent 成为参与者而非旁观者：自动触发构建、自动部署、自动监控、自动根据预设规则调整灰度或回滚。人类从流程执行者变成规则制定者和异常处理者。

四、让 Agent 更好工作的关键要素¶

4.1 All In Code 的信息管理方式¶

All-in-One版本化管理要求将所有研发资源纳入统一的版本控制系统： | 资源类型 | 传统存储位置 | 统一版本化管理 | |---------|------------|--------------| | 源代码 | Git仓库 | 统一Git仓库，代码即真相源 | | 需求文档 | Wiki/Confluence | Markdown文件，与代码同仓库 | | 测试用例 | 测试管理系统 | 代码化测试，版本化存储 | | API文档 | Swagger/Postman | OpenAPI规范文件，代码生成 | | 配置 | 配置中心 | 环境配置文件，版本化 | | Skills/工具 | 分散的脚本 | CLI化工具，版本化发布 | | 记忆/上下文 | 无系统化管理 | 结构化存储，可检索 |

4.2 隔绝外部依赖：版本化一切¶

外部文档版本化：将依赖的外部文档定期抓取并版本化存储，AI始终访问本地版本
需求库版本化：需求以版本化文件形式存在于代码仓库，而非外部系统
依赖锁定：所有外部依赖（包括AI模型版本）都被精确锁定，确保可复现性
Mock服务：外部服务调用通过Mock服务隔离，测试和开发不依赖外部可用性

4.3 自学习和自我迭代能力¶

反馈闭环：AI的每一次产出都会经过验证，验证结果被记录并用于优化AI的后续行为
模式学习：AI分析团队的代码库，学习编码规范、设计模式和架构偏好
效率分析：系统追踪每个任务的完成时间、迭代次数、缺陷率，识别流程瓶颈
知识沉淀：AI从每次交互中提取可复用的知识，丰富组织的集体记忆

4.4 平台需要建设让 Agent 能安全执行的能力¶

沙箱和环境：AI在隔离的沙箱环境中运行，无法访问敏感数据和生产系统
权限分级：Agent不同级别的操作需要不同级别的授权，危险操作需要额外确认
分批执行：大规模变更可以分批次执行，每批执行后验证效果，降低风险
审计日志：所有AI的操作都被详细记录，便于事后审查和问题追溯
Dry Run模式：AI的所有操作可以先在Dry Run模式下执行，展示将要做什么而不实际执行
仿真环境：准备模拟环境，让Agent能放心地操作数据而不会产生副作用

4.5 研发后的验证能力的建设¶

当前的研发验证基础设施——单元测试、集成测试、CI 流水线，在端到端（E2E）测试环节存在障碍。当需要验证"前端按钮点击后是否正确触发后端逻辑"时，现有的容器化测试基础设施无法搞定BUC的权限验证问题。解决思路是将验证部署在日常环境，在研发过程中尽量简化，避免依赖配置，轻装简行。 CI 流水线验证的是代码能否编译、测试能否通过，但无法验证业务语义是否正确、用户体验是否受损、性能是否退化。即使 Agent 生成的代码通过了所有自动化测试，它仍然无法自主确认"这个功能是否真正满足了需求"。

五、Aone 在面向 Agent 的研发模式升级上的探索¶

5.1 研发模式的变化¶

在传统研发模式下，大家习惯将 Coding、CI、CR 和 CD 等阶段割裂来看。而在新的产品和设计理念下，尝试将许多过程合并为一个连续的阶段——例如在 Coding 阶段就同步完成 Code Review，从而彻底摒弃中心化的 Code Review 系统，将 Code Review 从传统的"以人为主导"的模式转变为"以 Agent 为导向"的模式。需求不再按照前端和后端的分工来推动，而是按照端到端的业务场景来组织交付。一个需求从提出到上线，由一个或一组 Agent 协同完成全栈实现。研发协作的基本单元从"人与人之间的分工协同"演变为"人与 Agent、Agent 与 Agent 之间的任务委托与自治执行"。

5.2 ALL In Code 的版本管理¶

把面向一整个产品或者整个应用的内容都以大库的形式来保存：

前后端代码
Agents 需要的 Skills 和工具
文档和操作手册
发布信息 handbooks 哲学是：代码库就是唯一的事实来源，一切需求从代码开始，也在代码中结束，形成闭环。

5.3 Agent Teams¶

探索一种新的，使得人和异构的Agent能始终在一个上下文中讨论的模式：需求在哪里，讨论就在哪里，讨论在哪里，上下文就在哪里。可以把多个Agent组成一个Teams，可以at一个前端Agent写前端，在这个平面中使得人可以操作一个Agent军团。这需要建设一种能力，使得能任意的将长程的 Agent 组装在一起成为一个Teams，使得Teams中的各个Agent 能相互协作和通信。

5.4 长生命周期的 Claw 模式¶

将 Agent 视为公民，如同团队中的一名正式员工——不仅可以将任务主动交给他，也可以让他被动地承担一部分日常工作。他具备应用本身的记忆与开发运维资源，既能被动接受指令执行任务，也能以"管家"的身份主动巡检、发现问题并采取行动。 主动巡检与优化：

线上报警自动排查：接收报警信号 → 自动定位根因 → 生成排查报告 → 建议修复方案
资源利用率优化：持续监控资源水位 → 识别浪费与瓶颈 → 生成优化建议 代码健康度维护：
技术债务追踪：定期扫描代码库 → 识别技术债务 → 生成债务报告 → 建议处理优先级
死代码清理：识别未使用的代码 → 生成清理报告 → 自动删除
依赖升级建议：监控依赖版本 → 发现安全漏洞或新版本 → 生成升级建议与影响分析 文档与知识自动维护：
文档自动更新：代码变更后 → 自动更新相关文档（API 文档、注释等）
API 文档同步：接口变更后 → 自动更新 API 文档和调用示例
变更日志生成：根据提交记录 → 自动生成 Changelog

5.5 Agent 端到端的任务执行以及和人的协作关系¶

有些场景需要和人协同工作，比如需要人确认申请资源，需要人确认推进流程等，让人能看到进展，在需要的时候"点击确认"推进流程。

5.6 仿真验证环境建设¶

主动卸掉历史包袱：在前后端联调场景中，尝试放弃一些传统依赖，如前端打包流程、配置中心等，以降低环境搭建的复杂度
Sandbox 中原地构建与启动：在 Sandbox 容器中直接构建服务端、启动服务端、构建前端，实现原地运行
Agent 驱动的 E2E 测试：在容器中直接让 Agent 进行端到端测试——Agent 自主打开浏览器、加载页面、执行交互验证，完成全链路测试闭环
智能生成测试用例：根据本次需求描述、讨论上下文以及生成的代码 Diff 信息，自动生成所需的 E2E 测试或冒烟测试用例

5.7 针对 Agent 的身份权限的建设¶

Agentic IAM 是面向 AI Agent 的完整身份与访问管理体系。它与传统 IAM 的核心差异在于：主体从"人"变成了"自主执行的软件实体"，由此带来的不是局部改造，而是对 IAM 每一个链路域的重新设计。

5.8 代码的合并模式¶

在 Agent 成为主要代码生产者的研发模式下，采用短生命周期分支 + 合并队列 + 分级质量门禁的组合策略。每个 Agent 任务在独立分支上执行，完成后进入一个串行化的合并队列，先完成的先合并。合并前必须通过对应级别的质量门禁，合并过程中自动处理 rebase 和简单冲突，无法自动处理的冲突退出队列等待人工介入。

5.9 ChangeSet 的引入¶

将所有前端、后端代码都放在同一个代码库之后，每次变更和发布所涉及的范围并不相同——有时只是换个 Logo，有时则需要改动复杂的前后端逻辑。有的变更需要做完整的端到端测试，有的变更只涉及 UI 调整。 ChangeSet 是一个存在于git版本库中的，把每次变更的过程都记录下来的系统。区别于Spec 文档，可以给ChangeSet设置不同的生命周期。可以开发一个中心化的Agent 来持续维护这个ChangeSet。 ChangeSet 解决的场景：

某次变更发布很久之后，想回溯当时到底做了什么
并非每个需求、每次发布所需检查的内容都一样
本次发布需要关注什么，存在哪些风险
如果系统出了问题，应该回滚哪些 Commit

六、结语¶

就在 2023 年的这个时候，我们启动了 AoneCopilot 项目。那时，我们还在遥想软件研发的终局会是什么模样：一句话完成一个需求的时代，究竟是悬在天边的幻想，还是终将照进现实的微光。没想到，不过短短三年，那曾经遥不可及的未来，竟已近在咫尺。 作者介绍：向邦宇，在阿里工作超过10年，负责了阿里巴巴代码平台，在阿里内部建设了多个 AI Coding 工具，这些产品在阿里内部被广泛使用，同时也面向业界主导开发了一站式的，小白用户也能用 AI Development产品"搭叩"。

深度分析¶

本文提出了一个极具洞察力的核心命题：AI Agent时代研发效率的瓶颈不在于AI本身的能力，而在于组织结构和协作范式的滞后。作者通过"电力与流水线"的历史类比，揭示了一个普遍规律——技术革命需要配套的组织变革，否则新工具只能在旧框架中碰壁。

三大核心矛盾的深层逻辑：

第一，上下文碎片化 vs. 端到端自主执行。传统研发以"分工"为核心组织原则，将完整的产品价值流切割为多个专业域。这种切割对人类专家是合理的——人需要聚焦才能深度积累。但AI Agent的天赋是"全局上下文理解与端到端执行"，与传统分工模式天然冲突。当一个功能需求需要跨越前端、后端、数据库、DevOps等多个域时，Agent必须反复切换上下文，每次切换都是信息损耗。这不是AI能力问题，而是信息架构问题。

第二，知识生产与知识维护的分离。传统研发中，需求在语雀、文档在Confluence、代码在GitHub、Issue在Jira——这些信息孤岛之间没有机器可读的关联。AI无法像人类一样"想起来"某个决策的上下文，只能被动等待人类整理后注入。当文档更新滞后于代码变更成为常态，AI的判断质量必然受限。

第三，发布流程中的权力分散。传统发布流水线是为"人"设计的——需要审批、需要人工检查、需要人类确认。但AI是软件实体，应该能够程序化地触发构建、自动部署、智能回滚。权力分散导致的不是安全，而是AI能力的系统性抑制。

作者提出的"大厂模式"（All In Code + Agent Teams + Claw）代表了一种理想状态，但落地路径需要因地制宜。阿里内部的Agentic实践有其特定条件：大规模代码库、完善的CI/CD基础设施、丰富的工具链生态。中小团队直接复制可能面临投入过重的风险。

值得警惕的是，"短生命周期分支+合并队列"模式对代码质量门禁的要求极高。当AI成为主要代码生产者，代码风格一致性问题会大幅减少，但业务逻辑正确性验证成为新瓶颈——传统CR能发现的问题，自动化测试未必能覆盖。此外，"中心化ChangeSet维护Agent"本身可能成为单点故障，需要配套的冗余和降级机制。

从行业演进角度，本文揭示的趋势值得关注：研发组织的最小单元正从"人"向"Agent"迁移。这意味着未来的研发管理不再是"管理人"而是"管理Agent军团"——需要新的度量标准、新的协作接口、新的安全边界。这对传统研发管理者是全新课题。

实践启示¶

面向 Agent 的研发转型路径建议：

信息架构先行，工具跟进。不要急于引入更多AI工具，首先梳理研发信息流：代码、文档、需求、测试、配置的存储位置和关联关系。目标是让Agent能程序化访问所有上下文，而非依赖人工整理注入。可以从"代码即文档"开始，将分散在Wiki的需求改为Markdown与代码同仓库存储。
小范围试点长生命周期Agent。Claw模式（主动巡检、技术债务维护、文档自动更新）比端到端需求交付更容易落地，且能产生可见价值。建议选择技术债务扫描或依赖升级建议作为首个Agent日常任务，累计经验后再扩展到更复杂的端到端交付场景。
发布流水线需要重新设计权限模型。传统"人审批"模式应逐步过渡到"规则驱动+异常人工介入"。初期可以保留人工审批作为安全兜底，但逐步将常规变更（版本升级、配置调整、UI修改）的发布权限下放给Agent，关键变更保留人工确认节点。
建立面向Agent的质量度量。除传统代码质量指标外，需要新增：Agent生成代码的自动化测试覆盖率、端到端场景的自动化验证比例、从需求到上线的平均完成时间（由Agent主导的闭环任务统计）、Agent自主完成率 vs. 需要人工介入率。这些指标帮助评估Agent化转型的进展。
Sandbox环境是验证能力的关键投入。Agent驱动的E2E测试是Agentic研发闭环的最后一块拼图。没有可信赖的仿真验证环境，Agent的产出无法被自动化确认，只能依赖人工检查，这会成为效率瓶颈。可以优先建设轻量级的前后端联调Sandbox，降低环境搭建复杂度，让Agent能在隔离环境中完成全链路验证。