Codex在Windows上的推理回归issue里，用户明确区分了“错误完成输出”和“停滞/不完整执行”可能是不同根因——科研工作流里遇到Codex“看起来在干活但结果不对”时，排查顺序到底该先查模型行为还是先查任务规格？

目录

一、问题的提出：两类失败现象为何不能合并归因

先把场景钉死。科研工作流里使用Codex类智能体，典型任务是：读一批实验数据、写分析脚本、跑出统计量、生成图表、把结论写进报告。某一天你发现结果不对——可能是相关系数符号反了，也可能是脚本只写了一半就停了。直觉上大家会说“模型退化了”，但如果把这两件事放在同一个归因框架里处理，几乎必然导致误判，因为它们的失败位置根本不在同一层。

在Windows平台Codex推理回归的相关issue讨论中，用户已经做出了一个相当关键的区分：错误完成输出指的是模型正常触发结束符、输出结构完整、但内容与任务意图不符；停滞/不完整执行指的是模型没有正常结束，表现为输出被截断、工具调用悬空、反复重试同一动作或在长上下文里“原地打转”。前者的失败点在语义层，后者的失败点在执行层。本文评述：把两者合并成“模型不行”，等于把语义错误和执行中断混为一谈，后续无论怎么调温度、换模型、加提示词，都只是在错误的分支上做优化。

更麻烦的是，这两类现象在观测上会互相伪装。一个规格模糊的任务，会让模型“合理地”产出一个错误但完整的答案——这看起来像错误完成输出，实质是任务规格缺陷；一个执行环境问题（比如Windows下路径分隔符、编码、子进程超时），会让模型在正确理解任务的前提下被迫中断——这看起来像模型停滞，实质是harness问题。笔者认为，排查顺序之所以值得专门讨论，正是因为现象层与根因层之间存在系统性的错位，而错位方向是可以被先验判断的。

核心判断：错误完成输出优先怀疑规格与上下文；停滞/不完整执行优先怀疑执行环境与工具链。两者都排除之后，才进入模型行为层。这个顺序不是偏好，而是由失败位置的可观测性决定的。

二、背景与问题定义：把“看起来在干活”拆成可观测变量

2.1 任务规格（Task Specification）的严格定义

本文把任务规格定义为：一组足以判定“输出是否正确”的约束集合，包括输入数据的语义、输出格式、计算口径、边界条件、失败处理约定和验收标准。注意这个定义的关键词是“足以判定”——规格的本质不是“把话说清楚”，而是“让正确性可判定”。一个规格如果无法在事后机械地判断输出对错，它在工程意义上就是不完整的。

科研场景的规格缺陷有几种高频形态。其一是口径缺失：比如“计算显著性”没有说明是双侧还是单侧、是否做多重比较校正。其二是格式隐含：要求“输出表格”但没规定列名、单位、缺失值表示。其三是失败语义缺失：数据缺失时应该报错、跳过还是插补，没有约定。其四是上下文漂移：多轮对话中早期约定的口径在后续轮次被覆盖或遗忘。这四类缺陷都会稳定地产生“错误完成输出”，而且换更强的模型往往只会让错误答案更流畅、更自信。

2.2 停滞/不完整执行的可观测特征

与语义错误不同，停滞在观测上有更硬的信号。工程上可用的判据包括：输出是否触发正常结束标记；工具调用是否有配对的返回；同一动作是否在滑动窗口内重复超过阈值；单步耗时是否超过任务基线分布的高分位；上下文长度是否接近窗口上限。这些信号都可以在harness层被记录，不需要模型自省。

Windows平台会放大这类信号。路径分隔符混用、控制台代码页（如GBK与UTF-8）不一致、PowerShell执行策略限制、长路径（260字符）限制、子进程超时与信号处理差异，都会让一个语义上完全正确的计划在执行层断裂。本文评述：很多被归因为“模型在Windows上推理退化”的issue，实际证据链指向的是工具执行层的非确定性，而非模型权重或推理策略的变化。这一点在排查顺序上具有决定性意义。

2.3 为什么“先查模型”是一种系统性偏差

先查模型之所以流行，有三个认知原因。第一是可见性偏差：模型输出是屏幕上最显眼的东西，而规格文档和环境配置是隐形的。第二是叙事偏好：“模型退化了”是一个完整的故事，而“规格没写清楚”需要承认自己的问题。第三是工具惯性：调温度、换模型、改提示词都是低成本动作，而重建规格和回归基线是高成本动作。

但这三条理由都不构成证据。笔者认为，正确的做法是把“先查什么”变成一个可判定的决策问题，而不是一个习惯问题。下一节给出的三层模型，就是把这个决策问题结构化的尝试。

三、原理与技术路线：Spec–Harness–Model三层诊断模型

3.1 三层模型的构造逻辑

本文提出的SHM三层模型，把一次智能体任务的执行链路切分为三个可独立观测的层：Spec层（任务规格与验收标准）、Harness层（执行环境、工具链、日志与超时控制）、Model层（模型行为、解码策略、上下文管理）。三层之间存在单向的约束关系：Spec定义正确性，Harness保证可执行性，Model在两者约束下生成动作序列。失败必然落在某一层，且不同层的失败在现象上有稳定的对应关系。

本文评述：这张表的价值不在于分类本身，而在于它给出了一个排除顺序。Spec层和Harness层的排查成本远低于Model层，且结论更硬。只有当同一规格、同一环境、多次重复都稳定复现语义错误时，才具备把责任归到Model层的证据条件。

3.2 判定主线：先规格、后模型；先可复现、后归因；先边界、后调参

先规格、后模型：任何一次“结果不对”，第一步不是看模型，而是把任务规格拿出来，问三个问题——正确性是否可机械判定？口径是否唯一？失败语义是否约定？如果任一答案是否定的，那么当前观测到的错误完成输出无法归因于模型，因为规格本身没有提供判定依据。

先可复现、后归因：不可复现的失败不能作为归因证据。工程上要求至少三次重复执行，记录每次的输入哈希、环境快照、输出与工具日志。若失败率在重复间波动很大，优先怀疑Harness层的非确定性（超时、并发、编码、网络），而不是模型。

先边界、后调参：在动温度、top-p、上下文截断策略之前，先确定失败是否发生在边界条件上——超长输入、空输入、异常字符、极端数值。边界失败往往有确定性根因，调参只会掩盖它。

# 最小可复现记录模板（伪代码，字段为工程约定）
run_id:       2024-xx-xx-
spec_hash:    sha256(spec.md + acceptance.yaml)
env_snapshot: {os: "Windows 11 23H2", shell: "pwsh 7.4",
               codepage: 65001, python: "3.11.x", cwd_len: 187}
input_hash:   sha256(inputs/)
output_hash:  sha256(outputs/)
exit_reason:  normal | truncated | tool_timeout | loop_guard
repeats:      3/3 fail  -> 可复现

3.3 错误完成输出的诊断树

面对一个“完整但错误”的输出，建议按以下顺序走诊断树。第一步，做验收断言回放：把输出喂给事先写好的断言（列名、单位、数值范围、符号方向），看是哪一条失败。第二步，做规格消歧实验：把疑似模糊的那一条约束显式化，重跑，看错误是否消失。若消失，根因在Spec层，结案。第三步，若显式化后仍错，做上下文隔离实验：把任务拆成单轮、短上下文重跑，排除上下文漂移。第四步，才进入模型对照实验。

这个诊断树的关键设计是每一步都能产生一个可证伪的结论，而不是“感觉好一点了”。科研工作流尤其需要这一点，因为科研数据的错误往往不会立刻暴露，而是污染后续分析。笔者认为，把验收断言前置到任务规格里，是比任何提示词技巧都更有效的稳定性手段。

3.4 停滞/不完整执行的诊断树

停滞的诊断顺序与语义错误不同，它从日志开始。第一步，看结束原因：是正常结束、长度截断、工具超时，还是循环保护触发。第二步，看最后三个动作：是否存在重复调用、悬空调用、对同一文件的反复读写。第三步，做环境降级实验：把工具链换成最小集合（单进程、无并发、显式编码），看是否恢复。第四步，检查Windows特有因素：路径长度、代码页、执行策略、杀软拦截、子进程信号。

一个实用的经验判据：如果失败输出在“内容上是对的，只是没写完”，优先查Harness；如果输出“写完了但内容是错的”，优先查Spec。这个判据不能替代完整诊断，但能在三十秒内把排查引向正确的分支。

四、关键数据与案例：Windows平台上的回归证据链

4.1 公开issue中的现象分布（基于公开讨论的归纳，非统计抽样）

需要说明的是，本节不对任何具体issue做数量统计，因为公开讨论的样本存在严重的选择偏差（报错的人才会发帖）。这里只做现象类型归纳，并明确标注为定性观察。在Windows平台上与Codex类工具相关的公开讨论中，反复出现的现象包括：命令在PowerShell与cmd之间行为不一致；输出文件编码导致后续读取失败；长路径下文件创建失败但错误被吞掉；工具调用返回空但流程继续；以及最典型的——模型在等待一个永远不会返回的工具结果。

本文评述：这些现象的共同点是失败发生在模型之外，但表现为模型行为异常。模型在等待工具返回时表现为“停滞”，在拿到被截断的工具输出后表现为“基于错误信息继续推理”，最终产出错误完成输出。也就是说，Harness层的故障可以同时伪装成两类现象，这正是排查顺序必须先固定Harness层的原因。

4.2 一个可复现的科研场景案例（模拟数据，用于说明机制）

构造一个典型科研任务：读取CSV、按分组计算均值与置信区间、输出Markdown表格。规格里写了“计算95%置信区间”，但没写是正态近似还是t分布，也没写是否假设方差齐性。模型选择了正态近似，输出完整、格式正确，但审稿人要求的t分布区间与之存在系统偏差。这是典型的错误完成输出，根因在Spec层的口径缺失。

同一任务的另一个版本：规格写清楚了，但CSV在Windows下以GBK保存，脚本以UTF-8读取，首列出现乱码，分组键匹配失败，脚本在空分组上抛异常，模型重试三次后放弃，输出半截报告。这是停滞/不完整执行，根因在Harness层的编码不一致。两个版本的现象完全不同，但如果只看“结果不对”四个字，很容易被合并处理。

4.3 回归基线的构建：把“感觉”变成“指标”

科研工作流的回归测试不能只看“跑通没跑通”，要建立三层指标。第一层是执行指标：结束原因分布、平均步数、工具调用成功率、超时率。第二层是语义指标：验收断言通过率、关键数值的相对误差、格式合规率。第三层是稳定性指标：同一输入的多次运行间输出一致性（可用结构化字段的哈希比对）。

这三层指标对应SHM三层，能直接告诉你失败落在哪一层。本文评述：很多团队做回归只做第一层，于是“跑通了”被当成“对了”，语义错误被长期掩盖；另一些团队只做第二层，于是执行层的不稳定被误读为模型波动。三层同时记录，才能把归因从经验判断变成数据判断。

五、对比与局限：先查规格的适用边界与反例

5.1 适用边界

“先规格、后模型”不是万能公式，它有明确的适用边界。第一，它适用于有明确验收标准的任务；对于开放式探索任务（如“帮我想几个假设”），规格本身无法完全形式化，此时应转向过程评估而非结果归因。第二，它适用于可重复执行的任务；一次性、强交互的任务难以建立回归基线。第三，它要求团队具备记录环境快照的工程能力；没有日志，Harness层的排查无从谈起。

5.2 反例：什么时候应该先查模型

存在三类应当优先怀疑模型的情形。其一，同规格、同环境、同输入，稳定复现语义错误，且规格已通过消歧实验确认无歧义。其二，跨平台对照显示Windows显著更差，且环境差异已被逐一排除（编码、路径、shell均对齐）。其三，模型版本切换后出现系统性行为变化，且变化方向与已知的解码或训练差异一致。

即便在这三类情形下，归因也应保持谨慎。笔者认为，“模型退化”是一个强主张，需要强证据；而工程实践中最常见的错误，是把规格缺陷与执行噪声的叠加误读为模型能力下降。一个可操作的纪律是：任何归因到Model层的结论，必须附带“规格已消歧、环境已对齐、失败可复现”三项证据，缺一不可。

5.3 与既有方法的对比

常见的替代思路有三类。第一类是提示词工程优先：通过更详细的指令来“绕过”规格问题。这在短期内有效，但本质是把规格写进提示词，仍然没有解决可判定性问题。第二类是换模型优先：用更强模型覆盖失败。这对语义错误有一定效果，但对执行层故障无效，甚至因为模型更“积极”而放大工具调用问题。第三类是全链路可观测优先：先建日志与追踪，再谈归因。本文评述：第三类与SHM模型最兼容，也是笔者认为最值得投入的方向——它把排查从“猜”变成“查”。

六、工程落地：科研工作流的排查SOP与回归基线

6.1 五分钟分诊流程

第一步（30秒）：看结束原因。正常结束→走语义分支；截断/超时/循环→走执行分支。第二步（2分钟）：语义分支下，跑验收断言，定位失败条目；执行分支下，看最后三个动作与工具日志。第三步（2分钟）：语义分支做规格消歧实验；执行分支做环境降级实验。第四步（30秒）：记录结论与证据，更新回归基线。

# 分诊决策（伪代码）
if exit_reason != "normal":
    branch = "harness"          # 先查执行层
    check(tool_logs, last_actions, env_snapshot)
else:
    branch = "spec"             # 先查规格层
    failed = run_assertions(output)
    if failed and disambiguate(spec, failed):
        root_cause = "spec"
    else:
        branch = "model"        # 最后才到模型层

6.2 科研场景的规格模板

建议每个科研分析任务都配一份最小规格文件，至少包含：输入数据的来源与编码、字段语义与单位、计算口径（含统计方法选择规则）、输出格式（列名、精度、缺失值表示）、失败处理约定（报错/跳过/插补）、验收断言清单。这份文件不是给模型看的提示词，而是给人和机器共同使用的判定依据。

本文评述：把规格写成文件，最大的收益不是模型更听话，而是团队内部对“什么算对”达成一致。很多所谓的模型回归，本质是团队成员对任务口径的理解本来就不一致，模型只是把这个分歧暴露了出来。

6.3 Windows环境检查清单

建议在每次回归前固定检查：终端代码页是否为UTF-8（chcp 65001）；Python的默认编码与文件实际编码是否一致；工作目录路径长度是否接近260字符；PowerShell执行策略是否允许脚本；子进程超时设置是否合理；杀软是否拦截了临时文件写入；路径分隔符是否在跨工具传递时被错误转义。这份清单可以直接作为Harness层的回归用例。

6.4 拓展学习资源

以下资源可用于深入理解本文涉及的概念与工程实践，均在新窗口打开：

• Microsoft PowerShell 官方文档——用于核对Windows下命令行为与执行策略。
• Python codecs 文档——编码一致性排查的权威参考。
• Windows 最大路径长度限制说明——长路径问题的官方解释。
• NIST 软件质量组——软件测试与可复现性相关方法学资料。
• arXiv cs.SE 最新预印本——跟踪智能体工程与回归测试的前沿工作。

七、结论与展望

回到最初的问题：科研工作流里遇到Codex“看起来在干活但结果不对”，排查顺序到底该先查模型行为还是先查任务规格？本文的答案是：先查任务规格，再查执行环境，最后才查模型行为。这个顺序不是对模型能力的否定，而是对失败位置可观测性的尊重。错误完成输出与停滞/不完整执行之所以必须分开处理，正是因为它们分别指向Spec层与Harness层，而这两层的排查成本远低于Model层，结论也更硬。

展望未来，笔者认为有三个方向值得关注。第一是规格的形式化：把验收断言变成可自动生成、可自动回放的工件，让“什么算对”从口头约定变成工程资产。第二是执行层的可观测性标准化：为智能体工具链定义统一的日志与追踪格式，使跨平台差异可被量化而非猜测。第三是归因方法学：借鉴软件工程中的缺陷定位与因果推断方法，把“模型退化”这类强主张纳入可证伪的检验框架。本文评述：这三件事都不性感，但它们决定了智能体能否真正进入严肃的科研生产流程。

主要参考文献