四层架构：prompt、context、harness 与 loop
12 个概念 · 约 50 分钟 · 无需安装任何内容 · 一门值得反复回看的短课
一个 agent 运行了 40 分钟，花掉 50 美元，却没有产出任何可用的东西。事后查看日志，你会发现它一遍遍尝试同样的 3 种方法，每次只改几个词。
你会改什么？
几乎所有人都会改 prompt。这是他们首先查看的地方，也是唯一能在 10 秒内修改的东西。于是他们重写 prompt，再次启动，眼看它又花 40 分钟做同样的事。
prompt 本来没有问题。系统里没有任何东西会发现运行已经停止进展，因此也没有任何东西会将它停下。真正的修复大约只有 11 个词，位于另一个文件，属于大多数人叫不出名字的一层。
本课会告诉你这些名字，一共 4 个：prompt、context、harness、loop。它们不是四选一的技能，也不是逐级攀登的 4 个台阶，而是层层嵌套的 4 个容器，每个容器负责不同的一部分工作。看清它们之后，「我的 agent 坏了」就会变成一个有地址的问题：哪一层出了问题？
本课故意设计成这一节最短的课程。它是一张地图，而记不住的地图就没有完成任务。
你至少应该通过任意一扇门驾驭过一次通用 agent：从事代码工作可以学习 Claude Code 与 OpenCode，不从事代码工作可以学习 Cowork 与 OpenWork。规格驱动开发会有所帮助，但不是必修课。这里不需要仓库、数据库或安装任何内容。一页聊天标签和一个你用过的 agent，就是全部准备工作。
📚 教学辅助材料
查看完整演示文稿：四层架构：prompt、context、harness 与 loop
为什么这些词现在如此混乱
如果你在网上读到这些词时觉得它们含义不定，问题不在你。这是一个年轻的领域，而它得到词汇的顺序错了。
不久以前，所有人能触碰的只有一层。你输入一条消息，再阅读返回内容。「prompt engineering」代表全部技能，因为 prompt 就是全部操作界面。
之后，工具迅速向外扩展。编码 agent 为你提供权限文件、规则文件和 hook。这是模型外的一层，而且可以配置。随后又出现 schedule 和 Routine。这是包裹前一层的另一层，同样可以配置。短时间内出现了两个新界面。
词汇没有跟上。每个界面都由最早写到它的人命名，名称彼此碰撞。「context engineering」有时指窗口，有时指模型运行前完成的所有工作。「graph」一词用于 3 种不同对象，概念 11 会将它们分开。harness 最容易引起麻烦。网上多数文章把 harness 和 loop 合在一起，仿佛它们是一层。另一些文章又用它指第三种东西：提供工具、凭据和安全边界的平台。
如果不是因为一点，这本可是一场无害的词语之争：缺少权限规则和缺少 schedule 是两种不同的 bug。它们位于不同界面，也由不同的人修复。 用同一个词指代两者，会把你送到错误的地方。开头的故事正是如此。
因此，本课做两件事：把四层作为容器交给你，再提供一种测试。以后这些词再次改变时，这种测试仍然有效，而它们一定会变。
用白话解释关键词
现在读一遍。某个词变得模糊时再回来。后面会完整解释每一个词。
| 术语 | 白话含义 |
|---|---|
| Prompt | 你发送的消息：要求、示例、格式和角色。 |
| Context window | 模型写一次响应时能看到的一切。没有放进去的内容就不能作为事实使用。 |
| Curator | 决定什么进入窗口、以什么顺序进入，以及什么被排除的机制。 |
| Beat | agent 的一个完整回合：从你的指令开始，包含它进行的每次工具调用，直到安静下来。 |
| Harness | 模型周围用于运行一个 beat 的代码。 |
| Loop | harness 外围的系统，负责启动 beat、判断结果并在多个 beat 之间记忆。 |
| Heartbeat | 启动 beat 的东西：schedule、事件或条件。 |
| Spine | 保存在模型外的状态，让下一个 beat 知道上一个做了什么。 |
| Stopping condition | 一条可测试的规则，用来说明工作已经完成。它由 maker 以外的东西选择并执行。 |
| Maker-checker | 一个 agent 完成工作，另一个 agent 或命令负责检查。 |
| Human gate | 运行继续之前由人作出决定的位置。 |
| Sub-agent | 拥有自己窗口的助手，完成一项工作并返回摘要。 |
| Graph | 多个这类技术栈连接成的拓扑：接下来运行什么、每条边传递什么状态、谁检查谁。 |
你会在 Loop Engineering 和 Harness Engineering 中再次遇到其中几个词，这是有意的。本课是地图，那些课程是地图所描绘的疆域：它们会构建本课只负责命名的东西。
一幅图：4 个容器，逐层嵌套
容器，不是步骤。每个 beat 仍然会构建 prompt。checker 和 human gate 位于 loop 上，而非 beat 内，因为产出工作的一方不能决定什么才算完成。
这幅图真正表达的是下面这句话。在课程结束前，它还会出现 3 次：
好 prompt 会在坏 context 中失败。好 context 会在裸 harness 中失败。好 harness 没有 loop 就会闲置。
这就是「每层都在下一层内部」的实际含义。内层的任何东西都无法弥补外层缺失，外层也无法挽救损坏的内层。
用 90 秒证明这里最重要的主张
亲眼见过之后，本课要教的那一句话更容易相信。打开你已经使用的 agent，让它完成一项结果可检查的小型真实任务：应该能运行的脚本、应该相等的电子表格合计，或应该能打开的链接。
要求它完成工作，然后阅读返回内容。
修好它，让它能够工作，完成后告诉我。
现在先别相信回答，亲自检查结果。运行脚本，计算该列，打开链接。
只要任务包含真实工作，你就会以足以令人不安的频率看到：一个自信的「完成了，全部修好」附在从未验证的工作之后。这不是模型撒谎，也不是 prompt 太弱，而是因为**这套配置没有要求任何东西进行检查，也没有让模型以外的东西决定「完成」是什么意思。**记住这种感受。概念 6 会解释它，后面的整门课都依赖它。
**15 分钟：**阅读上图、概念 2（4 种工作单位）和概念 9 的表格。把那张表放在下次糟糕的调试过程中能看到的地方。
**50 分钟：**从头读到尾，完成两个简短的观察练习和最后的诊断练习。
**以后：**回来查练习，不必重读正文。这些方法用于查阅，不用于背诵。本课只有一句话值得记住，它就在最后。
第 1 部分：形状
概念 1：容器，不是步骤
最常见的画法是把这 4 个词画成梯子：prompt 在底部，供初学者使用；loop 在顶部，供专家使用。这幅图暗中承诺，水平足够高之后，你会离开较低的台阶。
这幅图是错的，而且会让你付出金钱。
**每个 beat 仍然会构建 prompt。**即使一个 loop 已经在 schedule、checker 和 spine 的帮助下无人值守运行了 6 个月，它每天仍会多次向模型发送消息。如果消息含糊，loop 就会按时更快地产出含糊的工作。你永远不会离开内层，只会把它们包起来。
因此，层与层之间是包含关系。prompt 位于窗口内，窗口为一个 beat 构建，整个 run 负责启动、判断和记住 beat。
**这种图很容易产生 3 个错误观念。**现在就值得把它们消除：
- **外层不等于以后。**你不会按顺序构建这些层。大多数时候，你租用其中 3 层，只拥有 1 层，概念 10 会说明这一点
- **外层不等于更重要。**粗心的 prompt 放在设计精良的 loop 内，只会按 schedule 产出带账单的坏工作。各层没有高低之分，而是彼此嵌套
- **它们不是同一个盒子的 4 种尺寸。**嵌套图可能让人误以为这是同一对象的 4 个版本。它们是 4 种完全不同的对象，下一个概念会告诉你如何区分
概念 2：工作单位测试
每层都由它负责的那部分工作定义。弄清这 4 个单位之后，无论别人决定用什么名字，你都能在任何地方认出它们。
| 层 | 工作单位 | 白话解释 |
|---|---|---|
| Prompt | 一次模型调用 | 你输入后按 Enter 的内容。改了文字，就是另一个 prompt。 |
| Context | 窗口 | 模型在这一次回答时能看到的一切：你的消息、文件、之前的对话、规则文件和工具结果。 |
| Harness | 一个 beat | agent 很少只回答一次就停止。它会调用工具、读取结果、再次思考，再调用另一个工具。从你的指令开始直到安静下来，全部是一个 beat。harness 是运行它的代码。 |
| Loop | 整个 run | 没有人输入时发生的事。某个东西启动 beat，某个东西判断工作是否合格，某个东西在 beat 之间记忆。 |
现在来看测试。以后词汇再次变化时，这部分仍然值得保留：
当博客、厂商或职位描述提到「harness」「context engineering」或「agent loop」时，不必争论词语。改问：他们说的工作单位是什么？一次模型调用、窗口、一个 beat，还是整个 run？
如果对方的「harness」包含 schedule，他们就是把本书的两层画成了一层。如果「harness」指提供工具和凭据的平台，他们指的又是更宽的范围。这些用法都不算错，只是地图不同。你现在可以翻译不同地图，而不必困惑。
第 2 部分：逐层理解
概念 3：Prompt，工作单位是一次模型调用
prompt 是你编写的消息：模型应该扮演谁、你想要什么、好工作是什么样、有哪些示例，以及回答应采用什么形式。所有这些构成一份输入，并产生一份响应。
这里的技艺比多数人想的更窄。找出最弱的一项，只修那一项。如果输出形式错误，就添加正确形式的示例。如果语气错误，就说明受众。同时重写 5 项，无法告诉你究竟是哪项出了问题。2026 年 AI Prompting会完整讲解这一层。
人们常在这一层投入过多，原因有两个，也都很合理。这是唯一无需编写代码就能练习的层，也是唯一能在 10 秒内修改的层。两点都是优点，但生产环境出问题时也会立刻变成陷阱：压力之下，人们会修改容易改的东西，而不是实际损坏的东西。
**prompt 层真正损坏时的表现：**模型显然理解了任务，也大致完成了正确的工作，但回答的形式、长度或语气错误，或缺少你以为理所当然的小节。事实没有错，只是不是你所要求的内容。重读自己的文字，就能看出原因。
概念 4：Context，工作单位是窗口
窗口是模型写一次响应时能看到的一切。一个未附加的文件，不能作为事实提供给模型。昨天的对话也不可用，除非有东西把它重新放回窗口。
但不要从另一个方向过度理解。窗口内容很少时，模型并非空白。训练期间学到的一切仍在，并会填补空缺。这就是本概念末尾失败模式的机制。缺少你的文档时，模型不会沉默，而会取用自己已经知道的最可能内容，以陈述事实时同样的信心说出来。
这就产生了定义本层的问题：材料永远多于窗口容量，因此必须由某个东西作出选择，决定放入什么及其顺序。这个东西就是 curator。无论你是否亲自编写，curator 都存在。窗口迫使它完成 3 项工作。
**首先是顺序。**位置会改变材料的影响。在一项著名研究中，重要段落位于长输入的开头或结尾时准确率最高，位于中间时则下降。这个结果已有一个名字：「lost in the middle」。1 该研究测量的是 2023 年可用的模型，因此今天使用任何模型时，都应测试影响有多强，而不是直接假设。教训仍未改变：把唯一的重要限制埋在附件第 9 段，是你作出的真实决定，即使当时没有意识到。
**接着是压缩，而且并非免费。**把 40 页总结成 4 页，才能装入窗口。但如果摘要遗漏例外，之后就无法恢复。那条信息已经不在本次运行中。本层的隐藏代价正在这里：每次压缩都在押注某些内容不会重要。
**最后是丢弃，而且它是一项策略。**窗口装满时，某个东西必须决定移除什么。如果你不设策略，harness 会在最糟糕的时刻，用一条你从未读过的规则代替你决定。
下面的测试可以在一分钟内用于任何配置：
指向窗口里的任意一份文档，说出**是哪条规则把它放进来的。**如果诚实回答是「检索器返回了它」，你拥有的是搜索框，不是 curator。有些工作这样足够，有些则很危险。为 AI 提供可搜索的上下文会真正构建检索部分。Agentic Coding第 2–4 部分会教你手动管理窗口。
**context 层损坏时的表现：**回答流畅、自信，但事实错误。它往往对「另一件事」是正确的：文件旧版、另一位客户，或文档示例而非你的情况。自信、错误、接近某个真相，这 3 点加在一起几乎就是可用于定位该层的特征。现在你也知道「另一件事」来自哪里。
**亲自观察（2 分钟）。**选一个你熟悉的文档问题，在两个全新对话中各问一次。第一个对话粘贴完整文档，第二个只粘贴前 1/3，再问同一个问题。
这是文档。只根据我提供的内容，它对 [位于最后 1/3 的内容] 是怎么说的？
第二个对话通常会回答，而不是说不知道，并且往往很自信。这不是模型表现不佳，而是训练知识填补了窗口留下的空洞。你没有修改 prompt 中的任何一个词，却改变了回答。
概念 5：Harness，工作单位是一个 beat
你给出一条指令。agent 读取 3 个文件、运行命令、读取错误、编辑内容、再次运行，然后安静下来。你只输入了一次，大约发生了十几件事。这整个过程就是一个 beat，harness 是运行它的代码。
工作清单很短，也很普通：组装 context，调用模型，运行模型要求的工具，把结果送回模型，处理错误，执行 beat 结束前必须证明的条件，然后重复，直到模型不再请求工具。
你已经在使用 harness。Claude Code 有一个，OpenCode 和 Cowork 也有。你批准过的每个权限提示、启动时读取的每份规则文件，以及 commit 前自动运行的每项检查，都属于 harness。Harness Engineering会教你有意构建一个，而不是默认继承一个。
这里有一点常让人意外，而且比表面上更重要。
**sub-agent 的调用方式像工具，行为却大得多。**多数系统通过工具调用启动 sub-agent，正因如此，两者的差别很容易被忽略。工具调用出去再带着结果返回，例如文件内容、API 响应或错误。sub-agent 则会打开自己的窗口，运行自己的 beat。通过那个工具形状入口返回的，是整个技术栈嵌套副本的输出。
这带来真实价值：sub-agent 可以读取 40 份文档，同时完全不占用你的窗口；你得到的是 3 段摘要，而非 40 页内容。但也有一项容易忽略的真实代价：**返回的是一份以十足信心写成的摘要，其中也包括 sub-agent 理解错误的部分。**你没有看到那 40 份文档，后续组件也看不到。摘要听起来多自信，与它读得多好毫无关系。
概念 6：定义 harness 的边界
这是本课的转折点。之前都是描述，之后都是推论。
beat 可能因许多原因结束：timeout 触发、达到 token 上限、抛出错误、权限被拒绝，或模型认为已经完成。**这些都不能证明工作成功，**只能证明 beat 结束了。
好的 harness 可以在 beat 内执行真正的检查：编辑后运行测试套件、验证 schema，或把输出与已知总数比较。命令不通过时，可以拒绝结束。这是验证，不是模型的意见。能做到时就应该构建。
但边界至关重要：
beat 可以证明某项具体检查通过，却无法决定通过这项检查是否已经足够。
测试通过，只能证明该测试通过。它不能证明测试覆盖了真正重要的情况，也不能证明所选测试定义了整个任务。run 开始前，必须由某个人决定「完成」是什么意思。
设想一个银行对账 agent。它提出 40 个匹配项，并报告账单已经平衡，却从未比较两个总数。context 已组装，工具正常运行，也没有出现错误。所有内部信号都很健康，但结论仍然是假的。
只有事先有人要求两个总数必须相等，beat 内的 checker 才会发现问题。这个要求才是重点。maker 不能自己设置终点，再证明自己已经越过。
在 prompt 中写「验证你的工作」无法解决问题。模型写出「已验证」和写出「已完成」一样容易。最终的成功定义必须来自被判断工作之外，因此属于再向外一层。
概念 7：Loop，工作单位是整个 run
loop 提供一个 beat 无法自行提供的东西。
heartbeat 启动每个 beat：schedule、事件，或不断触发直到某个条件为真的机制。没有 heartbeat，你就是 heartbeat。你停止输入，工作也随之停止。
spine 把状态保存在模型外，让下一个 beat 知道上一个做了什么。它可以只是每个 beat 后重写的一份文件：
run: nightly reconciliation, 2026-03-14
done: pulled 412 payments and 388 open invoices
in progress: matching pass 3 of 5, 341 matched so far
needs a person: invoice 4471, two candidates both at 0.52
budget: 3 beats used of 12
这份文件一点也不聪明，所以才可靠。下一个 beat 行动前先读取它，于是会从第 3 轮继续，而不是从头开始。第 4 行记录 agent 无法作出的决定。概念 8 会把这一行变成 human gate。
外部停止机制决定整个 run 是否继续：
- **事先选定并由命令证明的成功条件。**标准来自 maker 外部
- **beat、支出和用时上限。**无论下一次尝试听起来多有希望，上限都不会动摇
- **无进展检查。**识别反复尝试但没有实质变化
- **独立 checker。**判断工作的一方没有制作该工作
这些机制都不会询问 maker 是否完成。每一项都依赖 maker 自身判断之外确立的事实。这就是 maker-checker 规则的一句话版本。
回到开头的失败：40 分钟、50 美元和同样的 3 次尝试。缺少的是无进展检查，不是更好的 prompt。重写 prompt 可以改变每次尝试的措辞，却无法让 run 发现自己已经卡住。
Loop Engineering会构建 heartbeat、spine、停止机制、checker 和 gate。Trusting the Checker则会追问 checker 本身是否值得信任。
概念 8：Human gate 是出口，不是停止
run 还有一种退出方式，与上面 4 种不同。
停止机制让 run 安全失败，gate 则让 run 在获得帮助后成功。
它之所以重要，源于一个容易说却难以牢记的观念：模糊不等于错误。
agent 遇到真正两可的决定，并不代表它出了故障。invoice 4471 匹配两笔付款，两者得分都是 0.52。这不是匹配器的 bug，而是数据本来的样子。但没有 gate 时，agent 只有两个选择，而且都很糟糕：失败并丢弃 9 轮有效工作，或猜测。
**猜测更危险。**这一点值得认真学习，因为它与直觉相反。崩溃很响亮，猜测却很安静，而且看起来与正确答案完全一样：格式相同、信心相同、在报告中的位置也相同。下游无人能分辨。失败的 run 会被修复，猜测的 run 则会在电子表格里留下一个悄悄出错的数字。
gate 应事先写好，而不是临场决定。触发条件就是图左侧的内容：信心低于你设定的阈值、价值高于你设定的上限，或任何难以撤销的操作。gate 触发后，案例会交给指定的人。应付账款部门的 Ayesha 打开案例，看到 invoice 4471 和两笔候选付款。她记得客户在 3 月付过两次款，大约 20 秒就能选出正确一笔。
她的回答不会结束 run，而会作为新证据重新进入，让 run 从暂停处继续。
第 3 部分：使用地图
概念 9：哪一层出了问题？
这就是地图的价值。每层都有可识别的失败方式，因此症状会指向相应界面。
| 你看到的现象 | 首先查看哪里 | 修改什么 |
|---|---|---|
| 输出形式或语气错误，但任务理解正确 | Prompt | 最弱的元素：示例、指令或输出形式 |
| 回答自信、流畅，但事实错误 | Context | curator：放入了什么、顺序如何、丢弃了什么 |
| 报告未经证明的成功，或忽略失败的工具调用 | Harness | 工具、错误处理，以及 beat 必须证明什么 |
| 错误答案未经检查就到达人或系统 | Loop | checker、由谁选择标准，以及它是否曾拒绝过任何结果 |
| 永不停止、过早停止，或本应询问时选择猜测 | Loop | 停止机制与 gate |
关于这张表，有两点需要坦白。
**它是搜索顺序，不是判决。**失败经常跨越边界。每一行都应理解为「先看这里」，而不是「责任一定在这里」。概念 12 会讨论真正难以区分的情况。
**这张表要打破的习惯。**多数团队会在错误的层调试，原因完全可以预测，并非愚蠢。agent 花 50 美元反复尝试，大家便重写系统 prompt。prompt 没问题，只是缺少无进展检查。但 prompt 能在 10 秒内修改。压力之下，人们会改容易改的东西，而不是实际损坏的东西。**动手前先大声说出层名，就是全部纪律。**这只花 5 秒，却决定你是修 1 次还是 6 次。
概念 10：你实际拥有哪几层？
你不会在每个项目中都构建 4 层，很多时候会租用其中 3 层。了解所有权，才能知道哪些建议真正适用。
| 层 | Mode 1：用通用 agent 解决问题 | Mode 2：制造工作者 |
|---|---|---|
| Prompt | 大部分属于你。平台拥有自己的系统指令和工具说明。 | 属于你，只写一次并重复使用。 |
| Context | 部分属于你：附加什么、何时清空。压缩和检索属于 harness。 | 属于你。curator 由你编写。 |
| Harness | 租用，并可通过工具、skill、hook 和项目指令进行部分配置。 | 属于你。 |
| Loop | 大部分租用。平台设置 loop，但可能开放上限与审批配置。 | 属于你。每个停止机制都由你编写。 |
在 Mode 1 中，「添加无进展检查」并不是可以执行的指令，因为没有相应文件。你在外两层的任务不同：**了解租用的行为。**harness 在哪里压缩窗口，压缩时丢掉什么？工具调用失败后是否静默重试？任务中途耗尽空间时会怎样？这些都是关于现有产品的可回答问题，答案会改变你的工作方式。
在 Mode 2 中，4 层都属于你，也不会有人替你限制 beat。
在 Mode 1 中读完本页后得出结论：「这些我都做了，因为工具已经全都做了。」
工具完成的是它自己的工作。你将要构建的工作者，没有工具替它完成你的工作。Claude Code 会限制自己的 beat，却不会限制你编写的 loop。演示正是在这道缝隙里变成生产事故。
**查清租用了什么（4 分钟）。**选择最常用的 agent。查询前，先写下对下面 3 个问题的猜测。先猜很重要，因为猜测与真实答案之间的距离，正是你不知道自己在信任的部分。
- 窗口装满时，harness 会移除什么？是否通知你？
- 工具调用失败时，是否重试？重试几次？你能否看到？
- run 在任务中途达到上限时，已经完成的工作会怎样？
现在去查清。文档能回答一部分，第 1 个问题还可以直接测试。运行一次长会话，早期明确 3 项具体决定，继续工作直到工具压缩对话，再让 agent 重述 3 项决定。无法重述的内容，就是 harness 认为你不需要的内容。
把答案写在团队能看到的地方。在 Mode 1 中，这份短文档就是你的 context 工作和 loop 工作。它不是同一工作的缩小版，而是另一项工作。
概念 11：Graph 位于哪里
graph engineering 被广泛讨论，但 graph 不是第 5 层。
四层描述一条执行路径：一条消息、一个窗口、一个 beat、一个 run。graph 描述的是拓扑：接下来运行什么、每条边传递什么，以及谁检查谁。
四层描述一个节点内部发生什么，graph 描述节点之间发生什么。
节点不一定是 agent。它可以是函数、规则、工具调用、human gate、测量、一个 beat、整个 loop 或完整 agent。多 agent 系统只是 graph 的一种。
本书区分这个词的 3 种用途：
- 执行图决定接下来运行什么，以及状态如何在步骤之间移动
- 记忆图保存实体、发现和来源，供之后的 run 使用
- 治理图记录哪些组件为其他组件提供信息、执行检查、批准和施加限制
这些标签是本书的地图，不是行业标准词汇。
一个真实 graph、6 个节点、1 个 agent。
以概念 8 的夜间应付账款流水线为例：
- **拉取。**函数读取付款和未结发票，再转换成统一格式。不涉及模型
- **路由。**固定规则把金额超过 50 万卢比的发票标记为需要人工审批，无论信心如何
- **匹配。**完整 agent 使用四层提出匹配并附上信心分数
- **关口。**Ayesha 决定低信心或高金额案例，答案作为新证据返回匹配节点
- **证明。**函数比较匹配总额和账单总额，不一致就停止流水线
- **入账。**函数写入已接受的匹配，并把未解决案例送去复核
两个条件会把工作送到关口，其决定再返回匹配。每条边都说明自己传递什么。
只有匹配节点是 agent。其他节点是确定性代码、规则、人员和测量。graph 协调它们，却不假装它们属于同一类型。
查看匹配节点内部，就会看到本课第一幅图：loop、harness、context、prompt。概念 1–8 描述的一切都发生在这个节点内。开始询问前后应发生什么时，graph 才真正开始。
证明节点包含概念 6 缺少的检查。它位于匹配节点外，不能被匹配节点跳过，而且只接收需要的值。这就是治理设计：制作匹配的节点不能推翻判断它的测量。
边与节点同样重要。拉取节点发送标准化记录，匹配节点返回建议匹配和信心分数，关口返回一项人工决定。graph 难以调试时，边的契约不清通常就是原因。
token 成本也主要位于匹配节点。与 agent 相比，另外 5 个节点几乎不花钱。因此，「我们构建了 graph」没有透露多少成本信息。应统计 agent 节点、检查运行频率并实际测量。
如果只有一个节点调用模型，6 节点 graph 的成本可能低于单个 agent 工作流。盒子数量不是成本模型，内部的自适应工作才是。
还要记住两项提醒。2025 年 6 月，Anthropic 报告其单 agent 研究系统大约使用聊天 4 倍的 token，多 agent 系统大约使用 15 倍。2 这是一个系统在特定时间的测量，不是常数。agent 密集型 graph 必须证明成本合理。
Anthropic 还提醒，多 agent 设计不适合所有工作者都需要同一 context，或各部分高度依赖的任务。3 此后编码工具已经变化，但底层约束仍在。工作者越需要同一 context 和彼此的中间结果，并行 agent 带来的收益就越少。
Graph Engineering会构建这些内容，也会说明什么时候不该构建。
概念 12：框架与你对抗时
一张从不质疑的地图，最终会变成仪式。因此，这里要有意让它变得不舒服。
**有些失败确实横跨两层。**悄悄丢弃最早对话的策略属于 context 决定，但它可能只有在 loop 允许 run 持续到窗口装满时才造成麻烦。哪层坏了？老实说，两层都是。更便宜的修复位于其中一层，而具体是哪层取决于你的系统，不取决于这张表。
**有些诊断指向一层，修复却位于另一层。**这是最有用的情况，不是缺陷。agent 报告未经证明的成功时，诊断位于第 3 层，因为它涉及 beat 对自身能知道什么；修复通常位于第 4 层，因为来自外部的成功标准才能让结论可信。框架把你送到症状之外，恰恰说明它完成了工作。
**有些失败不属于任何一层。**有时模型就是无法达到所需质量，再怎么排列容器也创造不出不存在的能力。命名各层是为了停止猜测，不是让弱模型变强。如果确实清除了四层问题，工作仍然很差，诚实选择是更强模型、更小任务或不同方法。Trusting the Checker会帮助你判断。
**也不是每个项目都需要四层。**只运行一次的任务不需要 loop，强行构建也是浪费，而且正以本节不断警告的方式产生成本。四层描述存在的东西，并不要求你全部构建。
第 4 部分：练习
练习：说出层名
下面有 8 个失败案例。为每个案例指出应首先查看哪层，以及要做的一项修改。打开答案前先写下自己的回答。认出答案远比自己产出答案容易，而真正的技能只有后者。
1. 你要求用包含 5 个指定列的表格总结竞争对手，返回的却是 3 段精彩文字，内容准确。
答案
**Prompt。**模型理解了任务，也完成了工作，只有形式错误。应提供所需表格示例，而不是用更多文字解释为什么需要表格。这是本层最清楚的特征：正确工作，错误容器。
2. agent 自信地说你的价格方案把使用量限制在 5,000 次请求，而价格页面写的是 50,000 次。agent 读过该页面。
答案
**Context。**对于本应位于窗口内的文档，回答自信、流畅却错误，几乎就是特征。某些内容经过压缩、截断或被旧副本替换，训练知识用看似合理的数字填补空洞。运行 curator 测试：哪条规则把页面放入窗口？是否放入了全部内容？
3. 夜间 run 报告「所有测试通过，修改已提交」。早晨却发现测试套件从未运行，构建失败。
答案
**诊断看 harness，修复看 loop。**这正是概念 6。harness 中应该做两件事：用 hook 真正运行套件，并且不通过就不允许 beat 结束。但这只证明套件运行过，而选择套件作为标准的仍是 run 本身。可信版本需要外部停止机制：由你事先选择、由 maker 之外的东西执行成功条件。如果想靠在 prompt 中加「始终运行测试」解决，请重读概念 6。
4. 一个 run 在下午花完预算，日志显示同样 3 种方法只换了少量措辞，不断重试。
答案
**Loop。**缺少无进展检查，可能也没有支出上限。这就是本课开头的故事。prompt 是最诱人的查看位置，也会浪费你的下午。
5. 发票匹配 agent 夜间处理了 300 张发票，并报告全部匹配。抽查发现有几张对应两笔同样合理的付款，它悄悄选了一笔。
答案
**Loop，具体是缺少 gate。**没有组件故障。agent 遇到真正模糊的决定，只有猜测或失败两个选择。它选择猜测，而结果与另外 290 个正确答案完全相同。应事先写好触发条件（信心低于阈值、金额高于上限），把案例交给人。
6. 你让 sub-agent 读取 40 个支持工单。它返回 3 段整洁摘要，其中两项结论错误。
答案
**Harness。**sub-agent 通过工具调用到达，却运行完整技术栈的嵌套副本，因此无论读得多好，摘要都充满信心。你没有看到 40 个工单，下游也不会看到。修复点是要求它返回什么：应返回可核查的引文、工单 ID 和证据，而不是必须信任的结论。
7. 一次长会话在 20 个回合内进展顺利，之后 agent 开始反驳早期共同决定，仿佛它从未发生。
答案
**Context。**窗口装满后，有内容离开了。丢弃策略由 harness 而非你设定，而且恰好丢掉了最需要保留的决定。应把决定持久保存在对话外，例如规则文件、spec，或每次重新附加的笔记，而不是相信聊天记录会永远保留。
8. 你已经排除一项困难研究任务的四层问题：prompt 精确，窗口材料正确，harness 已验证，loop 会正确停止和检查。输出仍然平庸。
答案
**哪层都不是。**概念 12 就是为此存在。四层描述可能在哪里损坏，却不会创造能力。诚实的下一步是换更强模型、缩小并收紧任务、改用另一种方法，或承认这项工作需要人。永远不会错的框架没有帮助。
用自己的失败来练习
上面的练习用于校准。现在把地图迁移到真实失败。
回想 agent 最近一次产出错误或昂贵结果的经历，依次回答：
- **哪个工作单位出错？**一次模型调用、窗口、一个 beat，还是整个 run？
- **之后改了什么？**是否位于同一层？
- **什么原本能发现问题？**说出机制、所属层，以及由谁选择标准。
来看一个例子。
**失败。**法务运营团队要求 agent 找出所有自动续期的供应商合同。它报告审阅了 40 份合同并找到 3 份续期。两个月后，又有 3 份合同续期，因为它们使用的是「evergreen term」。
1. 哪个单位失败？
报告形式正确，40 份合同也都可用。缺少的是「已审阅」的含义。run 把成功定义为找到一个短语，再按自己的定义判断自己。失败的是整个 run。
2. 团队改了什么？
他们向 prompt 添加更多短语：evergreen、rolling term、self-renewing。这能修复已知示例，却抓不住下一种陌生表述。失败位于第 4 层，他们却改了第 1 层。
3. 什么能发现问题？
法务运营负责人应在运行前选择成功条件：
- 每份合同必须返回带页码的续期条款引文；或
- 返回未找到续期条款，再交给人处理。
命令可以检查 40 份合同是否生成 40 份没有空白的完整结果。规则由法务负责人选择，agent 无法降低要求。
这样，遗漏的合同会变成可见问题，而不是静默成功。团队也许仍需改进 prompt，但 loop 会暴露下一种陌生短语，而不是把它认证为完成。
真正有用的技能不是立即说出正确层，而是检验最诱人的答案，并拒绝停在最容易修改的层。
下面的 prompt 可以帮助诊断自己的案例：
我最近遇到一次 agent 失败：[描述你的要求、返回内容，以及如何发现错误]。我想判断四层中的哪一层出了问题：prompt（一次模型调用）、context window（模型能看到什么）、harness（一个 beat，即运行工具并决定 beat 结束的代码），还是 loop（整个 run：什么启动、停止和检查它）。请询问缩小范围所需的问题，再给出最可能的判断，并说明什么原本能更早发现它。如果我选错层，请直接反驳。
练习中的 8 个案例都有清晰特征，你的真实失败则不会。完整分析一个真实案例，比认出全部 8 个答案更能培养能力。
离开本课时应带走什么
每个概念一行，最后是一句话。
- **概念 1。**四个容器逐层嵌套，不是梯子上的 4 个步骤。每个 beat 仍会构建 prompt
- **概念 2。**每层由工作单位定义：一次模型调用、窗口、一个 beat、整个 run。即使词汇改变，这个问题仍然有效
- **概念 3。**prompt 是一次模型调用。只修最弱的一项，不要同时修改 5 项。它最容易修改，也因此常替其他层背锅
- **概念 4。**窗口是模型掌握的事实，训练知识会填补窗口遗漏。curator 始终存在，负责排序、压缩和丢弃。指向一份文档，说出哪条规则把它放进来
- **概念 5。**beat 是一条指令及其后直到 agent 安静的一切。sub-agent 通过工具调用到达，却运行完整嵌套技术栈，返回并未挣得的信心
- **概念 6。**beat 可以证明一项具体检查通过，却无法说明通过是否足够，因为 maker 不能判断什么才算完成
- **概念 7。**loop 提供 beat 无法自行提供的 heartbeat、spine 和 4 个外部停止机制，且没有一个让 maker 定义成功
- **概念 8。**human gate 是出口，不是停止。模糊不是错误；猜测比崩溃危险，因为它看起来像答案
- **概念 9。**每层都有可识别的失败方式。先说出层名，再寻找修复
- **概念 10。**Mode 1 租用 3 层并配置 1 层；Mode 2 的 4 层都属于你。「我的工具会做」指工具自己的工作，不是工作者的工作
- **概念 11。**graph 不是第 5 层。四层描述节点内部，graph 描述节点之间。节点不全是 agent，token 倍率值得按自己的任务测量
- **概念 12。**地图是搜索顺序，不是证明。有些失败跨层，有些来自模型本身，也不是每个项目都需要四层
最后是唯一值得记住的一句话：
好 prompt 会在坏 context 中失败。好 context 会在裸 harness 中失败。好 harness 没有 loop 就会闲置。所以，出问题时先说出层名，再着手修复。
这就是为什么在演示中可用的 agent 常在生产环境失败。演示只需要内层，外层从未构建。问题不在模型，而在缺少模型周围的层。
接下来去哪里
现在你有了地图。本节其余内容是地图所描绘的疆域，每门课只负责一层：
- Harness Engineering 构建第 3 层，把你的要求变成强制执行的规则
- Loop Engineering 构建第 4 层：heartbeat 类型、spine、maker-checker 和 human gate
- Trusting the Checker 回答构建第 4 层后立即出现的问题：中心的 checker 是否可靠
- Graph Engineering 处理一条执行路径之外的拓扑，并以另外两门课为基础
- Leaving the Laptop 为本节收尾：loop 可信之后，究竟应该在哪里运行
第 1、2 层也有前面的课程：2026 年 AI Prompting讲 prompt，Agentic Coding第 2–4 部分讲窗口。
真正能构建可用 agent 的人，不是写出最聪明 prompt 的人，而是让 loop 知道何时停止、何时询问的人。