你用 AI 写代码的时候是不是经常遇到这些崩溃瞬间。AI 总想一步到位写完所有功能结果上下文爆了留下一堆没文档的半成品。刚写完核心功能就说任务全部完成实际上明确要求的一半功能都没做。或者项目看起来能跑其实到处都是隐藏 bug要花好几倍时间自己去修。更离谱的是代码库里有个不规范的写法AI 能复制给整个项目造成坏代码人传人现象。有没有注意到一个现状现在同等能力的模型越来越多但不同产品之间的体验差异没有缩小反而在拉大。比如编程场景有的产品写出来的代码 bug 一堆有的产品写出来的代码可以直接提交。为什么因为模型是一样的但差距不在模型而在于怎么用模型。这个怎么用模型在 AI 行业里有个专门的概念叫 Harness。但怎么用模型这个说法还不够准确。更准确的说法是怎么让模型稳定可靠不失控地工作。这就是我们今天要讲的 Harness Engineering驾驭工程。从写指令到驾驭 AIAI 编程经历了三次演进。第一个阶段是2022到2024年的提示词工程时代。这个阶段的核心是怎么写好一条指令。比如 Few Shot就是在指令里先附上几个符合要求的输出示例让 AI 严格按照示例的格式和逻辑生成内容。Chain of Thought 思维链就是在指令里要求 AI 必须一步一步拆解问题逐步推导不能直接给出结果以此提升逻辑准确率。还有最常见的角色设定在指令开头先给 AI 划定一个明确的身份。但当时哪怕是大家最喜欢玩的 AI 猫娘或者用 AI 帮忙写代码核心玩法都是写一条固定的提示词然后一次性发给 AI让它按照这条指令的要求输出内容。第二个阶段是2025年的上下文工程。这个时候单挑 prompt 不够用了。你开始需要为模型动态构建整个上下文环境让模型在做每一个决策时都能看到它所需要的信息。包括和任务相关的所有文件内容之前和 AI 的全部历史对话AI 可以调用的所有工具的使用规则从专属知识库中检索到的相关资料等等。第三个阶段就是2026年初正式诞生的 Harness Engineering驾驭工程。这个概念由 Harness Corp 联合创始人在2026年2月首次提出。定义只有一句话每当你发现 Agent 犯了一个错误你就花时间去工程化一个解决方案让它再也不会犯同样的错。这句话看起来平平无奇但背后有一个很多人隐隐约约察觉到但却没能说清楚的问题。模型的能力够了但它就是不听话。这个概念提出六天之后OpenAI 就在他们的百万行代码实验报告中正式采用了 Harness Engineering 这个术语官方认可这个工程方向。而在这之后的一个月里这个概念快速火遍了整个 AI 工程圈成了行业内最核心的讨论和落地方向。三个实验证明一切在讲 Harness 怎么设计之前先看三个真实案例。第一个案例是 LangChain。LangChain 是做 AI 开发框架的公司他们今年做了一个实验。用同一个模型 GPT-5.2参数一个都没动只改变了外部的工程环境。然后在 Terminal Bench 2.0编程基准测试上把成绩从52.8提升到了66.5提升了13.7个百分点。排名从第30名开外直接冲到了前五。注意这个过程只改了 Harness不换模型。第二个案例是研究员 NT B Joins 的实验。这个实验的结论更加极端。同一个模型同一个提示词只改变它的运行环境编程基准测试成功率从42%跳到了78%差了将近一倍。而它的变量只有 Harness。换句话说Harness 带来的提升相当于换了一代模型。第三个案例是 OpenAI 的百万行代码实验。OpenAI 的 Codex 团队做的可能是最有说服力的证明。从一个空的 Git 仓库开始用五个月时间大约100万行代码做了1500个 PR全部都是由 AI Agent 生成。人类工程师在这个过程中一行代码都没写过。团队一开始只有三个工程师后来扩到七个平均下来每位工程师每天合并3.5个 PR。他们估算如果用传统方式手写这个项目的工期应该是现在的十倍。Codex 团队的核心工程师说过一句很直接的话Agent 不难Harness 才难。这三个来自行业头部机构、顶级研究员的真实实验和项目最终都指向了一个无可辩驳的结论。模型不是瓶颈Harness 才是。记住这三个数字52.8、42、100万。AI 为什么总是搞砸在讲 Harness 怎么设计之前我们先说一个前置问题Agent 为什么会失败。Anthropic 的工程师总结了四种典型的失败模式。第一种失败模式叫做试图一步到位。Agent 倾向于在一个会话中把所有功能全部做完。结果就是上下文窗口耗尽留下一堆没有文档的半成品代码。等下一个会话启动的时候Agent 只能花大量时间去猜测之前发生了什么。第二种失败模式叫做过早宣布胜利也叫半场开香槟。在复杂项目的开发后期只要 AI 完成了部分核心功能有了可见的产出它就会直接判定整个任务已经全部完成主动终止任务。哪怕用户明确要求的大量功能还没实现核心需求还没被满足依然会被停止。第三种失败模式叫做过早标记功能完成。AI 写完某个功能就会把这个功能标记为已完成而不会主动做端到端的完整功能测试不会验证这个功能在真实运行环境中到底能不能正常使用能不能满足需求。大家有没有遇到过这种情况AI 产出的代码看起来能跑但实际上到处都是隐藏的 bug而我们作为开发者需要花好几倍的时间自己去调试修复。第四种失败模式是坏代码的魔女因子。AI 在生成代码的时候会严格遵循当前代码库里已有的代码模式、架构风格和编写规范无论这个风格、这个模式是好是坏它都会忠实地复制。而且在整个项目里持续放大这个问题。也就是说如果你的代码库里有不规范的写法或者有一些有问题的设计模式AI 不仅不会纠正还会持续复制它、放大它最终导致整个项目出现架构漂移。这意味着不加约束的 AI 智能体会以极快的速度在项目里积累大量技术债务让后续的维护和迭代变得越来越难。这四种失败模式就是 Harness 要解决的核心问题。四大护栏让 AI 听话综合 OpenAI、Anthropic、LangChain 的实践Harness 可以归纳为四个核心组件。第一个组件是上下文工程。最常见的形式就是项目根目录的 agents.md 或 claude.md 文件。这些文件中有一个必须遵守的关键工程要求文件不能太长。ETH Zurich 的研究发现agent.md 文件应该控制在60行以内。过长的指导文件反而会降低 Agent 表现。这是因为上下文其实是一个稀缺资源过多的指导会挤掉任务、代码和相关文档的空间。正确的做法应该是提供一个稳定而小巧的入口点然后让 Agent 根据当前任务按需检索和拉取更多细节。比如在 Ghost 的项目里agents.md 每一行都对应一个历史的失败案例。每一次 AI 犯错都会把对应的规避规则更新到这个文件里让 AI 不会再犯同样的问题。第二个组件叫做架构约束。这是 Harness 最核心的一环。OpenAI 团队建立了严格的分层架构规则从 types、config、ripple、survive、runtime 到 UI并且明确规定每一层只能依赖下面的那一层不能反向依赖。关键在于这些规则不是靠 prompt 告诉 AI 请遵守它而是用确定性的 Linter、结构化测试来机械执行它。如果 Agent 违反架构规则CI 直接挂掉这是没得商量的。而且 Linter 的报错信息里还嵌入了修复指引告诉 Agent 应该怎么改。Cursor 团队在 Self-Driving Code Basics 的专项研究中也得出了完全一致的结论约束比指令更有效。这背后有一个反直觉的行业常识给 AI 的可选择范围越小给它的执行边界越明确AI 的效率和准确率反而越高。反而如果没有明确的架构约束如果 AI 可以生成任何形式的代码它反而会消耗大量 token 去尝试错误的、不可行的方案。第三个组件叫反馈循环。在传统开发中人类工程师负责代码审查。而在 Harness 里这个工作变成了 Agent 对 Agent 的方式。LangChain 总结出一个叫做 Pre-Completion Checklist Middle Layer 的机制。它会在 Agent 退出之前拦截它提醒它对照任务规格做一次验证。从规划、发现、构建、验证到修复一套标准化的闭环流程。行业内也叫 Build and Self Verify分为固定的四个步骤由 Harness 强制 AI 按顺序执行不能跳过任何一步。第四个组件是熵管理。随着时间推移AI 生成的代码会积累大量问题比如文档过时、架构漂移、风格走样。OpenAI 团队管这个叫垃圾回收。他们的做法是定期启动专门的 Agent 去扫描文档不一致、架构违规等问题提交修复 PR。而这些 PR 大多能在一分钟之内审查并合并。另一个做法是 Doc Gardening Agent自动扫描文档和代码之间不一致发现过时的内容就自动提交 PR 修复。使用 Agent 为 Agent 维护文档。四个实战技巧现在你已经知道 Harness 的四大组件了再来看 LangChain 在实际优化过程中的四个具体操作技巧。第一个Trace 分析总结经验教训。Trace 指的是 AI 智能体在执行任务全流程的完整日志里面会记录 AI 每一步的决策、调用的工具、生成的内容、报错信息、还有执行结果等所有操作。LangChain 把 Trace 分析做成一个 Agent Skill。每次实验跑完系统自动抓取 Trace并行启动多个错误分析 Agent主 Agent 汇总发现和建议然后针对性地修改 Harness。这跟机器学习里的 Boosting 逻辑比较相似每一次优化都针对解决已经发生的问题让 AI 不会重复犯同样的错持续提升 Harness 的稳定性。因为很多人用 AI 的时候只会盲目换提示词或者换模型但却从来没有认真仔细分析过任务失败的具体原因白白浪费每一次失败的优化机会。第二点给 Agent 提供上下文。LangChain 针对 AI 最常见的基础执行错误开发了专门的 Local Context Middleware也就是本地上下文中间件。作用是在 AI 执行任务的过程中自动完成固定的标准化操作。第一映射当前工作目录和父子目录结构。第二查找 Python 等工具的安装路径。第三把这些信息注入给 Agent。这么做是因为在陌生环境里不知道当前目录的结构不知道项目里有哪些文件不知道有哪些工具可用也不知道工具的安装位置最终导致写出的代码路径错误或者调用工具失败。第三检测并破解 Doom Loop。Doom Loop 是什么Agent 一旦决定了某个方案就会不断重复这个方案的小修小补哪怕大方向是错的也会直着继续不会重新思考方案的合理性最终陷入死循环浪费大量 token导致任务无法完成。LangChain 的 Loop Detection Middleware也就是循环检测中间件会通过工具调用的钩子实时追踪 AI 对每一个文件的编辑次数对同一个操作重复执行次数等。一旦某个次数超过阈值就给 Agent 的上下文里追加一条提醒请考虑重新审视你的方案。第四点工具不是越多越好。关于这一点Vercel 做过一个实验把 Agent 的工具从15个砍到只剩下两个任务准确率反而从80%提高到100%。这听起来比较反直觉但原理非常简单。给 AI 提供的工具越多它需要理解的工具规则和使用场景相应也会变多也就随之占用了大量的上下文空间同时也会让 AI 在选择工具的时候有可能出现判断失误选错工具用错工具最终导致任务失败。行业标杆实践也验证了这个结论。支付巨头 Stripe 的内部 AI 系统里总共有超过500个可用工具但每个 Agent 只能看到精心筛选过的工具子集而不会看到全部工具以此来保证 AI 执行的准确率。模型重要还是 Harness 重要讲到这里你可能会冒出一个疑问Harness 真的比模型重要吗模型厂商不断提升模型能力Harness 的价值最终会不会被稀释掉关于这个问题整个行业也在讨论。我们把它们分为 Big Model 阵营和 Big Harness 阵营。Big Model 阵营认为模型能力的增长才是主要的Harness 只是权宜之计。OpenAI 的 Noam Brown 说过Harness 就像一根拐杖我们终将能够超越它。他的论据是推理模型出现之前开发者们在 GPT-4o 上搭建了大量复杂的 Agentic 系统来模拟推理能力。然后推理模型一出来很多基础设施一夜之间就不需要了。他给 AI 开发者的建议是别花六个月搭建一个可能六个月后就被淘汰的东西。Big Harness 阵营认为大模型的核心能力是文本理解、逻辑推理和内容生成但这些原生能力无法解决任务执行过程中的稳定性、安全性和可控性问题也无法自主完成长复杂项目的全流程管控。模型是引擎Harness 就是方向盘和刹车。引擎再强没有方向盘你也到达不了目的地。用 Llama Index 创始人 Jerry Liu 的话说模型决定了你能做什么Harness 决定了你能不能做成。我的看法是两边都对了一半但它们适用场景不同。Harness 确实在不断演进和简化。Minus 六个月内重构了五次 HarnessLangChain 一年内重新架构了三次。研究型 Agent 模型变强了Harness 就该变薄。但变薄和消失是两回事。打个比方是不是车速越快护栏就越重要在时速30km 的自行车道可以没有护栏在时速120km 的高速公路护栏是标配不可能没有。而在时速两三百公里的高铁上整个轨道都是封闭的。模型能力在提升Harness 也在进化但架构约束、反馈循环、熵管理这些东西本质上是不会消失的只会换一种形态。Noam Brown 说 Harness 是拐杖这句话是对的。但拐杖会消失方向盘和刹车不会。写在最后OpenAI 团队在总结他们的工作时说了这么一句话我们现在最大的挑战在于设计环境、反馈循环和控制系统。换句话说他们不写代码他们写的是规则。Stripe 的工程师也不写代码他们设计的是 Blueprint确定性节点和 Agentic 节点的混合编排全程管控 AI 的执行流程。这说明什么这说明一个根本性的变化工程师的价值或者说程序员的价值正在从写代码的人变成设计让 Agent 可靠工作系统的人。现在看来Harness Engineering 已经不是某一家公司自己搞的小众尝试了它是现在整个 AI 行业从上到下都在跟进的大势所趋实打实的底层大变化。给新人写 Onboarding 文档对应 agents.md。定代码规范和架构原则对应 Linter 和结构测试。做 Code Review 确保质量对应 CI/CD 检查。定期做技术债清理对应垃圾回收。给工具做精简和选型对应工具链管理。遇到反复出现问题就写进规则对应反馈循环。Agent 越强就越像一个能力很强但需要管理的员工。你不会把一个刚入职的天才工程师扔进一个没有文档、没有规范、没有 CI 的项目里然后还想指望他写出完美的代码。同样的道理你也不应该把一个强大的 AI 模型扔进一个没有 Harness 的环境里然后抱怨它不好用。现在很多人都在问AI 越来越强程序员会不会被取代。现在看来答案已经很明确了。只会写代码的程序员一定会被取代但会设计 Harness、会驾驭 AI 的工程师会迎来自己的黄金时代。所以下次看到一个 AI 工具问这三个问题就够了。出错的时候是怎么自动恢复的上下文满了怎么压缩代码质量靠谁来把关这才是真正看懂一个 AI 产品的方式。
AI写代码总是烂尾?问题不在模型,在你不会驾驭
你用 AI 写代码的时候是不是经常遇到这些崩溃瞬间。AI 总想一步到位写完所有功能结果上下文爆了留下一堆没文档的半成品。刚写完核心功能就说任务全部完成实际上明确要求的一半功能都没做。或者项目看起来能跑其实到处都是隐藏 bug要花好几倍时间自己去修。更离谱的是代码库里有个不规范的写法AI 能复制给整个项目造成坏代码人传人现象。有没有注意到一个现状现在同等能力的模型越来越多但不同产品之间的体验差异没有缩小反而在拉大。比如编程场景有的产品写出来的代码 bug 一堆有的产品写出来的代码可以直接提交。为什么因为模型是一样的但差距不在模型而在于怎么用模型。这个怎么用模型在 AI 行业里有个专门的概念叫 Harness。但怎么用模型这个说法还不够准确。更准确的说法是怎么让模型稳定可靠不失控地工作。这就是我们今天要讲的 Harness Engineering驾驭工程。从写指令到驾驭 AIAI 编程经历了三次演进。第一个阶段是2022到2024年的提示词工程时代。这个阶段的核心是怎么写好一条指令。比如 Few Shot就是在指令里先附上几个符合要求的输出示例让 AI 严格按照示例的格式和逻辑生成内容。Chain of Thought 思维链就是在指令里要求 AI 必须一步一步拆解问题逐步推导不能直接给出结果以此提升逻辑准确率。还有最常见的角色设定在指令开头先给 AI 划定一个明确的身份。但当时哪怕是大家最喜欢玩的 AI 猫娘或者用 AI 帮忙写代码核心玩法都是写一条固定的提示词然后一次性发给 AI让它按照这条指令的要求输出内容。第二个阶段是2025年的上下文工程。这个时候单挑 prompt 不够用了。你开始需要为模型动态构建整个上下文环境让模型在做每一个决策时都能看到它所需要的信息。包括和任务相关的所有文件内容之前和 AI 的全部历史对话AI 可以调用的所有工具的使用规则从专属知识库中检索到的相关资料等等。第三个阶段就是2026年初正式诞生的 Harness Engineering驾驭工程。这个概念由 Harness Corp 联合创始人在2026年2月首次提出。定义只有一句话每当你发现 Agent 犯了一个错误你就花时间去工程化一个解决方案让它再也不会犯同样的错。这句话看起来平平无奇但背后有一个很多人隐隐约约察觉到但却没能说清楚的问题。模型的能力够了但它就是不听话。这个概念提出六天之后OpenAI 就在他们的百万行代码实验报告中正式采用了 Harness Engineering 这个术语官方认可这个工程方向。而在这之后的一个月里这个概念快速火遍了整个 AI 工程圈成了行业内最核心的讨论和落地方向。三个实验证明一切在讲 Harness 怎么设计之前先看三个真实案例。第一个案例是 LangChain。LangChain 是做 AI 开发框架的公司他们今年做了一个实验。用同一个模型 GPT-5.2参数一个都没动只改变了外部的工程环境。然后在 Terminal Bench 2.0编程基准测试上把成绩从52.8提升到了66.5提升了13.7个百分点。排名从第30名开外直接冲到了前五。注意这个过程只改了 Harness不换模型。第二个案例是研究员 NT B Joins 的实验。这个实验的结论更加极端。同一个模型同一个提示词只改变它的运行环境编程基准测试成功率从42%跳到了78%差了将近一倍。而它的变量只有 Harness。换句话说Harness 带来的提升相当于换了一代模型。第三个案例是 OpenAI 的百万行代码实验。OpenAI 的 Codex 团队做的可能是最有说服力的证明。从一个空的 Git 仓库开始用五个月时间大约100万行代码做了1500个 PR全部都是由 AI Agent 生成。人类工程师在这个过程中一行代码都没写过。团队一开始只有三个工程师后来扩到七个平均下来每位工程师每天合并3.5个 PR。他们估算如果用传统方式手写这个项目的工期应该是现在的十倍。Codex 团队的核心工程师说过一句很直接的话Agent 不难Harness 才难。这三个来自行业头部机构、顶级研究员的真实实验和项目最终都指向了一个无可辩驳的结论。模型不是瓶颈Harness 才是。记住这三个数字52.8、42、100万。AI 为什么总是搞砸在讲 Harness 怎么设计之前我们先说一个前置问题Agent 为什么会失败。Anthropic 的工程师总结了四种典型的失败模式。第一种失败模式叫做试图一步到位。Agent 倾向于在一个会话中把所有功能全部做完。结果就是上下文窗口耗尽留下一堆没有文档的半成品代码。等下一个会话启动的时候Agent 只能花大量时间去猜测之前发生了什么。第二种失败模式叫做过早宣布胜利也叫半场开香槟。在复杂项目的开发后期只要 AI 完成了部分核心功能有了可见的产出它就会直接判定整个任务已经全部完成主动终止任务。哪怕用户明确要求的大量功能还没实现核心需求还没被满足依然会被停止。第三种失败模式叫做过早标记功能完成。AI 写完某个功能就会把这个功能标记为已完成而不会主动做端到端的完整功能测试不会验证这个功能在真实运行环境中到底能不能正常使用能不能满足需求。大家有没有遇到过这种情况AI 产出的代码看起来能跑但实际上到处都是隐藏的 bug而我们作为开发者需要花好几倍的时间自己去调试修复。第四种失败模式是坏代码的魔女因子。AI 在生成代码的时候会严格遵循当前代码库里已有的代码模式、架构风格和编写规范无论这个风格、这个模式是好是坏它都会忠实地复制。而且在整个项目里持续放大这个问题。也就是说如果你的代码库里有不规范的写法或者有一些有问题的设计模式AI 不仅不会纠正还会持续复制它、放大它最终导致整个项目出现架构漂移。这意味着不加约束的 AI 智能体会以极快的速度在项目里积累大量技术债务让后续的维护和迭代变得越来越难。这四种失败模式就是 Harness 要解决的核心问题。四大护栏让 AI 听话综合 OpenAI、Anthropic、LangChain 的实践Harness 可以归纳为四个核心组件。第一个组件是上下文工程。最常见的形式就是项目根目录的 agents.md 或 claude.md 文件。这些文件中有一个必须遵守的关键工程要求文件不能太长。ETH Zurich 的研究发现agent.md 文件应该控制在60行以内。过长的指导文件反而会降低 Agent 表现。这是因为上下文其实是一个稀缺资源过多的指导会挤掉任务、代码和相关文档的空间。正确的做法应该是提供一个稳定而小巧的入口点然后让 Agent 根据当前任务按需检索和拉取更多细节。比如在 Ghost 的项目里agents.md 每一行都对应一个历史的失败案例。每一次 AI 犯错都会把对应的规避规则更新到这个文件里让 AI 不会再犯同样的问题。第二个组件叫做架构约束。这是 Harness 最核心的一环。OpenAI 团队建立了严格的分层架构规则从 types、config、ripple、survive、runtime 到 UI并且明确规定每一层只能依赖下面的那一层不能反向依赖。关键在于这些规则不是靠 prompt 告诉 AI 请遵守它而是用确定性的 Linter、结构化测试来机械执行它。如果 Agent 违反架构规则CI 直接挂掉这是没得商量的。而且 Linter 的报错信息里还嵌入了修复指引告诉 Agent 应该怎么改。Cursor 团队在 Self-Driving Code Basics 的专项研究中也得出了完全一致的结论约束比指令更有效。这背后有一个反直觉的行业常识给 AI 的可选择范围越小给它的执行边界越明确AI 的效率和准确率反而越高。反而如果没有明确的架构约束如果 AI 可以生成任何形式的代码它反而会消耗大量 token 去尝试错误的、不可行的方案。第三个组件叫反馈循环。在传统开发中人类工程师负责代码审查。而在 Harness 里这个工作变成了 Agent 对 Agent 的方式。LangChain 总结出一个叫做 Pre-Completion Checklist Middle Layer 的机制。它会在 Agent 退出之前拦截它提醒它对照任务规格做一次验证。从规划、发现、构建、验证到修复一套标准化的闭环流程。行业内也叫 Build and Self Verify分为固定的四个步骤由 Harness 强制 AI 按顺序执行不能跳过任何一步。第四个组件是熵管理。随着时间推移AI 生成的代码会积累大量问题比如文档过时、架构漂移、风格走样。OpenAI 团队管这个叫垃圾回收。他们的做法是定期启动专门的 Agent 去扫描文档不一致、架构违规等问题提交修复 PR。而这些 PR 大多能在一分钟之内审查并合并。另一个做法是 Doc Gardening Agent自动扫描文档和代码之间不一致发现过时的内容就自动提交 PR 修复。使用 Agent 为 Agent 维护文档。四个实战技巧现在你已经知道 Harness 的四大组件了再来看 LangChain 在实际优化过程中的四个具体操作技巧。第一个Trace 分析总结经验教训。Trace 指的是 AI 智能体在执行任务全流程的完整日志里面会记录 AI 每一步的决策、调用的工具、生成的内容、报错信息、还有执行结果等所有操作。LangChain 把 Trace 分析做成一个 Agent Skill。每次实验跑完系统自动抓取 Trace并行启动多个错误分析 Agent主 Agent 汇总发现和建议然后针对性地修改 Harness。这跟机器学习里的 Boosting 逻辑比较相似每一次优化都针对解决已经发生的问题让 AI 不会重复犯同样的错持续提升 Harness 的稳定性。因为很多人用 AI 的时候只会盲目换提示词或者换模型但却从来没有认真仔细分析过任务失败的具体原因白白浪费每一次失败的优化机会。第二点给 Agent 提供上下文。LangChain 针对 AI 最常见的基础执行错误开发了专门的 Local Context Middleware也就是本地上下文中间件。作用是在 AI 执行任务的过程中自动完成固定的标准化操作。第一映射当前工作目录和父子目录结构。第二查找 Python 等工具的安装路径。第三把这些信息注入给 Agent。这么做是因为在陌生环境里不知道当前目录的结构不知道项目里有哪些文件不知道有哪些工具可用也不知道工具的安装位置最终导致写出的代码路径错误或者调用工具失败。第三检测并破解 Doom Loop。Doom Loop 是什么Agent 一旦决定了某个方案就会不断重复这个方案的小修小补哪怕大方向是错的也会直着继续不会重新思考方案的合理性最终陷入死循环浪费大量 token导致任务无法完成。LangChain 的 Loop Detection Middleware也就是循环检测中间件会通过工具调用的钩子实时追踪 AI 对每一个文件的编辑次数对同一个操作重复执行次数等。一旦某个次数超过阈值就给 Agent 的上下文里追加一条提醒请考虑重新审视你的方案。第四点工具不是越多越好。关于这一点Vercel 做过一个实验把 Agent 的工具从15个砍到只剩下两个任务准确率反而从80%提高到100%。这听起来比较反直觉但原理非常简单。给 AI 提供的工具越多它需要理解的工具规则和使用场景相应也会变多也就随之占用了大量的上下文空间同时也会让 AI 在选择工具的时候有可能出现判断失误选错工具用错工具最终导致任务失败。行业标杆实践也验证了这个结论。支付巨头 Stripe 的内部 AI 系统里总共有超过500个可用工具但每个 Agent 只能看到精心筛选过的工具子集而不会看到全部工具以此来保证 AI 执行的准确率。模型重要还是 Harness 重要讲到这里你可能会冒出一个疑问Harness 真的比模型重要吗模型厂商不断提升模型能力Harness 的价值最终会不会被稀释掉关于这个问题整个行业也在讨论。我们把它们分为 Big Model 阵营和 Big Harness 阵营。Big Model 阵营认为模型能力的增长才是主要的Harness 只是权宜之计。OpenAI 的 Noam Brown 说过Harness 就像一根拐杖我们终将能够超越它。他的论据是推理模型出现之前开发者们在 GPT-4o 上搭建了大量复杂的 Agentic 系统来模拟推理能力。然后推理模型一出来很多基础设施一夜之间就不需要了。他给 AI 开发者的建议是别花六个月搭建一个可能六个月后就被淘汰的东西。Big Harness 阵营认为大模型的核心能力是文本理解、逻辑推理和内容生成但这些原生能力无法解决任务执行过程中的稳定性、安全性和可控性问题也无法自主完成长复杂项目的全流程管控。模型是引擎Harness 就是方向盘和刹车。引擎再强没有方向盘你也到达不了目的地。用 Llama Index 创始人 Jerry Liu 的话说模型决定了你能做什么Harness 决定了你能不能做成。我的看法是两边都对了一半但它们适用场景不同。Harness 确实在不断演进和简化。Minus 六个月内重构了五次 HarnessLangChain 一年内重新架构了三次。研究型 Agent 模型变强了Harness 就该变薄。但变薄和消失是两回事。打个比方是不是车速越快护栏就越重要在时速30km 的自行车道可以没有护栏在时速120km 的高速公路护栏是标配不可能没有。而在时速两三百公里的高铁上整个轨道都是封闭的。模型能力在提升Harness 也在进化但架构约束、反馈循环、熵管理这些东西本质上是不会消失的只会换一种形态。Noam Brown 说 Harness 是拐杖这句话是对的。但拐杖会消失方向盘和刹车不会。写在最后OpenAI 团队在总结他们的工作时说了这么一句话我们现在最大的挑战在于设计环境、反馈循环和控制系统。换句话说他们不写代码他们写的是规则。Stripe 的工程师也不写代码他们设计的是 Blueprint确定性节点和 Agentic 节点的混合编排全程管控 AI 的执行流程。这说明什么这说明一个根本性的变化工程师的价值或者说程序员的价值正在从写代码的人变成设计让 Agent 可靠工作系统的人。现在看来Harness Engineering 已经不是某一家公司自己搞的小众尝试了它是现在整个 AI 行业从上到下都在跟进的大势所趋实打实的底层大变化。给新人写 Onboarding 文档对应 agents.md。定代码规范和架构原则对应 Linter 和结构测试。做 Code Review 确保质量对应 CI/CD 检查。定期做技术债清理对应垃圾回收。给工具做精简和选型对应工具链管理。遇到反复出现问题就写进规则对应反馈循环。Agent 越强就越像一个能力很强但需要管理的员工。你不会把一个刚入职的天才工程师扔进一个没有文档、没有规范、没有 CI 的项目里然后还想指望他写出完美的代码。同样的道理你也不应该把一个强大的 AI 模型扔进一个没有 Harness 的环境里然后抱怨它不好用。现在很多人都在问AI 越来越强程序员会不会被取代。现在看来答案已经很明确了。只会写代码的程序员一定会被取代但会设计 Harness、会驾驭 AI 的工程师会迎来自己的黄金时代。所以下次看到一个 AI 工具问这三个问题就够了。出错的时候是怎么自动恢复的上下文满了怎么压缩代码质量靠谁来把关这才是真正看懂一个 AI 产品的方式。
