AI Agent 工作流编排：从单轮到多智能体协作

单轮 Prompt 能解决的问题有限，真正复杂的业务——审批流、多步骤调研、跨系统操作——需要把 LLM 嵌入有状态的工作流中。2026 年，LangGraph、Temporal + LLM 等方案让 Agent 编排从实验走向生产，本文梳理关键设计模式。

为什么需要图（Graph）而非链（Chain）

简单的 Chain 是线性流水线：A → B → C。但真实任务充满分支和回环：

• 检索结果不充分 → 重写查询 → 再次检索
• 工具调用失败 → 降级策略 → 人工介入
• 多 Agent 并行调研 → 汇总 → 生成报告

LangGraph 将 Agent 建模为有向图：节点是处理步骤，边是流转条件。每个节点读写共享状态（State），天然支持循环和条件分支。

from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    messages: list
    retrieved_docs: list
    needs_human: bool

graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve_node)
graph.add_node("generate", generate_node)
graph.add_node("human_review", human_review_node)

graph.add_edge("retrieve", "generate")
graph.add_conditional_edges("generate", should_escalate, {
    "human": "human_review",
    "done": END
})

人机协同（Human-in-the-Loop）

生产环境中，完全自主的 Agent 风险太高。推荐在以下节点插入人工审批：

1. 写操作前：发邮件、改数据库、转账等不可逆操作
2. 低置信度时：模型自评 confidence < 阈值
3. 合规敏感：法律、医疗、财务建议类输出

LangGraph 的 interrupt_before 可以在指定节点暂停执行，将当前状态持久化，等待人工确认后从断点恢复——而非从头重跑。

多 Agent 协作模式

三种常见拓扑：

• 主管-工人（Supervisor）：一个路由 Agent 分派任务给专业子 Agent（检索、代码、写作），适合异构任务
• 流水线（Pipeline）：每个 Agent 处理一个阶段，输出作为下游输入，适合标准化流程
• 辩论（Debate）：多个 Agent 提出方案互相质疑，最后由裁判 Agent 综合，适合决策类任务

多 Agent 不是越多越好——每多一个 Agent 就多一份 token 消耗和出错概率。先用单 Agent + 多工具验证，再按需拆分。

状态持久化与容错

长任务可能运行数分钟甚至数小时，必须考虑中断恢复：

1. 每个节点执行后 checkpoint 状态到 PostgreSQL / Redis
2. 节点设计为幂等——重试不会产生副作用
3. 设置全局超时和单节点超时，超时后进入降级路径
4. 记录每步的 input/output/token 用量，便于审计和计费

可观测性：Agent 的黑盒问题

传统服务有明确的请求-响应，Agent 则是一连串内部决策。建议接入：

• LangSmith / Langfuse：可视化 Agent 的每一步推理和工具调用
• OpenTelemetry：将 Agent span 接入现有链路追踪
• 成本仪表盘：按用户/任务统计 token 消耗，设置预算告警

小结

Agent 工作流编排的核心是用图表达业务逻辑、用状态连接各步骤、用人工节点控制风险。从最简单的两节点图开始，逐步增加分支和子 Agent，比一开始就设计复杂多 Agent 系统更务实。