企业同时使用多个 AI 助手时不能只统计总调用次数。可执行的口径至少要区分助手身份、活跃用户、任务启动、有效会话、业务结果和成本。统计时应使用稳定 ID 关联数据展示名称只负责阅读否则产品改名、同一助手出现多个入口后历史趋势会被切断。这个问题在 2026 年 8 月变得更具体。GitHub 为 Copilot Usage Metrics API 增加了按第三方智能体拆分的活动数据企业可以分别查看不同智能体应用的任务启动与会话情况。多助手治理开始从「有没有人用」走向「谁在用、用哪个、产生了什么结果」。先统一统计对象同一个 AI 助手可能出现在 IDE、代码仓库、聊天入口和自动化任务里。如果按入口统计它会被误算成四种产品如果只看总调用量又无法判断采用情况。更稳妥的方式是为每个助手保留稳定 ID再把入口、模型版本和展示名称作为可变化属性。GitHub 本次更新也采用了类似思路。API 返回agent_id和agent_name官方明确建议跨周期聚合时使用稳定的agent_id因为展示名称可能变化。它还区分用户主动启动的任务与会话数量避免把不同事件简单相加。使用量要分成三层第一层是采用情况回答有多少人在用、使用频率如何。第二层是运行情况回答启动了多少任务、形成多少会话、失败和取消发生在哪里。第三层才是业务结果例如完成的代码变更、解决的工单或节省的人工步骤。只看第一层容易制造虚假繁荣。某个助手的活跃人数很高可能只是默认安装任务启动很多也可能伴随大量中断。只看业务结果也有问题因为早期试点还没有足够样本团队会过早淘汰仍在学习期的方案。三层数据要并排看不能互相替代。业务结果还要提前定义口径。代码场景可以记录合并后的变更客服场景可以记录已解决工单研究场景则可以记录被采用的报告。只写一个笼统的「任务完成」字段很难支撑后续比较。一个适合起步的数据字典可以包含这些字段assistant_id、entry_point、user_id、task_started_at、session_id、status、model_id、cost和outcome_type。涉及员工数据时还要限定查看权限、保留周期和聚合粒度避免把采用分析变成绩效监控。统一运行层能减少口径分裂当不同助手各自连接模型、知识库和工具时日志结构往往彼此不兼容。ZGI 这类可自托管的 Agent Runtime 可以作为统一运行入口帮助团队把模型、数据、工具和工作流放进同一套运行关系中。这里更重要的价值是建立共同的身份与事件口径不是承诺某个现成仪表盘能自动算出业务回报。如果部分助手运行在外部平台也不用强求所有数据搬到一起。可以先定义稳定助手 ID 和最小事件模型再从 GitHub、内部运行时或其他系统汇总。来源字段必须保留否则同名事件的含义很容易混淆。上线统计前先拿一周数据回答三个问题同一个助手改名后能否连续追踪同一次任务是否被多个入口重复计数任务数量能否对应到一个可验证结果。三题都能回答再用这些数据支持续费、扩容或淘汰决策。GitHubhttps://github.com/zgiai/zgiGiteehttps://gitee.com/zgiai/zgi