项目二：可恢复 Agent Workflow

项目目标

实现一个设备故障分析工作流：读取设备信息、在线历史和告警，生成报告；创建维修工单前必须人工审批。

架构

API
→ Task Service
→ Workflow Worker
  ├→ LLM
  ├→ Read-only Tools
  ├→ Approval
  └→ create_ticket Tool
→ PostgreSQL：任务、步骤、执行、Eval
→ Redis：短期运行状态和限流

工作流

parse
→ validate
→ collect_evidence
→ analyze
→ generate_report
→ [需要工单?]
   ├─ 否 → completed
   └─ 是 → waiting_approval
             ├─ reject → completed
             └─ approve → create_ticket → completed

生产化要求

结构化

• 每个 Agent 节点有 Schema；
• 解析失败最多修复一次；
• 业务规则继续校验。

状态

• 每一步保存 checkpoint；
• 服务重启后继续；
• 取消和审批是显式状态。

幂等

• create_ticket 使用 operation_id；
• 重复审批或恢复不会创建两张工单。

可观测性

• Trace；
• Prompt、模型和 Tool 版本；
• Token、成本、延迟；
• 错误与重试。

Eval

至少 30 条案例：

• 正常；
• 信息不足；
• 权限；
• 工具失败；
• 文档注入；
• 低置信度；
• 高风险批量操作。

故障演示

• 模型超时后有限重试
• Tool 成功但响应丢失后不重复创建
• Worker 重启后从 checkpoint 恢复
• 审批拒绝后不会执行
• 越权设备被拒绝
• Prompt 修改后执行回归 Eval

技术选择

第一版可以自写状态机，理解数据结构后再接 LangGraph。框架不是项目价值，可靠性设计才是。