GPT‑6 Astra 之后，哪些 Harness 还值得做？

这周前沿模型疯狂出货，基模厂更新的速度已经快到模型名和版本号根本无法记住的地步🤯

无一例外都让你免费用，一会在这个 code 一会儿在那个 router,生而为人，我薅的好无助，不过我无一例外都薅了。

然后在疯狂使用前沿模型后，除了惊喜和疲惫外，就开始思考模型和 harness 之间的关系。因为我自己这大半年也一直在做 harness 相关的开源，我的感受是基本上是一个动态细化的过程，跟着 claude code,codex 两大顶流 harness 工具一起成长，现在还是 harness 生态的初级阶段。

我发现，有一类工程优化，做的时候很有效，换个模型就可能该删了。

Anthropic 公开过一个例子：Claude Sonnet 4.5 接近上下文上限时，会提前收尾。

团队在 Harness 里加入上下文重置，缓解这种行为。等换到 Opus 4.5，原来的问题消失了，那套重置机制也就成了额外负担。

这件事比“模型越来越强”具体得多。它提醒我们，写进 Harness 的一些规则，可能只是某一代模型的使用经验。

现在 GPT‑6 Astra 出来了，类似的检查值得再做一遍。

之前安排的规划、分工、摘要、复核，还有多少在改善结果？

哪些步骤只是在延续旧模型留下的习惯？

如果官方产品已经提供历史检索和执行管理，我们自己做的那一层，还剩下什么价值？

我的判断是，围绕模型能力缺陷搭起来的流程，会最先承受删减压力；

负责外部状态、执行权限和业务验收的部分，仍然有大量工作可做。

通用运行能力则会越来越多地由平台提供。

这三种情况混在一起，很容易得出“Harness 没用了”或者“Harness 永远最重要”这样的结论。

落到一个实际项目里，两句话都不够指导开发。

同样叫“被吃掉”，能力消失、实现迁移和责任保留是三种不同情况。本文分析示意。

先检查那些要求模型照着走的步骤

这里说的 Harness，是模型外面负责组织工作的那套系统：给它什么上下文、允许调用哪些工具、如何持续执行、在哪里保存进度，以及拿什么判断任务完成。

其中有一部分，很像给旧模型写的详细操作说明。

接到任务先生成计划，交给另一个角色检查，再交给执行者；执行者做完，由评审角色提出问题，最后再安排一次综合判断。

每个阶段都输出固定格式，进入下一阶段前还要总结一次。

在模型容易漏步骤、跑偏的时期，这样做有现实理由。但模型升级之后，每一轮调用都应该重新证明自己的作用。

假设任务只是修复一个接口的参数校验。一个能够读懂调用链、修改实现、补充测试的模型，已经可以在一次连续工作中完成。

强制拆成几个角色，会增加上下文交接。

上一个角色看到的原始报错，下一个角色可能只拿到一段概述；真正需要修改的边界条件，在交接时被整理成了泛泛的“加强健壮性”。

角色多了，信息反而可能少了。

这也是我认为固定式多 Agent 编排最需要重新评估的地方。

多个 Agent 读取同一批材料，用相近的提示词讨论同一个问题，未必能带来足够独立的判断。它们也可能一起接受了最初那个错误前提。

有明确工作边界的并行仍然有价值。几个互不依赖的模块可以分别检查；兼容性审查与性能测试可以同时进行；

大范围检索可以按资料集合切开。这里的收益来自任务可并行、证据不同、上下文可以隔离。

如果只是给同一段推理换几个身份，收益就需要用数据说明。

Astra 的官方使用指南也提示了另一个变化：它对 Skill 和 AGENTS.md 里的指令更敏感，含糊或冲突的规则可能导致提前停工；

小任务也可能触发超出所需范围的测试。这意味着旧 Harness 中“每次都要全面检查”一类规定，可能被执行得更加认真。

模型更会遵守规则之后，规则本身的质量就更容易暴露。

值得保留的，是项目特有的约束：哪些模块不能直接依赖、什么操作需要确认、怎样算通过验收。

至于“请认真思考”“再全面反思三遍”这类通用要求，可以先放进删减实验里。

记忆不会凭空出现，但我们可能不用自己做了

Astra 发布资料里有一个值得单独看的细节。

在 Codex 中，Astra 可以跨上下文窗口保存笔记，也可以搜索之前的窗口，找回没有被记进笔记的需求和测试结果。

发布时，这还是需要配置开启的实验功能，官方计划在随后几周设为默认。用户感受到的是“模型终于记得住了”。

从实现上看，这里面有历史存储、有检索、有笔记，还有模型决定什么时候去查。

因此，一个只提供“定期总结对话，下一轮再塞回去”的记忆产品，确实会遇到压力。

官方运行环境一旦把历史检索做好，用户就少了维护第二套摘要系统的理由。

但这不能进一步说 RAG 或上下文工程已经过时。

模型能处理更长的材料，仍解决不了材料没有接进来的问题。

它也无法仅靠阅读能力判断，一份旧设计文档和今天的线上配置，究竟应该以哪份为准。

企业内部还有权限边界：某位用户能访问的客户资料，不能因为检索方便就提供给另一位用户。

上下文系统接下来值得投入的地方，会更具体。

检索结果能不能追溯到原文？资料修改后，旧索引何时失效？同一个配置出现多个版本时，哪个是当前事实？

任务中的临时猜测，会不会被存成长期知识？

这些问题即使交给一个理解能力很强的模型，也需要系统提供依据。

Anthropic 将会话日志保存在上下文窗口之外，允许按需重新读取历史事件。

OpenAI 自己介绍 Harness 工程时，就把较短的 AGENTS.md 当作导航，将详细知识放进有版本管理的仓库文档，

并用检查程序维护链接、结构和时效。这个设计把原始资料留在可查的位置，减少了每次把所有规则塞进提示词的需要。

因此，记忆层值得做的调整，是减少反复压缩，保留可追溯的原始记录，并把当前有效的信息找准。

至于笔记存储和会话搜索是否还要自己实现，要看平台提供到哪一步。

模型再聪明，也不能靠推理确认一次写入

考虑一个很普通的执行故障。

Agent 调用接口创建了一份文档。服务端已经创建成功，但响应在返回途中丢失，客户端收到超时。

这时再调用一次创建接口，可能得到两份文档；

直接报告成功，也可能出错，因为请求还存在根本没有到达服务端的可能。

上下文再长，推理再深入，也不能从一个超时结果中恢复出服务端的真实状态。

系统需要提前安排查询方式。如果接口支持幂等键，就让同一次业务操作始终携带相同标识；

如果能够查询操作状态，就先读回结果；

两者都没有时，需要承认状态不确定，停止盲目重试。

超时只说明没有收到确定响应；恢复操作需要查询依据或接口提供的幂等保证。本文故障示例。

这类问题不会随着模型升级消失。

同样的情况还包括：

进程中断后从哪里接着做，两个 Agent 是否正在修改同一份数据，一项外部操作已经发生但本地进度尚未保存，

以及预算耗尽时如何停止仍在运行的任务。

这里，“记得刚才做了什么”和“知道外部系统实际发生了什么”有明显差别。

一段对话摘要可以保存前者，后者需要操作记录和权威状态查询。

所以，执行必须有界，也必须能恢复。

“有界”要落实到工具和运行环境中。

例如，只给当前任务需要的权限，限制外部调用费用，规定最长运行时间，并提供可用的取消机制。

提示词中的预算要求可以帮助模型做决策，实际限额还得由程序执行。

“能恢复”也需要比“继续刚才的任务”更多的信息。系统必须分清已完成、未开始、执行失败和结果未知。

尤其是结果未知，不能被一个简单的失败状态吞掉，再交给重试器处理。

这部分 Harness 可以交给成熟平台，也可以根据业务需要自己做。无论由谁实现，相应职责都得有人承担。

Managed Agents 将会话、Harness 与执行沙箱分开建模，让各部分可以独立更换。

Anthropic 的 Managed Agents 就将会话日志、Harness 和执行沙箱拆成独立组件，允许各自更换实现。

通用基础设施被平台承接，是另一种“被吃掉”：功能继续存在，只是应用开发者不必重复维护。

官方接口表列出 Session、Harness 与 Sandbox 各自的职责；它不等于任意外部业务操作都能自动恢复。

复核可以少几轮，验收得更具体

模型升级后，我会优先减少那种没有新增证据的复核。

让模型把自己的答案再看三遍，可能发现遗漏，也可能只是把答案改得更像经过检查。

一个“评审通过”的文本结果，无法证明代码已经覆盖了并发问题，更无法证明外部文档已经正确写入。

独立验收依然值得投入。这里的“独立”，主要指验收依据独立于执行者的解释。

修改接口，要有能够触发原始问题的测试；迁移数据，要核对记录和业务不变量；生成页面，要实际检查交互和渲染；

向外部系统写入，要读回目标对象。

模型可以帮助生成测试、定位失败、解释差异，但完成状态应该绑定这些证据。

这也有助于控制验证成本。一个文本修改没必要自动触发整套端到端测试，一处涉及支付状态的变更却不能只做语法检查。

Harness 可以根据改动范围和风险选择验证器，通过以后收尾；

没有新改动和新证据，就不必继续安排同类复核。

更强的模型能够在这套机制里发挥更大作用，因为它更有机会理解测试失败的原因，并修正实现。但业务验收条件仍然要由业务方明确。

“退款成功”究竟指申请已受理，还是资金已退回？“文章交付完成”指本地生成，还是目标平台上已经能正确阅读？

这些定义含糊，模型再强也可能完成了另一个版本的任务。

还有一批 Harness，需要换个优化目标

把前面的判断放在一起，可以得到一份比较实际的检查表。它表达的是优化方向，不能代替具体任务上的测试。

固定规划、反思、角色接力

常规任务可能不再需要这么多轮次

可继续投入：按任务难度触发，保留有增益的步骤

多 Agent 编排

身份分工本身不足以证明收益

可继续投入：独立任务并行、上下文隔离、冲突控制

摘要与记忆

简单会话摘要容易被原生能力替代

可继续投入：原始记录、时效、来源与访问权限

工具适配

通用点击脚本、格式修补可能减少

可继续投入：清楚的工具语义、权限、幂等与状态查询

执行与恢复

平台会接管更多通用实现

可继续投入：业务操作记录、取消、预算、异常恢复

质量检查

重复文本复核的收益可能下降

可继续投入：可复现测试、外部读回、业务验收

对开源项目和产品来说，还要多问一句：这一层功能即使有必要，用户为什么需要单独使用你的实现？

“Agent 需要记忆”不能自动证明一个记忆产品有竞争力。

官方提供了基础功能后，用户会比较接入成本、数据控制、跨模型迁移和实际效果。

同样，“Agent 需要可靠执行”也不能保证每个工作流框架都有价值。

如果接入平台原生运行环境就足够，重复做一套调度器可能很难获得回报。

只有遇到平台覆盖不到的业务语义、部署条件或可靠性要求，自己维护的成本才更容易成立。

这会影响开发优先级。通用提示词编排可以继续做，但不宜把它当成长期稳定的优势。

真实任务的失败记录、难以接入的业务系统、能够准确验收结果的测试集，往往需要持续积累，也更容易证明改善了什么。

删掉一层再跑，才能知道它还值不值

目前的公开资料不足以给出“Astra 能替代百分之多少 Harness”的答案。那需要固定任务、工具、预算和验收方法，对不同配置做比较。

一个可操作的方法，是保留旧模型和旧 Harness 作为基线，

同时测试旧模型配精简 Harness、新模型配旧 Harness、新模型配精简 Harness。

先区分模型升级和流程删减的影响，再逐项做消融测试；保护机制在隔离环境中验证。本文实验设计建议。

这样至少能分清：收益来自模型升级，还是删掉了原有流程中的负担。随后再逐项取消规划器、摘要器或复核器，观察变化。

权限和生产保护不能直接拿真实业务做删减实验，这部分应在隔离环境中验证。

评估也不宜只看一次完成得漂不漂亮。

还要记录最终验收通过率、人工接手时间、完成一个有效任务的总成本，以及最慢的一批任务被卡在哪里。

节省了模型调用，却多花半小时人工收拾结果，很难说优化成功。

测试任务里应当留下一些不顺利的情况：接口超时，资料互相矛盾，工作做到一半需求变化，工具返回部分结果，进程在外部写入后中断。

只测试正常路径，会高估模型，也会低估那些平时看起来没什么存在感的工程代码。

我会先从自己最舍不得删的那层开始检查。

当初为什么加它？对应的失败还能复现吗？去掉以后，新模型究竟差在哪里？

如果说不清，只剩下“这样比较完整”，就值得先做一次对照测试。

模型已经升级了，Harness 里那些为旧模型留下的步骤，也该重新验收了。

文章来自于"一支烟花AI"，作者 "烟花老师"。