公众号名称：ElonMax

作者名称：ElonMax

发布时间：2026-06-18 07:44

同一个模型，采用不同的智能体构建方案，排名从第35 跃升至第5，所以，你的Agent能力天花板不在模型里，而在👇的详细说明里😁

2026年3月，HumanLayer在博客里公布了一个让很多人坐不住的数据。

Terminal Bench 2.0上，Claude Opus 4.6——当时公认的最强编码模型——在Claude Code这个官方工具里跑，得分排名第33。同一个模型被放到一个第三方团队定制的工具链里，直接冲到第5名。

第33到第5。只换了工具链，没换模型。

这不是个例。Viv Trivedy——Harness Engineering 这个概念的提出者——公开说过，自己的团队把 Agent 的表现从 Top 30 提升到 Top 5，靠的仅仅是重建了模型外部的那层系统。

你可能也猜到了：问题不在模型，在模型外面的东西。

而这个”外面的东西”，正是2026年上半年AI Agent开发领域最值得关注的认知转向——Loop Engineering 和 Agent Harness Engineering。它们在同时回答同一个问题：当 AI Coding Agent 从被动问答工具进化为在反馈循环中自主迭代的系统时，我们该怎样设计这个系统？

“做完一步看一步”的工程化

先说第一个概念：Loop Engineering。

Kilo.ai在2026年6月给出的定义是目前最清晰的概括——Loop Engineering是”设计、运行并持续改进AI编码Agent内部反馈循环的工程实践”。

翻译成人话：你不再把AI当作一个一次性的代码生成器，而是设计一套”定义目标→查看代码→改代码→验证结果→读输出→决定下一步”的迭代系统。

这跟 Prompt Engineering 的区别在哪？Prompt Engineering 关心的是”怎么让模型第一次就输出好结果”，基本单元是一条 Prompt，评估标准是第一次回答的质量。Loop Engineering 关心的是”怎么让模型在一轮轮的反馈中持续纠偏直到任务完成”，基本单元是循环流程，评估标准是最终结果的正确性。

最直观的例子来自 Kilo 的原文：假设你让 Agent 修一个 Bug——用户在保存账单设置时，如果公司名包含单引号就会报错。

弱循环的设计：Agent猜测Bug是SQL注入转义问题，直接改数据库查询。

强循环的设计：Agent先找到前端表单、API路由、校验Schema、数据库更新路径。然后尝试复现失败。观察问题出在前端校验、后端校验、序列化、SQL还是展示逻辑。然后改最小的相关代码路径。跑回归测试。确认修复。

两者的差距在哪里？不是模型的能力，是 Agent有没有被设计成会”看验证结果再决定”的系统。

一个完整的 Loop 有五个阶段：意图设定（定义明确可验证的目标）→ 上下文采集（从代码库和日志中收集必要信息）→ 行动（修改代码或运行命令）→ 观察（捕获测试结果、编译错误、运行时输出）→ 调整（根据观察更新计划并继续）。五个阶段不断循环，直到任务完成或被卡住。

Loop Engineering 最反直觉的点正在这里：测试失败不是错误，是新的上下文。类型错误不是阻塞，是关于某个假设被推翻的信号。一次代码审查不是反馈，是驱动下一轮行动的观察。

五种经典的反馈循环模式

不同场景需要不同的反馈信号，由此衍生出五种已被广泛验证的循环模式：

测试驱动循环：Agent先复现失败或写一个失败的测试，然后修改实现代码直到测试通过。适合Bug修复、解析器行为、数据转换。反馈信号二元且清晰——测试通过或失败。

编译器驱动循环：类型系统天然就是一个反馈传感器。Agent改代码→跑类型检查→把编译错误当作精确的修复清单。在迁移、依赖升级、大规模重构中效果极其显著。

审查驱动循环：人类审查者的评论成为观察源。Agent分类评论→区分Bug、产品问题、风格偏好和超出范围的需求→针对性修改→验证结果。反馈信号丰富但需要解析。

运行时调试循环：Agent用日志、堆栈跟踪、HTTP响应、浏览器截图来缩小根因。每次迭代都是一次”形成假设→做定向修改或添加定向检测→观察结果→更新假设”的循证过程。反馈信号最接近真相，但也最嘈杂。

产品迭代循环：文案、UI状态、边界条件、验收标准都需要迭代。Agent实现版本→对比设计约束→调整布局→验证响应式行为。反馈信号来自设计规范和用户验收标准，有时需要人类判断。

Agent = Model + Harness

如果说 Loop Engineering 定义了 Agent”怎么动”，那 Harness Engineering 定义了 Agent”在什么里面动”。

Viv Trivedy 把这个问题提炼成一个高度浓缩的公式：Agent = Model + Harness。

这个公式的力量在于它的排他性——如果你不在模型侧，那你的所有工作就是造 Harness。Harness 具体包含什么？系统提示词和 AGENTS.md。工具、Skill、MCP服务器以及它们的描述。文件系统、沙盒、浏览器等内置基础设施。子代理的编排逻辑——拆分、切换、路由。Hook 和中间件——压缩上下文、续接任务、运行 Lint 检查。可观测性——日志、Trace、成本和延迟计量。

听起来像一套工作量巨大的脚手架。确实如此。而且这些不是模型提供方的职责范围，是你的。Claude Code、Cursor、Codex、Aider、Cline，本质都是 Harness。底层模型有时一样，但你感受到的行为差异，80%来自 Harness 的设计。

Addy Osmani 在4月的博客里写下了一句话——我认为它是2026年上半年关于 Agent 最值得记住的论断之一：

“一个不错的模型配上优秀的 Harness，击败了一个优秀模型配上糟糕的 Harness。“

棘轮机制：每次失败都变成一条规则

Harness Engineering 最重要的工程习惯，我称之为”棘轮机制”。

普通人看到 Agent 犯错时的反应：“哈，AI真蠢。”

Harness 工程师的反应：“这个错误可以变成一条规则。”

Agent 提交了包含注释掉的测试的 PR？AGENTS.md 里加一条”永远不要注释测试；要么删除要么修复”。Agent 执行了危险 Bash 命令？加 Hook 拦截 rm -rf、git push --force 和 DROP TABLE。Agent 在长任务里迷路了？拆成 Planner 和 Executor，用文件系统传递中间状态。Agent 反复”说任务完成了”但代码还跑不通？在循环里接入类型检查的背压信号——类型检查不通过，Agent 就被循环卡住。

HumanLayer 说得极透彻：“这不是模型问题。这是配置问题。”

每条好的 Harness 规则都应该能溯源到一次真实发生的失败。不能凭空拍脑袋加。你只能因为 Agent 真的犯了这个错才加这条规则。等到模型变强到不再犯这个错了，就可以删掉这条规则。

这听起来粗糙，但它提供了一个极其强大的属性：规则越用越精，Agent 越用越好。

Harness 的八大组件

综合 Viv Trivedy、Addy Osmani、HumanLayer 和 Anthropic 团队的输出，我把一个成熟的 Harness 分解为以下八大组件。

文件系统和Git——持久状态层：没有文件系统，Agent 就只能靠上下文窗口里的那点东西工作。有了文件系统和 Git，Agent 可以读代码、写中间产物、做版本管理、跨会话共享状态。绝大多数其他 Harness 组件最终都会指向文件系统做点什么。

Bash和代码执行——通用工具：今天的 Agent 主循环是 ReAct 模式，但 Harness 只能执行它预先定义了逻辑的工具。与其预构建所有工具，不如给 Agent 一个 Bash 终端，让它按需构建工具。Simon Willison 一针见血：“Agent 已经非常擅长 Shell 命令了。多数任务可以归结为几条精心选择的 CLI 调用。”

沙盒和默认工具集：Bash 只有跑在安全的地方才有用。沙盒提供隔离的操作环境——语言运行时、包管理器、Git、测试 CLI、无头浏览器。Agent 在沙盒里安装依赖、运行代码、做自验证。模型不配置自己的执行环境。决定 Agent 在哪儿跑、有什么可用、怎么验证输出——全是 Harness 层面的决策。

记忆和搜索——持续学习：模型的知识只到训练数据截止日期。Harness 通过 AGENTS.md 在会话间传递知识。Agent 修改那个文件，Harness 重新加载它，知识就流动了。一种粗糙但有效的持续学习。

对抗上下文腐烂（Context Rot）：Context Rot 是当前 Agent 系统工程中最棘手的瓶颈——随着上下文窗口填满，模型的推理和完成任务能力显著下降。三种应对技术：压缩（智能摘要和卸载旧上下文）、工具调用卸载（大工具输出的头尾留在上下文，完整内容卸载到文件系统）、渐进式 Skill 披露（启动时只加载必需 Skill，特定任务需要时才展示更多）。Anthropic 还贡献了第四种：完全上下文重置——把当前会话完全拆除，从一份结构化的交接文件重建。

长周期执行——Ralph Loop、规划、验证：Ralph Loop 是一个极简但有效的技巧——Hook 拦截模型尝试退出的动作，把原始 Prompt 重新注入一个干净的上下文窗口，强迫 Agent 继续。这个技巧把一个单会话 Agent 变成了多会话 Agent。更复杂的架构是 Planner/Generator/Evaluator 的拆分。Anthropic 团队明确说，拆分生成和评估到不同的 Agent，比让同一个 Agent 自己评估自己的产出效果好得多——因为 Agent 在评估自己工作时总是偏向乐观。

Hook——强制执行层：Hook 是你从”我告诉 Agent 要做 X”到”系统强制执行 X”的分界线。在工具调用前、文件编辑后、提交前、会话启动时运行。成功静默、失败详细——这是 Hook 的设计原则。类型检查通过了，Agent 什么也听不到。类型检查失败了，错误文本注入循环让 Agent 做自修正。

AGENTS.md和工具选择——最高杠杆的配置点：放在代码仓库根目录的 Markdown 规则文件，仍是单点杠杆最高的配置。两条实战教训：保持简短——HumanLayer 控制在60行以内。每条规则都要挣来——每条规则应该能溯源到一次具体的失败。棘轮，不脑暴。

一场价值200美元的对比实验

理论听完了，来点实打实的案例。

2026年3月，Anthropic 的研究员 Prithvi Rajasekaran 发表了一份 Harness 设计报告，是公开领域里对完整 Harness 架构最透彻的产出。他的目标是：让 Claude 在没有人类干预的情况下，花几个小时构建完整的全栈应用。

他发现了两个核心问题。第一个是上下文焦虑（Context Anxiety）：模型在接近自己认为的上下文限制时，会提前收尾工作。第二个是自我评估偏差：让 Agent 评估自己产出的代码质量？它会自信地给出大量好评，哪怕人类一看就是中等水平。

他的解法是一个受 GAN 启发的三 Agent 架构：

规划者（Planner）：接收一两句话的需求描述，展开成一份包含16个子功能、横跨10个 Sprint 的完整产品规格。系统 Prompt 明确让它聚焦产品上下文和高层技术设计，不追求技术实现的细节——因为如果规划者预先指定了某个方案错了，这个错误会在下游级联放大。

生成者（Generator）：按 Sprint 一个一个功能实现，技术栈是 React + Vite + FastAPI + SQLite（后升级为 PostgreSQL）。每个 Sprint 结束后做自评估，然后交给质量门。

评估者（Evaluator）：用 Playwright MCP 真正点击运行中的应用。不是静态看代码，是真的像一个用户那样点按钮、填表单、查 API。按四个维度评分——产品深度、功能完整性、视觉设计、代码质量。每个维度有硬阈值，任何一项不达标，Sprint 就算失败。

在每次 Sprint 开始前，生成者和评估者要协商一份 Sprint Contract：约定”done”长什么样才动工。生成者提出要建什么、怎么验证。评估者审查提案，确认生成者在做正确的事情。双方迭代直到达成一致。

结果是残酷的：

单Agent版本：20分钟，9美元。应用能打开但游戏跑不起来，实体出现在屏幕上但没有响应任何输入。布线是坏的，代码层面没有任何表面指示。

完整 Harness 版本：6小时，200美元。16个功能全部实现：精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计师、可分享链接的游戏导出。还因为 Planner 被要求”在规格中融入 AI 功能”，自带了 Claude 集成。

20倍的Token成本，换来的是从”不能运行”到”可以玩”的质变。

天花板随着模型上移，但不会消失

读到这你在想什么——如果模型继续变强，这些 Harness 组件大部分会不会变成多余的？

Anthropic 团队的回答：每个 Harness 组件都编码了一个”模型自己不会做”的假设。模型变强了，那个假设就可能不再成立，那个组件就该被移除。

但故事没有到此结束。模型变强后，之前不可能完成的任务变成了可以挑战的。新任务有新失败模式，新失败模式需要新的 Harness 组件。旧的 Harness 组件被移除的同时，新的 Harness 需求出现了。

Harness 不会缩小，它只是移动了。

半年多前，Sonnet 4.5 还有严重的上下文焦虑，Harness 不得不用复杂的上下文重置和交接机制来应对。Opus 4.6 来了，上下文焦虑几乎消失了。那套焦虑缓解的脚手架成了死代码，可以删了。但随之而来的是新的问题：现在 Agent 能跑更长时间了，但多天范围内的记忆策略呢？多个专业 Agent 之间的协调呢？生成式 UI 的设计质量评估呢？

天花板随着模型的能力上移了，但天花板本身没有消失。

这也解释了为什么最好的 Harness 设计者始终在迭代一个活系统，而不是设置一次就撂那儿不管。

你的代码库有多”可Harness”？

Birgitta Böckeler 在 Martin Fowler 的网站上写了一篇我反复读过的文章。她提出了 Harness Engineering 中一个容易被忽略的概念：Harnessability（可Harness性）。

不是所有代码库同样适合被 Harness。强类型语言天然有类型检查作为反馈传感器。清晰的模块边界可以施加架构约束规则。Spring 这样的框架抽象了大量细节，Agent 甚至不用理会。没有这些属性，那些控制机制你就建不了。

她的同事 Ned Letcher 给这些属性起了一个名字：Ambient Affordances（环境可读性）——“环境本身的那些结构属性，使得它对于在其中运行的 Agent 来说，是可读的、可导航的、可处理的。”

这在新项目和遗留项目之间制造了一个残酷的分化。新项目可以从第一天就设计可 Harness 性。遗留项目——尤其是积累了巨量技术债的——面临一个悖论：最需要 Harness 的地方恰恰是最难建 Harness 的地方。

她还提出了 Harness Templates 的概念：把一组针对某种技术栈的引导层和传感器层打包成模板，新项目可以直接装载使用。未来团队选择技术栈时，也许会问一句：“有没有现成的 Harness 模板？”

这和 Ashby 的必要多样性定律形成呼应——一个调节器必须至少拥有它所调节的系统具有的多样性。LLM 可以生成几乎任何东西，但如果你锁定了技术拓扑，Agent 的输出空间就被大幅压缩，一个全面的 Harness 也变得更可行了。

汇合：一个完整的融合架构

Loop Engineering 和 Harness Engineering 不是两个独立的概念。它们是一个硬币的两面。

Loop Engineering 定义的是 Agent 的动态行为逻辑——它在时间轴上怎么迭代、怎么纠偏、怎么收敛。Harness Engineering 定义的是 Agent 的静态外围系统——它依赖什么基础设施、遵循什么约束、通过什么渠道获得反馈信号。

两者的交汇点只有一个字：反馈。

Harness 负责生产高质量的反馈信号——编译错误、测试失败、Lint 警告、运行时日志、代码审查意见、UI 截图。Loop 负责消费这些反馈信号并转化为下一步行动——分析失败原因、修改代码、重新验证、循环直到成功。

一个完整的融合架构大致如下：

底层是 Harness 基础设施：文件系统、Git、沙盒、Bash 终端、MCP 服务器、可观测性管道。

中间层是 Harness 配置：AGENTS.md（行为规则）、Hook（强制校验）、子 Agent 编排（上下文防火墙）、Skill（渐进式知识披露）。

运行时是 Loop 执行引擎：Plan→Search→Modify→Verify→Repair→Summarize 的迭代循环。

外层是 人类工程师的棘轮循环：发现 Agent 犯错→转化为 AGENTS.md 规则或 Hook 逻辑→在下次运行时自动生效→Agent 越用越好。

这个架构提供了三个独特价值：

第一，它把 Agent 开发从 Prompt Engineering 的认识论陷阱里拉了出来。 你不再纠结于怎么把一句话写得让模型”理解正确”，而是设计一套系统让模型在犯错后自己发现并修正。从”降低首次出错的概率”到”提高纠错的速度和可靠性”，这是一次思路转向。

第二，它提供了一个可累积的知识管理框架。 每条规则可以溯源到一次真实失败，每个 Hook 解决一个具体问题，团队经验不流失。

第三，它对模型升级有天然的适应性。 你只需要移除那些被模型自身能力覆盖的组件，然后针对新解锁的任务范围设计新的 Harness。

明天开始可以做的三件事

行动一：检查并优化你的 AGENTS.md

如果你在用 Claude Code、Cursor 或 Cline，检查代码仓库根目录下有没有 AGENTS.md 或 CLAUDE.md。如果有，检查每一条规则是否能溯源到一次真实失败的实例。删掉空的、泛泛的规则——比如”写高质量代码”——换成从错误中提炼的具体约束。

如果你还没有这个文件，现在创建一个。从你过去两周遇到的最烦人的 Agent 错误开始，加三条规则。每条规则控制在60字符以内，一条规则一件事。

行动二：为 Agent 配置 Hook

最基本的 Hook 配置：每次代码修改后自动运行类型检查和核心测试。成功静默，失败详细——如果检查通过，Agent 什么都不用管；如果失败，错误信息被注入上下文中，Agent 必须处理它才能继续。

这是最接近”免费午餐”的 Agent 配置改动。投入时间不超过30分钟。然后观察一个变化：Agent”声称完成但代码跑不通”的情况会大幅减少。

行动三：记录一次棘轮迭代

选一个 Agent 在过去一周里犯过的错误。不是那种模型自己犯傻的——是那种”如果配置里提前说了，Agent 就不会犯”的错误。把它写成一条规则，加到 AGENTS.md 里。

一个月后，如果你发现了8-10条这样的规则，你的 Agent 会比一个月前可靠得多。不需要换模型，不需要升级框架。只需要你做 Harness Engineering。

我们花了太多时间争论哪个模型最聪明。这场争论短期内不会有结论——模型的迭代速度太快了，今天的第一名明天可能就掉到队尾。

但有一件事是确定的：决定 Agent 能力天花板的，从来不是模型本身，而是你围绕模型建立的那套系统。

---

内容效果不满意？点此反馈