Prompt升职了，多亏了 Harness 和 Loop 工程

AI大模型工程师李工最近有点困惑。 他在某大厂做了三年AI工程，Prompt写得炉火纯青，few-shot、chain-of-thought、角色扮演这些技巧闭眼都能来。 但上个月leader找他谈话说要升级团队AI能力，让他研究怎么让Agent真正能独立跑起来，他发现自己最擅长的事情，好像突然不够用了。 "我不缺Prompt技巧，我缺的是怎么让这玩意儿自己转起来。" 2026年中，AI工程圈子里最热的讨论，已经从怎么写好一条Prompt变成了怎么设计一个能自己跑的Agent系统。 这个转变背后，其实是两套新范式的成熟：Harness工程和Loop工程。

Harness工程：给Agent造一个能干活的车间

先说个扎心的对比。

你写了一条Prompt：作为资深后端工程师，请review这段Python代码，遵循PEP8规范，检查潜在bug。

模型乖乖回了，review得有模有样。

但第二天，你发现代码里有个变量命名风格完全没按团队规范走。

你又加了一句：注意变量命名要符合团队的snake_case规范。

模型道歉了，改了。

第三天，你让它review一段新增的代码，这次它记住了命名规范，但测试覆盖率的检查没了——因为你的Prompt越来越长，上下文窗口塞不下了。

这不是Prompt写得不好，这是单次交互的无状态本质在作祟。

Prompt工程优化的是这一次，而真实生产环境需要的是每一次都一样靠谱。

Harness工程解决的就是这个问题。

Harness这个词，直译是马具——套在马身上用来传递力量和控制方向的那套装备。

放到AI工程里，它指的是Agent的运行外壳：工具有没有、约束有没有生效、出错了谁来把关。

有句话在圈子里传得很广：Agent = Model + Harness。

模型负责能做什么，Harness负责在什么边界内做、怎么做才不出错。这两样东西缺一不可。

一个没有Harness的Agent，就像一个有能力但没受过任何职业培训的员工——理论上什么都能干，实际上什么都不敢干，或者干出来的东西你不敢用。

Harness这个概念是 Mitchell Hashimoto 在2026年初正式提的。他是HashiCorp和Terraform的联合创始人，这人最擅长的就是把工程实践里的隐性知识显式化、抽象成可复用的框架。他提出Harness这个概念之后，OpenAI的Ryan Lopopolo跟进写了一篇文章，拿他们团队用Agent交付的一个百万行量级生产项目做案例，引发了圈内的广泛讨论。

Lopopolo说了一句很直接的话：当你的工程团队不再以写代码为主业，而是以设计环境、定义意图、搭建反馈回路为主业的时候，Harness就是那个核心产出。

Harness的核心结构分三层，理解了这三层，你就知道它到底在解决什么问题。

第一层是工具与执行层。

Agent要能干活，得先有手。

读写文件、调用bash、访问API、操作浏览器——这些工具的定义方式、参数约束、权限边界，全都在这一层。

工具定义越清晰，Agent行为越可预期。

你说帮我查一下这个函数的调用者，Agent能精准调用的前提是它知道有这么一个工具存在、知道怎么调用、知道返回什么格式。

这不是Prompt能解决的问题，这是工程问题！

第二层是控制与验证层，这是Harness区别于普通Prompt工程的关键。

一个经典场景：你在Prompt里写请遵守代码规范。

这有用吗？

有点用，但不多。

它的本质是依赖Agent的"自觉性"——它愿意遵守就遵守，心情不好可能就忘了。

你换一个做法：接一个 pre-commit hook，任何不符合规范的代码直接被阻断，连提交的机会都没有。

前者是概率性合规，后者是确定性约束。

Harness工程做的，就是把我希望它这样做变成它不可能那样做。

测试套件、类型检查、权限门控、审批流程——这些接进来之后，Agent犯的不是被降低概率的某类错误，而是那类错误在结构上就不可能发生。

第三层是持久化与状态层。

这是Harness支撑长周期任务的基础。

AI有个致命弱点：上下文窗口是有限的。

长任务跑到一半，上下文满了，之前的工作就丢失了。

更糟糕的是，Agent自己不知道丢了什么，它会继续自信地往下跑，产出一堆基于错误前提的代码。

Harness的解决办法是把状态外置：不依赖上下文窗口来记住进展，而是把中间结果写到文件、数据库、或者直接用Git管理。

Agent崩溃了，重启之后从上次保存的断点继续，而不是从零开始。

Stripe的Minions项目把这三层用到了极致。

他们在Ruby代码库里围绕LLM编码Agent构建了一套完整的Harness：Agent运行在隔离的devbox里，pre-push阶段自动跑Linter，从三百万个测试里精选CI子集执行，任何失败直接反馈给Agent让它自我纠正，通过了才提PR。

整个流程无人值守，每周自动合并超过一千个PR。

一千个PR，人工只负责最终审查。

这不是PPT里的未来，这是当下的现实。

但Harness有一个根本局限：它解决的是"Agent能不能正确地干活"，不解决"谁来给Agent分配活"。

搭好Harness之后，你得到的是一个训练有素的员工，但它仍然在等你下指令。告诉它干什么，它干完，等你下一条指令。

整个过程中，人仍然是那个不断喂Prompt的角色。

这就是接下来Loop工程要解决的问题。

Loop工程：让系统自己驱动自己

Loop工程的核心转变，用一句话说就是：

把工程师从逐轮提示Agent的人，替换成设计让系统自动提示Agent的系统的人。

这个转变的标志性事件，是OpenClaw创始人Peter Steinberger的一条推文。

他写了十二个字：You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

Claude Code的负责人Boris Cherny几乎同一时间在一次公开演讲里说了几乎一样的话：我现在不提示Claude了，我有一批Loop在跑，它们在提示Claude，决定接下来做什么。我的工作是写Loop。

两个人，不同背景，同一个判断。

这可不是啥巧合！

这是范式转移发生时，敏锐的从业者会产生的共识。

Loop比Harness高一层。

打个比方：Harness是工厂的生产线，Loop是工厂的大脑。

它决定什么时候启动生产线、生产什么、检验结果是否合格、不合格就返工重来。

理解Loop的关键，是搞清楚它的两个核心要素：触发器和可验证目标。

触发器是让循环启动的条件。

常见的有三种：

定时触发，比如每天凌晨两点自动跑依赖安全检查；事件触发，比如收到新PR就启动代码审查Agent；目标触发，比如设定"所有单元测试通过"作为终止条件，Agent一直跑到达标为止。

可验证目标是Loop能不能稳定运行的关键。

"所有CI通过"是好目标——可验证，信号明确，过了就是过了。

"帮我优化一下性能"是坏目标——Agent没法判断什么时候算做完，可能无限循环，也可能没做好就停了。

选错目标，是Loop失控最常见的原因。

Loop有五个核心构件，每个都关乎系统的稳定性。

自动化触发是发动机。

没有可靠的触发机制，Loop就退化成需要人手动运行的脚本，失去了自治的价值。

创作者与检验者必须分离。

这是Loop设计里最反直觉、也最重要的原则。

你不能让同一个Agent既干活又给自己打分。

那会产生"自我确认偏差"——Agent做出一个决定，然后立刻告诉自己"这个决定是对的"，错误永远得不到纠正。

正确的做法是独立的验证Agent负责评估结果，只有它通过，这一轮循环才算完成。这不是浪费资源，这是质量保障的基本前提。

连接器打通GitHub、Jira、Slack等外部系统。

Loop要能感知外部世界，才能自主发现工作、主动汇报进度、响应反馈。

没有连接器的Loop是个孤岛——它能干活，但它不知道干什么、干了谁来看。

隔离工作区支持多个Agent并行操作同一个代码库而互不干扰。

多个Agent同时改同一个文件是灾难，worktree隔离让并行成为可能。

持久化记忆让下一代循环能站在上一代的肩膀上。

Loop跑得越久，积累的失败案例、成功路径、上下文理解就越多。

每一轮循环不是从零开始，而是基于历史积累。

Steve Yegge的Gas Town项目是Loop工程的一个标杆案例。

他设计了一个"Mayor" Agent作为协调者，管理二三十个并行的Claude Code实例。

巡逻Agent持续扫描代码库的健康状态，发现问题就分配给工作Agent去修，完成后更新状态、通知相关人。状态存在Git里，崩溃重启后从断点续跑。

整个系统基本不需要人介入。

人只做两件事：审查PR，在系统卡住的时候去排查问题。

但必须正视的现实是，Loop的代价不低。

成本是第一道坎。

单Agent的Loop消耗的token大约是普通对话的四倍，多Agent并行系统大概是十五倍。

大规模运行的团队，月度账单轻松七位数起步。

适用性是第二道坎。

Loop不是万能药。

高频重复、结果可验证、工具链已接通——这三个条件缺一个，Loop就容易失控。

目标模糊的Loop可以在几小时内烧掉几百美元，同时产出一堆没人敢用的代码。

认知负债是第三道坎，也是最容易被忽视的。

当Loop跑得越来越好、工程师介入越来越少，你会慢慢失去对系统的理解——不知道它在干什么、为什么这样干、出了问题从哪里排查。

借用一个比喻：你把一辆车调成自动驾驶，不代表你可以在后座睡觉。关键路径上的人工审查，是那种没出事的时候觉得多余，出了事才发现致命的东西。

Prompt没死，它升职了

写到最后，想说一件有点讽刺的事。

越是追求自动化，越依赖那些需要人深度思考才能写出来的东西。

Loop不是Prompt的替代品，它是Prompt的容器。

所有能稳定运行的Loop，归根到底都锚定在某个人花时间亲手写下的文档上——一份CLAUDE.md、一组SKILL.md、一套系统提示、一段清晰可验证的目标描述。

Prompt从没离开这个房间，它只是升职了。

从台前到了幕后。从被逐字逐句优化的对象，变成了被架构设计所封装的东西。

所以真正的AI工程师要做的，是把执行环境建好、搭起自驱动的骨架、同时永远记得自己还握着方向盘——

那三样东西，Harness、Loop，以及最根本的、知道该让系统做什么的那份判断力。

前两样可以学，最后一样，只能在真实项目里慢慢熬。