每个人都在谈论持续学习，仿佛它只意味着一件事：更新模型权重。但关于 Agent 生态系统，有一个不容忽视的事实——目前生产环境中绝大多数的 Agent 都依赖于封闭的尖端模型。当你无法拥有权重时，自然也无法对其进行微调。对于大多数 Agent 构建者来说，权重级别的持续学习是行不通的，尤其是在处理最前沿的能力时（比如 Fable 5 或 GPT 5.6）。
但这并不意味着 Agent 无法学习。Agent 系统可以在三个层面进行改进——模型、框架和上下文 [0]——而后两者完全在你的掌控之中。这正是巨大（但常被忽视）的机遇所在：框架层面的学习让你能够挖掘生产轨迹，系统性地改进驱动每个 Agent 实例的代码、工具和指令；而上下文层面的学习则让你能够在 Agent、用户和组织级别进行个性化定制，让你的产品在每一次交互中变得更好。做到以上所有，你将获得可以每日部署的复合式改进。
在本文的其余部分，我将介绍过去一年里我们如何将持续学习应用于 Replit Agent，并分享我们一路走来学到的所有经验。
大规模评估和改进 Replit Agent
大多数 Replit Agent 用户从一个想法开始。他们用自然语言描述目标——没有代码仓库、测试套件或选定的框架——并期望 Agent 将其变成一个可运行的应用程序。结果可能是一个网站、幻灯片、移动应用、几个相互关联的产物，或者完全不同的东西。
氛围编码者通常不会检查差异或测试输出。Replit Agent 的成功标准出奇地简单：当用户点击时，应用程序应该能正常工作。
这改变了评估的任务。单一的分数可以帮助做出特定的发布决策，但它无法告诉我们，周复一周，Replit Agent 是否对用户变得更好。要回答这个问题，评估必须成为改进循环的一部分。
NASA 刘易斯研究中心，发动机研究大楼中央控制室，1968 年——当测量能够改变最终交付物时，它才至关重要。
评估现在需要做得更多
过去的 Agent 评估看起来像一个单向过程：运行评估，产生分数，做出发布决策。当发布速度缓慢且被测量的对象很少变化时，这种方法行之有效。但当模型、提示词、工具和产品界面都在快速变化时，它就会失效。
旧的循环让评估感觉是有限的。但 Replit Agent 变化太快，单一分数无法承载整个决策。一个分数可以在某一组任务上比较两个候选方案。它无法解释用户关心什么、生产环境在哪里出问题、或者下一步该改进什么。
评估必须从发布检查转变为改进循环。
旧的评估任务止步于人工发布决策；新的评估任务则为一个从生产中学习并部署改进后 Agent 的持续系统提供输入。
该系统有两个测量支柱和一个优化循环。离线基准测试告诉我们，候选变更在发布前能否完成模拟的应用程序构建任务。在线 A/B 测试和生产轨迹则显示变更发布后对真实用户的影响。这些信号随后反馈到评估和发布决策中。
没有任何一个层面是足够的。基准测试在发布前捕捉回归问题。A/B 测试显示生产行为是否发生了变化。轨迹聚类解释了聚合指标下的失败原因。人工判断确保改进循环始终指向正确的产品和工程成果。其形态类似于安全工程中的瑞士奶酪模型：每个层面都有漏洞，但组合在一起能捕捉到比任何单一层面都多的问题。
现有基准测试止步于用户
像 SWE-bench [1] 和 Terminal-Bench [2] 这样的 Agent 编码基准测试，在受限、可重复的环境中评估代码。这些基准测试很有价值且被广泛采用，但它们遗漏了氛围编码者关心的信号。
Replit Agent 通常从头开始创建代码库。用户不会带来固定的路由、函数签名、选择器或测试；他们带来的是一个产品需求。Agent 自行选择技术栈、数据库模式、路由、组件和交互流程。
这就产生了一个功能正确性差距。一个 Agent 可以满足编码基准测试的局部约束，但仍然在用户所看到的事情上失败：完成的应用程序是否按要求工作。对于氛围编码来说，评估目标是产物本身：它是否能加载，核心工作流是否正常，结果是否符合需求？
ViBench 简介
正是对这种端到端评估风格的需求，促使我们构建了 ViBench [3]，这是我们用于氛围编码的公开基准测试，它衡量一个简单但重要的信号：Agent 构建的应用程序是否符合规格说明。
ViBench 从一个用简单英语编写的产品需求文档（PRD）开始，该文档源自匿名的 Replit 生产轨迹。然后，Agent 接收 PRD 并从头开始构建一个可运行的应用程序，不受传统编码基准测试所需的脚手架、路由或参考的限制。
然而，使 ViBench 贴近现实的这种灵活性，也需要一个同样灵活的评估 Agent，一个始终以 PRD 为基础的 Agent。在 SWE-bench 风格的基准测试中，项目已经存在，因此评估范围是固定的。在氛围编码中，Agent 选择技术栈、路由、组件和流程。评估必须探索它创造出的任何东西。
为此，每个 ViBench 任务都将 PRD 与一组自然语言测试计划配对，这些测试计划描述了完成的应用程序必须满足的功能级交互和断言。评估 Agent 使用 Playwright 作为灵活的基础，这使其能够执行复杂的特性，如离线模拟、文件操作和多租户。因为它事先不知道应用程序的定位器或结构，所以它在笔记本环境中工作，逐步发现应用程序的构建方式并与之交互，这种方法源自 Replit 早期关于自动化自测试的研究 [4]。
在 Replit 的规模上运行 ViBench 以及我们的一般评估，也需要强大的基础设施支持 [5]。在内部，我们依赖相同的生产基础设施，这些基础设施让我们能够为构建应用程序和运行 Agent 而启动隔离的、资源充足的沙箱。因为我们可以快速复制这些沙箱 [6]，所以我们并行运行大部分评估，而无需担心跨评估污染。
除了从头开始构建应用程序，ViBench 的相同基础——由自然语言测试计划评分的自然语言 PRD——也适用于一系列氛围编码场景。为了评估 Agent 如何在现有应用程序内部工作（更接近 Replit 的中期轨迹工作负载），我们让它在现有代码库上启动，并根据特性 PRD 衡量它交付特性扩展的能力。该代码库可以来自我们自己的参考实现，也可以来自 Agent 自己氛围编码的应用程序（我们在论文中称之为 Vibe-to-ref 和 Vibe-on-Vibe）。当我们发布新的产品界面时，相同的基础让我们能够快速衍生出新问题，以评估新颖的交互模式，就像我们为 Agent 4 的并行与合并以及子 Agent 分解所做的那样。
ViBench 保持行为评估器固定，同时改变输入和构建策略。
早期的 ViBench 结果给了我们两个有用的教训。首先，前沿编码基准测试的分数并不总能迁移到完整的应用程序构建上，尤其是对于开源权重模型。其次，大多数模型在扩展自己的代码时会变得更差，因为错误往往会累积。这些教训共同为我们提供了一个更好的攀登目标：不仅仅是编写能通过测试的代码，而是构建能够经受住下一次用户请求的应用程序。
A/B 测试是我们保持诚实的方式
我们非常信任离线评估，但它们不是唯一的评判标准。我们见过足够多的 Agent 更新在受控环境中看起来不错，但上线后却导致真实用户行为倒退，这让我们明白生产环境需要自己的测量层。
用户是不按剧本出牌的，始终在线，并且以任何离线基准测试都无法完全复现的规模在操作。他们会放弃项目、改变主意、以令人惊讶的方式组合功能，并发现我们不知道要测试的故障模式。
因此，我们对大多数影响 Agent 的更新进行 A/B 测试：提示词、工具、框架修订、模型更换以及更大的行为变更。多个实验通常同时运行——并保持归因清晰，以避免隐藏交互效应。A/B 测试揭示了用户行为、情绪和成功情况：用户是否继续使用，成本是否出现意外变化，情绪是否发生波动，以及用户是否交付了成果？
A/B 测试让我们能够受控地了解生产行为，但聚合指标本身并不能解释一切。这是胜利吗？根本的行为变化是什么？
A/B 测试的一个挑战是结果难以解读。如果运行时间增加，是 Agent 做了更多有用的工作，还是它卡住了？如果成本下降，是我们提高了效率，还是 Agent 悄悄地停止做某些有价值的事情？如果情绪下降，是哪些用例出现了倒退，哪些故障模式是新的，哪些用户放弃了？
Telescope：什么出了问题
A/B 测试告诉我们生产行为何时发生了变化。Telescope——我们的轨迹分析和聚类系统——则有助于解释原因。
在生产规模下，没有工程师能阅读每一条轨迹。Telescope 将重复出现的模式组织成工程师和 Agent 可以处理的问题集群。它总结失败轨迹，进行嵌入，聚类相似案例，并在分布变化时对新会话进行分类。目标不仅仅是统计失败次数，而是发现那些显而易见却被忽视的失败。
GIF
对我们不知道要寻找的内容进行聚类。
Telescope 使用简短、基于证据的切面，其灵感来源于与 Clio [7] 相同的自底向上方法。对于轨迹，它从用户消息、可见的 Agent 回复、工具调用、错误、元数据和其他上下文中重建会话。然后，Telescope 总结出错的地方，嵌入这些总结，并使用基于密度的聚类 [8] 来形成新兴的问题组。
切面使调查更快，尤其是在仅靠聚类不够时。当支持报告指向一个广泛的问题（例如端口故障）时，工程师和 Agent 可以先搜索紧凑层，探索相关的切面，然后深入查看具有日志和可观测性上下文的代表性会话，以解释问题。
总的来说，相同的结构将分散的失败转化为产品问题：哪些工作流占主导，哪些被放弃，哪些反复出错，以及缓解措施是否正在缩小目标集群。
有关此底层架构的更多信息，请参阅我们合作伙伴 Braintrust [9] 关于 Topics 的深度文章。
循环：从证据到 Agent 改进
一旦测量到位，瓶颈就会转移。ViBench、A/B 测试和 Telescope 可以告诉我们什么失败了、在哪里失败以及发生的频率。我们仍然需要将这些证据转化为可行的修复方案。
我们采用自我改进循环来解决这个问题。操作原则很简单：如果 Agent 对构建软件有用，那么它们也应该对改进 Agent 本身有用。每一轮循环都从读取生产日志、轨迹聚类和最近的失败开始，以寻找值得追踪的假设。然后，它构建一个候选方案，打开一个附有推理过程的草稿 PR，根据 ViBench、A/B 结果、轨迹数据和最近的基线来衡量结果，并建议是发布、迭代还是放弃。
优化循环发现问题、提出 Agent 变更、评估它们，并决定是发布、迭代还是放弃。
发布不会变成自动的。循环可以准备证据和初步实现；工程师仍然需要审查结果并拥有发布决策权。
每次运行都会记录它尝试了什么以及发生了什么，包括失败。该记录会随着时间的推移改进循环：未来的运行可以重用有效的方法，避免已知的死胡同，并提出更具通用性的变更。
Agent 迭代变得更快，同时不放弃工程控制权。给定一个新的模型、产品界面或可靠性目标，循环可以主动寻找提示词编辑、技能建议、工具修复和框架变更，而工程师则让系统始终指向更大的产品最优目标。
一个具体的例子
最近的一次运行始于一个虽小但不断增长的 Telescope 集群。环境设置在大量冷启动场景中悄然恶化。这些会话从聚合指标中并不明显，但该集群显示出一个值得调查的模式。
在呈现该模式后，循环读取了受影响的轨迹，提出了一个补丁，添加了一个回归测试，并针对 ViBench 运行了候选方案，以确认主要路径没有出现倒退。工程师审查了证据，批准了变更，并在同一天将其推送到生产环境。
补丁发布后，用户情绪恢复，受影响的用户不再受阻。这就是我们想要的形态——一个能够发现真实失败模式、将其与受影响的用户联系起来、提出适当级别的修复方案、并带回足够证据供人类决定是否发布的循环。
人类品味仍然最重要的地方
大部分工作可以自主运行：聚类失败、提出假设、构建候选方案、运行评估和整理证据。人类仍然设定方向并把关大多数出口，包括：
- 假设选择。 一个系统可以呈现数千个失败，但人类决定哪些问题值得消耗循环的过夜预算。并非每个集群都同等重要，也并非每次回归都指向正确的产品问题。
- 实现架构。 轨迹可能显示用户正在放弃某个工作流，但决定是平滑该路径、改变 Agent 的行为还是重新设计界面，这属于工程和产品判断。
- 评估策展。 这不是行政工作；它塑造了 Agent 攀登的山丘。如果评估奖励了错误的行为，优化循环将忠实地朝着错误的方向优化。
- 发布审批。 发布 Agent 变更不仅仅是看一个数字。发布审批意味着阅读证据，了解影响范围，决定风险是否可接受，并负责部署。
这种平衡很重要：循环可以承担更多的搜索、测量和综合工作。工程师仍然选择方向，做出产品决策，并决定发布什么。
闭环
评估不再仅仅是发布前的关卡。它有助于决定修复什么、测试什么以及发布什么。
这项工作不是为了产生一个更好的数字。而是为了将用户的失败转化为更好的发布版本，从而让更多的想法变成人们自豪地发布的应用程序。
我们很高兴能继续推动自主 Agent 的前沿发展，重点关注最复杂编码任务的可靠性。如果你对从事自主编码 Agent 的工作感兴趣，我一直在为 Replit AI 团队招聘——请联系 [email protected]
作者：Daniel Furman、Peter Zhong、Zhen Li、Michele Catasta
参考文献
[1] SWE-bench：语言模型能解决真实的 GitHub 问题吗？
[2] Terminal-Bench：在命令行界面中针对困难、现实的任务对 Agent 进行基准测试
[3] ViBench：氛围编码基准测试
[4] 通过基于 REPL 的验证实现 Agent 3 的大规模自测试
[6] Replit 快照引擎内部：让 AI Agent 安全的技术
[9] 我们如何实现大规模持续轨迹智能
