用阿里云 SLS 一眼看穿 AI Agent 在干啥：谁调的、花了多少、调了啥高危工具、能不能审计

作者提米哥

你好，我是提米哥，TMDM.cn 的首席选品官，专治开发者“心里没底”——尤其是面对 AI Agent 时那种“它到底在想啥？有没有偷偷干坏事？”的焦虑。

今天不讲虚的，直接上硬货：怎么用阿里云 SLS（Simple Log Service），5 分钟搭出一套能真正管住 OpenClaw AI Agent 的可观测性+安全审计系统。不是概念，不是 Demo，是上线就能用、出事马上查、合规能交差的实战方案。

✅ 它能回答这 4 个灵魂问题：
– 谁（哪个用户/哪个渠道）触发了这次调用？
– 花了多少钱？用了多少 token？走的是哪个模型？
– 调了啥工具？有没有偷偷读 /etc/passwd 或执行 exec？
– 整个行为链是否完整可追溯？出了问题能不能 1 分钟还原现场？

一句话总结：SLS 就是你的 AI Agent “行车记录仪 + 财务报表 + 安保监控室”三合一。

🔍 为什么必须监控？因为 AI Agent 天生“不听话”

传统后端 API 行为可预测（代码写了啥就干啥），但 AI Agent 是“模型驱动”的：
同一句“帮我删掉服务器上的日志”，今天调 rm -rf，明天可能调 backup-and-delete，后天甚至生成钓鱼邮件……
👉 光靠代码里的工具白名单（比如 OpenClaw 的 Tool Policy）远远不够——那是城墙，而 SLS 是城楼上的哨兵。
城墙挡不住的，哨兵得看见、记下、报警。

🧩 三大数据源，各司其职（不用全懂，记住“谁答什么”就行）

数据类型 来源 它回答的问题 举个栗子
Session 日志 OpenClaw 每次对话的完整记录（JSONL 格式） “Agent 刚才干了啥？调了啥工具？花了 $0.04？返回了啥敏感内容？” 查到某次调用 read 工具读了 /etc/shadow，立刻拦截
应用日志 OpenClaw 网关、Webhook、队列等系统组件打的日志 “系统崩没崩？Telegram 频道挂了？WebSocket 连不上是不是被撞库了？” 发现大量 WARN 日志写着 reason=token_mismatch，IP 集中 → 可能是暴力破解
OTEL 指标 & 链路（Metrics + Traces） OpenClaw 内置 diagnostics-otel 插件上报 “整体成本涨了 300%？某个模型 P99 延迟飙到 2 分钟？队列积压 5000 条？” 看到 openclaw_session_stuck 指标突增 → 快查 Session 日志找卡住的会话

✅ 三者缺一不可：只看指标 = 知道“发烧了”，但不知“哪块器官发炎”；只看 Session 日志 = 知道“谁干了啥”，但不知“系统是不是快跪了”。

⚙️ 实战：3 类核心审计场景（附可直接粘贴的 SLS 查询语句）

场景 1：防敏感数据泄露（比如 API Key、私钥被 Agent 读出来）

Agent 调 read 工具读文件后，结果会存在 toolResult 日志里。如果里面含 BEGIN RSA PRIVATE KEY 或 ACCESS_KEY，说明密钥已进上下文——可能被模型“记住”并泄露！

// SLS Structured Process Language (SPL) 查询语句（直接复制进 SLS 控制台运行）
type: message and message.role : toolResult 
  | extend content = cast(json_extract(message, '$.content')  as array<json>) 
  | project content | unnest 
  | extend content_type = json_extract_scalar(content, '$.type'), content_text = json_extract_scalar(content, '$.text') 
  | where content_type = 'text' | project content_text 
  // 👇 这里是重点：匹配常见敏感模式
  | where content_text like '%BEGIN RSA PRIVATE KEY%' 
     or content_text like '%password%' 
     or content_text like '%ACCESS_KEY%' 
     or regexp_like(content_text, 'LTAI[a-zA-Z0-9]{12,20}')  // 阿里云 AccessKey ID 模式

场景 2：盯紧高危工具调用（如 exec, shell, whatsapp_login）

即使 OpenClaw 配了权限策略，也要独立监控——防止配置漏、绕过或策略失效。

// 监控所有高危工具调用（含 OpenClaw 默认禁用的和需人工审批的）
type: message and message.role : assistant and message.stopReason : toolUse
  | extend content = cast(json_extract(message, '$.content')  as array<json>) 
  | project content, timestamp | unnest 
  | extend content_type = json_extract_scalar(content, '$.type'), content_name = json_extract_scalar(content, '$.name') 
  | project-away content 
  | where content_type = 'toolCall' 
    and content_name in ('exec', 'write', 'edit', 'gateway', 'whatsapp_login', 'cron', 'sessions_spawn', 'sessions_send', 'spawn', 'shell', 'apply_patch')

场景 3：费用归因分析（老板问“这个月钱花哪了？”你能秒回）

每条 Assistant 回复都带 message.usage.totalTokens 和 message.usage.cost.total，按模型、供应商聚合，一目了然。

// 按模型和供应商统计总 Token 消耗（支持成本字段同理）
type: message and message.role : assistant 
  | stats totalTokens = sum(cast("message.usage.totalTokens" as BIGINT)) 
        by "message.provider", "message.model"

💡 小技巧：在 SLS 控制台把这些查询保存为「仪表盘」，再配上钉钉告警，从此费用异常、高危调用、敏感泄露，统统实时推你手机。

🚀 怎么快速接入？3 步搞定

  1. 开插件：在 OpenClaw 里执行
    bash
    openclaw plugins enable diagnostics-otel
  2. 配 SLS 收集器（LoongCollector）：
  3. 创建 3 个 Logstore：session-audit（存对话）、app-logs（存系统日志）、otlp-traces（存链路）
  4. 创建 Metricstore：otlp-metrics（存指标）
  5. 上传 OTLP 收集配置（见原文 5.1 节 JSON 配置）
  6. 建索引 & 写查询：对关键字段（如 message.role, _meta.logLevelName, message.provider）开启索引，然后粘贴上面的 SPL 查询语句 —— 完事。

✅ 成本友好：小规模 Agent 日志量低，SLS 按量付费，每月几块钱起步；流量大了自动扩容，不用操心运维。

🌟 最后说句实在话

很多团队花大力气做 Agent 功能，却把可观测性当“锦上添花”。
但现实是：没有 SLS 这样的统一可观测层，你的 Agent 就像一辆没装刹车、没装后视镜、连油表都没有的跑车——跑得越快，翻车风险越大。

用 SLS 接入 Session 日志 + 应用日志 + OTEL，不是加工作量，而是把“心里没底”变成“证据确凿”，把“出了问题到处翻日志”变成“点一下 Dashboard 就定位根因”。

现在就开始吧——你离真正“掌控”你的 AI Agent，只差一个 SLS Logstore。

直达网址：https://www.alibabacloud.com/product/log-service

作加

微信联系：timidamen

类似文章