Replit 发布 ViBench：构建面向 Vibe Coding 的端到端 Agent 评估闭环
在 Replit Agent 的生态中，大多数用户始于一个模糊的想法：用自然语言描述目标，无需预置仓库、测试套件或选定框架，期望 Agent 将其转化为可运行的应用。这种“Vibe Coding”（凭感觉编码）的成功标准看似简单——用户点击即可运行，但评估逻辑却极为复杂。
随着模型、提示词（Prompt）和产品界面的快速迭代，传统的单一评分机制已无法衡量 Agent 是否真正在进步。Replit 意识到，评估必须从单纯的“发布检查”转变为“持续改进闭环”。
从单向评估到持续改进闭环
过去，Agent 评估是一个单向过程：运行评估 -> 产生分数 -> 做出发布决策。这在发布周期长、变更少的场景中有效，但在当前快速变化的环境下已显不足。
Replit 构建了双支柱、一优化的评估系统：
- 离线基准（Offline Benchmarks）：在发布前模拟应用构建任务，提前发现回归。
- 在线 A/B 测试与生产追踪（Online A/B Tests & Production Traces）：监控发布后真实用户的行为变化。
- 优化循环：将生产信号反馈至评估系统，指导后续迭代。
这种架构类似于安全工程中的“瑞士奶酪模型”，单一层面存在漏洞，但多层防御能更有效地捕捉问题。
挑战：传统基准的局限性
现有的代码基准测试（如 SWE-bench、Terminal-Bench）通常基于预设的代码库、固定的函数签名和测试用例。然而，Vibe Coding 的核心在于 Agent 需自主决定技术栈、架构和交互流程。
这就造成了“功能正确性缺口”：Agent 可能满足局部代码约束，但生成的应用在实际运行中无法完成用户请求。因此，评估的目标必须从代码本身转移到生成的制品（Artifact）上：应用是否加载？核心工作流是否可用？结果是否符合需求？
引入 ViBench：专为 Vibe Coding 设计的基准
为填补这一空白，Replit 推出了 ViBench，这是一个公开基准，专门衡量 Agent 生成的应用是否符合规格。
核心机制
- 动态需求生成：ViBench 从匿名化的 Replit 生产追踪中提取纯英文的产品需求文档（PRD）。
- 从零构建：Agent 接收 PRD，在不依赖脚手架、路由或引用约束的情况下，从零构建运行中的应用。
- 自适应测试：评估 Agent 使用 Playwright 作为底层框架，在 Notebook 环境中逐步发现应用结构。由于它不知道应用的具体定位器（Locators），必须通过自然语言测试计划（Natural-language test plans）来探索功能级交互和断言。
基础设施支撑
在 Replit 规模下运行 ViBench 需要强大的基础设施。Replit 利用其生产环境中的隔离沙箱（Sandbox），快速分叉（Fork）这些环境以并行运行评估，既保证了资源充足，又避免了评估污染。
ViBench 的灵活性使其可扩展至多种场景：
- Vibe-to-ref：在 Agent 自行生成的代码库上进行功能扩展评估。
- Vibe-on-Vibe：在现有代码库上评估新功能。
这种设计使得 Replit 能够快速针对新产品功能（如 Agent 4 的并行合并与子代理分解）衍生新的评估问题。
“评估必须成为改进循环的一部分。单一的分数无法告诉我们，周复一周，Replit Agent 是否对用户更好。” —— Replit 官方团队
ViBench 的发布标志着 Agent 评估从关注代码正确性向关注用户体验和端到端功能一致性的重大转变，为未来 Vibe Coding 生态的标准化提供了重要参考。
