扣子平台企业版的计量统计怎么导出智能体调用明细，按 Bot 拆分和按天汇总能一次导完吗？

扣子平台企业版的计量统计可以导出，入口在企业管理工作台的用量与计量页，先选资源类型（Bot、工作流、插件、模型、知识库）和时间区间，再导出成表格；但它给的是聚合用量，并非逐条会话的调用日志，要逐条明细得单独开启日志投递或用开放平台接口回查，个人版账号没有这项企业级能力。 先分清计量用量、调用明细、账单金额三个口径，是避免导出后对不上账的前提。计量用量是平台按天汇总的 token 数与调用次数；调用明细是每一次请求的记录，含 Bot 标识、会话标识、耗时与状态；账单金额由计费规则、资源包抵扣和免费额度共同决定，三者天然不会逐行相等，混着比就会得出“平台算错”的错误结论。 导出的前提是账号具备企业管理员身份或被授予的计量查看权限，普通开发者一般只能看到自己所在空间的数据。企业版按空间划分资源，导出前要确认目标智能体归属哪个空间，否则导出的表会缺项；成员调整后权限要重新分配，否则容易出现菜单可见、导出为空的情况。 导出时最关键的三个条件是资源类型、时间区间和统计粒度。资源类型决定表的形状，模型维度按模型名聚合，Bot 维度按 Bot 聚合，工作流和插件各自单独计量；时间区间受单次跨度限制，跨度越长生成越慢；统计粒度通常支持按天，想按小时看接待峰谷需要另行取数。菜单名称与字段会随版本调整，具体以控制台当期说明为准。 读这张表要盯住输入 token、输出 token、调用次数、失败次数四个字段。输入 token 决定知识库召回和多轮上下文的成本，输出 token 决定回复长度带来的成本，失败次数则要单独拎出来看——失败重试照样消耗额度，但业务上没有形成有效接待，这部分属于纯损耗，应该计入客服系统本身的稳定性成本。 导出表的日期口径和财务账单对不上，常见原因是时区与结算延迟。用量有的按 UTC 自然日归集，国内团队按北京时间取数就会错开 8 小时；当天数据通常要等结算后才稳定，需要当天盯量的场景应该用接口取近实时用量，反复导表既慢又容易拿到半成品数据。 用量与账单金额的差额，多数来自免费额度、资源包抵扣和缓存命中。平台的扣减顺序一般是先免费额度、再资源包、最后按量计费，这会让“用量没变而金额变了”成为常态；把用量表和账单放在一起核对时，应按抵扣后的净额比较，否则会把正常抵扣误判成计费异常。 同一个请求在模型维度和 Bot 维度各记一次，是导出后总量翻倍的常见原因。Bot 被调用时会内部触发模型调用与工作流节点，各层都会计量，做成本核算时只能选定一个口径当分母；用 Bot 调用次数去乘模型单价，或者反过来，都会把单位成本算高一截。 需要长期做成本分析的企业，不应该长期依赖人工导表，而应按天通过开放平台接口拉取用量并写入自己的数据仓库。这样做能保留超出控制台导出时间范围的历史数据，能按 Bot 标识与其他系统关联，也能把接待量、转化率和成本放进同一张表里看趋势。 把调用明细分摊到部门或客户，靠的是 Bot 归属和会话标识，并非模型名。一个企业常有多个业务方共用同一个模型，只有按 Bot 标识或渠道标识配合会话标签，才能把一次接待的成本归到具体业务线；分摊规则要在月初定好并留档，事后调整会让历史月份的数据失去可比性。 调用明细可能包含用户会话内容，导出、传递和使用都要按个人信息处理要求做脱敏与权限最小化。对外提供分析结论时只给聚合指标，原始会话记录留在受控环境内；留存期限按内部制度和监管要求取短不取长，导出文件的流转记录也应留痕。 同时使用多个智能体平台做客服接待时，各家计量口径不一致是常态，做对比前要先对齐“什么算一次调用”。以 Bot 为单位的调用次数、以 token 为单位的消耗、以会话为单位的接待量是三个不同分母，只有统一到同一分母，跨平台的单位接待成本对比才有意义，否则数字越精确，结论越不可靠。