v0 (Vercel)：闭源托管产品，无公开 agent-loop 源码，但从 SDK 消息协议 + 官方文档可复原出「组合式模型」架构

v0 (Vercel)

一句话定位

v0 是 Vercel 的闭源托管代码生成/构建产品（v0.app，原 v0.dev），其 agent 循环、编排逻辑本体完全没有公开源码可读；本 dossier 依据官方架构博客（“v0’s Composite Model Family”）与十余篇官方文档，加上真实存在、可读的配套客户端 SDK vercel/v0-sdk（消息格式、API 契约），做的是架构级复原而非源码阅读——凡是没有一手证据支撑的结论都在正文中明确标注为”未公开/未证实”。

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

• v0 本体（agent loop / 后端编排 / RAG 检索 / AutoFix 模型服务代码）无公开仓库，不存在 vercel/v0 这样的开源库。确认方式：官方文档与博客通篇均以产品行为描述，从未指向一个开源仓库；vercel/v0-sdk 的 README/scope 也明确自己只是”SDK for the v0 Platform API”，即调用 v0 托管服务的客户端库，不含服务端实现。
• 唯一可读的真实公开代码是 github.com/vercel/v0-sdk，分析基准 commit 001fae4d36b3b627c9e89af0e00a55f31c2b9c70（作者时间 2026-06-25 13:26:15 -0400），当时包版本 v0-sdk@0.16.4 / @v0-sdk/react@0.5.0 / @v0-sdk/ai-tools@0.3.8。这是客户端 SDK + React 渲染组件 + AI-SDK 工具包装，不是 harness 本体，但其消息格式、content-part 类型枚举、API 请求/响应类型是目前唯一的、字面意义上的”源码级”证据。
• 关键路径（均在 vercel/v0-sdk 仓库内，相对路径）：
  • packages/react/src/types.ts —— MessageBinaryFormat、MessageProps 等类型定义。
  • packages/react/src/components/content-part-renderer.ts —— content-part type 字符串到 UI 渲染的 switch 语句，是复原 agent-loop 任务分类的最佳证据（task-thinking-v1、task-search-web-v1 等）。
  • packages/react/src/hooks/use-streaming-message.ts —— SSE + jsondiffpatch 增量流式协议实现。
  • packages/v0-sdk/src/sdk/core.ts —— 底层 fetcher/streamingFetcher，session-token 头处理。
  • packages/v0-sdk/src/sdk/v0.ts（2459 行，仅抽样/grep，未逐行读完）—— 完整 REST client + 全部请求/响应 TypeScript 类型。
  • packages/ai-tools/src/tools/chat-tools.ts —— 用 Vercel AI SDK 的 tool() 把 v0 chat 操作包装成可被第三方 LLM 调用的工具。
  • packages/ai-tools/src/tools/hook-tools.ts —— webhook CRUD 工具。
  • examples/v0-clone/app/api/chat/route.ts —— 参考 Next.js 路由 handler，展示同步/流式/已存在会话分支与限流。
• 另有 github.com/vercel/sandbox（Vercel Sandbox SDK/CLI，v0 运行时依赖的底层计算原语）存在但未克隆，仅读了其官方文档页 vercel.com/docs/sandbox（超出 v0-specific 范围，是通用 Vercel 基础设施）。
• 一手信息来源以官方架构博客 “v0’s Composite Model Family”（vercel.com/blog/v0-composite-model-family，2025-06-01，作者 Aryaman Khandelwal / Gaspar Garcia / Ido Pesok / Max Leiter）为核心，辅以 15 篇 v0.app/vercel.com 官方文档页全文抓取（详见文末存档清单）。抓取日期 2026-07-07。

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

未公开逐行可读的控制流代码；以下为间接复原，明确标注证据来源：

• packages/react/src/components/content-part-renderer.ts（第 75-153 行）中的 content-part 类型枚举 task-thinking-v1、task-search-web-v1、task-search-repo-v1、task-diagnostics-v1、task-read-file-v1、task-coding-v1、task-start-v1、task-generate-design-inspiration-v1，以及对任意未来 task-*-v1 的通用兜底渲染——这本质上就是 agent 逐步执行记录序列化进消息流的产物。据此可复原出的循环形态：发出 task-start-v1 → 执行工作（搜索/读文件/诊断/写代码）→ 发出完成态 content part → 流式输出文本 →（任务队列非空则重复）→ 最终 assistant 文本。这是推断，不是读到的调度器代码。
• docs/agentic-features（官方文档，仅部分逐字保存）称 agent “coordinates multiple tasks”、“maintains context”，用户可随时 Stop，或用 Auto-continue 让其”自动推进多步任务”——即循环在任务粒度（而非 token 粒度）上可恢复/可中断。
• MCP 服务器指南（docs-api-v0-mcp-server.md）文档化了一个 “Resolve pending task” 操作（POST /v2/chats/{chatId}/messages/resolve）——这是循环可在执行中途暂停等待人工输入（批准计划、授权、回答问题）然后恢复的证据，说明这不是一次不间断生成，而是带 pending/resolved 状态的状态机。
• sdk-v0-client.ts 约 122 行：ChatSummary.latestVersion.status: 'pending' | 'completed' | 'failed' —— 确认”生成即版本”有明确的生命周期状态字段。
• 结论：无法对循环的确切终止条件、最大步数、异常处理做源码级断言；以上均为从消息协议/API 契约反推的架构级证据。

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

• Composite-model 博客”Pre-processing”一节原文：“We also include recent messages from your chat to maintain continuity, and summaries of older ones to optimize the context window.” —— 明确证实存在滚动摘要式长上下文压缩，区别于简单截断。
• Versions（docs-versions.md）是持久化的检查点/记忆机制：每条产出代码的消息创建一个新的不可变版本；恢复旧版本会创建新版本（线性历史，chat 内不分叉；分叉需 fork 出独立 chat，对应 SDK 里的 chats.fork）。
• 沙箱文件系统持久化（docs-sandbox.md）：“The filesystem persists between sessions for the same chat”，沙箱闲置后休眠、下次访问自动恢复，单次会话上限 5 小时；按 chat 隔离即是记忆/会话边界，状态不跨 chat。
• “Memories & Skills” —— 仅在 docs-design-systems-2.md 的 FAQ 里被顺带提及：付费团队可在工作区设置中开启 “Restrict Memories & Skills”，把团队级记忆/技能编辑权限收紧到仅所有者（其他人只读）。不存在独立的 /docs/memories 页面（已确认 404）——Memories 是真实存在的产品功能（团队级长期记忆存储），但除访问控制开关外没有单独文档，数据模型、作用域、检索机制均未公开。这是一个明确的文档缺口，不做推测填补。
• Session-token 机制（sdk-core.ts 第 41-44、56-59 行）：响应头 x-session-token 被捕获并在后续请求中回放——这是传输层的服务端会话亲和机制，与 chat/version 模型是分开的两层。
• API 限制（docs-api-platform-overview.md）：单 chat 上限 10,000 条消息，更早的消息”自动归档”——这是平台层面上下文窗口管理的又一具体数字。

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

• Bash 工具：docs-terminal-commands.md 明确命名 —— “v0’s Bash tool runs commands in the same sandbox…”。每条命令都在项目根目录下的全新 shell 中运行——无持久 shell 状态，agent 必须显式串联操作，这是一个真实的架构约束而非单纯 UX 说明。
• Delete 工具：rm -rf 等递归强制删除在所有权限模式下均被系统级拒绝；文件删除改走专门的 Delete 工具，理由是”保持沙箱状态与编辑器一致”（docs-terminal-commands.md，“What’s always blocked”一节）。
• 权限模式——三种，用户可配置，跨 chat 持久化：Ask（每条非白名单命令都需确认）、Auto（默认；白名单命令静默执行，其余询问）、Full（除系统级拒绝项外全部执行）。默认白名单包含只读文件系统操作（ls, find, cat, head, tail, tree, wc, cd, pwd）、搜索（grep, rg, jq）、本地 git 只读命令（git status/log/diff/show）、只读的 gh/vercel CLI 子命令、echo, whoami，以及值得注意的 agent-browser（命名的浏览器自动化工具）与 sleep（计时工具）。
• 规则格式与 Claude Code 的 Bash(pattern) 风格完全一致：JSON 存储的 allow/ask/deny 三个数组，作用域分 User 与 Team 两级（合并语义是”任一允许即允许、任一拒绝即拒绝、否则询问”，即最严格者优先中带例外的合并规则）。文档给出了完整的规则块示例。
• MCP 工具：v0 支持 (a) 自带 MCP 服务器（No Auth / Custom Headers / Bearer / OAuth 2.0），预置 Context7、Glean、Granola、Hex、Linear、Notion、PostHog、Sanity、Sentry、Zapier 等；(b) Marketplace 集成背书的 MCP（Neon、Supabase、Upstash、Stripe 等），三种工具权限模式：Disabled / Ask for Approval（手动，默认）/ Always Run（自动，5 秒可撤销窗口）。文档明确写道：“Even in auto mode, dangerous operations still require explicit approval”——无论用户设置如何，都有一层硬编码的安全兜底。
• MCP 工具作用域限定：资源级（例如一个 Neon 集成只绑定一个具体数据库实例）、项目级、上下文注入（资源 ID、集成实例名自动带入工具调用）以防跨项目泄漏。
• API 层面的工具/技能挂载：mcpServerIds: string[] 与 attachedSkillIds: string[] 是 chats.create 与 chats.sendMessage 的字面请求字段（sdk-v0-client.ts 约 759 行、905-906 行）——工具/技能是按消息挂载的，不只是 chat 全局配置。
• v0 自身也是 MCP 服务提供方（而非仅消费方），地址 https://v0.app/api/mcp，仅支持 OAuth（文档明确写”Do not put a v0 API key in your MCP client configuration”），暴露 7 个工具，与 v0 API v2 端点一一对应（创建/列出/获取 chat，列出/发送消息，resolve task，获取预览）。
• 预装第三方 agent（Claude Code）在沙箱终端里是另一个”工具”层面的存在——详见 Skill 一节；它刻意不受v0 自身工具权限系统管辖（是 OS 级终端访问，治理体系完全独立）。

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

• 博客原文（“Pre-processing”一节）：“First, v0’s system prompt defines v0’s response format and includes information about v0’s capabilities. We also include recent messages from your chat to maintain continuity, and summaries of older ones… Finally, we retrieve additional context based on your query from our own dataset, pulling from documentation, UI examples, your uploaded project sources, internal Vercel knowledge, and other sources.” —— 明确的三阶段动态 prompt 组装：(1) 静态系统提示（响应格式 + 能力说明）→ (2) 近期消息窗口 + 摘要历史 → (3) RAG 检索上下文（文档/UI 示例/项目源码/内部知识）。
• 未发现任何泄露/逐字系统提示文本——这只是架构层面的披露，不是实际 prompt 字符串。网上流传的第三方”v0 system prompt 泄露”内容未采用，遵循只用官方一手来源的硬性要求。
• Instructions 功能（docs-instructions.md）= 用户自定义的可复用 prompt 片段，通过消息输入框的勾选项按消息挂载；两个内置预设：“Be Concise” 与 “Plan Mode”（后者：“先生成详细计划……再等待你批准后才继续”，一种显式的”先计划后批准”prompting 模式，用户可开关）。
• 设计系统 skill（见下节）同样作为附加上下文，通过 attachedSkillIds 注入 prompt 组装管线。

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

• 模型路由：SDK 类型中发现的 modelConfiguration.modelId 枚举值为 'v0-auto' | 'v0-mini' | 'v0-pro' | 'v0-max' | 'v0-max-fast'，另在文件中某处旧类型里还出现 'v0-opus-4.7'（sdk-v0-client.ts 约 96-103 行 vs 约 1592-1596 行——同一文件中两处枚举不完全一致，很可能是 v1/v2 API 版本差异，未能独立确认哪个是当前有效值，如实标注分歧而非择一断言）。v0-auto 本身就是内部模型路由存在的证据——它与博客描述的”基础模型 + Quick Edit”二分是并存的、独立的另一层路由。
• Quick Edit 流水线（博客原文）：“For smaller edits, parts of your request are routed to our Quick Edit model that is optimized for speed… optimal for tasks with narrow scope, like updating text, fixing syntax errors, or reordering components.” —— 确认了按任务范围分类路由：大范围生成走前沿基础模型，窄范围编辑走独立的快速专用模型。这是整个 harness 里”router”证据最扎实的一处。
• 未发现多 agent / 子 agent 派生架构——文档与博客通篇未出现”sub-agent”、“delegate”、“orchestrator agent”等字样。v0 架构上是单一 agent + 组合式后端管线（基础模型 + AutoFix + Quick Edit + RAG），不是 LangGraph/AutoGPT 意义上的多 agent 系统。明确记录为未实现/无证据，不假设其存在。
• 模型版本旁证（博客）：v0-1.0-md 用 Anthropic Sonnet 3.7，v0-1.5-md 用 Sonnet 4 —— 确认基础模型是可替换的（这正是组合式架构的设计初衷），2025 年 6 月发文时是 Anthropic 系。

Skill / 插件体系

• Design Systems 2.0 是一套正式的 Skill 系统，docs-design-systems-2.md 有完整规范：
  • “skill” 定义为”一小组聚焦的指令，v0 随你的工作保存并在相关时拉入使用”。
  • 持久化为 v0.json manifest，schema 包括：version（整数，当前为 1）、referenceWorkspace.sources[]（最多 3 个只读 GitHub 源，各含 id、type: "github-repo"、repo.org/name、ref、mountPath，形如 /vercel/share/v0-reference-workspace-sources/<org>/<repo>/<ref>）、environment.providers[]（shared-env-vars 携带环境变量 id，或 vercel-project 携带 projectId）、starter.source（skill-directory | empty | v0-default）+ starter.path。
  • 导入流程本身是 agentic 的：v0 发现源 → 构建 starter app → 暂停等待人工审核后才保存 → 校验 → 返回校验后的链接。这是一个具体的”agent 提议、人类批准、再持久化为可复用 skill”闭环。
  • Skill 通过 prompt 工具栏按 chat 挂载，或在 prompt 中按名引用；attachedSkillIds 是确认存在的字面 API 字段。
  • 治理：默认任何编辑者可创建/编辑/删除 skill；付费团队可切换”Restrict Memories & Skills”为仅所有者可编辑，其余只读。
• 预装 agent（docs-pre-installed-agents.md）是第二个、性质不同的”插件式”存在：Claude Code（及未具名的其他 agent）预装在沙箱内，通过 CLI 包装（如 claude 命令）从终端调用。流量被强制经过 Vercel AI Gateway（出于模型访问策略与分包商合规原因）；直接二进制执行、绕过 Gateway、安装任意第三方 agent 均被明确标为**“unsupported / at your own risk”**，Vercel 声明对此类流量不承担可见性/责任。企业版默认关闭（需手动开启），其余套餐默认开启。
• Marketplace 集成（Neon、Supabase、Upstash、Stripe、fal、Deep Infra、Grok/xAI 等）是第三个扩展面，基于工具调用而非指令注入（见工具体系一节）。

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

• 这是文档证据最扎实的一个维度——自研 AutoFix 模型（vercel-autofixer-01）是一个真实的”在自身错误上训练”反馈闭环，博客原文：
  • 动机：“Language models are stochastic… Some consistently over-format with markdown, others misplace files or introduce subtle bugs. We use a comprehensive set of evals, along with feedback from v0.dev users, to track these patterns.”
  • 演进路径：早期版本 = 确定性规则 + Gemini Flash 2.0 作为 AI 纠错器 → 之后替换为自研训练的模型。
  • 训练方法：强化微调（Reinforcement Fine-Tuning, RFT），与 Fireworks AI 合作完成，“经过多轮训练迭代”，优化目标是”最小化各追踪类别上的错误率”（博客中给出了按类别的错误率训练曲线图——是真实训练曲线证据，不只是营销话术）。
  • 基准结果：vercel-autofixer-01 得分 86.14（error-free-output-rate）@ 8,130 字符/秒，对比 gemini-2.5-flash-preview 89.55 @ 559 字符/秒、gpt-4o-mini 83.33 @ 238.9 字符/秒——即以通用模型 10-40 倍吞吐换取接近的准确率，这正是用 eval 派生的错误信号做 RFT 专精小模型的意义所在。
  • 该模型在流式生成中途（拦截基础模型仍在生成的输出流）与流式结束后各跑一次，外加一次确定性的格式 linter 最终纠错——即”中途拦截 → 流后模型二次纠错 → 确定性 linter”三级纠错级联。
  • 另有面向用户、按需触发的 “Fix with v0”（docs-agentic-features.md）：是同一纠错能力的用户侧版本，特定针对部署阶段的错误/警告（而非仅生成时），未编辑代码每天 20 次免费，之后按额度计费。
  • 未发现 harness 从实时用户会话轨迹更新自身权重的证据（即没有”从你的具体对话中学习”这类持续训练声明）——RFT 训练被描述为 Vercel 侧的离线过程，基于 eval 集 + 聚合用户反馈信号，不是逐用户在线学习。这是需要精确区分的一点：不能把”eval 驱动的模型训练”等同于”在线自我修改”。

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

• 消息 content-part 流本身就是 trace 格式：每个工具/任务步骤都被序列化为消息二进制格式里的一个类型化 content part（见 Agent Loop 一节的 task-* 类型枚举）——这就是终端用户在 UI 中可见的执行轨迹（进度指示器、截图、引用链接、docs-agentic-features.md 所述的”tool execution cards”）。
• MessageBinaryFormat（react-types.ts 第 5 行）：[number, ...any[]][] —— 一种紧凑的元组数组线格式（类型打标行），客户端经由 jsondiffpatch 增量、通过 SSE 重建（use-streaming-message.ts）。这是 Vercel 自研的二进制/增量协议，不是 OpenAI tool_calls 数组或 Anthropic content-block stream 这类标准格式——值得标注为一个真正独特的设计选择。
• Webhooks（ai-tools-hook-tools.ts、sdk-v0-client.ts 中的 HookDetail/HookEventDetail 类型）：事件类型包括 chat.created/updated/deleted、message.created/updated/deleted/finished，每次 webhook 投递都带自己的 status: 'pending'|'success'|'error'——这是外部/程序化可观测性面（与 UI 内 trace 相对），供集成方在真实事件之上搭建自己的 trace 流水线。
• 部署侧可观测性完全继承自 Vercel 平台本身：部署日志、“Vercel Toolbar”、分析、Core Web Vitals——不是 v0 专属的埋点，只是 Vercel 标准产品可观测性面套用到 v0 生成的应用上（docs-deployments.md）。
• 浏览器操作 trace：v0”会把它看到的截图发给你”（docs-agentic-features.md）——这是针对该特定工具的轻量可视化 trace，不是结构化日志。
• 未公开任何内部结构化 trace/日志 schema（如 OpenTelemetry span）供 Vercel 服务端自用调试——以上均为面向用户/API 的 trace 面，没有更深层的披露。

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

• 威胁模型明确声明（docs-security.md 原文）：“v0 doesn’t take LLM-generated code for granted. We consider all code potentially incorrect or adversarial” —— 执行前代码分析、沙箱执行、输入校验、“对抗性测试”。
• 密钥管理：依赖 Next.js 自身的 server/client 环境变量边界约定（NEXT_PUBLIC_ 前缀 = 客户端可见，其余仅服务端）；v0 会静态分析 NEXT_PUBLIC_ 的使用并告警/自动重构（把代码搬到 Route Handlers/Server Actions）——这是一个具体的自动化密钥卫生机制，不只是书面政策。
• 沙箱环境变量继承自关联的 Vercel Project；预览 iframe 只能读取 Development 环境——“敏感环境变量”（Vercel 的一个独立标记）被明确排除在 v0 预览可访问范围之外（docs-vercel-integration.md）。
• 企业安全：SOC 2 Type 2（Security/Confidentiality/Availability）、GDPR、SSO（SAML）、RBAC、审计日志、会话控制、可选择退出数据训练、数据隔离（客户间训练数据”无交叉污染”）。
• 审批门机制是本维度证据最扎实的部分——存在三层独立的审批：
  1. 终端/Bash 权限模式（Ask/Auto/Full）——见工具体系一节。
  2. MCP/marketplace 工具权限模式（Disabled/Manual/Auto，即便 Auto 模式下”危险操作”仍有硬编码的强制审批）——见工具体系一节。
  3. 系统级无条件拒绝列表（rm -rf 等），任何权限模式都无法覆盖——见工具体系一节。
  4. “Resolve pending task” API 原语——一个通用的”暂停等待人工输入”机制，可用于”批准计划、回答问题、授予权限、或完成集成设置”（docs-api-v0-mcp-server.md）——这是上述 1-3 层背后的统一抽象：所有审批门最终都表现为一个 chat 被阻塞的”pending task”。
• 部署策略（团队级）：可限制哪些机制（Git、CLI、REST API、Deploy Hooks、Marketplace）被允许触发部署——比逐命令权限系统更粗粒度的组织级门禁。
• 漏洞上报：security@vercel.com，标准做法，非 v0 专属。

沙箱与执行隔离

• 基于 Vercel Sandbox，据 vercel.com/docs/sandbox 描述运行在 Firecracker microVM 内的 Amazon Linux 2023 guest 上（“Each sandbox runs in a secure Firecracker microVM with its own filesystem and network”）。可用运行时：node26/node24/node22/python3.13（默认 node24），用户 vercel-sandbox 带 sudo，默认工作目录 /vercel/sandbox。
• v0 专属的沙箱语义（docs-sandbox.md）：每 chat 一个沙箱（不是按用户、不是按组织）——“Files, env vars, and running processes never cross from one chat to another”。文档明确了三层隔离边界：按 chat、按用户/团队（只能通过显式的 chat 分享触达）、与生产环境隔离（部署运行在完全独立的基础设施上，各自有独立环境变量——沙箱永远不是已部署应用运行的那台机器）。
• 生命周期：首次需要时惰性创建（需要服务器的代码生成，或仓库导入）；文件系统在同一 chat 的多次会话间持久化；沙箱闲置时休眠、自动恢复；单次会话硬上限 5 小时；全新 chat 总是拿到全新沙箱（除非显式 fork/import，否则不带状态）。
• Sandbox Network Policy：默认出站 allow-all；团队所有者可在团队设置中限制沙箱可达的出站主机。
• 取代了旧的”浏览器端预览”（无法运行服务端代码/API 路由/真实数据库连接）——即 v0 把整个执行模型从纯客户端模拟升级为真实的服务端 VM，专门为支持 agentic/全栈工作而做（据 docs-sandbox.md 及 2026 年 2 月的产品重发博客）。
• 预装 agent（Claude Code）运行在同一个沙箱内，拥有与其他沙箱进程相同的文件系统/环境变量访问权限——文档原话”the same level of access that any process running in the sandbox terminal has”，即一旦进入沙箱，harness 自身工具执行与第三方 agent 执行之间没有额外的隔离层。

与模型的协同设计

• 这是 Composite-model 博客的核心论点——其设计理由是解耦：基础模型负责推理/生成；RAG 负责基础模型跟不上的、快速变化的框架知识；一个自研训练的 AutoFix 模型（不是基础模型本身）负责纠错；一个独立的 Quick Edit 流水线负责窄范围快速编辑。明确的设计目标（原文）：“as base models improve, we can quickly upgrade to the latest frontier model while keeping the rest of the architecture stable” —— 即刻意把前沿模型设计成可替换组件，而非与 harness 联合训练/协同进化。
• 具体替换证据：v0-1.0-md（Sonnet 3.7）→ v0-1.5-md（Sonnet 4），“其余技术栈保持稳定”——一次真实的、有日期的前后替换，不是假设情形。
• 基准表（博客）：v0-1.5-md/lg 在内部”无错误生成率”评测上大幅超过其自身的基础模型对照组（93.87 / 89.80，对比 claude-4-opus 78.43、claude-4-sonnet 64.71、gemini-2.5-pro 58.82、o3 58.82、gpt-4.1 58.82）——即无论底层前沿模型是谁，组合式管线（RAG + AutoFix + prompt 脚手架）都能在其之上明显加成，这是”协同设计确实在起作用而非纯营销”的直接证据。
• AI Gateway 是 v0 自身模型调用与预装第三方 agent（Claude Code）唯一的传输路径——这是一种”模型无关但受策略约束”的设计：无论底层用的是哪个模型、调用方是 v0 本体还是访客 agent，模型访问都被集中门禁/计量/分包商审计。
• vercel-autofixer-01 是”与 Fireworks AI 合作”训练的——Fireworks 是这个特定自研小模型的 RFT 训练/托管伙伴（基础/前沿模型本身来自 Anthropic/OpenAI/Google，经 Gateway 接入；AutoFix 模型是 Vercel 自有 IP，托管在 Fireworks 上）。

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

• AutoFix 模型存在明确的用户反馈闭环（博客原文）：“We use a comprehensive set of evals, along with feedback from v0.dev users, to track these patterns and identify areas where output consistently needs correction.” —— 用户会话结果（隐含：哪些生成被手动修正/重新提示、哪些部署失败）反哺 eval 集的筛选，进而驱动 vercel-autofixer-01 的离线 RFT 训练。这是轨迹驱动的eval 设计，不是”轨迹直接转梯度”的训练。
• 企业层级明确的退出条款：“Enterprise customers can opt out of having their content used for model training”（docs-security.md）——这是”非企业（免费/Pro）用户对话内容默认可用于模型训练”最有力的间接确认，但文档没有说明具体是哪个模型、用了多大比例的数据、以及具体机制。标注为：政策层面确认了轨迹复用的存在；技术管线（采样方式、权重、是基础模型还是仅 AutoFix）未公开。
• 非企业版 API 条款（docs-api-platform-overview.md，Platform API 部分”Data Privacy”条目）：“Your code remains private and is not used for training”——这与 docs-security.md 里企业退出条款所暗示的”非企业默认参与训练”存在直接矛盾或至少张力。本 dossier 如实记录为两份官方文档之间未解决的分歧，不擅自择一为准，留待后续澄清。
• 未公开：v0-1.5-md/lg 基础模型自身权重是否用 v0 会话数据做过微调（博客只讨论了 AutoFix 训练，未提基础模型微调）；是否存在任何在线/实时学习；除组合式模型博客中的两张表（无错误生成率；AutoFix 无错误率+吞吐）外没有更多 eval 基准细节披露。

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

• 与 Aider、Claude Code 等”可读源码、agent loop 明确”的 harness 相比，v0 是本调研系列里唯一完全闭源的样本——所有结论均属架构级复原而非源码阅读，这本身就是与其他 harness 最大的方法论差异，读者引用本页任何结论时应保持相应的置信度折扣。
• 独有的、有实证支持的设计是**“专精纠错模型”路线**（vercel-autofixer-01 用 RFT 训练出一个体积更小但吞吐高 10-40 倍的纠错模型，而非依赖通用大模型做自我修正）——这与多数 harness 依赖同一个基础模型自我反思/重试的做法（如 Aider 的 lint/test 反射循环、直接把错误喂回原模型）形成鲜明对比，是”为纠错单独训练专用小模型”而非”复用主模型多跑一轮”的少数已披露实例。
• 权限规则的字面格式（Bash(pattern) allow/ask/deny JSON 三数组）与 Claude Code 的权限规则语法高度一致，值得在跨 harness 对比阶段核实是否为巧合的行业收敛，还是团队间借鉴。

原始源码定位

• repo（v0 本体）：无公开源码，闭源托管产品（v0.app）。
• repo（配套 SDK，实际克隆读取）：https://github.com/vercel/v0-sdk
• commit/version analyzed：001fae4d36b3b627c9e89af0e00a55f31c2b9c70（作者时间 2026-06-25 13:26:15 -0400；v0-sdk@0.16.4 / @v0-sdk/react@0.5.0 / @v0-sdk/ai-tools@0.3.8）
• 关键文件列表（相对 vercel/v0-sdk 仓库根路径）：
  • packages/react/src/types.ts
  • packages/react/src/components/content-part-renderer.ts
  • packages/react/src/hooks/use-streaming-message.ts
  • packages/v0-sdk/src/sdk/core.ts
  • packages/v0-sdk/src/sdk/v0.ts
  • packages/ai-tools/src/tools/chat-tools.ts
  • packages/ai-tools/src/tools/hook-tools.ts
  • examples/v0-clone/app/api/chat/route.ts

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/v0-vercel/ 下：

• NOTES.md —— 本次调研的完整逐维度笔记（本 dossier 的直接来源）
• v0-composite-model-family.md + v0-composite-model-family-raw.html —— 核心架构博客（主要一手来源，全文读取）
• docs/blog-introducing-the-new-v0.md —— 2026 年 2 月 relaunch 博客
• docs/docs-sandbox.md —— v0.app/docs/sandbox
• docs/docs-pre-installed-agents.md —— v0.app/docs/pre-installed-agents
• docs/docs-mcp-integrations.md —— v0.app/docs/MCP
• docs/docs-ai-models.md —— v0.app/docs/ai-models
• docs/docs-terminal-commands.md —— v0.app/docs/terminal-commands
• docs/docs-code-editing.md —— v0.app/docs/code-editing
• docs/docs-instructions.md —— v0.app/docs/instructions
• docs/docs-security.md —— v0.app/docs/security
• docs/docs-api-platform-overview.md —— v0.app/docs/api/platform/overview
• docs/docs-api-v0-mcp-server.md —— v0.app/docs/api/v2/guides/mcp-server
• docs/docs-vercel-integration.md —— v0.app/docs/vercel-integration
• docs/docs-versions.md —— v0.app/docs/versions
• docs/docs-design-systems-2.md —— v0.app/docs/design-systems-2
• docs/docs-deployments.md —— v0.app/docs/deployments
• docs/vercel-sandbox-overview.md —— vercel.com/docs/sandbox
• sdk-excerpts/react-types.ts、content-part-renderer.ts、use-streaming-message.ts、sdk-core.ts、sdk-v0-client.ts、ai-tools-chat-tools.ts、ai-tools-hook-tools.ts、example-v0-clone-chat-route.ts —— vercel/v0-sdk @ 001fae4d3 的逐字源文件副本

已知硬缺口（不做编造，明确列出）：

• 无 v0 本体 agent-loop/编排/RAG 服务端源码可读；Agent Loop 与可观测性两节的内部机制均为从消息格式/API 契约反推，非直接读代码所得。
• “Memories” 功能真实存在（设置页有开关）但无独立文档，数据模型/作用域/检索机制未知。
• 未发现多 agent/子 agent 派生的任何证据，按”未实现”记录，不假设与 Claude Code 等 harness 对等。
• docs/security 与 docs/api/platform/overview 在”非企业内容是否默认用于训练”上直接矛盾，未在本页调和，如实并列。
• sdk-v0-client.ts 中两处 model-ID 枚举不一致（v0-opus-4.7 只出现在其中一处），未独立确认哪个是当前有效版本。