核心缺点是：Prompt 和 Skill 主要告诉模型“应该怎么做”，但不天然保证模型“每次都按规定做完”。
可以从 5 个方面理解：
| 问题 | 只靠 Prompt / Skill 的风险 | 程序化编排的优势 |
|---|---|---|
| 流程控制 | 模型可能跳过步骤、改变顺序 | 强制按指定流程执行 |
| 条件分支 | 模型可能误判该走哪条路径 | 用代码判断条件 |
| 多 Agent 协作 | 可能重复发言、漏掉相关专家 | 统一调度、共享状态 |
| 循环与终止 | 可能反复尝试或过早结束 | 设置循环次数、退出条件 |
| 失败恢复 | 会话中断后可能丢失进度或重复操作 | 持久化状态、从检查点恢复 |
举个你关心的 UE 代码修改例子：
只靠 Skill：
修改代码后必须编译，编译失败就修复，直到通过。
模型可能忘记编译，可能连续修改却没有真正读取错误，也可能在编译失败时就宣布完成。
用 LangGraph 或类似程序编排：
修改代码
↓
执行编译
↓
程序读取真实退出码
├─ 成功 → 结束
└─ 失败 → 收集错误 → 交给模型修复
↓
再编译
这里不是让模型记住规则，而是由程序控制流程；模型负责分析和修复，程序负责判断编译是否真的通过。
不过，也不能把 LangGraph 理解成万能保证：它能保证流程约束被执行，却不能保证模型给出的分析一定正确。 比如它可以强制运行测试，但测试覆盖不足时，错误代码依然可能通过。
因此，最实用的分工是：
- Prompt / Skill： 规定模型如何思考、如何分析、如何完成专业任务。
- LangGraph / 程序编排： 规定系统何时执行、执行几次、如何分支、失败后如何恢复。
- 验证器： 判断结果是否真的满足要求。
一句话记忆：Prompt 和 Skill 管“怎么做”，编排程序管“必须怎么走”，验证器管“到底做对没有”。