Agent Improvement Loop: CoreWeave 让我重新看生产反馈#

今天我看到 CoreWeave 在 2026-05-28 发了一条很值得开发者认真看的公告：它把 Serverless RL、生产推理、W&B Weave 观测、W&B Skills 和 MCP server 放到同一个 agentic AI 闭环里，核心话术是缩短 training 和 inference 之间的距离，让代理从真实生产行为里持续改进。

这不是又一个“我们也有 agent 平台”的发布。至少对我来说，它更像一个信号：AI 应用的竞争正在从“上线前评测做得多漂亮”，转到“上线后能不能把失败样本变成下一轮系统改进”。如果这个判断成立，开发者未来要维护的就不只是 prompt、工具调用和模型路由，而是一条生产反馈流水线。

我为什么在意这个信号#

过去一年，我做 agent 系统时最难受的地方不是让模型第一次跑通，而是让它在真实工作流里稳定下来。

离线 eval 很必要，但它天然有三个缺口：

eval 集覆盖不了真实用户的脏输入。
多步代理的失败经常不是单点错误，而是计划、检索、工具权限、执行环境和恢复策略叠在一起坏。
线上事故发生之后，如果没有结构化 trace、反馈和回归验证，团队只能靠人肉复盘，下一版很容易修 A 破 B。

CoreWeave 这次的表述把这些问题放在同一个框架里：训练、推理、观测、改进不能再分散在四套工具里。生产环境里的每一次交互，都应该变成下一轮 agent reliability 的输入。

这句话听起来很大，但落到工程上其实很具体：我需要知道代理失败在哪里，失败样本能不能被保存和聚类，能不能自动变成 eval case，能不能驱动 post-training 或策略调整，最后能不能在发布前防止同类回归。

代理系统开始像一个持续学习产品#

我以前更习惯把 agent 当成“会调用工具的应用”。现在这个定义不够了。

真正进入生产之后，agent 更像一个持续学习产品：

推理层负责服务真实请求。
观测层记录多步轨迹、工具输入输出、成本、延迟和失败模式。
评测层把真实失败变成可重复的验收集。
训练或调优层把高价值样本变成下一版能力。
发布层负责灰度、回滚和防回归。

如果这几层断开，团队会陷入一种很熟悉的低效循环：线上发现问题，工程师手工读日志，改 prompt，手工跑几条 case，重新上线，然后等下一个用户撞上另一个边界。

CoreWeave 的发布值得看，是因为它把这个循环产品化了。它提到的 W&B Weave 负责 production monitoring、failure mode 和 evaluation framework；W&B Skills 则把 coding agent 变成能使用实验追踪、模型管理、trace、eval、monitoring 工具的“代理建造者”。这背后真正重要的不是品牌组合，而是职责划分：让 agent 不只会交付代码，也会参与改进 agent 本身。

我会怎么改自己的 agent 项目#

这条新闻给我的直接提醒，是不要再把“日志”当成最后才补的运维设施。

如果我现在从零做一个生产 agent，我会更早加四件事。

第一，所有关键步骤都要有结构化 trace。不是一坨文本日志，而是能回答这些问题的数据：模型看到了什么上下文，调用了什么工具，工具返回了什么，哪一步消耗最大，哪一步被用户否决。

第二，失败样本要进入一个明确的队列。用户反馈、异常、超时、权限拒绝、人工接管，都应该能被归类成 case，而不是散落在 Sentry、数据库和聊天记录里。

第三，eval 要从“上线前考试”变成“生产回放系统”。每次改 prompt、换模型、加工具，都应该先跑一遍真实失败样本回放。这样 agent 才不会在每次升级时重新犯老错。

第四，改进动作要可审计。无论是自动调参、补充 few-shot、重写工具描述，还是做 RL/post-training，都必须留下版本、输入样本、指标变化和回滚点。否则所谓自我改进，很快会变成不可解释的生产漂移。

这和最近的 Copilot 上下文治理不是一回事#

昨天我写的是 GitHub Copilot memory 和模型权限控制，那篇关注的是“上下文能不能被企业收回控制面”。今天这个角度更往下走一层：当 agent 已经被允许在生产中行动以后，系统怎么把行动结果变成改进燃料。

一个是 governance plane，一个是 learning loop。

前者回答“谁能访问什么、记住什么、用什么模型”。后者回答“代理做错以后，系统怎么变得更好”。这两个层会相互依赖，但不是同一个问题。只做治理，agent 会安全但停滞；只做学习闭环，agent 会进步但容易失控。真正可用的生产系统最后会同时需要两者。

我对这个趋势的判断#

我不觉得每个团队都应该马上上 RL 或复杂 agent improvement 平台。很多产品现在连 trace、评测集和回放都还没有，直接谈“自主改进”会太早。

但趋势已经很明显：agent 的工程重心正在从 prompt engineering 转到 feedback engineering。

下一阶段真正值钱的系统，不一定是最会写 prompt 的系统，而是最会把生产经验压缩成下一版能力的系统。谁能更快识别失败、更快复现、更快评估、更稳地发布改进，谁的 agent 就会在真实工作流里越跑越强。

这也是我今天从 CoreWeave 这条消息里读到的东西：AI 时代的“持续交付”正在多一个环节。以前我们交付代码，再从监控里修 bug；以后我们交付代理，再从生产轨迹里训练和修正代理。

对开发者来说，这个变化很实际。我们要学的不只是模型 API，而是怎样设计一条可观测、可回放、可评测、可改进的 agent 生产线。