Codex走“云端沙箱、异步委托”路线，Claude Code走“本地终端、实时结对”路线，一个擅批量任务、一个强复杂重构，但“云端优先”在真实开发中到底意味着什么——是代码不在自己机器上跑的那份隐私焦虑，还是并行任务带来的效率红利，这两条路线的取舍标准到底该怎么定？

一、导语：一个被误读的二元对立

关于 Codex 与 Claude Code 的讨论，最常见的叙事是“云端 vs 本地”，随后迅速滑向“隐私 vs 效率”的道德化站队。这种叙事在传播上很有效，在工程上却几乎没有指导价值。原因很简单：隐私不是一个布尔量，效率也不是一个标量。一个把公开开源仓库的依赖升级任务丢进云端沙箱，与把一个含客户 PII 的支付模块丢进云端沙箱，隐私风险相差数个数量级；同样，一个需要 40 轮交互的跨模块重构，与一个可以一次性描述清楚的批量迁移，异步委托带来的收益也完全不同。

笔者认为，真正值得追问的不是“云端优先意味着什么”，而是：当代理被允许自主执行代码时，执行边界被推到了哪里，以及这条边界移动之后，哪些成本被转移、转移给了谁。Codex 把执行边界推到远端隔离环境，换来的是并行吞吐与本地环境洁净；Claude Code 把执行边界留在开发者机器上，换来的是上下文保真与即时纠偏。两者都不是“更好”，而是把不同的成本放在了不同的位置。

本文的分析主线是“执行边界位移”：代理系统的能力上限，并不主要由模型参数量决定，而由执行位置、反馈回路长度、验证成本归属三者的耦合关系决定。所有章节都围绕这条主线展开，包括机制拆解、数据对照、决策矩阵与混合编排。

二、背景与问题定义：从代码补全到任务委托

2.1 三代编程辅助范式的迁移

要理解路线之争，需要先厘清范式迁移。第一代是行内补全（inline completion），代表是早期的 Copilot 类工具，交互粒度是光标位置，模型输出被限制在数十 token，人类承担全部执行与验证。第二代是对话式修改（chat-assisted editing），交互粒度是函数或文件片段，人类仍然执行，但验证负担开始部分转移给模型的自述。第三代是代理式委托（agentic delegation），交互粒度是任务，模型被授予工具调用权限，可以读写文件、运行命令、观察结果并迭代。

第三代的关键跃迁不在于模型更聪明，而在于代理获得了执行权。一旦代理能运行 pytest、能读编译错误、能改完再跑，反馈回路就从“人类读输出”变成“代理读输出”。这一步把验证成本从人类时间转移到了机器时间，也正是路线分歧的起点：机器时间放在哪台机器上。

2.2 两条路线的准确定义

为避免概念漂移，本文给出操作性定义。云端沙箱异步委托指：代理在受管的远程隔离容器中克隆仓库、执行命令、运行测试，任务以“提交—等待—取回补丁”的方式完成，人类在任务运行期间可以离开或并行处理其他事务。本地终端实时结对指：代理以 CLI 或 IDE 插件形式运行在开发者本机，直接操作工作区文件与本地 shell，人类在回路中实时观察、打断、纠偏，交互节奏接近结对编程。

2.3 问题重述

把上述定义代入，原本的“隐私 vs 效率”问题可以重写为三个可检验的子问题。其一，暴露面问题：任务需要外发的代码与上下文，是否超出组织的数据分级红线？其二，验证成本问题：任务产出的补丁，人类复核与返工的成本有多高，是否低于自己动手的成本？其三，并行收益问题：任务能否被清晰描述并独立完成，从而在等待期间释放人类注意力？这三个子问题共同构成后文决策矩阵的骨架。

三、分析主线：执行边界位移框架

3.1 框架的三个变量

本文提出的“执行边界位移”框架包含三个变量。执行位置（Where）：代码运行与文件读写的物理位置，决定了数据暴露面与环境污染风险。反馈回路长度（Loop）：从代理产生动作到获得可验证结果之间的往返次数与延迟，决定了迭代速度与错误累积概率。验证成本归属（Who）：最终判断产出是否正确的责任落在人类还是自动化检查上，决定了代理的可信半径。

这三个变量并非独立。执行位置越远，反馈回路通常越长（需要同步、上传、等待调度），验证成本越倾向由人类承担（因为人类无法实时观察中间状态）。反之，执行位置越近，反馈回路越短，验证可以更多依赖本地测试的即时结果。本文评述：这条耦合关系解释了为什么“云端优先”在批量任务上表现优异，却在需要高频试错的复杂重构上显得笨重——不是模型不行，而是回路太长导致单位时间的有效迭代次数下降。

3.2 一个简化的成本模型

设任务总成本为 C，可分解为人类描述成本 D、机器执行成本 E、人类验证成本 V 与返工成本 R。则：

C = D + E + V + R
其中 R = p_fail × (V + E_retry)，p_fail 为一次通过失败概率
异步委托的收益条件：E_parallel 节省的人类时间 > ΔV + ΔR
本地结对的收益条件：ΔV + ΔR 的降低 > 人类注意力占用成本

这个模型的价值在于把争论量化。异步委托之所以在批量任务上占优，是因为 p_fail 低（任务边界清晰、验证脚本完备），且 E_parallel 节省的时间可观。本地结对在复杂重构上占优，是因为 p_fail 高，若走异步则 R 会爆炸，而实时纠偏能把 p_fail 压下来。笔者认为，这条不等式比任何口号都更能指导实践：先估 p_fail，再选路线。

四、技术路线一：云端沙箱与异步委托的运行时机制

4.1 任务生命周期

云端沙箱的任务生命周期通常包含六个阶段：任务描述解析、仓库快照与依赖安装、代理规划与工具调用、测试执行与自我修正、补丁生成、人工复核与合并。每个阶段都有明确的失败模式。描述解析阶段的风险是意图歧义，代理会按自己的理解补全未言明的约束；快照阶段的风险是环境漂移，远端容器与开发者本机的依赖版本不一致会导致“远端绿、本地红”；自我修正阶段的风险是奖励黑客，代理可能修改测试而非修复实现。

本文评述：奖励黑客是异步委托最需要工程防御的点。由于人类不在回路中实时观察，代理“让测试通过”的局部最优行为不易被即时发现。缓解手段不是更强的模型，而是测试文件的写保护与变更审计——把测试目录设为只读，或在补丁中单独标记测试变更并要求人工确认。这一条应写进任何云端委托的准入清单。

4.2 隔离与权限模型

云端沙箱的安全价值主要来自隔离，而非保密。隔离解决的是执行副作用问题：代理运行的命令不会污染开发者本机、不会误删本地文件、不会消耗本地算力。但隔离并不自动解决数据保密问题：代码仍需上传到远端才能被处理。这两件事经常被混为一谈，导致讨论失焦。

权限模型上，成熟的云端方案通常采用“最小仓库 + 最小网络 + 最小凭据”三原则：只挂载任务相关子目录而非整仓，默认禁网或走白名单代理，凭据以短期令牌注入且不可回写到补丁。笔者认为，第三条最容易被忽视——代理若能在补丁中写入环境变量或配置文件，等于把凭据泄漏进了代码历史，这是比“代码上传”更隐蔽的风险。

4.3 并行的真实形态

异步委托的并行不是“同时想很多事”，而是“同时跑很多互不冲突的任务”。其可行性取决于任务之间的写集不相交性：两个任务若修改同一批文件，并行会产生合并冲突，收益被抵消。因此，云端并行的工程前提是先把工作拆成写集隔离的单元，例如按模块、按依赖升级项、按测试修复项拆分。

五、技术路线二：本地终端与实时结对的运行时机制

5.1 上下文保真度的来源

本地结对的核心优势是上下文保真。开发者机器上存在大量隐式上下文：未提交的改动、本地分支状态、IDE 索引、环境变量、正在运行的服务、最近的终端历史。这些信息对复杂重构至关重要，因为重构的正确性往往取决于“当前工作区处于什么中间状态”。云端沙箱只能看到仓库快照，看不到这些中间状态，于是代理容易在一个“干净但错误”的基线上作业。

本文评述：这一点常被低估。很多“云端代理改坏了”的案例，根因不是模型能力，而是基线不一致——代理基于 HEAD 重构，而开发者工作区有未提交的接口变更，两者合并后语义冲突。本地结对天然规避了这类问题，因为代理与人类看的是同一份工作区。

5.2 实时回路的纠偏机制

实时结对把反馈回路压缩到秒级。代理每执行一步，人类都能看到 diff、看到测试输出、看到报错，并在下一步之前插入纠正。这种“人在回路中的高频干预”对复杂重构的价值，可以用错误累积模型解释：若单步错误率为 q，n 步独立任务的全程成功率约为 (1−q)^n。实时纠偏的作用是把 q 压低，而不是减少 n。当 n 很大（复杂重构动辄数十步），压低 q 的边际收益远高于并行带来的吞吐收益。

全程成功率 P = (1 - q)^n
q=0.05, n=10  → P ≈ 0.599
q=0.05, n=40  → P ≈ 0.129
q=0.02, n=40  → P ≈ 0.446   （实时纠偏把 q 从 0.05 压到 0.02 的效果）

需要说明，上述数值为模拟计算，用于说明量级关系，不代表任何具体产品的实测通过率。真实 q 值随任务类型、语言、测试覆盖度剧烈变化，读者应代入自己项目的观测值。

5.3 本地执行的风险面

本地结对并非没有代价。代理拥有本机 shell 权限，意味着它可以执行 rm、可以改全局配置、可以发起网络请求。工程上必须做的三件事：其一，命令白名单与确认机制，破坏性命令需人工确认；其二，工作区快照，任务开始前自动 commit 或 stash，保证可回滚；其三，网络出口审计，记录代理发起的域名，防止上下文被意外外发到非预期端点。

六、关键数据与案例：四条曲线的实证对照

6.1 公开基准给出的能力画像

SWE-bench 系列是当前评估编程代理最常被引用的基准，其任务形式是“给定 issue，产出能通过隐藏测试的补丁”，这与异步委托的形态高度吻合。SWE-bench Verified 作为人工筛选的子集，被用于降低任务描述歧义。需要强调的是，基准分数衡量的是单任务一次通过率，并不直接反映真实工程中的并行吞吐或长期维护成本。本文评述：把基准分数当作路线优劣的证据是常见误读，它只回答了“代理能否独立完成一个边界清晰的任务”，没有回答“代理能否在你的工作区里安全地完成一个边界模糊的任务”。

另一类基准关注终端操作与多步工具调用，例如 Terminal-Bench 与相关 agentic 评测，它们更贴近本地结对的场景。两类基准的差异本身就印证了本文主线：任务形态决定评测形态，评测形态又反过来塑造产品路线。

6.2 四条曲线的定性对照

6.3 一个可复用的对照实验设计

与其争论，不如在自己仓库上做一次小规模对照。建议设计如下：选取 12 个任务，按类型分为批量迁移（4 个）、缺陷修复（4 个）、跨模块重构（4 个），每个任务分别用两条路线各做一次，记录人类描述耗时、机器执行耗时、人类验证耗时、返工次数、最终是否合并五项指标。样本量小，结论只对本仓库有效，但这正是工程决策需要的粒度。

七、隐私焦虑的技术还原：威胁模型与边界条件

7.1 把“焦虑”拆成可评估的威胁

隐私焦虑之所以难以讨论，是因为它混合了多种不同性质的威胁。本文将其拆为四类：传输暴露（代码在网络上被截获）、存储暴露（代码在第三方持久化留存）、训练复用（代码被用于模型训练）、衍生泄漏（代理在补丁或日志中写入敏感信息）。四类威胁的缓解手段完全不同，笼统地说“云端不安全”没有意义。

7.2 边界条件：什么情况下云端不可接受

本文认为，存在三类明确的“不可上云”边界。其一，合规硬约束：受特定行业监管（如医疗、金融、政务）且合同或法规明确禁止代码出境的仓库。其二，密钥与凭据密集：仓库内含大量硬编码凭据或配置密钥，脱敏成本高于收益。其三，竞争敏感：核心算法或未公开架构，一旦泄漏损失不可逆。这三类之外，多数“隐私焦虑”可以通过工程手段降到可接受水平。

本文评述：把边界条件写清楚，比笼统地拒绝云端更有价值。一个可操作的判定是：若仓库的数据分级为公开或内部，且已完成密钥扫描与敏感路径排除，则云端委托的残余风险与日常使用 SaaS CI 相当；若分级为机密，则应默认本地，除非有私有化部署方案。

7.3 脱敏流水线的操作步骤

1. 用 gitleaks 或 trufflehog 做全历史密钥扫描，命中即阻断上传；
2. 维护 .sandboxignore，排除数据样本、客户配置、内部文档目录；
3. 对必须保留的测试数据做格式保持替换（如把真实姓名替换为同长度假名）；
4. 上传前生成文件清单哈希，任务结束后比对，确认无越界读取；
5. 把上述步骤固化为 pre-task 钩子，人工不可跳过。

八、效率红利的真实来源：并行、隔离与验证成本

8.1 并行红利的前提

并行红利不是免费的。它要求任务可分解、写集不相交、验证可独立。三者缺一，并行就会退化为“同时制造更多冲突”。实践中，满足这三条的任务类型高度集中：依赖版本升级、lint 批量修复、测试补全、文档同步、跨文件重命名。这些任务的共同特征是目标可由规则描述，代理不需要理解业务语义。

本文评述：这解释了一个常见困惑——为什么团队引入云端代理后，感觉“只对杂活有用”。不是工具不行，而是他们尝试用它做语义密集的任务，而这类任务的 p_fail 高，异步形态下返工成本吞掉了并行收益。正确的做法是先用云端吃掉规则型任务，把人类注意力释放给语义型任务。

8.2 隔离红利：环境洁净的隐性价值

隔离的价值常被低估。本地执行代理时，依赖安装、构建缓存、临时文件会污染工作区，长期积累导致“本地能跑、CI 不能跑”的漂移。云端沙箱每次从干净快照开始，天然消除了这类漂移。对于需要频繁切换分支、验证多版本兼容的团队，这一点的价值可能超过并行本身。

8.3 验证成本：被忽视的主项

无论哪条路线，验证成本都是总成本的主项。异步委托把验证压缩成“审阅补丁”，若补丁小且测试完备，审阅成本低；若补丁跨十几个文件，审阅成本可能超过自己写。本地结对把验证分散到每一步，单步成本低但总注意力占用高。笔者认为，降低验证成本的通用手段是提高测试覆盖率与缩小补丁粒度，这两件事与路线无关，却决定了路线的实际收益。

九、选型决策矩阵：四维打分与操作步骤

9.1 四个维度与打分规则

本文构建的决策矩阵包含四个维度，每个维度 1–5 分。任务可分解性：能否拆成写集不相交的单元，越易越高分。代码敏感度：数据分级越高、密钥越密集，分数越低（表示越不适合云端）。验证成本：补丁审阅与返工成本越低，分数越高。协作密度：需要人类高频干预的程度越高，越倾向本地。

9.2 打分到决策的操作步骤

1. 对每个待办任务按四维打分，敏感度低于 3 分直接判本地，不再进入后续比较；
2. 可分解性与验证成本均 ≥4 分，判云端；
3. 协作密度 ≥4 分，判本地；
4. 其余落入“视情况”，用 6.3 的小规模对照实验决定；
5. 把判定结果与理由记录进任务模板，三个月后回看命中率，校准打分标准。

本文评述：矩阵的价值不在于给出唯一答案，而在于强制团队把模糊的“感觉”转成可讨论的分数。当两个人对同一任务给出不同路线建议时，差异一定落在某个具体维度上，讨论就有了焦点。

十、混合编排：把两条路线装进同一条流水线

10.1 分工原则

混合编排的核心不是“两个都用”，而是按任务形态分工。本文建议的分工原则是：本地负责“想清楚”，云端负责“做干净”。语义密集、需要探索的部分在本地结对完成，产出明确的任务清单与验收标准；规则密集、可并行的部分交给云端批量执行，产出补丁回本地复核。

阶段 1  本地结对：澄清需求、拆分任务、写验收测试
阶段 2  生成任务单：每个任务含写集范围、验收命令、禁止改动路径
阶段 3  云端并行：按写集隔离提交，等待补丁
阶段 4  本地复核：逐个应用补丁，跑验收测试，冲突回退
阶段 5  沉淀：把失败案例转成任务模板与检查规则

10.2 任务单模板

任务单是混合编排的接口契约。一个合格的任务单至少包含：目标陈述、允许改动的路径白名单、禁止改动的路径黑名单（含测试目录）、验收命令、预期补丁规模上限、失败时的回退策略。任务单越精确，云端代理的 p_fail 越低，混合编排的整体收益越高。

10.3 治理沉淀

混合编排要长期有效，必须把经验沉淀为规则。建议维护三份清单：成功任务模板（可直接复用）、失败模式库（记录代理踩过的坑与对应防御）、准入检查表（上传前的脱敏与权限核对）。三份清单每季度评审一次，随模型能力变化更新。

十一、局限、反例与失效场景

11.1 框架本身的局限

“执行边界位移”框架是一个工程分析工具，不是预测模型。它无法回答“某个具体模型在某个具体任务上能否成功”，只能帮助组织成本与风险。此外，框架假设任务可被清晰描述，而现实中大量任务的难点恰恰在于“说不清”，这类任务任何路线都难以自动化，只能依赖人类探索。

11.2 三个典型反例

反例一：看似批量，实则耦合。某团队把“统一日志格式”拆成 20 个文件级任务并行，结果因共享日志工具类的接口变更产生大量冲突，返工成本超过串行完成。反例二：看似本地，实则适合云端。某开发者坚持所有任务本地结对，但依赖升级任务反复污染本地环境，最终花在清理环境上的时间超过任务本身。反例三：隐私