文章深入探讨了AI agent的工程化结构，介绍了Harness和Loop在其中的作用。Harness负责为AI agent提供可靠的运行环境，包括上下文、工具、权限、测试等，确保单次执行的安全与高效。而Loop则关注AI任务的持续改进，通过自动化任务发现、执行、评估和反馈，形成闭环，让AI agent越用越智能。文章强调，AI工程需要结合Harness和Loop，才能真正发挥AI agent的潜力，实现稳定、高效的智能应用。

---

▍先说一个容易踩的坑

现在讨论 Harness，很容易聊岔。有人会想到那家做软件交付平台的 Harness 公司，有人会想到安全带，有人会想到测试框架。本文讲的是第三种附近的东西：AI agent 的运行外壳，也就是模型之外那套让它知道该看什么、能用什么、错了怎么停下来的工程结构。

如果把大模型看成一个会干活但有点迷糊的新同事，Harness 就是工位、权限、任务单、测试、日志和旁边那个会拦一下的人。

没有 Harness 的 AI 工程，常见画面很熟：你把需求丢给模型，它热火朝天地改了十几个文件，最后测试没跑、规范没看、数据库迁移也顺手动了。你问它为什么，它还能写一段特别有礼貌的解释。

Loop Engineering 解决的是另一层麻烦。团队不可能永远靠一个人坐在屏幕前给 agent 打字、看结果、再打字。Loop 关心的是：任务从哪里来，谁分派，怎么并行，谁检查，失败案例怎样变成下一次的规则。

一句话先放在这里：Harness 管“这一次别翻车”，Loop 管“下一次别还在同一个地方翻车”。

Harness 管单次执行，Loop 管持续改进

▍Harness：给 agent 搭一个靠谱的施工现场

Martin Fowler 网站 2026 年 4 月 2 日发布的文章，把 harness 放在 coding agent 的语境里讲得很实在：要减少人类监督，就得提高我们对结果的信心。信心从哪里来？模型说“我已经完成了”不算数，真正有用的是可检查的反馈、上下文边界和自动化约束。

这听起来像老工程师的废话，但它特别有用。因为 AI 编程工具越强，事故越容易伪装成效率。以前一个初级工程师要花半天才能改坏的东西，现在 agent 五分钟就能改坏，还顺便写好提交说明。

Harness 的价值，是把“我相信它”改成“系统已经替我检查过一轮”。

它通常包括几类东西：项目上下文、代码检索、工具调用、权限控制、测试命令、静态检查、人工审批、日志记录。LangChain 在 2026 年 6 月 3 日的文章里也用了一个很直接的说法：agent = model + harness。模型会思考，harness 负责把它接到真实世界。

举个更土的例子。你让 agent 修改支付逻辑。好的 harness 会先把相关代码、接口约束、失败案例和测试命令交给它；会限制它不能碰生产密钥；会要求涉及扣款的改动必须人工确认；会把每次工具调用和测试结果记下来。

这时 agent 还是可能犯错。可它不再是在空地上乱跑。它被放进了一个施工现场：有围挡，有安全帽，有验收单。

▍Loop：不要再亲手喂每一口提示词

Loop Engineering 更像工作方式的变化。Addy Osmani 在 2026 年 6 月 7 日写过一篇文章，开头说得很直：loop engineering 是把你自己从“提示 agent 的那个人”换下来，改成设计一个系统，让系统去提示 agent。

以前我们和 coding agent 的关系像打乒乓球。你打一拍，它回一拍。你说“改这个 bug”，它改；你说“跑测试”，它跑；你说“再看一下边界条件”，它再看。效率确实比纯手写高，但人还被粘在流程里。

Loop 想做的事，是把这张乒乓球桌改成一条小型流水线：任务自动发现，agent 领取，执行后自检，失败进入队列，规则更新，下一轮继续。人仍然在，只是从“每一步都按按钮”的人，变成“设计循环、看仪表盘、处理例外”的人。

Loop 的关键不在于让 agent 永远跑，它真正要解决的是让系统记得发生过什么。

这也是很多团队卡住的地方。它们买了强模型，装了漂亮的 IDE 插件，甚至给每个项目都写了提示词模板。可失败案例没有沉淀，评测集没有更新，工具权限没人复盘。下一次，agent 还是像第一次来公司一样，礼貌、勤奋、没记性。

▍两者到底差在哪

可以用一个很简单的判断方法。

你问的是“这个 agent 怎么完成一次任务”，多半在谈 Harness。你问的是“这些任务怎样自动流转，并且越跑越好”，多半在谈 Loop。

Harness 更靠近运行时。它关心上下文、工具、检查、权限、可观察性。一个好的 harness 会让 agent 在单次任务中少猜一点，多验证一点，别一兴奋就越界。

Loop 更靠近组织流程。它关心任务来源、调度、并行、评测、记忆、复盘和下一次策略。一个好的 loop 会让团队不必靠某个高手每天手工喂提示词，也能稳定地把 AI 放进工程节奏里。

两者的关系也不复杂。Loop 通常跑在 Harness 之上。没有 Harness 的 Loop 很危险，因为你只是让一个不受控的 agent 自动跑得更久。没有 Loop 的 Harness 也有点可惜，因为每一次执行都可能不错，但经验没有变成系统能力。

▍别急着上大循环，先回答四个问题

问题	偏 Harness	偏 Loop
失败在哪里发生？	单次任务跑偏、误改文件、测试没过	同类失败反复出现，没人沉淀
谁在控制节奏？	人给 agent 一个任务，等它交付	系统自动发现、分派、检查任务
核心资产是什么？	上下文、工具、权限、日志、评测	任务队列、记忆、反馈数据、复盘机制
最怕什么？	agent 越权或胡乱提交	自动化把错误放大成批量事故

这张表的意思很直白：很多团队以为自己缺一个更聪明的模型，其实先缺的是一套更像样的执行环境；也有一些团队已经把单次执行管得不错，下一步才轮到 Loop。

▍OpenAI 的 Harness 实验为什么值得看

OpenAI 的 Harness Engineering 文章里有一个很有意思的信号：Codex 这类 coding agent 的表现，不只取决于模型本身，也取决于你把它放进怎样的 benchmark harness 里。换句话说，评测环境、任务描述、工具反馈和执行约束，都会影响最后结果。

这件事对普通团队也有启发。很多人评估 AI 编程工具，方式仍然很随意：丢一个需求，看它写得像不像。可真正决定能不能进生产的，常常是更无聊的部分：它能不能稳定跑测试？能不能读懂项目里的旧约束？能不能在不确定时停下来问？能不能把失败记录下来？

AI 工程会越来越像测试工程、平台工程和流程设计的混合体。模型负责能力上限，Harness 和 Loop 决定能力能不能落地。

▍一个团队今天可以怎么做

不用先写一套宏大的 AI 平台。真的不用。先挑一个低风险但高频的工程任务，比如修 lint、补单测、更新依赖、处理小型 bug、生成迁移说明。然后按下面这个顺序做。

第一，把项目约束写进仓库，别只写在某个人脑子里。例如：代码风格、测试命令、禁止修改的目录、提交前检查、常见坑。

第二，给 agent 一个最小 harness。让它每次必须读取任务说明、相关文件、测试命令和验收标准；危险动作需要人工确认；所有执行结果要留下日志。

第三，每周做一次失败复盘。别只骂模型。把失败拆成三类：上下文没给够、工具没接好、评测没覆盖。能写进 harness 的就写进去。

第四，再考虑 loop。当单次任务已经比较稳，再让系统自动发现任务、派发给 agent、跑验收、把结果放进待审队列。

这里有个小判断：如果你还不敢让 agent 自动提交 PR，就别急着让它通宵跑任务。先把安全带装好，再谈自动驾驶。

假如你从2026年开始学大模型，按这个步骤走准能稳步进阶。

接下来告诉你一条最快的邪修路线，

3个月即可成为模型大师，薪资直接起飞。

阶段1:大模型基础

阶段2:RAG应用开发工程

阶段3:大模型Agent应用架构

阶段4:大模型微调与私有化部署

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇

配套文档资源+全套AI 大模型 学习资料，朋友们如果需要可以微信扫描下方二维码免费领取【保证100%免费】👇👇