大家谈到持续学习（Continual Learning）时，常常好像它只意味着一件事：更新模型权重。但 agent 生态里有一个不太好回避的事实——今天生产环境中的绝大多数 agent 都依赖闭源前沿模型。当你并不拥有权重时，当然也无法微调它们。对大多数 agent 构建者来说，权重层面的持续学习并不可行，尤其是使用最前沿能力时更是如此（比如 Fable 5 或 GPT 5.6）。
但这并不意味着 agent 不能学习。Agentic 系统可以在三个层面改进——模型、harness 和 context [0]——其中后两个完全在你的控制之内。这正是一个巨大但常被忽视的机会所在：harness 层面的学习，让你可以挖掘生产环境轨迹，系统性地改进支撑每个 agent 实例的代码、工具和指令；context 层面的学习，则让你可以在 agent、用户和组织层面做个性化，让产品随着每一次交互变得更好。把这些都做起来，你就能形成可每天发布、持续复利的改进。
在本文余下部分，我会介绍过去一年里我们如何把持续学习应用到 Replit Agent，并分享一路上学到的经验。
大规模评估和改进 Replit Agent
大多数 Replit Agent 用户都是从一个想法开始。他们用自然语言描述目标——没有代码仓库、没有测试套件，也没有选定框架——然后期待 agent 把它变成一个可运行的应用。结果可能是一个网站、一套幻灯片、一个移动应用、几个相互连接的产物，或者完全不同的东西。
Vibe coders 通常不会检查 diff 或测试输出。对 Replit Agent 来说，成功标准看似简单：用户点来点去时，应用应该能正常工作。
这改变了评估工作的性质。单个分数可以帮助某个具体发布决策，但它无法告诉我们，Replit Agent 是否一周比一周更好地服务用户。要回答这个问题，评估必须成为改进循环的一部分。
评估现在必须承担更多工作
Agent 评估过去看起来像一个单向过程：运行 eval，产出分数，然后做发布判断。当发布节奏很慢、被测对象很少变化时，这种方式有效。但当模型、prompt、工具和产品界面都在快速变化时，它就会失效。
旧循环让评估看起来边界清晰。但 Replit Agent 变化太快，单个分数无法承载整个决策。一个分数可以在某一小片任务上比较两个候选方案。它无法解释用户真正关心什么、生产环境哪里出了问题，或者下一步应该改进什么。
评估必须从发布前检查，转变为改进循环。
这个系统有两个测量支柱和一个优化循环。离线 benchmark 告诉我们，候选改动在发布前能否完成模拟的应用构建任务。线上 A/B 测试和生产环境轨迹则展示改动发布后真实用户受到了怎样的影响。这些信号随后回流到 eval 和发布决策中。
没有哪一层单独就足够。Benchmark 在发布前捕捉回归。A/B 测试显示生产行为是否发生变化。轨迹聚类解释聚合指标下面的失败。人的判断则确保改进循环始终指向正确的产品和工程结果。这套结构类似安全工程里的瑞士奶酪模型：每一层都有洞，但合在一起能捕捉到比任何单层更多的问题。
现有 benchmark 离用户还差一步
SWE-bench [1] 和 Terminal-Bench [2] 这类 agentic coding benchmark，会在受约束、可重复的环境里给代码打分。这些 benchmark 很有价值，也已经被广泛采用，但它们漏掉了 vibe coder 真正在意的信号。
Replit Agent 经常是从零创建代码库。用户不会带来固定路由、函数签名、选择器或测试；他们带来的是一个产品需求。agent 会自己选择技术栈、schema、路由、组件和交互流程。
这造成了一个功能正确性缺口。一个 agent 可以满足编程 benchmark 的局部约束，却仍然在用户看得到的地方失败：最终应用是否真的做到了用户要求的事。对 vibe coding 来说，评估目标是成品本身：它能不能加载，核心流程能不能跑通，结果是否符合请求？
介绍 ViBench
我们之所以构建 ViBench [3]，正是因为需要这种端到端评估方式。ViBench 是我们面向 vibe coding 的公开 benchmark，用来测量一个简单但重要的信号：agent 构建出来的应用是否满足规格要求。
ViBench 从一份普通英文的产品需求文档（PRD）开始，这些 PRD 来自匿名化的 Replit 生产环境轨迹。随后，agent 收到 PRD，并从零构建一个可运行的应用，不受传统编程 benchmark 所要求的脚手架、路由或参考实现约束。
不过，ViBench 的现实感来自这种灵活性，而这种灵活性也要求 eval agent 同样灵活，并且始终锚定 PRD。在 SWE-bench 风格的 benchmark 中，项目已经存在，所以评估对象是固定的。在 vibe coding 中，agent 会选择技术栈、路由、组件和流程。评估必须探索它实际生成出来的一切。
为此，每个 ViBench 任务都会把 PRD 与一组自然语言测试计划配对，这些测试计划描述成品应用必须满足的功能级交互和断言。eval agent 使用 Playwright 作为灵活的骨架，这让它可以演练复杂功能，例如离线模拟、文件操作和多租户。因为它事先并不知道应用的定位器或结构，所以它在 notebook 环境里工作，逐步发现应用是如何构建的，并一步步与之交互；这种方法来自 Replit 早期关于自动化自测的研究 [4]。
在 Replit 的规模下运行 ViBench，以及我们的整体 eval，也需要强大的基础设施支持 [5]。在内部，我们依赖同一套生产基础设施，它让我们可以启动彼此隔离、资源充足的 sandbox 来构建应用并运行 agent。因为我们可以快速 fork 这些 sandbox [6]，所以大量评估可以并行运行，而不会有不同评估彼此污染的风险。
除了从零构建应用之外，ViBench 的同一套基础——用自然语言测试计划给自然语言 PRD 打分——也可以适配一系列 vibe-coding 场景。为了评估 agent 如何在一个现有应用内部工作，也就是更接近 Replit 的中途接手型工作负载，我们会让它从现有代码库开始，并测量它根据 feature PRD 交付功能扩展的效果。这个代码库可以来自我们自己的参考实现，也可以来自 agent 自己用 vibe coding 搭出来的应用；在我们的论文中，我们把这称为 Vibe-to-ref 和 Vibe-on-Vibe。当我们发布新的产品界面时，同一套骨架也能让我们快速派生新问题，用来评估新的交互模式，例如 Agent 4 中的 parallel-and-merge 和 subagent decompositions。
早期 ViBench 结果给了我们两条有用经验。第一，前沿编程 benchmark 分数并不总能迁移到完整应用构建，尤其是对开放权重模型而言。第二，大多数模型在扩展自己写的代码时表现会变差，因为错误常常会层层叠加。合起来看，这些经验给了我们一座更值得攀登的山：不只是写出能通过测试的代码，而是构建能经受住下一次用户请求的应用。
A/B 是我们保持诚实的方式
我们非常信任离线 eval，但它们不是唯一裁判。我们已经见过足够多 agent 更新在受控环境中表现很好，却让真实用户行为倒退，因此知道生产环境需要自己的测量层。
用户行为没有脚本、随时发生，并且处在离线 benchmark 无法完全复现的规模上。他们会放弃项目、改变主意、以意想不到的方式组合功能，并发现我们不知道该测试的失败模式。
因此，我们会对大多数影响 agent 的更新做 A/B：prompt、工具、harness 修订、模型替换，以及更大的行为变化。多个实验经常并发运行——同时保持清晰归因，避免掩盖交互效应。A/B 测试会暴露用户行为、情绪和成功情况：用户有没有继续做下去，成本是否出现异常，情绪有没有变化，用户是否真的发布了东西？
A/B 测试的一个挑战是结果很难解读。如果运行时长上升，是 agent 做了更多有用工作，还是卡住了？如果成本下降，是我们提高了效率，还是 agent 悄悄停止做某些有价值的事情？如果情绪下降，哪些用例退化了，哪些失败模式是新的，哪些用户放弃了？
Telescope：看清哪里在坏
A/B 测试告诉我们生产环境行为何时发生了变化。Telescope——我们的轨迹分析和聚类系统——帮助解释为什么。
在生产规模下，没有工程师能读完每一条轨迹。Telescope 把重复模式组织成 issue clusters，让工程师和 agent 可以采取行动。它总结失败轨迹，对它们做 embedding，聚类相似案例，并在分布变化时对新 session 分类。目标不只是统计失败数量，而是发现那些明明摆在眼前却容易被忽视的问题。
Telescope 使用简短、基于证据的 facets，灵感来自 Clio [7] 中同样自下而上的方法。对轨迹而言，它会根据用户消息、可见的 agent 回复、工具调用、错误、元数据和其他上下文重建 session。随后，Telescope 总结哪里出了问题，对这些摘要做 embedding，并使用基于密度的聚类 [8] 形成自然浮现的问题组。
Facets 能让排查更快，尤其是在单靠聚类还不够的时候。当支持报告指向一个宽泛问题，例如端口失败，工程师和 agent 可以先搜索这层浓缩信息，查看相关 facets，然后再钻到代表性 session 中，结合日志和可观测性上下文解释问题。
聚合起来，同一套结构会把零散失败变成产品问题：哪些工作流最常出现，哪些被放弃，什么反复出问题，以及某个缓解措施是否正在缩小目标 cluster。
关于这套底层架构的更多信息，可以阅读我们的合作者 Braintrust 写的 Topics 深度文章 [9]。
这个循环：从证据到 agent 改进
一旦测量存在，瓶颈就会转移。ViBench、A/B 测试和 Telescope 可以告诉我们什么失败了、失败在哪里、发生得有多频繁。但我们仍然必须把这些证据转化为合理的修复方案。
为了解决这个问题，我们转向一个自我改进循环。它的运行原则很简单：如果 agent 对构建软件有用，它们也应该对改进 agent 有用。每一轮都会先读取生产日志、轨迹 cluster 和近期失败，找出一个值得追的假设。然后它构建一个候选方案，打开一个附带推理说明的 draft PR，用 ViBench、A/B 结果、轨迹数据和近期 baseline 衡量结果，并建议是发布、迭代还是放弃。
发布并不会变成自动动作。这个循环可以准备证据和第一版实现；工程师仍然会评审结果，并对发布决策负责。
每次运行都会记录它尝试了什么、发生了什么，包括失败。这个记录会随着时间改进循环：未来运行可以复用有效做法，避开已知死胡同，并提出更能泛化的改动。
Agent 迭代会变快，同时不放弃工程控制。面对一个新模型、产品界面或可靠性目标，这个循环可以主动找出 prompt 修改、skill 提案、工具修复和 harness 改动，而工程师则继续让系统指向更大的产品最优解。
一个具体例子
最近一次运行，是从一个虽小但正在增长的 Telescope cluster 开始的。环境设置在一长串冷启动场景中悄悄退化。这些 session 从聚合指标里看并不明显，但 cluster 显示出了一个值得调查的模式。
这个模式浮现后，循环读取了受影响的轨迹，提出 patch，添加回归测试，并把候选方案放到 ViBench 上运行，以确认 happy path 没有回归。工程师评审证据，批准改动，并在同一天推到了生产环境。
Patch 发布后，用户情绪恢复，受影响用户也不再被卡住。这就是我们想要的形态——一个循环能找到真实失败模式，把它连接到受影响用户，提出恰当粒度的修复，并带回足够证据，让人类决定是否发布。
人类品味仍然最重要的地方
其中很多事情都可以自主运行：聚类失败、提出假设、构建候选方案、运行 eval、整理证据。人类仍然设定方向，并把住大多数出口，包括：
- 假设选择。 一个系统可以浮现一千个失败，但由人来决定哪些问题值得占用这个循环一整晚的预算。不是每个 cluster 都同样重要，也不是每个回归都指向正确的产品问题。
- 实现架构。 轨迹可能显示用户正在放弃某个工作流，但决定是把这条路径做得更顺、改变 agent 行为，还是重新设计界面，是工程和产品判断。
- Eval 筛选与维护。 这不是行政工作；它塑造 agent 要攀登的那座山。如果 eval 奖励了错误行为，优化循环就会忠实地朝错误方向优化。
- 发布批准。 发布一个 agent 改动不只是读一个数字。发布批准意味着阅读证据、理解影响范围、判断风险是否可接受，并对 rollout 负责。
这种平衡很重要：循环可以承担更多搜索、测量和综合工作。工程师仍然选择方向，做产品判断，并决定什么可以发布。
闭合循环
评估不再只是发布前的一道关。它帮助决定要修什么、测什么、发布什么。
目标不是产出一个更好的数字，而是把用户遇到的失败转化为更好的发布，让更多想法变成让人愿意自豪发布的应用。
我们很高兴继续推进自主 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