SiriuS: Self-improving Multi-agent Systems via Bootstrapped Reasoning

Paper: arXiv:2502.04780 Code: zou-group/sirius Code reference: main @ 16643cdc (2025-12-01)

1. Motivation

SiriuS要解决的是一个很具体的问题：多智能体系统虽然能通过分工协作提升复杂任务表现，但训练数据往往依赖手工提示、固定规则或人工标注，导致优化成本高、迁移性差，而且很难把“协作过程中产生的中间推理轨迹”转化成可复用训练集。论文关注的不是单体 LLM 的泛化，而是如何系统性地优化多智能体协作链路本身。作者认为，真正的瓶颈是“经验”而不是“模型容量”：如果能把成功轨迹保留下来，并把失败轨迹通过反馈修正后再回流成数据，就能形成一个自举式的 experience library，让后续的 agent fine-tuning 不再依赖人工逐条筛选。这个问题值得研究，因为一旦多智能体系统可以持续自我改进，就能在 reasoning、biomedical QA 和 negotiation 这类强依赖交互结构的任务里，把协作收益从一次性 prompt engineering 提升为可迭代的训练范式。论文对现有多智能体方法的批评非常明确：很多系统把 agent orchestration 设计得很复杂，但训练阶段仍然停留在“人工写 prompt + 固定 role description + 零样本运行”的范式里。这样做的直接后果是，系统表现高度依赖初始化提示词，角色之间的交互质量也几乎不会随着部署而变好。即便某次协作成功，成功原因通常也只存在于那一条对话轨迹里，没有被提炼成后续可复用的 supervision。

这类瓶颈在本文覆盖的三类任务里都很明显。对 College Physics / Chemistry 这类问题求解任务而言，单个 agent 常常会在早期推导里犯错，后续 agent 只能在错误前提上继续工作，导致“错误被链式放大”。对 PubMedQA 这类 biomedical QA，难点不只是选项判断，而是如何在较长上下文里提取证据、形成中间判断并压缩成最终答案。对 negotiation / competitive games，问题又变成策略交互不是静态 mapping，而是随着对手行为动态变化，单次成功策略未必能泛化到新初始条件。作者隐含提出的一个更强问题是：多智能体系统里真正值得学习的对象，到底是最终答案，还是协作过程本身？

如果答案只是一个 A/B/C/D 选项或一个成交价格，那么直接用终局 label 做监督会丢失绝大部分“为什么这一轮协作成功”的信息。SiriuS 的出发点正是认为，多智能体系统最宝贵的信号是中间消息序列、角色间依赖和失败后可被修复的 reasoning fragments，而不是单一最终 output。从训练范式角度看，这篇论文试图弥补 single-agent self-improvement 方法和真正 multi-agent optimization 之间的空白。STaR 一类方法核心是“模型自己生成推理，再把成功推理回灌”；COMM 强调多 agent 沟通结构；TextGrad 借用 textual feedback 改进输出。

但这些方法大多只覆盖某一侧：要么自举但不是多 agent，要么多 agent 但没有把交互过程系统转化成训练集。SiriuS 的动机恰好在于把这两个方向合并。

论文还强调了人工数据瓶颈的工程现实意义。如果每个 agent 都需要人工标注 demonstration、人工写 error analysis、人工编排 refinement 流程，那么 agent 数目一多，维护成本会线性甚至超线性增长。相比之下，自举式 experience library 的目标是让系统在已有任务流上运行时自然积累训练样本，这意味着新增 task family 时，不必完全从零开始构造专家数据。值得注意的是，作者并没有把问题表述成标准 RL 中的“在线探索和策略优化”，而是更像“离线经验蒸馏”。

这是因为本文关心的是 LLM multi-agent pipelines 在现有 API 和 SFT 生态下怎样落地自改进：系统先运行、再筛选、再增强、再监督微调。这个 framing 很务实，也解释了为什么 released code 主要围绕 JSONL 生成和 OpenAI fine-tuning job，而不是自定义 PPO / policy gradient 训练。因此，SiriuS 的研究价值不只是多一个 benchmark 分数，而是提出一个可操作的判断：当 multi-agent system 表现不足时，优先优化的对象不应只是 prompt template，而应是“经验资产化”流程。

谁产生了高价值中间步骤、哪些失败可通过 feedback 修复、哪些角色需要独立更新，这些问题才决定系统是否能持续改进。论文摘要和实验设定共同说明，作者希望解决的是一个“跨环境共享”的训练难题，而不是只在某个任务上做特化提分。因为 problem-solving、PubMedQA、actor-critic QA 和 negotiation 四类 setting 的奖励形态差异很大，如果同一套自改进框架仍然有效，就意味着被学习的对象更接近协作规律本身，而非某个单任务的标签结构。

这种动机也来自现有 multi-agent literature 的一个常见弱点：系统通常在 inference 时引入更多角色，但训练时仍默认这些角色共享同一种能力边界。SiriuS 明确反对这种假设，认为 physicist、critic、judge、seller 这些角色之所以存在，本来就是因为它们面对的局部决策问题不同；如果训练数据不保留这种差异，分工只会停留在 prompt wording，而不会沉淀为参数层面的 specialization。从数据经济性看，这篇论文关心的是如何把“昂贵的长轨迹”转化成“可重复使用的 supervision”。

多智能体系统一次运行要消耗更多 token、更多上下文传递和更多 orchestration 成本，如果这些运行结果只服务当前样本，边际收益会非常低。SiriuS 的 motivation 正是把这些已经付出的运行成本转成未来训练收益，让一次协作不仅回答一个问题，还顺带生产下一轮改进所需的数据。作者还在动机层面暗示了一个质量控制问题：多智能体交互比单模型 CoT 更容易出现错误传播，因为每个角色都会把前序输出当作条件。这样一来，坏样本不是简单的“答案错了”，而是可能在前半段就已经污染后续所有消息。

因此，仅靠最终 accuracy 做离线筛选不够，必须显式区分 good trajectory、wrong trajectory 和 repairable trajectory，才能避免把系统性错误回灌进训练集。换句话说，SiriuS 试图回答的是：怎样在不引入重型 RL 基础设施的前提下，让 multi-agent system 具备类似“越用越好”的性质。这个问题一旦成立，意义不仅在论文里的三个 benchmark family，也在任何依赖角色分工、阶段化推理和可验证 outcome 的 agentic workflow 上都有外溢价值。

2. Idea

核心想法是把多智能体交互看成“可筛选、可修复、可回灌”的轨迹生产过程：先收集完整交互，再保留成功 reasoning steps 作为高质量库；对失败轨迹则用反馈和重写进行增强，最后用这些库数据对各个 specialized agents 做监督微调。和 COMM / STaR 这类方法相比，SiriuS 的区别不是单纯换了 prompt 或加了 self-reflection，而是把“多智能体协作过程”本身当作训练数据来源，并且显式做库级别的过滤与增强。更具体地说，SiriuS 的核心 insight 是：多智能体系统的 improvement signal 不是均匀分布在所有消息上的。

成功轨迹里，真正有价值的是“在该角色可观测上下文下，这个 agent 给出了推动全局成功的那一步响应”；失败轨迹里，真正有价值的是“错误是如何被指出、如何被重写”的那一段局部修复过程。只要能把这两类局部高价值片段稳定抽出来，multi-agent training 就能从一次性运行变成可积累的 curriculum。论文的创新点可以拆成三层。第一层是 experience library 视角：把每个 task instance 的多轮协作都当作可以入库的 trajectory，而不是一次性 inference。

第二层是 bootstrapped augmentation：失败样本并不被直接丢弃，而是先用额外 agent 或 feedback prompt 生成 critique，再把 critique 条件化到 regeneration 上。第三层是 role-wise fine-tuning：不是训练一个统一大模型学会所有角色，而是让 physicist、mathematician、summarizer，或者 actor、judge、critic 各自从与自身职责对应的样本中学习。

这种设计和 STaR 的根本差异在于数据颗粒度。STaR 的基本单位通常是“问题 + 推理 + 正确答案”，对象仍是单模型；SiriuS 的基本单位则是“某个 agent 在前序 agent 输出条件下的局部决策”。也就是说，SiriuS 默认认为角色 specialization 是真实存在的，训练时也应保留这种分工结构，而不是把所有协作消息简单拼接后让一个模型统一拟合。它和 COMM 的差别则在于优化闭环。COMM 的重点在多 agent 通信能否提高一次任务性能；SiriuS 则进一步追问：这些通信内容能否在事后被转成 library，并在下一轮更新里反过来提升通信质量。换言之，COMM 更像“设计协作系统”，SiriuS 更像“让协作系统持续学习”。

它和 TextGrad 的差别也很清楚。TextGrad 把 textual feedback 当作优化信号，但目标更接近让单个模型在语言层面自我修订。SiriuS 则把 feedback 放进多 agent pipeline 里，并把 feedback 结果写回不同角色的独立训练文件。于是，feedback 不只是一次性的纠错提示，而成为后续 role-specific SFT 样本的来源。如果用一句话概括这篇论文的思想，可以写成：SiriuS 不是再造一个更聪明的协调器，而是把多智能体系统运行时自然产生的“成功协作模式”和“可修复失败模式”沉淀为训练资产，再用这些资产反过来更新参与协作的 agent 本身。

这个思路带来的一个重要后果是泛化机制发生了变化。传统 prompt engineering 的泛化主要来自 prompt 是否足够通用；SiriuS 的泛化则来自经验库是否覆盖了跨任务共享的局部协作规律，例如先提出物理直觉、再补数学推导、最后做答案压缩，或者先让 actor 产出候选、再让 critic 针对性指出漏洞。作者的结果表明，这类局部规律比最终答案模板更可迁移。论文因此把“bootstrapped reasoning”具体化成一种数据工厂，而不是一句抽象口号。系统先运行现有 agents 得到原始轨迹，再用 correctness 或 utility 把轨迹分层，随后只把高价值局部响应和经修复后的局部响应写回库中。

真正的新意不在于单次轨迹内部多了几个角色，而在于这些角色的交互被重复利用为下一轮训练监督。这也解释了为什么作者坚持 role-wise fine-tuning 而不是统一端到端蒸馏。若把所有消息拼成一个大样本交给单模型，模型可能学到表面话术，却不一定学到“某角色在某前序上下文下应承担什么责任”。SiriuS 的核心假设是，协作能力的可迁移单元不是完整对话，而是角色条件化后的局部决策分布。另一个关键 insight 是 augmentation 不只是“纠错”，而是“把失败转成可教样本”。错误轨迹本身不能直接监督，但错误轨迹配上 critique 和 rewrite 之后，就能暴露系统最缺失的能力边界。

于是 SiriuS 利用失败案例的方式，并不是把它们当负样本做判别学习，而是把它们加工成更贴近专家 demonstration 的正向 supervision。

如果拿 single-agent self-training 做对照，可以把 SiriuS 看成把自举单位从 question -> rationale -> answer 扩展成 task -> multi-agent interaction graph -> per-role demonstrations。这一步扩展看似只是数据格式变化，实则决定了系统能否保留协作结构、角色职责和错误修复链条这三类单模型范式里没有的信号。

3. Method

整体框架

SiriuS 的训练管线对应图 1：先运行基础 multi-agent system 采集轨迹，再按奖励/正确性筛选出 good trajectories，随后对坏轨迹做 augmentation，最后把整理后的 library 用于每个 agent 的 fine-tuning。

Figure 1 解读：上半部分是轨迹采集，系统先让多个 agents 顺序协作产生完整交互；中间的筛选模块保留成功轨迹并丢弃低质量片段；下半部分的 augmentation 模块会把失败样本变成可学习样本，再进入监督微调，从而形成闭环自举。

这个框架最关键的地方在于，论文把“运行时协作”和“训练时数据构造”完全打通了。普通多智能体 pipeline 往往只关心前半段，即如何让 agent 们完成当前样本；SiriuS 额外关心每个样本在运行完之后应该进入哪条数据路径：是直接进入 good library，还是先进入 wrong set，再被 feedback 和 regenerate 模块转化为新 supervision。也正因为如此，SiriuS 的核心不是某个更复杂的 coordination algorithm，而是一个围绕 trajectory lifecycle 组织的训练流水线。从代码实现看，这个“整体框架”并不是抽象口号。

Problem_solving/PhyChem/get_a_sol.py 负责生成初始多 agent 轨迹，并同时写入 sol、correct、wrong 三类日志；get_b_feedback.py 针对 wrong 轨迹生成反馈；get_c_regenerate.py 用反馈重写答案并重新判断是否修复成功；fine_tune.py 再把每个角色对应的 JSONL 提交到独立 fine-tuning job。论文里的四阶段图在 released code 里几乎就是四类脚本。一个重要直觉是：SiriuS 不把失败轨迹视为噪声，而把它视为“尚未完成清洗的潜在训练数据”。

如果直接丢弃失败样本，系统只能从 already-good demonstrations 学习，数据效率会很差；如果无差别保留失败样本，又会污染 SFT。作者选的中间道路是先判错、再反馈、再重写，只把可被修复成高质量示范的部分送回库中。从 Figure 1 的信息流看，SiriuS 实际上同时维护了两种数据转换。第一种是 success path：把成功任务中的原始角色响应直接抽成 demonstration；第二种是 repair path：把失败任务变成 错误响应 -> critique -> regenerated response 的链式样本。前者提供高精度信号，后者补足覆盖率，两条路径合并后才形成可持续扩张的 experience library。

这一设计的关键取舍在于，作者并没有尝试学习一个统一的“元协调器”来在线调度所有角色，而是把优化重心放在离线库构建。原因很直接：只要库中样本质量持续提高，下一轮即使仍用同样的 orchestration 结构，局部角色策略也会变得更强。也就是说，SiriuS 的 improvement locus 是 per-role policy quality，而不是 runtime controller complexity。 Method 部分还隐含一个重要前提：任务必须至少提供某种可验证 outcome，用来决定哪些轨迹能进入 good set。对 physics / chemistry 是最终答案正确性，对 PubMedQA 是 yes/no/maybe 分类正确性，对 negotiation 则是 utility 或 win rate。SiriuS 因此不是无条件适用于所有开放式 agent conversation，而更适用于那些虽然推理链复杂、但 outcome 仍可比较或可打分的 agentic task。

多智能体形式化

论文把系统写成 $⟨ S, A, T, R, N, G ⟩$ ： $N$ 个 agents 通过有向图 $G = (V, E, P)$ 组织，状态转移由 $T$ 给出，奖励由 $R_{i} : S \times A \to R^{N}$ 给出。这里的关键不是 RL 的经典探索，而是把“协作链路”显式建模成图结构，方便不同任务切换角色和通信路径。这个形式化的价值在于把不同任务统一到同一抽象下。对 problem-solving，图结构是 Physicist -> Mathematician -> Summarizer；对 actor-critic，是 Actor -> Judge -> Critic -> Actor(regenerate)；

对 competitive games，则对应两个玩家在若干 turn 中交替行动。论文因此不需要为每个 setting 单独发明训练原则，而是只要求：系统能够输出可分解到各角色的轨迹，且存在某种 reward / correctness 信号来判定哪些局部片段值得保留。图中的 $P$ 可以理解为 message passing 规则，也就是某个 agent 在调用时到底能看到哪些前序消息。这个点很重要，因为 SiriuS 不是对“裸输入到输出”做学习，而是对“带有前序协作上下文的局部响应”做学习。一个 physicist 的好回答，不等于一个 summarizer 的好回答；

同样，critic 的训练样本也必须看到 actor 与 judge 的中间结果，否则就学不到真正有针对性的反馈。如果从监督学习角度重写这套形式化，实际每个 agent 学习的是条件分布： $π_{θ^{(n)}} (a^{(n)} ∣ x, a^{pre (A^{(n)})}),$ 其中 $x$ 是当前任务输入， $a^{pre (A^{(n)})}$ 是图中前驱 agent 的输出。SiriuS 的 role-wise fine-tuning 本质上是在不同条件上下文下分别拟合这些局部策略，而不是学习一个单一 joint policy 去同时扮演所有角色。

这个形式化还有一层含义：同一个输入 $x$ 在不同角色视角下对应的是不同学习问题。physicist 需要生成可供后续建模的物理直觉，mathematician 需要把前一步分析转成方程推导，summarizer 则需要压缩并校准最终答案格式；judge 关注是否正确，critic 关注为什么错以及怎样改。SiriuS 用图结构把这些差异显式保留下来，避免在统一训练目标里被平均掉。

经验库构建

经验库的核心数据单位是 reasoning trajectory。论文的筛选逻辑是把产生成功结果的 reasoning step 直接保留下来，形成 good trajectory set；对失败样本，则先做 feedback，再做 regeneration 或 rewriting，使其尽量接近可监督学习格式。这一步很重要，因为多智能体系统里最有价值的信息通常不在最终答案，而在“谁在什么上下文下给了什么中间判断”。如果只保留 final output，库会退化成普通 SFT 数据，失去协作知识。论文里的 experience library 不是一个无结构 memory dump，而是按角色和任务类型组织的样本集合。

对 problem-solving，库中既有 physicist 的初步物理分析，也有 mathematician 的形式化求解，还有 summarizer 的最终归纳；对 actor-critic，则分别保存 actor 的回答、judge 的判断、critic 的反馈以及基于反馈的重写。这样的好处是每个角色在 fine-tune 时都能看到“和自己职责同分布”的训练样本，而不是混杂的全局对话。从 released code 也能看出这种角色分桶策略。fine_tune.py 会遍历 physicist、mathematician、summerizer 三个 agent，并读取 finetune_{agent.name}.jsonl 分别提交训练；

fine_tune_critic.py 也会为 feedback、judge、actor 生成独立 job。这说明论文里的 library 在落地时并非单一数据库，而更接近一组 per-role curated datasets。经验库构建还有一个隐含选择：保留的是“局部正确步骤”还是“完整成功轨迹”。从论文描述和代码行为看，SiriuS 更偏向完整轨迹下的局部响应抽取。也就是说，先判断一条样本最终是否正确，再从中抽出对应角色在该上下文中的消息作为 demonstration。这种做法虽然可能错过某些“局部有用但全局失败”的片段，但能更稳地控制监督信号质量。

这个设计也解释了为什么作者强调 successful trajectories。对于 multi-agent chain，后续 agent 的表现往往强依赖前序上下文；如果前序 agent 已经偏离正确思路，那么即便后续 agent 给出表面上合理的话，也未必是值得学习的 response。SiriuS 因此优先信任全局成功样本，把它们看成高置信度 demonstration，再把失败样本交给 augmentation 流程额外处理。可以把 experience library 理解成一种“结构化蒸馏缓存”。它缓存的不是静态 labels，而是经过任务验证的协作模式：什么样的物理分析有助于后续推导，什么样的 critique 能真正促成 actor 修正，什么样的议价响应在新资源配置下仍然有效。正是这些模式，而不是单纯的最终答案，构成了 SiriuS 的可迁移知识。论文在这里最值得注意的，不是简单声称“成功样本更好”，而是把成功样本进一步切分到角色级 supervision。这样做会丢掉部分全局对话纹理，但换来一个更稳定的训练接口：每个 agent 的数据格式、职责边界和优化目标都更清晰。对于依赖 API fine-tuning 的 released implementation，这种 role-bucketed library 比维护一个超长多角色对话数据集更可操作。

迭代训练

Algorithm 1 的流程是：在第 $t$ 次迭代，针对每个 agent 生成轨迹 $a_{i}^{(n)} \sim P_{θ_{t}^{(n)}} (\cdot ∣ x_{i}, a_{i}^{pre (A^{(n)})})$ ，筛出满足奖励阈值 $ϵ$ 的样本进入 good set，再对失败样本做 augmentation，最后用整理后的库继续 fine-tune。

更形式化地写，论文的迭代过程可以概括为三步： $G_{t}^{(n)} = {(x_{i}, a_{i}^{(n)}) ∣ R_{i}^{(n)} > ϵ},$ $B_{t}^{(n)} = Augment ({(x_{i}, a_{i}^{(n)}) ∣ R_{i}^{(n)} \leq ϵ}),$ $θ_{t + 1}^{(n)} = SFT (θ_{t}^{(n)}, G_{t}^{(n)} \cup B_{t}^{(n)}) .$ 第一步从当前策略生成样本并打分；第二步把低分轨迹通过 feedback / rewrite 变成更高质量样本；第三步用 good set 与 repaired set 的并集继续更新第 $n$ 个 agent。这里最值得注意的是， $B_{t}^{(n)}$ 不是原封不动的失败集，而是经过 transformation 之后的新 supervision。

这种迭代训练和传统 RL 最大不同在于更新算子是 SFT 而不是 policy gradient。论文的“self-improving”并不意味着在线 credit assignment，而是意味着系统可以周期性地产生新训练数据、再把数据喂回模型。对当下依赖 API model 的实际工程环境，这比要求可微分 rollout 或 token-level reward 更现实。

def sirius_iteration(agents, data, thresholds, generate, augment, finetune):
    good_sets = {agent.name: [] for agent in agents}
    library = []
 
    for x in data:
        traj = generate(agents, x)
        for agent in agents:
            if reward(traj, agent) > thresholds[agent.name]:
                good_sets[agent.name].append((x, traj[agent.name]))
            else:
                library.extend(augment(x, traj[agent.name], agent))
 
    for agent in agents:
        finetune(agent, good_sets[agent.name] + library)

这段伪代码抓住了 Algorithm 1 的主干，但还有两个实现细节值得补充。第一，代码里 good_sets 与 library 实际上往往是分文件写出的，而不是在内存里统一保存；因为 released implementation 假设会通过外部 fine-tuning API 读取 JSONL。第二，失败样本进入 augment() 后，产物并不一定回到原 agent 同一个数据桶里，而是可能分配给 feedback/judge/actor 等不同角色的训练文件，这体现了多角色增强而非单角色重写。一个直觉解释是：SiriuS 通过阈值 $ϵ$ 做的是 sample selection，而通过 augmentation 做的是 sample repair。前者控制精度，避免把明显错误轨迹直接送进 SFT；后者控制召回，避免浪费所有错误轨迹。两者配合，才让自举训练既不过分保守，也不过分噪声化。从学习动态看，这种迭代还有一个重要效果：随着 agents 逐轮变强，进入 good set 的样本分布也会改变，系统因而会不断接触到更难、但仍可修复的失败模式。SiriuS 的自举不是一次性把错误改对，而是让训练库的难度和多样性随模型能力同步上升，形成一种近似 curriculum 的扩展过程。

Problem-solving setting

Problem-solving 里用的是 Physicist + Mathematician + Summarizer 的链路。README 里的 driver 显示轨迹先由 Problem_solving/PhyChem/get_a_sol.py 生成，再由 get_b_feedback.py 和 get_c_regenerate.py 做失败样本修复，最后送入 fine_tune.py。

def collect_problem_solving_traces(question, physicist, mathematician, summarizer):
    a = physicist.call_agent(physicist_prompt(question), question, temperature=0.0)
    b = mathematician.call_agent(math_prompt(question, a), question, temperature=0.0)
    s = summarizer.call_agent(sum_prompt(question, a, b), question, temperature=0.0)
    return {"phy": a, "math": b, "sum": s}

Figure 1 的对应实现思路是顺序依赖：前一个 agent 的输出会进入后一个 agent 的 prompt，因此系统不是简单投票，而是带上下文传递的分工推理。

这一设定的 intuition 很直接：对 college-level science questions，正确求解通常需要“先建立物理/化学直觉，再进行数理计算，最后把冗长推理压缩成标准答案格式”。如果让单个 agent 一步完成三件事，很容易同时在概念建模、计算细节和答案格式上出错。SiriuS 则把这些环节拆给不同角色，从而把错误暴露在更早阶段，也让后续 fine-tuning 更容易聚焦到单一职责。从脚本组织看，get_a_sol.py 既负责多 agent 推理，也负责按是否正确写出 correct 与 wrong 日志；get_b_feedback.py 会针对错误样本生成批评或补充说明；

get_c_regenerate.py 读取这些反馈，再尝试重写答案并重新评估正确率。也就是说，problem-solving setting 里的 augmentation 不是抽象的“数据增强”，而是显式的“先让系统指出哪里错，再让系统基于错误解释重答一次”。这种流程的优点是能够把失败样本转化成两类训练信号。第一类是 feedback agent 的示范：在看到原始错误轨迹后，怎样写出有效 critique。第二类是 regenerate 后的新正确轨迹：在带有 critique 的条件下，怎样给出改进后的推理。作者实际上在一条失败样本上榨取了两层监督信息，而不是只保留最终修复后的答案。

另一个细节是问题求解 setting 的 role dependency 非常强。Mathematician 的 prompt 依赖 Physicist 的初步分析，Summarizer 的 prompt 又依赖前两者输出。因此，若 Physicist 阶段质量提升，后两者得到的上下文也会同步改善。这解释了为何 per-role fine-tuning 即使只直接更新某一角色，也可能间接提高整条链路的端到端表现。

Actor-Critic setting

Actor-Critic 设定里有 actor、judge、critic 三个 agent。代码侧的 Actor_Critic/agent.py 定义了统一的 call_agent 和 fine_tune 接口，fine_tune_critic.py 会把三个 agent 分别写成独立的 JSONL，再分别提交 OpenAI fine-tuning job。

def actor_critic_loop(actor, judge, critic, x):
    answer = actor.call_agent(actor_prompt(x), x, temperature=0.0)
    judgment = judge.call_agent(judge_prompt(x, answer), x, temperature=0.0)
    feedback = critic.call_agent(critic_prompt(x, answer, judgment), x, temperature=0.0)
    if is_failed(judgment):
        answer = actor.call_agent(regen_prompt(x, answer, feedback), x, temperature=0.0)
    return answer, judgment, feedback

论文公式与 released code 实现差异：论文把 augmentation 描述成统一的库增强流程，但代码实际上是按任务目录分别生成训练集文件，再用 OpenAI fine-tuning API 分别提交每个 agent 的训练任务；也就是说，论文抽象的是算法层，released code 落地的是按 JSONL 文件驱动的监督微调流水线。这个 setting 和经典 RL 里的 actor-critic 名字相同，但语义并不完全相同。这里的 judge 更像 correctness detector，critic 更像 natural-language error explainer，而不是 value function estimator。

SiriuS 借用了 actor-critic 结构中的“先行动、再评估、再纠偏”逻辑，但最终更新方式依然是监督微调。理解这一点很重要，否则容易误以为论文实现了某种基于 critic reward 的梯度更新。在这个 setting 中，judge 和 critic 的分离是方法设计的关键。若让一个 agent 同时负责判对错和给修改建议，错误检测与错误解释会耦合在一起，导致监督信号不稳定。SiriuS 把二者拆开：judge 先输出是否正确，critic 再围绕错误原因提供更细粒度反馈，最后 actor 在 regeneration 阶段吸收这些反馈。这种分工实际上把 failure repair 拆成了 detection 和 correction 两步。

从 released code 来看，fine_tune_critic.py 明确会为 feedback、judge、actor 分别构建 finetune_*.jsonl 并提交 job，这说明作者不是只想让 actor 更会重答，而是希望 judge 更会判错、critic 更会给建议。也就是说，SiriuS 在 actor-critic setting 中优化的是整个纠错生态，而非单个输出模型。为什么这种结构有效？直觉上，很多 LLM 错误并非“完全不会”，而是初答时没有触发正确约束。judge 负责把错误显性化，critic 负责把“应该如何修”语言化，actor 再根据这些线索生成第二次答案。

于是，系统学到的不只是最终正确答案，还有一套把错误逐步拉回正确轨道的协作模式。

Competitive setting

竞争场景包括 Resource Exchange、Ultimatum、Sell&Buy。Table 2 说明每个任务都定义了明确的角色、初始资源、目标和效用函数，例如 Ultimatum 用 $100 的 split、Sell&Buy 用价格最大化/最小化。这一 setting 很能体现 SiriuS 与普通 QA 自举的不同，因为这里的 reward 不是静态正确率，而是由双方互动结果决定的 utility。也就是说，轨迹质量不仅取决于“我说得是否像标准答案”，还取决于对手如何回应、局面如何演化、最终 payoff 是否提高。SiriuS 之所以还能适用，是因为它只要求存在可观测 outcome，并不要求 reward 必须是单步可微或文本可比对的。

Resource Exchange 中，玩家持有不同资源并有不同目标，协商是否交换；Ultimatum 中一方提议分钱方案，另一方选择接受或拒绝；Sell&Buy 中双方围绕价格持续谈判。三者共同点是都包含角色专属目标、回合式交互和 outcome-driven evaluation，因此都能自然产出“成功协商轨迹”和“失败协商轨迹”。在这一类任务里，experience library 学到的不是某个标准句式，而更像 negotiation policy 的语言化版本。例如什么时候应该坚持高价、什么时候应当让步、在对方资源结构变化后怎样重构报价。

这也是为什么论文特别做了 changed setting 的泛化实验：作者想验证 SiriuS 学到的是策略模式，而不是对固定初始配置的过拟合。

图 5 和图 6 对应的是资源交换和 Seller&Buyer 的泛化测试。图 5 显示在新初始资源配置下，fine-tuned 的策略仍能维持较高 win rate 和 payoff；图 6 则说明 seller 经过前一配置训练后，在 30/70 新配置里仍然能逼近公平定价，说明不是简单记忆 50。

Figure 5 解读：左侧是 decisive games 的 win rate，右侧是 all games 的 payoff；SiriuS 训练后的 player 2 在多个格点上优于 GPT-3.5 / GPT-4o-mini，表明经验库能迁移到新的初始资源分布。

Figure 6 解读：在 seller-buyer 任务中，训练后 seller 的成交价更稳定地靠近 50，说明模型学到的是更优的议价策略，而不只是拟合单一设置。

竞争 setting 还有一个值得强调的点：这里没有一个像 physics answer 那样的唯一 gold response，因此 augmentation 的意义更偏向“保留高 payoff interaction pattern”。这让 SiriuS 的适用范围超出传统有标准答案的 reasoning task，也说明作者真正关心的是多 agent 轨迹能否作为训练资产，而不是 task label 形式本身。

代码到论文映射

Code reference: main @ 16643cdc (2025-12-01) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
Multi-agent graph / role chaining	`Problem_solving/PhyChem/agent.py`	`physicist`, `mathematician`, `summarizer`
Trajectory collection	`Problem_solving/PhyChem/get_a_sol.py`	task driver
Feedback extraction	`Problem_solving/PhyChem/get_b_feedback.py`	feedback driver
Failed-trajectory regeneration	`Problem_solving/PhyChem/get_c_regenerate.py`	regeneration driver
Fine-tuning on library	`Problem_solving/PhyChem/fine_tune.py`	`fine_tune()`
Actor/Judge/Critic loop	`Actor_Critic/agent.py`	`Agent.call_agent()`
Critic feedback/regeneration	`Actor_Critic/get_critic_feedback.py`, `Actor_Critic/get_critic_judegement.py`, `Actor_Critic/get_critic_regenerate.py`	feedback / judgment / regeneration drivers
Critic fine-tuning	`Actor_Critic/fine_tune_critic.py`	`fine_tune()`
Competitive negotiation games	`Competitive/NegotiationArena/games/ultimatum/game.py`	game logic
Buy/Sell pipeline	`Competitive/NegotiationArena/buysell_main.py`	task driver
Library merge / filtering	`libs/merge.py`	merge utility

4. Experimental Setup

数据集

College Physics / College Chemistry：由 MMLU、GPQA、TheoremQA 组合而来；论文说明这里按训练/测试集划分，Appendix 给出更细分布。
PubMedQA：1000 个 open-domain biomedical questions，论文使用原始 split 的训练 500 / 测试 500。
Competitive tasks：Resource Exchange、Ultimatum、Sell&Buy。

Baselines

Single-Agent
STaR
COMM
TextGrad

Metrics

Accuracy(%): 问答任务的正确率。
Win rate: 竞争任务中获胜比例。
Payoff: 竞争任务中的效用回报。

训练配置

Backbone model：代码通过 args.model 指定，README 示例里使用 gpt-3.5-turbo。
推理温度：代码 temperature=0.0。
生成上限：max_tokens=5500。
Fine-tuning：通过 OpenAI Fine-tuning API 逐个 agent 提交 JSONL 数据。
轮询间隔：60s 检查 fine-tuning job 是否完成。
论文未详细说明 GPU、训练步数和 batch size；released code 主要是 API 驱动的外部微调流程，而不是本地训练脚本。

这里需要特别注意一个复现层面的事实：论文在方法叙述上看起来像统一训练算法，但 released code 的训练配置实际上被拆散在各个 task 脚本里，通过 args.model、不同日志目录和不同 finetune_*.jsonl 文件控制。也就是说，严格意义上并不存在一个集中式 config.yaml 列出所有超参数；能确认的稳定实现细节主要来自脚本中的 API 调用、temperature、token budget、job polling 与数据文件命名规则。

因此，这篇笔记里关于训练配置的结论应理解为“released code 可核实到的 SFT pipeline 配置”，而不是传统开源训练项目里那种完整的本地训练 recipe。对希望复现论文数字的人来说，最大的依赖不是 GPU 设置，而是外部 API model 版本、生成数据质量以及后续 fine-tuning job 的可重复性。

5. Experimental Results

主结果

Table 3 的 exact numbers：

Model	Method	College Physics	College Chemistry	PubMedQA
GPT-3.5-turbo	Single-Agent	24.30	38.46	56.40
GPT-3.5-turbo	STaR	29.91	47.69	63.80
GPT-3.5-turbo	COMM	30.84	50.77	71.80
GPT-3.5-turbo	TextGrad	32.71	41.54	NA
GPT-3.5-turbo	SiriuS	33.64	56.92	74.20
GPT-4o-mini	Single-Agent	39.25	41.54	67.40
GPT-4o-mini	STaR	42.06	47.69	69.20
GPT-4o-mini	COMM	42.06	49.23	70.60
GPT-4o-mini	TextGrad	42.99	44.62	68.20
GPT-4o-mini	SiriuS	46.73	60.00	73.40

SiriuS 在三个 reasoning / QA 基准上都优于对应 backbone 的所有 baseline；提升最明显的是 College Chemistry 和 PubMedQA，说明经验库对需要中间推理的任务更有效。

Actor-Critic 结果

Table 5 的 exact numbers：

Model	Method	TP Accuracy	Overall Accuracy
GPT-3.5-Turbo	Self-Correct	11.80	16.40
GPT-3.5-Turbo	Prompt	18.40	47.60
GPT-3.5-Turbo	SiriuS	35.00	50.60
GPT-4o-mini	Self-Correct	24.60	28.80
GPT-4o-mini	Prompt	51.60	58.20
GPT-4o-mini	SiriuS	59.80	66.80

这张表说明 SiriuS 不只是提升最终答案正确率，也能显著提高触发正确修正的局部推理片段质量，尤其是 GPT-4o-mini 上的整体准确率提升更明显。

竞争任务

论文的竞争结果不在 Table 6；Table 6 实际是 dataset split statistics。竞争设置的主要结果见 Figure 5 / 6：在 Resource Exchange 里，Player 2 在 35Xs + 15Ys vs 15Xs + 35Ys 的新初始配置下，SiriuS-GPT-3.5 和 SiriuS-GPT-4o-mini 的 win rate / payoff 都优于对应 base LLM；在 Sell&Buy 里，seller 经过前一配置训练后，在 30/70 新配置下仍能把成交价稳定拉回更合理区间，说明学到的是可迁移的议价策略而不是记忆固定报价。

Figure 5 的 exact results 如下（行列顺序均为 GPT-3.5、SiriuS-GPT-3.5、GPT-4o-mini、SiriuS-GPT-4o-mini）：

Player 2 Win Rate	GPT-3.5	SiriuS-GPT-3.5	GPT-4o-mini	SiriuS-GPT-4o-mini
GPT-3.5	0.86	0.90	0.89	1.00
SiriuS-GPT-3.5	0.54	0.68	0.57	0.80
GPT-4o-mini	0.00	0.00	0.20	0.86
SiriuS-GPT-4o-mini	0.00	0.00	0.00	0.57

Player 2 Payoff	GPT-3.5	SiriuS-GPT-3.5	GPT-4o-mini	SiriuS-GPT-4o-mini
GPT-3.5	2.36	4.72	2.72	1.80
SiriuS-GPT-3.5	0.72	3.52	0.88	3.28
GPT-4o-mini	-0.48	0.00	-0.80	1.20
SiriuS-GPT-4o-mini	-1.20	0.00	-2.80	0.36

数据增强统计

Table 7：

GPT-3.5-turbo：College Physics 108.93%，College Chemistry 157.78%，PubMedQA 13.09%，Actor-Critic 136.46%
GPT-4o-mini：College Physics 38.89%，College Chemistry 63.79%，PubMedQA 12.85%，Actor-Critic 14.94%

这些数值说明增强的收益在 problem-solving 和 actor-critic 上差异很大，体现出不同任务对失败轨迹修复的可学习性并不相同。更细地看，GPT-3.5-turbo 在 College Chemistry 与 Actor-Critic 上的增幅尤其大，说明较弱 backbone 更依赖 augmentation 提供的额外监督；而 GPT-4o-mini 在 PubMedQA 上只有约 12% 左右提升，意味着当原始多 agent pipeline 已经具备较强抽取和判断能力时，失败样本中可被修复并转化为高价值样本的比例会下降。换言之，augmentation 的边际收益与 backbone 初始能力密切相关。这组统计还支持论文的一个隐含判断：失败轨迹并不是均匀有用的。有些任务中的失败可以被 feedback 有效修正，因此扩充出大量新样本；有些任务中的失败则更像根本性理解偏差，即便重写一次也未必能转成稳定 supervision。SiriuS 的优势在于它至少提供了一个把这类差异显性化的框架。

局限性

论文未系统讨论计算成本、标注成本和不同 backbone 上的收敛稳定性；从代码看，方法仍依赖外部模型 API、长时间轮询 fine-tuning job，并且需要任务级别的数据整理。

结论

SiriuS 证明了一个实用结论：多智能体系统的优化重点不只是 prompt 设计，而是把协作轨迹变成可迭代训练数据。它把“成功经验保留 + 失败经验修复”组合成闭环，确实能提升 reasoning、biomedical QA 和 negotiation 三类任务的表现。

Paper Notes

探索

SiriuS: Self-improving Multi-agent Systems via Bootstrapped Reasoning

SiriuS: Self-improving Multi-agent Systems via Bootstrapped Reasoning

1. Motivation

2. Idea

3. Method

整体框架

多智能体形式化

经验库构建

迭代训练

Problem-solving setting

Actor-Critic setting

Competitive setting

代码到论文映射

4. Experimental Setup

数据集

Baselines

Metrics

训练配置

5. Experimental Results

主结果

Actor-Critic 结果

竞争任务

数据增强统计

局限性

结论

目录