你的 AI Agent 真的在受控运行吗？¶

Ch04.338 你的 AI Agent 真的在受控运行吗？¶

📊 Level ⭐⭐ | 7.5KB | entities/openclaw-agent-observability-session-logs-otel-sls.md

深度分析¶

1. 城墙与哨兵：重新理解 AI Agent 安全模型

传统后端服务的「受控」依赖确定性行为——代码审查能预判所有执行路径。但 AI Agent 的本质差异在于行为非确定性：同样的用户输入，模型可能产生完全不同的工具调用序列。

这意味着预防性控制（城墙，如工具策略管道、Owner-only 封装、循环检测器）永远无法覆盖未知绕过与逻辑性误用。OpenClaw 60 天代码审计数据显示，日均安全修复约 2.45 个，Critical + High 风险占 34%，风险集中于 tools/ + gateway/ 目录（61%）。

可观测性是唯一出路：不是替代城墙，而是作为哨兵补盲区。Session 审计日志回答「做了什么、花了多少」，应用日志回答「系统哪里异常」，OTEL 遥测回答「当前状态如何」。

2. 三条数据管道的分工与联动

OpenClaw Gateway 的三条数据管道来自三个独立生产者，各自承担不同审计职责：

Session 审计日志（SessionManager → JSONL）：每轮对话完整结构化数据，含工具调用、参数、Token 消耗。用途：安全审计、成本归因、行为分析。
应用运行日志（tslog Logger → JSONL）：网关、子系统层面的运行状态。用途：WebSocket 未授权、HTTP 工具调用被拒、认证失败等事件定位。
OTEL 遥测（diagnostics-otel 插件 → OTLP/HTTP）：Metrics + Traces 直推。用途：实时监控、告警、卡死会话检测。

阿里云 SLS 作为统一存储，其 SPL 算子对 JSON 嵌套字段解析便捷，安全与合规能力强（RAM 权限管控、敏感数据脱敏）。

3. Session 审计日志的四大核心场景

Session 审计日志的核心价值在于还原完整行为链。

第一个场景是敏感数据外泄检测：通过正则匹配工具返回结果中的私钥、密码、AK 标识等。第二个场景是 Skills 调用审计：追踪 SKILL.md 文件的读取行为，防止提示词工程资产被窃取。第三个场景是高危工具监控：exec、write、edit、shell、apply_patch 等 Gateway HTTP 默认禁止的工具调用必须被标记。第四个场景是成本归因：按 Provider/Model 统计 Token 消耗，支持会话级成本分析。

这四个场景共同构成了 AI Agent 的安全审计基础架构，覆盖数据泄露、资产保护、权限滥用和成本失控四类核心风险。

4. 多源联动的根因定位路径

异常发现到根因定位的标准路径：

OTEL Metrics 发现异常（延迟飙升/Token 激增/错误率突增）
  → 应用日志定位时间窗口错误详情（Webhook 超时/认证失败/网关异常）
    → Session 审计日志还原完整工具调用序列、模型交互内容与成本消耗
      → 确认根因并留存审计证据

这条链路的核心逻辑是：Metrics 负责发现、App Logs 负责定位、Session Logs 负责证明。三源缺一不可，否则要么发现不了问题，要么发现了但无法定位，要么定位了但举证不了。

5. Summer Yue 案例的警示：上下文窗口压缩是隐形威胁

Meta 超级智能实验室 AI 对齐总监 Summer Yue 向 OpenClaw 下达「未经批准不得操作」限制后，由于上下文窗口压缩机制，关键安全指令被「遗忘」，大量邮件被永久删除。

这个案例揭示了一个根本性设计缺陷：安全边界不应该是隐式上下文，而应该是显式策略。Session 审计日志能记录「做了什么」，但无法防止「忘了什么」。这需要从 Agent 架构层面解决——将安全策略与模型权重解耦，存入独立存储而非依赖上下文保持。

实践启示¶

1. 为每个 Agent 实例部署三条数据管道

不要只依赖「能用」的基础日志。从一开始就将 Session 审计日志、应用运行日志、OTEL 遥测三条管道全部接入。可观测性不是事后补救，是架构设计的必要组成部分。参考 OpenClaw 的 SessionManager 模式，将每轮对话的完整结构化数据持久化到 JSONL 文件。

2. 建立高危工具白名单与强制审计规则

在 OpenClaw 安全实践中，「Gateway HTTP 默认禁止」和「ACP 必须显式审批」的分级策略值得借鉴。将 exec、shell、write、apply_patch 等高危工具纳入白名单管理，所有调用必须记录调用方、会话 ID、时间戳、参数。

3. 用 SLS SPL 构建敏感数据外泄检测规则

参考文中提供的 SPL 查询模板，针对你的业务场景扩展正则模式：数据库连接字符串、API 密钥、业务敏感字段。SPL 的 JSON 嵌套字段解析能力能覆盖大多数结构化日志场景。

4. 将上下文压缩风险纳入安全威胁模型

参考 Agent 记忆系统对比的分析，窗口压缩导致的「遗忘」问题需要在架构层解决。安全关键指令应存储在独立策略引擎中，而非依赖模型上下文保持能力。

5. 设计「Metrics → App Logs → Session Logs」联动告警

不要让三个数据管道孤立运行。设计告警规则：当 OTEL Metrics 触发 Token 激增告警时，自动关联同时间窗口的 App Logs 定位根因，再通过 Session Logs 还原完整行为链。这是 AI Agent 运维从「能用」走向「可信赖」的标准路径。