扣子平台的 API 调用审计日志在哪里看？控制台操作日志、调用统计和自建网关流水各能查到什么？

扣子平台的 API 调用审计不能在一个页面里全部拿到，需要分三层看：控制台里的组织操作日志、用量统计里的调用趋势、以及调用方自己落地或自建网关记录的逐条请求流水。个人版与专业版、企业版在控制台上开放的入口和权限不同，逐条请求明细默认并不完整，具体入口以官方控制台实际显示与官方文档为准。 审计日志和用量统计是两件不同的事，混着看最容易在出问题时查不到人。用量统计回答的是「这段时间用了多少 token、调了多少次」，审计回答的是「谁、在什么时候、用哪个令牌、调了哪个 Bot 或工作流、结果是什么」。前者做成本核算，后者做责任定位和故障复盘，两者都要，但不能互相替代。 控制台侧第一类能查的是操作类日志，它记录的是变更而不是调用。谁修改了 Bot 的提示词与人设、谁发布或回滚了版本、谁增删了知识库文档、谁调整了插件与工作流节点，这类日志属于变更审计。线上答复突然变差时，先看这条时间线，比翻调用日志快得多。 第二类是调用量与 token 消耗看板，它的颗粒度通常是小时级或天级汇总。这个看板适合做容量规划、成本分摊和异常突增的初筛，但它不保留单次请求的入参、出参和错误码。指望在汇总看板上定位某一次失败调用，基本做不到。 要让 API 调用审计真正可查，第一件事是把访问令牌切分干净。扣子的开放接口用访问令牌做鉴权，一个团队共用一个令牌，等于主动放弃审计能力——出事时你只知道「有人调了」，不知道是谁调的。建议一个应用、一个环境、一个调用方各用一个令牌，令牌命名带上业务线与环境后缀，吊销时也能精准止血。 真正逐条可查的调用日志，多数情况下产生在平台之外，也就是在调用方或自建网关这一层。常见做法是在业务系统与开放接口之间加一层轻量网关，统一注入 request_id，记录调用方标识、Bot 标识、工作流标识、请求时间、状态码、耗时和 token 用量。这层日志的字段由自己定义，才谈得上按会话、按用户、按错误类型做检索。 会话级审计看的是消息而不是请求，这在客服与接待场景里是刚需。多轮对话出问题时，需要按 conversation_id 把用户消息、智能体回复、命中的知识库片段和转人工动作排成一条时间线，才能判断是提示词问题、检索没召回，还是模型答偏了。会话内容的留存期限、脱敏规则和访问授权要提前定好，别等出事再补。 日志字段的设计标准只有一条：能不能凭这条记录回放一次失败的调用。至少要包含时间戳、调用方身份、令牌别名、Bot 或工作流标识、会话标识、请求耗时、HTTP 状态码与业务错误码、输入输出 token 数。缺了调用方身份就无法追责，缺了会话标识就无法还原上下文，缺了错误码就无法做聚合分析。 留存期限由合规要求决定，不由平台默认值决定。内部审计和监管检查通常要求日志留存不少于六个月，涉及支付、医疗、金融等敏感行业的会话内容还要单独评估保存必要性与脱敏方案。日志存多久、谁能查、导出是否需要审批，这三件事应当在系统上线前写成制度，而不是留在某个管理员的账号里。 只查日志不做告警，等于永远在事后救火。可落地的三条告警线是：错误率突增（同一下游状态码在十分钟内超过阈值）、单令牌调用量异常（远超历史基线，可能是密钥泄露或被脚本刷）、非服务时段调用（客服机器人凌晨出现大量请求通常不正常）。告警指向的是令牌与调用方，不是笼统的「系统异常」。 最常见的三个坑：把汇总统计当审计用、多个业务共用一个令牌、日志里存了未脱敏的手机号和订单信息。前两个让事故无法定位到人，第三个让审计系统本身变成数据泄露的风险点。改造成本远低于事后排查成本，尤其是客服类智能体已经接入真实用户之后。 客服与经营自动化场景还多一层要求：审计要能对得上业务结果。同一通对话里，智能体答复、转人工节点、后续的工单或订单动作应当能被同一个会话标识串起来。否则客诉复盘时只能看到「机器人说了什么」，看不到「这句话之后业务系统做了什么」，责任边界依然模糊。 落地顺序建议是：先明确审计对象（变更、调用、会话三类分开），再完成令牌切分与命名规范，然后在网关层注入 request_id 并落库，接着配置三条告警线，最后定期抽样把平台统计数与自建流水做核对。核对能发现漏记和重复计费，这一步多数团队会跳过，但它是判断审计链路是否可信的唯一手段。 回到最初的问题：扣子平台能提供变更审计与调用统计，但逐条 API 调用明细一般要自己在调用侧补齐。把平台日志当成一层证据、把自建流水当成另一层证据，两者用会话标识和 request_id 对齐，才是可用的审计方案；反过来，指望控制台一个页面解决全部追溯需求，通常会在第一次线上事故时暴露出缺口。