为什么Qoder给每个AI代理配一个老板

当多个AI代理试图协同完成一个复杂的工程任务时，本能的想法是让它们直接对话：分享发现、请求帮助、广播更新。但随着代理数量的增加，这种交谈网络很快就会变得混乱：信息冲突、重复工作、状态空间膨胀失控。

阿里巴巴云的Qoder采取了相反的方法。其新的专家模式用一个充当团队负责人的单一代理取代了点对点消息传递。由该Leader决定谁做什么、何时做，并将结果拼接在一起。代理之间从不互相交谈。它们只和老板说话。

一个大脑，多双巧手

专家模式将工作分解为一个由依赖任务组成的有向无环图（DAG）。Leader维护全局视图，将需求分解为子任务，并将其分派给专门的专家。这些专家异步并行运行：一旦Leader发送一个任务，它会立即继续下一个任务，因此多个专家可以同时工作。

五种内置的专家类型各有自己的工具集：

• 研究专家：技术选型、根本原因分析、竞争研究、代码库影响评估。它集成了语义搜索、代码搜索、知识图谱和网络搜索。Qoder声称代码搜索的F-Score比行业基线提升了21%。
• 编码专家：新功能、紧急bug修复、重构、API开发、数据库建模。为确保安全，在跨平台沙箱（Mac、Linux、Windows）中运行。
• QA专家（验证）：变更感知回归验证、质量门禁、功能验证、部署前检查。
• 代码审查专家：PR/MR审查、风险评估、安全与性能检查、架构审查。根据Qoder的内部基准测试，它在行业中排名第二，超越了Cursor和Codex。
• 浏览器专家：前端交互测试、端到端表单流程、视觉回归、跨浏览器检查。Qoder声称与Playwright基于MCP的方法相比，节省了60%的token成本。

协调机制

每个专家通过一个邮箱汇报。完成任务后，专家发送一个回调，该回调进入Leader的收件箱。Leader空闲时读取消息，进行模型推理，并决定下一步行动：分派另一专家、更新任务状态或回复用户。这个循环（报告 → 评估 → 行动）一直持续到所有任务完成。

用户也参与其中。您可以随时中断，Leader会在下一周期中整合您的输入，调整方向或取消工作。角色从推动每一步转向对齐意图和审查结果，更像领导一个真正的工程团队。

从每个任务中学习

完成后，系统检测信号（修正、失败、用户指令）并提取可复用的技能。主代理和子代理都会从自身工作中捕获领域特定技能。这些技能作为持久记忆存储，当类似任务出现时自动召回，形成一个闭环学习循环。

基准测试：质量与成本

Qoder在内部复杂工程任务基准测试中测试了专家模式，涵盖全栈开发、跨语言重构和功能实现。他们从四个质量维度进行评估：可用性、完整性、UI体验和工程质量。专家模式在所有四个维度上表现更优。这些提升来自于架构选择（集中协调、异步并行调度和专门的专家），而不仅仅是增加更多代理。

当然，这些数据是Qoder自己的，比较模型未指明。但原则是站得住脚的：在代理能力重叠的系统中，一个共享的Leader能够维持自由消息传递难以保持的一致性。这种架构映射了一个真实的工程组织图，这是有原因的。