引子：PRD失效的三个真实现场 上周五的某电商中台需求评审会上，一位资深后端工程师第三次打断产品经理：“这个‘智能退款建议按钮’点击后，到底触发哪5个系统？库存扣减在风控校验前还是后？支付网关回调失败时，重试逻辑写在哪一版PRD里？”会议室陷入沉默——那份87页的PRD文档，通篇用“用户可获得更优退款方案”“系统自动决策”等模糊表述，却未定义任何一个状态跃迁条件。
测试同学的反馈更直白：“第3.2.4节说‘支持异常场景处理’，但没写具体有哪些异常、各走哪条路径、预期返回码是多少。我按什么写用例？按你口头说的，还是按上次上线崩掉的版本？”
最棘手的是AI Agent项目。当客服Agent上线首周，用户一句“我刚在APP投诉完，现在想加急处理，但又不想重复描述”，系统竟启动了全新对话分支——而原PRD里连“跨会话状态继承”四个字都没出现。传统PRD的线性功能罗列范式，在面对多智能体协同、状态驱动、实时反馈闭环的AI原生产品时，已不是“不够好”，而是结构性失能。
我们亟需一种新抽象：它不描述“系统应该做什么”，而是定义“系统如何协作着把事情做成”。这个新载体，就是编排图（Orchestration Graph）——一张可执行、可追踪、可验证的状态流转拓扑图。
为什么是“编排图”？从Prompt工程视角解构需求本质 PRD本质是面向人类读者的指令集：模块化、静态、依赖上下文理解。而编排图是面向LLM+Agent系统的领域特定语言（DSL）：角色化、状态化、路由驱动。
维度 传统PRD 智能体编排图 核心单元 功能模块（如“投诉提交页”） 角色节点（CustomerServiceAgent） 行为定义 输入→处理→输出（文字描述） 能力接口（.invoke()方法 + tool schema） 流程逻辑 “若A则B，否则C”（自然语言条件句） 带guard函数的有向边（lambda s: "vip" in s.tags） 状态管理 隐含在字段说明中（如“status字段取值为pending/processing”） 显式State Schema（Pydantic模型定义全生命周期字段） 以“用户投诉处理流程”为例：
PRD写法（4行文字）：
用户提交投诉，系统校验基础信息； 若为VIP客户，优先分配高级坐席； 若含“欺诈”关键词，同步触发合规审查； 审查通过后进入赔付流程。 编排图表达（3节点+2条件边）：
graph LR A[CustomerServiceAgent] -->|guard: “vip” in state.tags| B[SeniorAgent] A -->|guard: “fraud” in state.keywords| C[ComplianceChecker] 关键洞察：PRD是“告诉人怎么做”，编排图是“告诉机器何时调谁、传什么、判什么”。 每个节点的system prompt必须显式约束其职责边界（如Router节点的prompt强制声明：“仅当state.urgency==‘critical’且无可用坐席时，才调用EscalateToManager工具”），这正是Prompt工程对需求颗粒度的倒逼。
实战：用LangGraph构建可执行的编排图（含完整代码） 以下为可直接运行的最小可行示例（Python 3.10+, langgraph==0.1.44）：
from typing import TypedDict, Annotated, List, Optional from langgraph.graph import StateGraph, START, END from langgraph.checkpoint.memory import MemorySaver from pydantic import BaseModel # 1. 定义状态Schema（显式契约） class ComplaintState(TypedDict): text: str tags: List[str] # e.g., ["vip", "urgent"] keywords: List[str] assigned_to: Optional[str] escalation_needed: bool # 2. 定义智能体（每个即一个可调用节点） class CustomerServiceAgent: def __call__(self, state: ComplaintState) -> ComplaintState: # 简化版：提取关键词和标签（真实场景调用LLM） state["keywords"] = ["fraud"] if "欺诈" in state["text"] else [] state["tags"] = ["vip"] if "VIP" in state["text"] else [] return state class ComplianceChecker: def __call__(self, state: ComplaintState) -> ComplaintState: # 合规检查逻辑（此处模拟通过） print("✅ 合规检查通过") return state class EscalationRouter: def __call__(self, state: ComplaintState) -> ComplaintState: # Router节点不修改状态，只做路由决策（实际中可调用LLM判断） if "urgent" in state["tags"] and "vip" in state["tags"]: state["escalation_needed"] = True return state # 3. 构建编排图 builder = StateGraph(ComplaintState) builder.add_node("service", CustomerServiceAgent()) builder.add_node("compliance", ComplianceChecker()) builder.add_node("router", EscalationRouter()) # 4. 添加带条件的边（核心！业务规则即代码） builder.add_edge(START, "service") builder.add_conditional_edges( "service", lambda s: "fraud" in s["keywords"], {True: "compliance", False: "router"} ) builder.add_conditional_edges( "router", lambda s: s.get("escalation_needed", False), {True: END, False: "service"} # 非紧急则循环服务 ) # 5. 编译并运行 graph = builder.compile(checkpointer=MemorySaver()) result = graph.invoke({ "text": "VIP用户投诉支付欺诈，要求15分钟内处理！", "tags": [], "keywords": [], "assigned_to": None, "escalation_needed": False }, config={"configurable": {"thread_id": "1"}}) print("最终状态:", result) # 输出: {'text': '...', 'tags': ['vip'], 'keywords': ['fraud'], ...} ✅ Prompt设计意图注释：EscalationRouter节点的system prompt应包含明确约束：
“你是一个路由决策器。仅当state.tags包含’urgent’且’vip’时，设置escalation_needed=True；其他情况一律返回原state。禁止生成解释性文本。”
这确保LLM不会“自由发挥”，而是严格服从图结构。
...