多数生产环境中的Agent运行在闭源前沿模型上，因此开发者无法更新模型权重，必须专注于框架层和上下文层的持续学习。为了在Replit实现这一目标，团队构建了ViBench——根据自然语言规范评估功能性应用构建成功率，并配合Telescope——一个自动化系统，能将生产环境中的失败轨迹聚类成可操作的故障组。

Agent的持续学习

人人都把“持续学习“等同于“更新模型权重“。但关于Agent生态系统有一个不容忽视的事实：如今生产环境中绝大多数Agent都依赖闭源前沿模型。当你无法掌控权重时，当然也无法对其进行微调。对于大多数Agent构建者来说，权重层面的持续学习基本行不通，尤其是在使用Fable 5或GPT 5.6这类前沿能力模型时。

但这不代表Agent就无法学习。Agent系统可以在三个层面进行改进——模型层、框架层和上下文层[0]——而后两层完全在你的掌控之中。这正是巨大（却常常被忽视）的机会所在：框架层的学习让你能挖掘生产轨迹，系统性地改进驱动每个Agent实例的代码、工具和指令；而上下文层的学习则让你能在Agent、用户和组织层面实现个性化，使你的产品在每一次交互中变得更好。做到了以上这些，你就能获得每日可交付的复合式改进。

在本文剩余部分，我将介绍过去一年我们如何将持续学习应用于Replit Agent，并分享一路走来的所有经验教训。

大规模评估和改进Replit Agent

大多数Replit Agent用户是从一个想法开始的。他们用自然语言描述目标——没有代码仓库、没有测试套件、也没有选定的框架——然后期待Agent将其转化为一个可运行的应用程序。结果可能是一个网站、幻灯片、移动应用、数个关联产物，或是其他完全不同的东西。

Vibe编码者通常不会检查差异或测试输出。Replit Agent的成功标准看似简单：用户随意点击时应用程序能正常工作。

这改变了评估的任务。一个单一的分数可以帮助做出特定的发布决策，但它无法告诉我们，周复一周，Replit Agent是否对用户变得更好。要回答这个问题，评估必须成为改进循环的一部分。

NASA刘易斯研究中心，发动机研究大楼中央控制室，1968年——当测量结果能够改变交付物时，它就变得至关重要。

NASA刘易斯研究中心，发动机研究大楼中央控制室，1968年——当测量结果能够改变交付物时，它就变得至关重要。

评估现在需要承担更多责任

过去的Agent评估看起来像一个单向过程：运行评估，生成分数，做出发布决策。当发布节奏缓慢且被测量物很少变化时，这行得通。但当模型、提示词、工具和产品界面都在快速变化时，这个方法就会失效。

旧的循环让评估显得有边界。但Replit Agent变化太快，单一分数无法承载整个决策。一个分数只能在某类任务上比较两个候选方案。它无法解释用户关心什么、生产环境中哪里出错了、下一步该改进什么。

评估必须从发布检查转变为改进循环。

旧的评估工作止步于人类做出的发布决策；新的评估工作则为一个从生产环境中学习并交付改进后Agent的持续系统提供输入。

旧的评估工作止步于人类做出的发布决策；新的评估工作则为一个从生产环境中学习并交付改进后Agent的持续系统提供输入。

该系统包含两个衡量支柱和一个优化循环。离线基准测试告诉我们，候选变更在发布前能否完成模拟的应用构建任务。在线A/B测试和生产环境轨迹则展示变更发布后对真实用户的影响。这些信号随后反馈回评估和发布决策中。

没有任何一个层面是独立足够的。基准测试在发布前捕捉回归问题。A/B测试显示生产行为是否发生了变化。轨迹聚类解释聚合指标下的失败原因。人工判断确保改进循环始终指向正确的产品和工程成果。其形态类似于安全工程中的瑞士奶酪模型：每个层面都有漏洞，但组合在一起能比任何单一层面捕捉到更多问题。

现有基准测试止步于用户

像SWE-bench [1] 和 Terminal-Bench [2] 这样的Agent编码基准测试，在受限、可重复的环境中对代码进行评分。这些基准测试很有价值且被广泛采用，但它们错过了Vibe编码者关心的信号。

Replit Agent常常从头开始创建代码库。用户不会带来固定的路由、函数签名、选择器或测试；他们带来的是产品需求。Agent需要自行选择技术栈、数据模型、路由、组件和交互流程。

这就产生了一个功能正确性差距。一个Agent可能满足编码基准测试的局部约束，但在用户所见之处失败：完成的应用是否实现了要求。对于Vibe编码，评估的目标是产物本身：它能否加载、核心工作流是否有效、结果是否符合要求。

介绍ViBench

正是出于对这种端到端评估风格的需求，我们构建了ViBench [3]，这是一个针对Vibe编码的公开基准测试，衡量一个简单但重要的信号：Agent构建的应用程序是否符合规格说明。

ViBench从一个以简单英语编写的产品需求文档（PRD）开始，这些文档来自匿名化的Replit生产轨迹。随后，Agent接收到PRD，从头开始构建一个可运行的应用程序，不受传统编码基准测试所需的脚手架、路由或参考内容的限制。

然而，使ViBench如此逼真的灵活性也需要一个同样灵活的评估Agent——一个始终以PRD为基准的Agent。在SWE-bench风格的基准测试中，项目已经存在，因此评估范围是固定的。而在Vibe编码中，Agent选择技术栈、路由、组件和流程。评估必须探索它创造出来的一切。

为此，每个ViBench任务都将PRD与一组自然语言测试计划配对，这些计划描述了完成的应用必须满足的功能级交互和断言。评估Agent使用Playwright作为灵活的基础架构，这使得它能够执行复杂的功能，如离线模拟、文件操作和多租户。因为它事先不知道应用的定位器或结构，所以它在Notebook环境中工作，逐步发现应用的构建方式并与之交互——这种方法源自Replit早期关于自动化自测试的研究 [4]。

在Replit的规模上运行ViBench以及我们一般的评估，还需要强大的基础设施支持 [5]。在内部，我们依赖于同样的生产基础设施，这些基础设施让我们能够快速启动隔离的、资源充足的沙箱来构建应用和运行我们的Agent。由于我们可以快速复制这些沙箱 [6]，我们可以并行运行大部分评估，而无需担心跨评估的污染。

除了从头构建应用，同样的ViBench基础——由自然语言测试计划评分的自然语言PRD——也能适应一系列Vibe编码场景。为了评估Agent如何在现有应用内工作（更接近Replit的轨迹中段工作负载），我们让它从一个现有的代码库开始，并衡量它根据功能PRD发布功能扩展的效果。该代码库可以来自我们自己的参考实现，也可以来自Agent自己进行Vibe编码的应用（我们在论文中称之为Vibe-to-ref和Vibe-on-Vibe）。当我们发布新的产品界面时，同样的基础架构让我们能够快速衍生出新的问题来评估新颖的交互模式，就像我们对Agent 4的并行与合并以及子Agent分解所做的那样。

ViBench保持行为评估器固定，同时改变输入和构建策略。

ViBench保持行为评估器固定，同时改变输入和构建策略。

早期的ViBench结果给我们带来了两个有用的教训。第一，前沿的编码基准测试分数并不总能迁移到完整的应用构建中，尤其是对于开放权重模型。第二，大多数模型在扩展自己的代码时会变得更差，因为错误往往会叠加。结合起来，这些教训为我们提供了一个更好的攀登方向：不仅仅是编写能通过测试的代码，而是构建能够经受住下一个用户请求考验的应用。

A/B测试让我们保持诚实

我们深信离线评估，但它们不是唯一的评判标准。我们见过足够多的Agent更新在受控环境中表现良好，却在真实用户行为上出现回归，这让我们明白，生产环境需要自己的测量层。

用户是非脚本化的，始终在线，其操作规模是任何离线基准测试都无法完全复现的。他们会放弃项目，会改变主意，会以出人意料的方式组合功能，会发现我们不知道要测试的故障模式。

因此，我们对大多数影响Agent的更新进行A/B测试：提示词、工具、框架修订、模型更换以及更大的行为变更。多个实验经常同时进行——保持归因清晰以避免隐藏交互效应。A/B测试揭示了用户行为、情绪和成功率：用户是否继续使用、成本是否出现异常、情绪是否发生变化、用户是否成功发布了某样东西？

A/B测试为我们提供了对生产行为的受控解读，但聚合指标本身并不解释问题。这是胜利吗？根本的行为变化是什么？

A/B测试为我们提供了对生产行为的受控解读，但聚合指标本身并不解释问题。这是胜利吗？根本的行为变化是什么？

A/B测试的一个挑战是结果难以解读。如果运行时长增加了，是因为Agent做了更多有用的工作，还是因为它卡住了？如果成本下降了，是我们提高了效率，还是Agent悄悄地停止了做某些有价值的事情？如果情绪下降了，哪些用例出现了回归，哪些故障模式是新出现的，哪些用户放弃了？

Telescope：什么东西出了问题

A/B测试告诉我们生产行为何时发生了变化。Telescope——我们的轨迹分析和聚类系统——则帮助我们解释原因。

在生产规模下，没有工程师能读完每一条轨迹。Telescope将重复出现的模式组织成工程师和Agent可以处理的故障集群。它总结失败轨迹，对其进行嵌入，聚类相似案例，并在分布变化时对新会话进行分类。目标不仅仅是统计失败次数，而是发现那些隐藏在大众视野中的失败。

GIF聚类的目标是我们不知道要去寻找的东西。

聚类的目标是我们不知道要去寻找的东西。

Telescope使用简短、有证据基础的方面（facets），其灵感来源于与Clio [7]相同的自底向上方法。对于轨迹，它从用户消息、可见的Agent回复、工具调用、错误、元数据和其他上下文中重建会话。从那里开始，Telescope总结出问题所在，将这些总结进行嵌入，并使用基于密度的聚类 [8] 来形成涌现的故障群组。

当仅靠聚类不够时，Facets能加快调查速度。当支持报告指向一个宽泛的问题（例如端口故障）时，工程师和Agent可以先搜索紧凑层，探索相关的facets，然后深入分析包含所需日志和可观测性上下文的代表性会话。

总体而言，相同的结构将零散的失败转化为产品问题：哪些工作流占主导，哪些被放弃，哪些问题反复出现，以及某个缓解措施是否正在收窄预期的集群。

关于此基础架构的更多信息，请参阅我们合作伙伴Braintrust [9] 关于Topics的深度文章。

循环：从证据到Agent改进

一旦有了测量，瓶颈就转移了。ViBench、A/B测试和Telescope可以告诉我们什么东西失败了、在哪里失败、以及发生的频率。我们仍然需要将这些证据转化为可行的修复方案。

我们采用一个自我改进循环来解决这个问题。操作原则很简单：如果Agent对构建软件有用，那么它们也应该对改进Agent本身有用。每轮循环从读取生产日志、轨迹聚类和最近的失败开始，寻找一个值得追踪的假设。然后构建一个候选方案，打开一个附带推理过程的草稿PR，根据ViBench、A/B结果、轨迹数据和近期基线对其进行评估，并建议是发布、迭代还是放弃。

优化循环发现问​​题，提出Agent变更，评估它们，并决定是发布、迭代还是放弃。

优化循环发现问​​题，提出Agent变更，评估它们，并决定是发布、迭代还是放弃。

发布不会变成自动化的。循环可以准备证据和初步实现方案；工程师仍然需要审查结果并拥有发布决策权。

每次运行都会记录它尝试了什么以及发生了什么，包括失败。这些记录会随着时间的推移改进循环：未来的运行可以利用成功的经验，避免已知的死胡同，并提出更普适的变更。

Agent的迭代速度加快，同时不放弃工程控制权。面对一个新的模型、产品界面或可靠性目标，循环可以主动提出提示词编辑、技能建议、工具修复和框架变更，而工程师则让系统始终朝着更大的产品优化目标前进。

一个具体的例子

最近的一次运行始于一个虽小但不断增长的Telescope集群。环境设置在大量的冷启动场景中悄悄地恶化。这些会话从聚合指标中并不明显，但集群显示出一个值得调查的模式。

在浮现出这个模式后，循环读取了受影响的轨迹，提出了一个补丁，添加了一个回归测试，并在ViBench上运行了候选方案，以确认正常路径没有出现回归。工程师审查了证据，批准了变更，并在同一天将其推送到生产环境。

补丁发布后，用户情绪恢复，受影响的用户不再受阻。这就是我们想要的形式——一个能发现真实失败模式、将其连接到受影响的用户、提出适当级别的修复方案、并带回足够证据供人类决定是否发布的循环。

人类品味仍然最重要的地方

大部分工作可以自主运行：聚类失败、提出假设、构建候选方案、运行评估、以及整理证据。人类仍然设定方向并掌控大多数出口，包括：

• 假设选择。 一个系统可以浮现出成千上万个失败，但人类决定哪些问题值得投入循环的夜间预算。并非每个集群都同等重要，也并非每次回归都指向正确的产品问题。

• 实现架构。 轨迹可能显示用户正在放弃某个工作流，但决定是平滑那个路径、改变Agent的行为、还是重新设计界面，这属于工程和产品的判断。

• 评估策划。 这不是行政工作；它塑造了Agent攀登的山峰。如果评估奖励了错误的行为，优化循环就会忠实地朝着错误的方向优化。

• 发布审批。 发布Agent变更不仅仅是看一个数字。发布审批意味着阅读证据，理解影响范围，决定风险是否可接受，并掌控发布过程。

这个平衡很重要：循环可以做更多的搜索、测量和综合工作。工程师仍然选择方向，做出产品决策，并决定发布什么。

闭环

评估不再仅仅是发布前的关卡。它有助于决定修复什么、测试什么以及发布什么。

这项工作不是为了产生一个更好的分数。而是将用户的失败转化为更好的发布，从而使更多的想法变为现实的生产力。