阅读提示： 这页不是单纯转抄视频，而是把视频内容转成更适合学习与复用的站内版本。 “逐句学习版”尽量保持原视频推进顺序；“概念解析”和“个人模板”则是为了把这条内容真正变成你自己的工作流资产。
Harness Engineering 不是继续调 prompt，而是设计 AI 的工作环境
这条视频最有价值的，不是又发明了一个新名词，而是它把很多人已经零散在做的事重新命名了： 当同类错误总在重复出现时，重点不再是“再试一次”，而是把规则、工具、权限、记忆和验证系统化， 让 AI 即使换任务、换模型、换会话，也还能维持稳定质量。
这页最值得带走的判断： 模型决定能力上限，harness 更大程度决定稳定性、可控性与复用性。 如果你已经开始感到 prompt 越写越长、交接越来越乱、返工越来越多，那么你真正缺的往往不是更多提示词，而是一套工作环境设计。
先调环境，再调模型
当错误来自权限不清、上下文丢失、反馈没有沉淀时，换更强模型通常只能暂时掩盖问题。
先写规则，再写 prompt
优先沉淀在 AGENTS、CLAUDE、计划文档与 SOP 里的，才是下一次还能持续生效的内容。
先验流程，再验结果
结果好坏不是唯一问题，更重要的是：它是不是稳定、能不能重跑、别人能不能复用。
视频逐句学习版
以下内容按原视频推进顺序整理，保留逻辑链条，便于逐句复盘。
- 很多人以为 Agent 出错只是模型问题，但视频一开始就提醒：真正有价值的是背后的方法论。
- 当 Agent 犯错时，我们最常见的反应通常是重试一次，或者把 prompt 再改一版。
- 可如果同类错误总在回来，继续重试并不等于真正解决问题。
- 另一条路线是把问题工程化处理，让系统以后不再重复犯同样的错。
- 这条路线被概括为 Harness Engineering。
- 它关注的不是一句提示词，而是去设计 Agent 工作的环境。
- 这个环境包括工具系统、权限边界、记忆管理、上下文压缩和反馈循环。
- 这些组合起来，才叫 harness。
- 视频接着强调：harness 的影响并不是细微优化，而可能直接改变结果等级。
- 同一个模型，在工具配置方式变化后，基准测试排名可以大幅跃升。
- 甚至只改一个编辑工具的格式，成绩也可能出现数量级差异。
- 结论是：模型没变，但 harness 变了，效果就可能完全不是一个层级。
- 作者回看过去一年的项目时，发现自己其实一直在做类似事情，只是以前没有这个名称。
- 也就是说，很多看起来分散的流程治理动作，其实都可以被放进 Harness Engineering 的框架里理解。
- 为了让这个概念更容易懂，视频接着给出三个案例。
- 第一个案例来自一个多 Agent 系统。
- 系统里配置了多个 Agent，但最初最大的麻烦不是单个 Agent 写不好，而是它们彼此干扰。
- 上游 Agent 派出去的任务，下游 Agent 不一定能正确理解或稳定接住。
- 这说明问题出在协作环境，而不只是单个 prompt。
- 作者后来做了三类关键改动。
- 第一，用工作区隔离，避免多个 Agent 互相踩上下文与文件。
- 第二，用规则文件定义安全底线，先限制哪些事不能做。
- 第三，用 Agent 文件约束每次启动时必须先读什么。
- 这些改完之后，系统成功率不再依赖运气，而是从不稳定变成稳定可用。
- 第二个案例是内容引擎或工作流系统。
- 多条选题进来之后，并不是立刻让模型输出，而是先做筛选与评级。
- 然后再抓竞品全文，形成临时知识库。
- 在知识底座上，才让 AI 做更深一步的协作与产出。
- 初期结果不稳定时，单纯改 prompt 并没有明显帮助。
- 真正带来改善的是工作流节点的修改。
- 比如新增竞品数据源，让输入信息更完整。
- 比如调整评级阈值，让筛选更合理。
- 比如补上质量检查步骤，让错误在发布前就被拦住。
- 视频借这个案例说明：整条工作流本身，就是 harness。
- 模型在里面只是一个 API 调用，不是整套系统的全部。
- 第三个案例则更贴近日常使用 coding agent 的工作场景。
- 作者把统一知识库、多个工作区、规则文件和 SOP 文件组合在一起，形成稳定生产线。
- 中央知识库负责提供统一数据底座。
- 多个 Agent 工作区通过软链接或受控方式接入，既共享必要资料，又避免直接混写。
- CLAUDE 文件负责控制写作风格与默认工作方式。
- 规则文件负责控制安全底线，比如哪些目录不能直接动。
- SOP 文件负责定义每类内容的生产流程。
- 因此，即便换模型、换任务，整体输出质量仍能保持稳定。
- 视频最后把过去几年流行词串起来看：先是 Prompt Engineering，再到 Context Engineering。
- 前者在问“怎么把提示词写好”，后者在问“怎么把上下文喂好”。
- 而下一步更可能卷的，是 Harness Engineering，也就是“怎么把环境设计好”。
- 换句话说，AI 的最优解未必只在模型内部，很多决定质量的关键点其实在模型外部。
Harness Engineering 到底在设计什么
把一句概念拆成 5 个能落地、能检查、能持续优化的组件。
工具系统
Agent 能不能查资料、读文件、跑测试、调浏览器、做部署，不应该靠它猜，而应该被设计成可预期的工具组合。
权限边界
先决定哪些动作可以自动执行，哪些必须退回人工确认。真正稳定的系统不是更敢做，而是更清楚什么不能自动做。
记忆管理
把常见坑、验收标准、风格规则、命名约定写进 AGENTS、CLAUDE、计划文档和 SOP，而不是每次重新口述一遍。
上下文压缩
长会话里真正重要的不是保留所有聊天，而是把关键决策压缩进 plan、handoff、检查清单和结构化记录里。
反馈循环
测试、人工 review、上线验收、回滚点和失败复盘，决定错误会不会变成下一轮默认生效的规则。
| 当问题出现时 | 只调 Prompt 的常见反应 | 调 Harness 的系统反应 |
|---|---|---|
| 输出风格反复漂移 | 继续补几句风格要求 | 把风格写进 CLAUDE.md 或模板，让每次启动默认生效 |
| 总是误改不该碰的目录 | 提示“下次别再改” | 用规则文件与权限边界明确禁止，并加上线前验证 |
| 换会话后需要重新解释背景 | 把聊天历史贴得越来越长 | 把关键决策压成 plan.md、handoff 和 checklist |
| 同类错误重复出现 | 继续让模型重试 | 把失败原因沉淀进 SOP、测试与验收口径 |
视频里的三个案例，到底在证明什么
三个案例表面不同，本质上都在说明：问题常常出在系统层，而不在单句 prompt。
重点不是多，而是隔离与规则
工作区隔离、防干扰的文件组织、必读清单与安全底线，解决的是“Agent 之间互相踩踏”的问题。这是协作环境设计，不是提示词修辞。
重点不是写，而是先筛、先补数据、先质检
当输入质量、筛选阈值和质量检查节点被重新设计后，内容质量才稳定。也就是说，整条流程本身才是质量的主要决定因素。
重点不是模型换不换，而是系统是否可复用
统一知识库、规则文件、CLAUDE 风格约束与 SOP 生产流程放在一起时，质量不再主要依赖当前会话，而转为依赖系统本身。
把我自己的工作流拆成一张个人 Harness 结构图
最小可行版本不是企业级平台，而是你每天都能反复使用的 5 层结构。
目标与验收
先说清交付物是什么、什么时候算完成、哪些事绝不能做。没有验收标准，再强的 agent 也容易把局部正确误当整体完成。
工具与权限
再定义能搜索什么、能改哪些目录、能不能联网、能不能部署、什么场景必须回到人来确认。权限边界越清晰，系统越稳。
工作区、记忆与上下文压缩
把规则写进 AGENTS / CLAUDE，把长期理解写进计划与 handoff，把任务环境和中央资料区分开，避免长会话失控。
验证与反馈循环
测试、review、上线验收、回滚点与失败记录，负责把一次错误变成下一次默认防线，而不是下一次继续重犯。
SOP 与复用资产
最后把成功路径和失败教训都沉淀成 SOP、模板、检查清单和固定入口。真正的效率提升，来自默认流程而不是临场灵感。
个人 AGENTS.md / CLAUDE.md / 个人 SOP 模板
这三份文件不是装饰，而是把 Harness Engineering 落到日常工作的最小骨架。
AGENTS.md
负责定义项目目标、输出边界、禁区与验收动作。它解决的是“AI 到底应该怎样在这个项目里工作”。
# AGENTS.md ## 项目目标 - 本项目的核心交付物是什么 - 这次任务的完成标准是什么 ## 默认工作方式 - 先复述目标，再开始执行 - 复杂任务先写计划，再实施 - 不清楚时先定位根因，不要直接猜修复 ## 输出要求 - 默认用中文 - 变更说明要包含：改了什么、为什么、怎么验证 - 只提交本次相关文件，禁止 git add . ## 禁止事项 - 不要改动未授权目录 - 不要在未验证前声称“已完成” - 不要删除历史文件，除非已经确认可回滚 ## 必跑验证 - 指定测试命令 - 指定线上检查命令 - 指定回滚或备份要求
CLAUDE.md
负责定义默认思考方式、语言风格、项目级路径、部署规则与高频命令。它解决的是“启动后默认怎么思考、怎么说、怎么做”。
# CLAUDE.md ## 默认原则 - Use first-principles thinking. - 先理解底层目标，再决定执行路径。 - 如果路径不是最短，先指出更优路线。 ## 默认语言与风格 - 默认简体中文 - 回复要专业、清晰、可执行 - 命令与路径用反引号包裹 ## 项目记忆 - 站点目录：/var/www/your-site/ - 部署用户：ubuntu - 高风险目录：data / auth / central workspace - 线上改动前先备份旧文件 ## 常用验证 - pytest -q tests/xxx.py - curl -I https://your-site/path - curl -s https://your-site/path | rg "keyword" ## 输出前检查 - 是否只动了本次相关文件 - 是否给出验证证据 - 是否还原了公开页口吻，而不是内部协作口吻
个人 SOP
负责把任务从接收、澄清、计划、执行、验证、交接串起来。它解决的是“我每天到底按什么顺序用 AI”。
# 个人 SOP 1. 接任务 - 先写清目标、交付物、截止时间、验收标准 2. 判断任务类型 - 信息不足：先澄清 - 复杂实现：先 research / plan - 线上修复：先复现、再定位根因 3. 组装 Harness - 选择工具：搜索 / 文件 / 测试 / 浏览器 / 部署 - 写清权限边界：什么能自动做，什么必须确认 - 准备记忆：AGENTS / CLAUDE / 历史 handoff / checklist 4. 执行与压缩上下文 - 长任务把决策写进 plan.md - 阶段完成后更新 todo / handoff - 不要把全部状态只留在聊天里 5. 验证与复盘 - 跑测试、跑 curl、看真实页面 - 记录本次出错点和下次防线 - 把可复用的东西沉淀回模板
三者的关系可以这样记： AGENTS.md 负责定义项目里的工作边界， CLAUDE.md 负责定义默认工作方式， “个人 SOP” 负责定义你每天如何把任务推进到完成。 三者一起，才是一套真正可复用的个人 harness。
如果今天就开始实践，建议按这 5 步改你的工作流
不要一口气做完所有系统化工作，先做最能挡住重复错误的那一层。
先找一个反复出错的任务
比如部署、写页面、批量整理资料、生成内容、更新数据。不要从“我要做一个超级系统”开始，而要从“哪个环节最常返工”开始。
把边界和禁区写进文件，而不是继续口头提醒
凡是你已经提醒过两次以上的事，都值得沉淀进 AGENTS、CLAUDE 或 SOP。
给长任务准备 plan / handoff，而不是只留在聊天里
只要任务超过一个会话，或者可能中断、交接、重开，就应当开始做上下文压缩。
把验证前置
测试命令、页面检查命令、回滚点，都应该在开始实施前就确定，而不是做完后再想“怎么证明它真的好用了”。
每次复盘只沉淀一条能长期生效的规则
不要试图一次写完所有流程文档。真正有用的 harness，是从一个个重复错误里长出来的。
同主题延伸阅读
如果你想继续把这套方法做深，下面几页最值得连读。