企业官网建设流程全解析

在生产环境中构建 AI Agent 时，一个最常见的假设是：要想让 Agent 持续变好，就必须更新模型权重。

但现实是残酷的：绝大多数生产级 Agent 依赖闭源前沿模型（Fable、GPT 等系列）。当你不拥有权重时，fine-tuning 就彻底不在选项里。尤其是当你在能力最前沿工作时，这个路径基本被封死了。

这并不意味着 Agent 无法持续学习。

Replit AI 团队过去一年的实践证明：Agentic 系统可以在三个完全不同的层次上持续改进——模型层、harness 层和 context 层。而后两者，是绝大多数团队完全可控的。

把精力集中在 harness（工具、指令、代码结构）和 context（个性化记忆、用户/组织知识）上，你就能实现每天都在上线的可衡量改进，而不是等下一次模型发布。

我起初也以为，闭源模型意味着 Agent 的能力天花板基本固定了。后来看到 Replit 把生产 trace 直接转化成 harness 改进和 context 积累，才意识到：模型只是执行引擎，真正能每天迭代的是围绕它的整个系统。

为什么传统的一次性评估已经失效

过去 Agent 评估往往是单向的：跑 benchmark → 拿分数 → 决定是否发版。

这种模式在模型和 prompt 变化缓慢时还能勉强工作。但当 Replit Agent 每天都在调整 prompt、工具、harness 和产品交互时，单一分数根本扛不住决策。

用户是“vibe coder”——他们用自然语言描述目标，Agent 从零开始生成完整应用（网站、移动端、幻灯片等）。成功标准不是“代码通过测试”，而是“用户点开后实际能用”。

这就要求评估必须从“发版前检查”变成“持续改进闭环”。

Replit 构建了双支柱 + 一个优化闭环的系统：

• 离线 benchmark（ViBench）判断候选改动是否能在模拟任务中完成；
• 在线 A/B 测试 + 生产 trace观察真实用户影响；
• 所有信号反哺回评估和决策。

这类似于安全工程里的 Swiss cheese 模型：每一层都有漏洞，但多层叠加能捕获单一层漏掉的问题。

ViBench：为 vibe coding 设计的端到端评估

传统 benchmark（如 SWE-bench）假设已有代码库，Agent 只需修改现有结构。

而 vibe coding 的真实场景是：Agent 自己选技术栈、设计 schema、路由、组件和交互流程。评估目标变成了“最终生成的 App 是否满足原始需求”。

为此 Replit 推出了公开的ViBench：

• 输入是来自真实生产 trace 的自然语言 PRD（产品需求文档）；
• Agent 从零构建可运行应用；
• 评估 Agent 使用 Playwright 在 notebook 环境中逐步探索应用结构，执行自然语言测试计划。

它不仅能测从零构建，还能测“在已有代码库上扩展功能”（Vibe-to-ref、Vibe-on-Vibe），以及新产品交互模式（如并行与合并、子代理分解）。

早期结果揭示了两个重要信号：前沿 coding benchmark 分数并不总是迁移到完整 App 构建；大多数模型在扩展自己生成的代码时会变差——错误会累积。

这把优化方向从“写出能过测试的代码”转向了“构建能承受下一次用户请求的 App”。

Telescope：把生产失败变成可行动的洞察

A/B 测试能告诉你“行为变了”，但解释不了“为什么变了”。

Replit 的 Telescope 系统把海量生产 trace 聚类成问题簇：

• 重建会话轨迹（用户消息、Agent 回复、工具调用、错误、元数据）；
• 用证据驱动的摘要进行 embedding 和密度聚类；
• 形成可搜索的 issue clusters 和 facets。

工程师和 Agent 都能快速定位重复出现的失败模式，而不是靠人工阅读每一份日志。

把 Agent 用来改进 Agent 的自改进闭环

一旦有了测量，瓶颈就变成了“如何把证据转化为改进”。

Replit 的做法是让 Agent 自己参与改进循环：

1. 读取生产日志、trace 簇和近期失败，提出值得追的假设；
2. 构建候选改动（prompt 编辑、skill 提案、工具修复、harness 变更）；
3. 打开带推理说明的 draft PR；
4. 在 ViBench + A/B + 轨迹数据上测量效果；
5. 给出“发版 / 迭代 / 放弃”的推荐。

人类依然保留关键闸门：假设选择、实现架构决策、评估策展、最终发版批准。

一个真实案例：Telescope 发现一个缓慢增长的冷启动环境设置问题。闭环读取受影响轨迹、提出补丁、增加回归测试、在 ViBench 上验证后，工程师当天就审核并上线。用户情绪恢复，受影响用户被解锁。

三个持续学习层次的对比

Harness 层和 context 层加起来，能让你在模型不变的情况下实现可 compounding 的每日改进。

人类品味依然是最后一道防线

自改进闭环可以自主完成聚类、假设生成、候选构建、测量和证据整理。但人类必须负责：

• 决定哪些失败簇值得投入 overnight 计算预算；
• 判断是修复路径、改变 Agent 行为，还是重构产品表面；
• 确保评估真正对齐产品目标，而不是优化到错误的方向；
• 承担发版的风险与责任。

这个平衡让系统既能规模化搜索和合成，又不会失去工程判断。

把用户失败转化为更好发布的闭环

评估不再只是发版前的门禁，而是决定“修什么、测什么、发什么”的核心引擎。

当你无法通过更新模型权重来让 Agent 变好时，真正的杠杆就在于系统性地挖掘生产痕迹、改进 harness、积累 context，并用多层测量把证据闭环起来。

Replit 的经验表明：只要把这套机制跑起来，你就能把“每天都有真实用户失败”这件事，转化为“每天都能上线让更多想法变成优质 App”的能力。

这才是生产级 Agent 持续学习最被低估、也最可执行的路径。

你在构建生产 Agent 时，遇到过“模型不变但系统越来越难用”的情况吗？或者你们已经在 harness/context 层做了哪些持续改进的尝试？欢迎分享具体做法或遇到的瓶颈，我们一起把这些实践继续打磨。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。