AI Coding 的稳定性，不能只靠 Prompt：一次 Harness 工程化拆解

zzz_23682026-08-05 13:32

AI Coding 的稳定性，不能只靠 Prompt：一次 Harness 工程化拆解

AI Coding 进入长流程之后，很多问题看起来像"模型不够聪明"，实际更像"流程没有被工程化"。

一个模型可以会写代码、会解释需求、会调用工具，但这不等于它能稳定完成一条真实研发链路。真实任务里还有状态保存、阶段切换、权限控制、单测验证、部署确认、失败回退和人工审批。只靠一段越来越长的 CLAUDE.md 或系统提示词，很难长期覆盖这些约束。

这篇文章讨论的就是 Harness Engineering：把 AI 的工作方式，从"靠提示词提醒"变成"由外部结构约束"。

原文：微信公众号《AI 不缺智商缺纪律：一场 Harness 工程化实践》

文章目录

  • [AI Coding 的稳定性，不能只靠 Prompt：一次 Harness 工程化拆解](#AI Coding 的稳定性，不能只靠 Prompt：一次 Harness 工程化拆解)
    • [1. 先定义：Harness 到底是什么](#1. 先定义：Harness 到底是什么)
    • [2. 问题背景：为什么堆 Prompt 会到达上限](#2. 问题背景：为什么堆 Prompt 会到达上限)
    • [3. 问题分析：AI Coding 常见的三类流程失败](#3. 问题分析：AI Coding 常见的三类流程失败)
      • [3.1 上下文遗忘](#3.1 上下文遗忘)
      • [3.2 状态漂移](#3.2 状态漂移)
      • [3.3 验证绕过](#3.3 验证绕过)
    • [4. 一个最小可用 Harness 应该长什么样](#4. 一个最小可用 Harness 应该长什么样)
      • [4.1 极简常驻入口](#4.1 极简常驻入口)
      • [4.2 状态文件](#4.2 状态文件)
      • [4.3 职责隔离](#4.3 职责隔离)
      • [4.4 门禁脚本](#4.4 门禁脚本)
      • [4.5 可运行门禁 Demo](#4.5 可运行门禁 Demo)
      • [4.6 评测样例](#4.6 评测样例)
    • [5. 原文实践中最值得迁移的设计](#5. 原文实践中最值得迁移的设计)
      • [5.1 主会话变薄](#5.1 主会话变薄)
      • [5.2 文件交接替代口头交接](#5.2 文件交接替代口头交接)
      • [5.3 门禁外置，而不是提醒模型自觉](#5.3 门禁外置，而不是提醒模型自觉)
    • [6. 编排方式怎么选](#6. 编排方式怎么选)
    • [7. 验证闭环：评测 Harness 不要让裁判下场干活](#7. 验证闭环：评测 Harness 不要让裁判下场干活)
    • [8. 从零开始落地，可以按这个顺序](#8. 从零开始落地，可以按这个顺序)
    • [9. 边界：哪些场景不值得 Harness 化](#9. 边界：哪些场景不值得 Harness 化)
    • [10. 结论：AI Coding 的工程重点在外部结构](#10. 结论：AI Coding 的工程重点在外部结构)
    • 参考资料

1. 先定义：Harness 到底是什么

在 AI Coding 场景里，可以把 harness 理解成一套外部工程框架：

Harness = 规则入口 + 状态持久化 + 职责隔离 + 工具权限 + 门禁验证 + 评测回路。

它和 prompt 的区别在于：

对比项 Prompt Harness
作用方式 告诉模型应该怎么做 把流程变成可执行约束
可靠性来源 模型理解与遵守 状态、脚本、hook、评测
失败方式 忘记、跳步、自我矛盾 被门禁拦截、回退、等待人确认
适合场景 短任务、低风险任务 长流程、多阶段、有验证和权限边界的任务

一个最小 Harness 可以先画成下面这条链路：
#mermaid-svg-C5OFqc1zI85hMujv{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-C5OFqc1zI85hMujv .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-C5OFqc1zI85hMujv .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-C5OFqc1zI85hMujv .error-icon{fill:#552222;}#mermaid-svg-C5OFqc1zI85hMujv .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-C5OFqc1zI85hMujv .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-C5OFqc1zI85hMujv .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-C5OFqc1zI85hMujv .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-C5OFqc1zI85hMujv .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-C5OFqc1zI85hMujv .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-C5OFqc1zI85hMujv .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-C5OFqc1zI85hMujv .marker{fill:#333333;stroke:#333333;}#mermaid-svg-C5OFqc1zI85hMujv .marker.cross{stroke:#333333;}#mermaid-svg-C5OFqc1zI85hMujv svg{font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-C5OFqc1zI85hMujv p{margin:0;}#mermaid-svg-C5OFqc1zI85hMujv .label{font-family:"trebuchet ms",verdana,arial,sans-serif;color:#333;}#mermaid-svg-C5OFqc1zI85hMujv .cluster-label text{fill:#333;}#mermaid-svg-C5OFqc1zI85hMujv .cluster-label span{color:#333;}#mermaid-svg-C5OFqc1zI85hMujv .cluster-label span p{background-color:transparent;}#mermaid-svg-C5OFqc1zI85hMujv .label text,#mermaid-svg-C5OFqc1zI85hMujv span{fill:#333;color:#333;}#mermaid-svg-C5OFqc1zI85hMujv .node rect,#mermaid-svg-C5OFqc1zI85hMujv .node circle,#mermaid-svg-C5OFqc1zI85hMujv .node ellipse,#mermaid-svg-C5OFqc1zI85hMujv .node polygon,#mermaid-svg-C5OFqc1zI85hMujv .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-C5OFqc1zI85hMujv .rough-node .label text,#mermaid-svg-C5OFqc1zI85hMujv .node .label text,#mermaid-svg-C5OFqc1zI85hMujv .image-shape .label,#mermaid-svg-C5OFqc1zI85hMujv .icon-shape .label{text-anchor:middle;}#mermaid-svg-C5OFqc1zI85hMujv .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-C5OFqc1zI85hMujv .rough-node .label,#mermaid-svg-C5OFqc1zI85hMujv .node .label,#mermaid-svg-C5OFqc1zI85hMujv .image-shape .label,#mermaid-svg-C5OFqc1zI85hMujv .icon-shape .label{text-align:center;}#mermaid-svg-C5OFqc1zI85hMujv .node.clickable{cursor:pointer;}#mermaid-svg-C5OFqc1zI85hMujv .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-C5OFqc1zI85hMujv .arrowheadPath{fill:#333333;}#mermaid-svg-C5OFqc1zI85hMujv .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-C5OFqc1zI85hMujv .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-C5OFqc1zI85hMujv .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-C5OFqc1zI85hMujv .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-C5OFqc1zI85hMujv .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-C5OFqc1zI85hMujv .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-C5OFqc1zI85hMujv .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-C5OFqc1zI85hMujv .cluster text{fill:#333;}#mermaid-svg-C5OFqc1zI85hMujv .cluster span{color:#333;}#mermaid-svg-C5OFqc1zI85hMujv div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:"trebuchet ms",verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-C5OFqc1zI85hMujv .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-C5OFqc1zI85hMujv rect.text{fill:none;stroke-width:0;}#mermaid-svg-C5OFqc1zI85hMujv .icon-shape,#mermaid-svg-C5OFqc1zI85hMujv .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-C5OFqc1zI85hMujv .icon-shape p,#mermaid-svg-C5OFqc1zI85hMujv .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-C5OFqc1zI85hMujv .icon-shape .label rect,#mermaid-svg-C5OFqc1zI85hMujv .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-C5OFqc1zI85hMujv .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-C5OFqc1zI85hMujv .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-C5OFqc1zI85hMujv :root{--mermaid-font-family:"trebuchet ms",verdana,arial,sans-serif;} PASS
FAIL
用户目标
规则入口
状态文件 state.json
职责隔离 agent / 阶段产物
确定性门禁脚本
进入下一阶段
阻断并回退
评测样例回归

如果发布平台不渲染 Mermaid，也可以把这张图转成图片后插入。它表达的重点是：模型可以参与节点里的判断，但阶段推进必须经过外部可检查的门禁。

原文有一句表达很有代表性：模型供给智商，harness 供给纪律。为了避免把这句话写成绝对事实，本文更中性地说：当任务变长、工具变多、风险变高时，稳定性往往需要由模型外部的工程结构来补足。

2. 问题背景：为什么堆 Prompt 会到达上限

很多团队最开始都会走同一条路：把所有流程规范写进一个常驻说明文件。

比如：

  • 开发前先确认需求。
  • 改代码前先写测试。
  • 提交前必须跑单测。
  • 部署前必须合并主分支。
  • 高风险命令必须询问用户。

短期看，这种方式有效。问题是规则越写越多，常驻上下文越来越重，模型真正用来理解代码和任务的空间反而被挤压。

这不是纯主观感受。Lost in the Middle 论文指出，长上下文模型并不总能稳定使用上下文中部的信息，相关信息在开头或结尾时表现更好，在中部时性能可能显著下降。RULER 也提醒，单纯测试"长文本里找针"不足以代表真实长上下文能力，还需要多跳、聚合等更复杂任务。

所以，长上下文不是免费的流程保险箱。把所有规则都塞进 prompt，只是把问题从"没有规则"变成"规则存在但可能被忽略"。

3. 问题分析：AI Coding 常见的三类流程失败

结合原文实践和公开资料，可以把 AI Coding 的流程失败归为三类。

3.1 上下文遗忘

模型不是没有看过规则，而是在长任务中，规则被大量代码、日志、工具输出和中间推理稀释。到后半段时，它可能忘记"下一步应该验证"或"这个操作需要人工确认"。

VILA-Lab 的 Dive-into-Claude-Code 仓库把 Claude Code 拆成模型循环、权限、上下文管理、工具路由、恢复等基础设施来看。它的一个核心观察是：Agent loop 本身并不复杂，真正复杂的是围绕它的系统工程。

3.2 状态漂移

长任务经常跨多个阶段：需求分析、方案设计、编码、编译、单测、接口测试、部署、验收。只靠对话历史保存状态，很容易出现"模型以为做过了，但实际产物不存在"的情况。

这类问题的解法不是让模型更努力回忆，而是让状态落盘。例如用 state.json 记录当前阶段、责任 agent、已完成产物、待执行门禁和失败原因。

3.3 验证绕过

AI 最容易让人误判的地方，是它会给出看似完整的验收叙述：

  • "我已经完成修改。"
  • "测试应该可以通过。"
  • "这个方案是安全的。"

但工程上不能接受"应该"。验证必须落到确定性动作：编译是否真的跑过、单测是否真的通过、接口是否真的返回预期结果、危险命令是否真的被拦截。

Claude Code hooks 官方文档确认，PreToolUse 可以在工具调用执行前控制 allow、deny、ask 或 defer。这类机制的价值就在于：流程约束不再只依赖模型记忆，而可以在工具执行边界被拦住。

4. 一个最小可用 Harness 应该长什么样

原文中的 harness 很完整，包含多层配置、22 个 skills、12 个 commands、19 节点链、G1-G8 门禁和评测平台。但大多数团队不需要从这个规模开始。

更现实的起点是六个部件。

4.1 极简常驻入口

常驻入口只放最少内容：角色、基本代码偏好、流程触发条件、关键门禁索引。

不要把完整 TDD 指南、部署细则、评审模板全部常驻。它们应该按阶段加载，避免挤占主上下文。

4.2 状态文件

用一个结构化文件记录流程状态，例如：

json 复制代码 
{
  "task_id": "feature-2026-08-04-001",
  "intent": "FEATURE",
  "risk": "HIGH",
  "phase": "VERIFYING",
  "required_outputs": [
    "phases/requirements.md",
    "phases/design.md",
    "phases/verification.json"
  ],
  "gates": {
    "compile": "pass",
    "unit_test": "pending",
    "predeploy": "blocked"
  }
}

这个文件的意义不是好看，而是让"流程走到哪"不再依赖模型记忆。

4.3 职责隔离

Claude Code 官方 subagents 文档说明，每个 subagent 启动时都有新的隔离上下文，不会看到主对话历史。这个机制适合把角色拆开：

  • developer：只负责实现。
  • verifier：只负责检查。
  • deployer：只负责部署预发。
  • reviewer：只负责找风险。
  • dispatcher：只负责读状态并决定下一步。

重点不是 agent 数量，而是输入输出边界。一个 agent 写 phases/design.md，另一个 agent 只读这个产物继续工作。这样比"大家在同一段对话里互相解释"更可审计。

4.4 门禁脚本

门禁应该尽量确定性。例如：

  • G1：需求产物是否存在。
  • G2：设计文档是否包含验收标准。
  • G3：编译是否通过。
  • G4：单测是否通过。
  • G5：关键接口测试是否通过。
  • G6：证据文件是否完整。
  • G7：部署确认是否存在。
  • G8：生产发布是否由人确认。

这些门禁不应该只是"建议"。如果失败，就阻断流程，把状态退回到对应阶段。

4.5 可运行门禁 Demo

为了避免只停留在方法论，这里给一个最小可运行 demo。它不模拟完整研发流程，只验证一件事：流程能否独立于模型叙述，被外部脚本检查并阻断。

本地文件：

text 复制代码 
data/processed/harness-demo/
├─ state.json
├─ gate_check.py
└─ phases/
   ├─ requirements.md
   ├─ design.md
   └─ verification.json

核心状态文件 state.json 记录任务阶段、必需产物和门禁状态：

json 复制代码 
{
  "task_id": "feature-2026-08-04-001",
  "intent": "FEATURE",
  "risk": "HIGH",
  "phase": "VERIFYING",
  "required_outputs": [
    "phases/requirements.md",
    "phases/design.md",
    "phases/verification.json"
  ],
  "gates": {
    "requirements_review": "pass",
    "design_review": "pass",
    "compile": "pass",
    "unit_test": "pass",
    "evidence": "pass"
  }
}

门禁脚本只做确定性检查：字段是否存在、阶段产物是否存在、所有 gate 是否为 pass。这里保留核心代码：

python 复制代码 
import json
import sys
from pathlib import Path

REQUIRED_FIELDS = ["task_id", "intent", "risk", "phase", "required_outputs", "gates"]


def fail(message: str) -> None:
    print(f"FAIL {message}")
    raise SystemExit(1)


def main() -> None:
    state_path = Path(sys.argv[1]) if len(sys.argv) > 1 else Path("state.json")
    if not state_path.exists():
        fail(f"state file not found: {state_path}")

    state = json.loads(state_path.read_text(encoding="utf-8-sig"))
    missing_fields = [field for field in REQUIRED_FIELDS if field not in state]
    if missing_fields:
        fail(f"missing state fields: {', '.join(missing_fields)}")

    root = state_path.parent
    missing_outputs = [name for name in state["required_outputs"] if not (root / name).exists()]
    if missing_outputs:
        fail(f"missing phase outputs: {', '.join(missing_outputs)}")

    failed_gates = [name for name, status in state["gates"].items() if status != "pass"]
    if failed_gates:
        fail(f"non-pass gates: {', '.join(failed_gates)}")

    print(f"PASS task={state['task_id']} phase={state['phase']}")
    print(f"checked_outputs={len(state['required_outputs'])}")
    print(f"checked_gates={len(state['gates'])}")


if __name__ == "__main__":
    main()

运行通过样例：

powershell 复制代码 
python data\processed\harness-demo\gate_check.py data\processed\harness-demo\state.json

真实输出：

text 复制代码 
PASS task=feature-2026-08-04-001 phase=VERIFYING
checked_outputs=3
checked_gates=5

再把 unit_test 临时改成 pending，脚本会阻断流程：

text 复制代码 
FAIL non-pass gates: unit_test
EXIT_CODE=1

这个 demo 很小，但它说明了 harness 的关键点：模型可以写"测试应该通过"，但阶段推进不能相信这句话；只有状态、产物和门禁都通过，流程才进入下一步。

4.6 评测样例

Harness 本身也要被测试。否则每次改规则，都只能靠体感判断有没有变好。

可以先做 3 类样例：

样例类型 检查目标
低风险修复 是否能走最短流程，不引入过度评审
高风险功能 是否触发设计、单测、部署和验收门禁
故意失败任务 是否能发现编译失败、测试失败或缺失证据

SWE-bench 和 AgentBench 的共同启发是：评估 Agent 不能只看最终回答，要看它是否能在真实或半真实环境里完成任务。对团队内部 harness 来说，也应该尽量用可重复的测试任务和确定性评分，而不是只看一次演示是否顺利。

5. 原文实践中最值得迁移的设计

原文实践很复杂，但最值得迁移的不是"19 个节点"这个数字，而是三个设计原则。

5.1 主会话变薄

原文把主会话设计成一个"薄控制器"：主会话不直接读所有产物、不直接判断业务细节，只执行 dispatcher 给出的下一步指令。

这个设计的价值在于减少污染。主会话不再同时承担需求分析、技术设计、编码、验证和部署，而是把职责交给不同 agent 和文件产物。

这和微服务里的 thin controller 有点像：控制器不承载业务复杂度，只负责接收输入、调用服务、返回结果。

5.2 文件交接替代口头交接

多 agent 系统最怕"聊天式交接"。一个 agent 说"我已经完成了设计"，另一个 agent 信了，但文件里没有验收标准，后续就会一路错下去。

文件交接更慢，但更稳：

  • 每一步有明确产物。
  • 每个产物可以被 diff。
  • 每个阶段能被恢复。
  • 每次失败能定位到文件和门禁。

Apache Burr 的设计也体现了类似方向：用 action、transition 和 state 构建可观测、可测试的 AI 应用。无论具体框架怎么选，状态和转移显式化，都是长流程 Agent 的共同趋势。

5.3 门禁外置，而不是提醒模型自觉

"请你务必运行测试"是一条 prompt。

"没有测试结果文件就不能进入下一阶段"才是门禁。

这两者的可靠性差别很大。前者依赖模型遵守，后者依赖外部检查。Claude Code hooks、状态机、CI 脚本、schema 校验，本质上都在做同一件事：把关键约束从模型推理里拿出来。

6. 编排方式怎么选

原文对 Claude Code Workflow、Agent Team、dispatcher + 文件交接做了对比。这里整理成更通用的判断。

编排方式 适合场景 不适合场景
Prompt-only 短任务、一次性脚本、低风险修改 跨天任务、多阶段验证、权限复杂任务
Workflow 脚本 单阶段、可并行、无人工确认、时长可控 需要人工门禁、跨 session 恢复、长构建任务
Agent Team 多人并行探索、多模块独立处理 严格顺序工序链、强状态一致性要求
Dispatcher + 文件交接 有状态工序链、需要审计、需要恢复和人工确认 极短任务、强并行计算、无持久化需求

这里没有绝对最优。更合理的做法是混合使用：dispatcher 管控制流，Workflow 加速纯计算或并行评审，Team 处理独立探索任务。

7. 验证闭环：评测 Harness 不要让裁判下场干活

原文里一个很好的观点是：评测平台是评估者，不是执行者。

这句话很关键。假如被测 AI 没有部署，评测平台替它部署了；被测 AI 没有跑测试，评测平台替它跑了。那最后得到的分数就不再反映 harness 能力，而是反映评测平台帮了多少忙。

一个更稳的评测平台应该只检查：

  • 产物是否存在。
  • 状态是否符合 schema。
  • 编译日志是否真实产生。
  • 单测结果是否真实存在。
  • 门禁失败时是否阻断。
  • 高风险操作是否出现人工确认。

Scaling Laws for Agent Harnesses via Effective Feedback Compute 这篇论文也把 harness 放在工具使用、反馈、验证、记忆和修复这些外部机制里讨论。它的摘要指出，原始 token、工具调用、耗时或成本，并不能区分有用反馈和冗余交互，因此提出 EFC 这类 trace-level 指标来衡量反馈质量。

这对工程实践的启发是：不要只统计 AI 跑了多少轮、花了多少 token，要看每次反馈是否有效、是否被保留、是否推动了修复。

8. 从零开始落地，可以按这个顺序

如果你准备给团队的 AI Coding 流程加 harness，不建议第一天就搭完整状态机。可以按四步走。

第一步：把"必须验证"的动作写成脚本

先从最硬的动作开始：编译、单测、lint、接口 smoke test、敏感命令拦截。

这些动作不需要 LLM 判断，直接用脚本和 CI 检查。

第二步：把流程状态落盘

引入 state.json 或类似结构，记录当前阶段、下一步、必需产物、门禁状态。

这一步能解决大量"模型以为做过了"的问题。

第三步：拆出 verifier

先不要急着拆 10 个 agent。最值得优先拆的是 verifier。

让写代码的 agent 不负责最终验收，让 verifier 在干净上下文里只看产物和验收标准。这样能减少"自己审自己"的问题。

第四步：给 harness 做回归样例

每次改规则，都跑一组小样例：低风险修复、高风险功能、故意失败任务。只要这三类能稳定跑，harness 才有继续扩展的基础。

9. 边界：哪些场景不值得 Harness 化

Harness 不是越重越好。

这些场景通常不适合上复杂 harness：

  • 一次性资料整理。
  • 简单脚本或低风险文本修改。
  • 没有外部验证标准的创意任务。
  • 失败成本很低、人工检查更快的任务。
  • 团队还没有稳定开发流程，连人类 SOP 都没定清楚的任务。

Harness 的前提是过程可观测。如果中间产物无法落盘、验收标准无法定义、失败也无法复现，那么加再多 agent 和状态机，也只是增加协调成本。

10. 结论：AI Coding 的工程重点在外部结构

AI Coding 的稳定性不能只靠模型自觉，也不能只靠更长的 prompt。长流程任务需要外部结构：状态要落盘，职责要隔离，权限要拦截，门禁要阻断，评测要可重复。上面的最小 demo 已经验证了一个基本闭环：当阶段产物存在且 gate 全部为 pass 时流程放行；当 unit_test 仍是 pending 时脚本返回 EXIT_CODE=1 并阻断。

可以用一句话概括：

Prompt 让模型知道应该怎么做，Harness 让系统保证关键步骤不能被跳过。

这不是否定 prompt 的价值。Prompt 仍然负责表达目标、传递上下文、约束输出格式。但当任务进入多阶段、多工具、多风险边界之后，prompt 应该退到合适的位置，把流程纪律交给更确定的工程机制。

参考资料

感谢阅读，记得点赞、关注、收藏，欢迎各位评论区交流！！！

相关推荐
ATMQuant1 小时前
以AI量化为生：25.vnpy 4.4升级实战 - 魔改版框架如何安全跟进上游
人工智能·python·量化交易·vnpy
Raas1001 小时前
MAIGateway，魔芋企业级AI网关的FinAPI成本归因设计
大数据·人工智能·网关·api网关·finapi
啾啾Fun1 小时前
【AI原生组织】2-从L0到L6：Agent自治等级与组织成熟度地图
人工智能·ai-native
LaughingZhu1 小时前
Product Hunt 每日热榜 | 2026-08-04
人工智能·经验分享·深度学习·神经网络·产品运营
阿里云云原生1 小时前
金融级 AI 原生架构：FinXScope 如何解决智能体从 Demo 到生产的“最后一公里”？
人工智能·金融·架构·agentscope·finxscope
蓝速科技1 小时前
蓝速科技 AI 双屏翻译机商务选购与实测避坑指南
人工智能·科技
小彤花园1 小时前
和 AI 结对写网站：从 JSON 到一整个工具集
前端·人工智能·程序员
BerryS3N2 小时前
Java在人工智能与大模型时代的深度演进：从工程落地、高性能计算到企业级Agent与RAG架构实战指南
java·人工智能·架构
小白说大模型2 小时前
AI Agent 调试实战：从 Prompt 追踪到执行回放的系统化排障方法
人工智能·prompt
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02GitHub 镜像站点03国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）04Agnes AI 免费 API 接入指南：文本、生图、生视频，一套接口全免费05微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新06AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路072026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？082026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片0900 Debian字符界面如何支持中文10历年考研数学一、数学二、数学三真题试卷及答案PDF