🤓 Orchestrator：一个多代理AI编码器。在斯坦福的TerminalBench上排名13。开源！

TL;DR:

• 周末，出乎意料地，我开发了一个多代理AI系统，在斯坦福的TerminalBench排行榜上略高于Claude Code（排名第13）。
• 该AI系统包含一个调度代理，负责分配多个探索者和编码代理执行所有工作。
• 调度器明确定义子代理必须返回的知识工件，然后在后续任务中重用和合成这些工件——创建复合智能，每个动作都建立在先前发现的基础上。

📰 版本发布

(11月4日) 🌊 Orca-Agent-v0.1

• 通过强化学习（Reinforcement Learning）训练了14B参数的Orca-Agent-v0.1 (单独仓库链接)
  • Qwen3-14B在使用该多代理框架训练后，在斯坦福的TerminalBench上实现了160.71%的相对提升。
  • 我将多代理强化学习训练扩展到32块Nvidia H100，同时启动256个并发Docker环境。
  • 完整的训练代码、模型权重、数据集和文档均在此仓库开源。

(11月2日)

• 新系统与代理能力：
  • 调度器与子代理可以是不同模型
  • 应用现在完全异步
  • 应用现在是一个包，其他项目可依赖它
  • 代理在启动时接收环境快照
  • 代理可通过任务ID作为上下文引用，将该任务的所有上下文注入子代理
  • 新的单节点/分布式节点Docker管理器（用于测试，但主要由RL使用）
  • 修复了bug

(9月2日) 🤓 Orchestrator - 多代理编码器

• 在斯坦福的TerminalBench上排名12（并非长期，因此上方截图显示排名第13 😅）
• 该排名高于Claude Code
• 所有调度代码已开源

系统工作原理

调度器是整个操作的“大脑”——它接收用户的任务但从不直接接触代码。相反，它：

1. 分析任务并将其分解为专注的子任务
2. 调度探索者代理以理解系统
3. 委托编码代理执行实现工作，提供精确的指令
4. 验证所有更改通过额外的探索者代理
5. 维护上下文存储，包含所有发现的知识

调度器缺乏直接代码访问迫使规范的委托和验证模式，导致更策略性的解决方案。

有关该项目的代码结构完整分解，请参见此处

示例模型输出

模型使用XML标签定义操作，使用YAML定义操作参数（如果存在）。以下显示模型思考后调度编码代理：

<think>
Okay, now with task_003 identifying a backup, the next step would be to attempt recovery using this identified file.
</think>

<task_create>
agent_type: 'coder'
title: 'Attempt recovery using the identified backup file'
description: |
  Execute the following steps to recover using the backup identified in task_003:
  1. Move the identified backup file (/tmp/terraform_work/.terraform.tfstate.tmp) to the target location (/infrastructure/recovered_state.json).
  2. Verify the operation by checking:
     - The existence of the new file at the target location
     - The size matches the original backup file
     - The file permissions are set appropriately (rw-r--r--)
max_turns: 10
context_bootstrap:
  - path: '/tmp/terraform_work/.terraform.tfstate.tmp'
    reason: 'The backup file identified in task_003'
context_refs:
  - 'task_003'
</task_create>

📈 评估结果

在TerminalBench上的表现

Terminal bench 是斯坦福大学和Laude Institute 创建的卓越基准测试，用于量化代理在终端中完成复杂任务的能力。我的Orchestrator系统在排行榜上获得第13名，展示了与领先AI编码助手竞争的表现。

我使用Claude-4-Sonnet和Qwen3-Coder-480B-A35B对Orchestrator进行了评估：

此图像显示Qwen-3-Coder在基准测试中的表现。此README顶部的截图显示Sonnet-4的表现。

成本与效率

最引人注目的结果是Sonnet-4与Qwen3-Coder在Token使用量上的差异。

下表显示了在TerminalBench评估运行中（5次尝试，80个任务=400条轨迹）处理的总Token数（输入和输出均包含）。

模型	成功率	总评估成本	Token使用量
Claude Sonnet-4	37.0%	$263.56*	93.2M tokens
Qwen-3-Coder	19.7%	$217.83	14.7M tokens

*Claude Sonnet-4的成本反映了大量缓存使用，减少了实际API成本

🤖 代理

虽然所有代理使用相同的底层LLM，但每个代理都有自己的上下文窗口、专门的系统消息和独特的工具集。这创建了功能不同的代理，优化了各自的角色。

🎯 调度器代理

System message 角色：战略协调者和持久智能层
能力：任务分解、上下文管理、子代理委托
工具：任务创建、子代理启动、上下文存储管理
限制：不能直接读取或修改代码——仅在架构层面操作

调度器维护所有任务的完整图景，跟踪发现和进度。它创建精确的任务描述，明确指定子代理应返回的上下文，确保聚焦且有价值的信息收集。

信任校准策略：
调度器根据任务复杂度采用自适应委托：

• 低复杂度任务：授予编码代理极高自主权进行简单修改和错误修复
• 中/大型任务：保持强信任但使用迭代分解——将复杂问题分解为原子、可验证的步骤
• 验证哲学：广泛使用探索者代理验证进展，尤其是在涉及关键功能的任务中

🔍 探索者代理

System message
角色: 仅读调查与验证专家
能力: 系统探索、代码分析、测试执行、验证
工具: 文件阅读、搜索操作（grep/glob）、bash命令、临时脚本创建
限制: 不能修改现有文件 - 严格仅读操作

探索者收集代码库信息，验证实现，发现系统行为。它们创建知识制品，消除未来代理的重复探索。

💻 编码者代理

System message
角色: 具有写入权限的实现专家
能力: 代码创建/修改、重构、Bug修复、系统变更
工具: 全文件操作（读/写/编辑）、bash命令、搜索操作
限制: 无 - 全系统访问权限用于实现任务

编码者将架构愿景转化为可运行代码。它们接收带有相关上下文的聚焦任务，并在保持代码质量和规范的同时实施解决方案。

核心系统组件

🧠 智能上下文共享

上下文共享机制

我通过**上下文存储（Context Store）**引入了一种新型多代理协调方法 - 一个持久化的知识层，将孤立的代理行为转化为连贯的问题解决。不同于传统多代理系统中代理各自为政的模式，我的架构使知识积累和共享变得复杂而高效。

上下文存储模式：

1. 协调器引导的发现：协调器明确指定从每个子代理需要哪些上下文，确保信息收集和实现报告的聚焦与相关
2. 知识制品：子代理根据协调器需求创建离散、可重用的上下文项
3. 持久化记忆：上下文在代理交互间持续存在，构建全面的系统理解
4. 选择性注入：协调器精准地将相关上下文注入新任务，消除重复发现并提供子代理完成任务所需的所有信息
5. 复合智能：每个动作都基于先前发现构建意义，创造指数级的问题解决能力

关键优势：

• 消除重复工作：子代理无需重复发现相同信息
• 减少上下文窗口负载：代理仅接收所需特定上下文
• 支持复杂解决方案：单个代理无法解决的多步骤问题变得可处理
• 保持专注：每个子代理拥有清晰、聚焦的上下文窗口

该架构确保每条发现的信息都成为未来任务的永久构建块，创建一个在问题解决过程中真正学习和适应的系统。

📋 任务管理

协调器维护一个全面的任务管理系统，追踪所有子代理活动：

核心功能：

• 进度跟踪：监控任务状态（待处理/完成/失败）跨数百个协调动作
• 故障恢复：捕获失败原因以实现战略适应和智能重试
• 工作流协调：维护清晰的审计轨迹，防止重复工作
• 战略规划：支持将复杂问题系统性分解为可验证的子任务

任务管理器是协调器的操作记忆 - 而上下文存储保存发现的知识，任务管理器追踪发现的旅程本身。这种双层系统确保协调器始终知道它学到了什么以及如何学到的，从而实现基于先前尝试的智能多步骤解决方案。

⏱️ 时间敏感的协调

在早期评估中我发现，虽然系统能够完成极其复杂的任务，但会使用大量子代理，因此任务会超时。

因此，协调器现在采用一种时间高效的执行哲学，认识到浪费时间往往源于任务描述不佳而非执行缓慢：

预防原则：

• 前置精确性：协调器花费时间撰写精确的任务描述，而非反复修改模糊的描述
• 上下文完整性：始终提供过量上下文而非不足，防止子代理重复发现已知信息
• 明确期望：每个任务明确指定应返回的上下文，消除无焦点探索
• 严格范围定义：定义清晰边界 - 应该做什么和不应该做什么，防止范围蔓延

开始使用

开发环境：

uv sync

运行评估：

./run_terminal_bench_eval.sh

快速测试各种模型：查看/tests

说明

• 最初运行评估时，我看到我的结果会排在第12名。到提交时（24小时后），我的代理排在第13名。仅仅48小时后，我的代理又跌至第15名！AI的进步速度真是令人着迷。

致谢

• 感谢Taras支持我的实验计算成本
• 感谢Anthropic团队的所有出色团队，使我能够利用Claude-4-Sonnet，这是一个非凡的模型
• 同样感谢Qwen团队发布Qwen3-Coder，完全开源
• 感谢Claude Code团队启发了我的代理工具使用实现和哲学
• 感谢Litellm团队提供了如此简单的使用包，使我能够轻松切换供应商
• 感谢OpenRouter提供的出色路由服务，使我能够轻松切换模型

multi-agent-coding-system 快速上手指南

环境准备

• 系统要求: Linux系统（推荐Ubuntu 20.04+或CentOS 7+）
• 前置依赖:

  python3.10
  uv (Python包管理器)
  docker
  git
  

• 推荐镜像源:

  # 安装时使用国内镜像
  uv sync --index-url https://pypi.tuna.tsinghua.edu.cn/simple
  

安装步骤

1. 克隆项目仓库

   git clone https://github.com/Danau5tin/multi-agent-coding-system.git
   cd multi-agent-coding-system
   

2. 安装依赖

   uv sync
   

3. 运行评估脚本（需先安装docker）

   ./run_terminal_bench_eval.sh
   

4. 测试示例（在tests目录下）

   cd tests
   # 运行模型测试
   python3 test_models.py
   

基本使用

# 启动开发环境
uv sync

# 运行终端基准测试
./run_terminal_bench_eval.sh

# 测试模型表现
cd tests
python3 test_models.py

注意：实际使用需根据具体任务需求配置orchestrator参数，完整配置参考项目文档。