让模型在现有Agent框架内接受训练

给编码 Agent 调过提示词、工具和技能，模型仍然选错工具、跳过流程，甚至耗尽轮数也交不了差，问题未必全在配置。OpenHands 和 Snowflake 提出的办法是：让模型直接在你现有的 Agent 运行框架里接受后训练，练习它上线后真正要用的那套流程。

这条路线最有价值的地方，是减少训练与部署之间的落差。但它没有省掉任务集和评分脚本，也没有证明小模型经过训练就能胜任所有编码工作。看懂它，能帮你判断什么时候该继续调提示词，什么时候才值得动模型权重。

为什么训练模型还要重写一套 Agent

Agent 运行框架（harness）不只是循环调用模型。它还包括系统提示词、工具定义、技能、上下文长度和最大执行轮数。这些配置共同决定模型能看到什么、能做什么，以及必须在多久之内完成任务。

原文指出，很多强化学习（RL）框架自带 Agent 循环、工具格式和任务结构。团队想训练生产环境里的 Agent，往往得在训练框架里重新实现一次。除了工程成本，两份实现还可能逐渐偏离：训练时表现不错，上线后却碰到另一套执行细节。

OpenHands Agent SDK 的做法，是把已有 Agent 的配置直接带入训练。每次 rollout，也就是一次完整的任务尝试，都由这套 Agent 实际执行。

它要解决的首要问题，是让训练时练习的流程与上线时运行的流程保持一致。

原文引用的是 OpenHands 与 Snowflake AI Research 在 2026 年 11 月 3 日发布的方案，相关算力由 Snowflake Cortex Training 提供。这里的「沿用现有框架」仍有适配边界，并不代表任意 Agent 都能原封不动接入。

一次任务执行，怎样变成训练信号

模型仍然发送普通的 chat-completion 请求。Agent 与模型之间的代理记录每轮模型输出的准确 token，用于训练；提示词和工具返回结果不计入损失。

这表示训练直接优化的是模型生成的内容，并不表示提示词和工具结果不影响模型决策。

任务采用开放的 Harbor 格式。一个任务目录包含 instruction.md、定义沙箱环境的 environment/，以及负责评分的 tests/test.sh。脚本给出的分数就是奖励信号。每次 rollout 使用独立的 Snowflake Cortex Sandbox，Agent 的终端和评分器在同一沙箱内运行，评分对应它实际执行后的结果。

配置入口也相当直接：

• OPENHANDS_SYSTEM_PROMPT_FILE 指定系统提示词文件，OPENHANDS_TOOLS 指定工具。
• HARBOR_SKILL 指定技能路径，MAX_TURNS 和 MAX_CONTEXT_LENGTH 控制轮数与上下文长度。
• MODEL 指定基础模型，原文示例使用 Qwen/Qwen3.5-4B。

为了减少启动训练的操作，OpenHands 在 OpenHands/extensions 中提供了 cortex-training-rl skill。下面这条指令把模型、训练集、评估集、技能、15 轮预算和 50 步训练交给 Agent 配置：

Use /cortex-training-rl to post-train Qwen/Qwen3.5-4B on my Harbor tasks in ~/my-harbor-tasks/train and ~/my-harbor-tasks/eval with my agent's skill at ~/my-skill/SKILL.md, a 15-turn budget, for 50 steps.

要留意这一行里的两个任务目录：训练集与评估集已经分别指定，不能只准备一条自然语言要求就开始训练。

按原文描述，该 skill 会配置启动器、检查 GPU、在后台启动任务，逐步报告奖励和失败 rollout，绘制奖励曲线，并在结束后释放 GPU。它也能从 Claude Code 和 Cursor 使用。本地只承担 CPU 上的 Agent rollout，模型采样与训练使用 Snowflake GPU，默认每次运行分配四张 H200。

实验验证了流程，但没有包办编码能力

他们团队做的是代码定位实验：给定 SWE-smith 数据集中真实 Python 仓库的 GitHub issue，让 Agent 找出需要修改的文件、模块和函数。

这套框架使用专门的定位提示词、终端工具和提交答案的 localization_finish 工具，限制为 10 轮。奖励是文件、模块、函数三个层级的 F1 分数之和，最高 3.0。

他们用 Qwen3.5-4B 训练了 25 步，每步 64 次 rollout。原文称平均奖励持续上升，结果与专门实现的 RL 方案相当；从 Harbor 任务到训练完成，整个过程约两小时。

这个结果支持的是：沿用 Agent 框架的训练流程能跑通，并在这项定位任务上取得可比结果。原文没有列出具体起止分数、误差范围或更多任务的对照数据，因此不能据此判断收益有多大，更不能直接推到完整修复 issue。

运行限制也会影响迁移。沙箱不暴露训练机器的凭据，但每条终端命令都在新 shell 中执行。工作目录可以保留，导出的环境变量和后台进程不会保留。训练时暂不支持 OpenHands 的 file_editor，改文件必须走终端。启动器默认面向 Hopper GPU，使用 FlashAttention 3；其他配置可用，但起点仍是 Snowflake 的托管技术栈。

我的判断

我认同它优先消除训练与部署差异的方向。假如模型经常忽略技能、选错工具，那么让它在真实配置里练习，比维护另一套近似实现更直接。

不过，作者把这类问题归为行为失配，是有前提的。同样的失败，也可能来自工具描述不清、上下文缺失，或者任务超出模型能力。仅凭 Agent 没完成任务，无法判断该训练权重还是修配置。

真正的门槛，是你能否把真实工作写成可重复评分的任务。

评分脚本覆盖不了的质量，训练目标也未必会照顾。代码定位可以计算 F1，完整编码还要面对测试遗漏和需求歧义。原文没有给出提示词优化、工具收敛与后训练之间的成本收益对照，所以「什么时候训练更划算」目前仍主要是经验判断。

对普通团队，我会保留原文的先后顺序：先修提示词、收紧工具、建立任务集，再考虑训练。GPU 操作可以交给 skill，任务定义和评分质量仍要团队自己负责。

能拿来做什么

• 给日常 AI 编程失败留记录，区分选错工具、忽略技能、轮数耗尽与代码能力不足，先判断问题是否适合通过行为训练改善。
• 把反复出现的代码定位任务整理成 Harbor 任务，用 instruction.md 写清要求，用 tests/test.sh 自动评分，再准备独立评估集。
• 检查现有终端流程是否依赖跨命令的 export 或后台服务，并确认文件修改能通过终端完成，提前暴露训练沙箱的适配问题。
• 在提示词、工具和技能趋于稳定后，选一组范围明确的任务试训，同时观察独立评估集成绩与失败 rollout，避免只盯训练奖励曲线。