尧图网页设计 
OpenViking 使用量审计Usage Audit如何记录 Agent 到底用了多少上下文【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking当你把 Agent 接入 OpenViking 之后一个很现实的问题出现了Agent 到底消耗了多少上下文今天调了多少次检索Token 花在哪了OpenViking 使用量审计Usage Audit模块就是为了解答这些问题而生的——它是 OpenViking Server 内置的产品级统计与请求审计能力默认开启无需额外配置就能把 Agent 的 Token 消耗、检索次数、上下文写入活动逐日记录下来并在 Console 里以 Dashboard 形式呈现。为什么需要使用量审计 很多人做 Agent 可观测性时只盯着 QPS、延迟这类运维指标Prometheus 已经管好了。但还有一层常被忽视的产品语义数据你关心的问题对应的审计数据今天 Agent 烧了多少 Tokenvlm.call/embedding.call事件聚合检索功能用得频繁吗search.find/search.search请求统计谁在往上下文里写数据资源/技能/会话提交热力图哪个请求失败了、为什么请求审计日志状态码、耗时、错误码简单说Prometheus 告诉你系统健不健康Usage Audit 告诉你业务值不值钱。工作原理一条事件总线两个消费方 Usage Audit 最聪明的设计在于它不在 API 请求链路上同步写库而是复用 OpenViking 已有的 Observability 事件总线。数据流大致如下业务请求 / 模型调用 | v Observability Event Bus进程内事件总线 | -- Metrics subscriber运维指标 | -- Usage/Audit subscriber使用量审计 | v 后台 Worker 批量写 SQLite | v /api/v1/console/* 查询接口关键设计点非阻塞投递请求路径只做发事件绝不等待写库业务延迟零感知后台批量落库Worker 用有界队列默认 10000 批量写入默认 500 条/批每秒 flush 一次优雅降级队列满时丢弃统计事件并累计dropped_count宁可少记也不拖垮主链路优雅关闭服务停止时尽量 flush 剩余事件避免尾部审计丢失或重复写入。事件总线的实现位于 events.py审计订阅者见 subscriber.py后台批量写库逻辑在 worker.py。四类审计数据口径一目了然 1️⃣ Token 统计来自模型调用事件按小时粒度落库跨时区的今日查询可以在读端灵活切分事件展示口径vlm.callprompt_tokens→vlm_inputcompletion_tokens→vlm_outputembedding.callprompt_tokens→embedding_inputrerank.call已可落库2️⃣ 今日检索统计POST /api/v1/search/find与POST /api/v1/search/search的成功请求数Dashboard 首屏直接展示。3️⃣ 上下文提交热力图追踪四类成功写请求添加资源、添加技能、会话消息、会话 commit按日期 × 小时分桶一眼看出 Agent 什么时候在记忆。4️⃣ 请求审计日志每次 API 调用记录request_id、账号/用户、路由、状态码、耗时、错误码等信息。注意两点/metrics、/health、/api/v1/console/*等自身基础设施请求不会进入审计避免污染数据error_details经过凭据脱敏和大小限制不额外保存原始请求体、header 或堆栈——审计而不偷窥。五分钟上手配置与查询 ✅好消息是什么都不用配它就在工作。默认配置下 SQLite 文件位于 workspace 的_system/usage_audit/usage_audit.sqlite3。如果想自定义保留期、批量大小等完整配置示例{ server: { observability: { usage_audit: { enabled: true, backend: sqlite, queue_size: 10000, batch_size: 500, usage_retention_days: 14, audit_retention_days: 7, timezone: local } } } }几个值得知道的字段字段默认值说明usage_retention_days14Token/检索/热力图聚合数据保留天数0为不裁剪audit_retention_days7请求审计日志保留天数audit_retention_per_account1000每个账号保留的最新审计条数timezonelocal查询兜底时区写入永远按 UTC读端再按你的时区分桶查询入口Console 通过 4 个 BFF 接口读取审计数据仅ROOT/ADMIN角色可访问GET /api/v1/console/dashboard/summary # 首屏上下文数据量 今日 Token 今日检索 GET /api/v1/console/tokens # Token 趋势按日期范围 GET /api/v1/console/context-commits # 上下文提交热力图 GET /api/v1/console/audit # 请求审计分页查询支持状态码/api_type 筛选本地快速验证先发起一次检索请求触发数据再查 Dashboard 汇总——curl -X POST http://127.0.0.1:1933/api/v1/search/find \ -H Authorization: Bearer $OPENVIKING_API_KEY \ -H Content-Type: application/json \ -d {query:hello,limit:3} curl http://127.0.0.1:1933/api/v1/console/dashboard/summary \ -H Authorization: Bearer $OPENVIKING_API_KEY查询服务时区解析逻辑见 api_service.py表结构定义见 schema.py。常见问题速查 ️QConsole 返回enabledfalse检查server.observability.usage_audit.enabled是否为false或启动日志中是否出现Usage/Audit store initialized with sqlite backend。QDashboard 今天没有 TokenToken 只有触发vlm.call/embedding.call事件才会计入。记住数据按 UTC 写入若请求没传timezone参数会回退到 server 配置的兜底时区。Q请求日志里为什么没有 Console 自己的请求预期行为。/api/v1/console/*被排除在审计之外防止 Console 页面刷新刷爆审计表。Q生产环境多实例怎么部署当前仅 SQLite backend适合单机。多实例场景应实现UsageAuditStore协议换成共享存储而不是让各实例各写本地库。写在最后 ✨OpenViking 使用量审计用最小的架构成本一条进程内事件总线 一个后台批量 Worker把Agent 用了多少上下文这件大事变得开箱即用零侵入复用现有 observability 事件业务代码零改动⚡零延迟代价非阻塞投递 批量写库统计永不拖慢 API时区友好UTC 写入、读端分桶全球团队看同一份数据有分寸的审计脱敏 排除自身请求记录行为但不泄露隐私。完整设计说明见官方文档 Usage/Audit 使用说明相关测试覆盖在 tests/observability/ 目录下欢迎对照源码深入了解。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenViking 使用量审计（Usage Audit）：如何记录 Agent 到底用了多少上下文
OpenViking 使用量审计Usage Audit如何记录 Agent 到底用了多少上下文【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking当你把 Agent 接入 OpenViking 之后一个很现实的问题出现了Agent 到底消耗了多少上下文今天调了多少次检索Token 花在哪了OpenViking 使用量审计Usage Audit模块就是为了解答这些问题而生的——它是 OpenViking Server 内置的产品级统计与请求审计能力默认开启无需额外配置就能把 Agent 的 Token 消耗、检索次数、上下文写入活动逐日记录下来并在 Console 里以 Dashboard 形式呈现。为什么需要使用量审计 很多人做 Agent 可观测性时只盯着 QPS、延迟这类运维指标Prometheus 已经管好了。但还有一层常被忽视的产品语义数据你关心的问题对应的审计数据今天 Agent 烧了多少 Tokenvlm.call/embedding.call事件聚合检索功能用得频繁吗search.find/search.search请求统计谁在往上下文里写数据资源/技能/会话提交热力图哪个请求失败了、为什么请求审计日志状态码、耗时、错误码简单说Prometheus 告诉你系统健不健康Usage Audit 告诉你业务值不值钱。工作原理一条事件总线两个消费方 Usage Audit 最聪明的设计在于它不在 API 请求链路上同步写库而是复用 OpenViking 已有的 Observability 事件总线。数据流大致如下业务请求 / 模型调用 | v Observability Event Bus进程内事件总线 | -- Metrics subscriber运维指标 | -- Usage/Audit subscriber使用量审计 | v 后台 Worker 批量写 SQLite | v /api/v1/console/* 查询接口关键设计点非阻塞投递请求路径只做发事件绝不等待写库业务延迟零感知后台批量落库Worker 用有界队列默认 10000 批量写入默认 500 条/批每秒 flush 一次优雅降级队列满时丢弃统计事件并累计dropped_count宁可少记也不拖垮主链路优雅关闭服务停止时尽量 flush 剩余事件避免尾部审计丢失或重复写入。事件总线的实现位于 events.py审计订阅者见 subscriber.py后台批量写库逻辑在 worker.py。四类审计数据口径一目了然 1️⃣ Token 统计来自模型调用事件按小时粒度落库跨时区的今日查询可以在读端灵活切分事件展示口径vlm.callprompt_tokens→vlm_inputcompletion_tokens→vlm_outputembedding.callprompt_tokens→embedding_inputrerank.call已可落库2️⃣ 今日检索统计POST /api/v1/search/find与POST /api/v1/search/search的成功请求数Dashboard 首屏直接展示。3️⃣ 上下文提交热力图追踪四类成功写请求添加资源、添加技能、会话消息、会话 commit按日期 × 小时分桶一眼看出 Agent 什么时候在记忆。4️⃣ 请求审计日志每次 API 调用记录request_id、账号/用户、路由、状态码、耗时、错误码等信息。注意两点/metrics、/health、/api/v1/console/*等自身基础设施请求不会进入审计避免污染数据error_details经过凭据脱敏和大小限制不额外保存原始请求体、header 或堆栈——审计而不偷窥。五分钟上手配置与查询 ✅好消息是什么都不用配它就在工作。默认配置下 SQLite 文件位于 workspace 的_system/usage_audit/usage_audit.sqlite3。如果想自定义保留期、批量大小等完整配置示例{ server: { observability: { usage_audit: { enabled: true, backend: sqlite, queue_size: 10000, batch_size: 500, usage_retention_days: 14, audit_retention_days: 7, timezone: local } } } }几个值得知道的字段字段默认值说明usage_retention_days14Token/检索/热力图聚合数据保留天数0为不裁剪audit_retention_days7请求审计日志保留天数audit_retention_per_account1000每个账号保留的最新审计条数timezonelocal查询兜底时区写入永远按 UTC读端再按你的时区分桶查询入口Console 通过 4 个 BFF 接口读取审计数据仅ROOT/ADMIN角色可访问GET /api/v1/console/dashboard/summary # 首屏上下文数据量 今日 Token 今日检索 GET /api/v1/console/tokens # Token 趋势按日期范围 GET /api/v1/console/context-commits # 上下文提交热力图 GET /api/v1/console/audit # 请求审计分页查询支持状态码/api_type 筛选本地快速验证先发起一次检索请求触发数据再查 Dashboard 汇总——curl -X POST http://127.0.0.1:1933/api/v1/search/find \ -H Authorization: Bearer $OPENVIKING_API_KEY \ -H Content-Type: application/json \ -d {query:hello,limit:3} curl http://127.0.0.1:1933/api/v1/console/dashboard/summary \ -H Authorization: Bearer $OPENVIKING_API_KEY查询服务时区解析逻辑见 api_service.py表结构定义见 schema.py。常见问题速查 ️QConsole 返回enabledfalse检查server.observability.usage_audit.enabled是否为false或启动日志中是否出现Usage/Audit store initialized with sqlite backend。QDashboard 今天没有 TokenToken 只有触发vlm.call/embedding.call事件才会计入。记住数据按 UTC 写入若请求没传timezone参数会回退到 server 配置的兜底时区。Q请求日志里为什么没有 Console 自己的请求预期行为。/api/v1/console/*被排除在审计之外防止 Console 页面刷新刷爆审计表。Q生产环境多实例怎么部署当前仅 SQLite backend适合单机。多实例场景应实现UsageAuditStore协议换成共享存储而不是让各实例各写本地库。写在最后 ✨OpenViking 使用量审计用最小的架构成本一条进程内事件总线 一个后台批量 Worker把Agent 用了多少上下文这件大事变得开箱即用零侵入复用现有 observability 事件业务代码零改动⚡零延迟代价非阻塞投递 批量写库统计永不拖慢 API时区友好UTC 写入、读端分桶全球团队看同一份数据有分寸的审计脱敏 排除自身请求记录行为但不泄露隐私。完整设计说明见官方文档 Usage/Audit 使用说明相关测试覆盖在 tests/observability/ 目录下欢迎对照源码深入了解。【免费下载链接】OpenVikingSelf-evolving Context Database for AI Agents. Unify Agent Memory, Knowledge RAG and Skills.项目地址: https://gitcode.com/GitHub_Trending/op/OpenViking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考