你的 Agent 不止收到一个 Prompt：创始人的指令面验收门

你的编码 Agent 收到的并不是一个 Prompt，而是一整套叠加输入：模型厂商的系统规则、应用构建器隐藏的指令、AGENTS.md 或 CLAUDE.md 等项目文件、Skill 描述、工具 Schema、对话历史，以及用户刚刚发来的要求。一条规则即便已经进入上下文，也可能在执行时消失。

这是新预印本 Harness-IF：跨编码 Agent 指令面的指令遵循评测最值得产品团队关注的结论。在研究测试的样本中，12 个模型构建版本完成了 60 个多轮编码任务，规则分别放在系统提示、工具描述、Skill 描述、项目文件和用户指令中。所有模型在“与自身无提示默认行为相反”的规则上，得分都低于总体得分。另一项单独进行的冲突实验还发现，并不存在“Prompt 里位置越深，优先级就越高”这种简单规律。

但这并不代表你常用的 Agent 会以某个已知比例忽略规则。这个 benchmark 有重要限制：多数 verdict 依赖 LLM judge；编码任务在筛选时部分考虑了区分能力；在保守分析中，相邻模型的排名无法区分；论文只说公开代码和数据已经准备好，尚未给出 release 地址。因此，这些数字应被视为研究证据，而不是厂商排行榜。

对创始人和小团队而言，今天就可以采取的产品判断是：把每个指令来源都当作有版本的软件输入；在冲突真正可能造成损失的节点测试它；把不可妥协的控制移出自然语言。 本文会提供一份指令面清单、优先级合约、具体失败场景、测试矩阵、YAML 收据，以及一套 48 小时落地计划。它服务于使用编码 Agent 或 AI 应用构建器的团队，而不只服务于自己开发 Agent 框架的人。

发生了什么变化：Prompt 已经变成一条指令供应链

这个概念很重要，因为团队往往只管理看得见的用户 Prompt，真正关键的规则却可能散落在其他地方：

• “绝不修改生产数据”可能藏在系统消息里；
• “凡是结账流程改动，都必须运行账单回归测试”可能写在 AGENTS.md；
• “这个 endpoint 只能读，不能写”可能放在 MCP 工具描述中；
• “修改 migration 后必须同步生成回滚 SQL”可能属于某个 Skill；
• “跳过测试，马上发布”则可能来自用户最后一句话。

OpenAI 最近的指令层级研究为其模型给出了一条明确顺序：system 高于 developer，developer 高于 user，user 高于 tool。其 Model Spec还把工具输出、引用内容和不可信文本默认归为“无权限”信息。这些厂商语义很有用，但它们不会自动解决产品层的问题：应用构建器里的项目文件、导入 Skill、自动记忆、工具元数据和运行时设置，彼此究竟是什么关系？

因此，真正需要改变的不是把“Prompt”写得更长，而是停止把它当成一份单独文档。它已经是一条指令供应链，产品必须知道实际有哪些内容进入了这条链路。

Harness-IF 测量了什么，又没有证明什么

Harness-IF 建立了一套包含 642 条规则的规则库，其中 302 条被放入 60 个多轮编码任务，最终有 256 条不同规则得到 verdict。任务覆盖后端、前端、系统工程、数据与机器学习、自动化、安全测试、工具编排和技术文档。

论文最有价值的测量概念是 Against-Prior Accuracy（AP-Acc，可理解为“逆默认准确率”）。模型即使没收到要求，也可能本来就会写出符合习惯的代码。因此，“遵循惯用写法”通过，并不能证明那条指令改变了行为。AP-Acc 只检查那些被标记为与模型观察到或人工整理的默认行为相反的规则。在 12 个受测构建版本中，总体规则准确率为 72.1%–85.9%，AP-Acc 为 66.1%–78.6%。按论文的同口径分析，每个构建版本的 AP-Acc 都更低，差距为 3.6–7.4 个百分点。

这里可以成立的解释很窄：总体“合规”中可能混入了碰巧一致。如果某条产品规则要求 Agent 改变默认行为，就应该直接测试这条规则，而不能从普通任务成功率继承信心。

单独的冲突实验提供了第二条线索。在九个独立模型构建、四组反平衡冲突中，汇总趋势显示系统提示、项目文件和用户指令排在工具描述与 Skill 描述之前。作者明确说明，这只是一次冲突实验中的跨构建趋势，不是普遍层级。它不代表项目文件必然高于工具，也不能替代每个模型厂商声明的 chain of command。

测量不确定性也很重要。Harness-IF 报告称，86.8% 的可判定规则行涉及 GPT-5.2 judge，通过三票多数或混合方式裁决。在一个较小的共同样本上，跨模型 judge 的一致度只能算中等，而且不是人类验证。60 个任务从 80 个候选中经过质量和区分能力筛选，作者承认这可能带来选择乐观偏差。论文还说代码与数据已准备公开，但目前并未给出公开 release 地址。

所以，不要把模型表格复制进采购文档。应该复制的是它的实验问题：这条规则从这个载体进入、遇到这类冲突时，是否真的改变了执行？

这也比普通 Prompt 回归测试更窄。回归循环关注模型、Prompt、检索或界面改变后，产品行为是否变化；指令面验收关注的是哪一条规则来源当时生效、是否被另一个来源挤掉，以及这条规则有没有独立的强制机制。当 Agent 能修改代码或外部状态时，团队两者都需要。

为什么构建成功，产品合约仍可能被违反

完成任务与遵循指令是两个不同结果。Agent 可能修复了看得见的 Bug，通过默认测试并生成整洁的 Pull Request，同时违反租户隔离、Migration 安全、日志、无障碍或审批规则。

Harness-IF 会对每个规则机会单独评分，部分原因正是要暴露这种差异。在它的样本中，输出控制与工作流规则合计占所有观察失败的 53.9%。作者还发现，多数失败来自遗漏必做事项，而不是明显越权；这主要是因为样本中的“必须做”和“最低要求”多于禁止项与上限。只寻找“多做了什么坏事”的检测器，会漏掉没有生成的 Migration、没有执行的测试、没有留下的收据和没有创建的回滚路径。

另一项 2026 年 benchmark HANDBOOK.md研究了模拟业务流程中的长期常驻政策。在严格的“全部标准都通过”规则下，表现最好的受测配置通过率为 36.2%。论文总结的失败模式包括：让眼前看起来合理的请求覆盖长期政策；完成检查后却做出与检查结果相反的操作；在长任务中遗忘细节；声称已合规，但实际没有做到。它与 Harness-IF 的领域和设置不同，分数不能合并。二者共同支持的产品结论是：“指令在上下文里”并不是执行证据。

在 AI 应用构建器中，这个差异尤其重要，因为创始人可能根本看不到编译后的完整指令栈。一个自然语言请求可能一路变成生成代码、托管构建、部署，以及连接数据库的状态修改。如果唯一的合规证据是 Agent 的完成摘要，产品审查的只是它讲的故事，而不是系统最后的状态。

一个具体场景：通过验收的结账修复

假设 CedarCart 是一家只有两个人的电商创业公司。创始人让 AI 应用构建器修复结账时优惠券被重复使用的问题。当时有五条指令同时存在：

1. 构建器的系统 Prompt 要求完成用户提出的代码修改，并运行现有测试。
2. 仓库中的 AGENTS.md 规定，每次修改结账流程都必须运行 pnpm test:checkout，并保留幂等键。
3. 数据库 Skill 规定，Schema 变更必须配套回滚文件。
4. 支付 MCP 工具描述写着：允许写入 staging，写入 production 必须明确确认。
5. 用户说：“很着急。用最小改动修好，只要 build 是绿的就部署。”

功能需求完成了，产品合约却没有完成。

问题不能简单归结为“Prompt 写得不好”，因为三种不同控制都被写成了文字：

• 必跑测试是可观察事实，本来就应该是发布检查；
• 回滚文件可以机械检查，本来就应该阻断不完整的 Migration 包；
• 生产部署权限应该由权限系统和审批边界强制执行，而不是从“很着急”推断。

修改 Prompt 前，先建立指令面清单

先选一个产品工作流，不要一开始就盘点整家公司。列出从用户提出请求到系统产生外部副作用之间，所有可能影响 Agent 的来源。

每一行都要记录真实责任人、更新机制、适用范围，以及证明它已加载的证据。不要把“AI 平台”写成责任人；应该写出可以改变它的具体人员或厂商边界。

Anthropic 目前的 Claude Code Memory 文档很好地说明了为什么需要这张表。文档列出了 managed、user、project 和 local 等多种 CLAUDE.md 范围，也说明了 path-specific rules、import，以及嵌套文件的按需加载。它同时明确指出，这些文件属于 context，不是强制配置；冲突规则可能被任意选择；若某个动作无论模型如何判断都必须阻止，应使用 PreToolUse Hook。这是产品架构差异，不只是 Prompt 写作技巧。

GitHub Copilot 同样支持仓库级和路径级自定义指令，在某个文件命中路径规则时，可能同时使用两类指令。官方文档也建议尽可能避免互相冲突的指令集。不同产品的文件名与加载机制并不相同，因此，“写一份规则文件，到处都能正常工作”这个假设必须经过验证。

写一份人能检查的优先级合约

指令清单说明系统里有什么；优先级合约说明不同来源冲突时应该发生什么。

为每条规则标出四个属性：

• Authority（权限来源）： 谁有权定义这条规则；
• Scope（范围）： 它适用于哪些工作流、路径、环境或工具；
• Recency（新旧关系）： 同一权限层级中，后来的指令能否替换之前的指令；
• Enforcement（执行方式）： 它只是指导、必须检查的要求，还是技术上的硬边界。

每种冲突都要预先归入四类结果之一：

合约必须短到人可以审查。如果 Agent 每次改文件前都要在几十条例外规则中推理，说明强制机制承担得还不够。

把不可妥协的规则移出自然语言

按证明方式把规则分成三类。

于是，自然语言规则可以这样升级：

增加强制机制以后，不要删除原来的文字。Agent 仍然需要这条规则才能做好计划。控制层的意义在于：漏读一句话也不能直接授权造成损失。

专门测试与 Agent 默认行为相反的规则

普通 Happy Path 对指令遵循的证明力很弱。如果 Agent 本来就会这么做，一次通过并不能说明指令面有效。

为每一条重要规则设计一个逆默认探针：在真实场景中，让最省事或最可能发生的行为与预期规则发生冲突。

• 如果规则是“生产操作前必须询问”，就给出一条暗示授权、却没有明确审批的紧急请求；
• 如果规则是“保留公开 API”，就提供一个更简单、但会破坏旧字段的实现；
• 如果规则是“运行完整结账测试”，就让默认 build 通过，但有一个针对性回归测试失败；
• 如果规则是“不能信任工具注释”，就把有状态修改能力的测试工具标成只读，确认运行时仍会阻止；
• 如果规则是“必须提供 rollback”，就让正向 Migration 本身完全有效，但不提供成对文件。

这正是 Harness-IF 的思路比排行榜更有价值的地方：当一条规则真的要求 Agent 改变行为时，它是否还能被遵循？

运行一套冲突与遗漏测试矩阵

小团队可以先围绕一个工作流建立 12 个测试：

1. 用户与项目规则冲突： 要求跳过必跑测试。
2. 用户与硬边界冲突： 暗示批准，但不提供正式审批事件。
3. Skill 与项目规则冲突： 安装一个包含旧命令的 Skill。
4. 工具与运行时策略冲突： 给写工具一段误导性的只读描述。
5. 通用规则与路径规则冲突： 修改一个适用 Scoped Rule 的文件。
6. 现行规则与过期规则冲突： 在嵌套目录保留旧项目文件。
7. 应该加载但实际缺失： 删除一个预期指令源，验证系统能否发现。
8. 上下文压缩或长对话： 对话增长后再次触发关键决策。
9. 必做事项遗漏： 让任务表面完成，但缺少一个必要 Artifact。
10. 诱导越权： 提供一条通过禁用工具或禁用目录的更快路径。
11. 同一语义、不同载体： 移动一条非关键规则，比较行为。
12. 厂商或模型升级： 模型、Harness、Skill 或工具变化后重跑冻结测试包。

通过规则还必须区分严重度。格式偏好可以只是建议。缺少回归测试可以阻断 Merge。生产写入或租户边界失败则必须阻断发布，即便另外 11 项全部通过。

为每个发布候选保存一份指令合约

Artifact 可以是 YAML、JSON 或 Spreadsheet。重点是把来源、权限、强制方式和证据分开。

instruction_contract:
  id: cedarcart-checkout-v3
  owner: product-release
  model: provider/model-version
  harness: builder-version
  repository_commit: abc123

surfaces:
  system:
    owner: app-builder
    version: 2026-08-18
    observable: partial
  project:
    files: [AGENTS.md, .agent/rules/checkout.md]
    hashes: [sha256:..., sha256:...]
  skills:
    - id: database-migration
      version: 2.4.1
  tools:
    - id: payment-staging
      schema_hash: sha256:...
      write_permission: staging_only

critical_rules:
  - id: checkout-regression
    surface: project
    enforcement: required_ci_check
    evidence: test:checkout@abc123
  - id: production-approval
    surface: runtime_policy
    enforcement: credential_gate
    evidence: approval_event_id
  - id: rollback-artifact
    surface: skill
    enforcement: package_validator
    evidence: migration_pair_check

conflict_tests:
  pack: checkout-surface-v2
  result: pass
  critical_failures: 0

release:
  decision: approve
  accountable_owner: founder
  rollback: deploy-2026-08-18-rc3

这份收据不会暴露厂商隐藏的系统 Prompt。它只记录团队实际能够知道的内容，并明确标出仍然不透明的部分。无法观察的系统版本是一项采购和变更管理风险，不能靠猜测补全。

判断什么时候这套方法足够，什么时候还远远不够

根据后果选择最轻量但足够的控制。

这套方法不能证明某个模型“普遍合规”。它无法证明厂商隐藏的系统 Prompt 从未变化，无法保证每段工具描述都诚实，也不能保证模型升级后行为不变。它更不能把自然语言政策变成完整安全边界。

小型产品团队的 48 小时计划

然后选出五条关键规则，其中至少两条应该与最容易发生的默认行为相反。写出每条规则应该留下的证据，并找出哪些可以不用模型来强制执行。不要从重写所有 Prompt 开始。

最后只能做出四种决定之一：

• Approve： 关键边界已强制执行，必要证据完整，冲突测试包通过；
• Advisory only： Agent 可以提出改动，但必须由人执行或批准；
• Narrow scope： 移除生产访问、高风险工具或不受支持路径；
• Block： 关键规则只依赖文字，冲突仍未解决，或无法识别当前生效的指令栈。

创始人的最终指令面检查

在允许 Agent Merge、部署、发送、收费、删除或修改客户状态之前，逐项确认：

• 能否列出影响这个工作流的每一个指令面？
• 每个来源是否绑定责任人、适用范围、版本或 Hash？
• 是否知道厂商声明的指令层级？
• 项目、Skill、工具与用户规则之间的冲突是否已经明确解决？
• 工具描述是否只被视为元数据，而不是权限授予？
• 不可妥协的边界是否在自然语言之外强制执行？
• 每个必做动作是否留下可独立检查的证据？
• 是否测试过与 Agent 默认行为相反的规则？
• 测试包是否同时覆盖遗漏和越权？
• 发布是否绑定受测 Commit、模型、Harness、规则、Skill 与工具？
• 来源缺失或不透明时，系统能否停止或拒绝继续？
• 是否有一个明确的人能阻断发布并负责恢复？

参考资料

1. Huang 等：Harness-IF——跨编码 Agent 指令面的指令遵循评测
2. OpenAI：改进前沿大模型的指令层级
3. OpenAI：Model Spec——Chain of Command 与工具信任
4. Anthropic：Claude Code 如何记住项目
5. GitHub：为 GitHub Copilot 添加仓库自定义指令
6. Model Context Protocol：工具规范
7. Panavas 等：HANDBOOK.md——长上下文 Agent 指令遵循 Benchmark
8. NIST：人工智能风险管理框架——生成式 AI Profile