AI工程三大范式:Harness、Loop、Graph
2026/8/4 21:47:41 网站建设 项目流程

2026 年上半年,AI 工程领域密集冒出了三个新术语:Harness EngineeringLoop EngineeringGraph Engineering

三个概念几乎在同一时期被不同团队提出,又在社交媒体上被反复混用。有人说它们是同一件事的不同说法,有人认为它们是前后替代关系,还有人把它们和 Prompt Engineering、Context Engineering 混为一谈。

事情没那么复杂,也没那么简单。

这三个概念不是同义词,也不是竞争关系。它们是 AI Agent 系统的三个不同层次——分别解决"模型周围放什么"、“模型怎么迭代”、"多个模型怎么协作"的问题。

理解这三层架构,是 2026 年从"会用 AI"到"用好 AI"的关键分水岭。


第一层:Harness Engineering——给 AI 装上操作系统

2026 年 2 月,Anthropic 连续发布三篇关于 Agent Harness 的技术报告。几乎同时,OpenAI 一个五人小团队用 AI Agent 交付了 100 万行生产代码——全部由 Agent 编写,人类只做审查。

这两件事指向同一个结论:Agent 的瓶颈从来不在模型,在模型之外的环境。

Harness 这个词的原意是"马具"——套在马身上、连接马与马车的那套缰绳、鞍具和皮带。在 AI Agent 语境下,Harness 是模型之外的一切:约束条件、反馈机制、文档上下文、工具权限、记忆文件。

一个更直觉的类比:

模型 = CPU(原始算力)

上下文窗口 = RAM(有限、易失的工作记忆)

Harness = 操作系统(决定 CPU 看到什么、什么时候看到)

Agent = 应用程序(在操作系统之上运行的具体任务)

你不会让一个程序直接操作硬件。同样,你也不应该让一个裸模型直接面对真实世界的复杂任务。

Harness Engineering 的核心制品包括五类:

1. 项目文档(CLAUDE.md / AGENT.md / .cursorrules)

每个 Agent 会话开始时读取的项目说明文件,相当于新员工的 onboarding 文档。里面写着:项目架构是什么、编码约定是什么、“我们这里怎么做事”。名字因工具而异——Anthropic 叫 CLAUDE.md,OpenAI 叫 AGENT.md,Cursor 用 .cursorrules——但本质相同。

2. 进度追踪器(JSON Feature Lists)

用 JSON 而非 Markdown 定义的待办清单,每个条目包含:功能描述、验证方式、通过/失败状态。为什么用 JSON?因为 Agent 在自主运行时不太容易意外覆盖 JSON 结构,而 Markdown 很容易被改写成一团乱麻。

3. 记忆文件(Memory Files)

跨会话持久化的经验记录。上一次踩了什么坑、用了什么方案、效果如何。没有记忆的 Agent 每次都是从零开始的新人。

4. 工具定义(Tool Definitions)

这里有一个反直觉的发现:Vercel 在实验中移除了 80% 的工具定义,Agent 性能反而提升了。工具越多,Agent 的选择空间越大,选错的概率也越高。Harness Engineering 的一个重要分支是"减法设计"——给得少,反而做得好。

5. 反馈循环(Feedback Loops)

生成 → 验证 → 修正的闭环机制。这是 Harness 和 Loop 的交汇点,后面会展开。

LangChain 的一组实验数据很有说服力:同一个模型跑 Terminal Bench 2.0 基准测试,旧 Harness 得分 52.8%,新 Harness 得分 66.5%。模型没换,换的是模型周围的环境。

Agent 从来不是难点,Harness 才是。


第二层:Loop Engineering——设计"自己跑"的循环

2026 年 6 月,Claude Code 负责人 Boris Cherny 说了一句话:

“I barely prompt models anymore. I have loops that prompt the models for me. My job is to build the loops.”

(我已经很少直接给模型写提示了。我有循环来替我给模型发提示。我的工作就是构建这些循环。)

OpenClaw 创始人 Peter Steinberger 也表达了同样的意思:

“Stop prompting coding agents and start designing loops that prompt them.”

(别再提示编程 Agent 了,开始设计提示它们的循环。)

这两句话指向 Loop Engineering 的核心理念:从"写一条好提示词"转向"设计一个自我运转的循环系统"。

什么是 Loop?最朴素的理解是:

生成 → 审查 → 引导 → 重复

其实你一直在用这种循环。打开 Claude Code,让它写个着陆页,看完输出觉得 hero 部分不对,要求修改,再看,再改,再引导——这就是一个"人在回路"的 Loop。

2026 年的新趋势是把这个循环自动化:人只启动一次(给一个需求文档或 spec 文件),Agent 自己生成、自己读取输出、自己判断还需要做什么、自己给自己发下一轮提示,反复循环直到认为完成。

Loop Engineering 的核心问题是:循环什么时候该停?

这取决于任务的成功标准是否客观可验证。

场景适合 Loop?原因
测试是否通过✅ 适合二进制判断,可自动验证
分数是否超过阈值✅ 适合数值可量化
输出是否匹配模板✅ 适合格式可校验
“这个设计感觉对吗”❌ 不适合主观判断,循环会变成老虎机
“这是我想做的产品吗”❌ 不适合需要人类直觉
“用户会喜欢吗”❌ 不适合没有客观标准

一个实用的判断法则:客观 + 二进制 = Loop 是礼物;主观 + 开放式 = Loop 是老虎机。

Loop 的成本问题也不容忽视。单次 API 调用是一轮 token 的开销,一个 Loop 可能跑 10 到 50 轮,每轮都携带上下文、历史输出和中间状态。成本是复合增长的。对于月预算 20 到 200 美元的个人开发者,一个不受控的开放式 Loop 可以在一个下午烧光整月额度。

Loop Engineering 不是"让 Agent 自己跑"的许可证,而是"设计好什么时候让它停"的工程学。


第三层:Graph Engineering——编排多 Agent 的组织架构

2026 年 7 月,Graph Engineering 的概念开始浮出水面。

首先要澄清:这里的 Graph 和知识图谱(Knowledge Graph)没有关系。此 Graph 是图论中的"有向图"——节点是 Agent,边是工作流的方向和依赖关系。

如果说 Harness Engineering 解决的是"单个 Agent 的环境设计",Loop Engineering 解决的是"单个 Agent 的迭代节奏",那 Graph Engineering 解决的是"多个 Agent 之间的协作拓扑"。

当一个任务超出了单个 Agent 的能力范围——不是因为任务太难,而是因为任务太杂、太宽、需要不同领域的专业能力——你就需要多个 Agent 协同工作。Graph Engineering 就是设计这种协同的工程学科。

三种典型的 Graph 拓扑:

1. 链式(Chain)

Agent A 的输出直接喂给 Agent B,B 的输出喂给 C。像流水线,每个节点做一道加工。

适用场景:流程固定、步骤明确的管道型任务。比如"采集新闻 → 摘要生成 → 翻译 → 排版 → 发布"。

优点:简单、可预测、容易调试。缺点:一个节点卡住,整条链停摆。

2. 星型(Hub-and-Spoke)

一个"编排 Agent"负责分发任务和汇总结果,周围是多个"执行 Agent"各自处理子任务。

适用场景:一个复杂任务可以分解为多个独立子任务。比如"分析一家公司"拆成"财务分析 Agent + 技术分析 Agent + 行业分析 Agent",最后由"综合研判 Agent"汇总。

优点:并行执行、故障隔离。缺点:编排 Agent 是单点瓶颈,它的能力决定了整个系统的质量上限。

3. 网状(Mesh)

Agent 之间多对多通信,每个 Agent 可以向任意其他 Agent 请求信息或协作。

适用场景:高度动态、无法预定义流程的探索性任务。

优点:灵活、鲁棒。缺点:调试困难、成本不可控、容易出现 Agent 之间"鸡同鸭讲"的死循环。

Graph Engineering 的核心挑战不是技术实现,而是设计决策:

•哪些任务需要拆分?拆到什么粒度?

•Agent 之间的通信协议是什么?传递原始数据还是摘要?

•如何处理某个 Agent 失败的情况?重试、跳过、还是人工介入?

•成本如何分配?哪个 Agent 是 token 消耗大户?

这些问题没有标准答案,只有权衡。Graph Engineering 的本质是组织设计——和人类团队的组织设计惊人地相似。


三层架构的关系:不是替代,是叠加

理解了三个概念之后,关键问题是:它们之间是什么关系?

答案是:它们是垂直叠加的三层,不是水平竞争的三选。

┌─────────────────────────────────────┐│ Graph Engineering │ ← 多 Agent 怎么协作│ (编排拓扑、角色分工、通信协议) │├─────────────────────────────────────┤│ Loop Engineering │ ← 单个 Agent 怎么迭代│ (循环节奏、停止条件、成本控制) │├─────────────────────────────────────┤│ Harness Engineering │ ← 模型周围放什么│ (文档、工具、记忆、约束、反馈) │├─────────────────────────────────────┤│ Base LLM │ ← 底层模型│ (Qwen / Claude / GPT / ...) │└─────────────────────────────────────┘

Harness 是地基。没有好的 Harness,再精巧的 Loop 和 Graph 都建不起来。一个裸模型加上糟糕的项目文档和过多的工具定义,无论你如何设计循环和编排,输出质量都不会好。

Loop 是节奏。有了好的 Harness,Agent 需要知道"什么时候做完了"。Loop Engineering 定义了迭代的节拍和终止条件。没有 Loop 的 Agent 要么一次就停(太保守),要么永远跑下去(太烧钱)。

Graph 是组织。当单个 Agent 的 Loop 不够用,需要多个 Agent 协同时,Graph Engineering 定义谁做什么、怎么传递、如何汇总。

一个实际例子:

假设你要构建一个"自动代码审查系统"。

Harness 层:你给 Agent 写好 CLAUDE.md 说明代码规范、提供 lint 工具定义、设置"只能读不能写"的权限约束、挂上项目的历史 PR 作为记忆文件。

Loop 层:你设计一个循环——Agent 审查代码 → 生成审查意见 → 用 lint 工具验证意见是否合理 → 如果不合理就修正 → 直到所有意见都通过验证。成功标准是客观的(lint 是否报错),所以 Loop 是合适的。

Graph 层:你把系统拆成三个 Agent——"安全审查 Agent"专注漏洞检测、"性能审查 Agent"专注效率问题、"风格审查 Agent"专注代码规范。三个 Agent 并行工作,结果汇总到一个"综合报告 Agent"生成最终审查报告。

三层各司其职,缺一不可。


实践指南:你应该先关注哪一层?

不同阶段、不同场景,优先级不同。

如果你是个人开发者,刚开始用 AI Agent 写代码:

先做好 Harness。花 30 分钟写一份好的 CLAUDE.md 或 AGENT.md,把项目架构、编码约定、常用命令写清楚。这比任何花哨的 Loop 或 Graph 设计都能立刻提升 Agent 的输出质量。

如果你在构建自动化工作流,需要 Agent 自主完成多步任务:

开始设计 Loop。关键是找到客观可验证的成功标准——测试是否通过、格式是否正确、数值是否达标。有客观标准的任务放心交给 Loop,主观判断的任务留给自己。

如果你的团队在构建复杂的 AI 系统,多个 Agent 需要协同:

这时候才需要认真考虑 Graph Engineering。先想清楚角色分工和通信协议,再选择框架(LangGraph、CrewAI、AutoGen 等)。不要为了用框架而用框架——如果一条链式结构就能解决问题,不要上网状拓扑。

一个诚实的判断法则:

•80% 的 AI 应用问题,靠 Harness 就能解决

•剩下 15% 的自动化问题,靠 Loop 解决

•最后 5% 的规模化问题,才需要 Graph

不要被术语迷惑。回到你的实际问题,看它卡在哪一层。


写在最后

2026 年的 AI 工程,正在经历一场从"手艺人"到"系统工程师"的身份转变。

过去我们说"Prompt Engineering",潜台词是:只要我写出足够好的提示词,模型就能给我想要的结果。这是一种手艺人的思维——依赖个人技巧,一次一提示。

现在我们知道,真正决定 Agent 质量的不是提示词写得多巧妙,而是模型周围的环境设计(Harness)、迭代节奏设计(Loop)、协作拓扑设计(Graph)。

这是工程思维的胜利。

工程不性感。它不像 Demo 那样让人眼前一亮,不像"一个提示词搞定一切"那样适合发朋友圈。但工程是可靠的、可复制的、可扩展的。

2026 年,如果你还在琢磨"怎么写一条完美的提示词",是时候抬头看看更大的图景了。

好的 AI 系统不是"提示"出来的,是"设计"出来的。

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询