Wiki Notes

Appearance

Agent与工作流 ​

版本：v1.3

最后更新：2026-07-08

状态：已并入 AI Agents 与工作流总目录

这一页现在保留为 工作流与工程落地 子目录首页，方便历史链接继续可用。

如果你是从左侧新菜单进入，建议把这里看成统一总目录下的“工程实现层”：

一、这一组内容主要解决什么 ​

从工程视角看，这里主要覆盖四类问题：

层次典型问题推荐先读
工具层schema 怎么设计、参数怎么校验、权限怎么隔离Agent工具设计专题、工具结果校验专题、工具权限沙箱专题
编排层单 Agent、工作流、多智能体怎么取舍多智能体协作专题、工作流状态机专题、Agent回合控制专题
运行层长任务、补偿、恢复、上下文压缩、记忆治理怎么落地长任务恢复策略专题、工具调用补偿机制专题、上下文压缩与记忆分层专题、会话记忆治理专题
治理层审批、人工纠偏、可观测、评测、回放怎么闭环审批与人机协同模式专题、人工纠偏工作台专题、Agent计划回放专题、Agent任务分解评测专题、工具观测事件模型专题

二、遇到什么问题先看哪篇 ​

1. 工具会乱调、参数会乱填 ​

2. 流程一长就失控，不知道跑到哪一步 ​

3. 想上多智能体，但担心复杂度过高 ​

4. 高风险动作需要审批或人工接管 ​

5. 出事故后说不清错在哪一层 ​

三、推荐阅读路径 ​

1. 从“能跑”到“可上线” ​

  1. Agent工具设计专题
  2. 工具结果校验专题
  3. 工作流状态机专题
  4. 长任务恢复策略专题
  5. 审批与人机协同模式专题

2. 从“可上线”到“可治理” ​

  1. 工具权限沙箱专题
  2. 工具调用补偿机制专题
  3. 人工纠偏工作台专题
  4. 工具观测事件模型专题
  5. Agent计划回放专题

3. 从单 Agent 到多角色协作 ​

  1. 多智能体协作专题
  2. 上下文压缩与记忆分层专题
  3. 会话记忆治理专题
  4. 工作流状态机专题
  5. Agent任务分解评测专题

四、与总目录的关系 ​

五、什么时候应该优先看这一组 ​

1. 你的 Agent 已经“能跑”，但总是跑不稳 ​

这通常说明问题已经从模型能力层转到了执行层和运行层，更适合先看工作流状态、工具设计、恢复、补偿和观测，而不是继续只改 Prompt。

2. 你已经发现系统开始依赖外部状态 ​

只要流程里开始出现：

  • 工具调用
  • 数据写入
  • 审批节点
  • 长任务
  • 人工接管

就说明系统已经不只是“会回答”，而是在“会执行”，这时工程落地专题的权重会明显高于继续堆模型技巧。

3. 你开始担心事故、回滚和追责 ​

如果一个 Agent 系统已经会改数据、发消息、调外部系统或代表用户执行动作，那状态机、权限沙箱、回放、补偿和审批就不再是高级话题，而是上线前的基本功。

六、不同角色更适合怎么进入 ​

1. 应用工程师 ​

更适合先看：

  1. Agent工具设计专题
  2. 工具结果校验专题
  3. 工作流状态机专题
  4. Agent回合控制专题

2. 平台或架构同学 ​

更适合先看：

  1. 工作流状态机专题
  2. 长任务恢复策略专题
  3. 工具调用补偿机制专题
  4. 工具观测事件模型专题

3. 业务或交付负责人 ​

更适合先看：

  1. 审批与人机协同模式专题
  2. 人工纠偏工作台专题
  3. Agent计划回放专题
  4. 安全治理

七、当前官方资料最值得先建立的几个工程判断 ​

按 2026-07-08 复核可访问的 OpenAI Agents SDK、MCP、LangGraph 和 Temporal 官方资料，比较值得先建立的工程判断有这些：

1. tools、agents-as-tools、handoff、workflow 不是一回事 ​

OpenAI 当前 Orchestration and handoffs 文档把两类能力分得很清楚：

  • agent.asTool()：主 agent 保持最终责任，把 specialist 当成受控子能力调用
  • handoff：把控制权真正切给另一个 specialist

这对工程落地的意义很大，因为它们对应的其实是不同控制单元：

  • 工具调用：更适合单步、边界清楚、可校验的动作
  • agents-as-tools：更适合“主流程不丢控制权，但需要复杂子任务”的情况
  • handoff：更适合职责、上下文、权限和输出责任都明显不同的场景
  • workflow：更适合顺序、分支、状态转换已经大致确定的流程

如果这几层不分清，系统会很容易：

  • 明明只是工具调用，却上成多 Agent
  • 明明可以做 workflow，却让 Agent 自由决定所有状态流转

2. 人工审批和中断必须是“可恢复暂停点”，不能只是前端弹窗 ​

OpenAI 当前 Guardrails and human review 明确把 human review 设计成：

  • run 可以继续、暂停或停止的控制点

LangGraph 当前 interrupts 文档也明确强调：

  • interrupt 会保存图状态，并等待外部输入后继续

Temporal 当前官方文档对 durable execution 的解释则进一步提醒我们：

  • 真正有价值的暂停点，必须在失败、重启和跨时段后还能恢复

这背后的工程判断是：

  • 审批不是“弹窗确认”
  • 而是执行状态机里的正式节点

所以高风险动作更稳的做法通常是：

  1. 先生成待执行动作。
  2. 把动作快照、上下文和证据冻结。
  3. 在持久化状态上进入等待审批。
  4. 审批通过后再恢复执行。

3. 只要开始改外部状态，就必须把补偿和幂等当成主设计对象 ​

很多 Agent Demo 的默认假设是：

  • 工具失败就再试一次

但只要系统开始：

  • 写库
  • 发消息
  • 调第三方接口
  • 触发工单或审批

“再试一次”就可能直接制造重复副作用。

所以工作流工程里更稳的默认心智通常是：

  • 每个写动作都要问自己能不能幂等
  • 不能幂等时要不要做补偿
  • 补偿失败时要不要转人工

这也是为什么 工具调用补偿机制专题、人工纠偏工作台专题 和 Agent计划回放专题 应该被看成同一条治理链，而不是三篇互不相干的专题。

4. 记忆、状态和执行历史是三种不同对象 ​

工程里很容易把下面三件事混在一起：

  • 会话记忆
  • 当前工作流状态
  • 执行历史 / replay 证据

但从 LangGraph Persistence、OpenAI Conversation state 和 Temporal Event History / Workflow Execution 这些资料放在一起看，更清楚的拆分通常是：

  • 记忆：给后续决策继续用的上下文资产
  • 状态：当前 run 走到哪一步、等待什么输入
  • 历史：为了恢复、审计、回放和复盘保留的执行轨迹

这三者一旦混成同一个存储对象，后面通常就会出现：

  • 恢复不准
  • 回放缺证据
  • 记忆越积越脏

八、工程落地里最容易漏掉的四个边界 ​

1. 工具成功不等于任务成功 ​

很多系统只记录：

  • 工具是否返回 200

但真实任务还要继续问：

  • 参数是不是对的
  • 顺序是不是对的
  • 结果是不是被正确消费
  • 最终业务目标是不是完成了

2. workflow 负责收口确定性，Agent 负责处理不确定性 ​

如果一个步骤：

  • 输入稳定
  • 分支有限
  • 失败代价高

那通常更应该先做 workflow / state machine，而不是默认让 Agent 自由发挥。

3. 审批节点应该挡在副作用之前，而不是副作用之后 ​

很多“审批”其实做成了：

  • 先执行
  • 再通知

这不是真正的审批节点，只是事后告警。

4. 回放要能回答“为什么会走到这里”，不只是“走过这里” ​

如果回放里没有：

  • 状态迁移原因
  • 工具选择原因
  • 人工介入原因
  • 最终停止或升级原因

那它对事故复盘和优化价值会很有限。

九、不同系统形态更适合先补哪条工程线 ​

1. 工具型单 Agent ​

优先补：

  1. Agent工具设计专题
  2. 工具结果校验专题
  3. 工具权限沙箱专题

2. workflow + Agent 混合系统 ​

优先补：

  1. 工作流状态机专题
  2. 长任务恢复策略专题
  3. 审批与人机协同模式专题
  4. 工具调用补偿机制专题

3. 高风险写操作系统 ​

优先补：

  1. 工具权限沙箱专题
  2. 审批与人机协同模式专题
  3. 人工纠偏工作台专题
  4. 安全治理

4. 长任务、跨时段、跨人协作系统 ​

优先补：

  1. 长任务恢复策略专题
  2. 会话记忆治理专题
  3. Agent计划回放专题
  4. 工具观测事件模型专题

十、重点官方资源 ​

以下资源已按 2026-07-08 复核可访问：