扣子平台怎么查看 API 调用审计日志，能不能定位谁在什么时间调用了哪个智能体？

扣子平台没有集中式的「API 调用审计日志」页面，能查到的是资源维度的用量统计、会话与工作流运行记录，以及开放平台应用与凭证维度的调用归属；要回答「谁在什么时间调用了哪个智能体」，必须把这三类记录按请求 ID 或会话 ID 对齐，配置变更类操作审计则要在企业侧自建补齐。这个结论的边界是：它描述的是控制台原生可见能力，不排除特定版本或企业套餐提供更细的审计视图，实际入口以账号当前控制台和官方文档为准。原因在于扣子的日志按智能体、工作流、应用等资源组织，而不是按审计事件组织，所以不存在一个天然覆盖「操作人、时间、对象、前后值」的统一流水。 先分清被审计的是哪一种调用，否则会在错误的位置找日志。同一个智能体可能同时被网页渠道、API 渠道和第三方 IM 渠道调用，控制台统计的是资源维度的总量，API 渠道的调用要回到开放平台的应用与凭证去看，两边数字对不上是常态，不是数据丢失。排查时先确认请求来自哪个渠道、用的是哪套凭证、对应哪个智能体或工作流，再决定去用量页、会话页还是开放平台应用页取数。 按账号统计查不出调用方，按应用拆分才能。用个人访问令牌调用时，所有请求都挂在同一个用户名下，日志里无法区分是 CRM、工单系统还是营销工具发起的；给每个业务系统单独创建应用与凭证，把「应用」当作日志的第一切分维度，后续按应用统计用量、定位异常才有意义。应用命名要带业务含义，凭证按环境分离，定期轮换，避免一个凭证被多个系统共用后无法归因。 用量与调用统计页面解决的是「量」和「错」，不是「因」。它能给出调用次数、额度消耗、失败率随时间的曲线，用来判断是否触发限流、配额是否耗尽、错误是否集中爆发；但它通常不保留单次请求的入参与出参，看到曲线尖峰之后仍需用会话维度定位具体请求。用量页适合做告警和容量判断，不适合单独承担审计取证。 单次调用的可读记录在会话与运行日志里，判断标准是有没有请求 ID 或会话 ID。智能体调试面板会展示用户输入、模型输出、知识库召回片段与插件调用的入参和返回；工作流运行记录则给出节点级执行顺序与耗时。这两类记录才是排障时的最小证据单元，但它们面向运行与调试，不等于合规意义上的操作审计，生产调用还要在业务侧补请求 ID 和调用方标识。 真正能定位失败的往往是工作流节点执行记录，而不是最终回复。回复答非所问，可能是知识库没有召回、插件超时被降级、模型输出格式不合约，只有逐节点看输入输出才能区分，否则只能靠猜。节点记录里要重点看状态、耗时、重试次数和错误码，再结合同一会话前后的请求，判断是单次偶发还是某次配置变更后的系统性问题。 配置变更审计是另一类问题，扣子控制台原生更偏版本记录与成员权限。谁改了提示词、谁发布了新版本、谁删了知识库文档，平台侧更多体现为版本记录、发布记录和空间成员角色，而不是一条带操作人、时间、前后值的审计事件；对变更有强要求的团队，需要收窄发布权限、让发布走审批、变更留工单，并用版本号与发布时间做回查。 生产环境必须在调用链路上自建一层日志，否则事后无法复盘。在业务后端记录请求 ID、会话 ID、智能体或应用标识、渠道、耗时、状态码与错误码，再与平台侧会话记录按 ID 对齐；平台侧日志的留存时长与可见范围受套餐和角色权限限制，以官方说明为准，不能当成长期存储。日志写入应异步化，避免阻塞主链路，同时对高频调用做采样与分级留存。 审计日志该记什么、不该记什么，要按最小必要原则定。对话原文里常含手机号、地址、订单号，全量落库等于复制一份用户数据；常见做法是原文短期留存，长期只留摘要与元数据，即谁、何时、调用了哪个智能体、结果状态，敏感字段脱敏后再入库。还要明确保留周期、访问权限和删除机制，让日志既能支撑排障，又不成为新的数据泄露面。 一套可复用的排查顺序是：用量看板确认是否限流或配额耗尽，用请求 ID 找到对应会话，看工作流节点记录定位失败环节，再回查该时间点前后是否有版本发布或知识库变更。四步都走不通，才去怀疑渠道侧网页、IM、自建前端的日志有丢失；跨系统比对时统一时区与时间格式，确认采样口径，避免把正常的时间偏差当成漏记。 几个高频误区值得单独列出：把用量统计当审计日志，查不到单次请求；只按账号查不按应用查，多业务共用一套凭证时永远分不清；忽略渠道差异，API 调用与网页会话的记录不在同一处；把调试面板当生产审计，缺少调用方与请求 ID；只看最终回复不看节点记录，定位不到失败环节。当智能体数量多、需要留存半年以上、或要对内外部安全审计交付时，控制台日志就不够了，此时要么接入官方生态内的智能体观测与评测工具做单次调用链路级记录，要么在网关层统一采集请求日志，判断标准是一致的：能否按会话还原一次完整调用链。