编码智能体是模型加上围绕它构建的一切。Harness Engineering 将那个脚手架视为活的产物，每次智能体犯错时都收紧它。
简单说：每当智能体失败时，你工程化一个永久解决方案，使它永远不会再犯那个确切的错误。
什么是 Harness？
Trivedy 的核心定义承担了大部分重任：
Agent = Model + Harness。 如果你不是模型，你就是 Harness。
Harness 包含每一个不是模型本身的代码、配置和执行逻辑。原始模型不是智能体。只有当 Harness 为它提供状态、工具执行、反馈循环和可执行约束时，它才成为智能体。
具体而言，Harness 包括：
- 系统提示词、CLAUDE.md、AGENTS.md、技能文件和子智能体指令
- 工具、技能、MCP 服务器及其技术描述
- 捆绑的基础设施，如文件系统、沙箱和无头浏览器
- 编排逻辑，用于生成子智能体、处理交接和路由模型
- 钩子和中间件，用于确定性执行，如 lint 检查或上下文压缩
- 可观测性工具，用于日志、追踪、成本和延迟计量
核心而言，智能体是一个运行工具循环以实现目标的系统。真正的技能在于设计工具本身和那个循环。
Claude Code、Cursor、Codex、Aider 和 Cline 都是 Harnesses。底层模型在不同平台上可能完全相同，但你体验到的行为由 Harness 主导。
重新定义"技能问题"
工程师常常在看到智能体做无意义的事情时责怪模型，通常将问题归档为"等待下一个版本"来解决。
Harness Engineering 心态拒绝这种默认。失败通常是可理解的。如果智能体忽略了约定，将其添加到 AGENTS.md。如果它运行了破坏性命令，写一个钩子来阻止它。如果它在 40 步任务中迷失，将架构拆分为规划器和执行器。如果它一贯以损坏的代码结束，将类型检查反向压力信号接入循环。
HumanLayer 的说法："这不是模型问题。这是配置问题。"
性能基准测试证明了这一点：领先模型在现成框架中运行的得分，往往远低于同一模型在定制、高度调优的 Harness 中运行。将模型移入具有更好代码库工具、更紧提示和更锐利反向压力的环境，可以解锁原始设置遗留的能力。
今天模型理论上能做的和你实际看到的之间的差距，主要是 Harness 差距。
棘轮：每次错误都变成规则
Harness Engineering 中最重要的习惯是将智能体错误视为永久信号——不是重试和忘记的一次性意外。
如果智能体发了一个 PR，其中包含被意外合并的注释掉的测试，那是一个输入。AGENTS.md 的下一次迭代必须声明："永远不要注释掉测试；删除或修复它们。"下一个 pre-commit hook 应该自动在 diff 中标记 .skip(。Reviewer 子智能体必须更新以阻止注释掉的测试。
约束应该只在观察到真实失败时添加，只在有能力的模型使它们冗余时移除。好的系统提示词中的每一行都应该追溯到特定的、历史性的失败。
因此，Harness Engineering 是一门学科，而不是一刀切的框架。特定代码库的正确 Harness 完全由其独特的失败历史塑造。
从行为反向工作
设计 Harness 的最有效方式是从期望的行为开始，构建实现它的组件：我们想要的行为 → 实现它的 Harness 设计。
Harness 的每个部分都必须有明确的工作。如果你无法命名一个组件存在是为了交付的特定行为，它应该被移除。
文件系统和 Git — 持久状态
文件系统是基础的。模型只能在其上下文窗口中操作。文件系统提供读取数据的工作空间、卸载中间工作的地方，以及多个智能体协调的表面。
添加 Git 提供免费版本控制，允许智能体跟踪进度、分支实验和回滚错误。
Bash 和代码执行：通用工具
大多数智能体在 ReAct 循环上运行：推理、通过工具调用行动、观察、重复。不是为每个可想象的行动预构建工具，给智能体 bash 访问权限允许它按需构建需要的东西。
智能体通常在 shell 命令方面表现出色，使 bash 和代码执行成为自主解决问题的默认策略。
沙箱和默认工具
Bash 只有在安全运行时才有效。沙箱为智能体提供隔离环境来运行代码、检查文件和验证工作，而不危及主机。
好的沙箱附带强大的默认设置：预安装的语言运行时、测试 CLI 和无头浏览器，允许智能体观察自己的工作并关闭自我验证循环。
记忆和搜索：持续学习
模型除了训练权重和当前上下文外没有知识。Harnesses 使用记忆文件（如 AGENTS.md）弥合这一差距，将知识注入每个会话。
对于实时信息，如新的库版本或实时数据，网页搜索和 MCP 工具直接烘焙到 Harness 中。
对抗上下文腐烂
随着上下文窗口填满，模型的推理能力会下降。Harnesses 使用三种主要技术管理这种稀缺性：
- 压缩： 智能总结和卸载较旧的上下文以防止 API 错误
- 工具调用卸载： 将大量工具输出（如 2,000 行日志）存储在文件系统中，同时在上下文中只保留必要的页眉和页脚
- 渐进披露： 仅在任务明确要求时揭示指令和工具，而不是在启动时加载一切
长程执行
自主、长时间运行的工作遭受早期停止和糟糕的问题分解。Harnesses 通过结构设计对抗：
- 循环： 拦截模型尝试退出的行为，并强制它针对完成目标在新鲜上下文窗口中继续
- 规划： 强制模型将目标分解为逐步计划文件，通过每个步骤后的自我验证钩子检查工作
- 分离： 将生成和评估分离为不同的智能体，防止模型在评分自己工作时固有的正向偏差
钩子是你的执行层
钩子在请求行动和执行之间架起桥梁。它们在特定生命周期运行：工具调用前、文件编辑后或提交前。钩子阻止破坏性命令、强制执行自动格式化以节省 Token、运行测试套件。
理想情况下，成功是静默的，失败是冗长的。 如果类型检查通过，智能体听不到任何声音；如果失败，错误直接注入循环以自我纠正。
规则手册和工具选择
仓库根目录的扁平 Markdown 文件仍然是最高杠杆的配置点。然而，它必须被视为飞行员的检查清单，而不是风格指南。 保持简短，确保每条规则都是通过过去的失败赢得的。
同样的纪律适用于工具。十个高度聚焦的工具永远胜过五十个重叠的工具。
此外，因为工具描述填充提示词，恶意或草率的外部集成（如未经验证的 MCP 服务器）可以在智能体开始工作之前向其中注入不良提示词。
生产中的样子
最清晰的公开成熟 Harness 图景是 Fareed Khan 对 Claude Code 架构的分解。
几乎前面每个部分的概念都作为命名组件出现在这张图中。上下文注入是知识层。循环状态存在于记忆存储和工作树隔离器中。破坏性动作钩子位于权限门后面。子智能体上下文防火墙是整个多智能体层。工具分派注册表是 MCP 服务器和 bash 都插入的地方。
Claude Code 的轨迹至少与底层模型一样关于 Harness。
Harnesses 不会缩小，它们会移动
随着模型改进，对 Harness 的需求不会消失——它会转移。
很容易假设更好的模型使脚手架过时。例如，最近的模型升级大幅减少了"上下文焦虑"缓解的需求。但随着地板提高，天花板也提高。以前无法触及的任务现在可以触及，带来全新的失败模式。
Harness 中的每个组件都编码了关于模型自己无法做什么的假设。当模型改进时，过时的脚手架应该被移除，新的脚手架必须被构建以到达下一个地平线。
训练循环
Harness 设计和模型训练之间存在活跃的反馈循环。
今天的模型通常在特定 Harness 在循环中的情况下进行后训练，产生一定程度的过拟合。模型在 Harness 设计者优先考虑的特定行动上变得异常出色（例如，文件系统操作、bash、子智能体分派）。
这使 Harness 成为活的系统，而不是静态配置文件，并证明"最佳"Harness 是专门为你的独特任务和工作流优化的那个。
Harness-as-a-Service (HaaS)
行业正在从构建在 LLM API（提供补全）上转向构建在 Harness API（提供运行时）上。SDK 现在开箱即用地提供循环、工具、上下文管理、钩子和沙箱。
不是从头构建编排，现代默认是选择一个 Harness 框架，配置其核心支柱，并纯粹专注于领域特定的提示和工具设计。
这就是故障排除可扩展的原因：你正在调优一个良好分解的配置表面，而不是重新发明整个智能体架构。
未来方向
如果你看今天的顶级编码智能体，它们彼此看起来比底层模型更像。 模型不同，但 Harness 模式正在收敛。行业正在迅速识别将生成文本转化为可交付软件所需的承重脚手架。
最令人兴奋的开放问题超越了单个智能体：并行编排多个智能体、使智能体能够分析自己的追踪以修复 Harness 级失败、构建动态即时组装工具的环境。
最终，这是 Harness 停止作为静态配置文件，开始更像编译器行为的阶段。