作者：采晨
本文的技术细节已收录到《Alibaba Cloud AI Agent Handbook》，项目地址：github.com/aliyun/ai-a... Handbook 共读群。
编码提效≠交付提效
研发协作，是当前 AI 落地最关键的方向之一。阿里云云通信基础产品研发团队很早就开始通过 AI 提效：2024年，把代码补全、对话式编程、生成式 IDE 铺开到日常开发。2025年，标准化作业，把规范、领域知识沉淀为宪法、Skill，让 AI 干活有章可循。2026年，已经全面走向 Agent 化作业模式，正朝端到端交付迈进。
谈及 AI 为研发提效，业界的第一反应往往是 AI Coding，它确实大幅提升了编程效率。但实践表明，编码效率的提升并不等于整体交付效率的提升。
回看传统的需求交付链路，从需求产生到发布上线，编码只是其中一环。在 AI Native 的交付链路里，AI Coding 前后同样存在大量工作：在此之前，需要把需求翻译成 AI 能够理解的语言；在此之后，需要对 AI 生成的代码进行质检与功能测试。若这些工作仍由人承接，人的效率无法与 AI 媲美，人工作业的节点就会成为整条链路上制约交付效率的卡点，系统吞吐的上限，由人工介入密度最高的节点决定。
因此，追求端到端的交付提效，最好的方式是在需求提出之后让整条链路都由 AI 完成作业，即全链路 Agent 作业的研发模式。要落地这一模式，必须回答三个问题：其一，多 Agent 之间如何协作；其二，Agent 的作业边界与权限如何划分；其三，这套新的生产模式如何在现有系统中安全落地。
全链路 Agent 作业的关键问题
2.1 多 Agent 之间如何协作？
针对第一个问题，团队早期的多 Agent 协作尝试遇到了业界共性难题：上下文缺失。
以技术方案交接为例：研发 Agent 编写技术方案时着重描述整体技术架构与中间件选型，而下游测试 Agent 拿到方案后更想看到的是当前作业系统的边界在哪里、遇到问题应当如何定位。于是在每个 Agent 看来自己的产出都丰富且详细，但在上下游协作中却普遍出现"下游想要的内容、上游没有产出"的现象。问题的根源在于，早期的 Agent 协作仍是手工作坊式的生产方式，主要依赖人工经验、靠约定俗成进行协作，无法满足企业级生产对稳定性与一致性的要求。
我们的解法是借鉴工厂流水线：为研发流程定义标准与流程，明确 Agent 作业的要求，把每一道工序应该输入什么、输出什么都定义清楚，以流水线作业的形式让 Agent 协作进入标准化生产，统一协作契约、明确协作链路，使语义对齐、上下文完整传递、交接即插即用。
2.2 如何定义 Agent 的作业边界与权限？*
针对第二个问题：Agent 的作业边界与权限如何划分，这不单是一个技术问题，更是一个组织问题：把 AI 作为一种新的生产要素放进系统，应当如何管理它。
目前业界使用 Agent 的方式大致有两种：一种是把 AI 作为一个独立的个体去应用，即数字员工或数字人；另一种是把 AI 当作人在数字世界的延伸，即数字分身。 我们选择数字分身。原因在于，若把 AI 当作独立个体，就必须为其单独定义一套作业流程与行为准则，是工程复杂度更高的选择；而数字分身可以借鉴现有成熟的组织管理模式，用人的权限去作业。
其一，组织中不同人的权限本就不同，分身拥有与人一致的权限，能做什么、不能做什么被天然框定；其二，分身以人的权限提交代码、生成产物，在系统看来就是人执行了相应的操作，一旦出现问题可以追溯到人；基于责任约束，负责人有义务对自己分身的行为负责，并持续迭代与优化分身。通过数字分身把 Agent 作业的边界与权限明确下来，Agent 才能作为可被组织信任的生产要素纳入研发体系。
2.3 新的生产模式如何在现有系统中安全落地？
针对第三个问题，这套组织系统如何落地，我们的原则是安全生产加演进式落地。
稳定性优先是第一原则：无论需求由人实现还是由 AI 实现，都必须保证不导致线上问题、不影响客户使用。为此我们定义了两条门禁。
- 一是 Harness 工程门禁： 使用分身作业之前，必须保证当前应用的 Harness 工程已建设就绪，使 AI 作业过程有法可依，并基于 Harness 工程的建设情况定义分身的能力等级（L）。
- 二是需求风险等级门禁： 为需求区分风险等级（R），运维工具、数据看板一类简单需求风险较小，多应用协作、核心链路改造一类复杂需求风险较大。
分身在作业之前评估当前需求的风险等级，只承接自己能力范围之内的需求；若需求超出自己的能力范围（R > L），则转交对应的研发负责人以人工模式作业。系统上线初期，Harness 工程与知识库尚处建设早期，能够承接的还仅限于简单需求；随着作业过程中 Harness 工程与知识库的不断迭代和丰富，分身的能力边界逐渐外扩，可承接的需求由简单走向复杂。
这就是稳定性优先、由简到繁、渐进式落地的方案。
整体架构：云端数字分身+需求流水线自动化交付
基于上述思路，我们构建了一套基于云端数字分身与需求流水线自动交付的研发模式，可以实现 7×24 小时不间断作业。
在新的研发模式里，数字分身既是需求的入口，也是需求的路由器：产品、业务、技术角色都可以把需求提交给研发数字分身进行作业。数字分身接到需求后，首先判断当前需求的风险、评估自己的能力是否可以承接：判断可以承接的，自闭环完成后续的研发工作；判断超过自己能力范围的，分发给对应的研发负责人进行作业。
目前这套作业系统已经推广到云通信基础产品的四条关键业务线，国内短信、智能语音、智能调度、国际短信。以现有模型的能力，单个分身可以并行处理三到四个需求，极大提升了研发的并行度。实际落地效果显示，在分身评估可以承接的前提下，约三分之二的需求真正实现了端到端交付，简单需求端到端交付率为 66.7%，整体交付物符合预期。
关键技术方案设计
4.1 如何定义流水线
回到第一个问题：多 Agent 应该如何协作？
我们的答案是通过流水线定义多 Agent 的协作方式。 流水线的设计方法是：把 AI Native 交付模式下所有的研发工作分为九大工序，PRD 生产、门控、就绪、设计、编码、自检、测试质检、发布验收、Loop 反向，以九大工序为骨架设计流水线。
骨架之上遵循三条原则。第一条是契约链原则 ：每一个阶段的输入和输出、产物的内容以及格式，都事先定义清楚，工序的交付物即契约。第二条是底线原则 ：上一个工序的交付如果出现问题，必须打回重做，不合格不流转，绝不能带着问题向下游传播、影响整体的作业质量。第三条是可插拔 Skill：以清单化的能力承载各工序的执行并把整体工序串联起来，Skill 可替换、可增补、可持续升级，保证面向不同业务场景时具有更高的适配性。
三条原则中，前两条保证整体的作业质量不走样，第三条保证整体的作业模式可以扩展到不同的业务场景。
4.2 多分身如何协同作业
流水线定义好之后，分身如何在工序之间进行协作、实现端到端交付？
以 AI Coding 完成之后的质检和测试环节为例。首先为数字分身的子 Agent 建立独立的工作区，让它们独立进行作业：在同一个工作区作业时，子 Agent 会出现上下文幻觉的问题，不同子 Agent 的结论也会影响到其他 Agent 的判断；通过独立工作区可以把这种幻觉隔断，各角色的分身在自己独立的工作区里面只审核自己关心的内容，产品分身核对当前的业务需求是否完整实现，研发分身检查代码是否存在缺陷，安全分身审查当前的交付物是否满足安全合规，测试分身自动编写测试用例并在测试环境里自动执行。
所有分身检查完成后统一出具报告，收口到技术负责人 Agent：主 Agent 基于声明式检查点逐项核查，给出通过或不通过的结论；存在问题的，触发自动重跑和修复，异常与未通过一律打回本工序。依靠这种多角色的协同作业和自动化的测试，测试和质检环节的人工吞吐瓶颈被正面解开。
4.3 如何实现系统渐进式落地
最后一个问题：如何把这套系统渐进式落地？
我们主要依靠事后的质检和 Loop 机制。 分身每一次交付完成之后，都会进行一次审计，事后审计是标准的生产环节。审计的内容主要包括：当前的流程走得有没有问题，交付物是不是符合预期，以及整体作业过程里 AI 执行的数据，包括缓存命中率、Token 消耗等是不是正常。
审计过程中如果发现好的实践或者关键的信息，会自动沉淀到知识库里面，下次有同类的需求可以直接复用；如果审查出有待优化的点，会直接向分身的负责人推送对应的优化建议，由人决策当前的优化点是否执行，并进行整套物料的优化。
Loop 遵循"检测→归因→修正→验证"的循环。在这套机制下，每交付一个需求，就完成一次审计、一次物料的修正和迭代、一次知识库的更新；数字分身的能力逐步提升，能力等级由 L1 向 L2、L3 迈进，可以作业的边界一步步外扩，能交付的需求自然也会越来越多。正是通过事后审计和 Loop 的机制，实现了整套全流程 Agent 协作研发模式的渐进式落地，体系越用越强。
一个真实需求的端到端交付之旅
以一个脱敏后的真实需求为例，展示端到端交付的完整旅程。
业务方通过钉钉向研发负责人的数字分身发送需求的工单；数字分身接到需求之后，首先评估当前的需求是否可以承接。判断可以承接之后，多角色 Agent 进行圆桌讨论和需求对焦，并把对焦后的结果返回给对应的需求提出方；在得到需求方的确认之后，生成对应的需求文档。然后进行 Harness 物料的检查，只有在物料检查通过之后，才会进入后续的作业流程。
后续作业的第一步是技术方案的设计和内部评审，评审不通过的会自动打回修复；通过后提交给技术负责人进行技术方案的审批，审批通过之后自动进入 AI Coding 和测试环境的部署。下一步进行各角色的产物质检，如果发现问题也会自动进行修复；检测完成之后进入功能的自动化测试，只有当所有的测试用例都执行通过之后，提交给平台进行质检。在所有的研发流程完成之后进行事后审计：审计过程中的知识落库，并且把对应的优化点提交给对应的负责人去决策。
整条链路在通过接单门控后无人值守、九个阶段自驱动，每一步由谁执行、依据什么执行、结果如何，全程留痕、事后可查。
未来规划与展望
目前这套研发系统已经在云通信基础产品研发团队的交付体系内落地，后续的规划主要集中在三个方面。
其一，推动作业边界不断外扩 ：随着物料与经验的积累，由简单的需求慢慢向复杂需求转变和延伸，可交付需求的范围自然生长。其二，成本控制 ：底线是当前的这套交付模式不能比现有人工作业模式更贵，我们通过模型的分档路由、上下文的治理以及夜间低峰期的批量运行去降低交付成本。其三，适配新的组织模式：我们已经尝试通过一个工程师加若干数字分身组成一个作业单元的方式，直接负责一个领域的工作，使团队吞吐量不再受限于人头数；当前这套数字分身研发模式仍适配以人为主体的组织形式，如果后续在 AI 时代组织的形式有了新的变化，我们也会积极去适配。
回顾整个 AI 提效的历程，团队也走了不少弯路，我们的体会是两种极端都不可取。
第一种是因噎废食：觉得 AI 可能会产生幻觉、导致线上的稳定性风险，就干脆不用 AI，还是坚持古法编程。第二种是急于求成：不去做知识的整理和 Harness 工程的建设，而是指望通过模型足够强大来保证交付的质量。
实践过程中我们发现，不管模型有多先进，都很难一次性理解我们领域的知识：领域的知识往往是非标的、私域的，很多术语和黑话可能只有团队自己在用；有一些内容是非结构化的，靠人脑袋里口口相传去作业；还有很多是反常识的，系统里某一个缺陷和另一个 bug 协同存在、负负得正，竟然可以平稳运行。但改了其中一个就可能引发故障。这些内容 AI 都不可能一次性理解。
所以我们选择的策略是为 AI 定流程、定标准 ：先把它的作业范围框定在一个比较小的范围之内，然后在这个工程里由人带领 AI 学习、逐步迭代，通过渐进式的方式实现研发提效，实现 AI 研发流程的进化。同时我们在实践过程中得到一个结论：AI 研发提效长期的差异点并不在于模型能力的好坏，而在于围绕这一套模型建立起来的整个研发交付体系资产的厚度。