Agent Loop / Loop Engineering / Harness Engineering：专业术语的理清与工程化落地指南

一句先入为主的判断：2026 年的 AI 工程圈，Prompt Engineering 已经退居二线，Harness 与 Loop 才是主战场。但这两个词经常被混着用——甚至连不少技术负责人也讲不清边界。本文用"赛车"隐喻把三者钉死：Agent Loop 是引擎，Loop Engineering 是引擎调校手册，Harness Engineering 是制造并驾驭整辆赛车的系统工程。

在这里插入图片描述

一、术语溯源：三个词分别在哪层？

先把时间线拉清楚，不然容易串戏：

代际 术语 大致时间点 解决的核心问题
第一代 Prompt Engineering 2023 让模型"听懂"这一次的话
第二代 Context Engineering 2025 在对的时候把对的信息喂进去
第三代 Harness Engineering 2026 初 给模型套马具，让它能"持续干对活"
第四代 Loop Engineering 2026 中 让系统自己形成自治闭环，人只设目标

数据源见 的四代演进梳理。下面逐个拆。

二、Agent Loop：赛车的"引擎"

2.1 定义与起源

Agent Loop 是 AI 智能体的核心执行循环，也是 ReAct（Reasoning + Acting, Yao et al. 2022）范式在工程层的落地。如果说 ChatBot 是"文本生成器"，Agent 之所以是"任务执行者"，全靠这个循环在心跳。

ReAct 原版的三元组是 Thought → Action → Observation，工程化后一般展开为五阶段：

Receive（收请求）
  → Evaluate（LLM 判状态、决定下一步）
    → Execute（调工具）
      → Collect（拿 Observation）
        → 循环 or 终止

2.2 生产级实现的两个参照

  • Claude Agent SDK（Anthropic, 2025 末）：把"Claude Code"升级为通用 Agent 框架，一个 Turn = 一次 “LLM 输出 → 工具执行 → 结果反馈”，多 Turn 串成任务。
  • OpenAI Agents SDK：类似语义，但更强调多 Agent 编排下的 Loop 扩展。
  • 开源实现参考 harness9 的 AgentEngine：阻塞式 / 流式两种 ReAct 主循环，LLMProvider + Registry（工具注册）+ Env 三层解耦。

2.3 引擎层的真问题

跑通一个 ReAct Loop 只要几十行 Python，但生产环境的坑全在 Loop 之外：

  • 上下文窗口管理：Turn 数一多，System Prompt + 工具定义 + 每轮 I/O 都在吃 token，要做压缩（compaction）和分阶段暴露（progressive disclosure）
  • 输出不稳定性：模型不如程序稳定，JSON 缺括号、工具名拼错是常态，得加输出校验 + 自动重试 + 格式修复
  • 终止条件与安全带：最大循环次数、工具白名单、Token 成本上限，否则 Agent 会在错误路径上"无限自嗨"

💡 引擎本身不难造，难的是让引擎在真实路况下不爆缸。

三、Loop Engineering：引擎调校手册

3.1 这个词怎么火的

2026 年 6 月初，开源 Agent 项目 OpenClaw 作者 Peter Steinberger 发推：「开发者不该继续直接写 Prompt，而应该设计 Loop 来 Prompt Agent。」随后谷歌核心工程师 Addy Osmani 撰文跟进，正式定名 Loop Engineering。

3.2 严谨定义

Loop Engineering = 设计一套自动化的、具备递归目标的闭环外壳（System Loop），把开发者从"手动监督 Agent"里解放出来。人只定义终极目标和终止条件，由外部循环程序根据代码/环境反馈，自动、连续地向内部 Agent 动态派发 Prompt、捕获报错、验证结果，直到任务完成。

3.3 它和 Harness 的边界在哪（关键）

这是最容易混的地方，腾讯云那篇讲得最清楚：

  • Harness 关心：Agent 拿到任务后这一次怎么执行——上下文怎么组、工具怎么曝、沙箱怎么隔、权限怎么控、失败后怎么恢
  • Loop 关心：Agent 完成一次执行后系统怎么走——结果过了是否生成 PR？挂了是否重试？连挂是否交人？任务池下一项是否起新 Agent？旧状态带不带下轮？

Harness 像一台可靠的加工设备，Loop 像一条小型生产线。

更进一步的论断来自 的批判性研究：Loop Engineering 是 Harness Engineering 的子集——Loop 管的是"多次执行间的流转"，而 Harness 包住了 Loop 本身 + 模型外的全部确定性控制。两者关系是包含。

3.4 调校手册具体调什么

落到代码层面，Loop Engineering 的"调校项"包括：

  • 递归目标拆解：把"修复这个 repo 的所有漏洞"拆成可验收的子项队列
  • 动态 Prompt 派发：不写死 Prompt，Loop 会根据上一轮 Observation 拼下一轮的 System Prompt
  • 验证—重试策略：断言失败 → 自动重试（指数退避）vs 换工具 vs 交人
  • 状态继承规则：跨 Turn / 跨 Task 的 context 哪些带、哪些丢
  • 终止条件设计：max_iterations、cost_cap、human_in_the_loop 触发阈值

四、Harness Engineering：整辆赛车的系统工程

4.1 定义与公式

Agent = Model + Harness

Harness Engineering 是 2026 初随 LangChain / OpenAI 推企业级 Agent 落地时确立的范式。硅谷那句流行语：「If you’re not the model, you’re the harness.」

Harness 包含模型以外的一切：

  • 内层（贴近模型）：版本化 System Prompt、动态上下文组装、工具权限白名单、输出格式校验、自动重试、高危拦截
  • 外层（生命周期）：任务路由、跨会话记忆、日志监控、人机审批闸门、多 Agent 分工
  • 基础设施：代码沙箱、虚拟文件系统、网络隔离
  • 确定性中间件：Linter、上下文压缩、自我验证钩子

4.2 三大支柱（来自 NxCode 的提法）

  1. 上下文管理：静态（AGENTS.md、API 契约）+ 动态（CI 失败堆栈实时注入）+ 压缩 + 分阶段暴露
  2. 约束即生产力：越严格的约束 AI 收敛越快—— paradox，但被 Codex / Claude Code 反复验证
  3. 信号纯度与 GC：AI 会模仿代码库里的"先例"（包括坏代码），Harness 必须定期跑清理智能体维持信号质量

4.3 一个被低估的原则：产验分离

Anthropic 在 Harness design for long-running application development 里提了三角分工：

  • Planner：把模糊需求扩成完整 spec
  • Generator：逐步实现
  • Evaluator：像 QA 一样真实测试（操作页面、看交互、查运行结果）

⚠️ 别让一个 Agent 既当运动员又当裁判。Evaluator 必须能摸到真实世界，否则闭环是假的。

OpenAI Codex 那个百万行项目人类几乎零手写的实践告诉我们：Agent 反复失败时，工程师不该再调 Prompt 或换模型，而该问「环境里缺了什么能力」——然后把那能力补进 Harness。

4.4 国内大厂的实证

  • 百度 DuMate：内置安全沙箱 + 高危拦截，Harness 框架让大模型自主调 Word/Excel/PPT
  • 字节 Arkclaw：字节版"龙虾"，框架与模型趋同进化
  • 腾讯汤道生表态：同样模型能力下，Harness 设计直接决定实际效果与 Token 成本

德勤《2026 企业 AI 现状》：80% 企业部署了 AI 工具，但仅 15% 能规模化产生显著商业价值——Harness 想填的就是"能用 → 好用/可控/省钱"这道鸿沟。

五、回到赛车隐喻：三者怎么拼成一辆车

层级 术语 赛车隐喻 回答的问题
L1 Agent Loop 引擎（ReAct heartbeat） 单圈内：Thought → Action → Observation 怎么转起来
L2 Loop Engineering 引擎调校手册 多圈间：目标怎么拆、失败怎么重试、状态怎么带、何时交人
L3 Harness Engineering 整车系统工程（底盘+车身+电控+赛道） 车外一切：沙箱、工具、权限、eval、Planner-Generator-Evaluator、日志、多 Agent 协同

再叠加 的另一版辅喻帮助交叉理解：

Harness 是加工设备，Loop 是生产线。设备决定单件能不能做出来，产线决定批量能不能跑起来。

而 Loop 是 Harness 的子集——这一点 的论证值得记下来：Harness 包住了"模型外全部确定性控制"，Loop 只是其中管"多次执行流转"的那一块。把 Loop 单独拎出来喊 Engineering，是因为 2026 年大家发现流转层的问题已经复杂到值得单独立派了。

六、应用场景：企业落地该怎么选

应用场景不都需要三层全上，给一个梯度判断：

🔧 场景 A：单次工具调用 / ChatBI / 客服问答

  • 有 ReAct Loop 就够了，Prompt + Context 基本能覆盖
  • 不必上完整 Harness，套个工具白名单 + 输出校验即可

🏭 场景 B：代码生成 / 内部自动化 / 数据管线

  • Harness 必建：AGENTS.md（地图）+ spec（目标）+ eval（验收）三件套
  • Planner-Generator-Evaluator 三角分工
  • 沙箱 + Linter + CI 拦截

🚀 场景 C：长任务 / 多 Agent 协作 / 自治系统

  • Harness 打底 + Loop Engineering 上手
  • 任务队列 + 递归目标 + 自动重试 + human-in-the-loop 闸门
  • 参考 OpenClaw / Claude Agent SDK / OpenAI Codex 模式

七、发展前景：接下来 12-18 个月会怎么走

把几篇材料的共识揉一下：

  1. Harness 会成为 AI 团队的"核心 IP"。模型能力趋同后，竞争维度从"用哪个模型"切到"谁的 Harness 更轻更稳"——百度、字节、腾讯已经全线押注。
  2. Loop Engineering 会从"黑话"沉淀为"框架特性"。Claude Agent SDK、OpenAI Agents SDK、LangGraph 这类编排层，接下来 1-2 个版本大概率会把"递归目标 / 自动验证重试 / 产验分离"做成一等公民。
  3. 工程师职能的再定义。传统"写代码 → 调代码 → Review 代码"会迁移到"设计 Harness → 调试 Agent 行为 → 设计自动化验证"。不会写 Harness 的工程师，溢价会掉。
  4. Eval 是下一个战场。Planner-Generator-Evaluator 里，Evaluator 能摸真实环境这一条，会催生一批"Agent 测试基础设施"创业公司——类似 2010 年代的 CI/CD 赛道。

八、给技术负责人的三句话

第一，Prompt 决定上限，Harness 决定下限——项目不稳先别换模型，先看 AGENTS.md / spec / 验收标准缺哪样。

第二，Loop 并非定时任务，Loop “跨多次 Agent 执行的生命周期调度”——能把这块抽象清楚的架构师，现在稀缺。

第三，2026 年还死磕 Prompt 的团队，已经在和 2024 年的自己竞争；真正在和同行竞争的是 Harness + Loop 的工程化深度。

延伸阅读（按优先级）

  1. Addy Osmani 关于 Loop Engineering 的原文（ 有引述）
  2. Anthropic Harness design for long-running application development（Planner-Generator-Evaluator 三角出处）
  3. harness9 的 Agent Loop 实现（，可作为自己撸 ReAct 引擎的参照）
  4. 德勤《2026 企业 AI 现状》——Harness 商业价值的宏观背书

自研框架的好处是不用迁就 LangGraph / OpenAI Agents SDK 的抽象，坏处是所有"框架帮你兜底"的事都得自己造。下面这份清单是按你团队明天能拆 Jira ticket 的粒度写的，分两层：Harness MVP（单次执行内的确定性外壳）→ Loop 调校（多次执行间的流转调度）。P0 是先止血项，P1 是两周内能补齐的，P2 是长任务 / 多 Agent 才需要。

一、Harness 最小可行清单（自研栈版）

先给一句定位：Harness = ReAct Loop 外面套的那层"确定性控制壳"，包住模型之外的全部工程设施。Anthropic 两篇官方 harness 笔记（2025.11 Effective harnesses for long-running agents + 2026.3 Harness design for long-running application development）是这份清单的权威锚点。

P0｜跑起来不掉链子的 6 个模块

对照 的最小可用 Harness 5+1 结构，自研建议这样拆：

模块 职责 自研落地提示
Context Builder 拼 System Prompt：静态（AGENTS.md / 项目规则）+ 动态（最近会话 / 工具定义）+ 压缩策略 AGENTS.md 压到 100 行内，做目录指针而非说明书
Tool Registry 工具白名单注册、schema 校验、权限标签 先只放文件读/写/命令执行三个原子工具，别一上来 MCP 全开
Permission Engine allow / ask / deny 三级判断，按路径+工具+操作三维鉴权 写操作默认 ask，CI 环境可降为 allow 但需审计
Executor 调 LLM + 执行工具调用 + 返回结构化结果 这里就要埋输出格式校验 + JSON 修复 + 自动重试
Session Store 每轮输入/工具调用/输出/结论落盘 后面 Loop 层要靠它做状态外置
Verifier 配置测试 / lint / 自定义验证命令 这是 Harness 里最容易被省掉、但最不能省的一项

这 6 个模块齐了，你的自研 Agent 就已经能处理"代码库内任务"这类基础场景，不用急着上 MCP / sub-agent / 沙箱远程执行。

P1｜生产级 Harness 补齐项（团队/企业环境必做）

从单人玩到团队协作， 列的这几个要跟上：

  • 沙箱执行：不可信代码 / 浏览器 / 外部工具走隔离环境，别让 Agent 直接在你 CI runner 上 rm -rf
  • 事件流统一：模型输出、工具调用、审批、日志、artifact 走同一套流式返回协议（SSE 或 WebSocket）
  • 策略中心：组织级 allow/ask/deny、路径规则、工具规则，别散落在各 AGENTS.md 里
  • 成本控制：token 预算、工具耗时、并发上限、单任务 timeout
  • 审计与回放：能回答"谁让 Agent 做了什么、结果是什么"——这条合规场景刚需

P2｜长任务专用（参考 Anthropic 官方 harness design）

如果你的 Agent 要跑 30 分钟以上、跨多个 context window，上面那套会不够，得加 Anthropic 那套 long-running harness 的件：

1. Initializer + Coding Agent 双角色

  • Initializer（仅第一趟）：写 feature list JSON、init.sh、progress file、首 commit
  • Coding Agent（后续每趟）：增量推进 + 留结构化 handoff

2. Context Compaction vs Context Reset 两条策略

  • Compaction：同子任务内，摘要保留"目标+已完成+失败路径+下一步"，丢推理链和重复日志
  • Reset：阶段切换 / 上下文污染严重 / 角色切换时，直接清上下文，靠 handoff artifact 接棒

3. Handoff Artifact 七件套

Goal:        当前任务是什么
Constraints: 不可违反的约束
Completed:   已完成哪些
Failed:      哪些尝试失败了 + 为什么
Workspace:   文件变化清单
Verification: 跑过哪些验证命令 + 结果
Next Step:   下一轮从哪开始

Tip：Harness 自动生成初稿 → Agent 补解释，纯手写漏文件变化，纯自动缺判断理由。

4. Planner / Generator / Evaluator 三角

  • Generator 写完 ≠ 完成，Evaluator 必须独立（单独 Agent 或确定性脚本），否则自我评分必然虚高——主观任务（UI/设计）尤其严重

一个 TypeScript monorepo 的实操样板（ 给的配置，可直接抄）

  • Prompt 层：AGENTS.md ≤ 60 行只放通用约束；SKILL.md 按需加载，别提前塞
  • Context 层：MCP 同时只激活 2-3 个，其余关掉；git 当 Agent 原生记忆（小而语义明确的 commit 是卫生习惯）
  • Hook 层（这是自研最容易忽略的一层）：
    • Pre-commit：biome + typecheck，静默成功失败才报
    • PostToolUse：每次文件写入后 surface linter 错误
    • Stop hook：跑变更文件的测试，失败打回
    • Coverage hook：覆盖率下降告警
    • Loop detection：同一文件编辑 3+ 次触发告警
    • Escalation：阻塞 3+ 个 tool call 停掉并 ask human

⚠️ Hook 层是 Harness 的"确定性中间件"，比换模型管用。自研团队如果只撸 Loop 不撸 Hook，长任务必翻车。

二、Loop Engineering 调校 Checklist

Loop 层管的是"多次 Agent 执行之间怎么流转"。Addy Osmani 定名的五原语 + CodeBuddy 那篇的双层循环，拆成 checklist 如下：

🔧 Outer Loop（编排层）调校项

□ 递归目标（Recursive Goal）是否可验证

  • 反例：“把登录修好” → 正例：“OAuth callback 在缺少 state 时返回 400 而非 500，且新增 2 个单元测试通过”
  • 不可验证 = Agent 不知道何时停 = 无限自嗨

□ Find Work（找活）机制

  • 扫 issue / CI 报错 / 未通过测试，还是靠人喂？
  • 自研建议：任务队列（Redis / pg） + 优先级，别让 Agent 自己 ls 猜

□ 决定下一步的预算/停止条件

  • max_iterations、cost_cap、连续 N 次验证失败 → 交人
  • 不设这条，Loop 就是"更快地自动化错误"

□ Human-in-the-Loop 闸门

  • 高危操作（main 分支 push / 删数据 / 生产部署）必须 ask
  • 连续失败 ≥ 3 次、置信度低于阈值、跨 session 恢复失败 → 自动交人

🔩 Inner Loop（执行层，即 ReAct）调校项

□ Verify / Check 是 Loop 的灵魂

  • 确定性验证优先：测试 / 类型检查 / lint / 截图比对
  • LLM-as-Judge 只用于模糊规则，且有延迟、不够稳
  • 代码示例（ 给的朴素描摹版）：
def run_verification(commands: list[list[str]]) -> bool:
    for cmd in commands:
        r = subprocess.run(cmd, text=True, capture_output=True)
        if r.returncode != 0:
            print(r.stdout, r.stderr)
            return False
    return True

ok = run_verification([
    ["python", "-m", "pytest"],
    ["python", "-m", "ruff", "check", "."],
])

□ 状态外置哲学

  • 所有状态存外部（文件 / DB / STATE.md / LOOP-STATE.json），不存模型上下文窗口
  • 每次迭代从干净上下文起步，基于持久化内容工作 → 彻底解决遗忘 + 漂移 + 压缩失真

□ Memory 三项必答

  • 当前在做什么？
  • 上次试了什么、结果如何？
  • 哪些需要人类介入？

📊 Loop 健康度自查（每周过一次）

指标 红线
单 Loop 平均迭代次数 > 10 次还没过 Verifier → 目标拆得有问题
Verifier 通过率 < 60% → 验收条件太严或 Generator 没拿到足够上下文
连续失败交人率 > 30% → Escalation 阈值或 Hook 层没拦住
Token / 轮次成本方差 同一类任务差 3x 以上 → 上下文组装策略不一致

三、给你的自研栈递进建议

不要一上来 All in。按这个顺序铺，每层跑稳再下一层：

  1. ReAct Loop 先跑通：Thought→Action→Observation 五阶段能串起来，LLMProvider + ToolRegistry + Executor 三层解耦（参考 harness9 那种实现）
  2. 套最小 Harness P0：ContextBuilder / ToolRegistry / Permission / Executor / SessionStore / Verifier 六个模块 + Hook 链（PostToolUse / Stop / Escalation）
  3. 补长任务件：Initializer+Coding Agent、compaction vs reset 策略、handoff artifact、Planner-Generator-Evaluator 三角
  4. 再叠 Loop 层：递归目标 + 状态外置 + 验证器 + 终止条件 + human-in-the-loop 闸门
  5. 最后才上多 Agent / 编排：sub-agent 隔离、worktree、MCP 全开、跨 Agent 评测

💡 一个反模式提醒：很多自研团队第 1 步还没稳就跳第 5 步，结果是"多 Agent 跑得欢，单 Agent 还在裸奔"——Hook 层没拦、Verifier 没接、handoff 没结构，长任务必炸。

（注：文档部分内容可能由 AI 生成）

# 人工智能 # 软件工程 # python # 自然语言处理 # AI作画
Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

AI对话告别纯文本局限：开源TokUI，补齐大模型流式输出

当下大模型、AI Agent 已经成为企业数字化转型的核心工具，向量空间 JBoltAI 作为深耕 Java 生态的企业级 AI 开发框架，在落地智能问答、智能问数、多任务智能体等 AIGS 场景的过程中，发现一个长期无解的行业矛盾：大模型的底层运行逻辑是逐 Token 持续流式输出，但行业内仅有的三类 UI 承载方案 ——Markdown、JSON、HTML，全部无法适配这种原生特性，最终导致

avatar CSDN-OPC开发者社区
cover

Agent Harness：2026 年 AI 工程最重要的概念，一篇文章讲透

avatar CSDN-OPC开发者社区
cover

从国产替代到 Data + AI 国产数据库下一步该怎么走？

avatar CSDN-OPC开发者社区