企业官网建设流程全解析

前两篇小马聊了Harness Engineering（给 AI 套马具、不乱跑）和Loop Engineering（让 AI 在轨道上自己跑完全程）。这一篇再往前推一步：当流程不再是"一条直线"，而是要分叉、并行、按情况走不同路的时候，就轮到Graph Engineering（图工程）上场了。

引言

在上一篇《从Harness Engineering到Loop Engineering的演进实践方法论》里，小马把mydemoPro的工作流从"每步都要人推"的线性流程，升级成了"自主循环、失败自愈、只在关口找人"的 Loop。用下来很爽——大部分变更，AI 自己就从评审一路跑到归档了。

但跑着跑着，小马又冒出个新念头：为什么单测、代码规范检查、安全扫描非得一个一个排队跑？它们互不依赖，明明可以同时跑啊。还有——改一行文案的小需求，凭什么也要走和改核心逻辑一样长的全流程？

这两个念头，线性的 Loop 都满足不了，因为 Loop 本质是"一条线"。要解决，就得把工作流从"直线"升级成"有向图"——这就是这一篇的主角Graph Engineering。

先说结论，免得你担心又要推倒重来：Loop 其实已经是一张"退化的图"了（一条主链 + 一条失败回边）。所以 Graph Engineering 不是从零再来，而是把这张图长出更多结构：分支、并行、条件路由、汇合。

第一章：先认清现状——你已经有半个 Graph 了

Loop 的状态机，本质上就是一张图，只是目前是最简单的形态：

当前（Loop）：一条主链 + 一条回边 评审 → 提案 → 写码 → 测试 → 部署 → 归档 ▲______|（测试失败，回退写码）

Graph Engineering 要做的，是让这张图长出更多结构：

目标（Graph）：分支 / 并行 / 条件路由 / 汇合 ┌─→ [单测] ─┐ 写码 ─→ (并行分发) ├─→ [规范检查] ├─→ (汇合) ─→ 部署 └─→ [安全扫描] ┘ │条件路由 简单变更? ──是──→ 直接归档 └─否──→ 走完整链

一句话：从"一条线"到"一张网"，这就是 Graph 相对 Loop 的进化。

第二章：Graph Engineering 的好处、代价与推荐场景

2.1 好处

相比 Loop 的"一条线走到底"，把工作流建模成有向图带来这些能力：

一句话：Graph 的核心好处是“表达力"和"并行度”——它能描述 Loop 无法表达的分支、并行、汇合、多 Agent 协作。

2.2 代价（好处的另一面）

任何增强都有成本，Graph 也不例外：

2.3 推荐使用场景

该用 Graph 的信号（出现任一即值得考虑）：

• ✅有互不依赖、可并行的步骤：比如单测、规范检查、安全扫描、类型检查可以同时跑——并行能明显提速。
• ✅不同变更要走不同路径：比如"改一行文案"想跳过完整评审直接归档，"改核心逻辑"才走全流程——需要条件路由。
• ✅多 Agent 分工协作：前端 Agent、后端 Agent、测试 Agent 各做一段并汇合——图天然适合编排。
• ✅流程会频繁调整：希望"改流程 = 改配置（边表）"而非改代码。
• ✅需要流程可视化 / 可观测：想在面板上看清每次跑的实际路径。

不该用 Graph、Loop 就够的信号：

• ❌ 绝大多数变更是"评审→写码→测试→归档"的固定线性流程。
• ❌ 步骤之间强依赖、无法并行（后一步必须等前一步结果）。
• ❌ 单人 / 单 Agent 开发，没有多方协作编排需求。
• ❌ 团队规模小、追求轻量（不想引入图的复杂度和外部框架）。

第三章：要新增 / 改造什么（对照 Loop 的四件套）

如果你已经按上一篇搭好了 Loop 的"四件套"（技能包驱动 + 状态机脚本 + 护栏规则 + 复用已有能力），升级到 Graph 只需扩展其中两件，技能包和护栏规则基本复用：

第四章：落地方案（分 4 步，从小到大）

4.1 第 1 步：把状态机数据结构从"数组"改成"图"

Loop 里，阶段通常是一个有序数组（阶段 = [评审, 写码, 测试, ...]，一条线走下来）。Graph 的第一步，就是把它改成显式的「节点表 + 边表」：

# 节点：每个是一个可执行阶段NODES={"评审":{"gate":None},"写码":{"gate":"写代码前审批"},"单测":{"gate":None},"规范检查":{"gate":None},"安全扫描":{"gate":None},"部署":{"gate":"部署前审批","optional":True},"归档":{"gate":"提交前审批"},}# 边：从哪个节点、在什么条件下、去哪个（些）节点EDGES=[{"from":"评审","when":"通过","to":"提案"},{"from":"写码","when":"通过","to":["单测","规范检查","安全扫描"]},# 并行分发{"from":"单测","when":"失败","to":"写码"},# 回边{"join":["单测","规范检查","安全扫描"],"when":"全部通过","to":"部署"},# 汇合]

这一步是 Graph Engineering 的核心——用"节点 + 边"取代"线性顺序"，一切分支 / 并行 / 循环都由边表描述。之后要改流程，改这张表就行，不用动控制逻辑。

4.2 第 2 步：实现三种"图特有"的流转能力

线性状态机没有、图才需要的三样：

4.3 第 3 步：护栏适配图结构（关键安全点）

图比线性复杂，护栏要跟上，否则更容易"跑飞"：

• 防环失控：图可能有多条回边 → 全局"最大步数"上限必须保留，且要检测非预期环（A→B→A 无限转）。
• 并行卡点裁决：并行分支里若有节点需要人工放行（如安全扫描），要定义"并行组里任一卡点未放行 → 整组阻塞"。
• 汇合的失败传播：并行分支只要有一个失败，汇合点应判定失败并触发对应回退，而不是傻等。

一句话：图越灵活，护栏越要收紧。表达力和安全性要同步升级，否则灵活就变成失控。

4.4 第 4 步：可视化（Graph 的天然优势）

图结构可以直接渲染成流程图（如 Mermaid），接到你已有的可观测面板：

• 实时高亮"当前在哪个节点"
• 标出走过的路径、回退的次数、卡在哪个汇合点

这是 Graph 相比 Loop 的一个直观增值——线性流程画出来就一条线，没啥好看的；图画出来，一眼就能看清这次跑批走了哪条路。

第五章：一个务实的建议——现在需要做 Graph 吗？

聊了这么多好处，小马还是得泼盆冷水：大多数项目，现在还不需要做完整的 Graph。

判断很简单，对照第二章 2.3 的信号：如果你的变更绝大多数是"评审→写码→测试→归档"的固定线性流程、步骤之间强依赖没法并行、又是单人开发——那Loop 就够了，别为了图而图。mydemoPro目前就是这种情况，所以小马也还没把它升级成完整的 Graph。

但这不代表什么都不做。更稳的路径是"备而不用"：

核心原则一句话：先把数据结构留成"图可扩展"的样子，需求来了再点亮，不一次到位。

总结

把三篇串起来看，其实是一条清晰的进化线：

三句话带走：

• 什么是 Graph：把工作流从"一条线"升级成"一张有向图"，支持分支、并行、条件路由、汇合。
• 为什么用 Graph：并行提速 + 按需分流 + 多 Agent 编排 + 可视化——线性流程给不了的表达力。
• 要不要现在做：多数线性场景 Loop 就够；先把数据结构留成图可扩展的样子，需求来了再点亮。

最后照例送一句心法：

Harness 让 AI 不越界，Loop 让 AI 自己跑完一条线，Graph 让 AI 在一张网里分工协作——表达力越强，护栏越要收紧。

Graph 也没有标准框架，都是按需进化的。理解了它和 Loop 的关系，你就知道：不必一步到位，先把地基留好，等真需求来了，从单链长成网，其实很自然。

不懂的、想交流的，还是老规矩，可以联系小马哈。这是继 Harness、Loop 之后的第三篇，建议三篇连起来看。