AI Research 技术调研

Warp Agent Mode / Oz：终端客户端已开源（AGPL/MIT），云端编排大脑 warp-server 仍闭源

43分钟阅读

Warp Agent Mode / Oz

一句话定位

Warp Agent（终端内本地 agent）与 Oz（云端多 agent 编排/”云端软件工厂”平台）是同一产品家族的两层：Warp Agent 是本地执行体，Oz 是把 Warp Agent、Claude Code、Codex（以及 Gemini/OpenCode，见下）当作可互换”harness”来编排的云端控制面。2026-04-28 Warp 将其终端/ADE 客户端开源（AGPL-3.0 / MIT 双许可，github.com/warpdotdev/warp），这不是营销披露，而是可编译的一手 Rust 源码，覆盖 agent 循环状态机、工具/action 分类体系、MCP 管理器、Skills 系统、多 harness 驱动（Claude Code/Codex/Gemini）、权限/审批引擎、密钥信封加密、Docker/Kubernetes/Namespace 隔离检测。但服务端编排大脑 warp-server（真正的系统提示文本、eval 打分逻辑、Agent Memory 写入触发算法）不在此仓库中，仍为闭源——本 dossier 对每条论断都标注了”client 侧可见 / server 侧不可见”的边界。

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

  • Repo: github.com/warpdotdev/warp，克隆于 commit a612c95919cb101515ad663df9ec0e3436930c47（作者时间 2026-07-06 17:56:02 +0000，--depth 1 浅克隆 master，2026-07-07 克隆）。完整克隆约 504MB，提取后未保留在本地磁盘，仅保留约 340KB 精选源文件于 key-files/。
  • 客户端 Rust 代码分布在 app/src/（应用层）与 crates/（库层）两棵目录树下，核心相关路径：
app/src/ai/
├── agent/
│   ├── mod.rs                    — ConversationStatus / CancellationOutcome / CancellationReason
│   ├── conversation.rs           — 4547 行；fetched_memories()/context_window_segments()/summarization 状态
│   ├── linearization.rs          — 任务树 DFS 线性化，compute_active_task_ids/compute_task_depths
│   ├── task.rs, task_store.rs    — 任务簿记
│   └── telemetry.rs              — AIIdentifiers 跨系统 trace-ID
├── facts/mod.rs, manager.rs      — AIFact/AIMemory 云对象模型（UI 层）
├── skills/*                      — bundled.rs / remote.rs / global_skills.rs（仅目录存在性）
├── mcp/file_based_manager.rs     — cwd 范围 MCP server 发现
├── blocklist/
│   ├── permissions.rs            — 1243 行；六大类权限 taxonomy
│   ├── action_model.rs, action_model/{preprocess,execute/*}.rs — 工具异步预处理/执行管线
│   └── action_model/execute/*.rs — 一文件一工具的执行器
├── execution_profiles/mod.rs     — 按 profile 的组织策略强制
├── ambient_agents/{mod,scheduled,spawn,task}.rs — 云端/定时 agent 任务模型
├── agent_sdk/
│   ├── driver/harness/{mod,claude_code,codex,claude_transcript,codex_transcript}.rs
│   ├── driver/harness/claude_code/{parent_bridge,wake_driver}.rs
│   ├── memory_store.rs           — 521 行；Agent Memory CLI（增删改查）
│   ├── federate.rs               — 工作负载身份联邦令牌签发
│   └── driver/error_classification.rs, retry.rs
└── tracing/{native,cloud_agent_auth}.rs

crates/ai/src/
├── agent/orchestration_config.rs — RunAgentsRequest, matches_active_config(), Harness 枚举
├── agent/action/mod.rs           — 960 行；完整 AIAgentActionType 枚举
├── project_context/{global_rules,model}.rs — ~/.agents/AGENTS.md + 项目规则
├── skills/{skill_provider,parse_skill}.rs — SKILL.md 解析 + 10-provider 跨生态发现
└── telemetry.rs                  — AITelemetryEvent + contains_ugc()

crates/isolation_platform/src/lib.rs — Docker/DockerSandbox/Kubernetes/Namespace 检测
crates/managed_secrets/src/envelope.rs — HPKE/Tink 密钥信封加密
crates/computer_use/src/{mac,linux,windows}/* — 平台原生 computer-use 后端
crates/warp_server_client/src/base_client.rs — agent_mode_evals 内部 eval 特性
  • 官方一手网页信源（docs.warp.dev 与 warp.dev/blog）作为代码之外的交叉验证，详见文末”一手源存档”。

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

  • Client 侧把循环建模为显式会话状态机而非裸 while(not done)：ConversationStatus（app/src/ai/agent/conversation.rs 全篇散布引用）包含 InProgress、Blocked { blocked_action }、Error、TransientError 等状态；终止/非终止的转移由 CancellationOutcome（app/src/ai/agent/mod.rs:126-141）裁决：KeepInProgress / Succeeded / Cancelled / FinalizedExternally，各自映射自一个较丰富的 CancellationReason 枚举（手动取消、自动云端 handoff、用户提交后续、用户中途运行 shell 命令、revert、delete、长时命令完成、CLI-subagent 接管、agent 退出 shell）——这是”这一轮为什么结束”的完整分类，而非单一布尔量。
  • 服务端权威的运行状态（对云端/编排 agent，来自官方文档 docs/orchestration.md）：INPROGRESS、SUCCEEDED、FAILED、BLOCKED（等待用户，如命令审批）、ERROR、CANCELLED。父 agent 观察子 agent 的这些状态转移来决定等待/追加消息/替换/结束——即编排场景下”继续 vs 停止”的决策被显式上抛给父 LLM，而非硬编码。
  • 工具执行走异步 preprocess → queue → execute 管线（app/src/ai/blocklist/action_model/preprocess.rs）：各 action 可乱序异步预处理，但强制按原始顺序执行/发出（PendingPreprocessedActions 缓冲乱序完成的批次，仅当更早排队的批次全部完成才释放）——这是”并发工具调用”与”严格轮次顺序约束”的调和机制。
  • 对 Claude Code/Codex 这类作为云端 agent 运行的第三方 harness，“继续/停止”不是单一长驻进程循环：Oz 把休眠/已退出的子 CLI 会话视为可恢复，通过写入 mailbox 消息 + 用 --resume/resume <session-id> 重新拉起 CLI 来”唤醒”（见 wake_driver.rs，详见记忆与 Router 章节）。即：launch → CLI 退出/阻塞 → mailbox 消息到达 → wake（带 resume 标志重新拉起）→ CLI 再退出 → 循环。
  • 未找到：Warp Agent 自身（第一方）循环里”继续/停止”具体的系统提示文本——该逻辑活在闭源的 warp-server 里，客户端只暴露状态机/编排层面，不暴露提示词字符串层面。

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

  • 两种独立的摘要类型（app/src/ai/agent/mod.rs:1850-1854）：SummarizationType::ConversationSummary（整会话压缩，通过 AIConversation 上的 was_summarized()/is_summarizing() 跟踪，摘要消息带 token_count）与 SummarizationType::ToolCallResultSummary（单条工具结果摘要，例如压缩巨大 shell/文件输出）。
  • 上下文窗口占用是显式分段统计：AIConversation::context_window_usage() 返回浮点利用率，context_window_segments() 返回 Vec<ContextWindowSegment>（conversation.rs:677-690）——客户端渲染的是”什么在占用上下文”的分解视图而非单一百分比；这些字段由服务端下发的 usage_metadata 填充（conversation.rs:2021-2030）。
  • 跨会话”rewind”/压缩机制：MoveMessagesToNewTask 是摘要专用的一个 action，用于把旧消息搬迁到一个独立 task，使根会话的活跃上下文缩小（conversation.rs:3044、task.rs:374、task_store.rs:310）——压缩的实现方式是”把旧历史分拆进子任务”而非字面删除。
  • 长期记忆（“Agent Memory”）：服务端建模为包含版本化 Memory 的 Memory Store，每条 Memory 带 source（client 侧观察到 MemorySource::Manual，很可能还有 agent 自写的来源未在此 CLI 暴露）和自由文本 reason（app/src/ai/agent_sdk/memory_store.rs，521 行全读，完整 CRUD：list/get/update store，list/create/update/delete/list-versions memory）。客户端还在会话消息上内联建模”已取用的记忆”：AIConversation::fetched_memories()（conversation.rs:1213-1232）按 (memory_store_id, memory_id) 去重、保留首次出现顺序——证实记忆是逐消息取用（类 RAG），而非一次性注入会话开头。Telemetry 也建模了 AgentMemory 引用类型，带 memory_store_id/memory_id（app/src/ai/agent/telemetry.rs:36-43）。
  • 据博客与产品页（blog/multi-harness-cloud-agent-orchestration.md、blog/agent-memory-product-page.md）：Agent Memory 明确跨 harness（从 Claude Code 和 Codex 会话也能形成记忆，不止 Warp Agent 自身）、Oz 自身可写（任务完成时自我更新）、支持可插拔数据源（文件/skills、MCP、数据库、其他企业应用），定位为客户自有/可导出数据；截至 2026-07-07 官方文案标注为”research preview”、候补名单制——未 GA。
  • 第三方 harness 的会话/轨迹持久化用于 handoff：对 Claude Code，Oz 上传完整 ClaudeTranscriptEnvelope（app/src/ai/agent_sdk/driver/harness/claude_transcript.rs）——主会话 JSONL、全部子 agent JSONL 转录、每个 agent 的 TODO JSON——按代码注释存于服务端（GCS backed），以 Warp 自己的会话 ID 为键。恢复时下载并在磁盘上重新落地到 ~/.claude/projects/<encoded-cwd>/（路径编码方式与 Claude Code 自身约定一致：/ 和 . → -），外加尽力更新 ~/.claude/sessions-index.json，使真实的 claude --resume <uuid> CLI 机制能透明接手——这是第三方 harness 本地↔云端↔云端 handoff 的具体机制。
  • Warp 自身会话的本地↔云端 handoff（非第三方 harness）：据官方文档（docs/handoff-local-to-cloud.md）——Warp fork 本地会话（完整转录，非破坏性）并捕获工作区快照（未提交的已跟踪 + 未跟踪文件改动），云端 agent 在继续前应用该快照；应用失败的改动会被报告但不阻塞其余部分落地。需要开启”Store AI conversations in the cloud”隐私设置，且目标环境的仓库需与本地检出匹配。
  • 全局/项目规则文件是一种上下文注入机制（而非严格意义的记忆），但功能上与记忆共同塑造”项目间被记住的东西”：~/.agents/AGENTS.md 全局规则文件被文件系统监听并热重载（crates/ai/src/project_context/global_rules.rs，全读），此外还有按目录范围解析的 ProjectRule（crates/ai/src/project_context/model.rs）。

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

  • 完整的第一方工具/action 面在单个 Rust 枚举 AIAgentActionType 中列举（crates/ai/src/agent/action/mod.rs，960 行全读）。代表性变体：RequestCommandOutput（shell 执行，带 LLM 提供的 is_read_only/is_risky/uses_pager 提示 + rationale 字符串 + citations）、WriteToLongRunningShellCommand、ReadFiles、UploadArtifact、SearchCodebase（语义/向量搜索）、RequestFileEdits（diff 式）、Grep、FileGlob/FileGlobV2、ReadMCPResource/CallMCPTool、SuggestNewConversation/SuggestPrompt、InitProject、OpenCodeReview、ReadDocuments/EditDocuments/CreateDocuments（Warp Drive 文档）、ReadShellCommandOutput、UseComputer/RequestComputerUse、InsertCodeReviewComments、StartRecording/StopRecording（computer-use 会话录屏）、ReadSkill、FetchConversation、StartAgent（legacy 单子 agent 派生，StartAgentVersion 用于版本兼容）、SendMessageToAgent（agent 间 mailbox）、TransferShellCommandControlToUser、AskUserQuestion（结构化多选，带 is_multiselect/supports_other）、RunAgents（批量多子 agent 编排）、WaitForEvents（agent 显式等待异步事件，带空闲超时）。
  • 每个 action 都有 cancelled_result()（中途取消时如何合成结果）和 user_friendly_name()/Display 实现——工具 schema 与其取消/渲染语义统一在一处定义。
  • 调用协议：action 以工具调用形式从服务端经 warp_multi_agent_api::Message 流到达（proto 定义，不在此仓库——warp_multi_agent_api 是外部/生成的 crate），客户端侧转换为原生 AIAgentActionType（crates/ai/src/agent/action/convert.rs，确认存在但未深读）。执行按 action 类型分发到 app/src/ai/blocklist/action_model/execute/*.rs（一文件一工具：grep.rs、shell_command.rs、read_files.rs、call_mcp_tool*、start_agent.rs、wait_for_events.rs 等）——确认一文件一工具的执行器模式。
  • MCP 作为一等工具来源：CallMCPTool/ReadMCPResource 是原生 action 变体（非通用透传），MCP server 按 cwd/repo-root 范围从文件系统发现（app/src/ai/mcp/file_based_manager.rs，get_servers_for_working_directory），配置文件变动时通过 FileMCPWatcher 实时响应。MCP server 还能转发进第三方 harness：例如 ClaudeHarnessRunner 把解析后的 MCP server 序列化为临时 JSON 文件，经 claude --mcp-config <path> 传入（app/src/ai/agent_sdk/driver/harness/claude_code.rs:294-303，serialize_claude_mcp_config）。
  • 工具上的权限门控按 action 类型 + profile 范围（详见”安全与权限”章）；工具执行层与权限层清晰分离（action 定义”做什么”，permissions 模块决定”是否可以不询问就执行”）。

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

  • 开源客户端中未发现泄露/逐字的系统提示文本（符合预期——真实系统提示文本在闭源的 warp-server 中组装/持有，不在此客户端仓库）。
  • Client 侧可见的是喂给（服务端组装的）提示词的上下文组装机制：(a) 分层规则文件——全局 ~/.agents/AGENTS.md（crates/ai/src/project_context/global_rules.rs）+ 按目录解析的项目本地规则（crates/ai/src/project_context/model.rs，find_applicable_rules、find_applicable_project_rules）；(b) 规则文件的实时文件系统监听，编辑后热重载而无需重启会话；(c) 针对第三方 harness 云端运行的显式系统提示追加机制：当 Oz 有补充系统提示需要注入时，claude_command() 构造 claude --append-system-prompt-file <tmp path>（app/src/ai/agent_sdk/driver/harness/claude_code.rs:201-218）——即 Oz 不整体接管 Claude Code 的系统提示，而是在其基础提示之上追加 Oz 专属补充（mailbox/编排指令）。追加内容包含一段固定前导常量 MESSAGE_BRIDGE_CONTEXT_PREAMBLE = "Oz mailbox update for this child run.\nSource: lead agent\nContext type: user-level coordination messages\n"（.../claude_code/parent_bridge.rs:41-42）——这是源码验证过的逐字字符串，非转述。
  • Codex 没有等价的 --append-system-prompt-file；Oz 改为向 Codex 配置目录写入一个 AGENTS.override.md 文件（CODEX_AGENTS_OVERRIDE_FILE_NAME，app/src/ai/agent_sdk/driver/harness/codex.rs:493）——确认每个 harness 都通过该 harness 自身原生的定制机制接受提示注入，而非统一注入 API；Oz 按 harness 各自适配。
  • Skills（详见下一章）是一种按需的提示注入：ReadSkill 是一个独立工具调用（AIAgentActionType::ReadSkill）——skill 正文不会全部塞进基础提示，只有 name+description（front-matter）被索引，agent 判断相关时才通过工具调用显式读取完整 skill 内容（渐进式披露）。

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

  • 这是证据最充分的一个维度，代码与官方文档（docs/orchestration.md，一手全读）双重印证。
  • 官方模型：严格一层深——一个父 agent 加一个或多个子 agent；子 agent 不再派生自己的子 agent（截至 2026-07）。支持四种父/子位置组合：local→local、local→cloud、cloud→cloud、cloud→cloud-local（子 agent 运行在父 agent 自己的环境内而非独立环境，用于共享文件系统/共享 shell 场景）。子 agent 可以运行在与父 agent 不同的 harness 上（例如 Warp-Agent 父 agent 派生一个 Claude-Code 子 agent，反之亦然）——这就是”多 harness 编排”的字面实现机制。
  • 子 agent 的运行状态：INPROGRESS、SUCCEEDED、FAILED、BLOCKED、ERROR、CANCELLED——父 agent 据此决定等待/追问/替换/结束。
  • 消息传递是一个持久化、服务端支撑的消息总线：每个 agent（父 + 各子）都有以 agent ID 寻址的独立 inbox；消息与生命周期事件共享一个全局序列号，使父 agent 永不会在产生该结果的消息之前观察到子 agent 的 SUCCEEDED（官方文档明确的顺序保证）。消息机制与 harness 无关（无论运行时是什么都用同一套 mailbox 基础设施），且可恢复——处于终态的子 agent 仍可寻址，收到新消息会”唤醒”。这与代码侧发现的 Claude Code 专用 parent_bridge.rs/wake_driver.rs 机制完全对应（见 Agent Loop / 记忆章节）。
  • 官方文档记录的命名编排模式：Supervisor/Worker、Fan-out/Fan-in、Critic/Verifier、Review swarm（cloud→cloud，例如一个 PR 一个子 agent）、DAG（显式依赖排序）、Swarm（扁平对等协调，文档明确警告”谨慎使用——更难调试”）。Warp 应用内有两个斜杠命令入口：/orchestrate（agent 提议拆分方案：子 agent 数量、各自 prompt、环境、并行度，并等待批准）与 /plan（研究+计划，内联考虑编排；批准计划即批准”每个子 agent 默认继承、父 agent 可逐个覆盖”的运行级配置）。两者都要求人类显式批准才能启动子 agent——这是硬性治理门，不只是 UI 建议（API 对应：POST /agent/runs 上的 mode: orchestrate / mode: plan）。
  • 客户端数据模型：RunAgentsRequest（crates/ai/src/agent/action/mod.rs:212-247）是批量多子 agent 派生的工具调用——base_prompt + 各子 RunAgentsAgentRunConfig{name, prompt, title}，运行级 model_id/harness_type/execution_mode（Local vs. Remote{environment_id, worker_host, computer_use_enabled}）。每个子 agent 的完整 prompt = base_prompt + "\n\n" + agent_run_configs[i].prompt。独立的 matches_active_config() 函数（crates/ai/src/agent/orchestration_config.rs:56-96）判断新的 run_agents 调用是否可以免重新询问用户自动启动——因为它匹配已被用户批准过的 OrchestrationConfig，即批准状态是按（model, harness, execution-mode）在会话内记忆的，同一已批准会话内的后续同形态派生不会被重复询问。
  • 任务树线性化：app/src/ai/agent/linearization.rs（函数全读）——compute_active_task_ids 对任务图做 DFS/队列遍历，把 Subagent 工具调用视为”子任务压入活跃队列”、其对应 ToolCallResult 视为”弹出”，并有显式环检测（检测到环时记录 error! 日志并跳过，而非无限循环）。compute_task_depths 计算每个任务距根的深度，同样有环防护。这是文档提到的”编排小圆点条”UI（父 + 每个子一个圆点）背后的具体数据结构。
  • Harness 枚举：warp_cli::agent::Harness 有 Oz（原生 Warp Agent）、Claude、OpenCode、Gemini、Codex 五个变体（crates/ai/src/agent/orchestration_config.rs:184-214）——确认 OpenCode 和 Gemini 也被建模为 harness 类型，超出 2026-05 博客宣传的三个（Claude Code/Codex/Warp Agent）；agent_sdk/driver/harness/ 下确认存在 gemini.rs 驱动文件，但未找到 opencode.rs 驱动文件——OpenCode 截至此 commit 可能仅是配置层面存在、尚无独立云端驱动，需后续验证，不应臆断。
  • 按 harness 的计费模型（官方文档 docs/harnesses 索引页，会话内阅读）：Claude Code 和 Codex “各自直接调用其提供商，使用你提供的凭证，由提供商向你的账户计费”；Warp 另计计算积分（沙箱）与平台积分（编排层），与运行哪个 harness 无关——即 Oz 的编排/治理层独立于底层模型自身的推理计费单独计量。

Skill / 插件体系

  • 完整的 skill 解析流水线在代码中确认（crates/ai/src/skills/parse_skill.rs，全读）：解析 SKILL.md 风格文件，从 YAML front-matter 读取 name/description（回退：name 取自父目录名，description 取自首个 markdown 段落，截断至 MAX_SKILL_DESCRIPTION_CHARS = 512、在句/词边界截断）——与 Anthropic/Claude Code Skills 规范的渐进式披露设计完全对应（front-matter 是”始终加载”的索引；完整正文按需通过 ReadSkill 工具调用读取）。
  • 跨工具 skill 互通是明确且刻意的设计：SkillProvider 枚举（crates/ai/src/skills/skill_provider.rs，全读）有十个变体——Warp、Agents（通用 .agents/skills）、Claude、Codex、Cursor、Gemini、Copilot、Droid（Factory AI）、Github、OpenCode——各自映射到自己的目录约定（.claude/skills、.codex/skills、.cursor/skills、.gemini/skills、.copilot/skills、.factory/skills、.github/skills、.opencode/skills，加上 .agents/skills 和 .warp/skills）。SKILL_PROVIDER_DEFINITIONS 的顺序即优先级顺序（.agents 最先，然后 .warp，再 .claude 等）via provider_rank()。SkillScope 区分 Home（~/.claude/skills 等）vs. Project（./repo/.claude/skills）vs. Bundled（Warp 自带）。这意味着 Oz 能原生发现并调用一个项目已有的 Claude Code / Cursor / Gemini CLI / GitHub Copilot / Factory Droid skills，项目所有者无需做任何 Warp 专属的事——是真正的跨生态互操作设计，而非仅 Warp 品牌 skills。
  • Skills 即 agent（官方文档 docs/skills-as-agents.md）：任何 Skill（包括为其他编码 agent 编写、存放在 .agents/ 或 provider 专属目录的）都可以直接作为独立云端 agent 启动——oz agent run-cloud --skill <slug> --environment <slug>——并可放上 cron 定时（oz schedule --skill "flag-cleanup" --cron "0 2 * * *"，Oz 首次发布文章中也有确认）。这模糊了 skill/agent-自动化 的边界：一个 skill 同时是”agent 可读的能力”和”可直接作为自己的定时/触发式 agent 启动的入口”。以一个 Skill 启动的 agent 仍能访问其环境中存在的全部 Skills（不会被沙箱限制到仅启动用的那一个）。
  • 图标/品牌元数据也按 provider 区分（SkillProvider::icon()/icon_fill() 把 Claude 映射到 Icon::ClaudeLogo + 一个 Claude 品牌橙色常量 CLAUDE_ORANGE，Codex 映射到 Icon::OpenAILogo，crates/ai/src/skills/skill_provider.rs:76-101）——细节但具体地证明多 provider skill 身份在 UI 层被认真建模，不只是后端逻辑。
  • Warp 还在自己身上 dogfood Claude Code Skills：克隆的仓库自带 .claude/skills/*（在此检出目录内工作时被 harness 自动暴露为可用 skills），覆盖 Warp 内部开发工作流（add-feature-flag、add-telemetry、promote-feature、remove-feature-flag、warp-integration-test、rust-unit-tests、changelog-draft、review-pr-local、triage-issue-local、onboarding-verification-skill 等）——证实 Warp 自己的工程流程（据”Warp is now open-source”文章）就跑在 agent+skill 驱动的贡献工作流上，不只是面向客户的功能。

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

  • 未发现”agent 改写自己权重/策略”这类第一方、产品级机制——符合预期，此处自进化指的是工作流/记忆/eval 循环，不是模型微调。
  • Agent Memory 作为自我改进基质（记忆章节细节在此重述）：官方文案明确将 Agent Memory 定位为支持”随时间自我改进”——“Agent Memory 是对你所有组织知识的索引……它也是可写的，因此 Oz 自身可以在完成任务时自动向知识库添加内容”（blog/multi-harness-cloud-agent-orchestration.md）。这是最接近 eval/经验驱动学习循环的第一方声明，但属于营销层面语言，截至 2026-07-07 处于 research-preview/候补名单阶段——客户端代码中未找到记忆写入决策如何触发/去重/加权的公开技术细节（写入路径逻辑在服务端）。
  • agent_mode_evals Cargo 特性（crates/warp_server_client/Cargo.toml:10、crates/warp_logging/Cargo.toml:37、crates/warp_multi_agent_client/Cargo.toml:10、crates/cloud_object_models/Cargo.toml:10，接入 app/Cargo.toml:737-747）确认 Warp 维护一个内部 eval 构建模式：一份硬编码的 11 个 staging “eval user” 账号 ID 列表（EVAL_USER_IDS，crates/warp_server_client/src/base_client.rs:29-31，注释明确要求”与 warp-server 中的 script/populate_agent_mode_eval_user.sql 保持同步”）以及一个专用 HTTP header X-Eval-User-ID（EVAL_USER_ID_HEADER，同文件第 23 行）用于”把 agent-mode eval 请求路由到指定 eval 用户”。这是内部 eval 基础设施真实存在的可编译证据，但 eval harness/runner 本身（评测什么、纠正如何反馈）活在闭源的 warp-server 中，未公开找到。
  • 第三方对”基于 Oz 构建的自我改进 agent”的验证（非 Warp 自身的第一方声明，而是一篇已记录的客户案例研究，blog/rectangle-health-self-improving-ai-teammate.md）：“Rex”，一个由 Rectangle Health 工程师基于 Oz 构建的 Slack 多 agent 系统，被描述为具有”自我改进循环：它审查自己的运行记录、生成改进提案、并针对自己的代码库开 PR”。披露的指标：Rex 自己的代码中 54% 是 Rex 自己写的；60 个活跃开发日内跨 11 个仓库新增 139 次提交/97,000 行代码；每周约 100 次云端 agent 运行；从 Slack 提及到 PR 的典型周转时间 3-10 分钟。这证明编排+记忆+skills 这些原语在客户自行搭建时能组合成自我改进系统，但自我改进设计本身是客户在 Oz 原语之上的应用层逻辑，不是 Oz 内置功能。

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

  • 结构化、命名的 telemetry 事件，带显式隐私标签：AITelemetryEvent（crates/ai/src/telemetry.rs，全读）——每个事件有稳定的点分名称（如 "AgentMode.MerkleTreeSnapshot.Rebuild.Success"、"AgentMode.SyncCodebaseContext.Success"）、人类可读描述、由 FeatureFlag 门控的 enablement_state()、JSON payload()，以及一个 contains_ugc() 布尔标志（用户生成内容标记，用于决定是否需要更严格的处理/脱敏），通过 register_telemetry_event! 宏在 trait 层强制。
  • 跨系统 trace 关联 ID：AIIdentifiers 结构体（app/src/ai/agent/telemetry.rs，全读）携带 client_conversation_id、client_exchange_id（“用于关联同一底层请求失败的稳定 ID”）、server_output_id（服务端生成，仅在首个响应块出现）、server_conversation_id（服务端范围，与客户端的 AIConversationId 不同——明确注明”主要用于服务端日志与分析”），以及 model_id（实际使用的模型，可能与请求的不同）。这一四/五重 ID 拼接方案是关联客户端 UI 状态、telemetry 事件、服务端日志/分析的具体机制。
  • 引用也是 telemetry 类型化的：AIAgentCitation::for_telemetry()（app/src/ai/agent/telemetry.rs:19-46）把引用（Warp Drive 对象、Warp 文档页、网页，或Agent Memory——携带 memory_store_id/memory_id）转换为 telemetry 安全的 CitationForTelemetry 形状——即连记忆取用的溯源都接入了可观测性管线，不只是工具调用。
  • 官方产品层可观测面（docs/orchestration.md）：每个父/子运行都可独立跟踪——Warp 应用内的编排”圆点条”UI、Oz web app 里专门的 Sub-agents 标签页和 Runs 页面（oz.warp.dev/runs），以及 API 内省：GET /agent/runs/{runId} 查单次运行最新状态，GET /agent/runs?ancestor_run_id=PARENT_RUN_ID 一次列出某父运行的全部后代。Oz 首次发布的文章还描述了 Agent Session Sharing 链接——每次 agent 运行自动生成可分享链接，供队友实时观看进度并介入引导，加上审计轨迹和完整的 CLI/API 可控性（“每个 agent 都会产出一个链接、一份审计轨迹，并可通过 CLI 和 API 控制”）。
  • 第三方 harness 输出监控：app/src/ai/agent_sdk/driver/harness_output_monitor.rs 专门用于扫描运行中 harness 的终端输出，匹配 runtime_error_patterns()（harness 专属的子串，指示如无效 API key、无计费、配额耗尽等，通过与 Warp 查找功能相同的 DFA 机制做大小写不敏感匹配，据 harness/mod.rs:150-157 的文档注释）——即第三方 CLI 的可观测性部分是通过抓取其 stdout/stderr 屏幕内容实现的，而非结构化协议，因为 Claude Code/Codex 除了自己的转录文件外不向驱动暴露机器可读的 trace API。

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

  • 细粒度、带原因编码的权限模型，完全在客户端分发前强制执行（app/src/ai/blocklist/permissions.rs，1243 行，类型定义与约 40 个公开方法部分全读）：独立的 CommandExecutionPermission、FileReadPermission、FileWritePermission 结果类型，每个都是 Allowed(reason) / Denied(reason) 对，带显式原因枚举——例如 CommandExecutionPermissionAllowedReason 有 Dispatched | ExplicitlyAllowlisted | IsReadOnlyAndSettingEnabled | AgentDecided | AlwaysAllowed | RunToCompletion；Denied 原因包括 AutonomyForceDisabled、AlwaysAskEnabled、ExplicitlyDenylisted、ContainsRedirection、Inconclusive、AgentDecided。每个允许/拒绝决策都可审计到具体”为什么”。
  • 按 profile 的允许/拒绝列表覆盖六大权限类别：文件读、文件写（apply_code_diffs）、命令执行、MCP 工具、computer-use、ask-user-question、run-agents——各自有独立的 get_..._setting_for_profile / allowlist / denylist 访问器，以及组织级覆盖路径（get_org_execute_commands_denylist）。Profile 是命名的、可切换的执行上下文（AIExecutionProfile，app/src/ai/execution_profiles/mod.rs），且组织策略可以强制某项设置，使终端用户无法覆盖——例如 resolve_cloud_agent_computer_use_state() 在管理员设置了 ComputerUsePermission::Never 或 AlwaysAllow 时返回 is_forced_by_org: true（execution_profiles/mod.rs:55-90）——直接对应博客所称的”细粒度权限……遵循最小权限模型”。
  • 密钥管理：发现两套独立机制。(a) 客户端 HPKE 混合加密信封用于向服务端上传密钥（crates/managed_secrets/src/envelope.rs，部分读）——使用 Google Tink（tink_core/tink_hybrid），初始化时注册自定义的 HpkePublicKeyManager/HpkePrivateKeyManager；UploadKey::encrypt_secret() 把密文绑定到一个 UploadContext{actor_uid, secret_name, secret_type} 作为 HPKE AAD，使密文无法在不同 actor/密钥名/类型下被重放。(b) 官方文档（docs/secrets.md）确认服务端策略层：密钥值在创建后永不可取回（只能取元数据），每个密钥限定在团队或个人用户范围，密钥仅在特定触发上下文中自动注入为环境变量，管理员拥有完整审计可见性（“工程和安全负责人可以列出他们可访问的全部密钥”）。这是端到端一致的设计：客户端上传时加密，服务端只写存储，运行时按范围注入环境变量。
  • 工作负载身份联邦：app/src/ai/agent_sdk/federate.rs（部分读）签发短生命周期的联邦身份令牌（issue_task_identity_token、issue_gcp_workload_identity_federation_token），通过 ambient-workload-token header 限定到特定 run_id，由 FeatureFlag::OzIdentityFederation 门控——这是让云端 agent 在不将长生命周期云凭证嵌入 agent 环境的前提下，假设一个限定范围的云提供商身份（如 AWS/GCP）的机制。
  • Harness 层面的审批绕过是显式且被记录为刻意权衡的：Oz 用 --dangerously-skip-permissions 调用 Claude Code，用 --dangerously-bypass-approvals-and-sandbox --dangerously-bypass-hook-trust 调用 Codex（claude_code.rs:210、codex.rs:188-193，均逐字来自源码）。Oz 自己的文档注释解释了对 Codex 而言为什么这样做：--dangerously-bypass-hook-trust “允许 Warp 安装的编排插件 hooks 在无人值守的驱动会话中运行，而无需手动 hook 审查”，正因如此，“驱动启动前会校验 Codex 平台插件”（requires_verified_platform_plugin() 对 Codex 返回 true，默认返回 false）——即 Oz 显式地用”自己的外部沙箱（隔离平台，见下）+ 平台插件完整性校验”替换了 harness 自身进程内的安全门，而非叠加两套重复的审批系统。
  • 编排启动本身需要人类批准——在 Router/编排章节已述：/orchestrate 和 /plan 都把子 agent 派生门控在显式用户批准之后，按会话记忆为 OrchestrationConfigStatus::Approved/Disapproved，配合 matches_active_config() 使重复的同形态派生不会重新询问。

沙箱与执行隔离

  • 隔离平台检测是一等的、显式的运行时概念：IsolationPlatformType 枚举（crates/isolation_platform/src/lib.rs，全读）——Docker（自托管通用容器）、DockerSandbox（Warp 托管的托管沙箱）、Kubernetes（自托管 pod）、Namespace（Warp 托管、非容器化的”Namespace 实例”）。检测顺序：显式服务端下发的 WARP_ISOLATION_PLATFORM 环境变量（最高优先级，比启发式更可信）→ Namespace 实例启发式 → Kubernetes 启发式 → Docker 启发式 → None。每个平台都可以通过 issue_workload_token() 签发一个 WorkloadToken（token + 可选 expires_at），没有自己令牌机制的平台有通用的 WARP_WORKLOAD_TOKEN 环境变量回退。检测结果按进程记忆一次（OnceLock）。
  • 自托管至少有三种执行后端，据官方文档确认：Docker（self-hosting/managed-docker）、Kubernetes（managed-kubernetes）、以及 Direct（self-hosting-managed-direct.md，全读）——Direct 后端直接在宿主机上运行 oz-agent-worker 守护进程，完全没有容器隔离：“每个任务运行在独立的工作区目录中，但共享宿主机操作系统和内核”。文档明确将其标注为生产使用前需评估的安全权衡。机制：worker 在 workspace_root（默认 /var/lib/oz/workspaces）下为每个任务创建工作区目录，运行可选的 setup_command，在该目录内通过 oz CLI 执行任务，然后是可选的 teardown_command 和目录清理。这直接对应 IsolationPlatformType::Namespace/通用工作负载令牌代码路径（最弱隔离级别，仅文件系统层面分离）。
  • Warp 托管的托管沙箱（枚举中的 “DockerSandbox”）是 Warp 托管执行的默认层级——据 Oz 首次发布文章描述为”环境即 Docker 容器 + git 仓库 + 启动命令”，可在 5 分钟内通过 /create-environment 斜杠命令、Oz web app 或 CLI/API/SDK 建立，且默认在团队内共享。
  • Codex 自身的沙箱被显式绕过并替换为 Oz 的隔离层：--dangerously-bypass-approvals-and-sandbox 标志（见安全与权限章）确认 Oz 在把 Codex 作为 harness 运行时不依赖 Codex 内置的操作系统级沙箱——Oz 自己的 Docker/Kubernetes/Namespace 隔离才是实际边界，Codex 在其中”裸跑”。
  • Computer-use 本身是平台专属的原生代码（不是浏览器/VM 抽象）：crates/computer_use/src/{mac,linux,windows}/*——每个操作系统各自独立的键鼠/窗口/截图实现（mac/keyboard.rs、mac/mouse.rs、mac/window.rs、mac/screenshot.rs、linux/recording.rs、linux/keysym.rs、windows/keyboard.rs、windows/dpi.rs），确认 computer-use 动作是通过宿主机上真实的操作系统输入注入 API 执行的，无论 agent 被沙箱在哪台宿主机上，而不是无头浏览器。

与模型的协同设计

  • 多模型而非单模型，是明确的设计原则：Oz 首次发布文章称 Oz “一直是多模型的”，甚至早于它成为多 harness 之前；Oz 的既定设计原则之一就是对编排模式（隐含地也对模型选择）保持无偏好。
  • “Bring your own inference”（引用但未深读，标记为二阶段跟进项）：blog/bring-your-own-inference-to-warp（2026-05-20）在两篇 harness 发布文章中都被链接，明确关于给用户”更多推理控制权”，OpenAI 的 GPT 模型为新的开源仓库 agentic 工作流提供动力（据 warp-is-now-open-source.md）——Warp 将自己定位为 harness-and-model-agnostic 的基础设施，而非针对某一个模型家族紧密协同设计。
  • 为开源转型明确新增的开放模型支持：据 blog/warp-is-now-open-source.md，Warp 增加了对 Kimi、MiniMax、Qwen 的支持，外加一个 “auto (open)” 模型路由变体，自动为任务挑选最佳开放模型——这是”模型选择即功能”，而非深度模型专属的提示/工具协同设计。LONG_CONTEXT_WARNING_THRESHOLD: u32 = 272_000（app/src/ai/execution_profiles/mod.rs:19-22）是代码中一处具体的模型专属处理：一个 GPT-5.4/5.5 专属的长上下文计费警告（OpenAI 在超过 272K token 时自动应用长上下文定价），确认 Warp 确实编码了一些提供商专属的定价/行为怪癖，而非将所有模型视为完全可互换。
  • 按 harness 而异的提示注入机制（在 Prompt 设计章节已述）：Claude Code 用 --append-system-prompt-file；Codex 用 AGENTS.override.md 文件投放——这是 harness 专属（进而也是模型家族专属，因为每个 harness 默认使用其厂商自己的模型）集成工作的证据，而非单一通用适配器。
  • 发现但未深挖的 Codex 模型配置代码常量：CODEX_MODEL_KEY、CODEX_MODEL_REASONING_EFFORT_KEY、CODEX_MODEL_MIGRATIONS_TARGET = "gpt-5.4"（app/src/ai/agent_sdk/driver/harness/codex.rs:505-514）——确认 Oz 主动管理 Codex 的 reasoning-effort 配置，并有一个硬编码的迁移目标模型版本，即 Oz 把自己的 Codex 集成钉住/更新在特定 OpenAI 模型 ID 上，而非把”codex”当作一个不透明黑盒对待。
  • 未发现 Warp 训练或微调自己模型的证据——所有模型协同设计证据都停留在”集成/配置/路由”层面，不涉及权重层面。

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

  • 未发现会话轨迹反哺模型训练的证据（符合预期——Warp 不是模型实验室；它集成 Claude Code/Codex/Gemini/自己的 agent，均由各自实验室训练）。
  • 轨迹被持久化并在运营层面复用（这是这里确认过的”轨迹利用”最强形式）：对 Claude Code，完整的 ClaudeTranscriptEnvelope（主 JSONL + 子 agent JSONL + TODO）被上传到 Warp 服务端，可被重放/重新落地以在不同机器或云端恢复完全相同的 Claude Code 会话状态（记忆章节细节）。这是为连续性而做的轨迹复用，不是为模型改进。
  • agent_mode_evals 构建特性（自进化章节细节重述）确认 Warp 确实把一部分生产类流量路由通过一个专用的 eval-user 群组（服务端），强烈暗示该群组的轨迹/输出会喂给 warp-server 内部某个 eval/回归打分管线——但打分/评测逻辑本身不在公开的客户端仓库中，实际机制（基于 rubric 的 LLM 裁判？人工审核？黄金任务通过/失败？）未找到，不应臆测。
  • Agent Memory 的写入路径是另一个候选机制（“Oz 自身可以在完成任务时自动向知识库添加内容”——即成功任务的轨迹可以生成被持久化的记忆，从而偏置未来运行）。这是一个真实的、命名的产品机制，但截至 2026-07-07 处于 research-preview/候补名单阶段，写入什么/评分逻辑的具体触发机制未公开找到（服务端）。
  • Session Sharing + 审计轨迹（每次 agent 运行都获得可分享链接 + 审计日志，据 Oz 首次发布文章）是可能支持人在回路的轨迹审查/整理用于评测目的的基础设施，但没有公开信源证实它确实被这样使用——标记为推测，而非本笔记中陈述的事实。

与同类 harness 的关键差异（1-3 条）

  • 与 Claude Code/Codex 这类”单 harness 自成一体”的产品不同，Oz 从设计上把自己定位为跨 harness 编排层：同一套父/子编排原语（消息总线、批准门、run 状态机）对 Warp Agent、Claude Code、Codex（部分）Gemini 一视同仁地生效，且父子可以跨 harness 混搭——这是本调研中遇到的 harness 里对”多 harness 作为一等公民”处理最彻底的一例。
  • 对第三方 harness（Claude Code/Codex），Oz 不复用其自身的审批/沙箱机制，而是显式用 --dangerously-skip-permissions / --dangerously-bypass-approvals-and-sandbox 绕过，转而把安全边界完全交给自己的隔离层（Docker/Kubernetes/Namespace）——这是一种”信任外部治理层、不信任内部治理层”的架构选择，与把 sandbox 留给宿主 CLI 自己处理的设计相反。
  • 更细的跨 harness 对比（与 Claude Code、Codex、OpenHands 等的量化差异）留待 synthesis 阶段做统一表格，此处不重复展开。

原始源码定位

  • repo: https://github.com/warpdotdev/warp（客户端；warp-server 与 oz CLI 控制面内部实现未公开）
  • commit/version analyzed: a612c95919cb101515ad663df9ec0e3436930c47（2026-07-07 浅克隆，作者时间 2026-07-06 17:56:02 +0000）
  • 关键文件列表（相对路径，均在上述 commit）：
    • crates/ai/src/agent/orchestration_config.rs
    • crates/ai/src/agent/action/mod.rs
    • app/src/ai/agent/mod.rs
    • app/src/ai/agent/conversation.rs
    • app/src/ai/agent/linearization.rs
    • app/src/ai/agent/task.rs, task_store.rs
    • app/src/ai/facts/mod.rs, manager.rs
    • crates/ai/src/skills/skill_provider.rs
    • crates/ai/src/skills/parse_skill.rs
    • app/src/ai/mcp/file_based_manager.rs
    • app/src/ai/blocklist/permissions.rs
    • app/src/ai/execution_profiles/mod.rs
    • app/src/ai/blocklist/action_model.rs, action_model/preprocess.rs, action_model/execute/*.rs
    • crates/isolation_platform/src/lib.rs（+ docker.rs/docker_sandbox.rs/kubernetes.rs/namespace.rs 存在性）
    • crates/managed_secrets/src/envelope.rs（+ client.rs/manager.rs/secret_value.rs/gcp.rs 存在性）
    • crates/computer_use/src/lib.rs + mac/linux/windows 子目录
    • app/src/ai/ambient_agents/mod.rs, scheduled.rs, spawn.rs, task.rs
    • app/src/ai/agent_sdk/driver/harness/mod.rs
    • app/src/ai/agent_sdk/driver/harness/claude_code.rs
    • app/src/ai/agent_sdk/driver/harness/codex.rs
    • app/src/ai/agent_sdk/driver/harness/claude_transcript.rs, codex_transcript.rs
    • app/src/ai/agent_sdk/driver/harness/claude_code/parent_bridge.rs, wake_driver.rs
    • app/src/ai/agent_sdk/memory_store.rs
    • app/src/ai/agent_sdk/federate.rs
    • crates/ai/src/project_context/global_rules.rs, model.rs
    • crates/ai/src/telemetry.rs
    • app/src/ai/agent/telemetry.rs
    • app/src/tracing/native.rs, cloud_agent_auth.rs
    • app/src/ai/agent_sdk/driver/error_classification.rs, retry.rs
    • app/src/ai/agent_sdk/driver/harness_output_monitor.rs
    • crates/warp_server_client/src/base_client.rs
    • app/Cargo.toml, crates/warp_server_client/Cargo.toml, crates/warp_multi_agent_client/Cargo.toml, crates/cloud_object_models/Cargo.toml, crates/warp_logging/Cargo.toml
    • AGENTS.md（仓库根，Warp 自身贡献者开发说明，非运行时 agent 系统提示）
    • .claude/skills/*（Warp 自用的内部 Claude Code skills，非产品本身）

一手源存档（sources/）

/Users/zhao/projects/self-wiki/ai-research/sources/harness/warp-agent-mode/ 下：

  • NOTES.md（726 行，逐维度全量笔记，含精确文件/行号引用）
  • key-files/（18 个精选 .rs 源码摘录）
    • agent/：orchestration_config.rs、action_mod.rs、linearization.rs、memory_store.rs、global_rules.rs、telemetry_crate.rs、telemetry_app.rs
    • skills/：skill_provider.rs、parse_skill.rs
    • harness-drivers/：mod.rs、claude_code.rs、codex.rs、claude_transcript.rs、parent_bridge.rs、wake_driver.rs
    • security/：permissions.rs、envelope.rs
    • isolation/：lib.rs
  • blog/（5 篇官方 Warp 博客，CloakBrowser 抓取为 markdown）
    • multi-harness-cloud-agent-orchestration.md（2026-05-19，多 harness 发布）
    • oz-orchestration-platform-cloud-agents.md（2026-02-10，Oz 首次发布）
    • warp-is-now-open-source.md（2026-04-28，客户端开源）
    • rectangle-health-self-improving-ai-teammate.md（2026-06-12，客户案例研究）
    • agent-memory-product-page.md（Agent Memory 产品页）
  • docs/（5 篇 docs.warp.dev 页面）
    • orchestration.md、secrets.md、self-hosting-managed-direct.md、handoff-local-to-cloud.md、skills-as-agents.md

关系图谱

反向链接