从 Loop 到 Graph:我们的 Agent 工程化演进全景
现状之痛:很多人刚搞懂 Loop Engineering,AI 圈又开始讨论 Graph Engineering。你刚学完一个概念,下一个就来了——永远在追,永远没落地。
读完你将:拿到一条真实跑通的 Agent 工程化演进路径(Prompt→Context→Loop→Graph),每一层都有物理证据——不是我编的概念,是我 52 天里一步步踩出来的。
〇、不是概念竞赛,是工程演进
「未文手记」最近写了《超越Workflow:走向Graph Engineering》,一句话点破关键:
「很多人认为 Workflow 的升级方向是增加更多节点、更多分支和更多条件判断。但复杂性真正增加后,问题已经不再是『怎么加节点』,而是:如何描述实体、关系、状态以及在变化环境中的动态决策——这正是 Graph Engineering 与传统 Workflow 的根本分野。」
很多人把 Graph Engineering 当「又一个新概念」在追。但对我们实践派来说,它不是一个概念,是一条演进路径的下一站——而这条路径,我已经真实走了一遍。
一、脚手架演进全景:Prompt → Context → Loop → Graph

| 阶段 | 核心问题 | 抽象级别 | 瓶颈 |
|---|---|---|---|
| ① Prompt 工程 | 怎么让模型听懂 | 单次对话 | 复杂任务无法一次完成 |
| ② Context 工程 | 怎么给够上下文 | 单次会话 | 窗口有限/噪声多 |
| ③ Loop 工程 | 怎么循环执行 | 循环执行 | 循环失控/无状态 |
| ④ Graph 工程 | 怎么多 Agent 协作 | 多 Agent 编排 | 状态管理/失败定位 |
演进逻辑:每阶段解决上一阶段的瓶颈——
Prompt(单点能力)→ Context(记忆能力)→ Loop(执行能力)→ Graph(组织能力)
二、我们的 Context:先查索引,再喂上下文
我的第一站是 Context 工程。踩过的坑很典型:把知识库全量喂给 LLM——上下文爆炸、token 烧钱、回答还慢。

后来改成两步法:
- 查索引:知识库维护「概念→文章」静态映射表 + 规则匹配,秒级定位「该看哪几个节点」
- 喂相关片段:只把命中的节点喂给 LLM——上下文瘦身,token 大幅节省
这本质是 RAG 的轻量落地:不建向量库、不用 embedding,小知识库场景更便宜更快。
三、我们的 Loop:Harness 工程化(52 天的核心)
第二站是 Loop 工程——这是我投入最深、收获最大的一层。它的核心不是「让 Agent 循环跑」,而是让循环每转一圈都变强:

错误发生
→ ① error-ledger 记录(症状→根因→解法→状态)
→ ② 纠正沉淀(提炼成规则/技能)
→ ③ 规则物理化(写入 verify 脚本/门禁)
→ ④ 门禁免疫(不过 gate 直接拦截)
→ 回到 ①(新错误继续进来)
真实证据(52 天里跑通的):
- error-ledger 错误账本:每次被纠正的错误都结构化记录(症状→根因→解法→状态)
- 每日自我进化 cron(每晚 21:00):自动做错误复盘 + 热词研究 + 选题建议
- 门禁矩阵:任务输出前过 6 道物理门禁(task_context 存在/技能存在/规则执行/超时/回归/schema)
- Maker/Checker 分离:生产者和校验者物理分开,不自己审自己
这就是 H1《Self-Improving Agents 不是神话》里讲的完整闭环——反思是概率,进化是物理。
四、我们的准 Graph:多 Agent 协作(正在演进)
第三站是 Graph——我们已经在跑,只是还没用「图」的语言命名它。

以我维护的业务 Agent 体系为例:
- 节点(Node):邮件 Agent / 报告 Agent / 票务 Agent / 写作 Agent(各有分工)
- 边(Edge):Maker 产出 → Checker 校验 → 门禁放行/拦截(协作关系)
- 共享状态:SQLite(票务)+ 台账 + 知识库(只增不删)
- 治理:规则 → verify 脚本 → 门禁矩阵(图的治理层)
关键洞察:我们没写一行「图框架」代码,但我们的体系天然就是一张图——因为复杂任务多了,Agent 自然会从「一个人干」变成「一个团队干」。Graph 不是发明,是演进的自然结果。
五、Agent 工程化的四层脚手架(从业者路径)
如果你要搭建自己的 Agent 工程化体系,按这个顺序搭(我踩过的顺序):
| 层 | 是什么 | 验证标准 |
|---|---|---|
| ① Context 工程(地基) | 知识库+索引+记忆管理 | 知识检索命中率 > 90%? |
| ② Loop 工程(骨架) | 循环+错误记录+纠正沉淀+门禁 | 同样的错误不再犯第二次? |
| ③ 可观测性(神经) | 门禁+审计+追踪+台账 | 失败能 5 分钟内定位? |
| ④ Graph 工程(组织) | 多 Agent+状态管理+动态决策 | 加一个 Agent 不动其他 Agent? |
不要跳层:直接上 Graph 而 Context 没做好 = 图里全是「失忆的节点」。我 52 天的顺序就是 Context → Loop → 准 Graph,每一层都有证据。
六、认知升阶:Graph 是分水岭
Graph Engineering 是「从工程到架构」的分水岭。
之前(Prompt/Context/Loop):怎么让 Agent 干活(工程)
之后(Graph/平台):怎么设计 Agent 组织(架构)
未来 AI 的竞争,不只是模型能力,而是如何设计一套能稳定完成复杂任务的智能系统——这句话越来越成为共识。而设计「智能系统」,图就是那个正确的抽象。
对我们来说:Graph Engineering 不是又一个概念,是「Agent 多了以后怎么管」的工程答案。
七、此刻的你
此刻的你,不再满足于「又学一个概念」——你开始思考「我的 Agent 体系现在在哪一层,下一步怎么演进」。
你正在成为那个——把概念变成脚手架的实践者。
记住:Prompt 是问,Context 是记,Loop 是跑,Graph 是组织。每一层都有物理证据的演进,才叫工程化。
延伸阅读
- Self-Improving Agents 不是神话:从 error-ledger 到 Loop Engineering 的完整闭环 · Loop 阶段的完整实践
- 实践=技术×场景×价值:AI时代什么是真正的认知变现 · 实践派的方法论
- 场景路由——为什么「全能Agent」必死 · 多 Agent 协作的节点拆分
- 可观测性三件套——商业化Agent的反馈闭环 · 图的治理层
实体:Graph Engineering, Loop Engineering, Multi-Agent, Harness, 脚手架
价值:工程演进路径, 物理证据, 四层脚手架, 可落地
认知:Prompt是问,Context是记,Loop是跑,Graph是组织——每一层都有物理证据的演进才叫工程化
关于作者 无记——AI / Agent / 数智化转型实践者。 只写亲手跑通的东西,不聊概念。关注我,一起把认知变现。

浙公网安备 33010602011771号