从 Workflow Harness 到轻量 Prompt：Codex 5.6 之后我删掉了什么

2026 年 8 月，我把自己用了几个月的 AI 研发 Harness 做了一次接近重写的删减。

这不是把几段 Prompt 改短，而是撤掉了一套已经可以运转的控制平面：阶段 DAG、StateV3、追加事件链、Worker 计划、一次性写入授权、隔离 worktree、Patch Bundle、Promotion Runtime、Provider 回执与恢复逻辑，都退出了日常开发主路径。

这次改动以删除为主。稳定控制面与启动时共同加载的 Prompt，都缩到了原来的一小部分。

数字很夸张，但「删得多」不是结论。真正值得记录的是：为什么一套在 Codex 5.4、5.5 时明显提升效率的系统，到了 5.6 反而开始拖慢流程；以及删掉运行时以后，严谨性和安全性究竟放到了哪里。

先讲结论：我删的是重复控制，不是工程纪律#

旧 Harness 做对了很多事。它把原本依赖经验的工程习惯变成了显式契约：

• 当前源码和真实 Provider 状态高于聊天记忆；
• 澄清、设计、实现、评审和交付拥有不同的权限边界；
• 状态、事件和产物不能互相冒充；
• Worker 只能提供证据，主 Agent 才拥有最终综合；
• 写入、外部调用和发布必须有可回读的结果；
• 测试通过、Pipeline 成功和线上正确是不同层级的事实。

我最终删掉的，是为了强制这些原则而逐层长出来的通用编排。原则仍然保留，只是不再要求每一次普通修改都先进入一套自建的工作流引擎。

新的分工可以概括为：

模型与平台负责常见任务的探索、计划、编辑和验证
仓库负责稳定的业务知识与机械约束
顶层规则负责高后果动作的授权边界
Git、测试、Provider 与线上入口负责提供事实证据

这不是从「系统」退回「一句 Prompt」，而是把每种控制重新放回最合适的层。

旧 Harness 为什么会长成一个控制平面#

Marshall 的成熟版本并不是一份线性清单。稳定规则位于仓库内受版本控制的规则目录，每次运行的状态与证据位于被忽略的单次证据目录。前者是 Control Plane，后者是 Runtime/Data Plane。

一次实现任务的真实路径大致如下：

目标路由
  -> Progressive Context / Perception
  -> Stage DAG 与依赖检查
  -> StateV3 lease、revision、generation、fencing
  -> 修改计划
  -> StageWriteGrantV1
  -> 隔离 worktree Executor
  -> PatchBundleV1
  -> Patch Verification
  -> Trusted Host Promotion
  -> 目标工作区回读
  -> 测试、规格同步与 StageResultV1

对于设计和评审，系统还会先生成 WorkerSelectionV1 与 WorkerPlanV1，把风险、角色、上下文 Hash、输出位置、并发上限和汇合屏障绑定起来。Worker 默认只读，完成不等于被接受；主 Agent 必须等结果仍然与当前输入匹配，才能综合结论。

这套设计针对的是很真实的失败：长任务被 Compaction 打断，恢复后重复执行；评审引用过期代码；Worker 晚到的结果覆盖新一轮判断；Executor 越过文件范围；外部写入超时后被重复提交；「补丁已应用」被误报成「已经上线」。在 Codex 5.4 和 5.5 阶段，它用额外机制换来了稳定性，我的实际体验是划算的。

问题是，任何控制平面一旦开始承担恢复、隔离、审批和可审计性，就会自然长出 Schema、注册表、适配器、兼容层和测试。它不再只是帮助模型工作，而成为另一个需要持续开发的软件产品。

转折点不是一篇文章，而是几次不用 Harness 的任务#

真正让我动手的不是理论判断，而是 Codex 5.6 上几次刻意不用 Marshall Runtime 的任务。

我只给模型当前目标、仓库规则和安全边界，让它直接读取代码、制定最小计划、编辑文件、运行测试并检查 diff。结果并没有出现我预期中的明显退化：模型仍能维持范围，能主动查找真实调用链，也能区分实现、提交和部署。与此同时，它更快进入业务代码，中间产物更少，长任务的上下文增长也更慢。

这只是个人工作流中的小样本，不是严格对照实验。我不能由此证明「5.6 不需要 Harness」，更不能证明所有项目都应该删除工作流。但它足以暴露一个架构问题：当模型已经能可靠完成某项通用编排时，仓库再强制实现一遍同样的能力，净收益可能已经转负。

OpenAI 的 GPT-5.6 模型指南随后给出了更明确的迁移方向：迁移时应在代表性任务上比较质量、证据完整度、Token、延迟和成本；重复指令应该逐组移除，而不是一次性凭感觉清空；外部写入、破坏性动作、成本和范围扩张仍要保留清楚的授权边界。这个建议和我的观察一致，但也提醒了我：精简是一项需要验证的工程变更，不是一种审美偏好。

真正的瓶颈是 Harness 自己进入了上下文#

旧版并非把十万级文档一次塞给模型。它已经有 P0 到 P3 的 Progressive Context：当前阶段只加载必要命令、相关领域规格、风险视角和少量运行产物，大材料尽量只保留句柄。

但按需加载只能减少业务材料，消除不了控制平面的固定成本。每一轮仍要让模型理解：

• 当前目标对应哪个 Stage；
• 哪些 Node 和 Completion Barrier 必须满足；
• State、Event、Artifact 各自是谁的权威；
• Lease、Generation 和 Freshness 为什么可能让结果失效；
• Worker Report 怎样汇合；
• Write Grant、Patch Bundle 和 Promotion 分别允许什么；
• 当前结果应该写入哪个逻辑 Artifact Role。

随后，系统还会继续生成状态投影、事件、回执、Hash 绑定和验证产物。这些内容并非完全无用，但它们和需求、源码、测试争夺的是同一份注意力预算。

Anthropic 的 Context Engineering 文章把 Context 视为有限资源，并强调随着内容增长，新增 Token 的边际价值会下降。它也把 Compaction、结构化笔记和多 Agent 视为不同任务形状下的工具，而不是每次都要同时启用的标准套餐。这更准确地描述了我遇到的问题：旧 Harness 虽然帮助恢复，却也让 Compaction 更早发生；压缩以后，模型先要恢复的又是 Harness 自己的运行语义。

一次压缩的代价不只是「丢掉一些文字」，而是一连串恢复工作：重新确认阶段、租约、输入 Hash、未完成节点、有效产物和下一条允许的 Transition。对模型能力较弱的阶段，这些成本换来了确定性；当模型不依赖它也能稳定完成常见路径时，同一成本就变成了流程税。

我用四个问题决定一个机制的去留#

这次没有按目录机械删除，而是对每个机制问四个问题：

1. 它约束的是模型推理，还是现实后果？
2. 平台、Git 或 Provider 是否已经提供同等可信的能力？
3. 失败后是否需要跨进程恢复、重放或审计？
4. 它带来的风险下降，是否大于上下文、延迟和维护成本？

最终结果如下：

机制	成熟版解决的问题	最终处理
目标路由	区分澄清、实现、评审和交付的授权边界	保留为轻量 Goal Map
Progressive Context	让当前源码、领域规格和风险证据优先	保留按需加载，删除复杂 Loader Runtime
Stage DAG	表达并行、等待、重入和完成屏障	普通任务交给模型计划；真正不可交换的依赖继续显式化
State / Event / Artifact	长任务恢复、因果链和可交付结果分离	不再默认生成；长运行与审计自动化按需采用
固定 Worker 与 Team Plan	用独立视角降低确认偏误	改为按风险临时委派，不维持固定编制
Write Grant 与隔离 worktree	将写入限制在一次、一个版本和一组路径	从日常路径移除；高风险环境仍可使用 sandbox/worktree
Patch Promotion	在低信任执行器与真实工作区之间做校验传输	删除自建 Runtime，改用原生编辑、Git diff 和测试
Preview / Approval / Readback	防止外部副作用越权或不确定重试	完整保留
Protected Branch / Data / Cost / Destructive Gates	控制高后果动作	提升到顶层配置和机械 Hook

关键区别在于：模型可以越来越擅长规划，但不会因此获得替我决定生产写入、真实费用和不可逆操作的权力。能力会随版本变化，授权关系不会。

新架构不是「什么都交给模型」#

精简后的 Marshall 是一个很薄的 Context Router：

用户目标
  -> Marshall Skill 解析目标
  -> 读取一条对应命令
  -> 按需读取领域 Spec / 风险 Lens / Local RAG / Provider 证据
  -> 使用 Codex 原生计划、工具、编辑、测试与可选委派
  -> 返回结果、证据和残余风险

常驻层只包含项目 AGENTS.md、精简宪章和路由 Skill。impl、local-review、pr-submit 等命令按目标单独加载；完整规格树、历史研究、旧审计包和无关领域不再预载。

实现任务也不再要求 Jira、设计文件、审计目录、Worker Report 或 State Object 作为通行证。它的常见路径只有：

确认分支、范围和真实来源
  -> 追踪受影响代码
  -> 形成最小安全计划
  -> 修改已接受范围
  -> 按风险验证
  -> 检查最终 diff
  -> 报告已证实内容和剩余风险

这条路径依然严格，只是把证据换回本来就存在的事实源：当前代码、git diff、测试输出、远端 Ref、CI 状态、部署记录和线上回读。

pr_commit 的变化最能说明新的授权模型#

旧版交付依赖 Hash 绑定的预览、运行时 Gate、审批 Envelope、Provider Adapter 与多层 Receipt。机制很严谨，但用户说出的动作和内部协议之间距离太远。

精简后，commit、push、pr-submit、merge、deploy 再次成为五个不同的字面目标。pr_commit 只兼容性地表示：验证已接受范围，在 feature branch 上提交并非强制推送，然后准备 PR 的标题、正文、Reviewer、源分支和目标分支。Bitbucket 创建或更新仍然要展示精确预览并重新确认；合并和部署依旧不在授权之内。

这不是降低控制，而是把控制放在副作用发生前的那一刻。普通本地工作不再反复暂停，高后果动作仍然必须停下。

安全从流程机制收缩成了少量不变量#

删掉 Promotion Runtime 之后，安全不再依赖「每次修改都先去隔离执行」。它由四层共同承担：

1. 顶层配置定义受保护分支、生产或持久化数据、费用、破坏性与外部动作的确认门槛；
2. 仓库规则限制当前项目的分支、范围和领域行为；
3. Sandbox、文件权限和受保护分支 Hook 提供机械边界；
4. Git、测试、Provider 与线上入口提供执行后的独立回读。

这和 OpenAI 在 Harness Engineering 中总结的方向相似：入口应该更像地图，而不是把全部知识写成一本常驻说明书；同时，真正重要的边界要机械执行，而不是在 Prompt 里反复劝模型小心。

现在能证明什么，不能证明什么#

在简化分支的一次本地快照中，我能确认的结构事实是：旧 Runtime 和固定 Agent/Team/Promotion 目录已经退出主路径；轻量 Validator 仍会检查结构预算、路由可解析、残留 Runtime 引用、Agent 迁移、Local RAG 只读标记、图形有效性和受保护分支 Hook。这些状态会继续演进，不能被当成永久现状。

我也能确认主观体验：几次任务更快进入真实代码，中间记账更少，Compaction 更晚，压缩后的恢复更简单。

但这些还不能证明新方案在长期正确率上优于旧方案。文件少不是质量指标，Pipeline 绿色也只证明契约在当前检查范围内自洽。后续应该持续记录：

• Time to First Useful Edit；
• 每个任务的总 Token、工具调用与 Compaction 次数；
• 首轮聚焦测试通过率；
• Local Review 的有效发现率与误报率；
• PR 后返工次数；
• 被安全门禁正确拦截和错误拦截的次数；
• 部署后回归与人工介入时间。

只有这些指标在相似任务上长期稳定，才能说明精简提高了净效率。否则，删掉的机制还可能需要按风险重新引入。

最终理解：Harness 也需要被版本化地怀疑#

早期 Marshall 的价值，是把隐性工程纪律变成模型可见、运行时可执行的结构。它在 Codex 5.4、5.5 上解决了当时真实存在的问题，因此并不是一段「走过弯路」的历史。

但 Harness 中每一条规则都包含一个关于模型能力的假设：模型不会自己规划、不会稳定维护范围、不会在 Compaction 后恢复、不能可靠使用原生工具。模型升级后，这些假设必须重新验证。否则，为旧能力边界设计的脚手架会逐渐变成新模型的负担。

我现在更愿意把 Harness 看成一套可淘汰的假设，而不是永久架构：

• 模型做不稳、且失败代价可控的能力，用上下文、工具和评估帮助它；
• 可以机械验证的边界，放进代码、Hook 或 Provider Policy；
• 会产生真实后果的动作，保留清楚而独立的授权；
• 只有真正需要恢复、重试和审计的流程，才升级为持久化工作流。

这次转变不是从严谨走向随意，而是从「用工作流约束每一步」，转向「让模型负责路径，让证据证明结果，让门禁控制后果」。

延伸阅读#

• GPT-5.6 Model Guidance：精简 Prompt、定义授权边界，并用代表性任务比较质量、Token、延迟和成本。
• Harness engineering: leveraging Codex in an agent-first world：仓库知识、Agent 可读性、反馈回路与机械边界。
• Effective context engineering for AI agents：Context 预算、Compaction、结构化笔记和多 Agent 的适用形状。
• Effective harnesses for long-running agents：长任务怎样借助进度文件和 Git 历史跨会话连续推进。

下一篇可以从整体架构开始，逐层查看旧 Harness 最终成熟版的设计。顶层安全边界则单独写在Agent 自主之前的 Safety Gates中。