Agent持续学习的三层框架

大规模评估与改进 Replit Agent

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

Vibe coder 通常不检查差异或测试输出。Replit Agent 的成功看似简单：当用户点击时，应用应该能正常工作。

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

NASA 刘易斯研究中心，发动机研究大楼中央控制室，1968年——当测量改变船舶时，测量至关重要。

评估现在必须做得更多

Agent 评估曾经像是一个单向过程：运行评估，产生分数，做出发布决定。当发布缓慢且被测量的对象很少变化时，这种方法有效。但当模型、提示、工具和产品表面都在快速变化时，它就失效了。

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

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

旧的评估工作在人类做出发布决定时结束；新的评估则为一个持续的系统提供反馈，该系统从生产中学习并发布改进后的 Agent。

该系统有两个测量支柱和一个优化循环。离线基准测试告诉我们候选变更在发布前能否完成模拟应用构建任务。在线 A/B 测试和生产跟踪则显示发布后实际用户受到的影响。这些信号随后反馈回评估和发布决策。

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

现有基准测试止步于用户

Agentic 编码基准测试，如 SWE-bench [1] 和 Terminal-Bench [2]，在受限、可重复的环境中评估代码。这些基准测试有价值且被广泛采用，但它们忽略了 vibe coder 关心的信号。

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

这就造成了功能正确性差距。Agent 可以满足编码基准测试的局部约束，但仍然在用户所见之处失败：最终应用是否按要求完成了任务。对于 vibe coding，评估目标是产物本身：它是否加载，核心工作流是否正常工作，结果是否符合请求。

介绍 ViBench

对这种端到端评估风格的需求正是我们构建 ViBench [3] 的原因，这是一个针对 vibe coding 的公开基准测试，衡量简单但重要的信号：Agent 构建的应用是否满足规范。

ViBench 从一份从匿名化的 Replit 生产跟踪中提取的纯英文产品需求文档 (PRD) 开始。随后，Agent 接收 PRD 并从头构建一个运行中的应用，不受传统编码基准测试所需的脚手架、路由或参考的限制。

然而，使 ViBench 贴近现实的同一灵活性也需要同样灵活的评估 Agent，一个始终以 PRD 为依据的 Agent。在 SWE-bench 风格的基准测试中，项目已经存在，因此评估范围是固定的。在 vibe coding 中，Agent 选择技术栈、路由、组件和流程。评估必须探索它发明的任何内容。

为此，每个 ViBench 任务都将 PRD 与一组自然语言测试计划配对，这些计划描述了最终应用必须满足的特性级交互和断言。评估 Agent 使用 Playwright 作为灵活的骨干，使其能够执行离线模拟、文件操作和多租户等复杂特性。由于它事先不知道应用的选择器或结构，因此在笔记本环境中工作，逐步发现应用是如何构建的，并逐步与之交互——这种方法源自 Replit 早期关于自动化自测的研究 [4]。

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

除了从头构建应用之外，相同的 ViBench 基础（由自然语言测试计划评分的自然语言 PRD）也适用于一系列 vibe coding 场景。为了评估 Agent 如何在现有应用中工作（更接近 Replit 的中期轨迹工作负载），我们让它在现有代码库上启动，并根据特性 PRD 衡量它交付特性扩展的效果。该代码库可以来自我们自己的参考实现，也可以来自 Agent 自己 vibe coding 的应用（我们在论文中称之为 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] 自底向上方法启发的简短、基于证据的 facets。对于跟踪，它从用户消息、可见的 Agent 回复、工具调用、错误、元数据和其他上下文中重建会话。然后，Telescope 总结错误所在，嵌入这些总结，并使用基于密度的聚类 [8] 形成新兴的问题组。

Facets 使调查更快，尤其是在仅靠聚类不够时。当支持报告指向一个广泛的问题（如端口失败）时，工程师和 Agent 可以先搜索紧凑层，探索相关 facets，然后深入查看具有日志和可观测性上下文的代表性会话，以解释问题。

在聚合层面，相同的结构将分散的失败转化为产品问题：哪些工作流占主导，哪些被放弃，什么反复失败，以及缓解措施是否在缩小目标聚类。

有关此底层架构的更多信息，请参阅我们合作伙伴 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 团队招聘——请联系 pirroh@repl.it

作者：Daniel Furman, Peter Zhong, Zhen Li, Michele Catasta

参考文献

[0] Continual learning for AI agents [1] SWE-bench: Can Language Models Resolve Real-World GitHub Issues? [2] Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces [3] ViBench: A Benchmark on Vibe Coding [4] Enabling Agent 3 to Self-Test at Scale with REPL-Based Verification [5] Quantifying infrastructure noise in agentic coding evals [6] Inside Replit's Snapshot Engine: The Tech Making AI Agents Safe [7] Clio: Privacy-Preserving Insights into Real-World AI Use [8] Hierarchical Density Estimates for Data Clustering, Visualization, and Outlier Detection [9] How we made continuous trace intelligence possible at scale

• 原文链接： x.com/pirroh/status/2074...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～