从跟模型聊天，到给Agent画组织架构图

2022到2026，四年时间，AI工程圈换了五代掌门人。

从Prompt Engineering到Graph Engineering，每代都觉得自己抓住了终极答案，每代都被下一代打脸。但神奇的是——没有一代真的被淘汰。它们只是被包进了更大的套娃里。

今天就来聊聊这五代到底是怎么回事，每一代解决了什么上一代解决不了的问题，以及为什么你搞懂了第一代，却依然看不懂第五代在干嘛。

一句话：我该对模型说什么？ 2022年底，ChatGPT炸了。所有人突然发现，跟AI说话这件事，居然是一门手艺。

东京大学有个博士生叫Kojima，在实验室里随手敲了一句"Let's think step by step"（咱们一步步想），往GPT-3里一丢——模型的成绩直接起飞。就这么一句话，后来被叫做Zero-shot Chain-of-Thought，成了提示词工程的标志性时刻。

然后Karpathy说了那句名言："最热门的编程语言是英语。"

整个2023年，AI圈最大的社交货币就是"我会写prompt"。大家比谁的提示词更长、更花哨、角色设定更复杂。思维链、少样本学习、角色扮演、输出格式约束……六大技术家族轮番上阵，卷得飞起。

Prompt Engineering的本质是：假设模型能力固定，优化你的提问质量。 工程单位是"一句话"，时间尺度是"秒到分钟"。

但问题来了——提示词是手工制品，高度依赖特定模型版本。模型一更新，你好不容易调好的prompt可能就悄悄失效了。这有个名字叫Prompt Drift（提示词漂移）。很多团队甚至给prompt写了回归测试，像测函数一样测措辞，然后眼睁睁看着它们在每次模型升级后批量过期。

把确定性期望绑在概率系统上，这不是偶发事故，是必然结果。

更致命的是：提示词工程没有状态。模型答完就忘，下一轮从头来过。你给它再完美的指令，它也不会自己检查、不会自己纠错、不会自己决定下一步干嘛。

人，始终是那个循环的决策节点。

一句话：我该让模型看见什么？ 2025年，业界开始意识到一个尴尬的事实：你花三天三夜打磨一句prompt，不如花三十分钟把正确的资料塞进上下文窗口。

Karpathy打了个比方：把LLM看作CPU，把上下文窗口看作RAM。 你不会指望CPU自己记住所有东西——你得往RAM里装对的数据。Tobi Lütke（Shopify CEO）更是直接表态，他更喜欢"上下文工程"这个词，而不是"提示词工程"。

Anthropic也跟着定性：Context Engineering是Prompt Engineering的自然演化，不是替代。

上下文工程的核心问题是：模型在这一步推理时，应该看到什么、不该看到什么。 不只是系统提示词，还包括检索到的文档、对话历史、工具定义、用户元数据——所有进入上下文窗口的东西，都要被精心设计。

它有四个核心操作，可以记成"写选压隔"：

• • Write（写出）：把信息存到上下文窗口之外——笔记、记忆文件，别什么都往窗口里塞

• • Select（选入）：只把当下需要的拉进来，静态配置和动态检索结合

• • Compress（压缩）：留精华丢冗余，摘要和修剪，别让窗口被废话占满

• • Isolate（隔离）：分散到多个上下文窗口，用子Agent和环境隔离防止信息互相污染

这四个操作分别对应四种失败模式的修复：信息中毒、注意力分心、概念混淆、上下文冲突。

上下文工程解决了信息供给问题。但有个新的坑：Context Anxiety（上下文焦虑）。当上下文窗口快满的时候，模型会匆忙收尾，质量断崖式下跌——就像你期末考试还剩五分钟但作文只写了个开头。

而且，一个被充分喂养了上下文的模型，如果第一次就答错了，它不会自己发现。整个管线里没有任何机制推动它做二次检查。

信息给对了，但任务还是跑不动。

一句话：我该给Agent搭什么环境？ 2026年初，Mitchell Hashimoto（HashiCorp联合创始人）发了篇博客，提了个概念：Harness Engineering。

Harness，直译"马具"，或者更形象点——缰绳。想象骑马：马本身有强大的力量，能跑能跳能驮东西，但如果没有缰绳和马鞍，这股力量就是脱缰的野马，指不定往哪跑。

模型就是那匹马，Harness就是缰绳。Agent = Model + Harness。

LangChain的Harrison Chase补了一刀："If you're not the model, you're the harness."（如果你不是模型本身，那你就是缰绳。）

这一代的背景是：AI Agent开始从"聊两句就走"变成"干几小时的活"。但裸模型有四个硬伤——没记忆、没行动力、知识有截止日期、没运行环境。Harness Engineering就是给模型搭一套完整的系统脚手架：

• • 文件系统+Git（补记忆）

• • Bash+沙箱（补行动力，形成"执行→验证"闭环）

• • 记忆系统（跨会话知识沉淀）

• • 网络搜索+MCP协议（补知识截止，连接外部世界）

• • 上下文工程（信息质量管理，上一代的能力被包含进来）

• • 编排+Hooks（系统控制和质量关卡）

有个数据很能说明问题：OpenAI Codex团队，3个人，5个月，产出约100万行生产级代码，零手写。靠的不是模型多强，是Harness架构做得好。

Harness Engineering的哲学变了——从"调教模型"到"设计防错系统"。 不是让模型更聪明，而是改变系统结构，让错误在结构上不发生。

但它也有天花板：Harness是静态的。它搭好了环境，但"该生产什么""谁来验收""出了异常谁处理"这些动态决策问题，它回答不了。

车间搭好了，但流水线上还是需要人来盯着。

一句话：我该设计什么循环，让Agent自己跑？ 2026年6月初，Peter Steinberger（OpenClaw创始人）在X上敲了条推文，大意就十二个英文单词：别再手动给AI编码代理写提示词了，去设计一个能替你写提示词的系统。

几天之内，Boris Cherny（Claude Code的作者）在公开场合跟上："我不再prompt Claude了，有个loop在跑。"从2025年11月起，他的代码100%由Claude Code产出，每天10到30个PR。

紧接着，Google Cloud工程总监Addy Osmani做了系统性拆解，并正式命名：Loop Engineering（循环工程）。 他的定义是："Replacing yourself as the person who prompts the agent. You design the system that does it instead."（把自己从那个给Agent写提示词的人替换掉，转而去设计做这件事的系统。）

三个人，三家公司，同一周，同一个结论。

打个比方：如果提示词工程是在棋盘上走好每一步棋，那循环工程就是设计下棋的规则和裁判机制，让AI按照规则自己完成一整盘棋。

Loop Engineering把协作从"问答式"升级为"闭环式自动化"：人给目标，系统自己跑完全程。核心是五个原语加上一个记忆层：

• • 自动化触发（Automations）：定时任务、事件钩子、持续监听——没有触发的循环只是个脚本

• • 工作树隔离（Worktrees）：多Agent同时干活时不互相踩脚

• • 技能文件（Skills）：把项目约定、构建流程、已知陷阱写下来，Agent不再每次从零开始

• • 插件与连接器（Plugins & Connectors）：通过MCP协议接入外部系统，读工单、查数据库、跑CI

• • 子代理（Sub-agents）：最关键的架构决策——干活的和检查的必须分开。写代码的模型在评判自己代码时都挺自恋的

• • 状态持久化（State）：循环不能遗忘，上一轮做了什么、哪些任务排队中，都要记住

Boris Cherny说的不是工作变轻松了，而是关注点不一样了。设计循环比写提示词更难，因为你得对"什么叫完成"有精确的定义，对失败模式有预判，对成本有约束，对什么时候拉人介入有清醒的判断。

但Loop也有三个结构性天花板：它不能设计自己，多个Loop之间不能对话，它也不能质疑目标。 这三点，恰好指向了下一代。

一句话：多个Agent之间，怎么协作不失控？ 2026年7月18日，还是那个Peter Steinberger，在X上抛了个问题：是不是已经从Loop转向Graph了？

社区炸了。

先说清楚一件事：这里的Graph不是知识图谱。 知识图谱解决的是"系统知道什么"，Graph Engineering解决的是"系统由谁组成、如何协作、如何被治理"。

Graph Engineering的核心是把多个Agent（或处理单元）组织成一张有向图。图的三个基本元素：

• • 节点（Node）：干活的单元。可以是专业Agent（研究员、写手、审核员），可以是确定性函数，可以是工具调用，也可以是人工审批点

• • 边（Edge）：节点之间怎么走。顺序交接、条件分支、并行扇出、失败回退、循环重试——边是控制契约，不是随便连的线

• • 共享状态（Shared State）：在节点间流动的数据。任务进度、中间产物、成本预算、验证结果——这些必须显式设计，不能全塞一个大JSON

为什么需要Graph？因为当任务跨域——既要改支付逻辑又要保API兼容、既要迁数据又要更前端、既要过安全审查又要出发布说明——单个Loop必然变成一团乱麻。

单Agent的Loop有五个致命问题：控制流隐式（藏在prompt里）、状态混在对话中、职责边界模糊、并行汇合困难、局部恢复能力弱。本质上是同一个问题域：任务流程和任务状态没有成为独立对象。

Graph Engineering把这些从模型上下文里拎出来：把隐式计划展开成节点，把临时执行顺序展开成边，把对话历史中的任务进度转换成状态。

实践上有个关键设计——两张图：

• • Org Graph（组织图）：长期稳定的角色和权限边界，变化慢。一个Security Agent知道哪些接口有遗留风险，这些记忆不随任务结束而消失

• • Work Graph（工作图）：每次任务临时生成的执行拓扑。不同任务产生不同的图，分支可以动态增减

这就像公司有组织架构图（谁在什么岗位），也有项目甘特图（这次活儿怎么排）。用一张固定流程图覆盖所有任务，简单任务被过度编排，复杂任务又缺弹性。

Graph Engineering还有个很重要的概念叫Anchor（锚点）。多Agent系统最危险的不是某个Agent犯错，而是错误在图里被放大——Research Agent找到低质量资料，Writer写得很流畅，Reviewer只检查结构不查来源，Publisher顺利发布。每个节点都"完成了任务"，但整个系统输出了错误内容。

Anchor就是系统不能随意改写的外部参照：来源URL、测试执行结果、人工审批、不可变审计日志。没有Anchor的图，只是一个更复杂的Loop。

回顾一下这五代的核心问题：

代际

核心问题

工程单位

时间尺度

比喻

Prompt Engineering

怎么跟模型说话？

一句话

秒~分钟

写一封完美的邮件

Context Engineering

让模型看见什么？

一个上下文窗口

分钟~小时

准备一份完整的briefing folder

Harness Engineering

给Agent搭什么环境？

一整套运行时

天~月

给野马套上缰绳

Loop Engineering

设计什么循环让Agent自己跑？

一个闭环系统

持续运转

设计下棋规则而不是自己走棋

Graph Engineering

多个Agent怎么协作不失控？

一张执行拓扑图

跨任务长期

画团队组织架构图

关键认知：这五代是层叠包含关系，不是替代关系。 Prompt是Context的子集，Context是Harness的子集，Harness是Loop的基础设施，Loop是Graph里每个节点的内部运行机制。每一代都不会消失，只是被更大的框架包裹起来。

控制范围在持续扩展：从模型指令→推理输入→外部能力→连续执行过程→多个过程之间的拓扑关系。

每一次跃迁，不是让模型更聪明，而是让"聪明"在更大的系统、更长时间尺度上被放心使用。

Graph Engineering的提出者自己都没想那么远。但从演进逻辑推演，下一代可能要解决三个问题：

Loop不能设计自己——能不能让Loop观察自身运行数据，自动修改结构，AB验证，运行时演化？这叫Meta-Loop。

Loop之间不能对话——多个Loop能不能通过协议层协商、通过信任层验证？这叫Ecosystem Engineering。

Loop不能质疑目标——Agent能不能反问"你真的想要这个吗？"，在执行中发现意图偏差并校准？这叫Intent Engineering。

三个方向最终汇向同一个终点：元认知能力——AI系统对自身、对同伴、对目标的反思。

当然，这些都是推演。也许第六代根本不在这三条路上，也许有人明天发条推文就又造个新词出来。毕竟这个领域的规律就是：概念跑得比落地快，名词跑得比代码快。

但有一件事不会变：每一代工程的核心，都不是让AI更聪明，而是让聪明的东西被放心地用起来。

从"怎么问"到"怎么管一群人"，这趟旅程才刚开始。

参考资料：Andrej Karpathy社交媒体观点、Mitchell Hashimoto博客、Addy Osmani Loop Engineering拆解、Peter Steinberger X推文、LangChain/LangGraph官方文档、Anthropic多Agent研究系统架构等