Skip to content

版本 10：可靠性、HITL、可观测与评估闭环

把演示系统变成可运营、可审计、可持续改进的 AI 产品。

它解决什么问题

最终升级不是再增加一个 Agent，而是让整个系统在真实故障、敏感操作和模型变化中仍兑现产品承诺。可靠性处理运行错误，HITL 管理决策边界，可观测性解释发生了什么，Evals 判断系统是否真的变好。

核心定义与工作原理

每个节点定义超时、有限重试、幂等、熔断、降级与死信处理；发布、外发和高风险结论进入人工批准。Trace 串联请求、计划、Agent、工具、Handoff、成本与产物。离线评估覆盖任务、轨迹、工具与协作，在线监控漂移和用户结果，发布采用版本化与灰度。

架构视图（Architecture View）

分析时固定追问：谁拥有控制权，状态存在哪里，模型能决定什么，失败从哪里恢复，人工在哪个边界介入，运行证据如何被观察。

产品视图（Product View）

最终用户看到的是可信的进度、明确的审批、可恢复任务和一致产物；运营看到的是任务级事实而非孤立日志。北极星指标可用“无需人工返工且按 SLA 完成的合格报告比例”，并辅以成本、恢复、审批和安全指标。

简单实践

为完整系统制作生产检查表：注入检索超时、重复发布、审批跨日、远程 Agent 失联和模型升级五种场景；只写预期状态迁移、用户提示、告警和恢复责任，不执行故障实验。

实践只要求架构图、状态或消息契约、失败路径和产品指标，不要求安装依赖或运行代码。

正常场景

任务按约定入口进入，编排层保留业务状态，各节点或 Agent 产出结构化结果，质量门控制下一阶段，用户获得可理解的进度与最终产物。

失败与恢复场景

模型超时、工具失败或子任务质量不足时，区分可重试、可降级和必须人工接管的错误。恢复应依赖业务状态或检查点，而不是把整段任务盲目重跑。

什么时候使用

  • 核心抽象与任务形态一致。
  • 团队能运维它的状态、观测和升级路径。
  • 能满足审批、权限、恢复与成本约束。

什么时候不要使用

早期需求验证不必一次建齐所有平台能力，但涉及真实权限、外部动作或高价值决策时不能跳过关键保护。不要把日志数量当可观测性，也不要只以最终文风评分代替业务结果。

Trade-offs

获得 代价
更清晰地表达目标架构 增加建模和治理成本
复用运行与生态能力 接受版本、依赖和迁移成本
提升自主性或协作能力 增加时延、成本与故障面

产品视角

  • 用户与业务问题：解决哪个可量化瓶颈？
  • 产品价值：提升成功率、速度、可控性还是覆盖范围？
  • 用户体验：进度、等待、切换和失败是否可理解？
  • 自主性边界：哪些判断交给模型，哪些由代码或人决定？
  • 数据与权限：状态、敏感数据和工具权限如何隔离？
  • 失败与降级：能否重试、续跑、切回简单流程或人工处理？
  • 产品指标：完成率、P95 时延、单任务成本、人工介入率、恢复成功率。

框架中的对应实现

顶层 durable graph + Specialist teams + MCP/A2A gateway + policy/approval service + trace store + offline/online eval pipeline。每一层可独立演进。

Workflow、Graph Orchestration、Supervisor、Handoff、Context Isolation、HITL、Durable Execution、Evals。

检查清单

  • [ ] 产品约束先于实现选择
  • [ ] 区分代码控制与模型控制
  • [ ] 明确状态事实源、预算和恢复点
  • [ ] 覆盖权限、审计和可观测性
  • [ ] 记录组织成本与退出方案

延伸练习与参考资料

用同一产品场景改画另一种架构，比较运行语义而非 API 长短；继续阅读对应框架的官方架构、持久化、HITL 与观测文档。