过去一年，我们聊 Coding Agent，讨论最多的是：

• 模型够不够强？
• Prompt 怎么写？
• 工具调用怎么设计？

但最近 Hugging Face 社区公开的一条路线，让我看到一个不同方向：

未来的 Coding Agent，可能不只是被提示词驱动，而是可以通过真实工作过程不断学习。

8 月 5 日，Hugging Face 社区展示了一套新的开源组合：

把 TRL、OpenEnv 和 OpenCode 连接起来，让 Coding Agent 在隔离沙箱中完成完整的软件开发流程。

它可以：

• 阅读代码
• 修改文件
• 执行命令
• 运行测试
• 根据结果继续调整

然后，把整个过程产生的轨迹和最终测试结果，再反馈给训练系统。

简单理解：

以前我们训练模型，更像是在教它“怎么回答”。

现在开始尝试让它经历：

接任务 → 写代码 → 执行 → 失败 → 修复 → 验证

这一整套工程过程。

官方实验中，使用 Qwen3-8B 完成 32 道 DeepCoder 编程任务，训练 10 步后，平均奖励从约 0.27 提升到 0.71。

Qwen3-8B 在 32 道题、10 步训练中的平均奖励与波动曲线

Qwen3-8B 在 32 道题、10 步训练中的平均奖励与波动曲线

图 1｜官方实验中的平均奖励约从 0.27 升到 0.71；样本少、训练短，不能外推为真实项目能力。来源：Hugging Face。

当然，这个结果不能简单理解为：

“AI 已经学会写软件了。”

32 道题、10 步训练，距离真实企业项目还有很远。

但它验证了一件更重要的事情：

Agent 的执行过程，第一次更完整地进入了训练闭环。

最大变化：Agent 做过什么，终于可以被学习

理解这件事情，需要先看过去的问题。

以前训练 Agent，经常是这样的：

图片

看起来合理。

但和真实 Coding Agent 工作方式并不完全一样。

真正的软件开发环境是什么？

图片

而不是简单的一问一答。

问题就在这里：

训练时学的是简化交互，部署时面对的是完整工作流。

这次 Hugging Face 采用的是 loop-owning 模式。

简单理解：

不让训练框架控制所有流程，而是让真正负责工作的 Agent 自己掌握循环。

具体流程：

1. 每次任务启动一个独立沙箱；
2. OpenCode 自己决定读取哪些文件、修改什么代码；
3. 透明代理记录模型产生的 token、概率和完整消息轨迹；
4. 隐藏测试检查最终代码结果；
5. TRL 根据任务反馈更新模型。

TRL、OpenEnv、OpenCode、透明代理与验证器组成的真实 Harness 训练链路

TRL、OpenEnv、OpenCode、透明代理与验证器组成的真实 Harness 训练链路

图 2｜OpenCode 掌控工具循环，透明代理记录真实轨迹，验证器把隐藏测试结果送回 TRL。来源：Hugging Face。

这里有一个关键概念：

Harness。

它可以理解成 Agent 的工作环境。

就像一个真实程序员坐在电脑前：

有代码仓库。

有终端。

有测试环境。

有各种工具。

以前 Harness 主要负责：

“让 Agent 能工作。”

现在开始进一步参与：

“让 Agent 学习如何工作。”

真正重要的，不是多一个工具，而是行为开始产生训练信号

很多人理解 Agent，容易停留在：

• 给它接一个搜索工具。
• 给它接一个终端。
• 给它更多 API。

但工具本身只是能力。

关键问题是：

Agent 会不会正确使用这些能力？

以前，一个 Agent 调错工具，通常只是当前任务失败。

现在，这些失败过程可以成为训练数据。

比如：

• 为什么第一次修改失败？
• 为什么测试没有通过？
• 为什么选择了错误方案？

这些过程都可能帮助模型以后减少类似错误。

这也是这条路线真正有价值的地方。

它不是简单增强 Agent。

而是尝试建立：

执行行为 → 结果反馈 → 模型优化

这样的闭环。

类似方向其实已经有人探索。

7 月公开的 OpenForgeRL，也尝试通过代理层和远程容器训练真实 Harness。

Hugging Face 这次更大的价值，是把：

• OpenCode
• OpenEnv
• TRL

组合成了一套相对完整、可复现的开源方案。

未来企业真正难复制的，也许不是模型。

而是：

自己的任务。

自己的工具链。

自己的测试体系。

自己的失败案例。

奖励上涨，不代表 Agent 已经学会软件工程

这里必须保持冷静。

实验效果提升，并不等于 Coding Agent 已经具备真实工程能力。

原因很简单。

软件工程比刷题复杂太多。

真实项目里面还有：

• 权限问题
• 数据安全
• 性能影响
• 历史代码包袱
• 团队规范
• 产品理解

这次实验主要面对的是竞赛编程任务。

它和企业代码库完全不是一个难度。

官方另一轮 Qwen3-4B 远程实验也出现过类似情况：

奖励提升几步后，Agent 开始不断调用工具，却没有真正解决问题。

可能原因包括：

• 训练时间不足
• 异步延迟
• 沙箱失败
• 模型规模限制

另外，一个更关键的问题：验证器。

模型最终优化的是：它能看到的反馈。

如果测试设计不好，Agent 可能学会：让测试通过。

但不一定：让系统正确。

比如：

• 权限问题。
• 异常处理。
• 性能下降。
• 代码维护成本。

这些往往不会出现在简单测试里。

验证器能看见的成功与完整业务正确之间的边界

验证器能看见的成功与完整业务正确之间的边界

图 3｜验证器只会奖励它能观察到的目标；权限、安全、性能和可维护性仍需单独定义。

所以未来 Coding Agent 的核心竞争力，很可能不是：

谁测试更多。

而是谁能设计更好的验证体系。

大多数开发者，现在不用急着训练自己的 Agent

看到强化学习、Agent 训练这些关键词，很多开发者可能会觉得：

是不是应该马上搭自己的训练平台？

其实大部分团队还没有必要。

真正适合尝试这类方案的团队，一般具备：

• 可以控制模型和推理服务；
• 有大量重复任务；
• 有稳定测试环境；
• 有明确评价标准。

例如：

代码迁移。

自动修复。

内部脚手架生成。

固定领域开发任务。

这些场景更容易形成训练闭环。

哪些团队适合训练自己的 Coding Agent，以及大多数开发者应先完成的工作

哪些团队适合训练自己的 Coding Agent，以及大多数开发者应先完成的工作

图 4｜先判断任务和验证条件，再决定是否投入强化学习。

对于普通开发者来说，现在更重要的是另一件事：

先让自己的开发过程变得可验证。

比如：

• 写清楚完成标准；
• 增加自动化测试；
• 完善 CI；
• 在隔离环境运行 Agent；
• 保存日志和修改记录。

因为没有明确标准，就算训练 Agent，也只是把混乱放大。

Coding Agent 的未来，可能属于拥有“工程反馈系统”的团队

这次实验并没有证明：

Coding Agent 已经可以自主进化。

它只是证明了一条更清晰的方向：

未来 Agent 不只是调用工具完成任务。

它可能会通过：

1. 真实环境。
2. 真实反馈。
3. 真实失败。

不断调整自己的行为。

但对于大多数企业来说，第一步不是马上研究 GRPO。

而是解决一个更基础的问题：

什么叫完成？

如果一个任务没有清晰验收标准，没有可靠测试，没有可观察反馈，那么 AI 再强，也只能靠猜。

未来的软件工程竞争，也许不只是模型能力竞争。

更是：

任务定义能力。

验证体系能力。

工程反馈能力。

的竞争。

AI 可以越来越快地写代码。

但真正决定一个团队能不能持续交付的，是能不能让 AI 的每一次行动，都进入一个可理解、可验证、可复盘的工程闭环。

参考资料

1. Hugging Face：Training a coding agent using the OpenCode harness in remote HF sandboxes with TRL and OpenEnv
2. Hugging Face TRL Docs：OpenEnv Integration for Training LLMs with Environments
3. Hugging Face TRL：OpenCode HF Sandbox 示例
4. Hugging Face OpenEnv：OpenCode Environment
5. Hugging Face Datasets：DeepCoder-Preview-Dataset
6. Yu 等：OpenForgeRL: Train Harness-native Agents in Any Environment
7. Luo 等：Training Long-Context, Multi-Turn Software Engineering Agents with Reinforcement Learning

文章来自：51CTO