前言：为什么需要一张「概念地图」
过去三年，AI 领域的词汇膨胀速度远超技术本身的变化速度。今天大家都在聊 openclaw，明天又冒出 Harness Engineering，后天 Loop Engineering 的帖子就刷满了时间线。
如果你只是偶尔用 ChatGPT 写邮件，这些名词可能显得多余。但如果你已经开始用 Cursor、Claude Code、Codex 或 OpenClaw 做真正的工程工作，你会发现：同一件事，不同社区用了完全不同的语言来描述。
- 有人管这叫「提示词工程」
- 有人管这叫「上下文工程」
- 有人管这叫「工作流编排」
- 有人管这叫「Harness 工程」
- 还有人管这叫「Loop 工程」
它们真的是四代完全不同的技术吗？还是同一套东西被不断重新命名？
这篇文章试图做一件事：把这条演进线梳理清楚——从基础的 LLM，到 Agent，到 Workflow 编排（含那一波「拖节点连线」工具的兴衰与 reposition），到 Skill / MCP / CLI 等周边概念，再到 OpenClaw 代表的「个人 Agent 运行时」，再到 Harness Engineering 和 Loop Engineering 这两套 2026 年最热的叙事。
读完你应该能回答三个问题：
**1. 这些概念各自解决什么问题？
- 它们之间是替代关系还是嵌套关系？
- 哪些是真正值得投入的工程能力，哪些只是营销词汇？**
@[TOC]
第一章：从 LLM 到 Agent——一次范式跃迁
1.1 LLM 是什么：一个「只会说话」的函数
大语言模型（Large Language Model）本质上是一个概率性的文本生成器。你给它一段输入（prompt），它根据训练数据中的统计规律，预测下一段最可能的输出。
在 2022–2023 年的 ChatGPT 时代，主流用法是：
用户提问 → 模型回答 → 结束
这叫 one-shot（单次调用） 模式。它的天花板很明显：
- 模型不知道你电脑上的文件
- 模型不能执行命令
- 模型不能访问实时数据
- 模型一旦答错，没有自我纠正机制
你可以通过更好的 prompt 提升输出质量，但模型仍然被困在聊天窗口里。
1.2 Agent 是什么：模型 + 行动能力 + 循环
Agent（智能体） 的核心定义可以压缩成一句话：
Agent = 能在环境中采取行动、观察结果、并据此决定下一步行动的 LLM 系统。
这个定义来自 2022 年 Princeton 和 Google 提出的 ReAct（Reason + Act）模式：模型不再一次性给出最终答案，而是交替进行「推理」和「行动」：
思考 → 选择工具 → 执行 → 观察结果 → 再思考 → … → 达成目标
用伪代码表示：
state = init(goal) for step in range(MAX_STEPS): thought = model.reason(state) action = model.choose_tool(state) result = environment.execute(action) state = update(state, thought, action, result) if goal_achieved(state): break
这就是 Agent 与 LLM 的本质区别：LLM 回答一次，Agent 循环多次。
2023–2024 年，OpenAI 的 Function Calling、Anthropic 的 Tool Use 把这套模式产品化。模型开始能「调用工具」——读文件、搜网页、执行 SQL。但工具调用本身还不够，你还需要一个外层运行时来：
- 解析模型的 tool call 请求
- 真正执行工具
- 把结果塞回上下文
- 判断任务是否完成
- 决定是否继续循环
这个外层运行时，后来有了一个名字：Harness（挽具 / 挽具工程）。我们后面会详细讲。
1.3 Agent 不是魔法：三个常见误解
| 误解 | 事实 |
| Agent = 更聪明的模型 | 同一个模型，有无 Harness 表现可以天差地别 |
| Agent = 自主意识 | Agent 只是在循环里执行你设计的策略 |
| 买了 Agent 产品就省事了 | 可靠性、成本、安全，大量工作仍在 Harness 层 |
第二章：Agent 生态的关键零件
在深入 OpenClaw、Workflow 工具链和 Harness / Loop Engineering 之前，先把周边概念对齐。它们不是互相竞争的技术，而是组装一个可用 Agent 的不同零件。
2.1 CLI：通用行动接口
CLI（Command Line Interface） 是 Agent 最重要的「手」之一。
早期 Agent 框架倾向于为每种操作预置专用工具：读文件工具、写文件工具、搜索工具……但很快大家发现：Bash 本身就是一个万能工具。
Simon Willison 有一个精辟的观察：大多数工程任务，归根结底就是几个精心选择的 shell 命令。给 Agent 一个终端，它就能：
git diff看变更npm test跑测试curl调 APIgrep搜代码
Cursor、Claude Code、Codex 都把终端执行作为一等公民。这不是偷懒，而是承认了一个事实：预置工具永远追不上真实世界的操作空间，通用 CLI 才是扩展性最好的接口。
当然，CLI 也带来了最大的安全风险——Agent 可以执行 rm -rf。所以 Harness 必须配套沙箱、命令白名单、权限模型。
2.2 MCP：标准化的「插头」
MCP（Model Context Protocol） 是 Anthropic 在 2024 年底推出的开放协议，2025–2026 年迅速成为事实标准。
可以把它理解成 AI 世界的 USB-C：
┌─────────────┐ MCP 协议 ┌─────────────┐ │ AI Client │ ◄──────────────► │ MCP Server │ │ (Cursor等) │ │ (数据库/API) │ └─────────────┘ └─────────────┘
MCP 定义了三类核心原语：
| 原语 | 作用 | 例子 |
| Tools | 可执行的操作 | 查数据库、发 Slack 消息 |
| Resources | 只读数据源 | 文件内容、配置信息 |
| Prompts | 可复用的提示模板 | 代码审查模板 |
通信基于 JSON-RPC 2.0。客户端通过 tools/list 发现可用工具，通过 tools/call 调用。
为什么 MCP 重要？ 在它之前，每个 AI 产品都有自己的插件格式。你为一个 IDE 写的集成，换到另一个 IDE 就要重写。MCP 让「写一次，到处用」成为可能——同一个 Postgres MCP Server，Cursor、Claude Desktop、OpenClaw 都能接。
2.3 Skills：可复用的「操作手册」
Skill 这个概念在不同产品里名字略有差异，但本质相同：一段结构化的 Markdown 指令，教 Agent 在特定场景下该怎么做。
以 Cursor 为例，Skill 通常是一个 SKILL.md 文件，包含：
- 触发条件（什么时候该用这个 skill）
- 分步工作流
- 注意事项和约束
- 示例命令
--- name: deploy-check description: 部署前检查清单 --- # Deploy Check 1. 运行 `npm test` 2. 检查环境变量是否齐全 3. ...
Skill 与 Rules 的区别：
| Rules | Skills | |
| 加载方式 | 静态，每次对话都注入 | 动态，Agent 按需调用 |
| 粒度 | 全局行为约束 | 特定任务工作流 |
| 类比 | 公司规章制度 | 岗位操作手册 |
OpenClaw 把 Skill 生态做到了极端——ClawHub 上有数千个社区贡献的 Skill，从发邮件到控智能家居。这也是它安全争议的主要来源（后面会讲）。
2.4 Rules / AGENTS.md / CLAUDE.md：持久记忆层
另一组关键文件是项目级上下文：
- Cursor：
.cursor/rules/*.mdc - Claude Code：
CLAUDE.md、AGENTS.md - OpenClaw：
SOUL.md（人格）、MEMORY.md（记忆）、AGENTS.md（行为约束）
它们的共同逻辑是：把 Agent 每次会话都会忘记的东西，写到磁盘上，让 Harness 在启动时自动注入。
这是「上下文工程」最朴素的实现——不靠微调模型，靠文件系统做跨会话记忆。
2.5 一张零件关系图
┌──────────────────────────────────┐ │ Harness（运行时） │ │ ┌────────────────────────────┐ │ │ │ Agent Loop │ │ │ │ ┌──────┐ ┌──────────┐ │ │ │ │ │ LLM │───►│ Tool Exec │ │ │ │ │ └──────┘ └──────────┘ │ │ │ └────────────────────────────┘ │ │ │ │ Rules / Skills / AGENTS.md │ │ MCP Servers │ │ CLI / Sandbox │ │ Memory / Context Management │ └──────────────────────────────────┘
第三章：Workflow——从「拖线搭流程」到 Agent 时代的编排层
在聊 OpenClaw 和 Harness 之前，有必要单独讲一章 Workflow（工作流）。因为 2023–2024 年 Agent 爆火时，很多人第一次接触「让 AI 干活」，并不是通过 Cursor 或 Claude Code，而是通过画布上拖节点、用线连起来的低代码工具。
这一章回答两个问题：这类工具到底是什么？到了 2026 年，它们还活着吗，站在产业链的哪个位置？
3.1 Workflow 是什么：确定性管道 vs 自主循环
Workflow 在 AI 语境下，指把多个步骤按预定顺序（或条件分支）串联起来的执行图。核心特征是：路径在执行前 largely 可预见。
触发器 → 拉数据 → 清洗 → 调 LLM → 写回数据库 → 发通知
这和 Agent 的 ReAct 循环有本质区别：
| Workflow | Agent Loop | |
| 控制流 | 人（或编译器）预先画好 | 模型运行时动态决定 |
| 分支逻辑 | 显式 if/else 节点 | 模型根据观察结果即兴选择 |
| 适合任务 | 流程固定、步骤可枚举 | 目标清晰但路径不确定 |
| 失败模式 | 某个节点配置错了 | 模型在循环里空转或跑偏 |
| 可审计性 | 高——路径在图上是可见的 | 低——要靠 trace 回放 |
早期有一个常见误判：把 Workflow 当成 Agent 的「低配版」。更准确的说法是：Workflow 是 编排层（orchestration），Agent 是 推理层（reasoning）。生产系统里两者经常叠在一起，而不是二选一。
3.2 连线时代的三巨头画像
2023 年下半年到 2024 年，「连线搭 AI 应用」是绝对的流量中心。工具可以粗分三派：
派别 A：自动化集成（Automation）
代表：Zapier、Make（原 Integromat）、n8n
- 起源：IFTTT 的商务升级版，核心是「App A 发生某事 → 触发 App B 做某事」
- AI 化：2023 起陆续加入 OpenAI 节点、AI Agent 节点、向量检索节点
- 强项：接 SaaS、接 webhook、接数据库——集成密度极高
- 弱项：复杂推理、长链路状态管理、多 Agent 协作
n8n 是这一派里对开发者最友好的：开源、可自托管、2025 年后 AI 节点爆发式增长，到 2026 年已是很多团队默认的「集成神经系统」。
派别 B：LLM 应用搭建（LLM App Builder）
代表：Dify、Flowise、LangFlow、Coze（扣子）、FastGPT
- 起源：LangChain 概念太碎，有人把它做成可视化
- 典型画布：
输入 → Prompt 模板 → LLM → 输出解析 → 条件分支 → 工具调用 - 强项：RAG 知识库问答、内部工具原型、给业务方 demo
- 弱项：上线后需求一变，画布迅速长成意大利面；版本管理、测试、CI 都别扭
Dify 在中文圈影响力尤其大——一站式 RAG + 工作流 + 发布，很多团队「第一周用 Dify 搭了个知识库助手」。
派别 C：垂直领域工作流
代表：ComfyUI（图像生成）、部分 Stable Diffusion WebUI 插件生态
- 节点类型是「加载模型」「KSampler」「VAE 解码」，不是「调 GPT」
- 在 AIGC 圈依然是硬通货——精细控制生成管线，Agent 短期内替代不了
3.3 黄金年代：为什么「连线」当时那么火
几个因素叠加：
- LangChain 太难用：链、代理、记忆、回调嵌套在一起，新手看一眼
ConversationChain就想关 IDE - 低代码幻觉：「业务人员也能搭 AI」——对简单 RAG 问答确实成立
- Demo 极快：半小时连出一条「PDF 上传 → 切片 → 向量库 → 对话」，融资 PPT 好写
- 模型还不够强：GPT-3.5 时代，你把流程锁死反而更稳定；让模型自己决定下一步，经常翻车
那时候的技术叙事是：Prompt Engineering + Workflow = 应用。Agent 这个词在，但很多人实际搭的是「带 LLM 节点的 Zapier」。
3.4 裂痕：Workflow 工具撞上了 Agent 元年
2024 下半年到 2025，风向变了。
Coding Agent 崛起（Cursor、Claude Code、Windsurf、Codex）直接吃掉了一大块 use case：
- 以前：在 Flowise 里连一个「读代码库 → 总结」的 flow
- 现在：对 Cursor 说一句话，它自己 grep、读文件、总结——路径是运行时生成的，不需要你画
同时，框架层从「链」进化到「图」：
- LangChain 的线性
Chain不够表达循环和分支 - LangGraph（2024–2025，2025.10 达 1.0 stable）用代码定义有状态图：
State → Node → Conditional Edge → State - 工程师发现：复杂 Agent 逻辑用 Python/TypeScript 写比用鼠标拖更可控——可测试、可 diff、可 code review
视觉工作流工具的三重困境浮出水面：
| 困境 | 表现 |
| 可维护性 | 50 个节点的画布没人敢改，改一个牵一串 |
| 版本管理 | JSON 导出进 Git 是噩梦，merge conflict 看不懂 |
| 能力天花板 | 模型越强，预定义路径越显得多余；强模型 + 终端 > 弱模型 + 精致 flow |
社区里开始流传一种刻薄但部分成立的说法：「连线工具是 AI 时代的 Dreamweaver。」——能降低入门门槛，但严肃工程最终会回到代码。
3.5 2026 年的真实地位：没死，但换了赛道
连线工具没有消失。它们完成了一次 reposition，从「造 Agent 的主战场」退到「集成与胶水层」。
仍然强势的场景
1. 集成密集型自动化（n8n 的主场）
真实案例（Konverge AI 等交付团队的公开复盘）：一个报价系统，三分之二工作量是 Outlook、ERP、SharePoint、定价表对接，只有「匹配规格 + 生成报价」需要 Agent 推理。最终架构：
n8n 负责： ingestion → 解析 → 写回系统记录 → 人工审批节点 LangGraph 负责： 被 n8n 当作一个节点调用的「推理大脑」
九个工作日 demo 上线；后来加产品线，改 n8n flow 一个下午，不用重构 Agent。
2. 内部工具 / RAG 原型（Dify 的主场）
给销售搭知识库助手、给客服搭工单分类——需求稳定、用户非技术、要快速交付。Dify 的一键发布仍然比「从零写 Harness」快。
3. 运维与数据管道
定时拉数据、清洗、触发 LLM 批处理、写 Slack 通知——这是 cron + DAG，不是 Agent，但极适合 visual workflow。
4. AIGC 管线（ComfyUI 不动摇）
图像/视频生成的节点图和语言 Agent 是不同物种，ComfyUI 生态 2026 年依然繁荣。
明显失势的场景
- 「用画布搭一个 coding agent」 → 被 Cursor / Claude Code 碾压
- 复杂多 Agent 协作 + 长时状态 → 工程师转向 LangGraph / 自研 Harness
- 「业务人员完全自主维护 AI 应用」 → 承诺过度；稍有复杂度就需要工程师介入
一张 2026 年的分层图
┌─────────────────────────────────────────────────────────┐ │ 用户体验层：Chat / IDE / WhatsApp（OpenClaw Gateway） │ ├─────────────────────────────────────────────────────────┤ │ 推理层：Agent Loop + Harness（Cursor, LangGraph, …） │ ├─────────────────────────────────────────────────────────┤ │ 集成层：Visual Workflow（n8n, Zapier, Make） ◄── 连线工具的新主场 │ ├─────────────────────────────────────────────────────────┤ │ 连接器：MCP Servers, REST APIs, 数据库, SaaS │ └─────────────────────────────────────────────────────────┘
连线工具从「大脑」变成了「周围神经系统」。 这句话大概能概括它现在的地位。
3.6 Workflow 与 Harness / Loop 的关系
把前面几章的概念对齐：
- Workflow 节点图 = 外置的、可视化的、mostly 确定性的编排
- Harness = 包裹模型的完整运行时（含工具、记忆、规则、也可能含 workflow 触发器）
- Loop = Harness 内部的
while控制流，由模型驱动
一个成熟的 2026 生产栈经常是：
n8n（workflow：什么时候跑、接哪些系统） └─► 调用 LangGraph Agent（harness + loop：怎么推理、怎么验证） └─► 通过 MCP 访问业务数据
OpenClaw 则走了另一条路：不用画布，用 Markdown 文件 + Gateway + Heartbeat cron 做编排——本质仍是 workflow，只是 UI 从「节点图」变成了「文件 + 定时器」。
3.7 给选型者的一句话
| 你的需求 | 更可能的选择 |
| 接 10 个 SaaS，定时跑，业务规则常变 | n8n / Make |
| 快速搭 RAG 内部助手，非工程师维护 | Dify / Coze |
| 复杂 Agent 推理、要审计、要测试 | LangGraph / 代码 Harness |
| 个人 7×24 助手、消息渠道驱动 | OpenClaw |
| 写代码、改仓库、跑测试 | Cursor / Claude Code |
Workflow 工具没有输给 Agent——它们退到了更擅长的层。 以为拖条线就能取代工程的人失望了；懂得把 n8n 和 LangGraph 叠在一起的人，反而跑得更快。
第四章：OpenClaw——个人 Agent 运行时的样本
4.1 它是什么
OpenClaw 是奥地利开发者 Peter Steinberger 在 2025 年 11 月发布的开源项目（最初叫 Clawdbot，后改名 Moltbot，最终定名 OpenClaw）。到 2026 年中，它已成为 GitHub 上增长最快的 AI 项目之一，星标超过 30 万。
一句话概括：
OpenClaw 是一个自托管的个人 AI 助手运行时，让你通过 WhatsApp、Telegram、Slack、Discord 等日常聊天应用，与一个 7×24 在线的 Agent 对话。
它不是又一个 LangChain Demo，而是一个完整的 Gateway架构：
WhatsApp ──┐ Telegram ──┤ Discord ──┼──► Gateway ──► Agent Runtime ──► LLM (Claude/GPT/本地模型) Slack ──┤ │ iMessage ──┘ ▼ Workspace Files (SOUL.md, MEMORY.md, Skills)
4.2 核心设计：文件即记忆
OpenClaw 最聪明（也最「朴素」）的设计是：Agent 的「人格」「记忆」「技能」全部是 Markdown 文件。
| 文件 | 作用 |
SOUL.md |
Agent 的人格、语气、价值观 |
MEMORY.md |
跨会话持久记忆 |
HEARTBEAT.md |
定时自检任务清单 |
AGENTS.md |
行为约束与操作规范 |
skills/ |
可复用技能目录 |
每次 Agent 被唤醒，Gateway 从磁盘读取这些文件，拼装成 system prompt，发给 LLM。LLM 执行工具调用后，Gateway 把结果写回磁盘。
所谓「持久记忆」，本质上就是文件读写。所谓「主动性」，本质上就是 cron。
这不是贬低——恰恰相反，这种「用简单原语组合出复杂行为」的思路，是工程上最诚实的做法。
4.3 Heartbeat：让 Agent「主动」起来
传统 Chatbot 等人说话才回应。OpenClaw 通过 Heartbeat（心跳） 机制实现主动性：
- Gateway 每 30 分钟触发一次 Agent 运行
- Agent 读取
HEARTBEAT.md，检查是否有待办事项 - 无事则回复
HEARTBEAT_OK（被 Gateway 静默丢弃） - 有事则执行并通知用户
这让 Agent 从「你问我答」变成「它自己巡逻」。配合消息渠道集成，你可以收到「服务器 CPU 超 90% 了，我已经重启了服务」这类主动推送。
4.4 多 Agent 路由
OpenClaw 支持按渠道、按发送者、按工作区路由到不同 Agent 实例。每个 Agent 有独立的 workspace 和 session，互不干扰。这解决了「工作 Agent」和「生活 Agent」混在一起的隐私问题。
4.5 为什么 OpenClaw 爆火
几个因素叠加：
- 时机：2026 年市场已经准备好接受「个人 Agent」概念，不再觉得奇怪
- 渠道：不让你装新 App，直接在 WhatsApp 里聊——零切换成本
- 自托管：数据在自己机器上，对隐私敏感的用户有吸引力
- 模型无关：Claude、GPT、Gemini、Ollama 本地模型都能用
- 极简架构：懂 Markdown 就能定制 Agent，门槛极低
4.6 冷静看待：OpenClaw 的局限
作为样本极具价值，但作为生产系统需要谨慎：
- 安全风险：ClawHub 上数千个社区 Skill，已有多起 prompt injection、凭证泄露事件（Cisco、Snyk 均有审计报告）
- 运维成本：自托管意味着你自己负责更新、备份、监控
- 并非新范式：文件记忆 + cron + 消息网关，都是成熟技术的新组合
结论：OpenClaw 的价值在于把 Agent 运行时做成了消费级产品，让「个人 AI 助手」从概念变成可安装的东西。它的架构模式（文件即记忆、心跳即主动、Gateway 即渠道抽象）正在成为行业参考实现。
第五章：Harness Engineering——真正值得投入的工程学科
5.1 一个等式
2026 年初，Viv Trivedy 提出了一个简洁的定义，随后被 Addy Osmani、HumanLayer、Anthropic 等广泛引用：
Agent = Model + Harness
Harness（挽具） 是模型之外的一切：
- System prompt、Rules、Skills、AGENTS.md
- 工具定义、MCP Server、CLI 沙箱
- 子 Agent 编排、模型路由
- 上下文管理（压缩、摘要、检索）
- 钩子（hooks）、中间件、确定性检查
- 可观测性（日志、trace、成本计量）
- 错误恢复与人工升级路径
Cursor 官方博客也确认了这一点：Cursor 的 Agent Harness 由 Instructions（指令）+ Tools（工具）+ Model（模型） 三部分组成，且 Cursor 会针对每个前沿模型单独调优指令和工具描述。
5.2 为什么 Harness 比模型重要
有一个反复被验证的数据点：
在 Terminal Bench 2.0 基准测试中，同一个 Claude Opus 模型，在 Claude Code 里跑和在自定义 Harness 里跑，分数可以差出一个量级。有团队仅通过优化 Harness（不改模型），就从 Top 30 冲进 Top 5。
原因很直观：
- 模型是通用的，你的代码库是特定的
- 模型不知道你的命名规范、测试策略、部署流程
- 模型看不到它没被告知的信息
- 模型倾向于「看起来完成了」而不是「真的完成了」
Harness 填补的，正是「模型能力」与「任务需求」之间的鸿沟。
5.3 「Skill Issue」思维
HumanLayer 有一个刺耳但准确的说法：
大多数 Agent 失败不是 model problem，是 configuration problem。
Harness Engineering 的核心心态是 Ratchet：
Agent 犯错 → 分析原因 → 把修复写进 Harness → 永远不再犯
具体做法：
| Agent 犯的错 | Harness 修复 |
| 不知道项目用 pnpm 不用 npm | 写入 AGENTS.md |
| 注释掉失败的测试 | pre-commit hook 拦截 .skip( |
| 40 步任务中途迷失 | 拆成 planner + executor 子 Agent |
| 改完代码不跑测试 | 在 loop 里强制 test back-pressure |
| 上下文爆炸后胡言乱语 | 加入 compaction 策略 |
每一条 AGENTS.md 的规则，都应该能追溯到一次真实的失败。好的 Harness 是失败史的文件化。
5.4 Inner Harness vs Outer Harness
Talk Think Do 的指南做了一个有用区分：
| Inner Harness | Outer Harness | |
| 谁构建 | 工具厂商（Cursor、Anthropic） | 你 / 你的团队 |
| 例子 | Agent 模式、代码索引、diff 审查 UI | AGENTS.md、MCP Server、CI 传感器 |
| 可定制性 | 低 | 高 |
| 可移植性 | 绑定产品 | 跨产品 |
工程建议：优先投资 Outer Harness 的可移植层（AGENTS.md、MCP、CI 集成），再用产品特定的 Rules 做快速迭代。
5.5 Harness 的关键组件（从行为反推设计）
Addy Osmani 和 Viv Trivedy 都建议从期望行为反推 Harness 组件：
文件系统 + Git：Agent 的工作台面。没有文件系统，你就在复制粘贴聊天内容——那不是工程。
Bash + 代码执行：通用工具。预置工具追不上需求，终端是最终 fallback。
沙箱：隔离执行环境。allow-list 命令、网络隔离、用完即毁。
记忆 + 检索：AGENTS.md 注入、向量检索、BM25 混合搜索（OpenClaw 用 SQLite 实现）。
上下文管理：对抗 context rot 三件套——压缩历史、摘要 offload、子 Agent 分流。
验证回路：测试、lint、typecheck 的结果必须回流给 Agent，形成 back-pressure。
子 Agent：探索者、实现者、审查者分工，各自独立上下文窗口。
5.6 Harness Engineering 为什么是「真学问」
因为它满足一个好工程学科的特征：
- 可积累：每次失败都转化为永久约束
- 可度量：基准测试、成功率、成本/任务
- 可移植：核心资产（AGENTS.md、MCP）不绑定单一产品
- 有深度：上下文管理、安全、编排、可观测性，每一层都有大量未解决问题
如果你 2026 年只能学一样东西，学 Harness Engineering 的投资回报率高于追逐最新模型。
第六章：Loop Engineering——一次有用的命名，而非范式革命
Loop Engineering 虽然是 2026 年 6 月最热的词汇，但个人认为：它描述的现象是真实的，却被过度包装了。
6.1 它是什么
Loop Engineering（循环工程） 在 2026 年 6 月集中爆发。导火索是 Peter Steinberger（OpenClaw 作者）的一条帖子，大意是：
别再手动 prompt 你的 coding agent 了，去设计一个能自动 prompt 它的循环。
第二天，Addy Osmani 发文正式命名「Loop Engineering」，并给出解剖结构：automations、worktrees、skills、connectors、sub-agents、external state。
一句话定义：
Loop Engineering = 设计 Agent 的迭代循环——它何时行动、如何验证、何时停止——而不是你亲手敲每一条指令。
6.2 它解决什么问题
Loop Engineering 试图回答三个具体问题：
- 谁来发起下一轮？ 不再是人按回车，而是 cron、webhook、测试失败、定时器
- 怎么知道做完了？ 需要可测试的终止条件（测试通过、CI 绿、文件存在）
- 怎么防止空转？ 需要 max turns、预算上限、无进展检测、人工升级
这些问题的确存在，而且随着 Agent 能独立运行时间从分钟延长到小时，变得更加紧迫。
6.3 为什么说它「没那么了不起」
原因一：它只是 ReAct 的产品化命名
Loop Engineering 的学术祖先是 2022 年的 ReAct 论文。之后还有 Reflexion（2023）、Plan-and-Execute、Evaluator-Optimizer（Anthropic 的 Building Effective Agents 指南）……
整个「循环」概念在学术界和工程界已经存在四年。 Loop Engineering 做的，主要是给已经发生的事情贴了一个新标签。
# 这就是 Loop Engineering 的全部本质 while not done and steps < MAX_STEPS: action = agent.decide(state) result = env.execute(action) state = update(state, result) done = verifier.check(state)
十二行伪代码。没有新算法，没有新数据结构，没有新协议。
原因二：真正的难点不在「循环」，而在循环里的零件
Loop Engineering 的鼓吹者喜欢画一张演进表：
| 年份 | 时代 | 你做什么 |
| 2024 | Prompt Engineering | 写提示词 |
| 2025 | Context Engineering | 管理上下文 |
| 2026 | Harness Engineering | 搭建环境 |
| 2026 | Loop Engineering | 设计循环 |
看起来像是四级火箭。但更准确的描述是俄罗斯套娃：
Loop ⊂ Harness ⊂ Context ⊂ Prompt
Loop 不是新的一层，而是 Harness 里本来就应该有的控制流。一个 Harness 如果没有循环，它根本就不是 Agent Harness，只是一个带工具调用的 Chatbot。
把 Harness 里最显而易见的那个 while 循环单独拎出来叫「Loop Engineering」，有点像把 for 循环从编程里单抽出来叫「Iteration Engineering」。
原因三：产品实现极其朴素
看 Cursor 的 /loop 实现（来自官方 Loop Skill）：
while true; do sleep <seconds> echo 'AGENT_LOOP_TICK_<purpose> {"prompt":"<prompt>"}' done
就是一个 shell 死循环 + sleep + 唤醒 Agent。动态模式也不过是「Agent 自己决定下次什么时候 sleep」。
Claude Code 的 /loop、cron、hooks、GitHub Actions 触发——全是操作系统和 CI 领域二十年前的基础设施。
原因四：成本陷阱比技术突破更值得关注
2026 年 6 月，r/cursor 上有一个著名案例：一个 PM 让 Agent 给 87 个任务打标签，一小时烧掉 $1,400。Cursor CEO 亲自退款。
Loop 的核心风险不是「循环不够聪明」，而是循环没有刹车：
- 默认无界的 turns
- 每个 turn 加载完整上下文
- 价格 = 单价 × 轮次，Agent 把轮次搞爆了
所以 Loop 领域真正值得关注的工程实践是：
--max-turns/--max-runtime硬上限- 每任务成本可见性
- 无进展检测（同一测试失败三次就停）
- 可测试的终止条件
这些是运维和治理问题，不是新的工程范式。
6.4 那 Loop Engineering 有没有价值？
有，但价值在于降低了认知门槛，不在于创造了新技术。
它让更多人意识到：
- 你不该守在聊天窗口旁边
- 你该定义「完成」的标准，而不是定义「下一步」
- 验证器（verifier）是循环里最重要的零件，不是模型
如果你之前已经在用「跑测试 → 失败 → 喂给 Agent → 再跑」的模式，你早就在做 Loop Engineering 了，只是没人给你发一个时髦的标签。
6.5 一个更诚实的定位
┌─────────────────────────────────────────────────────┐ │ Harness Engineering │ │ ┌───────────────────────────────────────────────┐ │ │ │ Context Engineering │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ Prompt Engineering │ │ │ │ │ └─────────────────────────────────────────┘ │ │ │ │ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ │ │ Loop = 控制流（while + 终止条件） │ │ │ │ │ │ 不是独立的一层，是 Harness 的内置能力 │ │ │ │ │ └─────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────┘
Loop Engineering 是一份好的检查清单，不是一门新科学。
第七章：串起来——从 2022 到 2026 的完整时间线
2022.11 ChatGPT 发布 └─► Prompt Engineering 时代：怎么问问题 2022 ReAct 论文 └─► Agent 概念学术化：推理 + 行动交替 2023 Function Calling / Tool Use 产品化 └─► 模型能调工具了，但还需要外层运行时 2023–24 连线 Workflow 工具爆发（LangFlow, Dify, Flowise, n8n AI 节点） └─► 「拖节点搭 AI 应用」成为入门默认路径 2024.11 MCP 协议发布 └─► Agent 集成的 USB-C 时刻 2024–25 Cursor / Claude Code / Codex 成熟 └─► Coding Agent 吃掉「画布搭代码助手」场景 2024–25 LangGraph 1.0 └─► 复杂 Agent 编排回归代码定义的有状态图 2025 Context Engineering 命名（Tobi Lütke / Karpathy / Anthropic） └─► 关注点从「怎么说」转向「给什么信息」 2025–26 n8n / Dify 等 reposition └─► 视觉 Workflow 退到集成层，与 LangGraph / Harness 叠用 2025.11 OpenClaw 发布 └─► 个人 Agent 运行时消费级化（文件 + cron 替代画布） 2026 Harness Engineering 命名（Viv Trivedy / Addy Osmani） └─► 行业共识：模型之外才是主战场 2026.06 Loop Engineering 命名（Steinberger / Osmani） └─► 把 Harness 里的控制流单独品牌化
第八章：实践建议——如果你今天就要开始
8.1 按优先级排列的学习路径
| 优先级 | 学什么 | 为什么 |
| ⭐⭐⭐ | Harness Engineering | 最高 ROI，可积累、可度量、可移植 |
| ⭐⭐⭐ | MCP + CLI 工具链 | 打通 Agent 与真实世界的标准接口 |
| ⭐⭐ | Workflow 集成层（n8n 等） | 接系统、定时触发——别跟 Agent 抢「大脑」的活儿 |
| ⭐⭐ | Context / Memory 管理 | 长任务必备，AGENTS.md 是最小起步 |
| ⭐⭐ | Skills 编写 | 把重复工作流封装成可复用模块 |
| ⭐ | Loop 设计 | 重要但简单——定义目标、验证器、上限 |
| ⭐ | 追新模型 | 模型在涨，但 Harness 决定了你能用到多少 |
8.2 一个最小可用的 Harness 起步清单
# 你的项目今天就可以有的 Harness 1. AGENTS.md - 技术栈（语言、包管理器、测试框架） - 命名规范和目录结构 - 「禁止」清单（从真实失败中积累） 2. 一个 MCP Server - 至少接入你的数据库或 issue tracker - 让 Agent 能查真实数据而不是猜 3. 验证回路 - Agent 改完代码必须跑测试 - 测试失败 = 继续循环的输入 4. 终止条件 - 测试全绿 = 完成 - 同一错误重复 3 次 = 人工介入 - max 20 turns = 硬停止 5. 成本意识 - 知道一次 Agent 任务大概花多少钱 - 批量任务先在小样本上试跑
8.3 该警惕的 hype 信号
- 有人告诉你「Loop Engineering 替代了 Harness Engineering」→ 它们在套娃，不是替代
- 有人卖「Loop 框架」但不谈验证器和成本 → 在卖 while 循环
- 有人强调模型版本但不谈 AGENTS.md → 在等 GPT-7 而不是修自己的 Harness
- 社区 Skill / 插件不做安全审计就装 → OpenClaw 的教训
- 有人声称「拖条线就能搭生产级 Agent」→ 2024 年的故事，集成层和推理层要分开看
结语：模型是引擎，Harness 是整车，Loop 是油门
用一个不太严谨但好记的汽车比喻：
- LLM 是发动机——提供动力，但本身不会走路
- Agent 是「发动机 + 传动系统」——能把动力转化为行动
- CLI / MCP / Skills 是方向盘、油门、刹车——具体的操控接口
- Workflow（n8n 等） 是周围神经系统——接 SaaS、定时触发、胶水层
- Harness 是整辆车——底盘、悬挂、安全系统、仪表盘
- Loop 是巡航定速——你设定目标速度和停车条件，车自己跑
2026 年的行业共识越来越清晰：发动机厂商之间的竞争依然激烈，但赢家往往不是发动机最好的，而是整车造得最好的。
OpenClaw 证明了个人 Agent 可以落地；n8n + LangGraph 证明了 Workflow 与 Agent 可以分层协作；Harness Engineering 给出了系统化的方法论；Loop Engineering 提醒你别守在聊天窗口旁——这些都很有用。
但别被新名词晃花了眼。打开任何一个成熟 Coding Agent 的源码，你看到的核心逻辑依然是：
while not done: response = model.generate(context) if response.has_tool_calls: results = execute_tools(response.tool_calls) context.append(results) else: done = True
参考与延伸阅读
- ReAct: Synergizing Reasoning and Acting in Language Models[1] (Yao et al., 2022)
- Building Effective Agents[2] (Anthropic, 2024)
- Model Context Protocol Specification[3]
- OpenClaw Documentation[4]
- Agent Harness Engineering — Addy Osmani[5]
- Best Practices for Coding with Agents — Cursor[6]
- Anatomy of an Agent Harness — Viv Trivedy[7]（Harness 概念源头）
- Loop Engineering — Addy Osmani[8]
- n8n AI Workflows vs LangGraph — Suhas Bhairav[9]
- Choosing the Right Agentic Framework — Konverge AI[10]
引用链接
- ReAct: Synergizing Reasoning and Acting in Language Models: https://arxiv.org/abs/2210.03629
- Building Effective Agents: https://www.anthropic.com/research/building-effective-agents
- Model Context Protocol Specification: https://modelcontextprotocol.io/
- OpenClaw Documentation: https://docs.openclaw.ai/
- Agent Harness Engineering — Addy Osmani: https://addyosmani.com/blog/agent-harness-engineering/
- Best Practices for Coding with Agents — Cursor: https://cursor.com/blog/agent-best-practices
- Anatomy of an Agent Harness — Viv Trivedy: https://vvtrivedy.com/posts/anatomy-of-an-agent-harness/
- Loop Engineering — Addy Osmani: https://addyo.substack.com/p/loop-engineering
- n8n AI Workflows vs LangGraph — Suhas Bhairav: https://suhasbhairav.com/blog/n8n-ai-workflows-vs-langgraph-agents-visual-automation-vs-code-defined-agent-graphs
- Choosing the Right Agentic Framework — Konverge AI: https://konverge.ai/blog/choosing-the-right-agentic-framework-lessons-from-the-delivery-teams/
