多 Agent 组成研发小队：AI 研发如何从写代码走向端到端交付¶
Coding Agent 正在快速提升代码生成的速度，但一个 Feature 从需求到上线，还要经过需求澄清、方案设计、测试、Review、联调和发布。只优化 Coding，就像只提升一条生产线上的单台设备：局部吞吐上去了，等待、交接、验证和返工仍然决定整体周期。
我们因此把目标从“让 Agent 写代码”，调整为“让一支 AgentTeam 交付结果”：由 AgentCore 组织不同角色的 Agent 协作，让任务从 Issue 进入，经过研究、方案、实现、验证，最终产出可审查的 PR 和完整证据；再由 AgentLoop 采集真实运行轨迹，持续评估和改进这套研发小队。
一、Coding 已经很快，交付为什么仍然慢？¶
以团队中一个复杂 Feature 的典型链路估算，从需求到上线约需要 20 个工作日，其中代码实现约 2 天。即使 Coding Agent 把编码速度提升 10 倍，编码时间从 2 天降到 0.2 天，端到端周期也只是从 20 天降到 18.2 天。
原因很直接：研发不是一段代码生成任务，而是一条需要多人、多系统和多轮判断共同完成的链路。需求与 Spec 要反复对焦，方案要结合既有架构，测试与 Review 要等待反馈，跨模块联调依赖环境，发现问题后还可能回到 Spec、方案或编码阶段返工。
所以，下一步提效的重点不是继续压缩那 0.2 天，而是让 Agent 能够接管并串联剩余流程：减少上下文在角色之间的反复转述，让验证结果直接驱动下一步，让人只在目标、架构与风险判断上介入。
二、AgentTeam：把多个 Agent 组织成一支研发小队¶
AgentTeam 不是让多个 Agent 同时“自由发挥”，而是建立一个角色明确、状态可见、交付物可验证的协作系统。我们把 15 个面向不同工序的 Agent 组成能力池，由 AgentCore 作为 Leader，根据任务状态按需调度。
其中，几类代表性角色分别承担不同职责：
| 角色 | 主要职责 | 关键产物 |
|---|---|---|
| Researcher | 理解需求与代码库，构建问题证据地图 | 相关模块、约束与历史变更 |
| Explorer | 寻找同构实现，形成候选方案 | Reference Anchor 与方案比较 |
| Spec | 把目标、边界和验收条件结构化 | 可执行 Spec |
| Code Worker | 在独立分支和会话中实现候选方案 | 代码变更 |
| Test / Harness | 编译、测试和端到端验证 | 可复现的测试证据 |
| Judge / Verify | 独立做候选选优、语义验收和对抗审查 | 审查结论与失败反馈 |
| Deploy | 准备环境并执行发布验证 | 发布与回滚证据 |
AgentCore 负责的不是某一次生成，而是整个团队的运行：拆解任务、调度角色、保存状态和共享上下文，并根据失败类型选择下一步。测试失败，回到同一个 Code Session 继续修复；方案方向错误，带着失败证据重新进入 Research 和 Explore；持续不收敛，则触发 Human Gate，请人补充判断。
任务的输入可以是 Issue，也可以来自 Chat 中的人工补充；输出不仅是代码与 PR，还包括测试报告、审查证据、进度与阻塞状态，以及完整的可观测轨迹。这样，研发交付从“几个人分别完成一段工作”，变成“一个团队围绕同一状态和同一验收标准持续推进”。
三、Coding Loop：不是一次生成，而是持续收敛¶
多 Agent 协作能否可靠，关键不在 Agent 数量，而在协作机制。我们把最核心的 Coding Loop 设计成两层回环：内层解决“代码能不能跑”，外层判断“方案是不是对”。
首先，Researcher 从需求、代码和历史变更中建立证据地图；Explorer 再找到代码库中最相似的实现，形成一个或多个候选方案。不同方案进入独立分支和独立 Code Session，由 Code Worker 与 Test / Harness 组成内层循环：测试失败就保留上下文继续修复，直到通过或确认卡住。
候选实现完成后，由独立的 Judge / Verify 进行选优和验证。这里不仅检查测试是否通过，还要判断需求语义是否满足、是否偏离既有架构，以及是否存在“测试绿了但实现方向错误”的问题。验证通过才交付 PR；边界缺陷保留代码做增量修复，方案级错误则回到 Research / Explore 重新选择路径。
这套 Loop 有四个关键设计：
-
参考锚定：先找同构实现和架构约束，再设计方案。已有代码不是绝对真理，但通常是最精确、最新鲜的工程参照。
-
Produce / Verify 分离：作者与 Judge 使用独立会话，避免同一个 Agent 用自己定义的标准证明自己正确。
-
带记忆迭代：同一方案续接 Code Session，Research 也保留历轮失败反馈，避免每次返工都从零理解。
-
分级验证：正确性、安全和架构偏离必须修复；非阻塞改进项记录留档；连续不收敛时及时转人工。
因此，AgentTeam 的工作方式更像一支真实研发小队：有人研究，有人实现，有人独立审查，失败后依据证据返工，而不是把一个大 Prompt 交给单个 Agent 一次性完成。
四、从单次交付到持续进化¶
AgentTeam 跑通一次任务，只能证明流程可用。业务规则、代码和运行环境会持续变化；Prompt 或 Skill 的局部调整，也可能让其他任务退化。如果没有真实数据驱动的持续调优，Agent 会重复踩坑、反复消耗，最终仍要依赖人工兜底。
为此，我们用 AgentLoop 承接 AgentTeam 的数据飞轮。AgentCore 负责持续执行，AgentLoop 采集 Trace、Session 和 Trajectory，还原每一步模型调用、工具执行、失败和返工；再通过 Pipeline、Dataset、Evaluation 和 Experiment，把真实问题转化为可复现样本、可比较指标和可回测实验。
目前主要有两条调优路径：
-
离线 Meta-Loop：从人类专家的历史 Commit 反向整理题目，让 AgentTeam 在看不到答案的条件下独立解题；再比较 Diff 和执行轨迹，定位 Skill、Tool、状态流转或 Harness 的问题，调整后用同题和留出题回测。
-
在线 Experience Loop：真实任务的 Trace 自动上报，从成功与失败轨迹中提炼 SOP、工具调用路径、修复规则和反模式；经过来源、适用边界和效果验证后，在下一次相似任务中按语义召回，动态注入 Researcher、Explorer 或 Worker 的上下文。
这让每次交付不只产出一份代码，也为下一次任务留下可以复用的经验和验证资产。
五、阶段性结果：先证明流程跑通，再证明规模化收益¶
目前，这套 AgentTeam 已在两个实际任务中完成从需求到上线的闭环：一项是修复 Trace2Trajectory 的非标轨迹清洗问题，另一项是为数据处理管线增加新的算子。两项任务都完成了代码修改、测试验证、审查和上线，证明多 Agent 的协作链路已经能够进入真实研发流程。
在离线校准中，我们共整理了 24 道内部基线题，其中 19 道作为未参与调优的新题进行盲测。逐题对照专家代码后，结果为：10 道等价、5 道接近、4 道部分完成、0 道方向错误。这个结果说明当前方法能够帮助我们发现和修正结构性问题，但它是内部题集上的对照结果，不等同于生产环境通过率。
在线交付方面，当前少量 Feature 样本观察到的团队交付节奏约为一周。由于样本量仍小，且尚未按任务复杂度分组，这个数字更适合作为阶段性观察，而不是普遍结论。后续我们会持续跟踪独立验收通过率、人工 Review 投入、单位交付成本和上线后缺陷，判断提效是否真正成立。
AgentTeam 的目标不是用 Agent 取代研发，而是重新分配人的注意力：把可执行、可验证、可回放的工作交给 Agent，把目标、架构、风险和最终放行留给人。AgentCore 让多个 Agent 像团队一样工作，AgentLoop 让这支团队从真实交付中持续改进。只有执行闭环和数据飞轮同时建立，Coding Agent 的局部速度，才可能真正转化为端到端交付效率。