第 6 章：五层工程的统一视角与实践选择

本章解锁：你能运用统一决策框架判断任务该停在哪一层，识别 Agentic Design Debt，并理解五层叠加而非替代的关系。
预计时间：20 分钟

---

起点与环境

前置章节：第 1-5 章全部

经过前五章，你已经：

• 画出了五层演进的全景图（第 1 章）
• 拆解了 Loop 的五个构建模块（第 2 章）
• 设计了一个完整的 Agent Loop（第 3 章）
• 识别了从 Loop 到 Graph 的跃迁信号（第 4 章）
• 设计了一个包含边协议和失败恢复的 Agent Graph（第 5 章）

现在我们退后一步，把所有内容放在一起看。

---

为什么现在做

你现在面临的最大风险不是"不知道怎么做"，而是"知道太多了不知道选哪个"。

• 一个新任务来了，你应该先优化 prompt 还是直接设计 loop？
• 你发现 loop 有点吃力了，是真的需要 graph 还是 loop 没设计好？
• 团队里有人提议"上 Graph"，你怎么判断这是合理的架构选择还是过度设计？

这一章给你一个统一的决策框架，以及一个在任何层级都适用的警告：越自动的系统，验证责任越重。

---

动手实践

6.1 五层叠加关系的可视化

先把五层的叠加关系画清楚。这不是"楼梯"——你不是从一层爬到另一层，而是每一层都在下面那层之上叠加。

关键认知：Graph 不会让 Loop 消失，Loop 不会让 Prompt 消失。

回顾第 5 章的方案评审 Graph：

• Graph 层定义了架构评审、安全评审、性能评审三个节点的协作拓扑
• 每个评审节点内部是一个 Loop——观察方案、分析、生成报告、验证报告质量
• 每个 Loop 的每一步都需要Harness 层提供的工具（文件读取、搜索、格式化输出）
• Harness 需要把正确的Context 喂给模型（方案文档、评审标准、历史评审经验）
• Context 之上，每个 agent 的 system prompt 仍然是经过精心设计的 Prompt

五层全部在场，没有一层是多余的。

6.2 统一决策框架

面对一个新任务，用这个决策框架判断你应该在哪一层投入精力。

任务来了
│
├── 模型能做但做得不好？
│   └── 是 → 检查 Prompt（第 1 层）
│       └── Prompt 没问题？
│           └── 检查 Context（第 2 层）
│
├── 模型的回答质量 OK，但执行不稳定？
│   └── 是 → 检查 Harness（第 3 层）
│       工具配置对了吗？权限给够了吗？错误处理有吗？
│
├── 单次执行 OK，但需要持续运行或迭代纠错？
│   └── 是 → 设计 Loop（第 4 层）
│       需要什么触发方式？停止条件？记忆机制？
│
└── 单 Agent 的 Loop OK，但需要多角色独立协作？
    └── 是 → 设计 Graph（第 5 层）
        节点怎么分？边上传什么？共享状态怎么设计？

实践中的常见路径：

大多数任务不需要到第 5 层。根据社区讨论中的经验分布：

层级	大约覆盖的任务比例	典型任务
第 1-2 层	60%	单次问答、代码生成、文档撰写
第 3 层	20%	需要工具调用的复杂任务、需要沙箱的执行
第 4 层	15%	持续运行的自动化、需要迭代纠错的任务
第 5 层	5%	多角色独立协作、需要仲裁和收敛的复杂流程

这个分布告诉你什么？ 大多数时候你的瓶颈在底层，不在顶层。在急着设计 Graph 之前，先确认你的 Prompt、Context 和 Harness 都足够好了。

上面的决策树和比例表可以直接写成一个函数，给定任务特征，返回建议停在哪一层：

# decide_layer.py — 统一决策框架的代码化版本
def decide_layer(
    model_quality_ok: bool,      # 模型回答质量是否达标
    context_sufficient: bool,    # 上下文信息是否充分
    execution_stable: bool,      # 单次执行是否稳定（工具/权限/错误处理）
    needs_continuous: bool,      # 是否需要持续运行或迭代纠错
    needs_multi_role: bool,      # 是否需要多个独立角色
    roles_have_conflict: bool,   # 角色之间是否有结论冲突或仲裁需求
) -> dict[str, str]:
    """基于任务特征，返回建议的工程层级和行动方向。"""

    if not model_quality_ok:
        return {"layer": "1-Prompt", "action": "优化 system prompt 和 few-shot 示例"}

    if not context_sufficient:
        return {"layer": "2-Context", "action": "检查 RAG 策略、上下文窗口内容和工具返回值"}

    if not execution_stable:
        return {"layer": "3-Harness", "action": "检查工具配置、权限、沙箱、重试和超时策略"}

    if needs_continuous:
        if not needs_multi_role:
            return {"layer": "4-Loop", "action": "设计触发方式、停止条件、记忆机制和 Maker-Checker"}
        if not roles_have_conflict:
            return {"layer": "4-Loop(multiple)", "action": "多个独立 Loop 并行即可，不需要 Graph"}
        return {"layer": "5-Graph", "action": "设计节点拓扑、边协议、共享状态和仲裁机制"}

    return {"layer": "1-2 Prompt/Context", "action": "单次任务，聚焦 prompt 和 context 质量"}


# 使用示例
result = decide_layer(
    model_quality_ok=True, context_sufficient=True, execution_stable=True,
    needs_continuous=True, needs_multi_role=True, roles_have_conflict=True,
)
print(result)
# => {'layer': '5-Graph', 'action': '设计节点拓扑、边协议、共享状态和仲裁机制'}

这个函数就是前面决策树的代码映射。实际使用时你不一定要运行它——更重要的是把这串 if 内化为直觉：从底层往上逐层排查，瓶颈在哪一层就停在哪一层。

6.3 Agentic Design Debt（自动化设计债）

Addy Osmani 在 Loop Engineering 的讨论中特别警告了一个风险：

三件 Loop 没解决的事：验证还是你的责任、理解会腐化、最舒服的姿势往往最危险。

这就是 Agentic Design Debt——自动化设计债。让我们逐个拆解。

验证还是你的责任

Loop 和 Graph 可以自动执行、自动验证、自动仲裁。但验证体系本身是否正确，这个问题无法被自动化。

举个例子：你的代码审查 Loop 的 checker 用"测试是否通过"作为验证标准。如果测试本身就不完善（覆盖了功能但没覆盖边界情况），那 checker 通过了也不意味着代码是对的。

自动化系统越复杂，验证体系的盲区越难被发现。 因为一切"看起来在正常运行"。

这就是 Addy Osmani 说的"最舒服的姿势往往最危险"：当 loop 日复一日平稳运行，你很容易放松警惕，不再检查验证体系本身是否还有效。

理解会腐化

一个运行了三个月的 loop，你还记得它每一步的逻辑吗？你还记得当初为什么选了这个停止条件、为什么 checker 用了那个 prompt 吗？

Loop 和 Graph 越自动，你"不需要"理解它们的动机就越强。但你对系统的理解一旦腐化，出了问题你就无法判断是 loop 的 bug 还是预期行为。

对策：

• Loop 和 Graph 的配置文件中写清决策理由（为什么选这个模型、为什么这个节点标记为 critical）
• 定期（每月？每季度？）做一次"系统理解审计"——不是审计系统运行，是审计你对系统的理解

Agentic Design Debt 的三种表现

表现	症状	风险
验证漂移	验证标准不再匹配实际需求，但 loop 仍然"通过"	系统产出质量悄悄下降，但没人发现
理解腐化	设计者不再理解系统为什么这样运行	出问题时无法有效排查，只能推倒重来
抽象上瘾	遇到新问题就加新层，而不是检查现有层是否足够	系统复杂度指数增长，维护成本失控

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.
— Addy Osmani

6.4 从"个人能力"到"组织能力"

Josh Simmons 在讨论 Graph Engineering 时写下了一句总结：

Graph Engineering 真正代表的，是 Agent 工程开始从"个人能力"走向"组织能力"。

把这句话和五层演进放在一起看：

• Prompt Engineering：一个人在和一个模型对话——个人能力
• Context Engineering：一个人在管理一个模型的视野——个人能力
• Harness Engineering：一个人在搭建一个模型的运行环境——个人能力
• Loop Engineering：一个人在设计一个 Agent 的执行系统——开始触及系统能力
• Graph Engineering：一个人（或团队）在设计多个 Agent 的协作组织——组织能力

从第 1 层到第 4 层，核心仍然是"一个 Agent 的能力"。从第 5 层开始，问题性质变了：你在做的不再是"让一个 agent 变强"，而是"让多个 agent 组成一个有效的团队"。

这也是为什么 Graph Engineering 的很多问题，在软件工程的其他领域早就遇到过：

• 微服务编排：怎么让多个服务协调完成一个业务流程
• 分布式系统：怎么在节点失败时保持系统可用
• 组织管理：怎么让不同角色高效协作而不是互相扯皮

名字是新的，问题早就存在；底层技术并不新，但工程重心确实发生了变化。
— Josh Simmons

6.5 综合实践：你的决策练习

你的实践任务：对以下五个任务，分别判断它应该停在哪一层，并简要说明理由。

#	任务	你的判断（层级）	理由
1	让 AI 帮你写一封邮件
2	让 AI 每天自动把前一天的 git commit 总结成日报
3	让 AI 修复一个编译错误，直到编译通过为止
4	让三个 AI Agent 分别从用户体验、技术可行性、商业价值三个角度评估一个产品方案
5	让 AI 读取一份 PDF 文档并提取关键信息

参考答案：

#	层级	理由
1	第 1-2 层	单次任务，核心是 prompt 和 context（给模型看什么背景信息）
2	第 4 层	需要定时触发、读取 git 历史、跨天记忆（避免重复总结）、可能需要验证日报质量——典型的 /loop 模式
3	第 4 层	需要迭代纠错——修改代码 → 编译 → 失败 → 再修改——典型的 /goal 模式，需要 Maker-Checker 和停止条件
4	第 5 层	三个独立领域的评估 + 需要综合仲裁 + 可能存在结论冲突——符合 Graph 的使用条件
5	第 2-3 层	单次任务，核心是 Context（把 PDF 内容正确地喂给模型）和 Harness（PDF 解析工具配置）

6.6 未来展望

最后留一个开放的思考。

2022 年到 2026 年，AI 工程经历了五层演进。按照这个趋势，第六层可能是什么？

一些社区讨论中的方向：

• Multi-Graph Orchestration：多个 Graph 之间的协调（当一个组织有多个 Agent 团队时）
• Adaptive Topology：Graph 的拓扑结构不是预先画好的，而是根据任务动态调整的
• Agent Governance：当 Agent 系统足够复杂时，谁来治理 Agent？合规、审计、责任归属

这些方向有一个共同的底层逻辑：控制点继续上移，从"怎么做"走向"怎么管"。

但不管未来怎么演进，Addy Osmani 的那句话始终适用：

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

不管你用的是 Prompt、Loop 还是 Graph，你始终是那个最终负责验证结果、理解系统、承担后果的人。

---

理解检查

1. 综合题：一个团队在考虑把他们的 CI/CD 流水线改造成 Agent Graph——代码检查 Agent、单元测试 Agent、集成测试 Agent、部署 Agent 四个节点串行执行。你怎么评估这个方案？（提示：回想 5.5 节"何时不该用 Graph"）

2. 概念题：为什么说"验证体系的盲区随着自动化程度增加而更难被发现"？举一个具体例子。

3. 反思题：回顾你在第 2 章做的场景评估和第 3 章设计的 Loop。现在你觉得那个设计有什么可以改进的地方？（这是一道开放题，没有标准答案）

参考答案：

1. 这个方案很可能是过度设计。四个步骤是固定顺序的串行 pipeline——代码检查完才能测试，测试完才能部署。它们之间没有结论冲突需要仲裁，没有并行需求，边上传递的就是"通过/不通过"这样的简单信号。这用传统的 CI/CD pipeline 就能解决，甚至用一个 Loop（/goal 模式：反复修复直到所有步骤通过）就够了。拆成 Graph 只增加了协调开销和故障点。

2. 假设你有一个代码质量检查 Loop，checker 使用"lint 通过 + 测试通过"作为验证标准。三个月后，业务逻辑变复杂了，但测试用例没跟上——测试覆盖率从 90% 降到了 40%，但 lint 和现有测试仍然通过。loop 每天"正常"运行，checker 每次都通过，没有人意识到验证体系已经失效。这就是验证漂移——系统看起来健康，实际上在用过时的标准给不合格的产出盖合格章。

3. （开放题，学习者自行反思）

---

发生了什么

这一章你建立了五层工程的统一认知。

核心概念回顾：

• 五层叠加：新层不替代旧层，而是在旧层之上增加控制维度。Graph 中的每个节点可能是一个 Loop，Loop 的每一步需要 Harness，Harness 需要 Context，Context 需要 Prompt
• 统一决策框架：从底层开始检查，瓶颈在哪一层就在哪一层投入
• Agentic Design Debt：验证漂移、理解腐化、抽象上瘾——自动化程度越高，这三种风险越大
• 从个人能力到组织能力：Graph Engineering 标志着 Agent 工程的关注点从"一个 Agent 的能力"转向"多个 Agent 的组织效能"
• 工程师身份不变：不管用了多少层自动化，你仍然是系统的最终负责人

---

常见误区

误区	纠正
"学到第 5 层就毕业了"	五层不是课程进度。大多数任务停在第 1-2 层就够了。判断力比知识量更重要。
"自动化程度越高越好"	每增加一层自动化都增加一层验证责任。如果你验证不了，那层自动化就是定时炸弹。
"Graph Engineering 是大公司才需要的"	规模不是唯一因素。一个人也可能需要 Graph——如果你的任务确实需要多个独立角色协作。但在你确认这点之前，先尝试简单的方案。
"我需要完全掌握所有工具才能开始"	不需要。从你当前的瓶颈层开始，解决实际问题。工具和框架在快速变化，原则和思维方式才是持久的。
"这份教程过时了因为技术在变"	五层的具体工具会变（今天的 MCP 可能被明天的新协议替代），但五层的问题结构不会变——表达任务、提供信息、稳定运行、持续纠错、多方协作——这些是工程的基本问题。

---

本章检查点

完成以下清单后，恭喜你，你完成了整份教程：

• [ ] 我能画出五层叠加关系图
• [ ] 我能用决策框架判断一个任务该停在哪一层
• [ ] 我能解释 Agentic Design Debt 的三种表现
• [ ] 我能对一个"看起来需要 Graph"的方案做出合理评估
• [ ] 我理解了"Build the loop, but stay the engineer"的含义

---

全教程回顾

你在六章中建立了一个完整的认知体系：

章节	你获得了什么
第 1 章	五层演进的全景视图和杠杆点上移的逻辑
第 2 章	Loop 的五个构建模块和外部记忆的重要性
第 3 章	设计 Loop 的四步骨架、两种触发模式和 Maker-Checker 模式
第 4 章	从 Loop 到 Graph 的四个信号和 Graph 的三要素
第 5 章	Graph 的边协议、共享状态、失败恢复和人工确认
第 6 章	五层统一决策框架和 Agentic Design Debt 意识

最后一个思考：

这份教程是 2026 年 7 月的快照。到你读到它的时候，工具可能变了，框架可能变了，甚至可能出现了第六层。但有一样东西不会变：

你是工程师，不是操作员。你设计系统，不只是启动系统。你对结果负责，不只是对过程负责。

这就是从 Prompt 到 Graph 的整段旅程中，始终不变的底色。

---

← 上一章：设计可靠的 Agent Graph | 回到教程首页 →