这几年，AI 写代码的能力进步很快。把一个需求交给 Coding Agent，它已经可以读代码、改代码、跑测试，甚至准备好 PR。但在实际研发中，我们会遇到一个问题：代码写得更快了，一个需求从提出到上线，为什么还是要花那么长时间？
围绕这个问题，我们尝试用 AgentCore 把 15 个不同分工的 Agent 组织成一支研发小队，让它们参与完整的交付流程；再通过 AgentLoop 分析运行过程，持续改进这支小队的表现。这篇文章就聊聊，这套方式怎么工作，以及我们在实践中遇到了哪些问题。
01、AI 已经走向“持续做事”
最早使用 Chatbot 时，我们通常是问一个问题，等它给出回答。它可以帮我们整理知识、写文案、做摘要，但遇到复杂问题，回答的可靠性还不够稳定。
后来，以 DeepSeek R1 等为代表的推理模型，开始通过更充分的思考处理复杂问题。再往后，模型有了工具调用能力，可以读取外部信息、执行命令、修改文件，开始真正参与任务。
有了这些能力，下一步就是让 Agent 持续工作：观察环境、执行操作、检查结果，遇到问题后调整方法，再继续推进。
在 Coding 场景中，这种进步已经比较明显。相关基准测试指标从约 33% 提升到了 70% 以上。与此同时，AI 能够承担的任务也越来越复杂。如果用人类专家完成任务所需的时间来衡量，这个时间跨度大约每七个月就会翻一倍。
对研发团队来说，这带来了新的可能：我们可以开始考虑，让 Agent 参与更长的工作流程，承担更多需要连续推进的任务。
02、代码写得快了，交付为什么还慢？
拿团队里一个复杂 Feature 的典型流程来估算，从需求提出到上线，大约需要 20 个工作日，其中代码实现只占两天。假设 Coding Agent 能把编码速度提高十倍，这两天就能缩短到 0.2 天。但放到完整流程里，交付周期只是从 20 天变成了 18.2 天。
剩下的时间花在哪里？
需求要讨论清楚，Spec 要反复确认，方案要结合现有架构。代码写完后，还要测试、Review、跨模块联调，再准备发布。中间一旦发现问题，又可能回到前面的环节重新调整。所以，编码提速之后，需求确认、协作、验证和等待这些环节就变得更加突出。
我们接下来想做的，就是让 Agent 也能参与这些工作，把整个流程接起来。上下文可以随着任务向后传递，验证结果可以直接推动下一步，人则把精力更多放在目标、架构和风险判断上。
03、把 15 个 Agent 组织成一支研发小队
我们的做法，是把研发流程里不同角色承担的工作，拆成不同的 Agent，再通过 AgentCore 把它们组织起来。
这 15 个 Agent 组成一个能力池，由 Leader 根据任务需要调度。每个 Worker 都有自己的 Skill、Tool 和上下文，也有明确的职责。
一个任务进来后，Leader 需要判断：先做什么，交给谁，完成后怎么检查，出现问题后又该回到哪里。
比如，测试没有通过，就回到原来的 Code Session 继续修复；如果发现方案方向有问题，就带着失败证据重新做 Research 和 Explore；如果反复尝试仍然不能收敛，就触发 Human Gate，请人补充判断。
这里很重要的一点，是把任务状态保留下来。前一个 Agent 做了什么、为什么这样做、验证时发现了什么，后面的 Agent 都应该能接着使用。
任务可以从 Issue 开始，也可以通过 Chat 补充信息。最终交付的内容，除了代码和 PR，还包括测试报告、审查证据、进度、阻塞信息，以及完整的运行轨迹。
我们的目标，是让这支小队能够从需求一路推进到经过验证的交付，并进一步向自动部署上线延伸。
04、流程跑通以后，新的问题也来了
把 Agent 组织起来、跑通一次任务，只是第一步。进入真实研发流程后，我们逐渐遇到了几类持续性的问题。
首先，需求说清楚了，架构约束却未必传到位。
比如，我们希望在已有 API 上扩展能力，但如果没有把这个约束告诉 Agent，它可能会选择新增一个 API。单看当前任务，这种方式可能更容易完成；放到整个系统里，却不符合团队的设计要求。
这类信息往往存在于代码、文档和人的经验中，需要整理出来，并随着业务变化持续更新。
其次，真实场景总会带来预料之外的问题。
传统软件可以围绕已知功能路径设计测试。AI 应用的输入更加开放，用户可能换一种问法，也可能提出设计时完全没有考虑过的问题。
例如，在外卖应用里询问 Python 程序怎么写，就已经超出了原有业务范围。我们很难在第一天就把这些情况全部覆盖，只能在运行中不断发现和补充。
第三，同样的问题可能反复出现。
一次任务跑通，不代表后续都能顺利完成。代码、业务规则和运行环境都在变化。如果没有持续积累经验，Agent 就可能反复踩同一个坑，消耗时间和 Token，最后仍然需要人来处理。
第四，修好一个问题，也可能影响其他任务。
改了一个 Skill，当前案例通过了，另一个案例却可能退化。因此，每次优化之后，都需要有一套相对稳定的 Benchmark 和回归验证，帮助我们判断整体表现有没有改善。
这些问题也让我们意识到，Agent 需要一套持续运行、观察和调整的机制。
05、用 AgentLoop，把运行结果变成下一轮改进
我们把 AgentCore 作为运行面，把 AgentLoop 作为优化面。
AgentCore 负责带着这支小队完成任务。AgentLoop 则记录和分析任务是怎么完成的：调用了哪些模型和工具，在哪里失败，发生了多少次返工，最后的结果是否符合要求。
这些 Trace、Session 和 Trajectory 数据，经过 Pipeline、Dataset、Evaluation 和 Experiment，可以变成可复现的样本、可比较的指标，以及能够反复验证的实验。
这样，我们就能从一个具体问题出发，找到原因，调整 Skill、Tool 或协作流程，再运行一次，看看是否真的有所改善。新的运行又会产生新的轨迹，继续进入下一轮调优。
在这个过程中，我们用了三种方式，习惯上把它们叫作手动挡、半自动挡和自动挡。
手动挡，由业务专家来主导。专家先定义清楚什么是好的结果、要看哪些指标、用什么 Rubric 评估。评估后找到 Bad Case，把它们放进数据集，再通过实验比较不同方案。
半自动挡，由系统提供优化建议。比如，哪些任务消耗了过多 Token，哪些步骤效率偏低，哪个工具持续报错。系统把这些问题整理成报告，业务专家再根据报告做针对性的调整。
自动挡，则通过经验库持续积累和复用经验。按照 RAC 的思路，系统从轨迹中提取经验，再动态注入 Agent。经验的沉淀和注入可以自动完成，专家不用逐条整理，Agent 也能在后续任务中用上之前积累的经验。
这三种方式可以配合使用：专家定义目标，系统辅助分析，经验库负责持续积累。
06、在 Coding 场景里，我们怎么调优？
我们主要做了两件事：用专家实现建立离线基线，再从真实运行中持续积累经验。
先说离线实验。
我们从代码库里选了 20 个质量较好的人类专家 Commit，再根据这些代码生成对应需求，构建一套 Benchmark。
然后，让 Agent Team 来完成这些任务，把它的结果和专家实现放在一起比较：方案有没有偏差，代码实现有什么问题，验证是否充分，Agent 之间的分工是否合适。找到问题后，我们调整系统，再跑一轮实验和回归测试。这样，每次调整都有一批相对固定的题目可以检验，也能更清楚地看到哪些地方进步了，哪些地方还需要继续改。
再说在线经验积累。
真实任务会不断产生新的轨迹。经验库可以从中沉淀同类问题的 SOP、较好的执行路径，以及工具调用和工具路由中的反模式。比如，某种调用方式经常出错，就把这个模式记录下来，让 Agent 下次遇到相似情况时能够规避。某类问题有一条比较好的解决路径，也可以把它整理成经验，在后续任务中复用。
离线实验帮助我们对照专家基线，在线经验则让系统持续吸收真实任务中的反馈。
在多 Agent 的协作方式上，我们采用了一个不断迭代的 Loop：先调研，再探索方案，完成实现后进行验证和比较。如果没有达到验收条件，就带着反馈继续下一轮；满足条件后，再进入交付。这和 ReAct 中观察、行动、获取反馈的思路相似，只是我们把它用到了多个角色的协作中。
实践中，有两个做法比较重要。一个是让实现和验证由不同的 Agent 承担，使验证有独立的视角；另一个是在迭代时保留必要上下文，让下一轮能够接着已有证据和历史尝试往前走。
07、先从范围明确的场景做起
Coding 任务的开放性很强，同一个需求可能有很多种实现方法。因此，我们先把任务范围和验收条件限定清楚。目前，已经有两个场景的样例上线。
其中一个场景来自 Trace to Trajectory 服务。这个服务负责把 Trace 数据转换成轨迹数据，线上会不断遇到新的解析异常。
当出现无法解析的 Bad Case 时，我们把相关信息写入日志，通过告警触发新的 Issue，再启动研发小队，完成问题定位、代码修复和验证，最终形成经过验证的交付。
在最终验证中，我们选了 19 道题。其中，约 10 道题的实现结果与人类专家方案近似等价，另有 5 道题接近专家水平。在这些受约束场景的实践中，交付周期也从原来的约一个月缩短到了一周以内。
对我们来说，这项实践最有价值的地方，是开始把需求、实现、验证和反馈连成一个完整流程。AgentCore 让多个 Agent 像一支团队一样协作，AgentLoop 则帮助这支团队记住做过的事，从每一次交付中积累经验，逐步把后面的任务做得更好。
本文作者@阿里云云原生。原文链接：https://mp.weixin.qq.com/s/kfjekdBKA0wcT5pheMwU_Q?nwr_flag=1