周一上午，你让 agent 改一个看似简单的 bug。它读了 issue、翻了相关文件、写了 patch，commit 之前你顺手扫一眼。改对了。下午同一个 agent 改第二个 bug，这次它顺手把一个不该动的迁移脚本也碰了，CI 把它拦下来，lint 把错误信息连同修复指令一起塞回它的下一轮上下文，它自己绕回来重做。两件事看上去都是「agent 干活」，背后撑着的却是两个不同的工程学科：你拼给它的那段 issue 加文件加 README，是 context 这一层在工作；CI 拦截、lint 报错带修复指令、不让它把迁移脚本误伤，是 harness 这一层在工作。
边界一句话说清。context engineering 管模型在单次推理里看到什么；harness engineering 管整个 agent 系统怎么运转、怎么防错、怎么自我纠正。两者不是替代关系，是同一台机器上的两层。M. Trajan 把这个划分写得更干净：context engineering 问「agent 应该看到什么」，harness engineering 问「系统该阻止、度量、纠正什么」。只管前者，等于只告诉了 agent 它知道什么，对它「能做什么」「做错时会怎样」一句都没说。
当下被引用最多的统一公式来自 LangChain：Agent = Model + Harness。凡是不属于模型本身的代码、配置、工具、编排、反馈循环，都算 harness。Martin Fowler 在他那篇被广泛传阅的备忘里直接沿用这个公式，把 harness 概括为「AI agent 里除了模型之外的一切」。这是本文剩下所有讨论的中心论点。回到 harness engineering 总览，看 Agent = Model + Harness 的基础公式的来龙去脉会有更完整的语境，本篇专攻它和 context 这一对边界。
为什么是 2026 年这个词突然热起来？Vishal Mysore 给了一张瓶颈迁移表。2022 年 agent 不靠谱的根因是 prompt 写得不够好，2023，2024 年是上下文检索跟不上，2025 年之后是 agent 可靠性本身。问题从语言推到知识，再推到系统工程。模型每半年升一档，但 agent 在长任务里慢慢漂、在生产里时不时翻车的那部分，已经不是再多塞一段上下文能救得了的。这就是为什么 harness 这个词在 2026 年 6 月这个时间点开始密集出现在 OpenAI、Anthropic、LangChain、Martin Fowler 几个不同源头的文章里。不是营销标签轮换，是工程问题的重心真的换了一层。读者如果想直接看落到 Claude Code 上具体怎么补 harness 这层，可以辨析完概念后，看怎么在 Claude Code 上把 harness 这部分补齐。
四个词放进同一张坐标轴
工程师真正困惑的不是某一个词的定义，而是 prompt、context、harness、agentic 这四个词同时在飞，看不出彼此的边界。Vishal Mysore 把它们的关系压成最短的一句：prompt 告诉模型做什么、context 给它需要知道的、harness 保证它能可靠地把活干完。这是指令、知识、执行系统三种东西的分工。换成控制对象的说法就是：prompt 控制词语，context 控制知识，harness 控制执行。
| 维度 | Prompt Engineering | Context Engineering | Harness Engineering | Agentic Engineering |
|---|---|---|---|---|
| 控制对象 | 词语（一次对话里说什么） | 知识（一次推理能看到什么） | 执行（整个 agent 系统怎么运转） | 同 harness（社区里的另一个称呼） |
| 产出物 | 指令 | 给模型的输入素材 | 执行系统（约束 + 反馈 + 编排） | 同 harness |
| 介入时机 | 单次对话之前 | 单次推理之前 | agent 全生命周期 | 同 harness |
| 典型工件 | 提示词模板、角色设定、few-shot 示例 | 系统提示、检索内容、记忆、文件摘要 | 工具、skills、MCP、沙箱/文件系统/浏览器、编排逻辑、hooks/middleware | 同左 |
| 做不好的典型症状 | 模型误解指令、格式错乱 | 模型不知道关键事实、检索陈旧 | agent 跑着跑着漂掉、改坏文件没人拦、几天后行为退化 | 同 harness |
四个词的关系是同心圆。最里面是 prompt，控制一次对话。外面一圈是 context，控制一次推理能看到的全部输入。再外面一圈是 harness，控制整个 agent 系统从启动到结束的所有行为。LangChain 给 harness 列过一份完整组成清单：system prompt、tools、skills、MCP、文件系统/沙箱/浏览器、编排逻辑、hooks/middleware。凡是不属于模型本身的代码、配置、执行逻辑都算 harness。Anand Topu 引 Ryan Lopopolo 的说法更接地气：harness 就是人类围着 agent 搭出来的所有东西，包括工具、skills、文档、linting、扮演 reviewer 的子代理、TDD 护栏、仓库结构本身。换句话说，回到 harness engineering 总览，看 Agent = Model + Harness 的基础公式，会发现公式右半边的「Harness」在工程上不是一个组件，是一整层。
agentic engineering 和 harness engineering 在 2026 年 6 月的当下基本指同一件事。两者重叠到不需要刻意区分。社区里有人偏好用 agentic（强调「以 agent 为中心的系统设计」），有人偏好用 harness（强调「约束和反馈机制」），背后说的都是同一层东西。
四个词里还有一个容易混淆的小坑：framework、runtime、harness 这三个工程术语并不在同一层。LangChain 自己做了一次澄清。LangChain 是 agent framework（提供抽象和心智模型），LangGraph 是 agent runtime（提供持久执行、流式、状态持久化），DeepAgents 才是 agent harness（在 framework 之上再叠默认提示、约定式的工具处理、规划工具、文件系统访问）。读到 harness 这个词时不要把它和 framework 或 runtime 划等号。它是建在两者之上更高一层、面向「让 agent 可靠地完成任务」的工程层。辨析完概念后，看怎么在 Claude Code 上把 harness 这部分补齐，会发现实际落地时填的就是这一层：工具清单、skills、文件系统约定、hooks。
一条用得上的诊断规则：一次错看 context，慢漂移看 harness
同心圆的结构能说明分工，却不能直接帮你判断手头这个故障该归哪一层修。把一个具体故障扔过来，先问它的形状。M. Trajan 给了一条很短的诊断规则：一次输出错了，大概率是 context 问题；几周内慢慢退化、越用越不对劲，那就是 harness 问题。背后的直觉很直白。context 决定模型这一回看见什么、能想清楚什么；harness 决定整个系统在时间维度上会不会漂走。Trajan 还有一句更精炼的概括：context 帮模型思考，harness 防止系统漂移。这一条规则可以直接拿到日常排查里用。
更细一点的判断清单来自 Vishal Mysore，他把诊断流程切成三层：
- prompt 层故障：模型误解指令、输出格式错、忽略明确约束。改 prompt 或 system message。
- context 层故障：缺关键文件、检索拉回陈旧内容、不知道项目里某个约定。改检索管线、记忆系统或工具锚定。
- harness 层故障：agent 卡死在不可恢复状态、工具调用顺序错、输出本身正确但副作用闯祸、根本没有任何可观测信号、没有任何护栏拦得住危险动作。改编排、护栏、状态管理、可观测性。
Mysore 还给了一个让人警醒的判断：2025 年生产环境里绝大多数故障是 harness 失败被误诊成 prompt 或 context 失败，结果修在错的层、症状反复发作、团队对 agent 失去信心。这就是为什么先做归层、再动手改，比立刻冲上去改 prompt 更值得。如果对「harness 到底覆盖哪些东西」还没有完整心智模型，可以回到 harness engineering 总览那篇，看 Agent = Model + Harness 这个基础公式怎么把模型之外的所有东西收进来。
OS 类比把三层钉死
HPE 社区给了一个工程师一眼能看懂的类比：context 是 RAM，memory 是磁盘，harness 是操作系统。三层各自要回答的核心问题不一样：
| 层 | 核心问题 | 作用范围 | 典型故障 |
|---|---|---|---|
| Context | 现在这一步该看到什么 | 单次推理 | 投毒、分心、混淆、上下文相互打架 |
| Memory | 什么该跨 session 持久化 | 跨 session、跨时间 | 检索不相关、记忆陈旧、隐私泄漏 |
| Harness | agent 该怎么运转 | 整个系统生命周期 | 一击即中假象、过早收工、错误级联、自评失灵 |
类比的好处是边界清楚。一次性塞进窗口的东西归 context。跨 session 沉淀下来的东西归 memory。负责「什么时候塞、塞完之后下一步怎么走、做错了怎么回滚」的运行逻辑，全归 harness。Trajan 强调过，光做 context engineering 只回答了「agent 知道什么」，对「agent 能做什么、做错时会怎样」完全没说。那块没说的，就是 harness 的地盘。
关于「谁是谁的子集」，工程上别纠结
社区里两派对子集关系判断完全相反。HumanLayer 明确写过：他们把 harness engineering 视为 context engineering 的子集，把 context engineering 当成 prompt engineering 和一系列可靠性技术的超集。另一派（在 LangChain / Fowler 主流共识里）把方向反过来：harness 包住 context、包住 prompt。
这种分歧吵起来会很久，但工程实践里不重要。重要的是诊断时能把故障归到对的层去修。OS 类比里那张表用得上，HumanLayer 自己定的边界对内部一致也用得上，没必要纠结全社区统一术语。
AGENTS.md、跨 session 状态归 harness 而不是 context
读到这里有一个最容易踩的边界。AGENTS.md、知识库、进度文件，到底算 context 还是 harness？
Anthropic 在长任务那篇里点出了背景：长任务的核心难题是 agent 在离散 session 里工作，每个 session 从零开始记忆，像换班工程师每班都失忆。要让它别失忆，就得有跨 session 状态。这一类状态，AGENTS.md、init 脚本、进度文件、ADR，按 OS 类比落在 memory 层，再上一层是 harness 在管「什么时候读、读到哪、写回哪」。它们不是某次推理临时塞进窗口的 context。
Reddit 上一位 r/ClaudeCode 作者补了一个很实用的观察：体量大的代码库里，把整份架构标准、合规文档塞进窗口反而出问题。agent 容易被塞爆，或者命中「Lost in the Middle」的 U 型注意力盲区，中段直接忽略。让 agent 去查比把内容塞进来更强。这就是为什么 AGENTS.md 当目录而不是百科全书更可靠，背后是 harness 在决定怎么导航这些静态知识，不是 context 在决定一次塞多少。
OpenAI 那份大约 100 行的 AGENTS.md，骨架可以简化成下面这种形态。本身只列指向，不堆细节，让 agent 拿到一张地图，需要某条规则再点进对应文档。
# AGENTS.md
## 项目坐标
- 你在改的是：<一句话项目描述>
- 主要语言/框架：<列表>
- 入口与产物：<构建/启动命令>
## 找东西去哪里
- 架构规则与模块边界 → docs/architecture/README.md
- 命名、提交、PR 规范 → docs/conventions.md
- 已确认的设计决策（ADR）→ docs/decisions/
- 当前未完成的工作进度 → docs/progress/claude-progress.md
- 测试约定与基线 fixture → docs/testing.md
## 改动之前必看
- 数据库迁移：docs/migrations/RULES.md
- 公开 API 契约：docs/contracts/
- 第三方密钥与环境变量：docs/secrets-policy.md
## 不该碰的东西
- 列出「禁止 agent 直接修改」的目录或文件，附理由
每个目录里可以再放一份本地 AGENTS.md，作用是局部目录的二级目录，并非全局 AGENTS.md 的复制。以此控制每次进入新目录时塞进窗口的内容量。具体到 Claude Code 上怎么把这层补齐，可以接着看专门讲 Claude Code 上 harness 怎么搭的那一篇。
「harness engineering 不就是好工程换个名字」，三组同模型实验把这个判断按住
用诊断规则把故障归层之后，有人会立刻问：你列的这些东西不都是经典工程实践吗？Reddit 上反复有人说：一份 AGENTS.md、一份 CONTEXT.md、维护良好的 ADR、加上 lint 和测试这些质量门，搭起来就够了，这不就是经典软件工程吗？r/OpenAI 上一条高赞评论甚至把这层意思讲得很直接：harness engineering 比大家说的简单得多，本质就是用刻意的目录组织和文档让 agent 容易在代码库里干活，再配上 lint 和 tests 这种快速反馈门，agent 就有了好的工作地基。
这个论点的合理内核没法否认。CI、lint、code review、可观测性，这些工具人类工程师用了十几年，agent 进来之后并没有发明新机器。r/vibecoding 一位评论者把这层意思接得更细：harness 不是给模型加超能力，是安全带和强制函数。回执、范围边界、真源路由、关键决策需审批、漂移日志，越是用不到最好的模型，越需要这些治理，因为容错空间更小。
但「换皮论」解释不了一个事实。同模型、同 prompt、只换 harness，结果能差出一截。
三组对照实验放在一起看：
| 实验 | 变量 | 结果差 |
|---|---|---|
| Epsilla 引用的编程基准（来源） | 同一代 GPT-5 / Claude 4、同数据、同 prompt，只换运行时（harness） | 通过率从 42% 提到 78% |
| MindStudio 跑的 5 项基准（来源） | GPT-5.5，OpenAI 原生 Codex harness vs Cursor 的 harness | 功能性测试 61.5% → 87.2%，25.7 个点 |
| Anthropic「复古游戏制作器」对照（HPE 社区作者转述） | 同 prompt，单 agent 跑 vs planner/generator/evaluator 三主体 harness 跑 | 单跑 9 美元 / 20 分钟，核心功能坏掉；harness 跑 200 美元 / 6 小时，做出带 sprite 编辑器的可用游戏 |
第一组那个 42% → 78% 的来源只说「编程基准」，没指名具体哪一项。另一个独立观察（byteiota 关于 SWE-bench 系列基准的整理）给了一个互证：同一份模型权重在不同 agent framework 里跑 SWE-bench，分差就能覆盖 42%，78% 这个区间，决定分数高低的不是模型本身，是 prompting 策略、工具选择、检索系统、迭代循环这一整套外壳，也就是 harness。所以这一行的「换运行时」对应的不是替换某一个组件，而是同时换掉了围在模型外面的整套外壳。
第三组那个对照的细节也值得讲清，因为它解释了 evaluator 这层为什么必须独立存在。Anthropic 的三主体 harness 是 GAN 思路：planner 把一句产品 prompt 展开成更完整的 spec，generator 写代码，evaluator 用 Playwright MCP 去点真实运行起来的产物、按显式契约检查行为，两者反复迭代直到 evaluator 收手。evaluator 扮演的是一个怀疑型 QA 工程师，验 UI、API 端点和数据库状态，行为对不上 spec 就把任务打回 generator。9 美元那次单 agent 跑没崩在某个具体步骤，崩在结构本身。没有任何独立角色去验证产物是否满足契约，模型自评一向不可靠，结果就是表面跑得通、核心功能坏掉。这一组对照表明的是：少了 evaluator 这一主体，前面 planner 和 generator 做得再用力，最终是否收敛到能用的产物完全没保障。
第一组和第三组是方向性结论，第二组 MindStudio 那个 25.7 个点的差是单家测评，按归因引用看就行。三组一起呈现，方向完全一致：harness 是独立变量，并非 prompt 或模型的下游附属品。如果换皮论成立，把模型和 prompt 焊住、只动外面那层壳，分数不应该有这种量级的位移。
那这层壳到底新在哪？OpenAI 工程团队自己给过判断：他们当下最棘手的挑战集中在设计环境、反馈回路、控制系统这三件事上。Anand Topu 转述 Ryan Lopopolo 的关键词更直白：实现不再是稀缺资源，稀缺的是围绕代码的那些东西，注意力、上下文、清晰度。把这两句话放在一起，「换皮」与「不是换皮」之间的差就清楚了：
- 方法论是老的：强制函数（lint/CI/审批/可观测）这套思路，过去用在防人犯错。
- 强制对象是新的：现在是用同一套方法论去防一个不可靠的 agent 犯错。
- 新挑战不在「写 if-else 防错」这种动作上，而在「该装哪些传感器收 agent 的行为信号、该插哪些前馈钩子在它动手之前拦住、出错之后这个钩子要不要自动给它一条修复指令」。这些是经典工程没现成答案的问题。
所以更准确的说法是：harness engineering 把经典软件工程的强制函数搬到一个新对象上。对象换了，工件长得就不一样。AGENTS.md 不是 README，lint 报错带修复指令不是普通 lint，planner/generator/evaluator 三主体不是普通的微服务拆分。形似神不似。
「lint 报错带修复指令不是普通 lint」是怎么改造出来的？经典 lint 写出错误信息是给人看的（「unused import」），改造成 agent 取向后，错误信息同时是给下一轮 agent 的修复 prompt，结构上是「违反了什么规则 + 为什么这条规则存在 + 应该怎么改 + 可选的最小动作」。一个最小可抄的形态如下，自定义 lint 规则在被触发时输出这种结构化错误，hook 把它喂进 agent 的下一轮 context：
[RULE migration-no-edit]
File: db/migrations/2026_06_25_add_idx.sql
Violation: 已落库的迁移脚本被修改。该文件已在生产执行，事后改写会导致环境间状态分叉。
Fix:
1. 恢复本文件到上游版本（git checkout <sha> -- <file>）
2. 把你想做的改动放到一个新的迁移文件 db/migrations/<next_ts>_<slug>.sql
3. 在新迁移里写 forward/rollback 两段，参考 db/migrations/_template.sql
Allowed-next-actions: revert-file, create-new-migration
落到 Claude Code 上，可以用 hook 机制把这种错误信息在 lint 失败时自动塞回去（PreToolUse/PostToolUse 触发自定义 hook，hook 调用 lint，失败时把上面这段写进下一轮 prompt）。落到 pre-commit 上，等同写一个 pre-commit hook，在拦截 commit 时把同样的错误信息打到一个 agent 取向的输出通道（比如 stderr 加一份 .agent-feedback 文件，让 agent 下一轮读到）。重点不在用哪一种 hook 机制，重点在错误信息从「给人读」改成「给 agent 读、并且自带修复路径」。
对个人开发者怎么落地，先回到 harness engineering 总览里 Agent = Model + Harness 那个公式。你今天能动的不是 Model 那一边，是 Harness 这一边，而且越早动越便宜。Martin Fowler 把这套迭代纪律讲得最朴素：人类的工作就是反复 steer agent，问题反复出现就改前馈/反馈控制，让它下次更不可能再发生。这是一句可以直接抄到团队 wiki 上的工作守则。不去试图一次设计出完美 harness，而是把每一次复发的故障当成下一次 harness 迭代的输入。具体到 Claude Code 这个最常见的落点上，在 Claude Code 上把 harness 这部分补齐是一条更近的路径，把上面这套迭代纪律落进具体的 hook、AGENTS.md 和 lint 规则里。
harness engineering vs spec-driven development：spec 定义做什么，harness 保证做对
「强制函数搬到新对象」这个判断还会引出另一个问题。最近同样很热的 spec-driven development，和 harness engineering 是不是同一件事的两个名字？
spec-driven development 在实现开始之前定义「行为应该是什么样」，harness engineering 搭确定性的测试基础设施，证明这套行为在 PR、CI、发布里持续工作（Spec Coding）。换句话说，spec 是目标状态，harness 是把代码库持续校准到这个目标状态的控制系统。Loiane Groner 把整套关系拆成四层：spec 定义目标状态，harness 定义控制系统，agent 在控制系统里执行变更，人类长期 steer 这个系统。
谁先谁后没争议：没有 spec 就没有可被强制的东西，harness 就是一堆空门（Loiane Groner）。但项目里「今天该投资哪边」是真问题，Spec Coding 给的决策规则可以直接拿去用：
| 场景 | 该补的层 | 原因 |
|---|---|---|
| 行为还没谈拢，code review 时还在吵意图 | 先做 spec | 缺 spec 的典型症状就是「团队知道在做但不知道在做什么」 |
| 行为已定，每次发布都要重复手工核验同一批 case | 投资 harness | 缺 harness 的症状是「知道行为却没法低成本证明它」 |
| AI agent 写实现 | 两个都要 | spec 约束 agent 不越界，harness 证明输出没越界 |
这里要分清一个坑。SDD spec 不是 PRD 换个名字。PRD 是写给人看的、靠部落知识消歧、更新陈旧。SDD spec 是同时写给 agent 和 CI 看的、靠显式约束和验证规则消歧、随工作推进持续更新的活文档（Augment Code）。Augment Code 把它直接定义成「AI agent 派生代码的可执行契约」，这是 SDD 与传统需求文档真正的区别。
spec 的五个步骤怎么对到 harness 的具体控制，Loiane Groner 给了一张映射，工程师拿去就能照着补：
| spec 步骤 | harness 在这一步做什么 | 典型控制 |
|---|---|---|
| 产品意图 | 防止做错方向 | 产品约束文档、非目标、成功指标 |
| 高层设计 | 防止架构漂移 | 架构规则、模块边界、依赖约束 |
| 低层设计 + 验收标准 | 防止行为含糊 | 场景样例、契约样例、固件基线 |
| 实现 | 防止局部代码退化 | 类型检查、lint、静态分析、聚焦测试 |
| 验证 | 防止集成/运行时意外 | CI 门、契约校验、运行时信号、人工核查 |
Spec Coding 把后端 API 测试 harness 切成五层：fixture（确定性种子数据）、data factory（可程序化生成测试对象）、mock server（Prism、WireMock 这类替身）、契约测试 runner（Pact、Schemathesis）、环境引导（Docker Compose 把环境从零拉到可用）。这五层一摆出来读者就能立刻看出 harness 不是抽象口号，是一套可以一层一层补上去的工程件。
Martin Chesbrough 的判断可以收个尾：今天软件工程师需要学的就是 harness engineering 的技术实践，spec-driven 是配合它把人和 AI 协作做好的载体。想看 spec 怎么具体落到 agent 工作流里、harness 这部分怎么在一个真实编辑器里补齐，可以接着读在 Claude Code 上做 harness engineering 的实操篇。
把四个词放回工作流：今天动手补哪一层
花 30 秒回想过去一周里反复出现的 agent 故障，按前面的三层诊断各归一类。指令被误解或格式跑偏归 prompt，缺关键信息、检索到陈旧内容归 context，卡死、工具调用顺序错、正确输出却引发坏副作用、缺护栏归 harness。哪一栏最长，今天就动哪一栏，别同时改三处。
想把概念基础再过一遍，回到 harness engineering 总览，看 Agent = Model + Harness 的基础公式怎么往下拆。想直接在工具里把这一层补齐，看怎么在 Claude Code 上把 harness 这部分补齐，里面给了 AGENTS.md、hooks、lint 的可拷贝起点。
常见问题
harness engineering 中文怎么翻译？为什么没有公认的中文名？
目前没有公认的中文译名。「线束工程」按字面翻但读者会懵，「脚手架工程」和已有的 scaffolding 概念冲突，「约束工程」又丢掉了反馈和编排的含义。2026 年 6 月当下，中文技术社区普遍直接用英文 harness engineering。这个术语本身在中文语境里还在普及阶段，找不到官方中文名是正常的。你看到的各种中文写法都是作者自译，不构成行业共识。
harness engineering 和 LangChain、LangGraph 这种 framework / runtime 是同一个东西吗？
不在同一层。LangChain 是 agent framework，提供抽象和心智模型。LangGraph 是 agent runtime，提供持久执行、流式处理和状态持久化。harness 是建在两者之上的工程层，专门解决「让 agent 可靠地完成任务」这个问题，包括工具清单、skills、编排约束、hooks 和反馈机制。你可以用 LangChain + LangGraph 搭出一套 harness，也可以用别的工具搭。framework 和 runtime 是 harness 的原材料，不等于 harness 本身。
如果我已经在做 context engineering，需要再单独学 harness engineering 吗？
取决于你遇到的故障类型。如果 agent 每次单次推理结果都不对，信息缺失、检索陈旧、不知道项目约定，那是 context 层的问题，继续深挖 context engineering。但如果 agent 单次跑得还行、整体系统却越用越乱、几周后开始退化、改坏文件没有拦截、长任务里丢失前面的决定，那是 harness 层的故障，改 context 解决不了。两件事控制的是不同维度。context 解决「模型这一次看到什么」，harness 解决「系统在时间维度上会不会漂走」，一个做得好不能替代另一个。
为什么社区里有「harness 是 context 的子集」和「context 是 harness 的子集」两种相反说法？harness engineering 和 agentic engineering 又是什么关系？
两派的定义边界不同，但都内部自洽。主流共识（LangChain、Martin Fowler）把 harness 定义为「模型之外的一切」，自然包住了 context。HumanLayer 把 context engineering 定义成更宽的「一系列可靠性技术的超集」，harness 就成了其中一个子集。这个分歧的根源是「context」这个词的外延在不同作者那里不一样宽，工程实践里不需要选边站。OS 类比（RAM/磁盘/操作系统）提供了一个足够清楚的工作框架，按层诊断故障、归到哪层就在那层动手就够了。至于 agentic engineering，在 2026 年 6 月当下的社区用法里和 harness engineering 高度重叠，可以视为同义词，遇到 agentic engineering 这个词时直接对应到 harness engineering 理解即可。
对个人开发者来说，harness engineering 是不是只对大团队才有意义？
不是。三组对照实验里（42% 到 78%、61.5% 到 87.2%、9 美元失败 vs 200 美元成功）用的都是单次 agent 跑出来的数字，不是团队协作下的结果。个人开发者用没有 harness 的 agent 和有 harness 的 agent 跑同一个任务，差距同样存在。Reddit r/vibecoding 那条评论说得很直接：越是用不到最好的模型，越需要这些治理，因为容错空间更小。个人开发者通常预算有限、用的模型不是顶配，恰恰是最需要 harness 的群体。最小起点很低，一份 AGENTS.md、一两条 lint 规则、一个 pre-commit hook，今天就能搭起来。
第一周只做一件 harness 工作，应该做哪件？
按「防御价值/搭建成本」排序，建议这个顺序。第一周只做 AGENTS.md，它是后面所有 hook 和 lint 规则要指向的目录，没有它后续工件会变成孤立的零件。第二周加一条 lint 规则，挑你过去这一周被 agent 改坏次数最多的那一类（最常见的是「碰了不该碰的迁移脚本/配置文件/锁文件」），把它写成一条带修复指令的硬规则。第三周加一个 pre-commit hook，把这条 lint 接到提交链路上，让违反规则的 commit 在出门之前就被拦下来。三件事的关系是 AGENTS.md 立目录、lint 立规则、hook 立强制点，顺序倒过来做就会出现规则没地方说明、agent 改了之后没人接住的尴尬。
怎么判断一个故障该加前馈钩子（动手前拦）还是反馈钩子（动手后塞错误回去）？
看故障的代价是否可逆。代价不可逆，已落库的迁移被改写、生产配置被覆盖、外部接口被误调用、密钥被提交，必须前馈：在 agent 动手之前就拦，比如把这类操作的工具调用直接禁掉，或者要求显式审批。代价可逆，代码风格不一致、import 顺序乱、单元测试小幅退步、命名违反约定，反馈就够了，让 agent 先动手，lint/CI 给它一份带修复指令的错误信息，它下一轮自己绕回来重做更便宜。这条判据对应 Fowler 给的两类控制，前馈是 Guides（动手前 steer 它），反馈是 Sensors（动手后让它自纠）。还有一类灰色地带，代价当下可逆但堆积起来会变成不可逆（架构漂移、文档过期、依赖错配），这类靠「周期性扫一遍」的反馈循环更划算，不必每次动手都加前馈钩子。