BINARY GARDEN
2026-08-31 // AIAgent · Engineering · sibuchen

Engineering

Agent 的五层 Engineering 架构

从「怎么说模型才答得对」，到「五个 Agent 怎么分工」——一个工程师真正要做的五件事。

一、先问一个问题：Agent 是「用」出来的，还是「造」出来的？

2023 年，Shawn Wang（swyx）写了一篇被反复引用的《The Rise of the AI Engineer》，给这个新岗位定了个调：它既不是写提示词的 Prompt Engineering（太窄），也不是训练模型的 ML Engineering（太偏），而是「专门把 AI 落地成产品」的工程师。

到了 2025、2026，这个词的后缀悄悄变成了「Agent」。招人 JD 里开始出现 Agent Engineering，人们讨论的不再是「怎么让模型答得更好」，而是「怎么让一个（或一群）模型自动把事做完」。

但「让模型把事做完」这句话，拆开来看是一堆非常具体、非常工程化的问题：

  • 提示词模板怎么写，模型才答得对？（Prompt Engineering）
  • 该把哪些信息塞进上下文、哪些挡在门外？（Context Engineering）
  • 模型干活的时候，怎么约束它、防住它的错、守住安全底线？（Harness Engineering）
  • 一个 Agent 反复试的时候，什么时候继续、什么时候停下？（Loop Engineering）
  • 多个 Agent 一起上的时候，怎么分工、怎么协作？（Group Engineering）

我把这五件事叫做「Agent 工程的五层」。坦白说：我在可检索的权威文献范围内并没有找到这五个词的任何原始出处——它们更像是一种归纳，而不是某个权威提出过的框架。但它们的每一层内容都有非常成熟的对应物：提示词工程、上下文工程、马鞍工程、循环工程、协调工程。

换句话说：包装可能是新的，内容几乎都是旧的。 而这恰恰是最有意思的地方——Agent 时代真正稀缺的，从来不是新的魔法，而是把这些「旧」的工程纪律，用在对「非确定性系统」的驯化上。

下面一层一层拆。

二、Prompt Engineering：怎么说，模型才答得对

提示词工程听起来最「低级」，却是所有人都绕不开的第一层。官方定义很朴素：以可复现的方式，写出让模型持续满足要求的指令。

这句话的关键词是「可复现」和「持续」。所以 Anthropic 和 OpenAI 的官方文档在教你任何技巧之前，先要求你做三件事：定义清楚的成功标准、一套能实测的评估方法、一个第一版草稿提示词。 没有这三样，任何「优化」都是拍脑袋。

然后是几条经过反复验证的「心法」：

  • 新员工隐喻：把模型当作一个聪明、但完全不了解你工作规范的新员工。你不说清楚，它就只能猜。
  • 同事测试：把你的提示词拿给一个对任务毫无背景的同事，如果他困惑，模型也会困惑。这一条几乎能过滤掉九成烂提示词。
  • 示例比描述管用：few-shot 是官方公认最可靠的「控制输出格式、语气、结构」的手段，3–5 个「相关、多样、结构化」的示例通常效果最好。
  • 查询放结尾：长上下文场景下，把长文档放开头、把真正的问句放最后，响应质量可以提升最多 30%。
  • 思维链的反转：老模型时代，手把手教 "Let's think step by step" 是神技；但对今天的前沿模型，一句泛化的 "think thoroughly" 常常优于手写分步计划——模型自己的推理，经常超过你能预设的步骤。

还有一个容易被忽略的「坑」：提示词会过时。 为老模型设计的 "CRITICAL: You MUST use this tool..."，到了新模型上会变成「过度触发」——模型疯狂调用不该调的工具。官方甚至专门开了一节「Remove over-prompting」。

Prompt Engineering 的真正成熟标志，是把提示词从一个「文本」变成一件「软件制品」：变量化模板、版本化进代码仓库、复用型指令下沉到 CLAUDE.md 或 skills、由 eval 套件守护回归。一个被版本管理和 eval 守护的提示词，才算工程；一个飘在聊天框里的提示词，只是运气。

三、Context Engineering：给模型看什么，比怎么写更重要

Anthropic 在 2025 年抛出了一个很有分量的说法：Prompt Engineering 其实是 Context Engineering 的一个子集。 后者管的是更根本的问题——在采样时，喂给模型的那组 token 到底该怎么选。

核心原则一句话：找到能最大化目标结果的最小高信号 token 集合。

为什么「最小」这么重要？因为有个被反复验证的现象叫 context rot：上下文里的 token 越多，模型准确回忆信息的能力越差。每一块新塞进来的信息，都在消耗有限的注意力预算。还有那篇著名的《Lost in the Middle》论文：模型对长上下文中间位置的信息利用最差，重要证据放在开头或结尾效果最好——一条 U 型曲线。所以「把检索到的段落一股脑塞进去」是错的，你得把重要的挪到两端。

这直接引出了 Context Engineering 日常要做的四个决定：

  1. 检索还是全量塞？ 一个很实用的阈值：知识库小于约 20 万 token（约 500 页），全量放进 prompt 更简单；更大才上 RAG。配上 prompt caching（缓存读取比基础输入便宜 90%），「全量入上下文」的成本可以低到惊人。
  2. RAG 怎么做得更好？ 一个立竿见影的招是 Contextual Retrieval：给每个 chunk 前置一句 50–100 token 的背景说明，再结合重排序，检索失败率能从 5.7% 降到 1.9%——降幅 67%。
  3. 长任务怎么不爆上下文？ 四个机制：compaction（高保真压缩后重开窗口）、结构化笔记/外部记忆（把状态写到上下文之外，比如一个 progress 文件）、sub-agent（大量探索只回传 1000–2000 token 的精炼摘要）、以及清理历史工具原始输出。
  4. 什么时候按需加载？ just-in-time 检索：只保留轻量标识符（文件路径、查询、链接），运行时按需拉取，而不是预先把一切塞进去。Claude Code 就是这种混合策略——CLAUDE.md 前置，glob/grep 按需。

如果说 Prompt Engineering 管的是「措辞」，Context Engineering 管的则是「信息经济学」：每一块 token 都有成本，也都有（可能是负的）收益。给模型看什么，往往比让它怎么说更重要。

四、Harness Engineering：给模型套上一个不会犯错的壳

Harness 这个词直译是「挽具/外骨骼」，我更喜欢叫它「运行底座」。Anthropic 给过一个很漂亮的定义：工具是「确定性系统与非确定性 Agent 之间的契约」。 Harness Engineering 干的，就是把这个契约工程化。

最底层的骨架很简单：模型输出一个 tool_use 块 → 你的代码执行工具 → 把结果放进 tool_result 回传 → 模型继续。但真正的功夫全在细节里：

  • 协议约束：tool_result 必须紧跟对应的 tool_use，而且在消息数组里必须排在文本前面，否则直接 400 报错。这是最容易踩的坑。
  • 工具描述是命门：官方说这是「决定工具性能的最重要因素」，每个工具至少写 3–4 句——做什么、何时该用不该用、每个参数什么意思、有什么限制。另一个反直觉的建议是「合并而非细分」：把 create/review/merge 三个工具合成一个带 action 参数的工具，模型选择反而更准。
  • 工具输出要截断：模型上下文窗口有限，工具只返回高信号信息（语义化的标识符，而不是 UUID），Claude Code 默认把工具响应截在 25,000 token。
  • 防错前移：给工具定义加 strict: true，用 grammar-constrained sampling 保证模型输出的参数严格符合 JSON Schema，省掉运行时校验和重试。

然后是安全。Agent 世界最核心的威胁，是 2023 年被系统提出的 Indirect Prompt Injection：攻击者把恶意指令藏进 Agent 随后会检索到的数据里，就能远程劫持它——因为「处理检索到的 prompt，相当于任意代码执行」。工程上的防线是一套组合拳：

  • 不可信内容只放进 tool_result 块，绝不进系统提示词或用户文本；
  • 对不可信字符串做 JSON 编码，划清边界；
  • 最小权限：Agent 能碰什么、能改什么，默认关到最小；
  • 代码在沙箱里跑（无外网、文件限于工作目录）；
  • 模型看到之前，先用轻量模型筛查工具输出。

至于 MCP（Model Context Protocol），它把「接工具」标准化了，但规范自己写得明白：协议层无法强制安全，靠实现者落实。 工具调用前必须取得用户明确同意——这句写在规范里，但能不能落地，取决于写 harness 的那个人。

一句话总结这一层：把非确定性核心，装进一个确定性外壳。 外壳负责约束、防错、安全；核心只负责「想」。

五、Loop Engineering：什么时候继续，什么时候停下

单 Agent 的迭代循环，是 Agent 区别于「一次调用」的本质。它的原型是 2022 年的 ReAct：模型交替产出「推理」和「行动」，用环境返回的「观察」修正下一步。后来又有了 Reflexion——不更新权重，而是让 Agent 口头反思、把教训存进记忆，下一次试的时候引以为戒。

但 Loop Engineering 要回答的其实就两个问题：继续，还是结束？

先说「什么时候不该用循环」：Anthropic 给了一条很清楚的判定线。如果任务的步骤数可预测、能硬编码，就用 workflow（预定义代码路径）；只有面对「不知道要走几步」的开放问题，才上真正的自主循环。别为了用 agent 而用 agent。

再说「怎么结束」：真实系统里的共识是——停止条件必须有两层。

  • 语义层：任务真的完成了（比如调用了 final_answer，或输出被判定为最终结果）。
  • 机械层：一个硬性的迭代上限。smolagents 用「最大步数」，OpenAI Agents SDK 用 max_turns（超限直接抛异常），LangGraph 用 recursion_limit（当前默认 10007）。这一层是保险丝，不依赖模型自觉。

为什么保险丝这么重要？因为真实系统里排名第一的失败模式，恰恰是「该停不停」：Anthropic 的多 Agent 系统上线初期就发现 Agent「明明结果已经够了还在继续」；Chip Huyen 则点出另一种反面——「虚假完成」，Agent 以为自己做完了，其实没有。

所以成熟的 Loop Engineering 还会做一件事：给 Agent 一个能自我验证的 check。 Karpathy 说过，一个任务「可不可验证」，是它能不能被强化学习优化的最具预测性的特征。落到工程上就是 Claude Code 官方最佳实践的第一条：给它一个能跑的测试、一个能对比的构建或截图——这是你「全程盯着」和「放心走开」之间的区别。

循环的智慧，一半在于知道何时继续，另一半在于知道何时必须停下。

六、Group Engineering：让多个 Agent 分工，而不是让它们开会

当一个问题真的太大、太可并行、或者要对接的工具太多，单个 Agent 的上下文和精力就不够了。这时候轮到 Group Engineering 上场。

主流架构是 orchestrator-worker（主从）：一个 lead Agent 做规划，把子任务并行派发给 3–5 个子 Agent，每个子 Agent 有独立的目标、输出格式、工具和任务边界，干完只回传一份压缩后的结论。这本质上是一种「关注点分离」——每个子 Agent 守着自己的上下文窗口。

其他模式也存在：AutoGen 式的群聊（选一个发言者、广播给所有人，对等去中心化）、源自 1980 年代语音识别系统的黑板架构（共享状态而非消息传递）、以及 OpenAI Agents SDK 里的 handoffs（路由后把会话控制权转交给专家 Agent）。

但这一层最该记住的，反而是两条「劝退」：

第一，多数任务不需要多 Agent。 Anthropic 反复强调：先试「单个 Agent + 良好的上下文工程」，只有任务高度可并行、信息超单上下文窗口、或要对接大量复杂工具时，多 Agent 才真正划算。多数编码任务因为可并行的子任务少、LLM 又不擅长实时协调，反而不适合多 Agent。

第二，多 Agent 的价值本质，要想清楚。 Anthropic 自己披露过一组数据：他们的多 Agent 研究系统比单 Agent 提升 90.2%，但比聊天多花约 15 倍 token，而且「token 用量单独解释了 80% 的性能方差」。这组数字（注意：是厂商自报的内部评估）其实指向一个有点反高潮的结论——多 Agent 的有效，很大程度是「有组织地多烧算力」，而不是协作本身有什么魔法。 换句话说，如果你用同样的 token 预算喂给一个「多步思考 + 工具」的单 Agent，增益未必差多少。

所以 Group Engineering 真正要管理的，不是「怎么让 Agent 聊天」，而是两件更工程化的事：

  • 错误传播：Agent 是有状态的，错误会复利，一步走偏会把整条轨迹带进沟里。缓解手段是从错误点恢复而非从头重启、重试、checkpoint。
  • 规模控制：把「努力程度」显式编码进 prompt——简单查证派 1 个 Agent、3–10 次工具调用；复杂研究才派 10+ 个子 Agent。早期的坑就是简单查询派了 50 个子 Agent，纯粹浪费。

一句话：让 Agent 分工，是为了把问题切成能独立完成的块，不是为了开一场谁也不会结束的会。

七、把它们串起来：五层其实是一条线

讲完五层，回头看一眼，会发现它们不是五件事，而是同一件事的五个切面——驯化非确定性。

层核心问题一句话心法
Prompt Engineering怎么说才答得对让提示词成为被 eval 守护的软件制品
Context Engineering该看哪些信息上下文是首要资源，选最小高信号集合
Harness Engineering怎么约束防错安全确定性外壳，包住非确定性核心
Loop Engineering何时继续何时停完成判定之外，永远有一根机械保险丝
Group Engineering怎么分工协作先证明需要多个，再谈怎么分工

贯穿始终的，还有三条跨层的纪律：

  1. 简单优先：能用一次 LLM 调用解决的就别上 Agent，能用单 Agent 解决的就别上多 Agent。复杂度只有在「被 eval 证明能改善结果」时才允许增加。
  2. eval 先行：建 Agent 之前先建评估集。这里有个漂亮的指标分裂值得记住——pass@k（k 次里至少一次成功）和 pass^k（k 次全部成功）在 k=10 时讲的是完全相反的故事：前者逼近 100%，后者跌到 0%。前者适合「演示」，后者才是「生产可靠」。选错指标，是很多 Agent 产品「演示惊艳、上线翻车」的根源。
  3. 承认不确定性：就像这篇文章开头坦白的，五层分类法是归纳而非既有框架，而且这个领域最权威的证据高度集中在少数几家模型厂商手里——它们同时是「卖 token」的人。一个真正的工程师，在采信任何一条「共识」之前，都该问一句：谁在定义这个词，谁在从中受益？

这第三点，或许是「Agent 与 Engineering」这个题目最想说的话：Agent 时代最稀缺的，不是会调 API 的人，而是能把一个非确定性系统，用工程纪律一点点驯服的人。 那份对「共识」保持怀疑、对「数字」要求出处、对「简单」心怀敬畏的克制，本身就是工程师这个职业最值钱的部分。

八、结语：从今天可以动手的三件事

如果你看完想立刻做点什么，从这三件开始，它们几乎零成本、却最难被替代：

  1. 给你手头最重要的一个 Agent 建一个 eval 集——从 20–50 个真实失败案例起步，把失败变成回归测试。
  2. 给它一个「能跑的 check」——一个测试、一次构建、一张可对比的截图，让它自己验证自己。
  3. 重新审视它的上下文——删掉一块低信号 token，往往比再调一百次提示词更有效。

Agent 不会替你想清楚这些。想清楚这些的，是 Engineering。

参考 / 延伸阅读

官方文档与工程博客（Anthropic / OpenAI / 协议）

学术

专家与业界