Agent 说“已完成”，不一定代表文件读到了、工具执行成功了。OpenClaw 的 Gateway 是接收运行请求的后台服务；会话轨迹则按顺序记录一轮任务里的工具调用和结果。这里说的可观测性，就是用状态、日志和会话记录找到任务卡在哪一步。下面用一份虚构的闭店简报，比较一次正常读取和一次故意读错文件。
Gateway 显示请求结束，会话轨迹则显示读取失败
你需要准备
| 用途 | 准备 | 时间与费用 |
|---|---|---|
| 看已有运行状态 | 已安装并配置过 OpenClaw；能打开终端 | 约 5 分钟；只查看状态和记录 |
| 复做本机示例 | Ollama、OpenClaw 和一个支持工具调用的本地模型 | 本次两次模型运行约 2 分 27 秒；不调用云端模型 API，模型会占用电脑内存和电量 |
| 练习资料 | 包里的虚构闭店简报 | 不含真实顾客、订单或账号信息 |
下载本机练习包，里面有虚构简报、两条提示词、配置步骤和本次脱敏结果。
先分清三处记录
| 你要确认什么 | 看哪里 | 它能回答什么 |
|---|---|---|
| Gateway、渠道和会话当前如何 | openclaw status --all | 当前诊断快照。它不展开某次工具的完整执行过程 |
| Gateway 收没收到请求、服务是否报错 | openclaw logs | Gateway 文件日志；加 --follow 可边运行边看，加 --json 可读结构化记录 |
| 这一次 Agent 具体做了什么 | openclaw sessions tail | 会话中的提示、工具调用、工具结果和结束状态 |
一条 Gateway 请求返回成功，只能说明这一轮请求正常结束。要确认任务有没有做成，还要看会话里的工具结果和最终产物。
用只读简报做一次检查
练习包里只有一份虚构小店简报：营业收入 1,280 元、售出咖啡 32 杯、3 笔预订未确认。先按包内 README 建立独立的 profile（配置和会话记录与日常实例分开），只开放工作区内的只读 read 工具；然后在一个终端里启动 Gateway：
openclaw --profile s173-demo gateway run另开终端运行一次成功读取和一次缺失文件练习。练习命令和提示词都放在包内，模型只开放读取工作区文件；不要把真实订单或顾客资料放进练习目录。
开始前看一眼整体状态：
openclaw --profile s173-demo status --all在第三个终端跟着看 Gateway 日志：
openclaw --profile s173-demo logs --follow --json看到要检查的运行后按 Control-C 停止跟随。若只想查看最近记录，可以去掉 --follow，并用 --limit 200 限制条数。
接着列出最近会话：
openclaw --profile s173-demo sessions --active 60 --json从结果里复制这次运行的完整 session key（OpenClaw 用它区分每一轮会话），再查看轨迹：
openclaw --profile s173-demo sessions tail --session-key 'agent:main:explicit:s173-demo-missing' --tail 80把示例中的 session key 换成你刚才运行得到的值。需要找的是 tool.result（工具返回结果）那一行，而不是只看最后一行结束状态。
看结果时先定位哪一层出了问题
本机 Gemma4-12B 的成功读取耗时约 48 秒；故意读取不存在的文件约 99 秒。这是各一次的本机示范，耗时会随模型、电脑负载和配置变化，不能用来估算其他环境的速度。
| 练习 | 会话轨迹 | 最终回答 | 诊断 |
|---|---|---|---|
| 读取 daily-close.md | read ok | 引用 1,280 元、32 杯、3 笔预订；手续费标为未提供 | 文件读取成功，回答可回到原文核对 |
| 读取 missing-close.md | read error | 文件不存在，并建议检查文件名 | Gateway 请求和 Agent 会话都正常结束，但读取这项工作失败 |
第二次运行的轨迹大致是：
tool.call read
tool.result read error
session.ended success这正是容易误判的地方。session.ended success 表示 Agent 正常结束了这一轮；它不会把前面的 read error 自动变成成功。此时应该检查路径或文件名、工作区范围和读取权限，再重新运行。不要只看回复里有没有“已完成”。
如果连 Gateway 日志都读不到，先确认 Gateway 在运行，并核对当前 profile 的认证设置。本次新建的练习 profile 在配置认证前运行 openclaw logs，CLI 明确报了 Gateway 凭据缺失；设置独立 token 后，日志命令才正常返回。这属于日志连接或认证问题，不是缺失文件造成的。
如果你要确认微信、Telegram 等渠道是否连通，不能拿会话列表代替在线检查。会话列表只说明本地保存了哪些对话；按需使用 openclaw channels status --probe 做渠道探测。本次练习没有配置消息渠道，因此没有测试真实渠道连接、投递或回执。
分享诊断前先检查内容
openclaw status --all 是只读诊断，适合作为排查摘要。原始日志和会话记录可能带有工具摘要、错误、网址、粘贴内容或命令输出。即使工具会遮盖部分密钥，也先删掉顾客信息、内部链接、文件路径和账号标识，再把记录发给同事或支持人员。
给客户维护 Agent 时，可以把这套检查做成一份定期报告：记录版本、Gateway 状态、渠道探测结果和失败会话，再列出需要客户确认的修复项。报价按检查频率、渠道数量、响应时间和是否包含修复来定，不要把单纯的本机演示说成生产监控。
工具清单
- OpenClaw：负责接收任务、安排 Agent 工具调用并记录会话；开源软件，需先安装和配置 Gateway。
- Ollama：在本机下载和运行模型；本次只把虚构练习请求发到本机服务。模型文件需要磁盘空间，实际内存占用因模型和上下文而异。
- 还没配置本机练习环境，可先看本站的《OpenClaw 本地部署教程：连接 Ollama 模型》。要了解 Agent 如何处理未提供的信息，可以继续看《Agent 为什么会自信地答错？》。
来源与范围
本次使用 OpenClaw 2026.10.1、Ollama 0.35.1 和本机 Gemma4-12B，使用虚构简报，在独立 profile 中只开放工作区内的 read 工具，没有配置聊天渠道或真实业务。openclaw sessions tail 的轨迹确认了一次 read ok 和一次 read error；Gateway 日志显示请求结束，但没有代替会话轨迹解释读取为何失败。启动期间有可选的远程目录检查被本机网络安全策略拦截或超时；没有做整机网络抓包，也没有测试多用户权限、云端 Gateway 或真实消息渠道。
OpenClaw 的日志和会话命令会随版本变化；升级后先运行 openclaw logs --help、openclaw sessions --help 和 openclaw status --help，再按当前输出调整命令。