Replit Agent：无公开源码，靠工程博客一手披露还原的托管式云端编码 agent

Replit Agent

一句话定位

Replit Agent 是 Replit 平台内置的托管式（hosted-only）全自主编码 agent，没有任何公开源码、npm 包或可 clone 的仓库——它跑在 Replit 自家的 Repl 容器基础设施里，作为 SaaS 产品交付。本页的全部证据来自 Replit 官方工程博客（blog.replit.com，Engineering / AI 两个分类）对内部系统的第一手技术披露，而非源码阅读，这是与其他 harness 页面（可以引用 commit/行号）的根本区别，也是本页需要一开始就诚实声明的边界。

核心架构总览（目录结构关键路径 + 引用的 commit）

不存在代码仓库目录结构可供列出。可引用的是 14 篇官方工程博客文章（详见”一手源存档”），覆盖时间跨度 2024-08-14（blog-code-at-scale.md，Backer 数据管线）到 2026-06-23（blog-evaluating-improving-agent-at-scale.md，评测与自改进闭环）。命名的内部系统（均为 Replit 自造词，非通用营销语言，可信度较高）：

• Bottomless Storage — 2023 年就存在的先前工作，基于 GCS 的虚拟块设备存储，是 CoW 文件系统分叉的底层原语。
• Margarine — Replit 自研的、基于 Btrfs 的文件系统，驱动 Backer 数据管线的变更通知流。
• Backer — 挂在 Margarine Pub/Sub 变更流上的 Docker ETL 服务，把执行日志/LSP 诊断/OT 编辑动作写入 BigQuery，同时喂养产品分析和 AI 模型训练。
• Telescope — 借鉴 Anthropic Clio 方法论（arXiv:2412.13678）与 HDBSCAN 聚类算法的 trace 聚类分析系统，是自改进闭环的输入端。
• ViBench — Replit 自建的公开 agent 评测基准，PRD 驱动、由 Playwright 支撑的”渐进式发现型”评测 agent 打分（而非固定 locator 脚本）。

因为没有源码，下文的”文件路径”实际指本地存档的博客 markdown 文件名（sources/harness/replit-agent/ 下），用以定位每条论断的一手依据。

Agent Loop（主循环 / 何时继续何时停）

• 假设驱动的主循环：Agent v2（2025-02-25，与 Claude 3.7 Sonnet 联合发布，blog-agent-v2.md）官方描述为——“每一步先形成一个假设，搜索相关文件，只有信息足够时才开始改动”，并声称 v2 能”知道何时后退、重新思考”而不是在同一个 bug 上死循环。这是一个显式承认”陷入循环”是已知失败模式、并声称已针对性设计解决的表述。
• 循环上叠加的实时决策控制层：blog-decision-time-guidance.md 披露，循环并非单纯”LLM 调用→工具调用”，而是每一次 agent 迭代都有一个跑在独立、更快/更便宜模型上的分类器，检视轨迹（用户消息、工具结果、错误模式），决定是否在下一次生成前注入一条微指令。这是一个显式的、独立于 prompt 本身的控制层。
• Doom-loop 逃逸机制：同一分类器检测到”重复失败尝试、循环式编辑或高风险改动”时，会注入提示让 agent 去咨询一个跑在不同模型上的外部 agent（显式理由：降低”自我偏好偏差” self-preference bias），该外部 agent 从干净上下文提出新方案。设计利用的是”生成器-判别器差距”（generator-discriminator gap）——卡住的 agent 不需要自己生成修复方案，只需要能识别一个好方案。
• Agent 3 的自主时长目标：blog-automated-self-testing.md 明确给出量化指标——“我们让 Agent 的自主能力提升了 10 倍，把它能完全独立完成有效工作的总时长从 20 分钟提高到 200 分钟以上”（原文第 319 行：“bringing the total amount of time it’s able to do productive work completely on its own from 20 minutes to over 200 minutes”），主要靠自测试能力（见”自进化”节）实现，而非单纯模型升级。
• 测试子 agent 复用同一循环形状：同文披露”子 agent 遵循标准的 agent 循环：行动、观察、重复，直到它判断测试已完成”——确认 action→observe→repeat 是 Replit 内部对”标准循环”的定义，主 agent 与子 agent 共用这一循环形状，只是运行环境（notebook sandbox）不同。
• 停止判据未见显式披露：博客未给出主循环”何时判定任务完成”的具体终止条件规则（例如是否有独立的完成度分类器、还是纯粹依赖模型自身判断），这一点官方未披露，需标注为空白。

记忆与上下文管理（压缩、长期记忆、会话持久化）

• Checkpoint = git commit + DB 快照的联合体：blog-snapshot-engine.md ——“每当 Agent 达到某个任务的’完成度’状态，我们就创建一个 Git commit 并在 checkpoint 元数据中记录它”。每个 checkpoint 同时打包一次 git commit 和一次 Postgres 文件系统快照（通过 Bottomless Storage 的 CoW manifest 复制），代码和数据库状态被联合版本化、可联合回滚。
• 进程状态序列化用于崩溃恢复：博客分类索引页摘录（2024-11 前后一篇未单独抓取的文章）提到”我们持续将每个 agent 进程的状态序列化到其 Repl 中”——确认 agent 进程状态被持久化到用户的 Repl（而非仅存内存），代价是崩溃恢复时要重跑部分 LLM 调用。注：此条来自分类索引页摘录，未独立抓取完整原文，可信度略低于其他条目。
• 子 agent 隔离对抗”context rot”：blog-automated-self-testing.md ——“编程是高 token 消耗的。主 agent 上下文常常达到 8 万到 10 万 token……如果把测试纳入主循环，上下文会迅速被污染……为此我们把测试任务拆分成独立子 agent。主 agent 与测试子 agent 之间只传递彼此完成工作所需的最小上下文”。文中显式引用了 context-rot 研究（research.trychroma.com/context-rot）作为设计动机。
• 即时注入不进入持久历史：blog-decision-time-guidance.md ——“注入的提醒不会留存在对话历史中。决策做出后它们就消失。上下文只累积真正相关的内容”。这与”核心系统 prompt 永不改变以保住 prompt cache”的设计（见 Prompt 设计节）是同一枚硬币的两面。
• 执行环境本身作为记忆载体：测试子 agent 跑在一个持久化的 Node vm 沙箱 notebook 里，“变量持久化""浏览器会话持久化”跨越工具调用边界——设计意图是把状态挪出 token 流、放进执行环境（原文：“Context stays in code, not in tokens”）。

工具体系（定义/调用协议/注册/权限）

• MCP 作为外部连接层：blog-mcp.md、blog-replit-in-claude.md 确认 Replit 采用 Model Context Protocol 作为标准工具/连接器层，“官方 Replit Connector” 让 Claude（Claude Design）可以把开发任务交给 Replit Agent 执行。但 blog-mcp.md 本身内容偏通用协议科普（client/server/protocol 三段式模型，“AI 的 USB-C”），对 Replit 自身 MCP server 实现细节披露很薄，不能作为深度设计证据，只能确认”用了 MCP”这一事实。
• 工具范式的核心设计决策——“code-use” 而非逐动作 tool-call（blog-automated-self-testing.md，本维度最丰富的单一来源）：
  • 显式拒绝”每个动作一次 tool-call”范式（Playwright-MCP / Stagehand / Browser-Use 风格），理由是”每个工具都消耗宝贵的上下文……动作空间受限于可用工具集”；也拒绝端到端 computer-use CUA，理由是成本/延迟——原文给出具体数字：用 Claude Sonnet 4 在 1080p 下填一个 5 字段表单，约 $0.50、耗时 30-90 秒。
  • Replit 的解法：给 agent 暴露一个 JS 沙箱（Node vm.createContext，注入 Playwright 辅助函数），让 agent 写代码（循环、条件分支）而不是逐动作调用工具——量化的 token 效率收益例子：36 次”下个月”点击可以折叠成一次模型调用里的一个 for 循环，而不是 36 次模型调用。
  • Notebook 里除 Playwright 外还注入了：精简的 ARIA 增强版 DOM 表示、只读 DB 查询辅助函数、以及自上次执行以来捕获的客户端/服务端日志——即所谓”自定义工具”本质是注入到 REPL 里的 JS 函数，而非 JSON-schema 风格的 tool-call 定义。这是一个与主流 tool-calling harness（如 Claude Code 的 JSON tool schema）范式级不同的设计选择，值得在跨 harness 对比里重点标注。
• 包安装作为一个被网络层拦截的”工具调用”：blog-package-firewall.md ——agent 执行的 npm/pip install 命令被 Package Firewall（与 Socket 合作）在网络层拦截；被拦截的安装会返回一个 agent 可见的结构化信号，供其”建议一个安全替代方案……或把决定权交还给用户”。上线一周后日均拦截约 8,000 个包（原文标题即为”Blocking 8,000+ malicious packages daily”，已核实）。
• 未见披露：工具的 JSON-schema 注册协议、权限分级模型（如是否有细粒度的 per-tool allowlist）官方未公开具体机制，只能从 Package Firewall / dev-prod DB 隔离等具体安全机制侧面推断存在某种权限网关，见”安全与权限”节。

Prompt 设计（系统提示结构、动态组装）

这是全部证据里披露最详尽的维度，几乎整篇 blog-decision-time-guidance.md 是专门写这个的：

• 对静态前置系统提示的显式批判：原文指出”习得的先验会覆盖书面规则”，指令遵循”随上下文增长而退化”（首因/近因偏差，引用了”Lost in the Middle”，arXiv:2307.03172），并且”更多规则收益递减”（冗长导致优先级模糊）。
• Decision-time guidance 机制：一个跑在快/便宜模型上的轻量多标签分类器在每次迭代时判断哪些短情境指令此刻相关，从”4-5 条静态提醒”变成一个可复用的、“数百条”微指令组成的指令库，按需选择性加载而非全部拼接。
• 原文给出的具体注入示例（逐字引用）："Found 1 new browser console log, use the log tool to view the latest logs."——刻意设计成一条通知而非上下文倾倒，agent 必须自己去拉日志。
• 注入位置的实测影响：把同一条”鼓励并行工具调用”的指导语放在 trace 末尾（近因偏置位置）而非系统提示里，导致每轮循环多执行 15% 的工具调用——这是一个具体的、A/B 式的量化数字。
• 朴素”全部追加到底部”会复现同样的失败模式：文中提到实测——“避免使用 mock 数据”这条指令的遵从率在与 3 条以上其他提醒并存竞争优先级时会下降，有时甚至与用户消息本身冲突。
• Prompt cache 经济学是设计约束之一，不仅是质量考量：原文——“核心 prompt 从不改变，所以我们始终命中 prompt cache……相比动态修改系统提示的方案，成本降低 90%“。即”稳定可缓存的核心系统 prompt + trace 末尾的临时性注入”这一架构，是同时针对模型质量和推理成本两个目标联合优化的结果。
• Custom Instructions 作为第二层静态注入：blog-custom-skills.md ——用户/团队编写的常驻准则”在每个项目、每个会话、任何人打字之前，自动注入到 agent 上下文中”——这是与内部 decision-time 系统正交的、用户可控的第二层静态 prompt 注入。
• Skills 作为条件加载的 prompt 片段：同样”选择性加载”哲学的第三种实现——agent 不会一次性把工作区所有 skill 都塞进上下文，而是先只读每个 skill 的 description，判断哪些适用于当前任务，只加载匹配上的（详见”Skill 体系”节）。

Router / 编排（任务分解、多 agent、子 agent）

• Plan / Build / Edit 三态状态机（blog-plan-mode.md）：Plan Mode 是只读构思/任务列举态，agent 在此模式下”被禁止做任何代码改动”，但可以检索仓库/查文档；用户点击”Start Building”后转入 Build Mode。这是一个粗粒度、用户可见的编排/权限门，不是细粒度工具级权限系统。
• 测试子 agent 的上下文边界协议（blog-automated-self-testing.md）：主 agent 把一份高层计划（编号列出的断言清单）交给专门的测试子 agent；子 agent 在 notebook 沙箱里独立跑自己的 action-observe 循环；返回时”我们把测试结果总结并给出关于什么正常、什么损坏的指导”传回主 agent——即”计划进、摘要出”的显式上下文边界协议。
• Agent 4 的并行子 agent 分解（blog-agent-4-intro.md，本维度披露最详细的来源）：
  • “并行处理多个任务……当改动冲突时，Agent 4 使用专门的子 agent 来解决冲突”（合并冲突解决子 agent）。
  • “自动拆分大任务。对于较大的工作，Agent 4 可以把单个任务拆成更小的部分，用子 agent 并行处理，再重新合并结果”——自动任务分解 + 并行子 agent 执行 + 结果重组，官方在评测博客里专门提到 ViBench 为此新增了”Agent 4 的并行合并与子 agent分解”评测题目。
  • Kanban 式任务调度：“每个发给 Agent 4 的请求都会被拆分成在后台并行运行的离散任务……Agent 4 会智能地按最优顺序排列并执行它们”——暗示子 agent 池之上存在一个调度器/依赖解析器，但协议层细节（如何合并子 agent 结果、冲突解决算法本身）官方未公开，只有产品层描述，没有架构图或协议规范。
• 并行采样路线图（截至 2025-12 发文时尚未上线）：blog-snapshot-engine.md ——“我们甚至可以并行创建多个这样的环境，让不同的 Agent 都尝试解决同一个问题……使用推理时扩展（Inference-Time Scaling）的一个子技术——并行采样……挑选最佳改动集合并原子化应用”，援引 Anthropic Claude 4 在 SWE-bench 上并行采样 72%→80% 的结果作为动机。这是路线图/未来工作，不是已确认上线的功能，必须明确标注。
• 弱项：本维度没有找到架构图或子 agent 结果合并的协议级细节，是官方给出的最详细的多 agent 披露（Agent 4）也止步于产品能力描述层面。

Skill / 插件体系

• 专门的完整披露（blog-custom-skills.md，2026-06-10 发布，命名为”Agent Customization”，含 Custom Instructions + Skills 两部分）：
  • Skill = 一个文件夹，包含 SKILL.md + 可选的支持文件。SKILL.md 内三个必需部分：name（小写，通过 /name 调用）、description（原文明确说”这是 agent 判断是否使用某 skill 时读的唯一内容”——description 质量就是整个触发机制）、instructions（自由格式）。
  • 加载机制：agent 先只读所有 description，判断哪些与当前任务相关，只为命中的 skill 加载完整 instructions——显式不是全部 skill 常驻上下文。多个 skill 可以同时触发并叠加。
  • 手动调用：聊天里输入 /skill-name 或通过”+“按钮，作为自动 description 匹配之外的补充。
  • 分发形式：skill 是纯文本、可版本控制、可团队间共享；工作区级 skill 库展示在”+“菜单顶部；Enterprise 版限制只有管理员可创作，Core/Pro 版任意成员可创作。
  • 官方给出的显式失败模式分类：description 过宽 → 误触发；instructions 过于笼统 → 触发后输出跑偏；description 相互重叠 → 冲突（官方给出的修复方法是收窄 description，而不是改 instructions）。
  • 生态：Replit 提供合作伙伴”Skills directory”预制 skill（例如引用了 Mixpanel 产品经理原话的一个 Mixpanel 官方 skill）。
  • 与 Claude Code Skills 的相似度：这套 SKILL.md 约定（name/description/instructions 三段式、description 驱动的选择性加载、/name 手动调用）与 Claude Code 自己的 Skills 机制高度平行，很可能是借鉴/对标关系，但没有直接证据证明是直接抄袭或技术共享，只能在跨 harness 对比阶段标注”高度相似，因果关系未证实”。

自进化能力（自我改进 / 学习型记忆 / eval 驱动纠错）

两篇专门文章覆盖了这一维度：

• 完整自改进闭环（blog-evaluating-improving-agent-at-scale.md）：官方立场是”如果 agent 能用来构建软件，它们也应该能用来改进 agent 自身”。闭环步骤：读取生产日志/trace 聚类（经由 Telescope）→ 形成假设 → 构建候选改动 → 开一个带推理过程说明的 draft PR → 针对 ViBench + A/B 测试 + 轨迹数据 + baseline 做评测 → 给出上线/迭代/放弃的建议。显式声明不自动上线：“工程师仍然审阅结果并拥有发布决定权”。给出的具体例子：Telescope 的一个聚类发现了一个静默退化的冷启动环境配置问题；闭环读取受影响的轨迹，提出补丁+回归测试，跑 ViBench 验证，工程师当天批准上线，用户情绪评分随后恢复。
• Agent 3 自测试即推理时的 eval 驱动自纠正（blog-automated-self-testing.md）：Agent 3 的自测试本质是推理时（而非训练时）的自我验证——agent 通过一个基于 REPL 的测试子 agent 核查自己的工作，以捕获”Potemkin interfaces”（看起来能用、实际是坏的 UI），文中显式借用了 Goodhart’s Law / reward-hacking 谱系的框架来描述这一问题。
• ViBench（blog-evaluating-improving-agent-at-scale.md 描述，未独立抓取 vibench.ai 原站）：公开基准，PRD 驱动，自然语言测试计划由一个基于 Playwright、notebook 式的评测 agent 打分，该评测 agent”渐进式发现”应用而非使用固定 locator——官方明确动机是 SWE-bench/Terminal-Bench 式的固定脚手架基准无法衡量”vibe-coded 应用点开是否真的能用”。两条文档化的实证结论：(1) 前沿代码基准分数不能可靠迁移到完整应用构建能力，尤其是开放权重模型；(2) 大多数模型在扩展自己先前生成的代码时表现更差（错误会累积）。ViBench 命名了两个子变体：Vibe-to-ref（扩展已有/参考代码库）和 Vibe-on-Vibe（扩展 agent 自己先前的输出）。

可观测性（日志 / trace 格式）

• Telescope（blog-evaluating-improving-agent-at-scale.md）：trace 分析/聚类系统。从”用户消息、可见的 agent 回复、工具调用、错误、元数据及其他上下文”重建会话，把失败轨迹总结成简短、有证据支撑的”facet”（明确借鉴 Anthropic Clio 方法论，arXiv:2412.13678），对总结做 embedding，用密度聚类（引用 HDBSCAN 论文，doi:10.1145/2733381）分簇，并对新会话按演化中的簇分布做分类。底层聚类/embedding 基础设施与 Braintrust 合作共建（“Topics” 架构，braintrust.dev/blog/topics-architecture——本阶段未独立抓取，仅读取了 Replit 一方的引用）。
• A/B 实验基础设施（同文）：“prompt、工具、harness 版本、模型替换以及更大的行为变更”都会做 A/B 测试，“归因保持清晰以避免掩盖交互效应”（当多个实验并发运行时）；跟踪的信号包括运行时长、成本、情绪评分，以及用户是否”真的 ship 了东西”。
• “Backer” 数据管线（blog-code-at-scale.md）：虽然是公司级数据/分析系统而非 agent 专属可观测性组件，但它就是 trace/执行日志捕获的字面底层——Backer 是挂在 Margarine（自研 Btrfs 文件系统）Pub/Sub 变更通知流上的 Docker ETL 服务；每次文件系统变更都可以触发任意提取脚本，用一个受限 GCP token 写入 BigQuery。捕获内容包括”执行日志、LSP 诊断、以及 OT（Operational Transformation）动作”这类细粒度”timeline 数据”，同时喂养 AI 训练（例如一个”Code Repair”模型，文中一笔带过、未详细展开）和产品分析，采用”Progressive Classification”设计——先算便宜的确定性特征（字符串/AST/lint 统计），只对剩余的歧义案例做 LLM 分类。规模数字：存储超过 3 亿个仓库，日均约 7000 万个文件被编辑，每月写入超过 1 PiB。

安全与权限（审批门、密钥管理）

• 开发/生产数据库隔离是核心权限原语（blog-db-migrations.md、blog-snapshot-engine.md）：agent 只被授予对开发数据库的访问权；引入独立的每部署生产数据库正是因为”给 agent 不受限的数据库访问权限被判定为有风险”（agent 可能以破坏性或不兼容的方式修改它）。从 dev 到 prod 的 schema 迁移是确定性生成的（fork 自 drizzle-kit CLI，而非 LLM 生成 diff）——官方显式设计理由：“我们对模型的经验表明，更确定性的方法可能更可取……尤其考虑到错误迁移对用户生产数据的潜在影响”。迁移应用采用 Neon DB branching，创建一个一次性的生产分支副本做上线前测试，冲突警告在提升到生产前展示给用户。
• Plan Mode 作为审批门（blog-plan-mode.md）：agent 在此模式下从构造上就不能写代码/改数据库，用作提交 Build Mode 之前的”结构性安全”机制。
• Package Firewall（blog-package-firewall.md）：网络层的安装时拦截（与 Socket 合作），在代码到达环境前拦截已知恶意/被攻陷的包；官方给出针对 LLM 驱动包选择的显式失败分类——typosquat（域名抢注式仿冒包）、“slopsquat”（LLM 幻觉出一个听起来合理但不存在的包名，攻击者预先抢注该名字）、过时推荐（真实存在但训练截止后被披露漏洞的包）。日均约 8,000 次拦截。是更大的”Replit Auto-Protect”套件（还包括 Security Agent + Security Center，本阶段未详细展开）的一部分。
• 混合安全扫描白皮书（blog-securing-ai-generated-code.md，完整白皮书未抓取，仅读取博客摘要）：核心发现是纯 AI 安全扫描是非确定性的（同一漏洞在不同语法形式/prompt 措辞下会被分类不一致），且无法在没有真实漏洞信息源的情况下看到依赖级/供应链 CVE；Replit 生产环境采用的是显式混合方案——确定性静态分析 + 依赖扫描作为基线，LLM 推理叠加在其上处理业务逻辑/意图层面的问题。
• 快照/checkpoint 系统兼作安全网（blog-snapshot-engine.md）：每个 agent 动作都可通过 git + CoW 文件系统/数据库 checkpoint 回滚；路线图中明确提出”在隔离的分叉沙箱内放松护栏”，理由正是分叉环境是一次性的、可丢弃的——即隔离性是”允许给 agent 更多危险能力”这一决策的许可证。

沙箱与执行隔离

这是找到的最深入的基础设施维度（blog-snapshot-engine.md，专门文章）：

• Bottomless Storage Infrastructure（2023 年的既有工作）：基于 Network Block Device 协议的虚拟块设备，后端为 GCS，切分成 16 MiB 不可变分片；一个 manifest 把某个文件系统版本映射到其分片指针。“复制”变成”复制 manifest”（无论文件系统实际大小、耗时恒定）——这是”Remix”（项目复制）和 agent checkpoint/回滚共用的底层原语。
• git 版本控制叠加在其上：agent 在每个”完成度”checkpoint 提交一次 git commit；如果 git 状态本身损坏，可以从更早的文件系统快照恢复 git 对象图（而不仅是 git reflog），另外每个 app 还有一个独立的、不可变追加式 git remote 作为第二道防线。
• 可分叉数据库：dev/prod Postgres 跑在未经修改的本地实例上，其数据目录位于同一套 CoW 块设备基础设施之上——数据库的 checkpoint/恢复就是一次 manifest 交换，与文件系统 checkpoint 是同一机制，支持为新的 app 副本做完整数据库分叉。
• 路线图（截至 2025-12 发文时未上线）：“Transactional Compute”——并行启动多个分叉（代码+数据库）沙箱，让 agent 在每个沙箱内放松护栏地实验，然后把最佳结果原子化合并回去；官方明确把这与”并行采样”这一推理时扩展技术挂钩，援引 Anthropic Claude 4 在 SWE-bench 上 72%→80% 的数字。
• REPL 测试沙箱（blog-automated-self-testing.md）：给测试子 agent 用的独立 JS vm 模块沙箱，与主 agent 的执行上下文隔离，运行由 Playwright 驱动的浏览器自动化代码及注入的辅助函数——一个专为验证（而非构建）设计的、更窄的第二沙箱层。
• Neon DB branching（blog-db-migrations.md）：专门用于迁移安全的生产数据库分支-测试-再提升模式，是第三种沙箱机制（逻辑上独立于 CoW/git 系统，依托 Neon 自身的 branching 功能）。

与模型的协同设计

• Agent v2 与 Claude 3.7 Sonnet 联合发布（blog-agent-v2.md）：“与 Anthropic Claude 3.7 Sonnet 发布合作，我们很高兴宣布 Replit Agent v2 发布”——显式联合发布框架，但文章没有给出任何”共同设计了什么”的技术细节（未披露共享的 prompt/工具格式规范）。
• Replit↔Claude 集成（blog-replit-in-claude.md，2026-06-17）：“官方 Replit Connector” 让 Claude（具体是 Claude Design）可以把构建任务交给 Replit Agent 执行——这是 MCP 连接器层面的集成，不是模型训练/协同设计的证据；技术细节薄，多为产品发布层面的表述。
• 对”harness 与模型协同演化”的明确表态（blog-decision-time-guidance.md 结尾段落，是本维度里找到的最清晰的协同设计哲学陈述）：“随着模型智能和长程能力的演进，外部反馈以及工具层的角色也会改变。对于下一代模型，我们预期会有更强的自我反思能力，使它们更不需要依赖外部反馈”——即 decision-time guidance 被明确框定为一种针对当前一代模型弱点的补偿性机制，预期随模型进步而重要性下降。
• 未发现 Replit 为 agent 微调自研基础模型的证据（blog-code-at-scale.md 里提到的”Code Repair”模型看起来是一个更窄的内部模型，不是主 agent 驱动模型，且未详细展开）——不在证据不足的情况下推测更多模型训练层面的协同设计。

轨迹利用（session/trajectory 是否反哺训练/评测）

确认在两条独立战线上均有大量文档化证据：

• 评测时复用（blog-evaluating-improving-agent-at-scale.md）：ViBench 的 PRD 明确”取自匿名化的 Replit 生产轨迹”——真实用户会话数据播种了基准的任务分布。Telescope 的 trace 聚类直接喂给自改进闭环的假设生成阶段（见”自进化”节）。
• 训练数据复用 —— “Backer” 管线（blog-code-at-scale.md，本维度最详细的来源）：文中明确陈述”timeline 数据”（执行日志、LSP 诊断、OT/操作转换编辑动作——即细粒度轨迹/调试数据）被用作”我们的 AI 模型（例如 Code Repair）的训练数据”。隐私声明（原文引用）：“我们只把公开 Repl 用于分析和 AI 训练：任何非公开的用户代码——包括所有企业账户——都不会被审阅。即使对公开 Repl……所有用户代码也都经过匿名化处理，所有 PII 都被移除”。规模数字：存储超过 3 亿个仓库，日均约 7000 万个文件被编辑，每月写入超过 1 PiB。
• Progressive Classification 设计（同文）明确是为了避免”不加区分地把 100% 的 Repl 内容发给第三方 LLM”（出于成本和隐私考虑）——先算便宜的确定性特征（字符串/AST/lint 统计），LLM 分类只留给剩余约 1% 量级的歧义案例。
• 这套管线本身是公司级数据基础设施（也服务于产品/增长/销售策略），并非专为 agent 训练而建，但文章明确把 AI 模型训练列为其用途之一，因此可以确认计入”轨迹→训练”复用，与”轨迹→评测”复用（自进化节）是两条独立但相关的线。

与同类 harness 的关键差异（1-3 条，可以先留一句概述，后续 synthesis 阶段会做跨 harness 对比）

概述性初判（详细跨 harness 对比留待 synthesis 阶段）：

1. “code-use” 工具范式——Replit 明确拒绝了主流的”逐动作 tool-call”设计（Playwright-MCP/Stagehand/CUA 风格），转而让 agent 在注入了辅助函数的 JS REPL 里写代码来完成浏览器自动化，这与大多数 harness（包括 Claude Code）默认的 JSON-schema tool-calling 范式形成对照，值得作为一个独立设计流派记录。
2. checkpoint 即基础设施级 CoW 快照，而非应用层版本控制——git commit 只是双轨机制中的一半，另一半是底层 Bottomless Storage 的块级 CoW manifest 复制（同时覆盖代码和数据库），这种”文件系统级”而非”应用级”的可回滚性在其他 harness dossier 中未见到对应设计。
3. decision-time guidance 是目前所见 harness 里对”静态系统提示为何失效”论证最详尽、量化数据最丰富的公开披露（15% 工具调用增量、90% 成本降低等具体数字），但同时官方自己承认这是”补偿当前一代模型弱点”的过渡性设计，而非声称永久架构优势——这种自我定位的坦诚程度在同类工程博客中也较为少见。

原始源码定位

• repo: 无公开源码（closed-source 托管 SaaS 产品，无 GitHub 仓库、无 npm 包、无可 clone/pin 的 CLI）
• commit/version analyzed: 不适用——本页证据全部锚定在官方工程博客文章的发布日期（跨度 2024-08-14 至 2026-06-23），抓取日期统一为 2026-07-07
• 关键文件列表（相对路径，均指本地存档的博客文章，不是源码）：
  • sources/harness/replit-agent/blog-automated-self-testing.md — 覆盖 Agent Loop / 记忆 / 工具 / 编排 / 沙箱 / 自进化多个维度，单文档信息密度最高
  • sources/harness/replit-agent/blog-decision-time-guidance.md — Prompt 设计 / agent loop 控制 / doom-loop 模型切换恢复
  • sources/harness/replit-agent/blog-snapshot-engine.md — 沙箱 / CoW 快照 / checkpoint / 并行采样路线图
  • sources/harness/replit-agent/blog-evaluating-improving-agent-at-scale.md — ViBench / A-B 测试 / Telescope / 自改进闭环
  • sources/harness/replit-agent/blog-agent-4-intro.md — 并行子 agent / 任务分解与合并
  • sources/harness/replit-agent/blog-db-migrations.md — dev/prod 数据库隔离 / 确定性迁移生成
  • sources/harness/replit-agent/blog-custom-skills.md — SKILL.md 格式 / Custom Instructions
  • sources/harness/replit-agent/blog-package-firewall.md — 供应链安全 / 安装时拦截
  • sources/harness/replit-agent/blog-code-at-scale.md — Backer 数据管线 / 轨迹反哺训练
  • sources/harness/replit-agent/blog-agent-v2.md — Agent v2 / Claude 3.7 Sonnet 联合发布
  • sources/harness/replit-agent/blog-plan-mode.md — Plan/Build/Edit 三态编排
  • sources/harness/replit-agent/blog-mcp.md — MCP 协议说明（偏通用科普）
  • sources/harness/replit-agent/blog-securing-ai-generated-code.md — 混合安全扫描白皮书摘要
  • sources/harness/replit-agent/blog-replit-in-claude.md — Replit↔Claude Connector

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/replit-agent/ 下共 17 个文件（1 份 NOTES.md 阶段一笔记 + 14 篇博客文章 + 2 份分类索引页）：

• NOTES.md — 阶段一完整调研笔记（本页写作的直接依据）
• blog-evaluating-improving-agent-at-scale.md
• blog-decision-time-guidance.md
• blog-snapshot-engine.md
• blog-automated-self-testing.md
• blog-db-migrations.md
• blog-agent-4-intro.md
• blog-agent-v2.md
• blog-custom-skills.md
• blog-package-firewall.md
• blog-securing-ai-generated-code.md
• blog-mcp.md
• blog-plan-mode.md
• blog-code-at-scale.md
• blog-replit-in-claude.md
• blog-eng-category-index.md（发现用分类索引页）
• blog-ai-category-index.md（发现用分类索引页）

已知未抓取项（阶段一 NOTES.md 中明确标注，供后续阶段判断是否需要补充）：ViBench 官网 vibench.ai 原站、ViBench ACM 论文（doi.org/10.1145/3786335.3813162，付费墙）、securing-ai-generated-code.replit.app 完整白皮书、Braintrust “Topics” 架构第三方深挖文章、若干安全类衍生文章（safe-vibe-coding、16-ways-to-vibe-code-securely 等，与已覆盖内容重叠）、Anthropic 关于 agentic eval 基础设施噪声的文章（仅读取了 Replit 一方的引用）。