有个细节很刺眼：当 prompt 里开始反复写 MANDATORY、DO NOT SKIP，系统其实已经在报警了。
你不是在编程。你是在劝一个不稳定的执行者别走神。
这篇开发者博客讲的就是这个问题。它的核心命题很短：reliable agents need deterministic control flow encoded in software, not elaborate prompt chains。可靠的复杂 Agent，需要写在软件里的确定性控制流，而不是越来越复杂的提示词链。
我认可这个判断。Agent 工程的分水岭，正在从“谁更会写 prompt”，转向“谁能把 LLM 降级成可编排、可验证、可兜底的组件”。
Prompt 能做任务，不能当骨架
原文反对的不是 prompt。
窄任务里，prompt 很有用。改写、分类、提取、生成候选方案，提示词仍然是低成本入口。问题出在复杂 Agent：多步执行、工具调用、状态更新、异常处理，都被塞进一段自然语言里。
原文用了一个很准的比喻：如果一种编程语言的语句只是“建议”，函数还可能幻觉式返回 Success，复杂系统就无法推理，也无法扩展。
这不是修辞。它正好点中 Agent 的工程硬伤。
| 环节 | Prompt 适合承担 | 软件运行时该承担 |
|---|---|---|
| 单步判断 | 分类、总结、生成候选 | 输入输出格式约束 |
| 多步流程 | 提供局部推理 | 状态转移、分支、重试 |
| 工具调用 | 生成调用意图 | 权限、参数校验、执行顺序 |
| 可靠性 | 给出解释或建议 | 验证检查点、日志、回滚、人审 |
关键点不是让 LLM 本身变成完全确定的机器。那不现实，也不是原文的意思。
确定性应该放在外层。状态怎么变，工具能不能调，结果是否合格，失败后走哪条路，这些都要由软件接管。LLM 可以负责判断和生成，但不该负责整套系统的秩序。
对开发者来说，这意味着 prompt 模板要退到第二层。真正要写清楚的是状态图、输入输出契约、校验器、失败分支。
对技术管理者来说，采购或自研 Agent 平台时，也别只看 demo 是否顺滑。更该问四个问题：状态是否可追踪，工具调用是否可控，失败是否可见，输出是否可验。
真正危险的是静默失败
复杂 Agent 最怕的不是报错。
报错反而干净。系统停下来，团队知道哪里坏了。
更麻烦的是静默失败：它没有崩溃，没有红灯，还给出一段看起来很完整的结果。错就这样进入下一步，被包装、被引用、被执行。
拿客服 Agent 举例，不需要虚构事故也能看清风险。用户问退款，Agent 先查订单，再判断规则，再生成回复，再触发工单。只要其中一步把状态理解错，后面每一步都可能继续“顺畅”运行。
如果没有程序化校验，团队通常只剩三种兜底。
| 兜底方式 | 实际做法 | 现实代价 |
|---|---|---|
| Babysitter | 人盯着 Agent 跑 | 自动化收益被吃掉 |
| Auditor | 事后全量审计 | 成本后置，反馈太慢 |
| Prayer | 差不多就收 | 把可靠性交给运气 |
这三种都不适合生产系统。第一种省不了人，第二种拖慢交付，第三种迟早出账单。
“工欲善其事，必先利其器。”放在 Agent 工程里，这句话不是劝大家买更多工具，而是提醒团队别把工程问题伪装成玄学调参。
更可执行的做法，其实没有那么玄。
| 工程动作 | 要解决的问题 | 典型做法 |
|---|---|---|
| 显式状态管理 | Agent 当前走到哪一步 | 用状态机或工作流记录阶段、输入、输出 |
| 工具权限控制 | 防止乱调工具 | 按任务开放工具，限制参数和调用顺序 |
| 输出校验 | 防止错结果进入下一步 | schema 校验、规则校验、必要字段检查 |
| 失败重试 | 防止一次偏差放大 | 区分可重试、需降级、需中止的错误 |
| 日志追踪 | 事后能定位原因 | 记录 prompt、模型输出、工具返回、状态变化 |
| 人审节点 | 把高风险环节拦住 | 金额、权限、外发、删除类动作强制人审 |
这些东西不性感。也不适合做发布会截图。
但它们决定 Agent 能不能从演示走到生产。没有这些，模型越能干，错误扩散得越快。
门槛正在回到软件工程
我更在意的是，这篇博客说中了一个行业变化：Agent 的门槛不再只是 prompt 技巧，而是系统能力。
早期大家迷恋提示词，可以理解。它见效快，演示好看，进入门槛低。铁路刚出现时，最吸引人的也是速度。但铁路真正改变世界，靠的不只是火车头，而是时刻表、信号系统、调度规则和维修体系。
这个类比不完全一样。Agent 的不确定性更强，任务边界也更松。但重复的是同一种结构：单点能力很耀眼，真正的规模化靠外层制度。
开发者接下来要做的事会更具体。
少花一点时间堆“你必须、你绝对不能、请严格遵守”。多花一点时间写状态迁移、验证器和错误处理。能用代码约束的，就别交给自然语言祈求。
技术管理者也要改判断标准。
如果一个 Agent 项目只能展示成功路径，不能展示失败路径，它还没准备好进入核心流程。采购可以延后，试点可以缩小，先把可观测性和人审边界补上。
这不是保守。恰恰是对生产系统最基本的尊重。
目前还看不清的是，行业会不会形成一套稳定的 Agent 运行时标准。原文只是一篇开发者博客，不是正式标准，也没有给出万能框架。
但有几个变量已经可以观察：
- Agent 平台是否把状态、工具调用、日志和校验做成一等能力；
- 团队是否愿意为失败路径投入工程时间；
- 高风险动作是否默认有人审或强校验；
- prompt 是否从“流程控制中心”退回“模型交互接口”。
这几个问题，比提示词写得漂不漂亮更重要。
把逻辑从散文里拿出来，放回软件里。LLM 是组件，不是整套系统。
这句话听起来克制，其实很硬。它把 Agent 从魔法拉回工程，也把很多团队从 demo 的舒适区里拽出来。