Agent 上线后至少要观察五类结果：业务是否完成、执行链是否健康、输出是否合格、风险控制是否生效、资源消耗是否可接受。调用次数和模型响应时间只能说明服务被使用，任务有没有真正办完，还要看工具回执、审批状态和业务系统结果。ZGI Runtime 可以把 Agent、Workflow 和模型路由放在同一工作区，部署时还可按需接入 OpenTelemetry trace。
指标设计要从任务终点往前拆。用户拿到一段回答，可能仍在等待文件生成、数据写入或人工审批；模型请求成功，后面的工具也可能超时。只有每一步使用同一个任务编号，业务结果才能和模型、工具、Workflow 记录对上。
概念示意图：从业务结果回看运行节点、工具回执、模型调用与人工介入。
五类指标回答不同问题
指标放在一张总表里很容易互相替代。业务完成率低，需要继续区分任务卡在哪一层；模型输出通过率高，也不能覆盖工具提交失败。先按问题分组，再决定看板展示哪些数字。
| 观察层 | 要回答的问题 | 可记录的指标 |
|---|---|---|
| 业务结果 | 用户要办的事完成了吗 | 完成率、有效回执、交付时间 |
| 执行健康 | 流程卡在哪里 | 节点失败、超时、重试、恢复结果 |
| 输出质量 | 结果能继续使用吗 | 结构校验、引用核对、人工退回 |
| 风险控制 | 高影响动作受到管理了吗 | 审批、拒绝、越权拦截、异常写入 |
| 资源消耗 | 运行成本是否可接受 | 模型调用量、Token、端到端耗时 |
完成率需要预先写清完成条件。月度经营分析 Agent 读取指定账期数据、生成图表和报告草稿后，任务还可能停在复核阶段。只有报告通过审批并写入约定位置，业务状态才进入完成。模型生成成功、图表生成成功和报告交付成功应保留三个独立状态。
质量指标也要对应具体产物。结构化数据可以检查字段和类型，知识问答可以核对引用是否支持结论，文件任务可以检查格式、页数与必要章节。没有标注样本时，可以记录"返回了内容"和"通过了规则校验"，不要把这类数字写成准确率或召回率。
用同一任务编号串起记录
一次任务通常经过模型、检索、工具、审批和业务系统。每一层只记录自己的请求编号，排障时很难找到同一件事。更实用的做法，是为任务生成稳定标识，并把它带入节点记录、工具请求、审批记录和最终业务回执。
运行记录还要保存版本信息。Agent 指令、Skill、Workflow、知识资料和模型路由发生变化后，同类任务的表现可能跟着变化。看板按版本分组，才能判断失败增多来自哪次调整。敏感字段应脱敏，观察权限也需要单独配置。
ZGI 的自托管部署可以按需启用 OpenTelemetry，把 API trace 导出到 Jaeger 或 Langfuse。追踪默认需要主动配置；部署指南建议共享或生产环境优先记录摘要，只有数据策略允许时再采集完整提示词和输出。业务完成率、审批结果和最终回执仍要从企业系统补进同一条任务链。
先做一张小看板
第一版看板无需放几十个指标。可以先选一条高频任务，记录任务总量、完成状态、失败节点、人工介入、工具回执、端到端耗时和模型消耗。每天抽查几条失败记录，确认指标能否回答"停在哪里、为什么停、是否恢复"。
使用 ZGI 验证时，可以从一条 Workflow 开始，在业务系统与运行记录中共用一个任务编号，并把最终回执关联回来。连续观察一周后，再根据真实故障增加指标；没有对应行动的数字暂时不进主看板。这样做出的运行指标，才能帮助团队修流程、调权限和控制自动化范围。
ZGI 官网：https://zgi.cn
GitHub：https://github.com/zgiai/zgi