知识全景图/ 软件工程与系统/ 人工智能全景图/ AI 工作流编排、HITL 与状态管理

AI 工作流编排、Human-in-the-Loop 与状态管理全景图

把不稳定的模型判断嵌入稳定流程：触发、编排、审批、状态、恢复、审计和持续治理

阅读定位: 这一页回答的不是“模型会不会调用工具”，而是“组织级业务流程怎样安全接纳 AI”。它连接一次请求的一生、请求 Trace / 排障模板、AI 证据包索引、AI 应用架构模式、Tool Calling / 执行协议、Agent 系统、长上下文 / 记忆、LLMOps、AI 判断训练场和权限 / 租户 / 数据边界。主语不是单次回答，而是一个会持续推进、暂停、审批、恢复和留证的任务系统。

一、AI 工作流的最小闭环

Trigger
事件 / 用户 / 批任务

→

Context
身份 / 数据 / 目标

→

AI Step
分类 / 生成 / 判断

→

Tool / Human
执行 / 审批 / 接管

→

State
推进 / 暂停 / 恢复

→

Audit
Trace / Eval / 复盘

环节	核心问题	工程对象	常见失误
触发	任务为什么开始	event_id、request_id、schedule、webhook、user action	重复触发、来源不可追溯
上下文	这次任务代表谁、依据什么材料	tenant_id、user_id、policy、retrieved_docs、business_object_id	只靠聊天历史记状态
模型节点	模型负责哪类判断	prompt_version、model_id、schema、confidence、risk_tier	把业务规则藏进 Prompt
工具 / 人工	谁批准、谁执行、影响范围多大	tool_call_id、approval_id、actor、preview、diff	“确认继续”太粗，无法审计
状态推进	任务现在处于哪个可恢复位置	workflow_run_id、step_id、checkpoint、version、timeout	失败后只能重跑全流程
审计闭环	事后能否还原和改进	trace、decision log、eval_case、incident_id、owner	只有最终答案，没有流程证据

一句话:

AI 工作流不是“让模型多走几步”，而是把模型判断、业务规则、工具副作用和人工责任放进一个可暂停、可恢复、可审计的状态机。

二、先分清几种编排对象

对象	它编排什么	适合场景	不要混淆
Prompt Chain	多个模型调用顺序	摘要、改写、提取、分类	不是完整业务状态机
Tool Calling Runtime	模型提出的工具调用意图	查数据、调用 API、写草稿	模型不等于执行者
Agent Runtime	规划、工具、观察、记忆和循环	研究、编码、办公自动化	不能替代业务审批流
Workflow Engine	确定步骤、状态、分支、补偿	工单、审核、运营、财务、人事流程	AI 节点只是其中一种任务节点
BPM / 审批流	组织角色、审批责任和流程合规	合同、报销、权限、发布、采购	审批人批准的是具体动作和影响范围
LLMOps / Release	评测、观测、回归和上线证据	模型 / Prompt / 策略变更	不是线上任务状态本身

三、编排模型：DAG、状态机、事件和 Saga

模型	适合什么	关键设计	风险
DAG	批处理、离线评测、文档处理、多步骤生成	节点输入输出、依赖关系、重跑粒度	遇到人工等待和动态分支会变复杂
状态机	工单、审核、发布、长期任务	状态枚举、合法转移、终态、超时	状态过多或转移条件写散
事件驱动	异步工具、外部系统回调、跨团队流程	event_id、幂等消费、乱序处理、重放	没有 correlation_id 会失去因果链
队列 / Worker	高延迟模型调用、批量任务、限流削峰	重试、死信队列、并发、优先级	重试放大副作用和成本
Saga	多系统写操作、可补偿长事务	每步补偿动作、幂等键、对账	把回滚想成数据库事务
Agent Loop	路径不确定、需要探索的问题	最大步数、预算、观察质量、退出条件	循环、漂移、过度调用工具

四、Human-in-the-Loop：人不是橡皮图章

确认 Confirm

适合低到中风险动作。页面必须展示将要执行的对象、参数、影响范围、可撤销性和成本，而不是只给一个“继续”。

审批 Approve

适合跨权限、跨组织或外部副作用。审批记录要绑定 workflow_run_id、step_id、actor、decision 和 policy_version。

复核 Review

适合质量敏感输出，如合同摘要、医学信息、财务解释、内容审核。复核人看到的是模型证据链和差异点。

接管 Takeover

当模型低置信、循环、工具失败或用户投诉时，系统应把任务和上下文交给人，而不是让模型继续猜。

补充信息 Ask

模型缺少关键字段时，流程应回到用户或业务系统补齐材料；不要用幻觉填空让流程表面继续。

双人复核 Two-person Rule

适合高风险不可逆动作，如付款、权限变更、生产发布、删除数据。模型只能准备材料，不能自治执行。

4.1 人审材料包：人到底在批准什么

材料项	必须展示	写回字段	缺失风险
任务对象	客户、工单、文档、订单、发布单或权限对象的当前版本	business_object_id、object_version、tenant_id	审批人不知道自己批准的是哪个对象或旧状态
模型建议	AI 的结论、理由、引用、置信线索和不确定点	recommendation_hash、citation_ids、confidence_signal	人只能看到结论，看不到证据和边界
拟执行动作	工具名、参数、收件人、写入字段、外部副作用和可撤销性	tool_name、args_hash、side_effect_type、reversibility	确认动作太粗，事后无法判断是否越权或误操作
风险与策略	risk_tier、policy_version、阻断项、例外理由、是否需要双人复核	risk_tier、policy_decision、exception_id、review_rule	高风险请求被当成普通确认处理
审批决定	批准、拒绝、要求补充信息、改参数、转交他人或终止流程	approval_id、reviewer_id、decision、decision_reason	只知道“有人点过”，不知道人类判断内容
恢复路径	如果后续失败，如何重试、回滚、补偿或转事故响应	checkpoint_id、rollback_target、compensation_step、incident_candidate_id	审批后出错无法恢复，只能人工拼状态

HITL 的核心是可判断材料，不是阻塞按钮

人类介入只有在看到对象、证据、动作、风险、策略和恢复路径时才有意义。审批决定要写回 workflow_run_id 和 evidence_pack_id，成为后续审计、事故和回归的证据。

五、状态管理：要分清三种状态

状态类型	记录什么	典型字段	失败时怎么用
任务状态	工作流运行到哪一步	workflow_run_id、step_id、status、retry_count、deadline	从检查点恢复、跳过已完成步骤、转人工
业务对象状态	工单、订单、文档、发布单自身状态	object_id、object_version、owner、business_status	防止旧模型结果覆盖新业务状态
会话 / 记忆状态	用户意图、对话历史、长期偏好	session_id、memory_scope、summary_version、expiry	清理污染记忆、重建上下文、保留审计摘要

状态不应只存在上下文窗口里

上下文窗口适合让模型理解当前任务，不适合作为系统状态数据库。真正的状态要结构化存储，带版本、权限、过期策略和恢复点；Prompt 里只能放本次需要的状态投影。

六、幂等、重试、补偿与恢复

机制	要解决的问题	最小字段	AI 场景里的特殊点
幂等键	防止重复执行副作用	idempotency_key、tool_name、args_hash、actor	模型重试可能生成略有差异的参数，需要先 canonicalize
重试策略	处理供应商超时、临时失败	retry_count、backoff、last_error、budget_left	重试会消耗 token 和工具预算，不应无限尝试
补偿动作	撤销或修正已完成步骤	compensation_step、pre_state、post_state、owner	外部动作可能不能真正回滚，只能发更正或冻结
检查点	长任务暂停和恢复	checkpoint_id、step_outputs、context_summary、state_version	恢复时要重新校验权限、业务状态和 Prompt 版本
超时 / 取消	避免任务悬挂	timeout_at、cancel_reason、cleanup_status	人工审批等待、外部工具回调和模型流式输出都要有终态
转人工	机器不能继续时保住任务	handoff_reason、evidence_pack、assigned_to、sla	交给人的不是聊天记录，而是可决策材料包

七、观测与治理：每个流程都要能被问责

指标 / 证据	看什么	触发动作
步骤成功率	AI 节点、工具节点、人工节点分别哪里失败	定位是模型、工具、权限、审批还是流程设计问题
等待时间	人工审批、外部系统回调、队列排队	调整 SLA、自动提醒、拆分风险等级
循环 / 重试次数	Agent 是否反复走同一类动作	设置退出条件、转人工、收集坏例
覆盖率	多少任务自动完成、多少需要人工接管	决定是否扩大自动化范围
风险命中	高风险动作、越权拦截、安全策略命中	更新权限、护栏、审批模板
版本影响	Prompt / 模型 / 策略变更前后流程质量	进入 Eval、灰度、回滚或反馈闭环

7.1 Workflow Run 证据包：把状态迁移和人工责任串起来

证据节点	必须记录字段	判断重点
流程入口	workflow_run_id、request_id、trace_id、trigger_event_id、tenant_id、business_object_id	流程为什么启动，代表哪个租户和业务对象，能否和一次请求 Trace 对齐？
流程定义	workflow_definition_id、workflow_version、release_gate_id、owner、rollback_target	当前执行的是哪个流程版本，是否经过评测、灰度和回滚门禁？
状态迁移	step_id、from_state、to_state、state_version、transition_reason、checkpoint_id	每一步状态变化是否合法，失败后能否从确定检查点恢复？
AI 节点	model_id、prompt_version、schema_id、confidence_signal、eval_case_id、risk_tier	模型判断是否达到自动推进阈值，低置信或高风险是否触发人工接管？
工具 / 副作用	tool_call_id、idempotency_key、args_hash、side_effect_type、compensation_step	外部动作是否幂等、可对账、可补偿，重试是否会放大副作用？
人工责任	approval_id、reviewer_id、decision、decision_reason、evidence_pack_id	人类批准、拒绝、改参或接管的依据是什么，审批材料是否完整？
事故 / 回归	incident_id、regression_scenario_id、fixed_workflow_version、artifact_id、retention_until	流程坏例是否进入回归场景，修复版本和流程资产是否可追溯？

八、工作流事故回放：从卡住、误批到可恢复证据包

事故现象	要反查的证据	修复产物
AI 节点低置信却自动推进	workflow_run_id、step_id、request_id、confidence_signal、risk_tier、handoff_rule	收紧自动推进阈值，新增 handoff_reason 和 eval_case_id
人工审批材料不完整导致误批	approval_id、business_object_id、object_version、recommendation_hash、citation_ids、policy_version	升级人审材料包模板，补齐必看字段和双人复核规则
工具执行超时但副作用状态不明	tool_call_id、idempotency_key、args_hash、timeout_at、external_receipt、checkpoint_id	补外部对账、确认终态、记录 compensation_step
重试导致重复外部动作	retry_count、idempotency_key、canonical_args、tool_name、actor、side_effect_type	统一参数规范化，给副作用工具加幂等门和预算
业务对象版本变化导致旧 AI 结果覆盖新状态	business_object_id、object_version、state_version、step_outputs、fixed_workflow_version	恢复和写入前重新校验版本，旧结果只能进入人工复核
人工接管后证据没有回写	handoff_reason、assigned_to、decision_reason、evidence_pack_id、incident_candidate_id	把接管结论写回 workflow evidence pack 和 regression scenario

工作流事故复盘的最小字段

至少要能串起 workflow_run_id、step_id、request_id、approval_id、checkpoint_id、object_version、idempotency_key、compensation_step、handoff_reason、evidence_pack_id、incident_candidate_id、eval_case_id 和 fixed_workflow_version。

复盘不能只说“加人工确认”，而要形成可回放的 workflow evidence pack、可重跑的 regression scenario、可验证的 fixed_workflow_version。

九、典型场景和反模式

客服工单分流

AI 负责分类、摘要、建议回复；流程负责 SLA、升级、审批、客户通知和人工接管。

内容审核

AI 负责初筛和证据抽取；人工负责边界样本复核；系统负责策略版本、申诉和回归集。

销售 / 运营自动化

AI 可生成方案和下一步动作，但发外部消息、改客户状态、触发财务动作必须经过确认或审批。

代码与运维流程

AI 可生成补丁、解释日志、准备回滚方案；合并、发布、生产变更仍要走工程治理和审计。

反模式：流程藏在 Prompt 里

Prompt 写了十几条业务规则，但系统没有状态、版本、审批和回滚，最后只能靠模型“记得遵守”。

反模式：人工确认太粗

用户点了“同意”，但看不到影响对象、工具参数、外部副作用、可撤销性和审批责任。

反模式：批量错误无熔断

模型分类错一批任务，工作流仍继续自动推进，直到错误规模化扩散到外部系统。

反模式：重试没有预算

每次失败都让模型重新规划和调用工具，成本、延迟和副作用一起失控。

十、上线前评审问题

问题	必须回答	继续回读
AI 节点负责判断什么？	输入、输出 schema、置信度、失败条件、人工接管条件是否明确	AI 应用架构模式
哪些动作有副作用？	工具分级、确认门、审批人、幂等键和补偿动作是否存在	Tool Calling / 执行协议
任务如何恢复？	是否有 workflow_run_id、checkpoint、state_version、timeout 和 cancel path	长上下文 / 记忆
人批准的是什么？	是否展示对象、参数、影响范围、证据、风险和可撤销性	AI 产品 UX
权限是否重新校验？	恢复、重试、转人工、工具调用时是否重新应用身份和策略	权限 / 租户 / 数据边界
流程变更怎么上线？	Prompt、模型、策略、工具 schema 和流程定义是否走评测、灰度和回滚	LLMOps / 可观测性

总结:
AI 工作流编排的底层难点，是把模型这种概率性组件放进确定性的组织流程里。能自动的地方要有边界，不能自动的地方要有证据，人介入的地方要有责任，失败的地方要能恢复。

继续阅读:

AI 阅读路线 → 一次请求的一生 → 请求 Trace → AI 证据包索引 → 应用架构模式 → Tool Calling → Agent 系统 → Artifact Registry → LLMOps → 发布 / 回滚 → 事故响应