1.4 典型应用场景与价值主张

1.4 典型应用场景与价值主张

哪些事值得上图

本节在全册位置：告诉你什么时候该掏出 LangGraph。它不是所有大模型任务的答案——单次问答用链更轻。但当任务有循环、长上下文、人工节点或多角色协作时，图的价值立刻显现。我们的经验法则：先数任务里「要不要再走一步」的判定点，超过两个就上图，否则用链。

场景：从反思到多人协作

典型场景有四类。其一，带反思的生成：写-评-改循环。其二，工具密集型智能体：每步决定调不调工具。其三，长程任务：客服、数据处理，需跨多轮保持状态。其四，多智能体：不同专家各管一段，由主管路由。价值主张可归结为一句话——把「流程的正确性」从 prompt 里挪到代码与图里，让模型只负责它擅长的生成与判断。类比金融：链像一次性交易，图像带审批流与对账的结算系统。前者快但不可审，后者慢一点但每一步留痕。

# 场景检测器：根据任务特征建议是否用图
from langgraph.graph import StateGraph, START, END
from typing import TypedDict

class S(TypedDict):
    needs_loop: bool
    use_graph: str

def decide(s: S):
    # 有循环/分支/人工 = 用图；否则用链
    return {"use_graph": "LangGraph" if s["needs_loop"] else "Chain"}

b = StateGraph(S)
b.add_node("decide", decide)
b.add_edge(START, "decide")
b.add_edge("decide", END)
g = b.compile()
print(g.invoke({"needs_loop": True, "use_graph": ""}))
​

# 真实场景往往多个特征叠加
cases = [
    "客服工单：多轮+人工介入 -> 图",
    "文本摘要：单次 -> 链",
    "研报生成：检索循环+长上下文 -> 图",
]
for c in cases:
    print(c)
# 特征叠加时图的边际收益更高，单一特征也可视情况用链
​

案例：客服工单分流

背景：工单需机器人先处理，复杂时转人工，人工改完再回机器人，生命周期可能跨数小时。

操作：用条件边在「机器人节点」与「人工节点」间切换，状态保留工单上下文。

结果：切换不丢上下文，且每步可审计、可回放。

解读：图的「状态常驻」特性正好匹配工单的长生命周期，这是链很难低成本做到的。

变式：把人工节点换成另一个专家智能体，就演化为多智能体协作（见第五章），迁移成本极低。

工程清单

• 有循环、长上下文、人工节点、多角色协作这四类特征命中越多，越该用图，单一特征也可用链。

• 图的收益是把流程正确性从 prompt 挪到代码与图结构，让模型只负责它擅长的生成与判断。

• 先做特征判断再选型，不要因为图时髦就套所有任务，轻任务上图反而增加理解成本。

常见误区

拿图去套所有大模型任务，反而让简单链路变得难读；我们建议先数任务里「要不要再走一步」的判定点，超过两个才认真上图。

决策清单与边界

选型不该靠直觉，而靠一张可打分的特征表。下面把常见任务特征量化，分数越过阈值才上图。

# 特征打分器：命中一项加一分，>=2 用图
FEATURES = ["循环/反思", "条件分支", "人工介入", "长上下文", "多角色"]
def score(task: dict) -> int:
    return sum(1 for f in FEATURES if task.get(f))
print(score({"循环/反思": True, "人工介入": True}))  # 2 -> 用图
# 分数来自真实任务拆解，不是拍脑袋
​

⚠️ 常见坑：只看「模型能不能做」就决定上图，忽略控制流复杂度；真正该数的是判定点数量，两个以内用链更轻。

💡 关键直觉：图的收益与「判定点数量」成正比，单一特征也能用链，叠加越多图的边际收益越高。

补充一点：打分器的阈值不是铁律。我们线上把「循环/反思」权重调成 2，因为一旦任务需要写-评-改循环，图的收益会指数级放大；而「长上下文」单独出现时，有时用带记忆的链也能应付，不必强行上图。阈值要随团队经验微调，别照搬。建议每个新项目跑完第一次后，回看打分与真实选型是否吻合，偏差大的特征就调权重。

四类场景的最小骨架

前面介绍了场景分类，这里给出每类场景在图上对应的最小结构，让你判断「我的任务该长什么样」。

# 场景一：写-评-改反思循环，两个节点加一条回边
b.add_node("draft", draft); b.add_node("critic", critic)
b.add_edge(START, "draft")
b.add_conditional_edges("critic", ok_or_again, {"again": "draft", "done": END})

# 场景二：工具型智能体，条件边判断是否调工具
b.add_node("agent", call_model); b.add_node("tools", ToolNode(tools))
b.add_conditional_edges("agent", tools_condition)  # 自动决定

# 场景三：长程任务，关键是多轮不丢状态，靠检查点
g = b.compile(checkpointer=MemorySaver())
# 每次带 thread_id 调用，状态跨调用累积

# 场景四：多智能体，主管节点派活，专家做完回主管
b.add_edge("expert_a", "supervisor")   # 专家的出口指向主管
​

四类场景的骨架差异只在「边」的形态：反思是自环、工具型是条件回边、长程任务是检查点、多智能体是中心辐射。判断一个需求属于哪类，本质是看它的边该长什么样。

从验证到上线的演进节奏

选型用图之后，不必一步到位做成完整系统，按下面三个台阶走能显著降低风险：

台阶之间不要跳。绝大多数「图写错了」的事故，发生在跳过第一台阶直接上真实模型——结构错误被模型输出的随机性掩盖，排障时很难分清是结构问题还是模型问题。把图结构先跑稳，再替换组件，是这套框架下最省时的工程顺序。