一、引言Agent0 是什么我为什么要在笔记本上复现它大模型的能力提升长期卡在「高质量数据」这道坎上。OpenAI o1、DeepSeek-R1 证明了强化学习能显著提升推理能力但它们都需要海量标注数据做冷启动。Agent0aiming-labarXiv:2511.16043给了一个更激进的答案零数据。它不依赖任何人工标注而是从同一个基座模型初始化出两个 Agent让它们互相「施压」、螺旋进化——一个负责出题一个负责做题全程不需要人类介入。让我决定动手复现它的是它把「工具集成」和「自进化」这两个我一直关注的方向拧在了一起传统的 RL 训练让模型「想得更对」Agent0 更进一步让模型「用工具想得更远」——正是代码解释器让做题的 Agent 突破了自己权重里固化的知识上限。但摆在面前的是一个很现实的问题我手头只有一台 Windows 笔记本4GB 显存。论文用 Qwen3-8B 8×80GB GPU 训练我连它一个推理服务都起不来。于是我换了个目标不追求复现论文的 18% 提升数据而是验证「协同进化流程在替换工具集之后到底能不能跑通」。这篇文章记录的是整个过程——包括那些让我撞墙的环境坑以及最终跑通的那一刻。二、原理解析双 Agent 协同进化 工具集成推理先花一点篇幅把机制讲清楚这是后面所有改造的坐标系。2.1 两个 Agent一个飞轮Agent0 从同一个基座模型论文用 Qwen3-8B-Base初始化出两个 Agent角色职责训练算法Curriculum Agent出题者 π_θ生成恰好卡在 Executor 能力边界的前沿任务GRPOExecutor Agent做题者 π_φ用工具求解任务ADPO协同进化的飞轮是这样的关键点在于工具集成是这个飞轮的引擎。如果没有工具Executor 很快会触及模型权重的知识天花板任务复杂度也上不去有了代码解释器Executor 才能持续突破。2.2 两个 Agent 的奖励设计为什么「出题」也要学Curriculum 用 GRPO但奖励很讲究——它要的不是「越难越好」而是「恰到好处的难」不确定性奖励R_unc 1 − 2|p̂ − 0.5|奖励 Executor「半懂不懂」的任务p̂ 是自一致性分数p̂0.5 时 Executor 最纠结奖励最高。工具使用奖励R_tool奖励能促使 Executor 调用代码解释器的任务。重复惩罚R_rep用 BLEU 聚类去重防止出题者偷懒重复。Executor 用 ADPO对 GRPO 的改进作者为应对「伪标签噪声」专门设计的模糊度感知优势缩放对高模糊度任务降低训练信号权重模糊度调制信任域对模糊任务放宽裁剪上界。我理解这套设计的内核是出题者追求「让做题者恰好处于最近发展区」做题者则要学会在「答案不确定」的任务上别太自信。这是一对很优雅的共生关系。2.3 工具交互协议改造的靶心Executor 调用工具的方式很朴素就是一段多轮交互整个轨迹被拼成[t₁ ⊕ c₁ ⊕ f₁ ⊕ ... ⊕ o]任务、代码、回传、最终答案。我要改造的就是中间这段「工具」的定义和调用协议。三、改造过程那些让我撞墙的坑这是本文的重点——一个「理论上可行」的想法落到一台 4GB 显存的 Windows 笔记本上会经历什么。3.1 环境坑vLLM 根本装不上第一步当然是 clone 仓库、看依赖。requirements.txt赫然写着这三样全部是 Linux CUDA 专属Windows 上无法安装。而训练脚本需要conda python 3.12我本机是 3.13。更别说论文的 8B 模型训练要 8×80GB GPU——我 4GB 显存连它一个 fp16 推理~16GB都塞不下。决策彻底放弃本地 RL 训练把目标收敛为「用 transformers 1.5B 小模型跑通『工具集成推理』这条改造验证链路」。这正好命中了一个核心判断——改造的正确性不一定非要靠跑完整训练来证明。3.2 模型下载ModelScope 快 10 倍1.5B 模型 ~3GB我一开始想当然地用 huggingface.co 直连结果连不上。换 hf-mirror能连但只有 ~380KB/s算下来要 2 小时。最后换ModelScope阿里魔搭Qwen 官方镜像实测 ~3.6MB/s快 10 倍15 分钟下完。这个坑的教训是在国内做 Qwen 系模型ModelScope 是默认首选不是备选。3.3 API 兼容transformers 5.x 的破坏性变更装好环境跑起来先撞上一个 API 变更。transformers 5.x 里torch_dtype参数被弃用要改用dtypetrust_remote_code从from_pretrained的显式签名里移除了。前者只是警告后者直接报错。好在 Qwen2.5 是原生架构、不需要 remote code去掉这个参数就过了。教训用新版库时别拿旧教程的代码照抄先inspect.signature看一眼。3.4 工具适配层一个 workspace 缓存 bug 裸 JSON 解析真正的改造在这把 Executor 的代码解释器换成 WorkBuddy 工具集。原项目的工具基类在verl_tool/servers/tools/base.py我照着它写了workbuddy_tools.py继承BaseToolregister_tool注册暴露read_file / write_file / list_directory三个操作严格遵循标准契约conduct_action(trajectory_id, action, extra_field) - (observation, done, valid)每个 trajectory 一个独立沙箱 workspace含越界路径防护。跑单元测试时抓到一个真实的 bug基类load_env不会把新建的 env 写回缓存导致同一个 trajectory 的两次调用拿到不同的 workspace——文件写进去了第二次读却读不到。修法是在load_env里创建 workspace 后立即self.env_cache[trajectory_id] env。然后是推理验证时发现的一个小模型通病1.5B 经常不按tool_call.../tool_call包裹直接甩一个裸 JSON{name: read_file, ...}导致解析器没识别到、工具根本没执行。我加了一层「裸 JSON 兜底解析」扫描配平的{...}片段问题解决。这两个坑的价值在于它们不是理论问题是「真实模型输出」和「理想接口假设」之间的落差——只有真跑起来才会暴露。3.5 关于「真实 WorkBuddy 后端」的一个诚实判断有人会问你workbuddy_tools.py里那三个_run_read_file/_run_write_file/_run_list_directory是不是只是本地模拟有没有接上「真实 WorkBuddy API」这里需要澄清一个事实WorkBuddy 的「文件读写 / 命令执行 / 文档生成」是 Agent 自身的内置能力其底层就是对本地文件系统的操作等价于open()/os.listdir()/ 子进程执行。它并不存在一个独立的、可被任意 Python 进程通过 HTTP 调用的「WorkBuddy 文件 API」。WorkBuddy 另有一个云后端workbuddy_cloud_service对标 Supabase但那是面向「已发布应用」的云对象存储/数据库与本地文件读写是两回事。所以对这个「在本地 workspace 读写文件」的场景最忠实的『真实 WorkBuddy 本地文件系统适配器』就是直接操作真实目录。我给工具加了一个root_dir真实模式不沙箱化到 tmp而是直接读写用户指定的真实目录越界防护依然生效。我用它在一个真实目录上完成了 list → read → write 的闭环并用os层独立读盘校验确认写进去的是真实文件、越界写入被拦。这就证明这套工具不止能在沙箱里转在实际应用层的真实文件系统上同样跑通。四、实验对比数学任务 vs 文档任务改造的第二部分是把 Curriculum 的出题 prompt 从「数学竞赛题」换成「文档处理任务」。4.1 Prompt 迁移数学基线原项目dataset.py/question_generate.py里硬编码的 system promptYou are an expert competition-math problem setter. ... outputquestion.../question\boxed{final_answer}迁移后的文档任务 promptYou are an expert at designing document-processing tasks that must be solved with file-system tools (read_file / write_file / list_directory). ... outputtask.../taskanswer.../answer格式对照数学基线文档处理迁移后出题 promptcompetition-math problem setterdocument-processing task designer任务标签question.../questiontask.../task答案标签\boxed{final_answer}answer.../answer正确性判分mathruler 精确判等token 重叠占位生产建议 LLM-as-judge4.2 工具调用成功率对比真实数据我在本地用 Qwen2.5-1.5B-Instruct 跑了「Curriculum 出题 → Executor 工具调用」的循环验证。结果分三个阶段非常能说明问题① 英文 Executor prompt工具调用 0%我一开始让 Executor 用英文 system prompt 引导工具调用结果 3 轮全部失败——模型只是输出了一段「我会先读取文件……」却一次tool_call都没发。1.5B 小模型对 prompt 的语言和具体性极度敏感。② 中文 具体示例 prompt工具调用 100% 触发把 Executor 的 system prompt 换成中文、并给出具体的工具格式示例后5/5 轮全部成功触发工具调用轮次任务复杂度识别到的操作工具调用1read / write / extractlist_directory ×1绝对路径被拦2extractlist_directory read_file ×23write / summarize / extractlist_directory read_file ×2③ 补齐「文件约定」后端到端完整闭环上面三轮还暴露了一个真正的工程问题Curriculum 生成的任务引用了products.txt、data_files/transactions.txt等不存在的文件导致 Executor 的read_file大量返回 File not found。根因是——Curriculum 和 Executor 之间缺少「共享工作区文件」的约定。我把 Executor 工作区的真实文件清单告知 Curriculum 后立刻跑出了完整闭环这条闭环证明了改造的核心假设成立把 Executor 的代码解释器换成 WorkBuddy 文件工具集后「出题 → 工具调用 → 多轮求解 → 写回结果」的协同进化流程逻辑上是跑得通的。同时也要如实记录三个 1.5B 小模型的局限数值算错sales.txt 三项加起来正确值是 $8400450026001300模型写了 $10700——1.5B 的算术能力弱多轮后格式漂移工具调用 3-4 轮后模型开始输出「抱歉让我重试」这类偏离格式的话绝对路径越界模型有时会用/data这种绝对路径被沙箱的越界防护正确拦截这反而验证了安全防护有效。关键结论工具调用链路本身是通的瓶颈在 1.5B 小模型的算术与格式遵循能力而非工具适配层的设计——这正是「用 8B 模型做完整训练」才能解决的量级问题。五、改造前后对比三要素维度改造前基线改造后WorkBuddy 工具集环境依赖vLLM flash-attn tritonLinux/CUDA 专属Windows 不可装需多卡transformers CPU torchWindows 4GB 显存可跑工具调用范式python 代码块 → SandboxFusion 沙箱执行tool_callJSON → WorkBuddyToolread_file/write_file/list_directory任务域数学竞赛题\boxed{}标量答案文档处理任务读取/提取/摘要/写回answer开放式结果六、总结与展望做到了什么工具层替换跑通WorkBuddyTool严格遵循原项目BaseTool契约单测通过真实推理链路里工具被真正执行、返回真实结果。任务域迁移跑通Curriculum 能从「出数学题」切换到「出文档处理任务」。沉淀了 5 个实战踩坑记录workspace 缓存 bug、ModelScope 下载、transformers 5.x API、裸 JSON 兜底解析、「真实 WorkBuddy 后端」的技术判断。没做到什么如实说明没有复现论文的 18% 提升数据本地是 1.5B 模型的可行性验证不是 8B 完整训练完整 RL 训练GRPO/ADPO在 Windows 4GB 显存下无法进行需带 GPU 的服务器。后续方向接入 WorkBuddy 的云端后端workbuddy_cloud_service的云文件存储/数据库把「本地文件工具」扩展为「云端持久化工具」真正对标生产环境文档任务的正确性判分升级为 LLM-as-judge 或 embedding 相似度在带 GPU 的服务器上补完整训练对比实验验证「WorkBuddy 工具集 vs 代码解释器」的真实增益。