Graph Engineering：不是增加 Agent，而是设计 AI 系统的控制面

“总结这份文件，然后告诉我天气。”

这句话有两个动作，也有一个“然后”，却没有真正的依赖：查询天气并不读取文件摘要。若照着自然语言的顺序实现，第二项工作会无缘无故等待第一项结束。许多多步骤 Agent 的问题正是从这种虚假的“然后”开始的：独立任务被排成直线，共享上下文不断膨胀，一个步骤卡住，整条链也随之停下。

Graph Engineering（本文简称“图工程”）试图把这些被自然语言掩盖的关系重新画清楚。但它不是把流程图换成新名字，也不是用更多 Agent 换取更强智能。它关心的是 AI 系统的控制面：哪些工作有真实依赖，哪些可以并行；数据以什么结构交接；谁有权修改状态、调用工具或产生外部效果；错误在哪里被发现、隔离和升级；循环又在什么条件下停止。

“Graph Engineering”目前更接近一个社区标签，而非已有标准定义、参考架构和统一基准的独立学科。10 11 它讨论的组成模式也并不新。Anthropic 已将提示链、路由、并行、编排者-工作者和评估者-优化者总结为常见的 Agentic 工作流，并区分了“由代码预设路径的 workflow”与“由模型动态决定过程和工具使用的 agent”。1 新标签真正有用的地方，是把这些模式放到同一张系统图里，迫使工程师同时考虑依赖、状态、权限、验证、预算和失败路径。

本文采用一个克制的工作定义：

Graph Engineering 是对 AI 系统执行拓扑和控制面的设计：把 Agent、确定性代码、工具、人和评估器组织为有边界的工作单元，并显式规定它们之间的数据依赖、状态转移、并行、重试、终止、权限与失败路径。

这是本文综合社区讨论与现有工作流工程资料后采用的分析框架，不是某个厂商或标准组织发布的定义。

全文将用一条“带证据的技术研究报告”流水线贯穿八章：范围界定 -> 问题拆分 -> 并行检索 -> 确定性归约 -> 高影响主张验证 -> 综合写作 -> 人工批准与发布。这个案例不是为了证明 Graph 一定优于单 Agent，而是为了展示：当系统真的需要多种工作单元协作时，怎样让复杂度有理由、有边界，也有退出机制。

第一章：先去魅，Graph 不是 Loop 的继任者

当一个新术语出现，最省力的解释往往是一条技术演进路线：Prompt 之后是 Context，Context 之后是 Harness，Harness 之后是 Loop，Loop 之后终于轮到 Graph。仿佛每出现一个新对象，前一个对象就该退场。

这条叙事很顺，却混淆了不同设计层级。Prompt 约束一次模型交互；Context 决定模型此刻能看到什么；Harness 提供工具、运行环境和反馈；Loop 组织一个工作单元如何反复行动、观察和纠错；Graph 则把视野拉到系统层，回答多个工作单元如何连接、共享状态和交接控制权。后一个层次扩大了设计范围，并没有废除前一个层次。

这里的 Graph 画的是执行关系，不是知识关系。它不是 GraphRAG 或知识图谱，也不是图数据库。知识图谱中的节点可能是公司、论文和作者；执行图中的节点则可能是检索 Agent、去重函数、验证器或人工审批。执行图可以调用图数据库，但两者解决的不是同一个问题。

它也不等同于单个 Agent 内部的“规划 -> 行动 -> 观察”循环。Lilian Weng 对自主 Agent 的经典拆解聚焦规划、记忆、工具使用和反馈，这些都可以发生在一个节点内部。2 Graph 关心的是这个节点如何与其他 Agent、代码和人协作。

以代码修复为例：Agent 修改代码，测试程序运行测试；测试通过则结束，失败则回到修改节点；连续失败三次后升级给人。“修改 -> 测试 -> 失败后再修改”是一个 Loop，触发条件、测试节点、重试预算、通过出口和人工升级共同组成更大的执行图。说 Graph 将取代 Loop，就像说“形状将取代圆”：Loop 本来就是图中可能出现的局部结构。

因此，更稳健的默认方案不是“让多个 Agent 自由组成一张更大的图”，而是：

稳定的代码控制图 + 节点内有界的 Agent Loop + 显式的数据契约、验证门和恢复策略。

Anthropic 建议从最简单的可行方案开始，因为 Agentic 系统通常用延迟与成本换取任务表现；对不少应用，增强过的单次调用已经足够。1 图工程也包括有根据地决定“不拆图”。只有当系统出现了需要独立管理的数据依赖、控制权或失败路径，Graph 才开始成为真正的设计对象。

贯穿案例的起点因此仍是一个有预算的单 Agent 调研 Loop：理解问题、搜索资料、检查证据、生成报告。等任务需要覆盖多个独立来源、跨来源去重、核验关键主张、保留引用并在发布前获得批准时，再把外部控制面显式化。Loop 负责让一个工作单元在反馈中前进，Graph 负责让多个工作单元在约束中协作。

第二章：从线性步骤中找出真正的图

把需求中的动词依次放进方框，再用箭头连接，几分钟就能得到一张图；它也很可能只是把自然语言的顺序原样搬进系统。图工程的起点不是增加节点，而是证明每个节点为什么独立存在、每条边为什么不能删除。

假设研究流程被写成：“界定范围，然后拆分问题，然后检索官方资料，然后检索实践案例，然后查找反方观点，然后去重、验证并写作。”如果照着句子实现，三个检索任务会依次等待。但它们都只依赖研究问题，并不消费彼此的结果。真正需要串行的是“范围界定 -> 问题拆分”，真正需要汇合的是跨来源去重与后续验证。

审查每个“然后”时，可以连续问四个问题：

1. 下游是否读取上游的一项明确产物？
2. 删除连接后，下游会缺少什么数据或约束？
3. 如果保留数据关系、删除先后关系，两个节点能否同时执行？
4. 上游失败、超时或只返回部分结果时，下游应等待、降级、改道还是终止？

前两个问题寻找依赖，后两个问题寻找控制规则。回答不出任何一个问题的箭头，多半只是在表达“代码恰好写在下一行”。删掉伪依赖后，分支、汇合和并行机会会自然显现。

节点是一份可执行契约

“研究员”“审查员”“写作者”只是角色名称，不是系统边界。一个节点至少要说明它读取什么、产出什么、允许做什么、最多做多久，以及失败后图会看到什么。

单一职责不等于“只能调用一次模型或工具”，而是节点只对一种可独立判断的结果负责。它内部仍可运行有界 Loop。结构化输出则把节点边界变成可执行契约：研究检索节点可以返回统一的 claim/source/evidence/confidence 结构，其中 confidence 只是节点自评，不能替代验证。下游不必解析含混的自由文本，也无需继承上游的完整探索过程。

数据边、控制边与 state

社区材料常把边描述为真实的数据依赖；LangGraph 等图运行时还用边表达固定或条件执行转移。3 为了把两层问题说清，本文采用一组分析性分类：

• 数据边约定下游能读取什么，包括生产者、消费者、schema、证据、追溯信息和大小预算。
• 控制边约定下游凭什么获得执行资格，包括固定继续、条件分支、重试、升级和终止。

具体框架不一定真的把数据放在“边对象”中。节点可能通过共享 state 交换数据，edge 只负责转移；设计者仍需同时回答“下游读哪些字段”和“什么状态允许它运行”。如果一条边既没有载荷，也没有控制理由，它就不应存在。

State 也不是一份不断增长的聊天记录，而是图级公共数据模型。它保存跨节点协作、路由、恢复与审计需要的最小事实；节点只读取所需投影，并返回明确更新。LangGraph 的 Graph API 允许为 state 字段定义 reducer，以决定并发更新如何合并。3

class ReportState:
    brief: ResearchBrief
    questions: list[ResearchQuestion]
    evidence: list[Evidence]          # reducer: merge_evidence
    verified_claims: list[VerifiedClaim]
    draft: str | None
    approval: "pending" | "approved" | "rejected"

这里没有 all_messages、all_web_pages 或 agent_thoughts。原始网页可保存在外部对象存储中，由 Evidence 保留稳定引用；局部搜索对话留在检索节点内部。字段还应有所有权：问题拆分节点写 questions，检索节点只读；验证节点写 verified_claims，综合节点只读；approval 只能由人工步骤更新。

并发节点也不应共同修改一个隐式全局数组。它们各自返回 patch，再由 reducer 完成 schema 校验、拍平、精确去重和稳定排序。注意“确定性去重”的边界：规范化 URL、内容哈希和固定键去重可以由普通代码完成；两段不同措辞是否表达同一语义，需要不确定性判断，不能伪装成无误差的 reducer。

第三章：五种基本形状，以及什么时候不要用它们

节点、边和 state 明确后，拓扑选择就不再是画图偏好，而是依赖关系的结果。常见形状不是必须依次加入的成熟度阶梯，而是在回答不同问题。1 4

串行链适合数据逐级成熟的任务。研究案例中的“范围界定 -> 问题拆分”成立，因为后者需要读取受众、时间范围和排除项。相反，“检索官方资料 -> 检索实践案例 -> 检索反方观点”没有逐级依赖，不应排队。

路由在有限、预先允许的路径中选择一条。支持工单可以被结构化分类为 billing、technical、security 或 general，再由代码映射到不同提示词、工具和权限。模型可以提出类别，但退款、部署或跳过安全检查等高风险权限，不能由未经校验的自由文本直接授予。

并行与菱形适合已知的独立子任务：一个节点扇出，多条分支同时工作，结果归约后再交给需要全集的节点。在研究案例中，多个来源分支只读取同一个问题，分别返回 Evidence[]，随后由确定性代码去重，再交给主张验证。并行有机会缩短墙钟时间，却不会自动减少模型调用和总 token，也不会自动让结果更正确。

屏障只应放在必须看到全集的位置。跨来源去重、全局排序、比较候选或判断结果集合是否为空，需要等待所有必需分支；单条证据的 schema 校验、URL 规范化和片段抓取只依赖当前条目，可以继续向前流动。屏障的代价由最慢的必需分支决定，“阶段看起来整齐”不是同步理由。

编排者-工作者用于无法预先列完工作项的任务。例如，代码迁移涉及哪些文件，要先读取仓库才知道；开放研究需要拆出多少问题，也取决于本次范围。编排者可以输出受限的 WorkItem[]，代码负责校验数量、选择允许的 worker、设置并发与预算。动态的是任务集合，不是权限和控制规则。

评估者-优化者只有在质量标准可表达、反馈能产生可测改进时才值得画回边。评估器应返回主张 ID、失败标准、证据缺口和建议动作，而不是“再写好一点”。引用格式和必需字段优先由代码检查；语义支持关系再交给模型或人。循环还必须有轮数、时间、费用和停滞出口。

一张图不必凑齐五种形状。研究案例自然需要串行、动态工作项、独立检索并行、一次必要屏障和条件验证；是否加入草稿修订循环，则应由评测决定。确定性代码能完成的路由，也无需额外增加“路由 Agent”。

第四章：可靠性不来自更多 Agent，而来自门、边界与停止条件

形状正确只说明依赖没有画错，并不说明结果值得相信。多个 Agent 会带来更多候选判断，也会带来更多交接、失败点和共享偏差。图能做的不是消灭错误，而是规定错误必须经过哪些门、最多扩散多远、最迟何时停下。

验证门是一条反证接口

验证门应位于高影响产物进入下游之前。它的职责不是复述上游答案并表示赞同，而是针对明确标准，尝试定位、反驳、复现或交叉检查。研究报告中的核心数字、版本限制、因果判断和技术选型结论需要验证；过渡句未必值得支付同等成本。

验证节点应接收可追溯的最小单元，例如 claim_id、主张、适用范围、原始来源、证据片段和检索时间，并返回有限状态：

前三种是证据判断，第四种表示判断没有完成。工具失败不能伪装成“没有发现”，更不能被合并为通过。来源地址是否可访问、片段能否定位、数字和日期格式是否正确，可以先由代码或工具检查；语义上是否支持主张，再交给模型判断。对可执行结论，测试、静态分析和外部系统结果往往比另一次自然语言自评更接近环境事实。Anthropic 也强调 Agent 应从工具调用、代码执行等环境反馈中获得 ground truth。1

多视角检查可以扩大失败模式的覆盖面，却不能把投票变成事实。几个验证器若使用同一模型、同一资料和同一上下文，其错误并不独立。正确性、安全性、可复现性和来源忠实度等不同视角，通常比重复同一提示更有解释力；出现分歧时应保留证据并补证或升级人工，而不是让两个“通过”静默覆盖一个有根据的反对意见。

故障隔离必须保留缺口

一个分支失败后，其他分支能够继续，只说明计算没有一起取消；如果汇合节点不知道缺了什么，系统仍可能把残缺结果包装成完整答案。每个扇入点都要声明哪些输入必需、哪些可以缺失、缺失后如何降级，以及降级状态怎样传给下游。

用户指定的官方来源失败，可以有界重试，但不能在最终报告中假装已经覆盖；补充性的社区案例超时，可以继续并标记 partial；高影响主张没有验证结果，则不能进入正文。合法的 evidence = [] 表示节点完成了检索但没有结果，status = error 表示任务没有完成，两者不能混在一起。

并行计算之外，还要处理共享资源。多个工作者同时修改同一文件、数据库记录或工单，必须通过资源所有权、隔离工作区、事务、版本检查或串行提交解决。让 Agent 在 Prompt 里“注意不要冲突”，不是并发控制。

循环必须有目标、进展和硬上限

“最多三轮”只保证循环会被截断，不能证明前两轮在收敛。一份完整的循环契约至少包括：

1. 成功出口：哪些条件满足后可以结束。
2. 进展指标：新增未见候选、证据覆盖提高，或待解决集合缩小。
3. 停滞出口：连续若干轮没有可测进展时，返回部分结果或升级人工。
4. 硬预算：最大轮数、墙钟时间、token、工具调用与费用上限。
5. 异常出口：关键工具持续失败、状态冲突或输出始终不合法时终止。

未知规模的搜索尤其要对所有已见候选去重，而不只是对最终确认结果去重。否则，被拒绝的候选会在每轮重新出现，系统持续花钱验证同一条死路。循环结束也不该只有一个 done：completed、stalled、budget_exhausted 与 failed 对下游含义不同。预算耗尽不能被改写成“研究充分”。

图运行时提供的递归或步数上限可以作为最后保险，却不能替代业务停止条件。运行时知道走了多少步，却不知道主张是否已验证、搜索是否还有新证据、修订是否真的改善了结果。3

第五章：上下文工程其实也是边工程

验证门最终只能在它收到的信息上判断。如果输入是整段检索对话、彼此矛盾的摘要、没有定位信息的结论和大量重复工具输出，再严格的状态枚举也只是在低信号上下文上做结构化判断。

Anthropic 将上下文视为有限的注意力预算，并把好的上下文工程概括为：找到能够提高目标结果概率的最小高信号 token 集合。5 放进执行图中，上下文工程就是为每个节点构造有目的的 state 投影，并规定它沿边如何交付。

图级 state 与模型上下文不是一回事。State 可以保存完整、可校验和可恢复的公共事实；上下文只是某个节点在某次推理中真正看到的信息。一个验证节点需要主张、原始证据片段、来源位置和适用范围，不需要检索 Agent 尝试过的所有关键词；综合节点需要已验证主张、反证、引用和覆盖缺口，不应越过验证门浏览全部未通过候选。

一份边负载契约至少要回答六个问题：下游用它做什么；哪些字段缺失时不得继续；如何回到原始来源；最大条目或 token 预算是多少；哪些内容可以压缩；哪些过程日志和未验证判断禁止进入。

关键原则是：可以压缩结论，不能压掉证据入口。 摘要必须保留稳定来源、适用范围与取回原文的方法。事实、判断和运行状态也要分开：source_excerpt 是来源内容，verdict 是验证器判断，status = error 表示判断没有完成，三者不能被压成一句自然语言。

子任务隔离不仅缩短上下文，还能减少不同探索路径互相锚定。每个检索工作者在独立上下文中搜索，只向图级 state 返回结构化、可追溯的 Evidence[]。但隔离不能以丢失证据为代价；统一 schema 仍需包含问题 ID、来源类型、原始片段、定位信息、时间和失败状态。

当资料远大于单次上下文时，可以在 state 中先保存标题、地址、时间、标签、内容指纹和对象 ID，再按需取回当前判断需要的片段。按需检索能够避免预载所有材料，却会增加运行时延迟和工具导航失败。因此更实用的默认方案是混合式：稳定指令、schema 和权限边界预先放入；大段资料以索引存在；节点按需取回；高风险结论设置最低证据要求，检索失败不得被解释为“没有反证”。

工具本身也是上下文接口。工具名称、用途、参数和返回形状决定环境信息如何进入节点。职责重叠的工具集合会增加选择歧义，过大的返回会挤占后续推理。研究工具应优先返回规范化片段、来源地址、上下文范围和截断标记，而不是默认把整页 HTML 塞进消息历史。

长任务还需要区分三种记忆策略：5

• 上下文压缩保存当前对话的连续性，但可能遗漏后来才显重要的细节。
• 结构化笔记保存里程碑、已决事项、未解问题和下一步，但必须处理过期与版本冲突。
• 子任务隔离保存局部探索深度，但汇合时必须保留证据链和统一 schema。

“最小充分上下文”最终是一项可测试属性：删除必需证据时，下游应拒绝继续；加入大量无关材料时，关键判断不应明显退化；压缩后，引用和限制仍可追溯；按需检索失败时，节点应返回 error 或 partial，而不是补写不存在的信息。

第六章：从能跑一次到可以恢复，状态与副作用才是生产分水岭

Checkpoint 能让长任务不必每次从头开始，却不能证明外部世界没有变化。假设发送节点已经把邮件交给服务端，只是在响应返回前网络断开；本地 checkpoint 看不到成功结果。恢复后再次执行，可能补上一次失败，也可能发出第二封邮件。数据库写入、退款、部署和付费 API 调用都有同样的问题。

生产化的分水岭不是“是否启用了持久化”，而是能否同时回答：恢复时信任哪份状态，哪些代码会重新执行，同一个外部意图怎样至多产生一次被系统认可的效果。

以 LangGraph 的术语为例，checkpointer 保存单个 thread 的图状态快照，store 保存图状态之外、需要跨 thread 使用的应用数据。6 二者都不能替代外部效果记录。

继续、重试和重放也不是同一个动作。LangGraph 官方文档说明，从历史 checkpoint 重放时，checkpoint 之前的结果被保留，之后的节点会重新执行，LLM 调用、API 请求和中断也会再次触发。7 interrupt 恢复时，包含中断的节点会从头重启，因此中断前的副作用必须可重执行，或被移动到中断之后的独立节点。8 其他运行时的粒度可能不同，但设计时必须确认最后提交边界与最小重执行单元。

可以把可恢复执行写成：

可恢复执行 = 持久的状态快照
           + 明确的重执行边界
           + 可识别的业务意图
           + 可去重或可核对的外部效果

这里的幂等保护的是业务意图，不是某次函数调用。发送报告的标识不能只使用 thread_id，因为同一 thread 可能生成多个版本、使用不同收件人。本文建议在副作用之前，用已经 checkpoint 的稳定 state 生成效果标识：

effect_id = hash(
  workflow_id,
  effect_type,
  report_version,
  canonical_recipient_set,
  delivery_channel
)

effect_id、payload_hash 和报告版本先被持久化，再由效果账本通过唯一记录、条件更新或租约授予执行资格；调用外部服务时继续传递同一个幂等键，并保存提供方返回的 ID。若服务端可能成功但客户端超时，状态应进入 unknown：优先按原键查询或重试；外部系统既不支持去重也无法查询时，自动路径必须停止并转人工核对，不能诚实地承诺 exactly-once。

人工批准也应是一条控制边，而不是 Prompt 里的软建议。批准记录应绑定审批人、动作类型、报告版本、payload hash、收件人、渠道、环境、有效期和撤销状态。内容一旦改变，旧批准失效。批准解决未经授权的效果，幂等解决同一效果的重复提交，两者不能互相替代。

状态 schema 还会随代码演进。当前 LangGraph 文档明确指出，在途 checkpoint 会由最新代码加载；重命名或删除即将进入的节点、收紧字段类型、增加无默认值的必填字段，都可能破坏恢复。推荐做法包括新增可选字段、先新增后弃用、排空旧 thread，以及在 state 中记录 flow_version 以区分技术兼容与业务兼容。9

因此，可观测性必须能还原一次恢复决定，至少关联：

• workflow_id、thread_id、checkpoint_id、graph_version、schema_version；
• 节点尝试次数、开始与结束时间、错误类别和路由决定；
• 模型与工具版本、token、超时、重试和截断；
• approval_id、批准范围和 payload hash；
• effect_id、提供方请求 ID、结果状态和核对记录。

恢复测试也不能只看最终返回值。进程应被主动停在“外部服务已接受请求、本地未收到响应”“本地收到成功、效果账本未更新”“人工批准后 payload 发生变化”“中断期间 schema 升级”等位置。断言不是笼统的“最终成功”，而是同一 effect_id 不产生两个被认可的效果、结果不明时不会伪装成失败、批准只覆盖冻结 payload、旧 checkpoint 不会越过新验证门。

第七章：拓扑就是成本模型，但复杂度必须用数据证明

“拓扑就是成本模型”并不是说只看图就能算出账单，而是说图决定哪些工作必然发生、哪些可以重叠、哪里必须等待、什么条件会放大调用次数，以及失败后需要重做多少工作。真实输入、模型、工具、并发限制和运行数据，才提供计算参数。

对真正独立且近似同时启动的分支，可以用一组简化关系理解并行：

串行阶段墙钟时间 ≈ sum(各分支执行时间) + 编排开销
并行阶段墙钟时间 ≈ max(各分支完成时间) + 扇出/扇入开销
总工作量 ≈ sum(实际执行的模型、工具与代码工作)

这不是容量规划公式。排队、限流、连接池、重试和共享资源竞争都会改变结果。它只揭示一个稳定区别：并行改变独立工作的重叠方式，不会因为同时执行就自动删除工作。研究图的三个检索分支并行后，墙钟时间可能缩短，三次调用、三组搜索和三份输出依旧存在。

屏障则把最慢的必需分支变成所有分支的等待。条目级流水线能够删除不必要的中间同步，却不能消除最终确实需要全集时的尾延迟。屏障指标不应只有一个总时长，还应记录各分支队列与执行时间、最早和最晚到达、空等时间、缺失分支、超时原因、取消是否成功，以及下游最终消费了哪些结果。

验证、动态拆分和回边会进一步放大工作量。一次生成后再启动多个检查，至少增加对应的检查工作；证据不足又触发补检索和重写，成本继续沿回边增长。编排者输出多少工作项，后续就可能启动多少 worker，因此除了单节点 token，还要限制工作项数量、并发宽度、重试、整图时间和总费用。

模型分层也只能按职责提出假设，再用评测决定。确定性校验、精确去重和权限规则应优先由普通代码承担；边界稳定、输出受限的分类或抽取节点可以评估较便宜的模型；跨来源综合和高风险裁决可能需要更强模型。但路由本身也有调用成本和误路由损失。便宜路径若频繁回退或触发强模型复核，分层方案可能更慢、更贵。

一份可归因的成本账本至少应同时记录：

项目现有资料没有提供同一任务上单次调用、单 Agent Loop 与 Graph 的可复现实验，因此本文不声称“改成图后必然更快、更便宜或更准确”。正确的验证方式是建立基线，固定任务与来源，逐项加入并行、归约、验证、补证和持久化，使用同一成功标准比较，并对非确定性节点重复运行。再通过消融逐项移除组件，判断收益究竟来自哪里。

简单问题上，单次调用可能已经足够；开放研究或高风险发布上，额外门控和恢复才可能产生净收益。每个新节点都应带着一份可被推翻的假设进入系统：并行是否在覆盖不下降时改善 P95；验证是否降低不受支持主张率；补证是否真的带来新来源；模型分层是否在质量下限内降低总费用。假设不成立时，删除节点、合并边界或退回基线，都是正确结果。

第八章：一张可落地的最小图，应该怎样设计

所谓“最小图”，不是节点数量最少，而是能够满足当前成功标准、约束已知风险，并且每一处复杂度都有证据或可验证假设的最小控制图。面对一个新任务，可以按下面八步推导。

第一步：冻结目标与成功标准

第一份产物不应是流程图，而是一张运行边界卡：交付目标、受众、时间范围、排除项、质量与覆盖标准、延迟与费用预算、人工介入点和降级语义。成功标准必须能够否定一次运行，例如“所有进入正文的高影响主张都有可定位来源”“必需来源失败时不得声称完整覆盖”“发布动作必须绑定有效批准”。

风险也要分层。版本限制、数字、兼容性和因果结论可以标记为高影响；过渡句接受较轻检查。模型可以提出风险标签，但不能单独决定自己的哪些主张免于验证。

第二步：跑通一个有界 Loop 基线

先用最简单方案面对同一批任务：读取 ResearchBrief，检索并登记证据，生成草稿，再执行固定的引用和覆盖检查。它有轮数、时间和用量上限，也没有发布权限。基线与后续 Graph 使用相同的报告格式、引用映射、来源快照和指标，否则比较会同时改变拓扑与验收标准。

观察基线失败，再做最小响应：独立来源串行导致 P95 累加，才拆并行分支；证据重复，才加确定性 reducer；关键主张经常引用错位，才加主张级验证；中断后总要从头开始，才在稳定边界保存 checkpoint；发布重试可能重复，才加批准、效果账本与幂等键。

第三步：按失败边界定义节点契约

候选节点不按职位切分，而按可独立验证、可独立失败、权限不同和恢复价值切分：

补检索可以复用 retrieve 契约，不必复制另一个同能力 Agent。scope 与 decompose 也不是永远必须分开；只有能说明独立测试、权限、伸缩或恢复理由，节点边界才值得保留。

第四步：建立边登记表

每条候选边都写下数据负载、控制条件、失败出口和删除后果。例如，verify_claim -> synthesize 只在 verified 时交付主张、限制、反证和引用；insufficient 进入补证，rejected 被隔离，error 进入失败策略。approve -> publish 只有在批准有效、范围匹配、payload 未变化时可达。

边登记表也是数据访问白名单。综合节点没有从原始检索历史进入的合法边，就不应捞回被拒材料；发布节点没有从模型自由文本获得权限的边，就不能因为报告中写着“已经批准”而执行。

第五步：只在数据独立时并行，只在全集判断前设屏障

工作项不读取彼此中间结果、不共同写同一资源、失败可独立结算，才适合并行。并发宽度还要受来源限流、连接池与整图预算约束。单条证据的 schema 校验、URL 规范化和内容指纹可随条目完成；跨来源精确去重、必需来源覆盖和全局候选生成，才需要看到全集。

第六步：只验证高影响主张，让补证循环有界

验证先做来源可访问性、引用定位、日期与数字格式等确定性检查，再判断证据是否在声明范围内支持主张。insufficient 必须携带缺失的证据类型、已查来源、已见候选和剩余预算，而不是含混地“再试一次”。案例可以先采用最多两轮作为待评测配置，但不能把它写成通用最佳值。

第七步：对齐 state、checkpoint 与外部效果

State 保存跨节点协作、路由、恢复和审计需要的最小公共事实；原始网页与大段工具输出放在按稳定 ID 取回的外部存储。报告版本、payload hash 和 effect_id 在副作用前持久化；批准绑定这个冻结对象；外部结果进入效果账本。State 同时保存 schema_version 和 graph_version，迁移测试覆盖在途 checkpoint，而不只是新运行。

第八步：用增量评测决定哪些复杂度留下

建立一条增量版本阶梯：

每个版本使用同一批按简单、开放和高风险分层的任务，并注入必需来源超时、reducer 输入乱序、验证冲突、重复 URL、服务端成功但本地未记账、旧 checkpoint 加载新 schema 等故障。复杂度评审必须允许删除：若并行没有改善目标 P95，退回串行；若验证器与生成者错误高度相关，缩小验证范围或删除节点；低风险任务不需要发布时，可以在更轻版本提前结束。

经过八步，贯穿案例的候选图如下：

这张图仍然只是一组待验证的工程假设。框架 API 只是承载设计的方式；真正的最小设计包应包括运行边界卡、节点契约、边登记表、state 与所有权 schema、循环与降级出口、副作用与恢复方案，以及基线和故障评测。如果换一个运行时后，这些产物仍能说明系统行为，控制面才真正独立于框架存在。

结语：成熟的 Graph，不是更自由，而是更可解释

回到开头那句“总结文件，然后告诉我天气”。删掉虚假的“然后”，意义不在于画出一张更漂亮的图，而在于逼迫系统说明：工作为什么流向这里，判断由谁作出，错误能走多远，以及什么条件让它停下。

Loop 没有过时。它仍然负责局部探索、反馈和纠错；Graph 负责约束多个 Loop 如何共享状态、交接控制权和处理失败。没有契约、验证、预算、幂等和观测的多 Agent 系统，只是把一个 Agent 的不确定性扩散到了更多节点。

因此，成熟度的判断标准从来不是节点数量，而是工程团队能否清楚回答：

• 为什么存在这条边？
• 谁拥有这份状态？
• 哪些信息可以进入下一个节点？
• 失败后从哪里恢复，哪些代码会重新执行？
• 什么条件让循环停止，什么状态允许外部动作发生？
• 新增的复杂度究竟改善了哪个可测目标？

Graph Engineering 真正改变的，不是 Agent 能做多少事，而是工程师能否清楚说明：工作如何流动，判断在哪里发生，错误在哪里被拦住。

拿出现有的一条 Agent 工作流，逐条检查其中的每个“然后”：它传递了什么数据，施加了什么控制约束，删掉后会损失什么？如果答不出来，那条边很可能不该存在。

参考资料

1. Erik Schluntz, Barry Zhang. Building Effective AI Agents. Anthropic. 关于 workflow/agent 区分、复杂度原则，以及提示链、路由、并行、编排者-工作者和评估者-优化者。
2. Lilian Weng. LLM Powered Autonomous Agents. 2023. 关于 Agent 的规划、记忆、工具使用、反馈与局限。
3. LangChain. LangGraph Graph API overview. 关于 state、node、固定/条件 edge、reducer、动态 worker 与递归边界。
4. LangChain. Workflows and agents. 关于常见工作流模式及其显式图实现。
5. Anthropic Applied AI Team. Effective context engineering for AI agents. 关于最小高信号上下文、工具设计、按需检索、压缩、笔记与子任务隔离。
6. LangChain. LangGraph Persistence. 关于 checkpointer 的 thread 级状态与 store 的跨 thread 数据职责。
7. LangChain. Use time-travel. 关于从历史 checkpoint 重放时的重新执行语义。
8. LangChain. Interrupts. 关于中断、恢复、人工介入和中断节点的重执行边界。
9. LangChain. Backward compatibility. 关于在途 checkpoint 的技术兼容、业务兼容和 flow_version。
10. Codez. Graph Engineering with Claude: 14-Step Roadmap. 社区文章；本文仅采用其中节点/边、菱形、验证和循环收敛等通用直觉，未把特定产品 API、并发、模型继承和计费行为作为已核实事实。
11. SmartScope. What Is Graph Engineering? How It Differs from Loop Engineering and Whether the “Obituary” Is True. 二次分析；用于理解社区术语、Graph/Loop 关系和复杂度争议，不作为行业标准定义或量化结论依据。

资料核验说明：第 1、3-9 项为官方工程文章或官方文档，第 2 项为作者技术综述，第 10-11 项为社区材料。在线技术文档已于 2026-07-28 核对；产品行为可能随版本变化，实施时仍应以所用版本的官方文档和实际测试为准。