执行器可以换，控制面自己做：Claude Code、Codex 与同类工具对照 APSer-Atelier

先说结论

• Claude Code、Codex、DeepSeek Harness 和六个开源编排项目，覆盖的是执行器这一层，以及执行器之上的会话管理；APSer-Atelier 管的那一层，没有一个覆盖全。所以我们的做法是：执行器用现成的，可以换；控制面自己做。
• 我们按七条机制逐项对照，七个被对照的工具里没有一个七条都覆盖；这把尺子是按 Atelier 的需要定的，它只能说明这些机制确实做出来了，不说明 Atelier 比这些项目好。
• 启动、列出、发消息、停止、归档这一薄层会话管理，两家官方工具都在补；值得我们自己做的，是会话之上的那一层：一件事怎样算做完，谁能改哪个项目，什么事要等人拍板，怎样证明做对了。
• DeepSeek Harness 实测下来，接口满足作为执行器接入的条件，暂不接入；两个进程同时改同一个仓库都会成功、互不知道对方，跑完也不等于做成，这些要由上一层来管。

我们用 AI 编程工具交付项目，主力是 Claude Code 和 Codex，两家怎么用、怎么换的经过，写在《Claude Code、Codex 与 APSer-Atelier》里。两家之上，是我们自研的工作平台 APSer-Atelier：它接住要做的事，决定交给谁做、谁能改哪个项目、什么时候等人拍板、做完怎样算数。

9 月里我们自己反复问过一个问题：外面已经有不少把多个 AI 编程工具组织起来的开源项目，Claude Code 和 Codex 自己也在加会话管理，Atelier 还有没有必要自己做？

为了回答它，我们做了两轮对照。9 月 9 日，逐项查阅了六个开源编排项目的官方文档；9 月 21 日评估了 DeepSeek 开源的 DeepSeek Harness，27 日做了一次有界实测，并对照源码逐项核对。本文写对照的方法、结果和我们的判断。

一、执行器、会话编排、控制面，这三层各做什么？

英文里常把这类工具统称为 harness，直译是「挽具」，指把模型包起来、让它能动手干活的那层外壳。统称容易混淆，我们按做的事分成三层来看：

控制面这个词的意思是：负责安排、放行和叫停，自身不直接产出代码。Atelier 分哪几层、各层做什么，见《APSer-Atelier 的技术架构与选型决策机制》。

二、Claude Code 和 Codex 这两个执行器，官方正在补哪些会话管理？

在 Atelier 眼里，Claude Code 和 Codex 都是执行器：同一件事可以交给其中一家，一家不可用时由另一家在同一件事上接着做。两家在读哪份说明文件、记忆放在哪里、检查脚本怎么开关上的差异，前面那篇文章写过，这里不重复。

与本文有关的是另一件事：两家的官方命令行工具，最近几个月都在补会话管理。

日期取自两家在 GitHub 上的发布记录。

两家有一处差异，对控制面影响很大：能不能把一段提示词传进另一个会话。这里要分两种情况：「续接」是会话已经结束，接着它再说一轮；「运行中传入」是会话还在运行，从外面把话送进去。下表的依据均为 9 月 29 日查阅。

差别在第二种。它决定了一件事能不能在运行中的会话之间接力。用 Codex 时，Atelier 可以把人的答复、复核意见直接送进原来那个会话，让它接着做；用 Claude Code 时，一个正在运行的会话没法把话交给另一个正在运行的会话，要么由人转述，要么新起一个会话，把交接内容写成提示词重新交代一遍。我们的交接点和新会话提示词，都写进项目自己的待办文件，也是为了补这一段。

这也说明，只做「启动、列出、发消息、停止、归档」这一薄层的会话管理，官方正在自己做。第三方编排项目如果只做这一层，空间会越来越小。反过来，这也是我们对 Atelier 的要求：会话管理这一层尽量薄，精力放在会话之上的那一层。

三、按七条机制逐项对照，六个开源编排项目各覆盖了哪些？

9 月 9 日，我们从两份社区整理的项目清单里挑出六个，逐项阅读各自的官方文档、接口说明，文档没写清楚的地方再看源码。社区清单只用来发现项目，功能结论只采官方材料。

对照用的尺子是七条机制，都是 Atelier 在自己的交付里需要的：

1. 一件事有边界：一件事从提出到验收是一个单元，以验收证据关闭；
2. 待拍板事项集中：需要人决定的事项登记下来、集中答复，答复回流到执行中的工作；
3. 同一个项目只有一路在改：第二个写入者被拒绝；
4. 在制品有上限：同时进行的工作有数量上限；
5. 收口与回收：做完经过验证才算完成，完成后释放占用；
6. 换执行器不丢认知：项目知识放在不依赖某一家工具的地方；
7. 按额度切换执行器：一家的额度紧张时，改派另一家。

逐项结果如下。六个项目一栏按 9 月 9 日的官方材料填，「未找到」指在当时阅读的官方材料里没有找到，不证明项目一定没有；DeepSeek Harness（表中简称 DSH）是执行器，放在下一节细说，这一栏按 9 月 27 日的实测与源码核对填；Atelier 一栏按我们自己主干上的代码于 9 月 29 日核对。

尺子是按 Atelier 的需要定的，Atelier 一栏几乎全是「有」，理所当然；它能说明的只是这些机制确实做出来了，不说明 Atelier 比这些项目好。第 7 条 Atelier 自己也只做到一部分：能读到两家工具的额度用量，但只用于展示，还没有按额度自动改派。

几点说明：

• 七个被对照的工具里，没有一个七条都覆盖。 DeepSeek Harness 在「同一项目只有一路在改」上实测为无：两个进程同时改同一个仓库，都成功，互不知道对方；做完也没有经过验证才算完成的环节。 六个编排项目里，离工作流这一层最近的是 Relay：有任务依赖图、决策记录、审批、验证与合并跟踪，待拍板一项是唯一的「有」。它把这些记录放在自己的状态目录里。
• 「换执行器不丢认知」六个都是部分。 各项目都能把上下文交给另一个执行器，但交接的内容存在该项目自己的状态里；我们要求的是项目知识留在项目仓库里，用开放格式写，换工具、甚至不用这个编排项目，都能读到。
• 「同一个项目只有一路在改」有三个是明确的「无」。 CAO、AoE、SageCLI 的官方材料，都把同一个仓库里多路并行当成正向能力。这一点后面单独说。

有两处设计值得借鉴，只借思路，不接入：Omnigent 把「给会话发一条消息」拆成「已排队」「已被消费」两个可查询的状态，发消息成功不再只是「写进去了」；CAO 给会话状态定了一套明确的词：空闲、处理中、等待用户回答、已完成、出错。

还有一条是按我们的项目边界规则得出的：六个项目都不能成为 Atelier 运行的前提。Atelier 发布之后，要能在不安装、不启动任何第三方编排项目的情况下独立运行；第三方停更、升级或认证失效，Atelier 里已有的记录不能因此失真。按这一条，只能把它们放在隔离的、可以整个删掉的环境里试用，不能让 Atelier 依赖它们。

四、DeepSeek Harness 在一次有界实测里表现如何？

DeepSeek Harness 是 DeepSeek 开源的智能体运行框架，MIT 许可，处于开发者预览阶段。官方的安全说明写明：它没有经过安全审计，不应视为生产就绪。

9 月 21 日的资料评估，结论是值得作为一个可替换的执行器试一次。9 月 27 日凌晨，我们按下面的边界做了实测：

• 固定版本 0.1.7-rc.2，装在临时目录里，不做全局安装，也不写用户目录下的配置；
• 子进程只拿到运行所需的几个环境变量，本机其他凭据不进入；
• 验证对象是这层外壳，模型用本机 Ollama 上的 qwen3-coder-next，零费用，数据不出本机；另用同一组任务、同一套配置，换 deepseek-v4-pro 做对照；
• 夹具是一个零依赖的 Python 小仓：5 个测试里 3 个失败。

主要结果：

从执行器的角度看，它的接口可以接：一次任务一个进程，事件输出结构清楚，每一步带用量，会话可以续接，失败有明确的错误类型。同时有三件事，接入的一方必须自己补上：

• 成功要看两处。 退出码为 0，且回合是正常完成的，才算这一轮跑完；只看最后那条输出，中断时也会误判成功。
• 跑完不等于做成。 权限申请被拒，退出码照样是 0。产物对不对，要由上一层独立核对。
• 两路同时改同一个仓库，它不管。 这要由上一层来管。

同一天，我们把 Atelier 的 14 项能力逐项对照它的源码：它有 1 项（子代理与多代理编排），部分有 9 项，没有 4 项。没有的 4 项是：同一个仓库只允许一个写入者；在隔离的写入环境里改、由上一层验证后才并入；提交、推送、发布、验收与回滚；推送通知给人。

这次核对还有一个插曲：第一版对照表是按文档判断的，逐项看过源码后改正了 4 处，有的判重了，有的判轻了。只看文档下的结论，并不可靠。

它也有 Atelier 值得借鉴的地方：实验包里的自动复审按实际影响把一次操作分成低、中、高三级风险，高风险一律拒绝，中风险要当前指令明确授权；会话日志用文件锁保证同时只有一个进程写；文件工具在写入前核对「读过之后有没有被别人改过」。

最后的决定是：它的接口满足作为执行器接入的条件，暂不接入。现有的 Claude Code 和 Codex 已经覆盖了我们的受管执行，多接一个执行器要多维护一份，需要有一个具体的用途来抵偿。等出现适合交给本地模型或其他模型的一类任务，再按上面三条补齐判定后接入。

五、执行器这一层，我们为什么不自己做？

9 月 9 日，我们为本机大模型写过一层很薄的执行外壳做试验，想看看本地模型能不能独立完成一次完整的改动。

第一轮只给了模型三个工具：读文件、整文件写回、运行白名单里的命令。模型写出的功能代码是对的，却在更新变更记录时出了事：读文件时内容被截断，模型以为那就是全文，整个写了回去，一份 13934 行的变更记录变成了 32 行。好在全程没有提交，从备份恢复了。

第二轮补上了六个基本工具：按唯一锚点做局部替换、截断时明确提示、已存在的文件不允许整文件覆写、拒绝时告诉模型正确写法、同一调用连续重复就打断、按窗口裁剪历史。换一个 27B 的本地模型做同一件事，它独立走完了改实现、补测试、跑通 15 个测试、写变更记录、升版本号、提交，通过了五道提交前检查。其间被打断 4 次、被拒绝 3 次，每次都换了做法，最后成功。

那次试验的记录里写了一句：风险不在模型能力，在外壳的编辑工具。局部替换加唯一性校验、权限提示、上下文压缩，这些 Claude Code 和 Codex 早已做得很成熟。执行器这一层要做好，需要大量这样的细节，官方团队在持续投入；我们一个人去重做，既做不过，也没有必要。本地模型怎样作为执行器接进来，等跑通一条完整的任务链之后另写。

从经济学看，这个取舍也有依据。《权力与预测》一书把 AI 归结为预测，并指出：预测越便宜，它的替代品越不值钱，和它互补的东西越值钱 [11]。执行器生成代码，属于预测，更新快、越来越便宜，也越来越容易替换；和它互补的，是判断和对结果负责，以及记下每一次结果的数据。所以我们选择执行器用现成的，把力气花在组织工作、等人拍板和留下记录的那一层。

六、Atelier 管的那一层具体管什么？

对照下来，Atelier 自己做的，是执行器和会话编排都没有覆盖全的那一层。下面几项都已在我们自己的交付中使用：

• 一件事一条记录。 一个意图对应一件事，每一轮执行记为一次运行；一件事要进入「进行中」，必须先写清下一步；做完要有验证记录才能收尾。
• 一个项目只有一路在改。 每个项目同一时间只允许一个写入者，这个上限只能是 1，配置成别的数会被直接拒绝。写这篇文章时就遇到了一次：我们想为这篇文章另开一件事，Atelier 当场拒绝，理由是官网项目已被另一件事占着，「拒绝第二 writer」。于是这篇文章接在同一件事里写。
• 状态说不清时，先停下来恢复。 执行中途出了说不清结果的情况，这个项目进入恢复状态，仍算被占用；恢复之前不许第二个写入者进来，结果不确定的操作也不盲目重放。
• 改动先成候选，核对通过才并入。 执行器在一个不带版本库的私有快照里改，改完由控制层两遍固定为不可再改的候选；控制层重新验证，并入时再核对一次主线在这期间没有被别人动过，对得上才并入，对不上就拒绝。这一步只在本地提交，不推送。
• 在制品有上限，分深浅两类。 平台同时运行的工作，默认配置是深 4 个、浅 1 个；名额满了，新的工作排队。人这一侧另有一层：同一时间只推进一条主线。
• 该人拍板的，单独等人。 需要人决定的事项登记成待拍板，写清选项和代价；关联的那件事在答复之前不能继续，别的项目不受影响。需要本人亲自答复的事项，可以开启推送到手机。派出去的执行器不能推送、部署或改动凭据。
• 另一家复审，可以开启。 开启后，Claude Code 写的由 Codex 复审，Codex 写的由 Claude Code 复审，不许同一家自己审自己；复审不通过，退回原来那件事返修。
• 项目知识留在项目里。 规矩和踩过的坑写在项目仓库的开放格式文件里，哪家工具接手都读得到。
• 提示词可以在会话之间传。 人的答复、复核意见可以送进原来那个 Codex 会话接着做；Claude Code 的会话在 Atelier 上等待并取回答复。
• 执行器可以换。 派出去的工作默认交给 Codex；Claude Code 作为写入者可以开启，开启后 Codex 优先、Claude Code 兜底。在对话里和我们一起工作时，两家都在用。

这些做法是怎样从一个个痛点里长出来的，见《APSer-Atelier 的场景锚定与价值定位，以及实践总结》。

七、这次对照有哪些边界？

• 尺子是我们自己的。 七条机制和十四项能力，都是按 Atelier 的需要列的。被对照的项目各有自己的设计目标：有的面向团队并行，有的只管一次任务。它们在某一条上是「部分」或「无」，说明它们没有按我们的方式做，不说明它们做得不好。
• 「同一个项目只有一路在改」不是通用答案。 我们是一人公司，没有人手去评审和合并多路并行的改动，所以第二个写入者必须直接拒绝。团队有分支保护、代码评审和处理冲突的人，需要的是「可以并行，但彼此隔离、可以追溯」。其余几条，如一件事有边界、待拍板集中、在制品上限、做完验证后回收、换执行器不丢认知，在多项目并行的场景里更通用；按额度切换执行器，只在确实有几家可以互换、额度又是瓶颈时才值得做。
• 资料有日期。 六个项目按 9 月 9 日的官方材料，DeepSeek Harness 按 9 月 27 日的版本。这些项目更新很快，Codex 那两次会话管理的更新，距我们查阅只有三周。结论要随版本复核。
• 没有全部实测。 六个开源编排项目只读了官方材料，没有在本机安装运行；实测的只有 DeepSeek Harness 一个。

以下是我们的看法

执行器换得比预想的快。 从 4 月到 9 月，我们的主力执行器换过一次，后来两家并用，又试了 DeepSeek Harness 和本地模型。工作秩序如果建在某一家执行器上，每换一次就要重建一次；放在执行器之上、写进项目自己的文件里，换执行器时才不用从头来。

会话管理那一薄层，官方正在补齐。 启动、列出、发消息、停止、归档，两家官方工具都在做。值得我们自己做的，是会话之上的那一层：一件事怎样算做完，谁能改哪个项目，什么事要等人拍板，怎样证明做对了。

自己的规矩，先分清哪些是通用的。 同一个项目只有一路在改，对我们必要，对团队未必。把一人公司的偏好当成普遍需求，容易做出只有自己用得上的东西。

对照要落到逐条机制，并且有出处。 「未找到」和「没有」是两回事；按文档判断和按源码核对，这次就差了 4 处。

如果您也在同时用几家 AI 编程工具，可以先问自己一个问题：换掉其中任何一家，您的项目进度、规矩和验证记录，还在不在？

参考来源