生产治理 Playbook

AI Agent 原型的演示通常看最终回答。企业上线看的是另一组问题：一次改动有没有让系统变好，失败能不能定位到具体层，成本是否可控，高风险动作有没有审批，线上服务能不能被产品和运维团队接住。

生产治理不是把功能做完后的装饰层。每新增一层智能能力，就要新增一层可验证证据。

先用四类证据说话

证据	解决什么问题	Agently 入口
输出契约	业务系统能不能稳定消费结果	输出控制、模型响应
运行轨迹	一次请求、Action、流程和环境到底发生了什么	Event Center、DevTools
状态证据	产物、决策、检查点和上下文能不能找回	Workspace、长程任务状态与恢复 Playbook
场景回归	改 prompt、模型、工具或 flow 后是否真的变好	DevTools EvaluationBridge、应用测试、模型 judge

这些证据放在一起，才能从“这次输出看起来不错”升级到“这条能力可以被持续迭代”。

Eval：先固定代表性场景

最小 eval 不需要覆盖所有线上输入。先选能代表业务风险的样例：

样例类型	检查点
正常输入	字段完整、流程正确、输出可消费
边界输入	缺字段、模糊意图、长文本、重复提交
高风险输入	需要拒绝、审批、人工接管或最小权限
回归输入	历史线上问题、客户反馈、版本变更点

判断方式按风险分层：

• 字段、枚举、必填项：用结构化 output 和确定性断言。
• 业务规则：用明确规则检查，比如金额阈值、可逆性、审批要求。
• 语义质量：用第二个 Agently model judge 输出结构化判定，不靠关键词猜测。
• 人工验收：保留样例、输入、输出、judge 结果和人工结论。

DevTools 的 EvaluationBridge 适合开发期和发布前跑固定场景；线上请求不要全部实时塞进 eval。

Trace：让问题能定位到层

一个生产问题至少要能定位到下面哪一层：

Gateway
  task_id / session_id / trace_id / tenant

Request
  model request / output validation / retry

Action
  selected action / args / result / error / approval

ExecutionEnvironment
  environment declared / approval / ready / failed / released

TriggerFlow
  execution_id / chunk / pause / resume / close snapshot

Workspace
  artifact refs / decisions / checkpoints / ContextPack

Event Center 负责接收框架级 RuntimeEvent。生产日志、指标和审计 hook 应该从 run 字段关联链路，不要从 message 文本里解析 id。

Runtime stream 和观测事件不要混

需求	用
前端展示“正在审查第 3 条风险”	TriggerFlow runtime stream
诊断模型请求和 action 是否发生	Event Center / RuntimeEvent
本地看完整运行过程	DevTools ObservationBridge
发布前跑代表性样例	DevTools EvaluationBridge 或应用测试

给 UI 的 stream item 应该是稳定业务事件，例如 report_section_ready、approval_required、risk_item_ready。不要让前端绑定 raw parser path 或低层 token。

成本与可靠性先放在 owner 里

问题	Owner	设计动作
高频请求成本失控	Gateway / runtime settings	设置模型档位、预算、限流和降级路径
模型首 token 或流式响应卡住	model requester / result facade	配置 timeout、stream idle、materialization timeout
Action 慢或失败	Action Runtime / adapter	设置 timeout、错误结构、重试和 fallback
非幂等动作重复执行	业务 adapter	幂等键、外部写入记录、重复请求保护
长流程中断	TriggerFlow / Workspace	execution save、checkpoint、resume 和 artifact refs
prompt 或 flow 改动后质量不明	Eval / DevTools	固定样例集、基线、发布前回归

成本和可靠性不是一个全局开关。它们分散在 gateway、model requester、Action adapter、TriggerFlow 和业务系统里，需要按 owner 配置。

安全基线从能力可见范围开始

安全不是只靠 prompt 让模型谨慎。至少要处理四层：

层	要控制什么
可见能力	本轮任务让模型看到哪些 Action、MCP tool、Skill 和资源
执行权限	哪些动作只读、哪些要审批、哪些 fail closed
数据边界	输入、工具返回、日志、trace 和报告是否需要脱敏
审计恢复	高风险动作、审批、resume、外部写入是否可追踪

MCP 解决能力标准化暴露，不自动解决企业治理。Host / Action Runtime / ExecutionEnvironment / 业务 adapter 才是权限、裁剪、脱敏和审计的 owner。

上线拓扑的最小分层

api-gateway
  auth / tenant / route / rate limit / SSE or WebSocket

agent-service
  Agent definition / request contracts / result projection

workflow-worker
  TriggerFlow / Dynamic Task / pause-resume / stream bridge

capability-adapters
  Actions / MCP clients / internal APIs / sandbox environments

state-store
  Session store / Workspace / checkpoint / business DB refs

observer-eval
  RuntimeEvent hooks / DevTools / eval cases / release evidence

早期可以在一个进程里实现这些模块，但代码职责最好按这个分层放。等到负载、安全或组织协作需要拆服务时，不需要重新解释边界。

上线前检查

检查	通过标准
输出	所有业务写入来自结构化 data 或 snapshot 投影
流式	UI stream 是稳定业务事件，最终状态另行持久化
工具	Action/MCP 能力有 schema、权限、timeout 和错误语义
环境	沙箱、浏览器、数据库、MCP server 生命周期有 owner
状态	大产物进 Workspace，execution state 只留紧凑数据和 ref
恢复	pause/resume、checkpoint、live resource reinjection 路径清楚
观测	关键层都有 RuntimeEvent、trace id 或业务日志
评估	代表性样例可重复运行，并记录通过标准
安全	高风险动作有审批、审计和 fail-closed 路径
更新	release notes、示例、官网文档和 Agently-Skills 指引能同步

继续阅读

• 观测概览
• Event Center
• DevTools
• 长程任务状态与恢复 Playbook
• 工具治理与 MCP Host Playbook
• 从 PoC 到上线