team-solve：基于Memdoor的多智能体编程框架

team-solve 是一个专为解决编程问题设计的多智能体框架，构建于 Memdoor 工作流之上。该系统包含五个核心角色（规划者、两名构思者、求解者和经理）以及一个修复工作者。每个角色均从全新的上下文启动，仅通过磁盘文件进行通信。决定最终成败的关键在于运行样本的 Shell 脚本，而非模型本身。该方法被称为 GVS5H（Lee, 2026），即使用五个 Qwen3.8-27B 模型在 LiveCodeBench Hard 数据集上达到了与 Fable 5 相当的水平。

在使用作者确切提示词对 Qwen3.8-27B 进行重建后，该循环在 LiveCodeBench Hard 前十个问题上的五次传递测试中，平均得分为 9.8/10。相比之下，其自带框架得分为 9.6，而单独运行的 Fable 5 仅为 8.0。

相关代码文件由 coder 根据方法描述自动生成（2026-10-25），无人工编写痕迹。

LiveCodeBench Hard 前十题五次传递测试结果

测试基于 GVS5H 自带框架，在同一模型（Qwen3.8-27B，128K 回复上限）上重建为 Memdoor 工作流。针对 LiveCodeBench Hard 列表中的前十个问题，进行五次传递测试，并使用修正后的评分器对公共和隐藏测试集进行评分。

Pass Memdoor workflow Authors' 27B harness Fable 5 alone
1 10 / 10 9 7
2 10 / 10 10 8
3 10 / 10 10 10
4 10 / 10 9 8
5 9 / 10 10 7
Mean 9.8 9.6 8.0

“Authors'”列数据源自其仓库中重新评分的结果文件（q38_multiagent_pN, fable5_single_pN），即论文原始数据。bench/results/parity-5pass/ 目录保存了所有 50 次运行的完整记录，包括请求与回复、程序代码、评分器输出、每次调用成本及服务器信息，以及未计入结果的尝试。50 次运行中解决了 49 个问题；总成本为 $35.79（1530 万输出 token）。若加上因时钟限制被截断、修复停止或暂停的 16 次尝试，总成本为 $38.77。

注：此处测试范围为十个问题，每个问题五次传递，而非作者的 100 个问题。比赛时间为 2025 年 3 月 29 日至 4 月 6 日，模型可能在训练数据中见过这些问题，不能排除数据污染的可能性。“Fable 5”列数据来自作者文件的单次调用，并未在此框架中运行。循环仅查看公共样本，分数基于隐藏测试。一次运行的中位模型时间为 40 分钟（最长 4 小时），成本为 $0.39。全部在 OpenRouter 上运行，而非本地机器。运行脚本和本地路径显示为 <scratch> 和 $HOME，其他内容未经编辑。

与作者实现的一致性

逐字节完全相同：lib/test_parity.py 运行他们的 multiagent_solve 和本工作流，针对同一个脚本化模型进行比较。温度设置（计划 0.3，构思 0.4，经理和工作者 0.2），top_p 0.95 和 top_k 20，128K 上限，最多 10 轮。切断的工作者会生成摘要，无文本回复由其推理过程回答。

差异之处

主要差异在于主机环境。作者使用的是自有 FP8 vLLM。本测试使用 OpenRouter，按顺序请求 Modal, CoreWeave, Parasail, Wafer，直到 Modal 速度降至 14 tokens/s，随后仅使用 FP8 主机（Wafer, Parasail, CoreWeave）。其中 203 次调用由 Modal 服务，27 次由 CoreWeave 服务，115 次由 Wafer 服务。三次运行中途切换了主机，已完成步骤得以保留。

所需调整

问题文本存在差异：早期版本围绕每个问题编写任务文件，但 27B 模型从中规划的效果不如直接使用作者确切的 LiveCodeBench 文本。四项 Memdoor 更改使工作流能够像其框架一样提问：当模型未写入文本时，任务返回模型的推理；启用 top_p/top_k；使用 mark_cutoff 处理因上限被切断的回复；以及拥有独立四小时时钟的调用。

失分原因分析

  • Pass 5, abc399_e（隐藏测试 32/44）：第 1 轮程序正确，但经理构造了带有错误预期答案的反例，导致团队重写程序。新程序通过了样本测试，但未覆盖该特殊情况。
  • Pass 4, arc196_c 和 arc196_d：一个已通过所有隐藏测试的程序被后续轮次覆盖，因为经理未宣布完成。两者在循环结束前都找回了正确程序（arc196_d 在第 8 轮，arc196_c 在最后调用），成本分别为 $3.44 和 $4.24，是两次最昂贵的运行。

这两点均可在不改变方法的情况下修复（如对小输入使用暴力破解检查经理的反例；保留通过样本测试的最后一次程序）。上述分数未计入这些潜在修复。

运行方式

可通过以下命令安装并运行 team-solve 工作流：

curl -fsSL https://memdoor.ai/install.sh | bash
memdoor connect openrouter                 # 或 anthropic, openai, gemini, chatgpt
git clone --depth 1 https://github.com/guregodevo/memdoor

mkdir -p ~/.memdoor/workflows
cp -r memdoor/examples/workflows/team-solve ~/.memdoor/workflows/
mkdir my-problem && cd my-problem
cp -r ../memdoor/examples/workflows/team-solve/sample/* .          
memdoor workflow run team-solve --wait

在 memdoor tui 中使用 /workflow 可实时绘制运行过程。对于自定义问题，替换 task.md 并在旁边放置配对的 tests/N.in / tests/N.out 文件。程序名为 solution.py，从 stdin 读取，并与样本使用 diff 进行比较。需要 Python 3 和 bash 环境。步骤名称中不包含任何模型，无论 /model 固定为何种模型，均由其响应，支持本地模型（如 Janis, Ollama 或 llama-server）。

工作原理

工作流结构如下：

plan ──┬── ideate-a ──┬── solve ── test ── review ── repair ── verify
       └── ideate-b ──┘
Step Kind Reads Writes
plan Agent task.md plan.md, notes.md (ledger)
ideate-a/b Agent (Parallel) task.md, plan.md, notes.md Proposal at anchor (A: direct algorithm, B: different technique)
solve Agent Both proposals Decision in notes.md, solution.py
test Command tests/ test-output.log, test-status.txt
review Agent Captured test output review.md, repair instructions
repair Agent Manager's instructions Fixed solution.py or nothing
verify Command tests/ final-test-output.log

每个智能体的提示词均声明“全新上下文，读取文件，不要依赖聊天”。这种账本纪律被归功于性能提升。最后一步是整个裁决，通过 Shell 脚本检查样本。

首次运行发现

以计算字符串 {a, b, c} 中每种字母计数相等的子串数量为例（长度不超过 200,000 字符）：

  • 8 个步骤全部完成，5 个样本全部通过。求解者采用了构思者 A 的前缀状态方法，时间复杂度为 O(N)。在 N = 200,000 时运行时间为 0.04 秒。
  • 曾因提供商断开流连接导致运行终止。现已增加 max_retries: 1 并通过 --partition 恢复运行，保留已有工作成果。
  • 早期构思者提示词命名了样本中的方法，可能误导其他问题。现已调整为要求 A 提供最直接的可证明算法，B 提供来自不同技术家族的算法（2026-10-28）。
  • 最初尝试曾报错“no agent named coder”，已在当天通过网关修复（v1.692.0）。