[技术札记] 图工程：从单智能体循环到可恢复的 Agent 执行系统

[leecyang]

主题

架构设计

摘要

为什么选择 LingxiGraph ？从 Agents → Loops → Graphs

正文

许多 Agent 系统在原型阶段表现良好，却会在任务复杂度、并发规模和运行时间上升后迅速暴露问题。

一个常见原因并不在于模型能力，也不完全在于 Prompt，而在于任务本身的执行结构。

大量 Agent 系统实际上仍然遵循一种隐式的线性流程：

研究 → 分析 → 生成 → 审查 → 修改 → 输出

后一个步骤默认等待前一个步骤完成，所有信息不断进入同一个上下文，失败则往往意味着从某个大循环重新开始。

当系统规模扩大后，这种结构通常会带来几个直接问题：

• 不必要的串行等待；
• 上下文持续膨胀；
• Token 与模型调用成本增加；
• 单点故障影响整个工作流；
• 难以准确恢复中断任务；
• 很难解释系统为何选择了某条执行路径。

这也是为什么生产级 Agent 系统最终需要从 Loop Engineering（循环工程） 进一步走向 Graph Engineering（图工程）。

---

一、图工程的核心不是“画流程图”

图工程不是把原来的 Prompt Chain 换成一张节点图。

真正的变化是：

将智能体任务显式建模为一组具有明确职责、依赖、状态和控制边界的执行单元。

一个最基本的 Agent Graph 可以抽象为五类核心元素。

1. Node：节点

一个边界明确的工作单元。

节点可以是：

• Agent；
• LLM 调用；
• Tool Call；
• 普通函数；
• 检查器；
• Grader；
• 数据处理任务；
• 人工审批节点。

一个节点最好只承担一个主要职责。

2. Edge：边

边不应该仅仅表达：

“B 在 A 之后运行。”

更准确的定义是：

A 产生了 B 执行所必需的数据、状态或权限，因此 B 对 A 存在真实依赖。

这是图工程非常重要的设计原则。

执行顺序不等于依赖关系。

3. State：状态

状态记录整个任务执行过程中需要跨节点持续存在的信息，例如：

task_id
current_step
completed_nodes
artifacts
decisions
evidence
retry_count
budgets
approvals

没有可靠状态管理的 Graph，很容易退化为另一种形式的 Prompt Chain。

4. Router：路由器

Router 根据当前状态决定下一条合法路径。

模型可以参与判断，但模型的判断结果与系统允许执行的路径应当分离。

例如：

风险分类
   │
   ├── Low   → Quick Review
   ├── High  → Full Audit
   └── Other → Human Review

分类可以是概率性的，但系统允许进入哪些路径应该是明确且可检查的。

5. Gate：门控

Gate 决定某项工作是否有资格继续向下游传播。

典型 Gate 包括：

• Schema Validation；
• Test；
• Citation Check；
• Safety Check；
• Grader；
• Human Approval。

很多生产系统中，价值最高的节点甚至不是“产生新内容”的节点，而是阻止错误结果继续传播的节点。

---

二、不要把所有“然后”都建模成依赖

线性 Agent 工作流经常来自自然语言本身。

人很容易写：

先做 A
然后做 B
然后做 C

但图工程首先应该问：

B 是否真的需要读取 A 的输出？

如果答案是否定的，那么 A → B 这条边通常就不应该存在。

例如一个技术调研任务：

                ┌→ 市场信息 ─────┐
用户请求 ───────┼→ 代码仓库 ─────┼→ 综合分析
                └→ 竞品信息 ─────┘

三个研究任务如果互不依赖，就应该并行执行，而不是人为排列成：

市场信息
  ↓
代码仓库
  ↓
竞品信息
  ↓
综合分析

这条原则看起来简单，却往往是 Agent 系统降低端到端延迟最有效的方式之一。

---

三、节点必须拥有清晰的执行契约

如果一个节点无法被精确定义，它通常也很难：

• 测试；
• 路由；
• 重试；
• 替换；
• 监控；
• 独立演进。

一个可靠节点至少应该明确四件事：

{
  "node": "source_researcher",
  "input": {
    "topic": "string",
    "source_type": "primary"
  },
  "output": {
    "claim": "string",
    "source": "string",
    "confidence": "high | medium | low"
  },
  "failure": "no_primary_source_found"
}

也就是说，一个节点至少应明确：

1. 职责是什么
2. 输入是什么
3. 输出是什么
4. 失败意味着什么

尤其值得注意的是：节点之间应尽可能传递结构化结果，而不是任意自然语言。

自由文本会迫使下一个 Agent 再次解释：

“上一个 Agent 到底做了什么？”

结构化数据则让 Graph 能直接判断：

“当前状态是什么，以及允许执行什么。”

节点契约稳定之后，底层模型、Prompt 甚至工具都可以被替换，而不必重新设计整个工作流。

---

四、不要让 Agent 承担普通程序应该完成的工作

Agent Graph 中一个常见的反模式是：

每一个节点都是 Agent，每一条数据处理步骤也调用模型。

实际上，大量工作根本不需要推理。

例如：

• Array Flatten；
• 去重；
• 排序；
• Null Filtering；
• Schema Validation；
• 状态判断；
• ID 映射；
• 数据合并；
• 权限检查。

这些任务应该优先使用确定性代码完成。

例如：

const usable = results
  .filter(Boolean)
  .flatMap((result) => result.items);

const unique = [
  ...new Map(
    usable.map((item) => [item.source_url, item])
  ).values(),
];

一个非常实用的工程原则是：

代码负责确定性的 Plumbing，模型负责需要判断力的工作。

如果一个 Graph 的每一次数据搬运都需要调用另一个 Agent，那么系统实际上是在为自己的“连线”支付 Token 成本。

---

五、绝大多数 Agent Graph 都可以拆成几种基本拓扑

复杂系统看起来可能拥有几十甚至几百个节点，但其拓扑往往是几个基本结构的组合。

1. Chain

A → B → C

适用于后一个步骤确实依赖前一个步骤完整结果的情况。

优点：

• 简单；
• 可预测；
• 容易调试。

缺点：

• 无法利用独立任务并行性。

2. Fan-out / Fan-in

       ┌→ B1 ─┐
A ─────┼→ B2 ─┼→ C
       └→ B3 ─┘

一个任务拆成多个独立分支，并行执行后统一汇总。

非常适合：

• Deep Research；
• Code Review；
• 多来源事实核验；
• 市场分析；
• 多方案评估。

这是生产级 Agent 系统中非常重要的一种结构。

3. Router

               ┌→ Quick Path
Classifier ────┤
               └→ Full Audit

根据任务状态、风险、规模或用户意图选择不同执行路径。

它允许：

• 简单任务走短路径；
• 高风险任务执行完整检查；
• 不确定任务进入人工审查。

因此，系统不再需要对所有请求支付同样昂贵的计算成本。

4. Controlled Cycle

WORK
  ↓
VERIFY ── PASS → EXIT
  │
 FAIL
  ↓
FEEDBACK
  │
  └────────→ WORK

循环本身并不是问题。

真正危险的是：

repeat until good

这种没有明确停止条件的 Agent Loop。

任何生产级循环都应该拥有：

• Completion Test；
• 最大迭代次数；
• Token / Cost Budget；
• 历史尝试记录；
• Convergence Rule；
• 无法收敛时的升级机制。

---

六、并行并不天然意味着更快

如果五个节点互相独立，那么让它们并行通常是合理的。

但 Graph 中真正决定性能的不是“有没有并发”，而是：

系统在哪里等待。

例如：

A ─┬→ B1 ─┐
   ├→ B2 ─┼→ JOIN → C
   └→ B3 ─┘

只有在 C 确实需要 B1、B2、B3 的完整结果时，这个 Join 才是必要的。

典型场景包括：

• 全局去重；
• 候选项排序；
• 多方案比较；
• 判断信息覆盖是否充分。

如果每个结果可以独立进入后续流程，就没有必要人为加入 Barrier。

因此：

并行度只是一个参数，真正决定吞吐量的是 Graph Topology。

---

七、验证应该成为独立的系统边界

不要让同一个 Agent 在同一上下文中同时负责：

生成 → 自我审核 → 自我批准 → 发布

更可靠的结构是：

GENERATOR
    ↓
VERIFIER
   ├── PASS → NEXT
   └── FAIL → REPAIR

Verifier 可以独立验证：

• 每个重要结论是否存在证据；
• 引用是否真正支持对应结论；
• 输出是否满足 Schema；
• 代码是否通过测试；
• 是否符合安全要求；
• 是否存在第二条独立路径得到相同结论。

这里的关键不是简单地“多调用一个模型”，而是形成：

职责隔离与失败边界。

生成者负责生成。

检查者负责判断是否允许继续。

---

八、状态管理决定 Graph 是否真正进入生产阶段

很多 Agent 架构图只强调节点和边，却忽略最重要的部分之一：

State。

真正运行数小时甚至数天的 Agent 系统必须能够回答：

已经完成了什么？
为什么系统进入当前路径？
如果此刻进程中断，应当从哪里恢复？

因此，重要节点执行完成后应该产生持久化 Checkpoint。

同时，不建议在所有节点之间不断传递越来越长的完整 Transcript。

更合理的方式是：

Agent A
  ↓
Artifact Store
  ↓
artifact_id
  ↓
Agent B

节点之间尽可能传递：

• Artifact ID；
• URI；
• Structured Metadata；
• 必要摘要；
• State Reference。

而不是反复转述上一阶段生成的全部内容。

这样既减少上下文损耗，也使整个执行过程更容易：

• 审计；
• 恢复；
• 回放；
• 调试。

---

九、失败应该是局部事件，而不是系统级事故

在线性 Chain 中，一个步骤失败经常意味着整个流程停止。

Graph Engineering 的目标之一，是把失败限制在尽可能小的范围内。

不同节点可以具有不同失败策略：

策略	适用场景
Retry	网络、服务等瞬时错误
Fallback	首选模型或工具不可用
Skip	非关键分支失败
Repair	输出没有通过验证
Escalate	风险或不确定性超过阈值
Stop	安全、预算或权限边界触发

同时应尽可能保证写操作具有：

Idempotency（幂等性）

否则一次简单的 Retry 就可能：

• 重复创建资源；
• 重复发送消息；
• 重复扣费；
• 重复写入数据库。

可靠性并不意味着“保证每一个节点永不失败”。

可靠性意味着：

系统已经明确知道每一种失败发生后应该做什么。

参考资料

本文参考自：

• 原作者： rari（@0xwhrrari）
• 原文： Graph Engineering: How to Build AI Agent Systems That Don't Break at Scale