四种方案的本质差异选择工作流框架要匹配执行模型、工程成本、团队能力，不是找最好的那个。方案 工作流定义 状态持久化 执行引擎 ───────────────────────────────────────────────────────────────── Prompt-based Markdown + YAML 手写 JSON 文件 LLM（A 层） LangGraph Python 代码（图结构） 内置 State Schema Python 代码（确定性） Temporal Python/TypeScript 内置（数据库） 代码（确定性） n8n 可视化 + JSON 内置 代码（确定性）前三种支持语义判断（confidence = 0.95），n8n 基本只支持布尔表达式。LangGraph 和 Temporal 的执行引擎是确定性代码，Prompt-based 的执行引擎是 LLM 本身。Prompt-based（你的方案）工作流定义：Markdown + YAML 文件# workflow.md ## Phase 3：根因分析 执行子 Agent：rnd-automotive-issue-analyzer Context：{ { phases.phase2.log_dir }} 路由： - confidence = 0.95 → Phase 4 - 0.6 = confidence 0.95 → Gate A - confidence 0.6 且重试次数 3 → 重试 Phase 3 - confidence 0.6 且重试次数 = 3 → 人工升级优势：工作流定义可以被非工程师读懂和修改改 Markdown 比改代码快，适合频繁迭代LLM 执行路由逻辑，无需硬编码所有边界条件启动成本低，适合 POC 和快速验证劣势：路由逻辑由 LLM 执行，有不确定性（同一个输入可能有不同路由结果）缺少代码级的类型系统和测试工具支持可观测性需要手动接 Langfuse，不是开箱即用规模增大后，Markdown 文件维护难度上升适合：工作流经常变，改 Markdown 比改代码快的场景团队没有专职工程师，或非技术人员需要能读懂工作流定义快速验证 POC，3 天内跑通一个 MVPLangGraph工作流定义：Python 代码（图结构）fromlanggraph.graphimportStateGraph,ENDfromtypingimportTypedDictclassWorkflowState(TypedDict):jira_key:strbug_info:dict# Phase 1 输出analysis:dict# Phase 3 输出fix_result:dict# Phase 4 输出defanalyze_node(state:WorkflowState)-dict:result=call_skill("rnd-automotive-issue-analyzer",state["bug_info"])return{"analysis":result}defroute_after_analyze(state:WorkflowState)