从一句话，到一套系统

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