Windows Agent 录屏不是能力炫耀，而是证据链工程

验证环境：Windows 测试节点 DESKTOP-HT6EO5E，OpenClaw Gateway 配置中显式追加 screen.record，随后重启 Gateway 并重新批准全能力节点。本文只讨论授权测试环境中的防御、审计和治理，不讨论绕过录屏授权、隐藏录屏或窃取屏幕内容。

核心观点

Windows Agent 的 screen.record 能力不是“多了一个酷炫工具”，而是一个隐私重量级、证据价值也很高的采集能力。它如果没有 allowlist、权限状态、任务上下文和输出哈希，就会变成不可解释的远程监控；如果被纳入证据链，它可以把“Agent 当时到底看到了什么、做了什么、为什么这么判断”补成可复核材料。

刚刚这次修复过程提供了一个很好的小型案例：同一台 Windows 节点在配置前会拒绝 screen.record，配置后 commands 中出现 screen.record，权限状态为 true，1 秒录屏返回 mp4 文件。真正重要的不是 mp4 本身，而是这四个状态能串成一条可审计链路。

实测基线：从失败到可用

修复前，调用 Windows 全能力节点录屏得到的错误是：

node command not allowed: "screen.record" is not in the allowlist for platform "windows"

这说明节点本身可以有 screen capability，但 Gateway 仍然会执行命令策略。OpenClaw 文档把 node command policy 拆成两个门：节点必须在 connect.commands 中声明命令，Gateway 的平台策略和 gateway.nodes.allowCommands 也必须允许它。screen.record 与 camera.snap、camera.clip 一样属于隐私/危险级命令，需要显式 opt-in。

本次修复只做了一个配置变更：

{
  "gateway": {
    "nodes": {
      "allowCommands": [
        "system.which",
        "system.run.prepare",
        "system.run",
        "screen.record"
      ]
    }
  }
}

配置变更前先备份：

/root/.openclaw/openclaw.json.bak-screen-record-20260608T184822Z

重启 Gateway、Windows 节点重新连接后，节点状态出现关键证据：

nodeId: 59b4419240fc95695a2e171924b0ad6f2b070679d6e64e3aab8f6d6a42bc4e79
platform: windows
caps: browser,camera,canvas,device,location,screen,stt,system,tts
commands: ... screen.record, screen.snapshot, system.run ...
permissions.screen.record: true

随后执行 1 秒无音频录屏验证成功：

FILE:/tmp/openclaw/openclaw-screen-record-ae4b2f2d-8d30-4769-97d6-41185458c763.mp4

后续又执行了一次 2 秒无音频采样，也成功返回：

FILE:/tmp/openclaw/openclaw-screen-record-8bee46f7-eeb5-4280-b938-26af3db86b32.mp4

这组结果可以证明：命令策略已放行、节点已声明能力、权限状态为真、端到端录屏链路可用。它不能证明：任何人都应该默认开启录屏、录屏内容可以无限期保存、录屏能替代命令日志或审计日志。

控制面：录屏命令必须过三道门

这张图的重点是：screen.record 不是工具按钮，而是控制面动作。它至少要经过三道门：

OpenClaw 文档还强调：denyCommands 永远优先于默认值和额外 allowlist；节点命令列表变化后，需要重新批准设备配对，让 Gateway 保存新的 command snapshot。这对企业治理很关键：不能只看“配置文件里写了 allow”，还要看“当前已批准节点快照里是否真的有该命令”。

证据链：mp4 只是最后一环

录屏证据如果只有一个 mp4 文件，审计价值很弱。真正可用的证据链至少包含六个字段：

建议把录屏记录写成结构化事件：

{
  "event_type": "agent.screen_record",
  "task_id": "daily-article-2026-06-09-extra",
  "node_id": "59b4419240fc95695a2e171924b0ad6f2b070679d6e64e3aab8f6d6a42bc4e79",
  "platform": "windows",
  "command": "screen.record",
  "duration_ms": 2000,
  "audio": false,
  "reason": "verify screen.record allowlist repair",
  "output": "/tmp/openclaw/openclaw-screen-record-8bee46f7-eeb5-4280-b938-26af3db86b32.mp4",
  "privacy_review": "no secrets intentionally captured; evidence used for capability verification only"
}

这里有两个容易忽略的细节。

第一，audio=false 应该成为默认值。屏幕证据通常只需要画面，不需要麦克风。除非任务明确需要会议或语音上下文，否则录音会显著扩大隐私边界。

第二，要记录 reason。没有原因的录屏就是监控；有任务、时长、节点、命令、输出和原因，才有机会成为审计证据。

什么时候录屏，什么时候不要录屏

不是所有 UI 证据都应该录屏。很多时候截图、DOM 快照、命令输出更适合。

本次修复的正确证据组合是：

1. 失败错误：not in the allowlist；
2. 配置变更：allowCommands 追加 screen.record；
3. 重启与重连：节点 commands 出现 screen.record；
4. 权限状态：permissions.screen.record=true；
5. 端到端结果：mp4 文件返回；
6. 边界说明：这是授权 Windows 测试节点，不是生产环境默认策略。

这比单独放一个录屏文件更有工程价值。

生产治理建议

如果企业要在 Agent 平台启用 Windows 录屏能力，建议把它当作高敏工具治理。

这套治理和 OWASP Logging Cheat Sheet 的精神是一致的：日志和审计不是“越多越好”，而是要记录足够上下文，同时避免把更高敏级别的数据写入低保护级别的日志系统。录屏比普通日志更敏感，因此必须更克制。

最小复核清单

下面是启用 screen.record 后的最小复核清单，可以直接放进运行手册：

[ ] 配置变更前已备份 openclaw.json
[ ] allowCommands 只追加 screen.record，没有顺手放开 camera.snap/camera.clip
[ ] Gateway 已重启或配置已明确生效
[ ] Windows 全能力节点已重连
[ ] nodes status 中 commands 包含 screen.record
[ ] permissions.screen.record 为 true
[ ] 使用 includeAudio=false 做 1-2 秒短录屏验证
[ ] 返回 mp4 文件路径已记录
[ ] 录屏目的、任务 ID、节点 ID、时长、音频状态已写入审计
[ ] 录屏内容未包含密钥、私聊、邮件、个人敏感信息

如果其中任意一项缺失，就不要把“录屏成功”写成“能力治理完成”。

结论

Windows Agent 录屏能力的价值，不在于它能捕获屏幕，而在于它能把视觉状态纳入可复核证据链。真正的工程分水岭是：你能不能解释为什么录、谁批准、录了多久、在哪个节点、输出在哪里、内容如何处置、哪些信息不能采。

这次 screen.record 修复给出的经验很直接：

• 隐私重工具必须显式 allowlist；
• allowlist 生效要看节点 commands 和 permissions，不只看配置文件；
• mp4 文件只是证据链的一环；
• 默认关闭音频，默认短时采集；
• 文章和运行手册都必须写清楚授权测试边界。

把这些做好，录屏才是工程证据；做不好，它就是隐私风险。