Agent开发入门系列第 9 篇 · 读这一篇需要 6 分钟
系列导读：这个系列不追热点，只把 Agent 架构里那些密度极高、一次读不透的概念，一个一个拆开。
先说一个我见过的场景。
某团队花了两个月，把系统提示词打磨到近乎苛刻：角色设定、输出格式、思维链、十几个 few-shot 示例、边界情况的处理话术。上线后效果确实好，任务完成率从六成出头拉到八成五。
三个月后，模型厂商发新版本。他们做了一件事------把提示词换掉，只改了角色设定那一行，其余全部删掉。
完成率没掉。
那些花了两个月打磨的"优化"，绝大部分被新模型的内生能力直接吃掉了。更扎心的是团队发现：他们当初真正有效的修改，恰好是那些模型自己已经变好的地方；而那些模型一直不擅长的东西------比如"记得上次用户拒绝过转机"------他们怎么改提示词都没用。
问题出在哪？出在他们把"提示工程"当成了整个工程。提示工程只是最里面那一层。
一、五个范式，一条包含链
AI 应用工程的演进不是五个潮流的更替，而是同一个工程不断向外扩张关注面的过程。
1. 提示工程：让单次输出变好
关注面最窄的一件事：怎么设计和优化自然语言指令，让这一次调用的输出质量更高。
角色怎么设、指令怎么排序、示例给几个、要不要写"让我们一步一步思考"、输出格式怎么约束------全在这里。
它的边界也在这里：它只管这一次调用。 上一轮说了什么、工具返回了什么、任务还剩几步，这些都不在它的视野里。
2. 上下文工程：决定它该看到什么
第二波浪潮的转折点是大家意识到：只优化提示词不够，因为模型能看到的远不止提示词。
上下文工程把关注面扩展到：系统指令、工具定义、对话历史、外部知识、记忆、当前状态、动态检索结果。
于是核心问题变了：
Agent 每次决策时应该看到什么信息？
这是一个比"怎么写指令"大得多的问题，也是第 2 篇和第 3 篇的主题。提示词只是上下文窗口里的一个组件------把它单独拎出来反复打磨，却不管窗口里其余 90% 装的是什么，属于典型的局部优化。
3. Harness 工程：管运行与治理
第三波，视野从"模型能看到什么"移到"Agent 如何组织模型运行并与环境交互"。
涵盖的是 Agent 边界内、模型之外的一切运行与治理机制：上下文怎么构造、工具怎么暴露、权限怎么限制、结果怎么验证、出错怎么纠正。
这正是第 5 篇讲的五要素。Harness 这个词在这里要再强调一次------它不是限制模型的框架，而是把模型能力引导到正确方向的装置。
4. Loop 工程：管跨轮次的持续自主运行
第四波，关注面越过"单次运行"，进入"跨轮次、长期自主运转"。
它要回答的问题是一串：
- 谁发现下一件事 ------ 下一个动作从哪来，是模型判断还是外部推送
- 何时验证 ------ 每一步之后验，还是攒到最后验
- 何时继续、何时停止
- 何时算真正完成 ------ 不是"没工具调用了"，而是交付物真的成立
- 如何持续维护状态 ------ 第 30 轮时，Agent 还记不记得第 3 轮的约束
ReAct 循环是它的基本形态，但 Loop 工程管的是几十轮、上百轮之后的事：状态怎么压缩、失败怎么恢复、预算怎么控制。
5. Graph 工程：把一切组织成显式执行图
2026 年 7 月起，业界开始用 Graph 工程 描述一个更高层的视角：把 Agent 循环、确定性程序、人工审批组织成显式的执行图。
- 节点承担具体能力（一个 Agent 循环、一段确定代码、一次人工审批）
- 类型化的边规定路由与依赖
- 检查点在关键边界处持久化状态
LangGraph、Microsoft Agent Framework、Google ADK 的官方文档里，这套东西早就在做了，只是叫"图编排"或"graph-based workflow"。
关键结论
把五条合起来，本篇最该被记住的是这一行：
提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程 ⊂ Graph 工程
注意这是包含，不是并列。不是五个可以挑一个的技术选型，而是同一件事的五个层次。每一层都在前一层的基础上，把工程师的关注范围和影响力往外扩一圈。
一个必须补上的视角：Agent 循环是图里的一个节点
包含关系最容易读错的地方在这里，很多人一看"Graph 工程是最高层"就以为 Agent 循环过时了。
不是。单个 Agent 循环正是执行图中的一个节点。
Graph 工程不是要取代 Agent 循环，而是把 Agent 循环当成图里的一种节点来编排：
- 这个节点内部是自主循环（几十轮、不确定路径）
- 它旁边那个节点是确定性代码（一次调用、路径固定）
- 再旁边是一个人工审批节点（挂起、等信号、超时降级）
第 7 篇讲的"混合编排"，在 Graph 工程视角下就是这张图：确定的节点锁死在代码里，不确定的节点交给模型，两者用类型化的边连起来。 谁是主谁是从次不重要，重要的是它们在同一个图里被统一编排。
二、竞争优势正在迁移
包含关系不只是分类学，它有一个非常实用的推论：
当各家模型的能力越来越接近、不再是决定性差异因素时，竞争优势就转移到了模型之外的工程实践。
模型层有什么特性？共享、可购买。 你能买到的，别人也能买到；榜单上的排名每季度都在被刷新，开源与闭源之间的差距在不断收窄。在模型层建立壁垒，本质上是在一个正在商品化的市场上竞争。
真正难复制的是这些：
- 上下文管理
- 工具接口
- 约束
- 验证
- 纠正
- 状态管理
- 错误恢复
- 循环编排
一个把这件事讲透的案例
Terminal Bench 2.0 （评估 Agent 在终端环境中完成复杂任务能力的基准测试）上，LangChain 的得分从 52.8% 提升到 66.5% ，从排行榜 30 名开外 跃升至前 5。
改的不是模型。是 Harness，具体做了四件事：
- 让 Agent 自动检查自己的执行结果
- 检测是否陷入重复循环
- 优化思考策略
- 自动纠错
这四项有一个共同点：它们全都不在提示词里，全都在模型外面。 没有一项是"换个更强的提示词写法"能解决的，也没有一项需要重新训练模型。
案例的意义不止于那 13.7 个百分点。它说明的是：
当模型能力趋同，差异来自模型之外的工程组织。
对照第 1 篇那条结论------"模型固定时，扩上下文和工具往往比换更强的模型更有效"------这条判断在此被推到了极端：模型已经不是变量了，Harness 才是。
三、模型选型：给维度，不给推荐
这一节只给选型维度，不推荐具体模型版本------版本号写死，过期得比提示词还快。
闭源模型 （OpenAI、Anthropic 等）Agent 能力通常较强，成本较高，受 API 策略和服务条款约束。不要只看排行榜，要在自己的任务上评估。
开源模型 （DeepSeek、Kimi、GLM 等）成本低、可私有化、支持微调，适合成本敏感或有数据合规要求的场景。过去一年里开源与闭源的差距一度缩小到 6 个月以内，成本却显著更低。选型前务必在具体场景里测工具调用。
策略边界最容易被忽略 ：基准测试显示模型具备某项能力，不代表承载它的产品允许你用。要确认五件事：模型是否愿意执行、API 是否暴露所需能力、套餐与服务条款是否允许、有没有网络安全/隐私/模型提取方面的限制。同一个任务在聊天产品和 API 里可能得到不同结果。关键业务还要准备人工接管、合规模型替代或降级策略。
是否需要 Reasoning：绝大多数 Agent 应选支持思考的模型------多步推理、工具选择、动态规划、错误恢复都依赖它。例外极少：单步固定任务、固定位置的简单 GUI 点击、不需要动态决策的短流程。
输出速度与多模态 ：Agent 需要多轮模型输出，输出 token 速度直接决定延迟------20 轮推理、每轮多等 2 秒，总计就多等约 40 秒。需要处理图片、音频、视频时，多模态是硬性要求。
四、什么时候这个说法会失效
第一，包含关系是关注面的包含，不是效果的包含。 这是最容易误解的地方。外层做好了不代表内层可以省------Graph 工程再完善，每个 Agent 节点里的提示词写得一塌糊涂，那个节点照样跑不好。包含关系说明"外层包含内层的关注"，不说明"内层可以被外层替代"。 该写好提示词的时候还得写好。
第二，Graph 工程在任务不确定时容易变成过度设计。 任务路径本来就无法预定义，画出来的图有一半节点永远走不到，边画得越细维护成本越高。先用单次调用或自主循环跑通，图是后来才需要的东西。
第三，循环的层级越多，延迟越难压。 Loop 工程在 Agent 循环外面，Graph 工程又在 Loop 外面。每加一层就多一次序列化、多一次检查点读写、多一轮等待。层数不是能力，层数是账单。
第四，"何时算真正完成"在开放任务上没有定义。 订单处理有明确的完成态，"帮我想清楚要不要换工作"没有。循环工程在这里只能退回到可操作的规定------必须调用交付工具、达到最大轮数、人工接管------而这些规定本质上是承认"完成"是个工程约定，不是客观事实。
第五，模型能力再次跃迁可能改写这套划分。 第 7 篇讲过，Harness 里的脚手架会被模型内化------few-shot 示例、"让我们一步一步思考"、JSON 修复代码都已经被吸收了。如果某天模型原生就能可靠维护长程状态、自己在内部完成验证与纠错，那么 Loop 工程和 Harness 工程的一部分会塌缩进模型，划分方式就得重画。
这不是反对做 Graph 工程。而是说：它是对当前能力分布的描述，不是对未来的预言。
小结
这一篇只讲清了一件事：五个工程范式是同一件事的五个层次，不是五个并列选项。
vbnet
提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程 ⊂ Graph 工程必须记住的四点：
- 包含，不是并列。 每一层把关注面往外扩一圈，内层是外层的基础。
- 单个 Agent 循环是 Graph 里的一个节点。 Graph 不是取代 Agent 循环，而是把 Agent 循环当节点编排------这就是第 7 篇的混合编排。
- 竞争力在迁移。 Terminal Bench 2.0 上 52.8% → 66.5%、30 名开外 → 前 5，变的是 Harness，不是模型。模型层共享可购买，模型之外的工程才是自己的。
- 模型选型看维度不看榜单。 策略边界、工具调用能力、输出速度、多模态，这些都得在自己的任务上测。
最后是一个判断，说给下一篇用：
这套范式划分本身会过时------模型变了，划分方式可能就变了。但设计原则不会。
五个范式的名字可能会被下一个十年的术语替换，但"渐进式披露""只增不改""提议者与审核者分离"这类做法不会因为模型变强而失效------它们约束的不是模型能力，是系统的形状。
下一篇就把这九条原则一条条摊开。
下一篇：《九条穿越模型迭代的设计原则》
关注这个系列，我会持续更新。觉得有用的话，欢迎点个赞------它会让我更有动力把下一篇写好。