☘️
Harness Engineering
- Harness 是什么？（模型的方向盘+刹车）
- 核心思想：Agent 的可靠性瓶颈不在模型，而是在模型的系统环境。模型是推理引擎，Agent 是整辆车，引擎再强没有方向盘和刹车也无法驾驶
- 例如 每当让Agent 犯了一个错误，则通过 上下文管理、应编码约束等手段让Agent 永远不犯同样的错
- 与 context engineering 的区别
- context engineering 是给 Agent 看什么
- 管理 Agent 的上下文窗口，管理 Agent 看什么信息 不看什么信息
- harness engineering 是系统预防了什么、测量了什么、修复了什么
- 范围更广，包含架构约束、自验证循环、熵治理、系统的可演进性
- Harness 有什么用？
- LangChain Coding Agent 通过仅修改 Harness 在 terminal Bench 排行中从 top 30 冲到 top 5
- 没有更换底层模型，只是修改了 系统提示、工具配置、中间件 hook
- 即使在模型不变的前提下，光靠优化模型的系统环境也能带来很高的提升
- Harness 包含什么？
- 上下文架构
- Open AI 和 Anthropic 指出给Agent太多信息反而有害，Agent 的性能在上下文利用率超过大约百分之四十后开始下降
- 关键在于 不是给 Agent 一本百科全书，而是给 Agent 一张地图，让它按需查找（ 与 skills 渐进式披露理念相同）
- Open AI 的做法是将
AGENTS.MD 文件控制在大约 100 行 只充当目录 指向更深层的文档，Agent 需要什么信息让它自己去查，而不是一开始全部塞进去
- 架构约束 - 约束解空间
- 大多数情况下会通过 Prompt 约束 Agent 的行为，例如写 “请遵守以下规则” 但 prompt 中的规则本质上是
“建议” 模型可能会遵守也可能不会
- 应该用确定性的工具来进行约束，例如自定义的 linter(语法检查器) 和 结构化测试，规则一旦编码就在所有Agent会话中生效
- Vercel 一开始给 Agent 提供大量的工具，什么都能用 结果 Agent 反而变得困惑做冗余调用，后来它们移除 80% 的工具反而更快更可靠
- 自验证循环
- LangChain 的方案是使用中间件 hook 来解决
- 中间件跟踪每个文件的编辑次数超过阈值就提醒Agent重新审视方案
- Agent 在准备完成时拦截它执行一轮完整验证
- 推理三明治（根据模型来调整，例如：OpenAI 官方推荐 GPT5.4 建议大多数任务使用 high 即可，xhigh容易让模型思考过度反而导致性能下降成本上升）
- 规划阶段用 max or xhigh 推理强度充分理解问题
- 执行阶段使用 high 推理保证速度
- 验证阶段再拉回 max or xhigh 推理强度捕获错误
- 上下文隔离
- 当任务复杂到需要多个 Agent 协作时关键不是按角色分工
- 而是将 子 agent 当作上下文的防火墙
- 父 agent 只看给 子agent 的指令和 子 agent返回的最终结果，中间所有的工具调用和中间产物都被隔离，保持每个 agent 的上下文不被冗余的信息污染
- 熵治理
- Agent 持续运行的时间越长系统的混乱度越高，可能出现 文档过时、架构漂移、知识库和代码不一致
- Open AI 的方案是引入一个后台运行的文档梳理 Agent 定期扫描过时的文档并自动提交修复，形成自维护的闭环
- 可拆卸性
- 随着模型能力的提升， Harness 组件可能会逐渐变成模型性能的瓶颈（目前最强大的模型极大可能将会在六个月内被超越）
- 奥特曼名言：你今天所使用的最强模型，将是你余生中使用过最糟糕的模型
- 今年还需要 任务拆分、验证 才能完成的复杂任务，一年后强大的模型很可能只需要一个 prompt 就能完成
- 因此 Harness 必须是模块化的、可拆卸的，参考 Langchain 的方案，每个中间件独立添加特定能力，不需要的时候直接移除，不影响其他部分
- Harness 的投入是以复利形式生效的，加一条 linter 规则之后所有会话中这个错误都会被预防，加一个 hook 之后所有任务的交付都会经过这个 hook
- 投入越早，收益越大，但也不要过度工程化，只在 Agent 确实犯过错的时候再投入 Harness
