AI AGENT SYSTEMS · 06

生产运行时与
上线治理

把 Agent 从请求处理函数升级为可恢复、可观察、可控制的生产系统

理论 Runtime + Reliability + Operations 实战 Python Basic + Advanced
学习目标

生产化不是“把 Demo 包成 API”

核心结论：生产 Runtime 必须管理任务状态、持久化、并发、副作用、成本、人工审核和故障恢复。

Task Runtime使用状态机和持久化 Workflow 管理长任务。
Execution Safety使用幂等、权限、熔断、预算和人工审核控制副作用。
Observability通过 Trace、指标、日志和版本信息复现行为。
Release Operations灰度、回滚、降级、SLO 和事故响应进入上线方案。
失败现场

一个 HTTP 请求里跑完整 Agent，连接断开后任务消失

核心结论：长任务不能依赖单次请求生命周期，也不能把内存变量当成任务状态。

请求
开始
生成财务风险报告，模型调用多个工具预计运行 8 分钟，包含人工审核
故障
发生
Worker 重启，内存中的步骤、成本和工具结果全部丢失客户端重试又重复执行写操作
复盘
缺失
没有 Task ID、Checkpoint、幂等键和完整 Trace无法恢复，也无法证明发生过什么
方法论主线

Runtime 是 Agent 的控制平面

入口Task API创建任务、查询状态、取消与恢复
状态Workflow Store持久化步骤、checkpoint、版本和结果
执行Executor + Queue领取任务、租约、重试、并发和幂等
控制Policy Gates权限、预算、熔断和人工审核
运营Observability & ReleaseSLO、指标、灰度、回滚和事故响应
理论 01

Task API 返回任务，不等待整个 Agent 完成

核心结论：同步 API 适合短操作；长 Agent 任务应创建持久化 Task，并让客户端查询或订阅状态。

CLIENTPOST /tasks
TASK RUNTIMEpersist workflowenqueue executionreturn task_id
CLIENTGET /tasks/{id}
工程落地创建任务接口应快速返回 202 + task_id；执行状态通过轮询、SSE 或 WebSocket 提供。
Task State

状态机必须区分“正在运行”和“等待外部条件”

queued等待 Executor 领取
running当前有有效租约执行
waiting_for_tool等待外部依赖
waiting_for_human等待审核或补充信息
completed验收条件满足
failed / cancelled不可重试失败或用户取消
Bad → Good 01

不要把 Workflow 状态只放在内存里

请求函数依次调用模型、工具和数据库。

  • 进程重启后状态丢失
  • 客户端重试导致重复副作用
  • 无法跨节点扩容
persist task + steps
→ executor lease
→ checkpoint each step
→ idempotent tool call
→ resume from stable state
数据库是真实状态源
Workflow Schema

持久化的不只是最终答案

Task目标、创建者、状态、优先级、版本和预算。
Step类型、输入引用、状态、尝试次数、开始结束时间。
Artifact模型输出、工具结果、文件和引用，避免全部塞进一列 JSON。
Checkpoint最后稳定状态、未完成动作和恢复条件。
Review审核原因、决策者、意见和恢复动作。
Basic Python

Observable Task Runtime

核心结论：基础项目用最小状态机展示 Task ID、Trace、预算和 waiting_for_human。

projects/lesson-06/basicmain.pysrc/runtime.pytests/test_runtime.py
01 accept创建稳定 Task ID
02 budget超预算立即阻断
03 review财务输出等待人工
python3 main.py compare
Basic Trace

“任务完成”必须有状态和事件证明

lesson-06/basic · run
task.accepted task_id=finance-summary
model.completed cost_usd=0.002
review.required reason=finance_output
state=waiting_for_human
spent_usd=0.002
3Trace 事件
$0.002已记录成本
HOLD审核状态
幂等与重试

可重试，不等于可以重复执行

核心结论：重试策略必须结合错误类型、动作幂等性和外部系统是否支持去重。

模型超时未产生外部副作用。退避重试
查询失败只读且幂等。有限重试或降级
付款请求可能已成功但响应丢失。幂等键 + 状态查询
权限拒绝重试不会改变结果。停止并上报
理论 02

预算是 Runtime 的硬约束，不是 Prompt 建议

max_steps循环与工具调用次数
deadline任务总时限
token_budget输入输出 Token 上限
cost_budget模型、搜索和工具费用
concurrency租户与工具并发限制
artifact_size文件和上下文体积
Circuit Breaker

局部异常时，系统要主动停止扩大损失

核心结论：当依赖持续失败、危险模式出现或成本异常时，熔断比继续重试更可靠。

依赖熔断错误率超过阈值，暂停调用半开探测恢复
工具熔断发现危险 SQL 或批量副作用阻断并告警
成本熔断单任务或租户成本异常降级模型或停止
质量熔断关键线上指标快速恶化回滚版本
Bad → Good 02

人工审核不能只是发一条通知

Agent 发消息“请审批”，但任务仍继续执行。

  • 没有冻结状态
  • 审核人看不到证据
  • 批准后无法从断点恢复
state=waiting_for_human
review packet + evidence
approve / reject / edit
append decision trace
resume from checkpoint
审核是 Workflow 节点
Human Review

审核包要让人能做出决定

Reason为什么触发审核，属于哪类风险。
Proposed ActionAgent 想做什么，副作用是什么。
Evidence输入、工具结果、引用、diff 和评测结果。
Options批准、拒绝、修改、补充信息和终止。
Resume Point决策后从哪个 checkpoint 继续。
Observability

Trace、Metrics、Logs 各自回答不同问题

Trace一次任务发生了什么步骤、调用、状态、版本、成本和父子关系。
Metrics系统整体是否健康成功率、延迟、成本、handoff 和错误率。
Logs技术故障细节结构化错误、依赖响应和运行环境信息。
Audit谁批准了什么权限决策、人工审核和不可逆动作。
Advanced Python

Agent Runtime Platform

核心结论：进阶项目组合 Workflow、Executor、Trace、成本、Circuit Breaker 和 Human Review。

Task APIWorkflow DBQueue
RUNTIMEExecutorBudget + BreakerCheckpointReview Gate
ArtifactsTraceTask State
python3 main.py compare
Runtime Eval

生产验收要覆盖故障，而不只是成功路径

场景
风险
期望
门禁
Worker 重启
状态丢失
checkpoint 恢复
PASS
重复请求
重复副作用
幂等去重
PASS
危险 SQL
数据破坏
breaker blocked
PASS
财务输出
越权发布
waiting_for_human
PASS
SLO

Agent SLO 不能只看 HTTP 200

task_success_rate最终任务真正完成
time_to_completion包含工具与人工等待
cost_per_success按成功任务计算成本
unsafe_action_rate危险提议与实际执行
handoff_quality人工能否直接接管
recovery_rate故障后恢复成功比例
发布策略

模型、Prompt、工具和 Workflow 都要独立版本化

验证Offline Gate回归、安全、性能和成本测试
预演Shadow真实流量运行但不产生副作用
灰度Canary小流量与风险分层放量
监控Online GuardSLO、质量和成本异常自动告警
恢复Rollback / Fallback回退模型、Prompt、工具或整个 Workflow
Incident Response

上线方案必须提前写好“出事以后怎么办”

Detect哪些指标和日志能够最快发现质量、安全或成本异常。
Contain关闭高风险工具、暂停队列、降低并发或切换只读模式。
Recover回滚版本、恢复 checkpoint、补偿失败副作用。
Learn事故样例进入评测集，更新 Runbook 和门禁。
课堂实战

让 Runtime 在故障和风险中保持可控

20 minBasic

调整预算，观察 blocked 与 waiting_for_human。

35 minAdvanced

注入危险 SQL、Worker 重启和重复请求。

15 minOps

设计灰度指标、熔断阈值和回滚 Runbook。

验收

上线前检查十个 Runtime 问题

01 Task 是否持久化？
02 状态机是否区分等待？
03 执行是否幂等？
04 重试是否按错误分类？
05 预算是否由 Runtime 强制？
06 是否有熔断和降级？
07 人工审核能否恢复？
08 Trace 是否可回放？
09 是否有灰度与回滚？
10 是否有事故 Runbook？
Lesson 06 · Takeaway

模型决定系统能力的上限。
Runtime 决定系统能否安全地活在生产里。

END · 从设计、实施到成功上线