导读：如果只记住一句话

模型能力正在趋同，胜负手已经转移到模型外面那层工程。

这一句背后是一个朴素的事实：差距不在模型，而在模型外面那一圈——给它看什么、让它能做什么、怎么控制它别跑偏、出事了怎么查怎么回滚。这一圈东西这两年才被拆解成几个有名字的工程学科——提示词工程、上下文工程、Harness 工程、Loop 工程、Graph 工程。本文就沿这条演进线展开。

你的关注点	直接看
概念扫盲：智能体到底是什么	立论篇（定义 + 四个拐点）
技术主线：五级工程各解决什么	演进篇（本文核心）
选型决策：产品与框架怎么挑	落地篇（产品版图 + 框架选型）
风险评估：为什么大多数项目会死	落地篇（落地现实）
只有十分钟	导读 + 演进篇的"五级全景" + 落地篇的"落地现实"

---

立论篇 · 智能体是什么，从哪来

先把"智能体"定义清楚

一句话判据：判断一个系统是不是智能体，只看一条——下一步做什么，是它自己决定的，还是你事先写死的。

"智能体"这个词被用得很滥。厘清它和三个近亲的边界，后面的讨论才有基础。

• 它不是聊天机器人。 聊天机器人的输出终点是一段文字，交付物是"话"。智能体的输出终点是世界状态的改变——文件被修改了、工单被创建了、参数被下发了。它交付的是"事"。
• 它不是 RPA（机器人流程自动化）。 RPA 走录制好的固定路径（数据搬运、批量填表、定时报表、对账等）；智能体则在运行时根据当前观察决定下一步。代价是行为不完全可预测——这既是它的价值，也是它全部风险的来源。
• 它不是工作流引擎。 传统工作流的分支条件是你写的 if/else；智能体的分支条件是模型现场判断的。

一个形象的类比：

大模型 ≈ CPU。 它只会一件事：给一段输入，算出一段输出，无状态、无记忆、够不着外面任何东西。

智能体 ≈ 围着这颗 CPU 搭出来的一整台计算机 —— 内存管理、系统调用、外设驱动、进程调度、崩溃恢复。

这几年 CPU（模型）的性能确实在涨，但真正决定"这台机器能不能干活"的，是外面那些看起来很土的系统工程。而一个最小的智能体，本质就是一个循环：

while 任务没完成:
    决策 = 模型(当前上下文)        # 想：下一步干什么
    if 决策 是 "收工": break
    观察 = 执行工具(决策)          # 做：调用外部世界
    上下文 = 更新上下文(观察)      # 记：把结果放回去

这几行伪代码就是智能体的全部骨架。

四个能力拐点

时间线上的产品发布很多，但真正改变"能做什么"的只有四次：

2022 ──── ReAct：推理与行动交替（"想一步、做一步、看一眼"）
2023 ──── function calling / AutoGPT / Code Interpreter
2024 ──── Devin 类长任务智能体登场；Anthropic 发布 MCP
2025 ──── 编码智能体商用化；Google 发布 A2A；LangChain/LangGraph 1.0
2026 ──── MCP+A2A 进入 Linux Foundation；各大框架重构；企业落地阵痛

• 拐点一：会用工具——从"会说"到"会做"。 2022 年 ReAct 提出"别让模型一口气想完，让它想一步、做一步、看一眼结果、再想下一步"。2023 年 OpenAI 把它工程化成 function calling：用 JSON Schema 描述可调函数，模型返回结构化调用请求。它把模型从"文本生成器"变成了"决策器"——输出第一次可以直接驱动代码执行。
• 拐点二：会写并执行代码——拿到通用行动接口。 工具调用有个天花板：每个能力都得预先包成函数，包不完。给模型一个能跑代码的沙箱，等于给了它一个万能工具。直到今天，"能不能安全地跑代码"仍是衡量智能体成色的关键指标——它带来的能力和风险一样大。
• 拐点三：长任务续航——从一问一答到连续干活。 2023 年的 AutoGPT 是重要的反面教材：它演示了"让模型自己给自己派活、无限循环"的概念，也立刻演示了全部失败模式（原地打转、反复调同一个工具、上下文塞满后失忆、烧光 token 却没有产出）。它的失败不是模型不够聪明，是它外面什么都没有。 从 2024 年起，业界补的就是上下文工程、Loop 工程、记忆与检查点这几课。
• 拐点四：标准化互联——从"每家自己接"到"插上就能用"。 2024 年底 MCP（Model Context Protocol）把"M 个产品接 N 个工具"的 N×M 对接问题变成 N+M，现已是事实标准；2025 年 4 月 Google 发布 A2A（Agent2Agent）解决"智能体之间怎么互调"。

---

演进篇 · 五级工程（核心）

为什么要谈"演进"

大语言模型本身只做一件事：给定上文，预测下一个 token。它没有记忆、没有工具、没有目标、也不会自己停下来。

所谓"智能体（Agent）"，本质上是我们在这个"只会续写"的核心之外，一层一层套上去的控制结构。智能体能力的每一次跃迁，几乎都对应着一层新控制结构的出现：

阶段	工程范式	控制的对象	一句话概括	类比	概念保鲜期*
一	提示词工程	单次输入	把话说清楚	下达一道指令	按年算
二	上下文工程	输入的组织	把该给的信息给全	准备好资料袋	按半年算
三	Harness 工程	模型的运行环境	为模型搭起运行环境（外设+护栏）	搭好工作台	按月算
四	Loop 工程	多轮自主循环	让它自己干完再停	交代一项任务	约 6 周
五	Graph 工程	多体协作拓扑	让一群智能体分工	组织一个团队	进行中……

从上到下有三个同步发生的趋势：人的介入越来越少，系统的自主性越来越高，工程的复杂度也越来越大。

* "保鲜期"指某个概念从提出到被下一个概念盖过热度的大致周期，是一种行业观察而非严格度量。

换一个视角，五级也可以叠成一台"计算机"： 越往上，管的时间跨度越长、状态越多。

┌─────────────────────────────────────────────────┐
│ Graph 工程   可控可回放的编排   ≈ 工作流引擎+事务 │
├─────────────────────────────────────────────────┤
│ Loop 工程    自主推进的控制循环  ≈ 调度器+熔断    │
├─────────────────────────────────────────────────┤
│ Harness 工程 与外部世界的接口    ≈ 运行时+沙箱    │
├─────────────────────────────────────────────────┤
│ 上下文工程   这一刻看见什么      ≈ 内存管理       │
├─────────────────────────────────────────────────┤
│ 提示词工程   单次输入怎么写      ≈ 函数签名       │
├─────────────────────────────────────────────────┤
│ 大  模  型                       ≈ CPU            │
└─────────────────────────────────────────────────┘

这套"工程类比"会贯穿下面五节——每一级，我们都对照一个你在做传统系统时早已熟悉的东西。

---

一、提示词工程（Prompt Engineering）：把话说清楚

1.1 起点

最早我们与模型交互的全部手段，就是一段文本输入。提示词工程研究的核心问题是：在单次调用里，如何组织这段文本，让模型给出我们想要的输出。

1.2 关键手法

• 角色设定（Role）：你是一位资深的财务分析师……——用身份约束语气、专业度和视角。
• 少样本示例（Few-shot）：给几个"输入→输出"范例，让模型模仿格式与风格，而不必解释规则。
• 思维链（Chain-of-Thought）：让我们一步一步思考——诱导模型显式推理，显著提升复杂问题的正确率。
• 输出格式约束：要求返回 JSON、表格、指定字段，让下游程序能可靠解析。
• 分隔与结构化：用标题、分隔符、XML 标签划清"指令区 / 数据区"，减少混淆。

心态也变了：2023 年靠"咒语"（“你是世界级专家”“深呼吸慢慢想”）哄模型，2026 年靠结构化、可测试的指令——更像写规格说明，而不是念咒。

1.3 边界

提示词工程的天花板很明确：它只能控制"这一次"说什么。 缺了它的典型症状是答非所问、格式不对；但即便写到完美，也仍然：

• 模型不知道你昨天说过什么（无记忆）；
• 你无法在提示里塞进一整个代码库或知识库（受上下文窗口限制）；
• 再精巧的提示，也无法让模型真正去"查一个数据库"“调一个 API”。

当任务需要外部信息和跨轮记忆时，我们就迈入了下一层。

---

二、上下文工程（Context Engineering）：把该给的信息给全

2.1 从"怎么问"到"给什么"

如果说提示词工程关心措辞，上下文工程关心的是：在有限的上下文窗口里，究竟应该放进哪些信息、以什么顺序放、占多少预算。

一个经典论断：大多数智能体的失败，不是模型不够聪明，而是我们没把对的信息放进它的视野里。

一条底层原则要先立住：上下文是一种稀缺资源。 模型有个"注意力预算"，每多一个 token 都在消耗它。所以上下文工程的目标从来不是"给得多"，而是找到那组最小的、高信噪比的 token——恰好够撑起你要的行为，多一分都是负担。

2.2 关键手法：四类操作

业界（LangChain）把上下文工程的手段收敛成四个动词——写出去、挑进来、压一压、隔开来。几乎所有具体技巧都能归到这四类：

操作	做什么	典型技巧
Write 写出去	把信息存到窗口之外，免得每轮重新推导	草稿本（scratchpad）、记忆文件、待办计划；Anthropic 称之为"结构化笔记 / agentic memory"
Select 挑进来	需要时才把对的信息拉进窗口	检索增强（RAG）、记忆召回、按需加载（只存文件路径/查询/链接等轻量标识，运行时再动态取）
Compress 压一压	保住关键信息的前提下降 token	摘要、裁剪历史、Compaction（接近上限时把对话压成高保真摘要、重开窗口继续）
Isolate 隔开来	把不同上下文分开、防止互相干扰	子代理（各自干净窗口探索、只回传千字级结论）、按主题/任务分独立记忆

三个当下最重要、也最能拉开差距的落地点：

• 按需加载（just-in-time）胜过一次灌满：不必把资料预处理后全塞进去，而是像人用文件系统、书签那样——先给轻量索引，用到再取，让 agent 边探索边"渐进披露"。既省窗口，也更贴近真实工作方式。
• Compaction 让长任务能一直跑：把接近上限的历史压成摘要、重启一个干净窗口，是编码/研究类长任务"跑几小时不失忆"的关键。调这套摘要提示的诀窍是——先保召回（别漏关键信息），再提精度（删冗余）。
• 子代理做"上下文隔离"：让子 agent 在自己干净的窗口里烧几万 token 去探索，只把 1–2 千 token 的结论交回主流程，探索的噪声不污染主线。

此外，信息排布本身也是工程：模型对上下文首尾更敏感（"迷失在中间"效应），关键信息别埋在中段。

2.3 意义与边界

上下文工程第一次让模型能够基于它训练时并不知道的、实时的、私有的信息去工作。企业知识问答、文档助手、个性化对话，都建立在这一层之上。缺了它，长任务会出现三种典型症状：

• 越跑越傻：上下文塞满无关内容后模型抓不住重点（业内俗称 “context rot”）；
• 成本爆炸：token 按量计费，且注意力开销随长度显著上升，不做管理的长任务成本可差出一个数量级；
• 前后矛盾：早期结论被挤出窗口后，模型会推翻自己十分钟前的判断。

这是当前投入产出比最高的一层——大量所谓"模型不行"，换成"给它看对东西"就解决了。但它有个隐含前提：信息是你喂进去的，模型只负责"读和答"，还不能主动获取信息、也不能对世界产生动作。要打破这层"只读"，得给模型装上"手脚"——这就是 Harness 工程。

---

三、Harness 工程（Harness Engineering）：为模型搭起能干活的运行环境

Harness 的字面意思是"马具/挽具"——套在牲口身上、既借力又约束的整套装备，这也是"给模型装上手脚和护栏"这个直觉的来源。但放到工程里，它的分量比"手脚 + 护栏"重得多：Harness 是模型赖以运行的整个环境——把一颗只会算的"裸模型（CPU）"，装进一台配齐了外设、内存、系统调用与沙箱的机器。工具（手脚）和管控（护栏），只是这套环境里的两样组件而已。

工程类比：运行时 + 系统调用 + 沙箱。 模型是用户态进程，Harness 是内核加外设。进程想干任何实事，都得通过你提供的系统调用；你决定它能碰哪些文件、能不能联网、能不能删东西。

3.1 定位：管环境 · 地基

Harness 关注的不再是"输入文本"，而是模型赖以运行的整个环境：能调用哪些工具、遵守哪些规则、连接哪些系统、记住什么、输出要过哪些关卡——它管"环境"，是整座智能体大厦的地基，目标是让智能体工程从"能跑"走向"能交付"。

这一层也是 2026 年产品差异的主战场：前沿模型能力已高度趋同，同一颗"CPU"装进不同的机器，表现天差地别，差的就是 Harness。

3.2 三个视角看 Harness：从概念到落地

用三个视角刻画 Harness：六大杠杆偏"操作旋钮"、五大层级偏"组件划分"，这两个是概念地图；再加一个工程落地视角，看业界两套真跑在生产里的参考实现。

视角 A：六大杠杆——工程师可调节的"旋钮"

把操作手段归纳为六个可调的"旋钮"，覆盖从轻量调整到重量开发的完整谱系：

杠杆	内容	作用
杠杆一	系统提示	设定智能体的稳定人格、原则与边界
杠杆二	工具与模型上下文协议（MCP）	定义模型能调用哪些工具、以什么协议连接外部世界
杠杆三	上下文	决定运行时向模型注入哪些信息
杠杆四	子智能体	把复杂任务拆给专职的下级智能体
杠杆五	钩子（Hooks）	在关键节点（调用前/后）插入自定义逻辑，做拦截、校验、改写
杠杆六	技能（Skills）	把成熟流程封装成可复用的能力包，渐进式加载，即插即用

视角 B：五大核心层级——按职责切分的组件划分

比六大杠杆更"结构化"的一个概念视角：按职责把 Harness 切成五层，彼此是约束—赋能—校验的递进关系：

1. 第一层｜规则与标准（“交通法规”）：智能体必须遵守的硬约束与规范，划定不可逾越的边界。
2. 第二层｜能力与流程（“按图索骥”）：可复用的技能与标准作业流程，让它知道"这类事该怎么一步步做"。
3. 第三层｜外部连接（“标准化接口”）：通过工具/MCP 等标准接口对接外部系统，把"只会说"变成"能动手"。
4. 第四层｜记忆与上下文（“外化记忆”）：把状态与知识外化存储、按需召回，突破单次窗口的限制。
5. 第五层｜硬性校验（“质检关口”）：在输出关口做确定性检查（格式、权限、危险操作确认），把不可靠变可控。

视角 C：工程落地——业界两套参考实现

前两个视角是"概念地图"，这一节看两套真跑在生产里的 harness，把抽象层级对上具体实现。

① Claude Code：五层同心防线（本质是"一个包住模型的运行时"）

层	管什么	具体承载
环境层	在哪儿执行	运行时 + 沙箱 + 工作目录，划定它能碰到的世界边界
工具层	能做什么	文件读写、shell、MCP 工具；只读可并行、改写串行防竞态
控制层	什么不许做	权限（deny-first，逐工具/模式/目录）+ 钩子（调用前后）+ 人工确认
记忆层	带着什么知识	CLAUDE.md（项目规矩）、MEMORY.md（演进状态）、上下文压缩
评估层	做得对不对	独立的 evaluator/verifier——不让 agent 给自己的活打分

一句点睛：“记忆是建议，钩子是法律”——记忆层靠上下文影响行为（模型可以不听），控制层靠技术手段硬拦（模型绕不过）。

② LangChain deepagents：四类内建能力（batteries-included 的 agent harness，构建在 LangGraph 之上——自带全套常用组件、省你造轮子，但仍是要写代码的框架，不是装上就用的成品）

它跟其他框架用的是"同一套工具调用循环"，差别在于把生产级 harness 的部件都做成了内建。官方把这些能力归为四类：

类别	内建能力
执行环境	工具与 MCP、虚拟文件系统（可插拔后端）、文件系统权限、代码沙箱执行
上下文管理	Skills（SKILL.md，渐进披露，用到才读全文）、记忆（AGENTS.md 持久指令）、摘要与上下文卸载、提示缓存
任务委派	规划工具 write_todos（拆待办、跟踪 pending/进行中/完成）、子智能体（全新上下文、自治执行、只回传一份结论）
操控引导	人在环中中断（HITL，借 LangGraph 实现）、文件系统权限管控

两套实现印证了同一件事。 把它们并排看，组件几乎一一对应：

关键组件	Claude Code	deepagents
跑在哪、能调什么	环境层 + 工具层	执行环境
带什么知识、怎么省窗口	记忆层	上下文管理（Skills/记忆/卸载）
怎么拆活、并行	子智能体（杠杆四）	任务委派（规划 + 子智能体）
什么不许做、谁来把关	控制层 + 评估层	操控引导（权限 + HITL）

3.3 意义与边界

Harness 是从"聊天机器人"到"能干活的智能体"的分水岭。缺了这一层，会出现三种症状：

• 能想不能做：没有工具的模型只能输出建议，交付不了结果；
• 做了不该做的事：这是 Harness 最重要的职责——智能体的破坏力上限，等于你给它的权限上限。一个能执行 rm -rf 的智能体，早晚会执行一次 rm -rf；
• 工具用不对：工具描述写得含糊，模型就会传错参数、选错工具。工具描述本质上是写给模型看的 API 文档，质量直接决定成功率。

有了工具接口，模型才第一次能对真实世界产生动作；有了规则与校验，这些动作才敢交给它。这一层也是标准化正在发生的地方——MCP 干的就是把"工具怎么接进来"标准化。

但 Harness 搭好的只是"工作台"。谁来驱动模型反复观察—思考—行动，直到任务完成？这就是 Loop 工程。

---

四、Loop 工程（Loop Engineering）：让它自己干完再停

4.1 来龙去脉：一个"只活了六周"的新范式

Loop 工程是"AI 圈范式加速折旧"的一个标本。2026 年 6 月，OpenClaw 创始人 Peter Steinberger 发帖主张"设计能提示 Agent 的循环"，迅速爆火，一度让开发者相信"循环工程才是 AI 编程的新方向"；约六周后（7 月 18 日），同一个人又发了九个词——“Are we still talking loops or did we shift to graphs yet?”（还在聊循环，还是已经转向图了？），两天内 260 万+ 浏览。一个概念从爆火到被本人宣告"过时"，用了不到两个月。

这是又一次"造词狂欢"，还是真正的范式演进？

4.2 它是什么，为什么会出现

核心主张：不要再亲自给 Agent 写提示词，而是设计一个循环系统，让循环替你去提示 Agent。

“我已经不给 Claude 写提示词了，我有 Loop 在跑，它们自己决定该干什么，我的工作是写 Loop。” —— Boris Cherny，Claude Code 创造者

直接动因是上下文窗口装不下。 2025 年主流模型窗口普遍只有 ~20 万 Token（如 Claude 3.5 Sonnet），而中型项目代码动辄数十万 Token。Geoffrey Huntley 于 2025 年 7 月提出的 “Ralph” 方法给了破解思路：让 Agent 反复运行、每轮用全新上下文，靠"多跑几轮 + 外部状态"绕过窗口限制——这就是 Loop 的思想雏形。

放回主线：Harness 管"环境"，Loop 管"反馈与自驱"——让循环自己触发、自己派活、自己验收，把人从"每轮都得按一下继续"里解放出来。它比 Harness 高一层：不只搭好工作台，而是让台上的活自己转起来。

4.3 一个典型 Loop 的组成

业界把能自运转的 Loop 拆成几个可组装的构建块，每块解决"让循环真正转起来"的一个具体问题：

#	模块	一句话作用	不装它会怎样
1	自动化触发（Automations）	循环的"心跳"：定时或事件触发（cron、webhook、CI、队列）自动启动	只是"手动跑过一次"，不是一个循环
2	工作树隔离（Worktree）	给每个并行 agent 一份独立 git worktree（共享历史、隔离改动）	多个 agent 同时改文件会互相覆盖
3	技能包（Skills）	把项目规范、构建步骤、最佳实践打包成 SKILL.md 供每轮复用	每轮从零猜起，攒下"意图债"
4	插件与连接器（Connectors）	基于 MCP 接入文件系统、API、数据库、工单，让循环能真的动手	循环只能"建议"，开不了 PR
5	专门的子 Agent（Sub-agents）	写代码与查代码分离——一个创造、一个审查，形成内建质检	自己判自己"做完了"，无声失败混过验收

它们合起来跑一个 “生成 → 验证 → 迭代” 的闭环：

① Agent 生成代码/方案 ──► ② 验证器（另一个 agent）检查是否符合预期
        ▲                                │
        │  不通过：反馈 + 修正            │  通过
        └────────────────────────────────┴──► 收工

和 2023 年 AutoGPT 的朴素循环相比，关键差别只有两处：循环由"触发"自动发起；"完成"由独立验证者判定，而非干活的 agent 自己说了算。 这两点，决定了 Loop 的成败。

4.4 正面评价：它解决了什么真问题

• 突破上下文窗口的物理墙："反复运行 + 全新上下文 + 外部状态"让超出窗口的大项目也能持续推进——这是 Ralph 的真洞见。
• 把人从"逐轮提示"里解放出来：从"一句句喂提示"变成"写好循环让它自己跑"，是实打实的杠杆。
• maker–checker 让"无人值守"变可信：产出与验收分权，是把自动循环推向生产的结构性改进。
• 在"可机械验证"场景已跑通：编码有测试当裁判、性能优化有 benchmark 说话——这正是当下编码智能体成立的底层机制。

4.5 负面评价：为什么它备受质疑

五条最有分量的质疑，几乎每条都直指要害：

1. “新瓶装旧酒”：约 90% 的组件是传统自动化工具的重组（定时任务、工作流、版本隔离、状态管理、自动测试、代码审查），真正新增的只有"用大模型处理难以写成固定规则的不确定性任务"。2023 年 AutoGPT 已试过，因缺验证与边界控制而失败。
2. 烧钱如流水：每轮都烧 Token，而 Loop 可能跑很多轮，被实践者称为"致命痛点"。本质上"和写出一个无限循环没区别——问题不在 Loop，而在没设计好验证机制"。
3. 定义"完成"很难——目标漂移：目标一旦模糊，Loop 会找到一个"满足终止条件、却不是你想要"的解。它的天花板不是 Token，而是工程师的判断力——而 Loop 本身在削弱它：用得越多，动用判断力的机会越少。这是个深刻的悖论。
4. “屎山加速器”：模型倾向"哪报错就在哪再包一层"，Loop 把这种局部打补丁逐轮放大——表面越来越"健壮"，内部越来越难懂。

   “区别只有一点：人在屎山上一锹一锹地堆，AI 一轮一轮地堆，快很多。” —— Armin Ronacher，Flask 作者

5. 适用场景极有限：有效场景有个共同前提——产物能被机械化验证（代码有测试、性能有 benchmark，验证器能给二元信号）。一旦涉及"架构是否合理"“抽象是否恰当”，Loop 就会失败。

4.6 一个平衡的判断

在"产物可机械验证 + 需长期维护"的窄场景里，Loop 是真进步；离开这个前提，它的风险（烧钱、目标漂移、屎山、判断力退化）会迅速盖过收益。

所以别急着纠结"要不要赶紧上 Loop"，先问一个更朴素的问题：这个场景，有没有一个可靠、廉价、能自动运行的"验证器"？ 有，大概率能帮上忙；没有，先别碰。

还有三条不因自动化而消失的责任要提醒决策层：验收仍是你的、"理解债"会累积、判断力可能在依赖中退化。

而那句"还在聊循环，还是转向图了？"正好点出下一级：当任务复杂到需要多线并行、显式分支回滚、可回放的流程时，单个循环就扛不住了——进入 Graph 工程。

---

五、Graph 工程（Graph Engineering）：让一群智能体分工协作

5.1 范式转移：从 Loop 到 Graph（Loop 缩小成一个节点）

那条"还在聊循环，还是已经转向图了？"的推文被当作分界；紧接着 LangChain 团队补了一句更釜底抽薪的话——用图来建模 Agent，他们已经做了三年。叙事就此从"Loop 是核心范式"跨到了 Graph：

   Loop            ──►    缩小     ──►      Graph
整个系统的核心范式      降级为一个节点      接管系统级的编排职责

Loop 并没有死，只是从"整个系统"缩小成了"图里的一个节点"。 这是理解 Graph 的钥匙：它不取代 Loop，而是高一层去回答 Loop 答不了的问题——多个 Agent 并行、彼此依赖时，怎么组织？ 如果说 Loop 定义"一个 Agent 怎么工作"，Graph 给的就是"一群 Agent 怎么协作"的蓝图。

5.2 它是什么：节点 + 边

核心思想：把多智能体的协作显式建模成一张图来设计和执行。 一张图只有两个基本元素：

• 节点（Node）—— 工作单元：可以是一个 AI Agent、一段确定性代码、一个工具调用，甚至一个人工审批步骤。
• 边（Edge）—— 流转规则：A 的输出交给谁、B 必须先于 C、失败走哪条路。边的方向，定义了依赖与顺序。

如果再加一份可持久化为检查点的状态（State），就凑齐了 LangGraph 这类框架的三件套。于是"下一步做什么"从藏在循环里，变成了一张可控、可视、可调试的流程图。

5.3 一个例子，与 Loop / Graph 最根本的区别

一条"功能开发流水线"画成图——四个节点、三条带条件的边，就把"谁先谁后、谁依赖谁、失败怎么办"讲清楚了：

      ┌─────────┐
      │ Agent A │  写代码
      └────┬────┘
           ▼
      ┌─────────┐
      │ Agent B │  审查
      └────┬────┘
     通过 ╱   ╲ 不通过
        ▼      ▼
  ┌─────────┐  ┌──────────────┐
  │ Agent C │  │ 回到 Agent A │
  │  部署   │  │    修改       │──┐
  └─────────┘  └──────────────┘  │
        ▲                         │
        └────（修改后重新审查）─────┘

Loop 和 Graph 最根本的区别，藏在"边"里：代码里的先后顺序只代表"什么时候执行"，而图里的边代表"谁需要谁的结果"。如果两个任务之间没有数据依赖，它们就应该被并行执行，而不是被串起来白白浪费时间。

如果你做过 Activiti、Airflow 这类工作流引擎，这套并不陌生——它本质上就是工作流编排，只是执行单元从"一段代码"换成了"一个 Agent"。

5.4 "Graph"到底指什么：三种尚未统一的用法

注意一个多义性——"Graph Engineering"在业内至少有三种用法，概念远未统一：

解释	图是什么	谁在用
执行图	节点做事，边决定"下一步怎么走"	LangChain 的主流解释
组织图	节点是岗位角色（产品经理/开发/测试 Agent），边表达分工协作	X 平台上最流行的解释
治理图	“优化 / 审计 / 回滚 Loop 的 Loop”，三者互相监督成闭环	Carlos Perez 等提出

三种解释并存，恰说明 Graph Engineering 还处在"用定义探索边界"的早期，远未成行业共识。 汇报时用这个词，最好先说清指的是哪一种。

5.5 Loop vs Graph：多维度对比

维度	Loop Engineering	Graph Engineering
核心关注	单个 Agent 如何持续工作直到目标达成	多个执行单元如何协作、并行、汇合
拓扑结构	线性循环（一条线）	有向图（节点 + 边）
并行能力	本质串行，一轮接一轮	天然支持并行执行无依赖的任务
故障处理	整体重试或从头再来	单节点重试，故障隔离
可观测性	难以追踪每一轮的决策过程	图结构天然可渲染、可调试
适用场景	有明确二元验证器的任务	需要多角色协作的复杂任务
复杂度	概念简单，上手快	需要设计节点、边、状态流转
代表工具	/goal 命令、Ralph 脚本	LangGraph、各类图编排框架

一个好记的比方：Loop 像一个人加班加点、反复尝试把事做对；Graph 像一支团队——有人设计、有人开发、有人测试，并行工作，还有个 Leader 统筹调度。

5.6 客观评价：Graph 也并非万能药

和 Loop 一样，Graph 值得泼三盆冷水：

• 同样不是"全新发明"：Graph 也被质疑"新瓶装旧酒"——LangChain 自己都说"这东西我们三年前就做了"。把工作流编排套到 Agent 协作上，算不上颠覆。
• 必须赚回协调成本：图结构意味着额外的设计、实现、维护开销。Graph 得赚回这份协调成本才有价值；任务足够简单时，一条 Loop 反而更直接——过度工程是最常见的陷阱。
• 真正的挑战在设计：Graph 并没消除 Loop 的根本难题，只是把问题从"设计一个循环"变成"设计一张图"。节点的输入输出、依赖关系、验证机制，仍要你定义。图是更强的表达工具，但替代不了工程师的判断力。

5.7 三层收束：Harness、Loop、Graph 各司其职

绕一圈，正好收束到全文主线——“叠加而非替代”。把工程味最重的后三级放在一起，它们各管一件事，且层层嵌套：

层	管什么	定位	与相邻层的关系
Harness	管环境	地基	为上层每一步动作提供工具、规则、校验
Loop	管反馈	单个 Agent 的工作模式	每一步动作都依赖 Harness
Graph	管流程	多个 Agent 的协作蓝图	图上每个节点内部，跑的就是一个 Loop

        Graph（管流程 · 多 Agent 协作蓝图）
          │  每个节点内部，跑的是……
        Loop（管反馈 · 单 Agent 工作模式）
          │  每一步动作，依赖……
        Harness（管环境 · 地基）

需要说明的是，"Harness / Loop / Graph 三层"本身并非行业公认标准，而是一个便于理解的分析框架；重要的不是记住这个划分，而是看清每一层各自在解决什么。

---

六、五层是怎么配合的：一次循环里的分工

前面五级是分开讲的，但在一次真实的任务里，它们是同时在场、各守一段的。把一次循环展开，能看到每一层各自负责哪一棒：

用户请求
   │
   ▼
[Graph]  装载状态 / 检查点
   │
   ▼
[上下文工程]  组装本轮该看的信息 ◄──────────────┐
   │                                            │
   ▼                                            │
[提示词]  指令 + 工具描述                        │
   │                                            │
   ▼                                            │
( 大 模 型 决 策 ) ──直接作答──┐                │
   │ 要调工具                  │                │
   ▼                           │                │
[Harness]  权限校验 → 沙箱执行 │                │
   │                           │                │
   ▼                           │                │
 观察结果，回写上下文           │                │
   │                           │                │
   ▼                           │                │
[Loop]  继续? 换策略? 问人? 收工?                │
   ├── 继续 ────────────────────────────────────┘
   ├── 需确认 ──► [Graph] 中断，等人拍板 ────────┘
   └── 收工 ────► 返回结果 + 落检查点

看这张图时值得注意的一点：模型（那个"大模型决策"节点）在整张图里只占一个节点，其余全部是工程。这就是"胜负手在模型外面"的字面意思——也是本文用"演进"而非"清单"来组织全部内容的原因。

---

七、五级全景：一条清晰的主线，与一个冷静的判断

把五层放在一起看，会发现一条极其一致的演进逻辑：

提示词工程   ── 控制"这一句话"           …… 单次、无状态
     │  （加入外部信息与记忆）
上下文工程   ── 控制"喂进去的信息"        …… 单次、有信息
     │  （加入工具、规则、校验）
Harness工程  ── 控制"模型的运行环境"      …… 能动手、有护栏
     │  （加入自主的多轮循环）
Loop工程     ── 控制"一个自主循环"        …… 能自己干完一件事
     │  （把一个循环拆成多体协作）
Graph工程    ── 控制"一张协作拓扑图"      …… 一个团队协同交付

四条贯穿始终的规律：

1. 控制粒度越来越细：从一句话 → 一段上下文 → 一个环境 → 一个循环 → 一张图。
2. 自主性越来越高，人越来越"往后站"：从"手把手下指令"到"交代任务"“组织团队”。
3. 上一级的天花板，就是下一级的起点：每一层都是为了解决前一层"控制不住"的问题而诞生的——它们是叠加，不是替代（就像 TCP 出现了不代表 IP 没用了）。
4. 演进本身还在加速：不仅能力在往上走，新范式冒头的节奏也在变快——这正是开篇总表最后一列（保鲜期从"按年"一路缩短到"以周计"）所揭示的。下面就来正视这件事。

7.1 一个必须正视的现象：范式在加速，热词在"折旧"

回顾 2026 年上半年的 AI 工程演进，几乎每个月都有一个新概念冒出来，而且它们的"保鲜期"正一级比一级短：

Prompt   提示工程     红利期：按年算   ┐
Context  上下文工程   红利期：按半年算  │  越往后
Harness  基建工程     红利期：按月算   │  折旧越快
Loop     循环工程     红利期：约 6 周   │
Graph    图工程       红利期：进行中…  ┘

一句话：AI 行业连热词的折旧都开始按周算了。 这种加速有两面性——

• 积极的一面：说明行业在密集探索，方向确实在往前走。
• 尴尬的一面：也暴露出我们还没找到一个足够稳定的工程范式。每个新概念都在解决前一个的遗留问题，却又带来自己的新问题。曾有人一个月推 Loop、下个月就推 Graph，被调侃"造词速度比写稿还快"——这让人不得不问：这种快速更替，是真正的技术进步，还是注意力经济的产物？

7.2 一个冷静的判断：名字会变，问题不变

答案大概介于两者之间：Loop 与 Graph 确实代表了不同维度——从"让一个 Agent 跑得更久"到"让一群 Agent 协作得更好"——这个方向是真实且有意义的；但把一些早已存在的工程思想重新包装成全新"范式"，也难免有营销成分。

所以，本文自始至终强调的是"演进"而非"清单"，原因正在于此：与其追逐每一个新名词，不如盯住它们背后那个始终没变的根本问题——

如何让 AI 系统更可靠、更可控、更可扩展。

无论下一个词叫什么，这个问题都不会因为换个名字就自动消失。看懂"新范式在解决上一层的哪个天花板"，永远比记住这个词本身更重要。

7.3 实践启示：不要越级堆复杂度

演进不等于"越新越好"。真正的工程判断在于匹配任务复杂度，用够就好：

• 简单问答，一段好提示词足矣，不必上多智能体图；
• 需要私有/实时知识，加上下文工程即可；
• 要真正"动手"、要交付，才需要 Harness；
• 要它"自己干完一件事"，才需要 Loop；
• 只有当单循环确实扛不住复杂协作时，才请出 Graph。

每高一级，能力更强，成本、延迟与调试难度也随之上升。 选对层级，比选最高层级更重要。

---

落地篇 · 从"能跑"到"能交付"

八、产品版图：谁在做什么

一句话：2026 年的智能体产品差异，主要不是模型差异，是 harness 差异——同一颗"CPU"装进不同的机器，表现天差地别。

按"解决什么问题"分，大致四类：编码类（最成熟）、通用/个人/办公类（最热闹）、企业垂直类（客服/运维/对账，钱最多、也最难落地）、基础设施类（框架、MCP/A2A 协议、评测与可观测平台，增长最快）。下面重点看前两类的代表产品。

8.1 编码类——目前唯一被充分验证的杀手级场景

编码之所以第一个跑通，是因为它同时满足了智能体最需要的三个条件：行动可执行（代码能跑）、结果可验证（测试当裁判）、错误可回滚（Git）——天然的反馈闭环。

产品	出品方	特点
Claude Code	Anthropic	终端形态、可编程的 harness（钩子、权限粒度、子代理），胜在可控性与工程化
Codex	OpenAI	云端、擅长审 PR / 找 bug，支持大规模并发（OpenClaw 就靠它同时跑上百个实例）
Cursor	Cursor	编辑器内交互密度最高，补全 + 对话 + 跨文件改动一体

8.2 通用 / 个人 / 办公类——"数字员工"的三条路线

如果说编码类拼的是"把一件专业活干到可靠"，这一类拼的是"当一个什么都能搭把手的助理/员工"。三款代表产品，恰好走了三条不同的路：

产品	出品方	定位与特点
OpenClaw 🦞	Peter Steinberger（开源）	个人 AI 助理，跨 OS/平台。用你已经在用的 IM（iMessage、WhatsApp、Slack、Discord）像指挥人一样指挥它，它能跑 shell、管文件、自动化网页。号称 GitHub 史上最快突破 30 万星
Hermes Agent（爱马仕）	Nous Research（开源 MIT，2026/2）	常驻你自己服务器的自进化 agent：持久记忆（存于 ~/.hermes/）、技能自蒸馏（自动把解法沉淀成可复用的 SKILL.md）、本地零遥测、$5 小服务器就能 7×24 常驻（空闲自动"休眠"省 token）
WorkBuddy	腾讯 CodeBuddy 生态（闭源商用，2026/3）	开箱即用的"AI 员工" 桌面客户端，即插即用；靠 SOUL.md 规则 + 复盘 + 技能沉淀来进化；积分制，强在国内政企与微信/腾讯生态的集成

一句话概括三条路线：OpenClaw 偏"个人助理 + 开源可玩"、Hermes 偏"自进化 + 技术深度"、WorkBuddy 偏"开箱即用 + 生态集成"。

8.3 一条共性

无论编码类还是办公类，这些产品的差异几乎都落在 harness 上——记忆怎么存、技能怎么复用、连接器接了哪些系统、权限怎么管——而不是底层用了哪家模型。

---

九、开发框架：拿什么把这些拼起来

一句话：框架买的是状态管理、可观测性和生态接入。真需要这三样，框架省大力气；不需要，手写一个循环反而更快。

9.1 主流框架一览

LangChain 系（生态最大）——其实是一套三层的技术栈

很多人把 LangChain、LangGraph、deepagents 当成三个竞品来纠结选谁，其实 1.0 之后它们被重构成了同一套系统的三个抽象层级（官方原话：不是选竞品，是选抽象层级）：

  deepagents   自带全套组件、"有主见"的 agent harness   ← 最上层
      │
  LangChain    高层应用开发：模型/工具/中间件/预制 agent
      │
  LangGraph    底层编排运行时：状态/检查点/持久化/流式/HITL  ← 底座

框架	栈里的位置	定位
LangGraph	底座（退居幕后）	生产级编排运行时：把 agent 建成有状态的图，管检查点、中断恢复、持久化、流式、人在环中。1.0 之后它不再直接面向应用开发者，而是退到幕后当所有 agent 的运行底座——即本文的 Graph 层，公开生产案例最多
LangChain	应用开发层	面向开发者的高层抽象：模型、消息、工具、中间件、结构化输出、预制 agent 模式，用来快速搭应用；1.0 起 agent 已全部改建在 LangGraph 之上
deepagents	最上层 harness	batteries-included（自带规划、虚拟文件系统、子代理、Skills 与记忆等全套组件）的一套"有主见"的 agent harness（第三章视角 C 已详述）——省你造轮子，但仍是框架、要写代码，不是装上就能用的成品。它主要受 Claude Code 启发（2025/7 写成，几千行代码架在 LangGraph 上）；同一架构模式也被 Manus、OpenAI Deep Research 各自独立造出，OpenClaw 属同一家族

一句话记牢：LangGraph 是发动机，LangChain 是驾驶舱，deepagents 是一台组装到位的整车（但仍要你来开）——三者不是竞品，是同一套系统的不同抽象层级。

Anthropic 系

框架	定位
Claude Agent SDK	Anthropic 官方库（Python/TS），直接暴露 Claude Code 同款 harness：agent 循环、内建工具（读文件/跑命令/搜网/改代码/调 MCP）、子代理、钩子、Skills，会话可持久化续跑。2025 年底由 claude-code-sdk 更名而来，用途从编码扩展到通用 agent——相当于"把 Claude Code 的引擎单独拆出来给你用"

国内

框架	定位
AgentScope	阿里通义实验室开源的多智能体框架：强调透明可控（每次提示、调用、编排都可见）、模型无关（DashScope/OpenAI/Anthropic 通吃）、模块化像乐高；配套 Runtime（部署）、Studio（开发监控）、Bricks（可复用组件），面向生产落地

---

结语

从提示词到图，智能体工程的这五步，本质上是人类对一个"只会预测下一个词"的模型，一步步建立起信任与授权的过程——先教它说话，再给它资料，然后给它工具与规矩，接着放手让它自己完成任务，最后让一群这样的智能体像团队一样协作。

理解了这条主线，无论未来出现什么新框架、新名词，你都能一眼看清它站在哪一层、解决的是上一层的哪个天花板。

说到底，智能体不是一项需要从零学习的新技术，而是一个需要我们把已有的系统工程能力，用在一个新的不确定性来源上的问题。模型带来了不确定性，而消化不确定性——限流、熔断、审计、回滚、可观测、灰度——恰恰是我们最熟的那套东西。

---

附录 A：常见误解速查（备答用）

说法	实际情况
“换个更强的模型就行了”	前沿模型能力已高度趋同。产品差距主要来自 Harness 与工程，不来自模型
“提示词工程过时了”	没有。它只是从"全部"变成了"最底下一层"，依然必要
“智能体 = 自主性越高越好”	相反。生产级系统的关键是明确划定自主边界，界外必须回来问人
“先做 demo，工程以后补”	这正是大多数试点死掉的路径。评测和可观测性补起来的成本远高于一开始就建
“有了智能体就不需要工作流引擎了”	主流生产形态恰恰是二者结合：确定的部分用图编排，不确定的部分交给模型决策
“多智能体一定比单智能体强”	未必。多智能体带来协调成本和错误传播。单智能体做不好的事，拆成多个通常也做不好
“它会自己越用越聪明”	不会。模型是静态的，"变聪明"需要你主动改提示词、加工具、优化上下文——那是工程活

附录 B：术语速查

术语	英文	一句话解释
智能体	Agent	能自己决定下一步做什么、并通过工具改变外部状态的系统
工具调用	Tool / Function Calling	模型输出结构化的函数调用请求，由外部代码执行
提示词工程	Prompt Engineering	设计单次调用的指令、格式与示例
上下文工程	Context Engineering	决定每一轮让模型看见什么信息（≈ 内存管理）
Harness 工程	Harness Engineering	设计模型与外部世界的接口：工具、权限、沙箱、反馈
Loop 工程	Loop Engineering	设计自主推进的控制循环：何时继续、重试、换策略、停止
Graph 工程	Graph Engineering	把循环变成有状态、可持久化、可中断恢复的执行图
上下文窗口	Context Window	模型单次能看到的输入长度上限（≈ 内存容量）
检索增强	RAG	按需从外部知识库取回相关内容塞进上下文
检查点	Checkpoint	持久化的执行状态快照，用于中断后恢复
人机确认	HITL (Human-in-the-Loop)	关键操作执行前暂停，交人确认
MCP	Model Context Protocol	智能体接入工具与数据源的开放标准（Anthropic 发起，现属 Linux Foundation）
A2A	Agent2Agent	智能体之间通信协作的开放标准（Google 发起，现属 Linux Foundation）
子智能体	Sub-agent	被主智能体调用的专用智能体，在独立上下文里完成子任务
模型评审	LLM-as-judge	用模型评价另一个模型的输出质量，用于自动化评测

参考来源

信息核对于 2026 年 7 月 31 日。数字类结论多为二手报道，引用需注明不确定性。

技术分层与概念

• Prompt vs Context vs Harness Engineering: Key Differences — Atlan
• Agent Harness Engineering vs Context Engineering vs Prompt Engineering
• The Third Evolution: Why Harness Engineering Replaced Prompting in 2026 — Epsilla

协议

• Model Context Protocol prepares to break with its stateful past — The Register (2026-07-23)
• MCP gets an enterprise makeover — The Register (2026-07-29)
• Everything your team needs to know about MCP in 2026 — WorkOS
• A2A Protocol Surpasses 150 Organizations… — Linux Foundation (2026-04)
• A year of open collaboration: Celebrating the anniversary of A2A — Google Open Source Blog

框架

• LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones — LangChain
• The best AI agent frameworks in 2026 — LangChain
• 10 Agentic AI Frameworks You Should Know in 2026 — KDnuggets

产品

• Best AI Coding Agents in 2026: Harness, Cost, and Accuracy Compared — Firecrawl
• Best AI Coding Agents for 2026: Real-World Developer Reviews — Faros AI

落地现实（数字为二手报道，引用需注明不确定性）

• AI Agent Failure Rate: Why 70-95% Fail in Production — Fiddler AI
• AI Agent Observability: A Complete Guide for 2026 — Atlan
• AI Agent Adoption 2026: 120+ Enterprise Data Points — Digital Applied