阿里巴巴工程团队：代码写快十倍，交付周期为何只缩短1.8天

一个复杂功能从提出需求到上线，典型团队大约需要20个工作日，其中写代码只占2天。假设AI编码工具把这部分速度提升十倍，2天变成0.2天，整个交付周期也只从20天缩短到18.2天。阿里巴巴云工程团队在2026年11月发表的实践记录中，用这个算术把问题摆到了台面上：编码提速不是瓶颈，需求讨论、方案确认、测试验证、跨模块集成和发布准备才是。一旦代码写得更快，这些前后环节反而更加显眼。

他们的做法是把研发流程中不同角色承担的工作拆成15个Agent，由一个Leader根据任务需要调度。每个Agent有独立的技能、工具和上下文，职责明确：Researcher负责理解需求和代码库并构建问题证据图；Explorer寻找同构实现并形成候选方案；Spec结构化目标、边界和验收标准；Code Worker在独立分支和会话中实现候选方案；Test/Harness执行编译、测试和端到端验证；Judge/Verify独立选择最佳候选、执行语义验收和对抗性审查；Deploy准备环境并执行发布验证。

这套架构中两个设计选择被作者认为最为关键。第一，实现和验证必须由不同Agent完成，这样验证才拥有独立视角——如果写代码的Agent同时负责判断自己写得对不对，验证就失去了意义。第二，跨迭代的上下文必须保持——上一个Agent做了什么、为什么那样做、验证中发现了什么，后续Agent必须能继续使用这些信息。如果测试不通过，回到原始Code Session继续修复；如果方案方向错了，带着失败证据重新做Research和Explore；反复尝试仍不收敛，触发Human Gate请人介入判断。

在AgentCore负责执行之外，他们另设AgentLoop作为优化平面。AgentLoop记录任务完成过程：调用了哪些模型和工具、在哪里失败、经过几轮返工、最终结果是否满足要求。这些Trace、Session和Trajectory数据经过Pipeline、Dataset、Evaluation和Experiment处理，变成可复现样本、可比指标和可反复验证的实验。优化分三种方式：人工由领域专家定义什么是好结果、用什么指标和Rubric评估；半自动由系统生成优化建议（哪些任务消耗了过多Token、哪些步骤低效、哪个工具持续报错）；自动则通过经验仓库按RAC方法从Trace中提取经验并动态注入Agent。

实际效果方面，他们在Trace to Trajectory服务（将Trace数据转换为trajectory数据，生产中不断遇到新的解析异常）这个受限场景中做了验证：选取19个问题，约10个产生了与人类专家大致相当的实现，另外5个接近专家水平，交付周期从约一个月缩短到一周以内。离线实验中，他们从代码库选取20个高质量人类专家Commit，反向生成需求构建Benchmark，让Agent团队完成并与专家实现逐项对比。

作者也坦率列出了四类持续问题：需求说清楚了但架构约束未必传递到位（比如想扩展现有API能力，Agent可能选择新增一个API，单看任务更容易完成，放在系统全局则不符合团队设计要求）；真实场景总会带来未预料的问题（AI应用的输入远比传统软件开放）；同一问题可能反复出现（代码、业务规则和运行环境都在变化，经验不持续积累就会反复踩坑）；修一个问题可能影响其他任务（改一个Skill当前用例通过，另一个用例可能回退）。这些问题的存在本身说明，多Agent编排不是搭好框架就自动运转，而是需要持续观察、调整和积累。