图工程快速指南
从聊天机器人到循环再到图：如何架构、治理并为多智能体 AI 买单，通过一个可运行的发票纠纷解决系统来阐释
AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo
你的 AI 智能体处理简单情况时非常出色，而在风险上升的关键时刻恰好失败。这种模式在生产中如今已如此普遍，以至于迫使人们进行架构反思：不要继续扩展单个智能体，而应围绕它来工程化整个组织。这就是图工程（graph engineering），一门新兴的学科，将多智能体系统设计为受治理的拓扑结构，其中智能体、确定性代码、策略路由器和人工检查点成为显式图中的节点，而治理从提示词中的一句美好愿景变成结构本身可证明的属性。
本文带你走过从聊天机器人到循环再到图的完整演进过程，然后将其落地：一个基于 LangGraph 和 Claude 构建的可运行的发票纠纷解决系统，从一个不断失败的单一智能体重构为七节点图，成本降低 84%，速度快三倍，并且在关键场景下结果正确。
让我们开始吧。
1. 问题所在：你的智能体在关键时失效
让我们从一个每个企业都熟悉的系统说起。一位客户发邮件对发票提出异议。他们认为三个行项目被多收费了，援引了合同条款，并要求退款。你组织中的某个人现在必须对投诉进行分类、调取合同和订单历史、重新计算发票本应是多少、判断客户是否说得对、起草回复，并且如果确实需要退款，还要转移资金。
2024 年你会构建一个聊天机器人来挡掉这封邮件。2025 年你会构建一个智能体来处理它。智能体，按行业现在对这个词的使用方式，是一个包裹在循环中的大语言模型：模型读取任务，决定一个动作，调用一个工具（模型可以调用的函数，例如数据库查询或 API 调用），观察结果，然后重复，直到它宣布任务完成。
于是你构建了一个。你给一个强大的模型五个工具：搜索纠纷、获取合同、获取订单、计算退款、发送回复。你精心编写了系统提示词。对于简单的纠纷，它工作得很好。说实话，有点神奇。
然后一个棘手的案例来了。一个纠纷跨越两个合同修订案中的十四个行项目，还包含一次期中价格变更。你的智能体拉取合同，拉取订单，开始在自己的上下文窗口（模型一次能看到的文本工作记忆）内推理算术。大约在第九步，它把两个数字弄反了。然后它自信地为 4,180 美元发放退款，而正确的数字是 1,480 美元。什么都没崩溃。没有抛出任何错误。系统只是通过推理在金钱上出了错，而且没有任何审计追踪能解释原因，因为这个"决策"散布在一份长达四十次工具调用的对话记录中。
这就是本文要解决的问题。单智能体循环——2025 年的主力工作模式——存在天花板，生产系统正在撞上它。有三种失败模式反复出现：
上下文饱和（Context saturation）。智能体看到的一切都累积在一个上下文窗口中。等到它做出关键决策时，相关事实已经被检索碎片掩埋，模型注意力也随之下降。
无界委派（Unbounded delegation）。智能体可以按任何顺序、任意次数调用它的任何工具。没有结构性保证资金转移必须经过策略检查，因为"结构"只存在于提示词的建议之中，而提示词是请求而非约束。
行为与结构纠缠（Behavior entangled with structure）。智能体如何推理（它的行为）与整个任务如何组织（它的结构）位于同一个地方：一个提示词，一个循环。你无法分别对它们做版本管理、分别测试，或将它们交给不同的负责人。
针对这一天花板而涌现的学科被称为图工程：将多智能体系统本身设计为一张工程化的图，你指定哪些节点存在、哪些节点之间的转换被允许，以及运行时任务结构如何形成 [1]，[2]。本文解释这意味着什么、它从何而来、为什么重要，然后围绕上述发票纠纷系统，用真实代码构建一个实际的例子。
开始之前有一个诚实说明。截至撰写本文，这个术语才出现几周，其出处存在争议，而且它与知识图谱领域的旧用法相冲突 [2]。这个名字可能留存，也可能不会。它底层的工程问题是持久的，而这些才是本文真正要讲的内容。
2. 我们如何走到今天：聊天、智能体、循环、图
理解图工程最快的方式是走一遍行业的演进过程，因为每个阶段都是为了修复前一阶段的失败模式而存在。
第一阶段：聊天（2022 至 2023 年）。模型回答一条消息。工作单元是单次补全：文本进，文本出。这个时代的工程学科是提示词工程（prompt engineering），即雕琢指令措辞的艺术，让模型产出你想要的。其局限显而易见：模型能谈论工作，却不能做工作。
第二阶段：工具与 RAG（2023 至 2024 年）。两个新增功能改变了这一点。工具使用（也称为函数调用）让模型发出结构化请求，由你的代码执行，这样模型就能对世界采取行动。检索增强生成（RAG）让模型在回答前将相关文档拉入上下文，从而让它扎根于你的数据而非训练记忆。工程学科成熟为上下文工程（context engineering）：决定一次模型调用能看到什么信息、以什么形式、多长篇幅。局限是：每次调用仍然是一次性的。多步骤问题需要人类来驱动。
第三阶段：智能体与循环工程（2024 至 2026 年中）。ReAct 模式 [9] 闭合了循环：让模型推理、行动、观察结果、再次推理，自主进行，直到完成。行业花了两年时间学会如何把这个循环工程化好，一个真正的学科围绕它形成，有时被明确命名为循环工程（loop engineering）[1]：设计单个智能体的迭代周期。它重试什么？何时停止？如何自我检查？当循环运行很长时，它的上下文如何被压缩？Anthropic 关于构建高效智能体的指南捕捉了这一时代来之不易的共识：对于大多数任务，简单且仪器完备的循环胜过精巧的架构 [10]。
循环工程过去是、现在仍然是真正有价值的。但第三阶段的一切都发生在一个智能体内部，而第 1 节中的三种失败模式都是那个"一"的后果。
**第四阶段：图工程（2026 年中至今）。**对天花板的回应是停止扩展智能体，转而结构化组织。不是用一个带许多工具的循环，而是构建许多专门的节点，并在它们之间显式布线。在当前讨论中流行起来的表述很精炼：循环让智能体行为可编程；图让智能体组织可编程 [1]。
演进过程用表格表示如下：
+---------+------------------+----------------------+---------------------------+
| Era | Unit of work | Discipline | Ceiling it hit |
+---------+------------------+----------------------+---------------------------+
| 2022-23 | One completion | Prompt engineering | Can talk, cannot act |
| 2023-24 | Grounded call | Context engineering | One shot, human drives |
| 2024-26 | One agent loop | Loop engineering | Saturation, no governance |
| 2026- | Agent org graph | Graph engineering | (open; see Section 10) |
+---------+------------------+----------------------+---------------------------+
注意这一演进保留了什么。图工程并不会取代早期层级。图中的每个节点仍然需要良好的上下文工程。每个智能体节点内部仍然需要一个工程良好的循环。这些层级层层叠加，新的一层位于最上层 [1]，[4]。
3. 图工程到底是什么
现在给出精确的定义，因为文章的其余部分都依赖它们。
图（graph），按计算机科学的意义，是一组由边连接的节点。没什么特别之处：就是方框和箭头的形式化。
图工程是设计多智能体系统拓扑（其形状）的实践：哪些节点存在、节点之间允许哪些转换，以及运行时任务结构如何形成和变化 [2]。它回答结构性问题。谁做什么？谁可以把工作交接给谁？人在哪里？什么事永远不会发生？
有两张图很重要，把它们搞混是导致这个话题上大多数混乱文章的原因：
组织图（org graph）是系统的常设结构：定义好的角色、它们的工具、它们被允许的关系。它相当于一张组织架构图外加一套标准操作流程。你像对待代码一样设计它、评审它、做版本管理，因为它就是代码。
工作图（work graph）是为某个特定任务在运行时创建的临时结构：这个纠纷，被分解成这些步骤，有些并行，有些串行。工作图是实例；组织图是类。你像记录追踪（trace）一样记录工作图 [1]。
四类节点构成了这些图 [2]：
智能体节点（agent node）是一个带有角色、工具和自身循环的 LLM。它处理判断。
确定性节点（deterministic node）就是普通代码：同样的输入，同样的输出，每次都一样。它处理一切有正确答案的事情。
路由器节点（router node）是一个条件分支：它检查状态并选择下一条边。它处理策略。
人工检查点（human checkpoint）是图停下来等待真人的节点。它处理问责。
还有三个辨析，因为"图"这个词现在在 AI 的三个不同领域里都被大量使用：
这不是知识图谱工程。知识图谱将数据结构化为实体和关系（Acme Corp，is-customer-of，YourCo）。GraphRAG 是一种检索技术，通过遍历此类图来回答多跳问题，它结构化的也是数据 [5]。本文意义上的图工程，结构化的是智能体组织。一个系统可以两者兼用：智能体按组织图接线，同时在知识图谱上进行检索。同一个词，不同的层，这种冲突是这个名字的一个已知问题 [2]。
这不是经典的工作流编排。像 Airflow 这样的工具执行预定的、由确定性步骤构成的静态图。图工程处理的是包含非确定性节点（智能体）的图，这些图有时由规划器在运行时生成，而其核心工程问题在于约束哪些图可以存在。
这不仅仅是拥有 LangGraph。LangGraph [6]、CrewAI 和 AutoGen 等框架是基质（substrate）：它们给你构建图的原语。图工程是在其上施展的设计学科，就像拥有 Terraform 并不等于你就有良好的基础设施架构一样。本文使用 LangGraph，因为它是当前事实上的基质，而其中每一个设计决策都可以迁移到任何其他框架。
4. 为什么要费这个劲：把好处说清楚
在展示代码之前，先说回报。图工程通过四种方式回报其复杂性。
通过专业化获得可靠性。小而专注、输入干净的节点，胜过单个饱和的通才。每个智能体节点只看到其角色所需的上下文，这是把上下文工程变成了结构。
通过拓扑获得治理。在单智能体系统中，"智能体在发放超过 500 美元的退款前必须获得批准"是提示词里的一句话，而模型可以无视句子。在图中，它是一条不存在的边。你可以通过检查边集来证明，任何通往资金转移的路径都必须经过策略检查。治理不再是一种期望，而成为结构的一个属性——这正是审计人员关心的区别。
通过替换获得经济性。每个节点都是一个放置决策：模型还是代码？你每用一个确定性函数替换一次 LLM 调用，就省下了一次零成本、毫秒级、且不可能产生幻觉的调用。拓扑是智能体系统中最大的 FinOps 杠杆，第 9 节会量化这一点。
通过分离获得所有权。结构和行为终于各居其位。平台团队可以拥有组织图；领域团队可以拥有各自的智能体节点；风险团队可以拥有路由器策略。你可以改提示词而不动拓扑，也可以改拓扑而不动提示词。
还有一个诚实的成本面，跳过它就是渎职：图会成倍增加活动部件，而过早使用图会在不增加能力的情况下成倍增加失败模式和 token 消耗。第 8 节给出了何时单一精心工程化的循环仍是正确答案的标准——这种情况比当前炒作所暗示的更为常见。
5. 运行示例，版本 0：一个智能体，五个工具
从这里开始，一切都是具体的。技术栈是真实的，而且故意平淡无奇：Python 3.12，LangGraph 作为图基质 [6]，Claude 作为智能体节点背后的模型，Pydantic v2 用于类型化数据契约 [7]，SQLite 存放订单和合同以便仓库在任何地方都能克隆运行，以及基于 OpenTelemetry 的 Arize Phoenix 用于追踪 [8]。一个 API 密钥，大约 700 行代码，可以在笔记本电脑上运行。
版本 0 是大多数团队最先构建的系统，它是一个 ReAct 风格的单一智能体：
# v0_single_agent.py
from langchain_anthropic import ChatAnthropic
from langgraph.prebuilt import create_react_agent
from tools import (
search_disputes, # find the dispute record
fetch_contract, # pull contract terms and amendments
fetch_orders, # pull order and invoice history
calculate_credit, # a calculator tool the model MAY choose to call
send_resolution, # email the customer and post the credit memo
)
SYSTEM = """You are a dispute resolution specialist. Investigate the
customer's claim against their contract and order history. Recompute
the correct invoice amounts. If the customer is owed money, issue a
credit and send a resolution. Be accurate. Get human approval for
credits over $500."""
agent = create_react_agent(
model=ChatAnthropic(model="claude-sonnet-4-6"),
tools=[search_disputes, fetch_contract, fetch_orders,
calculate_credit, send_resolution],
prompt=SYSTEM,
)
result = agent.invoke({"messages": [("user", dispute_email)]})
在五十个合成纠纷上运行它，结果干净利落地分成两类。简单纠纷（一个行项目，无修订案）：大约 90% 正确，对话记录读起来像称职的工作。棘手纠纷（多个修订案、期中价格变更、部分发货）：正确率崩溃，失败恰好就是第 1 节中的那三种，如今可以观察到了。
智能体有时会在脑子里做算术，而不是调用计算器，因为工具使用是模型自己的选择，而模型很自信。它的上下文会饱和：到第三十次工具调用时，关键的合同条款已经在数千 token 之后了。而那句"超过 500 美元需人工批准"？在我们的运行中，智能体大多数时候都遵守了。"大多数时候"是在金融服务领域会毁掉职业生涯的说法。
此时的本能反应是写一个更长的提示词。图工程的思路则不同：不要指示一个智能体去扮演整个组织，而是直接构建这个组织。
6. 设计组织图：实践中的节点分类法
重构从一个对工作流中每项职责都要问的问题开始：**这个步骤需要判断，还是它有正确答案？**判断交给模型。正确答案交给代码。这个简单的启发式规则在可靠性和成本上的贡献超过任何提示词技巧，它产出了下面这个七节点组织图：
+--------------------+
email ----> | intake_classifier | (agent)
+---------+----------+
| DisputeCase
+---------v----------+
| evidence_retriever | (deterministic)
+---------+----------+
| EvidenceBundle
+---------v----------+
| recompute_engine | (deterministic)
+---------+----------+
| RecomputeResult
+---------v----------+
| resolution_drafter | (agent)
+---------+----------+
| ProposedResolution
+---------v----------+
| policy_router | (router)
+----+----------+----+
auto (<=$500, | | review (else)
high conf) | |
+--------v-+ +-v------------+
| executor |<-| human_review | approved
| (determ.)| | (checkpoint) |--+
+----------+ +--------------+ |
| rejected v
+-------> END
逐一走过这些节点，以及每个放置决策背后的推理。
intake_classifier（智能体）。阅读一封语无伦次的客户邮件并提取实际争议内容，需要对混乱的自然语言做出判断。用模型。但它的输出被强制为类型化结构 DisputeCase，因此下游所有环节收到的是事实而非散文。
evidence_retriever（确定性）。给定客户 ID 和日期范围，获取合同和订单是一次数据库查询。WHERE 子句里没有判断。在版本 0 中，这是由 LLM 决定何时、是否检索；这里则是四十行 Python，总是完整检索，零成本。
recompute_engine（确定性）。这是本次重构的演示核心。根据合同定价、修订案和发货记录重新计算发票，这是算术。算术有正确答案。让语言模型负责金钱上的算术是彻头彻尾的渎职——而版本 0 恰恰这么做了（每当模型跳过它的计算器工具时），这是它棘手案例失败的最大单一来源。这里它是带单元测试的纯 Python。它不可能幻觉出退款，因为它什么都不会幻觉。
resolution_drafter（智能体）。决定如何向不满的客户解释结果、选择语气、承认他们具体的挫败感：这是判断。用模型。注意这个智能体接收到什么：类型化的 EvidenceBundle 和类型化的 RecomputeResult，大约 1,200 token 的相关事实。它永远看不到原始合同，看不到检索过程，也从不做数学。它的数字从重算引擎的输出中复制而来，并有校验器检查它们是否一致。
policy_router（路由器）。提示词中 500 美元的门槛变成了一个 Python 条件。这是把策略写成代码：它无法被说服，不会心情不好，你的风险团队一眼就能评审。
human_review（检查点）。对于大额或低置信度的退款，图会停下来。是真的停下来：LangGraph 的 interrupt() 原语暂停执行，检查点器（checkpointer）将整个图状态持久化到磁盘，图在数小时后评审人员操作时恢复，必要时可以在不同的进程中恢复 [6]。人是拓扑中的一个节点，有明确的输入和输出，而不是附加在系统外部的包装器。
resolution_executor（确定性）。写退款单和发邮件是 I/O。用代码。
智能体节点还值得再评论一句，因为"图工程"并不能免除你工程化智能体本身的责任。每个智能体节点都带有一个角色定义（role definition），它读起来更像职位描述而不是提示词 [1]：它拥有的领域（纠纷受理）、它可以触碰的工具（在分类器的情况下没有；它唯一的工作是结构化提取）、它有权看到的上下文，以及它必须输出的 schema。在每个智能体节点内部，2024 至 2026 年的所有循环工程和上下文工程技巧仍然适用。图并没有取代这些学科。它容纳了它们。
7. 边：交接契约与序列化税
如果说节点是图系统干活的地方，那么边就是它们失败的地方。问问任何在生产中运行多智能体系统的人：残骸都在交接处 [1]。
朴素的交接——也是大多数框架演示中的默认做法——是传递对话记录：智能体 A 完成后，它的整个对话历史被前置到智能体 B 的上下文中。这失败两次。它用上游的碎屑重新饱和每个下游上下文，重现了图本要治愈的那种病。而且它真的花钱，因为每条穿过边的 token 都是你要付费重新序列化到下一次模型调用中的 token。我们称之为序列化税（serialization tax）。
图工程给出的替代方案是交接契约（handoff contract）：一个类型化的 schema，精确定义什么穿过每条边，其他一切都在边界上消亡。在 Python 中，就是 Pydantic 模型 [7]：
# contracts.py
from pydantic import BaseModel, Field
from decimal import Decimal
from typing import Literal
class DisputedItem(BaseModel):
line_item_id: str
claimed_reason: str
claimed_amount: Decimal
class DisputeCase(BaseModel):
"""Edge: intake_classifier -> evidence_retriever"""
customer_id: str
invoice_ids: list[str]
dispute_type: Literal["pricing", "quantity", "service"]
items: list[DisputedItem]
customer_sentiment: Literal["calm", "frustrated", "escalated"]
class RecomputeResult(BaseModel):
"""Edge: recompute_engine -> resolution_drafter"""
correct_total: Decimal
billed_total: Decimal
credit_due: Decimal
per_item_findings: list[dict] # itemized right/wrong per line
confidence: Literal["exact", "assumptions_made"]
assumptions: list[str] = Field(default_factory=list)
class ProposedResolution(BaseModel):
"""Edge: resolution_drafter -> policy_router"""
credit_amount: Decimal # validated == credit_due upstream
customer_message: str
internal_rationale: str
三个属性让契约远不止是整洁。它们是可强制执行的：如果分类器输出了垃圾，验证会在边上响亮地失败，而不是悄悄毒害三个下游节点。它们是可测试的：每个节点都可以用固定输入单独测试，因为它的接口是 schema，而不是"前一个智能体碰巧说了什么"。而且它们是廉价的：在我们的纠纷系统中，进入 resolution_drafter 的基于契约的交接大约携带 1,200 token，而在版本 0 的流程中同一点传递对话记录大约需要 9,000 token，仅这一条边就减少了 87%。第 9 节汇总了系统中的整体效果。
每条边的设计问题始终相同：下游节点需要知道什么才能完成工作，而不是上游节点碰巧知道什么？把这个问题回答好，就是把上下文工程提升为接口决策。
8. 布线与治理：拓扑即策略
这是完整的布线，它短到可以整体阅读——这本身就是论证的一部分：
# graph.py
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.sqlite import SqliteSaver
g = StateGraph(DisputeState)
g.add_node("intake", intake_classifier) # agent
g.add_node("evidence", evidence_retriever) # deterministic
g.add_node("recompute", recompute_engine) # deterministic
g.add_node("draft", resolution_drafter) # agent
g.add_node("human", human_review) # checkpoint (interrupt)
g.add_node("execute", resolution_executor) # deterministic
g.add_edge(START, "intake")
g.add_edge("intake", "evidence")
g.add_edge("evidence", "recompute")
g.add_edge("recompute", "draft")
g.add_conditional_edges("draft", policy_router,
{"auto": "execute", "review": "human"})
g.add_conditional_edges("human", apply_human_decision,
{"approved": "execute", "rejected": END})
g.add_edge("execute", END)
app = g.compile(checkpointer=SqliteSaver.from_conn_string("disputes.db"))
还有路由器，完整给出，因为它的简短正是重点所在：
# policy.py
AUTO_RESOLVE_LIMIT = Decimal("500.00")
def policy_router(state: DisputeState) -> str:
r = state["resolution"]
if (r.credit_amount <= AUTO_RESOLVE_LIMIT
and state["recompute"].confidence == "exact"):
return "auto"
return "review"
现在，我们审慎地陈述治理主张，因为它是本文最强的主张。 看看这个边集。从 draft 到 execute 没有边。起草智能体——靠近资金的唯一非确定性组件——在结构上无法触发资金转移。从 START 到 execute 的每条路径都必须经过 policy_router，而这个路由器只是十四行可评审的 Python。在版本 0 中，同等的保证是提示词里一句模型"大多数时候"遵守的话。在这里，它是图的一个属性，可以用一个遍历边的脚本检查，可以在一张图中向审计人员证明。
这就是"拓扑即治理"的含义，而且它可以泛化。允许转换的集合就是一个策略工件 [2]。审批阈值存在于路由器中。问责存在于带有持久化状态的人工检查点中，这顺带为你提供了人类评审所看到和所决定的完整、可回放的记录。职责分离——你的 SOX 审计员一直在问的那项控制——变成了字面意义上的图结构：提出方案的节点不可能是执行方案的节点。这一切都不需要信任模型。这一切都需要设计一张图。
9. 工作图、可观测性与拓扑的经济学
三个较短的话题补全了实践者的全景图，每一个都值得未来单独深入探讨。
动态工作图。到目前为止的一切都是静态拓扑：每个纠纷都走相同的七个节点。图工程的前沿是工作图生成器（work graph generator）：一个规划器节点，检查传入的任务并自行构建运行时图，决定生成哪些节点、按什么顺序、哪里可以安全并行 [1]。在纠纷系统中，自然的版本很小：一个规划器把一个十四行项目的纠纷扇出为并行的逐项目重算，然后合并结果。LangGraph 通过其 Send API 支持这种动态扇出 [6]。工程纪律在于约束生成器：最大扇出数、防环、每个任务的成本上限。一个无界的工作图生成器就是一台把 bug 变成发票的机器，所以要把这些边界视为设计的一部分，永远不要事后才想。还要注意诚实的默认选择：大多数系统，包括这个，用静态图就很好。当任务结构真正变化时才去用动态生成——这个时点比演示所暗示的要晚得多。
可观测性与评估。一张你看不见的图，就是一张你无法治理的图。用 OpenTelemetry 对系统进行插桩，在 Arize Phoenix [8] 中查看，把每次运行变成一条追踪，其中每个节点报告其延迟、token 用量和成本，每条边显示其负载。有两项实践很重要。首先，在两个层面评估：节点评估（分类器能否在标注集上正确提取纠纷？重算引擎能否通过其单元测试？）和图评估（整个拓扑能否在一个维护好的黄金纠纷集上产生正确的端到端结果，包括交接保真度——那些只出现在节点之间的错误？）。其次，对拓扑做回归测试：当你重新布线图时，黄金集能告诉你结构是否仍然有效，与任何提示词变更无关。诚实地指出开放的研究问题：评估动态生成的工作图——其结构本身每次运行都不同——还没有成熟的方法论。
**Token 经济学。**拓扑驱动支出，而纠纷系统量化了这一点。在我们五十个纠纷的测试集上测量：
+--------------------------------+-------------+-------------+
| Metric (avg per dispute) | V0 (loop) | V1 (graph) |
+--------------------------------+-------------+-------------+
| LLM calls | 23 | 4 |
| Total tokens (in + out) | ~61,000 | ~9,500 |
| Cost at Sonnet pricing | ~$0.31 | ~$0.05 |
| Hard-case correctness (n=20) | 55% | 95% |
| p50 latency | 94 s | 31 s |
+--------------------------------+-------------+-------------+
| V1 remaining errors: 1 misclassified intake, caught at |
| human_review. Zero incorrect credits reached execution. |
+--------------------------------+-------------+-------------+
这些数字背后的机制是通用的，它给了你图工程的三个 FinOps 杠杆：替换（每个确定性节点都是零美元的 LLM 调用；检索和重算从最昂贵的步骤变成了免费）、在边上压缩（类型化契约在每次交接上比对话记录好 80% 以上）、以及约束扇出（并行会线性放大支出，所以在生成器中设上限）。84% 的成本降低加上棘手案例上 40 个百分点的准确率提升，这种话听起来像厂商宣传——正因如此，发布这些数字的仓库会在 CI 中重新运行它们。
10. 运营模式、接下来会发生什么，以及现在该构建什么
谁拥有这张图？这个问题听起来像是组织问题，因为它就是。一旦拓扑成为受治理的工件，就必须有人像拥有生产 schema 一样拥有它：做版本管理、评审、通过拉取请求变更。企业中正在出现的模式是：平台团队拥有组织图和它的路由器，领域团队拥有各自的智能体节点（它们的角色定义、提示词和节点评估），风险团队拥有策略阈值，而图的定义是三方的契约。对于前向部署工程师——嵌入客户现场让 AI 系统真正运转起来的实践者——职位描述悄悄从"构建智能体"变成了"设计拓扑"，这是一项更资深、更持久的技能。
一个用于自我定位的简单成熟度模型：
+-------+---------------------------+-----------------------------------+
| Level | Shape | Governance |
+-------+---------------------------+-----------------------------------+
| 0 | Chat + RAG | None needed |
| 1 | One agent, tools, loop | Prompt-based (advisory) |
| 2 | Static org graph | Topology-based (structural) |
| 3 | + dynamic work graphs | + bounded generators |
| 4 | Governed agent org, many | Graph registry, org-wide policy, |
| | graphs, shared registry | cross-graph observability |
+-------+---------------------------+-----------------------------------+
2026 年中期的大多数企业处于第 1 级，并且正在痛苦中。这篇文章就是从第 1 级迈向第 2 级的动作。第 4 级是话语正在走向的地方。
接下来往哪里走？从当前的视角看，有四条轨迹似乎很可能。第一，基质的标准化：图的定义会想要一种可移植、声明式的格式，就像基础设施想要 Terraform 一样，而 MCP（模型上下文协议，连接智能体与工具的新兴标准）之类的协议已经暗示了互操作层。第二，图的图：一旦每个部门都有了组织图，部门之间的边就成了下一个工程面，"作为受治理智能体组织的企业"不再是一个比喻。第三，学习得到的拓扑：今天人类设计图、模型填充节点；关于智能体组织的研究已经在探索结构本身是否可以依据结果进行优化，让图工程师设定约束而不是画出每条边 [5]。第四，也是最不吸引人的，监管追上来了：拓扑即治理恰好产出 AI 风险框架开始要求的那些工件（允许转换集、检查点记录、可回放状态），而那些能把图交给审计人员的团队，会比那些只能交出提示词的团队走得更快。
这个名字会留下来吗？不确定，诚实的消息来源也这么说 [2]。"图工程"可能会输给别的标签，或者碎回编排的词汇表里。买入问题，租用术语。
不管怎样，这个季度该构建什么。挑一个重要的工作流，一个错误输出会损失金钱或信任的工作流。把它构建成一张静态图：把判断与计算分开，在边上放类型化契约，把策略放进路由器，把人工放在检查点，并对每个节点做插桩。对照你当前的单智能体版本测量成本和正确率。在我们的运行示例中，这项练习大约花了 700 行代码，产出了一个更便宜、更快、在棘手案例上准确率显著更高，而且首次可证明的系统。
循环让你的智能体有能力。图让你的系统值得信任。
这就是行业现在正在做的交易，不管我们最终怎么称呼它。
原文链接：Graph Engineering for AI Agents: The Practitioner’s Guide to Designing Multi-Agent Systems as…
汇智网翻译整理，转载请标明出处
