AI AGENT 工程范式进化史 • 系列总览
AI Agent 怎么越做越复杂？因为工程边界一直在往外扩。
过去几年，我们优化 AI 的方式一路往外扩：先琢磨一句提示词，后来开始拆流程、管上下文、搭运行环境、设计反馈循环，再到目前讨论较多的状态与图式编排。
这不是六个互相替代的新名词，而是六次工程边界外扩。为了把它讲清楚，我们不先背术语，只看一家街角餐馆，是怎么从一个点菜窗口，慢慢长成为一套完整后厨的。
从一个点，到一条链，再到一张图
00/同一家餐馆 · 持续升级
不是厨师突然变笨了，而是餐馆承担的事情越来越多。
这家店刚开张时，老板、服务员和厨师可能就是同一个人。客人点一碗面，他听清要求，转身就做。后来午市排起长队，包间开始接宴席，熟客有忌口，外卖平台不断催单，新员工还不能随便碰燃气和贵重食材。再后来，菜做咸了要返工，大额退款要经理审批，停电重启后还得知道哪张单做到哪一步。
厨师还是那个厨师，但决定结果的，早已不只是厨艺。它还取决于：订单有没有写清、工序有没有排好、资料和食材有没有递对、后厨工具和权限是否可靠、做错后能不能根据反馈修正，以及复杂情况下整个餐馆该往哪条路走。
这套比喻会贯穿整个系列，但不会重复同一段剧情。 总览负责展示餐馆的全景；目前规划的六站会依次走进点菜窗口、工序台、备料间、后厨、质检台和调度室。Graph 只是当前路线上的一站，以后出现新的工程关注点，系列会继续向外扩。
01/目前六站 · 一路往外扩
每一次升级，都是上一层解决不了新问题。
下面只看六个关键转折。具体方法、证据、误区和落地方式，留到每一站单独拆。
Prompt Engineering
优化单元 = 一次模型调用
本质：把这一张订单写清楚。
🪟 餐馆刚开张，客人就在窗口下单。 "一碗牛肉面，不要香菜，面硬一点，汤少一些。"厨师没换，订单写得越具体，第一次端对的概率越高。Prompt Engineering 关心的就是：目标、格式、约束和示例，怎样在这一次调用里表达清楚。
| 这一层解决： 把一次请求说清楚，让模型更容易理解和执行。 | 为什么会进化： 周末来了一个八人生日宴。一张订单写得再漂亮，也不该让一个人一次完成所有菜。 |
|---|
一个黑盒：进去一次，出来一次
Chain / Workflow Engineering
优化单元 = 多步流程
本质：把整桌菜拆成一张能执行的工序单。
📋 生日宴不能靠一句"做八个人的菜"来完成。 凉菜要先上，热菜要错峰，长时间炖煮的菜得提前开火，蛋糕还要等客人到齐。于是后厨有了工序单：谁先做什么、下一步交给谁、什么时候一起出餐。Workflow 的价值，是让复杂任务不再挤在一次回答里。
| 这一层解决： 把大任务拆成顺序、路由或并行步骤，每一步有清楚的输入输出。 | 为什么会进化： 流程排好了，客人花生过敏、当天鲈鱼售罄这些信息如果没有递到对应步骤，照样会出错。 |
|---|
把大任务拆成预先定义、可以检查的连续工序
Context Engineering
优化单元 = 这一步真正需要的信息
本质：不是把仓库全搬来，而是把这一刻要用的东西递到手边。
🧺 午市最怕的不是没菜谱，而是信息散落在不同地方。 熟客的过敏记录在会员系统，今日库存写在白板上，外卖备注藏在订单末尾。把所有资料一股脑堆上操作台，只会让厨师更难找到重点。真正有效的备料，是做哪道菜，就递来对应食材、忌口和最新库存。
| 这一层解决： 通过写入、选择、压缩和隔离，让模型在每一步看到恰当信息。 | 为什么会进化： 知道菜谱和库存，不等于能点火、用刀、调用收银机，更不等于拥有相应权限。 |
|---|
给模型配一套按需供给的信息系统
Harness Engineering
2026 年 2 月成为明确工程标签 · 优化单元 = Agent 的运行与执行环境
本质：把"知道怎么做"，变成"可以安全、稳定地做"。
🍳 一家真实后厨不会把所有东西都随便交给所有人。 新员工可以切配，却不能独自开燃气；海鲜柜要登记领用；外卖退款超过金额要主管批准；刀具要归位，冰箱温度要留记录。对应到 Agent，就是工具、沙箱、权限、日志、校验和护栏。
一句话区分： Context 是"这一刻给它看什么"；Harness 是"让它在哪里、拿什么、按什么规矩去做"。
| 这一层解决： 让 Agent 拥有可用、可控、可观察、可验证的行动环境。 | 为什么会进化： 工具都齐了，菜仍可能做咸、火候仍可能失手。系统还需要把结果变成反馈。 |
|---|
模型只是中间那块，真正难的是外面的执行环境
Loop Engineering
2026 年 6 月集中走红 · 优化单元 = 反馈 → 修正 → 再试
本质：不是让模型"多想几遍"，而是让每一轮都拿到可用反馈。
🥄 厨师出菜前会尝味，炸物会测油温，服务员还会把退菜原因带回后厨。 咸了就调整，没熟就继续加热，摆盘不合格就重做。关键不在于"再来一次"，而在于每次都有明确反馈，并且知道最多返工几次、超过成本后交给谁处理。
没有评价标准、预算和停手条件，循环只会变成更贵的原地打转。
| 这一层解决： 把结果、评价、修正、重试和停止条件设计成系统能力。 | 为什么会进化： 午市同时出现普通单、过敏单、退菜、退款、设备故障和多个档口协作时，一个循环已经管不了全局。 |
|---|
想 → 做 → 看 → 评：一轮反馈完成后再决定是否继续
Graph Engineering
2026 年 7 月成为热词 · 优化单元 = 有状态的复杂控制流
本质：把共享状态、节点和转移规则显式化。
🗺️ 餐馆做大以后，后厨更像一座交通枢纽。 普通堂食走标准线，过敏单必须复核，菜品不合格要回炉，大额退款停在经理审批，设备断电后要从最近完成的步骤继续；凉菜、热菜、甜点几个档口又像不同的专职 Agent，需要共享同一张订单状态。此时，一张线性工序单已经不够。
| 这一层解决： 把共享／持久化状态、条件分支、循环回路、人工卡点、崩溃恢复和多 Agent／子流程协作显式编排。 | 为什么会进化： Graph 不是必然的最高阶段。高度开放、难以预先固定路径的任务，强行画成确定图反而会限制 Agent。 |
|---|
02/重点来了 · 别被一堆名词唬住
这不是六个对手，是一层套一层的「棘轮」。
订单、工序、备料、后厨、反馈和调度，并不是六家互相竞争的餐馆。它们共同组成同一家餐馆。AI 工程也是一样：每一层都保留前面的能力，只是把关注边界再往外推了一圈。
当前六站分别回答六个逐步扩大的工程问题
Prompt 把话说清，Workflow 把步骤排清，Context 把信息喂对，Harness 把环境搭好，Loop 把反馈跑起来，Graph 再把有状态的复杂控制流显式化。 Graph 也不是"最后一定要到达的终点"。只有当系统需要跨步骤保存状态，并且条件分支、循环回路、人工卡点、崩溃恢复、多 Agent／子流程协作等复杂性开始叠加时，它才真正有价值。
03/一张表看清区别
从「一次调用」一路扩到「整个系统」
04/三个最容易混的地方
不是看名字像不像，而是看它到底在优化什么。
这三个边界讲清楚，目前六站的核心差异基本就不会串。
一句话 vs 一串步骤；看到什么 vs 能做什么；一个回路 vs 整张路网
Prompt ≠ Workflow： Prompt 关心"这一步怎么说"；Workflow 关心"整件事有哪几步、按什么顺序走"。
Context ≠ Harness： Context 是递给模型的信息；Harness 是 Agent 真正行动时能用的工具、环境、权限和护栏。
Loop ≠ Graph： Loop 关心"一个任务怎样根据反馈继续迭代"；Graph 关心共享状态如何在条件分支、循环回路、人工卡点、崩溃恢复以及多 Agent／子流程之间流转。
05/时间线说明 · 别把术语走红当成实践起点
"什么时候出现"要分清：实践早已存在，术语后来才流行。
实践通常早于术语：旧问题和旧方法，在新阶段获得共同名称
Harness Engineering： 并不是 2026 年才突然出现运行环境和工具。Mitchell Hashimoto 在 2026 年 2 月 5 日 把这套做法称为 Harness Engineering；OpenAI 又在 2 月 11 日发布同名工程文章，让这个标签进入更广泛讨论。
Loop Engineering： 反馈循环、测试---修正、自动重试早就存在。Addy Osmani 在 2026 年 6 月 7 日系统解释了这一轮"由人反复提示，转向系统自己驱动 Agent"的 Loop Engineering。
Graph Engineering： 图式编排同样不是新发明。LangGraph 在 2024 年 1 月 发布时就强调有环图和状态；到 2026 年 7 月，"Graph Engineering"这个标签集中走红，LangChain 于 7 月 22 日专门回应。
06/别为了图而图
那我到底该上哪个？
先找失败发生在哪一层，再加最小必要复杂度。尤其是 Graph，不应该用"功能听起来很多"作为判断依据。
能停在前一层，就不要硬上后一层
| 更稳妥的 Graph 判断线： 任务需要跨步骤保存或恢复状态，并且条件分支、循环回路、人工卡点、崩溃恢复、多 Agent／子流程协作这五类复杂性中，同时出现两项以上。即使满足，也应先确认这些路径能否被合理预先描述。这是一条实用启发式，不是行业统一标准。 |
|---|
07/听懂之后 · 怎么落到自己手上
别从"我要做一个 Graph Agent"开始，从"我的问题卡在哪一层"开始。
真正的实践顺序不是追最新名词，而是逐层排查：哪一层已经够用，就停在哪一层。
从真实任务和失败模式出发，不从框架名出发
第 1 步：先拿一个真实任务。 比如"整理客户反馈并生成回复""研究竞品并输出报告""自动处理内部工单"。不要先选框架。
第 2 步：先用 Prompt 跑通。 先确认模型是否理解目标、输出格式和基本约束。能一次做好的，不要复杂化。
第 3 步：任务太大就拆 Workflow。 把"搜集 → 判断 → 生成 → 校验"拆开。每一步输入输出尽量清楚、可测试。
第 4 步：哪一步缺资料，就补 Context。 不要一上来做"全量 RAG"。先问：模型做错，是因为不会，还是因为没看到正确资料？
第 5 步：需要行动，再搭 Harness。 给它最少够用的工具和权限，同时把日志、沙箱、校验和失败处理搭起来。
第 6 步：需要反复修正，再加 Loop。 先定义"什么叫做对"，再定义最多重试几次、花多少钱、什么时候必须停。
第 7 步：需要保存状态，而且复杂性开始叠加，再考虑 Graph。 把共享／持久化状态、条件分支、循环回路、人工卡点、崩溃恢复以及多 Agent／子流程协作关系画清楚。图是复杂度的说明书，不是时髦装饰。
08/系列路线图
这只是开篇。先拆目前六站，路线会继续向外延伸。
后续每一站都会接住上一站解决不了的问题：从点菜窗口开始，依次进入工序台、备料间、后厨、质检台和调度室。厨房只负责帮你建立直觉；每一站的主体都会回到真实 AI 任务、研究证据、失败模式和工程方法。
这张路线图是开放的。 Prompt 到 Graph 是当前要拆解的六站，不是对 AI Agent 工程演进的永久封顶。以后出现新的范式、术语或工程关注点，就从"还会有的..."继续向后追加。
真正的变化，不是我们从 Prompt "换成"了 Graph，更不会在 Graph 停下；而是开始把 AI 应用当成一个持续演进的工程系统来设计。Prompt 说清楚 · Workflow 排清楚 · Context 喂清楚 · Harness 搭清楚 · Loop 反馈清楚 · Graph 状态与路径清楚 · 还会有的...
全景看完，我们先回到点菜窗口：给厨师戴一顶"世界级主厨"的帽子，真的能让菜做得更准吗？进入第一站 · 你写的 Prompt，可能有一半是安慰剂 →
关于这个系列《AI Agent 工程范式进化史》------跟着同一家餐馆连续升级，一站一站讲透 AI Agent 工程的演进：Prompt → Chain → Context → Harness → Loop → Graph → 还会有的...
时间线参考来源：
1 Mitchell Hashimoto, 2026‑02‑05. My AI Adoption Journey 。Harness Engineering 概念原始出处，提出AI 编码采纳的六阶段演进叙事。 mitchellh.com/writing/my-...
2 OpenAI, 2026‑02‑11. Harness Engineering: Leveraging Codex in an Agent‑First World 。OpenAI 对驾驭工程范式的官方实践阐述。 openai.com/index/harne...
3 Addy Osmani, 2026‑06‑07. Loop Engineering 。提出循环工程范式，工程重心由编写提示转向设计自主闭环控制系统。 addyosmani.com/blog/loop-e...
4 LangChain, 2024‑01‑17. LangGraph 。状态图智能体编排框架首次对外发布，奠定 Graph 工程基础。 www.langchain.com/langgraph
5 LangChain, 2026‑07‑22. 3 Years of Graph Engineering with LangGraph 。复盘三年图工程落地实践，总结 Agent 架构演进思考。 www.langchain.com/blog/3-year...
口径说明：文中 "当前六站" 为帮助读者理解 AI 工程演进、关注点外扩的阶段性叙事框架，不存在行业统一官方标准，技术演进也并非止于 Graph 工程阶段。