Graph Engineering 两篇对照：战略观 vs 工程观

摘要

2026 年 7 月下旬，Graph Engineering（图工程）成为 AI Agent 编排领域的热门范式，两篇高热文章从不同角度定义它。本分析对比两者，提炼共识、差异与可操作结论。

	文章 A：@0xCodila 的 X 长文 (7-21)	文章 B：Graph工程完全指南 (7-26，原文 @Gyome1_)
视角	战略/范式：为什么从 loop 进化到 graph	工程/战术：怎么把图设计得可靠省钱
核心隐喻	节点思考、边传结果；“prompter 提问，architect 画图”	分布式系统：DAG、流水线、MapReduce 老模式换新内容
落地抓手	Claude Code Dynamic Workflows 官方功能	手工编排：parallel()、barrier、router、worktree
规模叙事	1 窗口 1000+ agents、16 并发，Bun 移植案例（$165k/11天）	成本优先：“Graph工程从账单开始”

verifier 必须独立上下文：agent 自检会自我放水。A 说”共享上下文的 agent 图只是穿了马甲的单 loop”；B 给出实现——对抗性审查者小组，任务是”找错”而非”改进”，投票 ≥2 才放行。
并行写入必须隔离：两篇都引 Bun 团队的教训（agents 互相覆盖文件）。解法一致：git worktree 隔离 + 结构性禁止危险命令，不是靠 prompt。
别给小任务画图：A 列了 4 条”skip the graph”场景（任务小/需逐步审批/探索期/真串行）；B 的判断标准等价——单模型能装下上下文、无独立分支、错误代价低时用线性。
成本是图的第一属性：A 提醒 workflow 比普通 session 贵得多（省的是协调不是工作量）；B 更激进——模型分层，提取/分类用便宜模型，综合/审查用强模型。

A 补 B 的”上限”：B 讲的是 5-20 个 agent 的手工编排，A 指出官方 Dynamic Workflows 把天花板推到 1000 agents/16 并发，且中间结果存在脚本变量里不占对话上下文（“零 token 协调”的真相：省协调不省算力）。
B 补 A 的”细节”：A 的 5 步课只到”verifier 要干净上下文”，B 给出全套工程件——
- 边携带结构化证据（schema：file/lines/confidence/evidence），自由文本传递会累积歧义
- 确定性归代码：去重、合并、排序用 JS 不用模型，省钱且结果稳定
- 收敛循环：seen 集合对”所有见过的项”去重（不只已确认的）+ 连续 2 轮无新发现即停
- 归约保链接：压缩证据时保留 sourceFindingIds，可追溯
理论根基不同：A 引 Goodhart 定律（单 loop 只盯自己指标）论证”为何需要图”；B 引软件工程四十年积累（DAG/屏障/MapReduce）论证”图不是新东西，新的是节点里装了模型”。

起手式：对每个”然后”问一句——下一步真的读上一步的输出吗？不读就并行。这是两篇文章共同的最小可行习惯。
验证节点三要素：独立进程/上下文 + 检查真实信号（测试真跑过没有，而非”agent 说完成没”）+ 冻结规则（agent 无权修改的锚点）。
扇出前回答三问（A 文原话）：每个 agent 在哪干活？结果怎么合并？两个 agent 意见冲突怎么办？
模型分层省钱：搜索/提取用 flash 级，路由判断用 plus 级，最终综合用 max 级。
规模路径：先用 Dynamic Workflows 从 20 个 agent 起试水看成本，再放开到上限；B 的手工编排适合需要精细控制边 schema 的场景。