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