文档定价博客开源

智能体工作流设计：从演示级自动化到生产级可靠性

2026年4月2日Lin Ivan

核心要点

只有当一个 demo 能在坏输入、部分失败和 policy 边界下仍然稳定运行，而不是靠临场发挥躲风险时，它才算真正的工作流。
真正的设计难点不是模型够不够聪明，而是你在执行前如何定义 state、context、tool scope、approval 和 recovery。
人工 review 不是弱系统的补丁，很多时候它恰恰是让你更早、安全上线有价值自动化的那个关键控制点。
可靠的智能体工作流会把 planning、authorization 和 execution 分开，不能让同一个 step 同时负责“判断”和“行动”。
当你的工作流可靠性依赖受治理的 context bundle，而不是每次都从分散系统重新拼证据时，puppyone 会非常有帮助。

大多数智能体 demo 里都藏着一个“隐形操作员”

很多早期智能体 demo 之所以看起来比实际更强，是因为背后有一个人默默替它完成了一部分工作：

在智能体看到输入前先把内容整理干净
发现上下文已经过期
判断哪一个工具是安全的
决定当前结果是否已经足够好
在执行造成损害前手动踩刹车

所以第一次真正上线时，团队常会觉得“怎么突然就不行了”。其实并不是系统突然坏掉，而是那个一直在支撑可靠性的隐形人工层消失了。

也正因为如此，好的智能体工作流设计必须先回答一个很直接的问题：

当操作员很忙、输入又很乱的时候，会发生什么？

如果你的答案是“prompt 会自己处理”，那你手上还只是一个 demo。

Anthropic 的 effective context engineering for AI agents 很有参考价值，因为它把问题重点从 prompt wording，转移到了真正塑造行为的完整 context state。本质上，生产工作流出问题也往往出在这里：不是模型“忘了一句话”，而是工作流给了它错误的 state、错误的 tool，或者根本没有清晰边界。

生产环境里必须明确设计的六个控制面

在继续增加工具、增加 agent persona 之前，先把下面这六个控制面设计清楚：

控制面	你需要回答的设计问题	一旦模糊会怎么坏掉
Goal contract	这次 run 到底要产出什么结果	智能体会跑偏、过度求解，甚至自己发明额外任务
State model	哪些事情已经完成，哪些还只是暂定状态	重试会重复执行，人也无法安全接手继续
Context contract	哪一组证据可以影响这个 step	模型会混用过期、噪声或互相冲突的信息
Tool boundary	这个 step 允许哪些 action	因为什么都像可选项，智能体会把手伸得过远
Approval policy	哪些 action 需要运行时 review 或 policy check	风险控制只存在于 prompt 文案里，而不是真正规则里
Recovery path	step 失败或 confidence 太低时，系统该怎么停	一个 timeout 或弱回答就能拖垮整个流程

这张表故意很朴素。可靠工作流往往就建立在这种朴素但明确的设计上。

NIST 的 AI Risk Management Framework 同样持续强调 traceability、control 和 lifecycle management。对智能体工作流来说也是一样：你应该能够解释用了哪些 evidence、暴露了哪些 tool、走了哪个 policy gate，以及系统为什么继续或停止。

最关键的分界线：把“计划”与“行动”拆开

让同一个 step 同时负责决策和执行，是把智能体工作流做危险的最快方式之一。

比如下面这些指令：

“读完 ticket 后直接给客户发送最终回复”
“检查这笔交易并直接批准退款”
“总结问题并修改生产配置”

它们看起来很高效，但本质上是把 judgment 和 action 压进了一个 prompt 形状的大黑盒。

更适合生产的模式通常是：

收集 evidence
提出 plan
做 policy 检查或请求 approval
只执行一个边界清晰的 action
写入 audit record

这看起来更慢，但通常更容易调试、更安全上线，也更容易扩展。因为每个 step 都有明确职责，整个工作流才真正可检查。

如果你的工作流在“思考”和“行动”之间产不出一个可 review 的 artifact，那通常就是设计味道不对。这个 artifact 可以很小：

一个 plan summary
一个结构化 diff
一个风险标签
一个带 confidence 和 evidence ID 的 action proposal

重点不是增加官僚流程，而是在 side effect 发生之前，把 decision seam 显性化。

为可恢复性设计 state，而不是为“英雄式成功”设计

生产工作流默认就应该是可恢复、可继续的。这意味着系统必须知道哪些已经完成、哪些还在等待、哪些步骤可以安全重试。

一个示意性的 state shape 可以像这样：

{
  "run_id": "wf_2026_04_02_1842",
  "status": "awaiting_approval",
  "current_step": "execute_change",
  "evidence_bundle_id": "ctx_8842",
  "proposal": {
    "action": "update_policy_exception",
    "reason": "ticket matches approved template",
    "confidence": 0.78
  },
  "approval": {
    "required": true,
    "requested_from": "ops-reviewers",
    "requested_at": "2026-04-02T14:20:00Z"
  },
  "side_effects": [
    {"step": "collect_context", "status": "complete"},
    {"step": "propose_plan", "status": "complete"}
  ]
}

这里追求的不是完美 schema，而是足够明确。

一旦工作流带着这样的 state 运行，就会带来几件好事：

重试可以只针对失败 step，而不是整条流程重放
operator 能立刻看懂这次 run 为什么暂停
人工 review 看的是一个紧凑对象，而不是去翻整段聊天历史
audit log 可以把 action、evidence 和 decision state 串起来

这就是从“希望智能体自己记住一切”，转向“让工作流在设计上就可恢复”。

human-in-the-loop 最适合放在 decision seam 上

很多团队会把人工审批加得太晚，或者加在错误的位置。他们让 reviewer 去重读一遍智能体已经读过的全部内容，结果自动化又退化成人肉劳动。

更好的做法，是把人放在业务风险最集中的 seam 上：

destructive write 之前
对外沟通之前
policy exception 之前
基于弱 evidence 采取 action 之前

同时，给 reviewer 的对象也必须足够紧凑，能让他快速判断：

不好的 approval object	更好的 approval object
整段 chat transcript	一个附 evidence link 的 action proposal
原始文档大段倾倒	带 source ID 的紧凑 evidence bundle
“请把所有东西都看一遍”	针对一个 decision 做 approve / deny / request changes

人工 review 的目标是降低风险，不是手动重跑原工作流。

如果 reviewer 不能在一分钟内理解建议动作，那问题通常不在 reviewer，而在上游：context 太大、state 太弱，或者 action contract 根本不清晰。

一个看起来朴素、但很能扛生产的工作流形状

你并不需要一个庞大的 orchestration platform 才能上线可靠流程。一个小而明确的工作流形状，已经足够走很远：

trigger:
  source: inbound_request

steps:
  - collect_context
  - compact_evidence
  - propose_plan
  - check_policy
  - request_approval_if_needed
  - execute_one_narrow_action
  - write_audit_log
  - return_summary

fallbacks:
  on_missing_context: ask_for_more_input
  on_low_confidence: route_to_human
  on_tool_failure: retry_once_then_pause
  on_policy_violation: block_and_log