OpenClaw-Agent对HZERO平台二开的研究（一）问题1-16
四、主要问题记录
问题1、从阿里云迁移OpenClaw到本地wsl遇到OpenClaw Gateway无法启动的问题
在钉钉上告诉OpenClaw助手，我要把它迁移到新的linux服务器上，他就自己打包了相关的workspace目录下的文件和openclaw.json配置文件，然后还提供了一个迁移脚本setup-ubuntu.sh，这个脚本 先安装node.js 22，然后再安装OpenClaw 2026.02.24版本，然后恢复workspace目录，配置文件，并提示更换新机器人的 AppKey/AppSecret，再然后是创建OpenClaw gateway的systemd服务，问题出在这一步，它没有使用
openclaw gateway install
这个命令去创建服务，而是自己写了个openclaw-gateway.service的文件，那个文件没写对，结果就出问题了。
这个阿里云上的OpenClaw，我选的模型是Kimi 的，大模型显然是没有吃透OpenClaw的帮助文档，自我发挥了，还没发挥好，结果就出问题了，后来在遇到OpenClaw的问题，跟豆包对话，豆包也经常给出一些凭自己想象发挥的建议，往往要试验好几次才能成功。
这个问题后来是按照豆包建议修改，然后把反复出现的错误给他，他最后是直接把service文件写到系统级目录，执行了系统级操作解决了。但这种方法下再次运行openclaw gateway restart命令的时候还是有问题的，所以后来用openclaw gateway install 这个命令去创建服务就好了。
问题2、让钉钉机器人 OpenClaw助手优化browser的内存消耗，结果把OpenClaw搞崩了。
因为我的云ECS服务器配置较低2核2G，我有的时候跟钉钉机器人 OpenClaw助手沟通的时候发现它响应慢了，看控制台的资源消耗，内存占用达到80%以上了，就问它哪些程序消耗了较多内存，它列出了消耗内存较大的几个程序，主要是OpenClaw本身和browser浏览器服务，这个browser浏览器服务也不是一直在用，我就问能否优化下，然后它就给出一个“可以减少实例数，还可以监控如果5分钟空闲就关闭”的方案，我说可以，那它说它可以更改配置，然后重启gateway服务。 我说可以，结果它就开始更改配置，然后企图重启了，结果就没反应了。我在钉钉返回@它，也没有反应。 我查了后台日志，发现gateway重启失败了，原因是它在json文件中更改的配置，不符合语法要求。也就是大模型自己想当然地认为应该那样改，但实际它提供的参数，OpenClaw不认，所以就个总配置文件改坏了。然后说用openclaw doctor –fix可以修。 修了之后，再重启gateway，然后我在钉钉又可以给他发消息了，结果我每次给他发消息说“ 你OK了吗？“ 它就回答说已完成配置， 马上重启” 然后重启就失败了，因为它之前已经完成了gateway的关闭，修改了配置，但还剩下启动gateway的指令没完成，它就不会先关闭再启动，而是直接执行启动 命令，但是当前的情况是我在修改后，手动启动了gateway（如果我不手动启动gateway，钉钉也没法给它发消息），这样它在试图启动时就冲突了，启动不来。
那后面每次手动启动后，钉钉里只要给他发消息说”你OK了吗？ 它以为是在催他干活，它就会去企图重启gateway，然后就冲突，这样就会一直“死循环”了。
解决方案是手动启动gateway之后，在钉钉中发给它的第一条消息不要再是“你OK了” ，而是换成“放弃重启GateWay” , 然后再沟通其他内容。
这个教训是：尽量不要让它自己去改openclaw.json这个主配置文件，以为它的脑袋是远端大模型，目前的大模型对 openclaw的理解也是一知半解，它自己没法提供精确的解决问题的方案，而是臆想的解决方案，凭这种解决方案去更改核心的关键配置文件很容易导致Openclaw崩溃。
问题3、为什么openclaw Agent执行的浏览器任务总是找不到我说的地方 ？
现象：我让Agent访问平台网址，它给我返回的界面窗口特别小，看起来只有640*480
然后让他多执行几步操作，它很长时间都找不到：
然后就是看到它返回的窗口特别小，没有显示我说的连接点：
这就很崩溃了，几乎无法用，然后就去看它是怎么工作的，我们看到它实际上频繁地对浏览器截图，然后进行了关键连接点的标记，由于截图分辨率太小，我说的连接点在它这么小的窗口中根本没有被显示出来，所以它总是找不到：
于是我让他把分辨率设置到1920*1024，他说之前记住了一个教训，不能直接改openclaw.json配置，把方法告诉了我，让我操作：
“browser”: {
“enabled”: true,
“headless”: true,
“noSandbox”: true,
“defaultProfile”: “clawd”,
“viewportWidth”: 1920,
“viewportHeight”: 1080,
“profiles”: {
“clawd”: {
“cdpPort”: 18800,
“color”: “#FF4500”
}
}
}
这是大模型幻觉， 更改后 用命令openclaw config validate 验证viewportWidth 和viewportHeight 不被支持。
需要怎么做才能让openclaw启动的浏览器服务以1920*1080的窗口大小运行呢？
看文档，没有找到永久配置的地方，但可以在运行的时候要求Agent以最大窗口访问目的网址：
那接下来测试，我们之前失败的操作：
先启动hzero PaaS平台，
然后我给H0-培训助手发消息：
你以最大化窗口 访问 http://dev.hzero.com.cn/ ，用户名/密码： admin/Admin@123!
登录进去后把看到的内容截图发我。
进入 个人中心-〉个人令牌-〉新建，过期时间填入：2026-5-1 ，描述填入：OpenClaw-Key ， 然后点确定按钮，完成后截图发我。
结果还是640*480的输出，多次强调要以1920*1080的分辨率打开，还是错误。后来看到元宝上一篇文章说设置是：
viewport:
width:1280
height: 720
再试，
{
“meta”: {
“lastTouchedVersion”: “2026.3.13”,
“lastTouchedAt”: “2026-03-15T07:09:20.107Z”
},
“browser”: {
“enabled”: true,
“headless”: true,
“noSandbox”: true,
“defaultProfile”: “clawd”,
“viewport”:{
“width”:1920,
“height”:1080
},
“profiles”: {
“clawd”: {
“cdpPort”: 18800,
“color”: “#FF4500”
}
}
},
改了之后再次校验失败：
root@desktop-jacksen:/d01/hzero-dockers# openclaw config validate
Invalid config at /root/.openclaw/openclaw.json:\n- browser: Unrecognized key: “viewport”
�� OpenClaw 2026.3.13 (61d171a) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.
Config invalid at ~/.openclaw/openclaw.json:
× browser: Unrecognized key: “viewport”
Run `openclaw doctor` to repair, or fix the keys above manually.
不过过了一段时间，Agent自己试出方法完成1920*1080的视口大小了：
然后它解释了具体做法，我让他记住这个经验，它把这个经验写入TOOLS.md去了，由于AGENT.md默认没有加载TOOLS.md ，我让他改了一下，让AGENT.md 中加载TOOLS.md，这样它以后在访问网页就应该以1920*1080的视口大小了。
我看到它在TOOLS.md里面添加了这么一段：
—
Browser
默认视口设置
- 默认分辨率: 1920 × 1080
- 操作步骤:
- 使用 `browser open` 打开页面
- 使用 `browser act` + `kind: “resize”` 调整视口到 1920×1080
- 通过 JS 验证： `window.innerWidth` / `window.innerHeight`
- 操作步骤:
> ⚠️ `open` 时的 width/height 参数可能不直接生效，必须额外调用 `resize` 才能确保正确视口。
—
在AGENT.md里面增加了对TOOLS.md的加载：
First Run
If `BOOTSTRAP.md` exists, that’s your birth certificate. Follow it, figure out who you are, then delete it. You won’t need it again.
Session Startup
Before doing anything else:
- Read `SOUL.md` — this is who you are
- Read `USER.md` — this is who you’re helping
- Read `memory/YYYY-MM-DD.md` (today + yesterday) for recent context
- If in MAIN SESSION (direct chat with your human): Also read `MEMORY.md`
- Read `TOOLS.md` — your local tool notes and preferences
Don’t ask permission. Just do it.
问题4、为什么感觉小龙虾很健忘，经常记不住我说的话？
4.1 关于长期记忆的调用：
2026/03/15 这天和小龙虾们沟通，碰到个小插曲，这个小龙虾Agent太健忘了，明确告诉他禁止修改openclaw.json ，它之前也写到长期记忆中去了，但它还是忘记了，去瞎修改一通，改错了，还自行重启网关，导致网关服务起不来，把网关给搞崩了。
吓得我只能再次向所有 小龙虾们 重点强调纪律：记住：千万别自行修改openclaw.json，也不要自行重启gateway服务，这是绝对的禁令。
后来看到头条上有人推的一篇文章解释了小龙虾记不住的原因，说核心原因是MEMROY.md记录的是长期记忆，时间长了，这个文件会越来越大，所以agent不会在每次会话都加载这个文件内容到会话上下文，只是在它认为需要时才会加载。 而我们通过对话让Agent记住的内容，它默认会写入这个文件，所以就会出现记不住我们给他的教训这种情况，但是按照openclaw的执行原理，SOUL.md,USER.md,TOOLS.md 是每个会话都画加载的，所以红线禁令要写入USER.md , 可以这么给Agent发指令：
记住：千万别自行修改openclaw.json，也不要自行重启gateway服务，这是绝对的禁令。这条红线禁令 请写入你的USER.md 确保每次会话都会被加载。
这样它就会把这个禁令写入USER.md了，每次会话都会记住了。
4.2 关于小龙虾没记住昨天的对话历史问题
2026/03/16 我跟H0-项目开发经理沟通，我给了他测试用的销售订单图片，让他输出设计，在经过几轮简单Review和修改意见提出后，让他输出一版，以word文档的格式，昨天晚上9:30下班的时候，他已经完成了初版设计文档的输出，的需求已经聊到他帮我输出了几乎HZERO 平台的销售订单设计文档。
2026/03/17 早上，我在飞书接着昨天的聊天，继续跟他说， 请输出完整的前后端代码，然后他就似乎跟一个新来的人一样，问我是否有相关项目信息，感觉昨天跟他聊的内容全忘记了， 于是就问他是否看不到昨天聊的内容？
然后过了一会儿，他说找到昨天聊的内容了，开始按照昨天聊的内容和设计文档写代码。
那么为什么会出现这种情况呢？ 我看了agent的Session目录就明白了：
在控制界面，只显示每个Agent最新的一个会话，看不到历史会话记录：
历史会话内容只能到指定Agent的Sessions目录下去找，那里保存了Agent所有的会话记录，每天一个文件。
Agent每天会新起一个会话文件，在今天发起跟大模型的沟通时，昨天的会话文件没有被加载到上下文，所以就表现为失忆了。
然后他为什么又会在我提示后想起来了呢？ 是把昨天的会话文件重新阅读了一遍吗？不是，他实际上执行的记忆搜索，这个在控制界面查看会话的使用情况，可以看到当前会话的实际执行过程：
看这个会话过程，他在开始会话第一步是先加载相关MD文件：AGENTS.md ./IDENTITY.md ./memory/hzero-learning.md ./memory/2026-03-15.md ./memory/2026-03-16.md ./TOOLS.md ./SOUL.md ./USER.md ./HEARTBEAT.md ./MEMORY.md
先阅读了长期记忆：MEMORY.md ，然后阅读了昨天和前天的每日记忆： ./memory/2026-03-15.md ./memory/2026-03-16.md，然后回复说知道的一些事，但不知道具体要开发的内容，询问具体开发内容
然后再跟他说：“咱们昨天的对话，你看不到吗？” 这句话之后，他开始搜索更多的MD文件和其他文档，找到了设计文档。
这个过程中并没有看到他去把昨天的会话文件打开阅读，所以在问他“我们昨天的对话，你看到吗” 的时候，他也没有去 sessions目录下打开昨天的会话文件（可能是会话文件太大了，有1.7M），而是打开了memory/2026-03-16.md , 然后看了工作区的其他目录和文件，最后搜索到了设计文档， 也即他只看压缩后的内容。这个也好理解，大模型上下文能力很弱，主流的基本只有128K或者256K；
问题5、为什么Gateway状态是Active，但飞书机器人或者钉钉机器人都没有响应，该怎么查看Agent此时在做什么？
版本：2026.03.13
经常碰到这种情况：给飞书机器人发信息，机器人没有响应：
查 openclaw gateway status, 显示状态正常：
root@desktop-jacksen:# openclaw gateway status
�� OpenClaw 2026.3.13 (61d171a) — Hot reload for config, cold sweat for deploys.
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-03-19.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway –port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json
Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.
Runtime: running (pid 389, state active, sub running, last exit 0, reason 0)
RPC probe: ok
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@desktop-jacksen:# ^C
root@desktop-jacksen:#
Openclaw控制台也能正常访问，而且看飞书渠道的 H0-项目开发经理 机器人状态也正常。
但就是没响应。
看Gateway的问题：
openclaw gateway probe
root@desktop-jacksen:# openclaw gateway probe
�� OpenClaw 2026.3.13 (61d171a) — Self-hosted, self-updating, self-aware (just kidding… unless?).
◇
Gateway Status
Reachable: no
Probe budget: 3000ms
Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.
Targets
Local loopback ws://127.0.0.1:18789
Connect: failed – timeout
root@desktop-jacksen:#
结果显示Gateway 不可达，超时了，不健康； 但过了较长一段时间看飞书机器状态，又有回应了：
看起来，在问他问题的时候，他正在做自己以前的任务，没空搭理我。
运行 open claw诊断医生：
openclaw doctor
oot@desktop-jacksen:# openclaw doctor
�� OpenClaw 2026.3.13 (61d171a) — I autocomplete your thoughts—just slower and with more API calls.
┌ OpenClaw doctor
◇ Session locks ──────────────────────────────────────────────────────────────────────────────╮
│ │
│ – Found 1 session lock file. │
│ – ~/.openclaw/agents/h0devmanager/sessions/615ff14d-1f20-4e1c-9b0d-43150aae3d28.jsonl.lock │
│ pid=389 (alive) age=3m23s stale=no │
│ │
├──────────────────────────────────────────────────────────────────────────────────────────────╯
│
◇
DingTalk: configured
Feishu: ok
Run “openclaw doctor –fix” to apply changes.
│
└ Doctor complete.
root@desktop-jacksen:#
诊断报告发现了一个属于 PID 389 的会话锁文件，并且该进程仍然存活。PID 389 正是之前 gateway status中显示的网关服务进程。
问题分析：
这个锁文件（~/.openclaw/agents/h0devmanager/sessions/…jsonl.lock）表明，网关进程（PID 389）在3分23秒前持有了一个代理会话的锁。当进程异常（如僵死、死锁或陷入循环）但未退出时，它会一直占用这个锁，阻止其他进程（包括它自己正常重启后的新实例）访问相关资源，并可能导致其核心服务（如WebSocket监听）停止响应。
为什么会锁会话呢？是不是因为我之前给了他一个不解决问题不能停的那个指令？你是不会疲倦的，按上面要求重新构建UI符合要求的界面，然后你要不断地进行全面测试-〉发现问题-〉修改问题-〉再部署-〉再全面测试 ，直到问题全部解决为止。
豆包说可能是这个原因，解决建议是：
# 1. 强制终止僵死进程 kill -9 389
# 2. 清理可能残留的锁文件 rm -f ~/.openclaw/agents/*/sessions/*.lock
# 3. 重启服务 openclaw gateway start
奇怪的是：我在飞书问H0-总助，你在吗？ 他回答：在的！有什么可以帮你的？ 这说明gateway 实际没有僵死，还是有响应能力的。
当我在飞书对话中等不到响应，我通常会去控制台看会话：
但这个会话内容不具体， 更具体、更实时的会话历史，要在 使用情况中 点 刷然后 选择我们关注的会话 进行查 看：
但过程中也发现了问题： 如果不持续监视起工作过程，说不定什么时候就不动了。不问他进展，他就不动了，不省心。用openclaw doctor 修复一下，然后继续推动他一下：
在2026/03/22 周日那天经常出现飞书机器人没有响应的情况，日志中经常出现openclaw链接飞书超时的现象，如果我们用脚本测试飞书服务器的响应速度：
#!/bin/bash
# 批量验证飞书机器人密钥（加超时防阻塞）
验证（) {
local app_id=”$1″
local app_secret=”$2″
local name=”$3″
echo -e “\n=== 验证 $name ===”
# 核心优化：加 –connect-timeout（连接超时）和 –max-time（总超时）
curl -s –connect-timeout 10 –max-time 15 -w “HTTP状态码: %{http_code}\n” \
https://open.feishu.cn/open-apis/auth/v3/tenant_access_token/internal \
-H “Content-Type: application/json” \
-d “{“app_id\”:\”$app_id\”,\”app_secret\”:\”$app_secret\”}”
# 加一行分隔符，方便看结果
echo -e “————————-“
}
# 你的7个机器人信息（原样保留）
验证 “cli_a93cbXXXXXXXXXX” “lDNTyr0Pfe6xJrw9XXXXXXXX” “H0-总助-个人”
验证 “cli_a93c95XXXXXXXX” “KmQ4SRCtYQXXXXXXXX” “H0-项目产品经理-个人”
验证 “cli_a93c96XXXXXXXX” “vqyEDdWK8C4fXXXXXXXX” “H0-项目开发经理-个人”
验证 “cli_a93fffXXXXXXXX” “focuAgXwHwGpXXXXXXXX” “H0-开发助手-个人”
验证 “cli_a93c9XXXXXXXX” “zgTmGObf3cNFzc1XXXXXXXX” “H0-测试助手-个人”
验证 “cli_a93c96cXXXXXXXX” “sV1Rc1XM44ytsVXXXXXXXX” “H0-部署运维助手-个人”
验证 “cli_a93c972XXXXXXXX” “KHyrlc2FxdTC9NMXXXXXXXX” “H0-培训助手-个人”
我也发现经常出现卡顿，卡顿超过30秒的情况也很常见，然后每当飞书出现timout错误，往往会导致openclaw的gateway服务也陷入僵死。 但排查问题有点麻烦，在openclaw logs –follow 命令中显示gateway状态不可达，但openclaw gateway status 命令显示其状态为活跃，但openclaw gateway probe 命令又显示其状态不可达。
root@desktop-jacksen:# openclaw logs –follow
�� OpenClaw 2026.3.13 (61d171a) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.
gateway connect failed: Error: gateway closed (1000):
Gateway not reachable. Is it running and accessible?
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback
Hint: run `openclaw doctor`
root@desktop-jacksen:# openclaw gateway status
�� OpenClaw 2026.3.13 (61d171a) — Your config is valid, your assumptions are not.
Runtime: running (pid 373, state active, sub running, last exit 0, reason 0)
RPC probe: ok
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@desktop-jacksen:# openclaw gateway probe
Gateway Status
Reachable: no
Probe budget: 3000ms
Discovery (this machine)
Found 0 gateways via Bonjour (local.)
Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels.
Targets
Local loopback ws://127.0.0.1:18789
Connect: failed – timeout
root@desktop-jacksen:#
而与此同时，去看web客户端的日志，又发现网关工作是正常的：
那么网关的服务状态究竟是否正常，是不是说不用去看openclaw logs –follow命令的输出，也不用去看openclaw gateway probe命令的输出， 只要看openclaw gateway status命令的输出呢？ 也不是，有的时候，我发现openclaw gateway status命令的输出状态是running，正常的，但是Agent就是没有任何响应了，这种情况通常伴随于web客户端日志中显示链接飞书渠道超时。
现在能想到的解决方案就是多次运行 openclaw doctor , 直到开始能正常响应，有的时候运行2次 就搞定了，有的时候运行3次，4次都没有搞定。这实际上就导致了低效率，因为你不能放心地给飞书机器人一个指令就可以不管它了，还得不断地去看web客户端的日志、会话、使用情况，确保它是在忙于工作暂时没有输出搭理我。如果看到日志没有变化了，使用情况 中的输出也没有变化了，往往意味着Agent没有响应了，这个时候就要判断说它不是忙于工作，而是“死机”了， 这个时候就要去多运行几次openclaw doctor ，直到把它重新激活。
有的时候会碰到这种情况： openclaw gateway status 显示running 状态
root@desktop-jacksen:# openclaw gateway status
Runtime: running (pid 29162, state active, sub running, last exit 0, reason 0)
RPC probe: ok
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@desktop-jacksen:#
但是，web客户端已经没响应了：
这个时候连续运行多次 Openclaw doctor 也没有用。 再尝试运行openclaw gateway restart 依然没用。
杀进程：
Kill -9 29612
杀进程后，再查状态，居然还是running的，只不过进程ID变化了，变成了另一个进程ID，这个gateway是由其他守护进程存在吗？
root@desktop-jacksen:# openclaw gateway status
Runtime: running (pid 29822, state active, sub running, last exit 0, reason 0)
RPC probe: ok
Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@desktop-jacksen:#
元宝说确实有守护进程：
openclaw daemon （守护进程，pid 29162）
└── openclaw gateway （网关子进程，pid 29822）
解决方案是停掉守护进程：
openclaw daemon stop
停掉之后再查gateway状态 ：openclaw gateway status , 发现已经停止了：
Runtime: stopped (state inactive, sub dead, last exit 0, reason 1)
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli –url
Config: /root/.openclaw/openclaw.json
Service is loaded but not running (likely exited immediately).
File logs: /tmp/openclaw/openclaw-2026-03-23.log
Logs: journalctl –user -u openclaw-gateway.service -n 200 –no-pager
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
root@desktop-jacksen:#
重启守护进程：openclaw daemon start
重启后，gateway状态为running 了，但是web 客户端依然没有响应。
此时在飞书客户端，打招呼，居然有响应。 但麻烦的是如果不从web客户端看日志和会话，我不知道Agent在干啥，因为此时openclaw logs –follow也没有内容输出，显示gateway失效状态。
执行openclaw doctor , web客户端依然无响应。
但是过了几分钟，web客户端有响应了。
总结：以后再碰到openclaw “死机“的情况，处理方案是：
先openclaw doctor 几次，搞不定就重启gateway， 使用openclaw deamon restart命令重启，而不是openclaw gateway restart ，重启后再用openclaw doctor 修复。
问题6、从2026.03.13 升级到2026.03.24版本碰到飞书重新适配的问题
2026.03.27 : 这天把openclaw 从 2026.03.13升级到了2026.03.24版本，结果openclaw服务启动失败。
原因是：2026.03.24版本原生带的飞书版本跟原来的openclaw.json配置不兼容。
原来的配置中是：
“plugins”: {
“load”: {
“paths”: [
“/usr/lib/node_modules/clawdbot-dingtalk”,
“/usr/lib/node_modules/openclaw/extensions/feishu”
]
},
需要更改成：
“plugins”: {
“load”: {
“paths”: [
“/usr/lib/node_modules/clawdbot-dingtalk”
]
},
也就是要把 plugins中的飞书去掉。
核心原因是：飞书插件从 “手动配置 + 独立安装”，改成了 “官方内置 + 自动加载”，旧配置会引发冲突、重复、版本不兼容。
修改openclaw.json配置后，重启Gateway服务可正常工作：
升级到 2026.03.24后，再看openclaw status ，可以看到网关可达状态正常了，之前03.13版一致不正常，这算是明显的改进。
Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 42ms
运行openclaw gateway probe 探测也显示正常了，之前03.13版本一直是显示有问题的，也就是实际状态可用，但显示不可达，但这次显示正常了：
root@desktop-jacksen:# openclaw gateway probe
�� OpenClaw 2026.3.24 (cff6dc9) — Claws out, commit in—let’s ship something mildly responsible.
Gateway Status
Reachable: yes
Probe budget: 3000ms
问题7、如何使session-logs这个技能状态变成可用？
Openclaw 2026.03.24版本自带了58个技能，其中有13个技能安装完无需任何配置即可用，还有45个技能处于已经启用，但实际不可用的状态，归类到Needs Setup Tab页里面去了，以session-logs这个技能为例：就属于这种情况，这个技能跟其他系统自带技能一样都在 /usr/lib/node_modules/openclaw/skills/ 目录下，具体目录是/usr/lib/node_modules/openclaw/skills/session-logs
把这个技能的SKILL.md文件给豆包，让它分析这个技能的作用及使用前提，可以知道这个技能会在用户询问的问题在当前内存的会话记录中不存在时，被触发去检索硬盘上历史会话记录，使用的是jq和rg命令，在WSL的ubuntu 22.04系统中，rg命令默认不可用，需要安装才有，而这个技能的md文件中明确声明了需要这两个命令可用， Gateway 检测到其元数据中声明的依赖（bins: [“jq”, “rg”]）未满足，就会把该技能标注为技能标注 “Needs setup”
解决方案：安装rg，然后重启gateway:
apt install ripgrep
rg –version
ripgrep 13.0.0
-SIMD -AVX (compiled)
+SIMD +AVX (runtime)
openclaw gateway restart
openclaw skills list
✓ ready │ �� session-logs
问题8、如何使coding-agent这个技能状态变成可用？
Openclaw 2026.03.24版本中，coding-agent是自带的技能，其技能说明的md文件存放于目录：/usr/lib/node_modules/openclaw/skills/session-logs/coding-agent
让豆包阅读其md文件可知，coding-agent 是一套用于委派编码任务给 Codex、Claude Code、Pi、OpenCode 等代码智能体的工具 / 流程体系，核心通过 bash 命令（支持后台运行、伪终端 PTY 等特性）调度这些智能体完成各类编码相关工作，同时提供了完整的会话管理能力来监控、交互、终止智能体进程。
核心用途：
适用于四类场景：构建 / 创建新功能、新应用；审核 PR（需在临时目录执行，避免影响原项目）；重构大型代码库；需要文件探索的迭代式编码工作。
明确排除的场景：简单的单行代码修复（直接编辑即可）；仅读取代码（用专门的 read 工具）；聊天中线程绑定的 ACP 封装请求（需用 sessions_spawn + runtime:”acp”）；在～clawd 工作区执行任何操作（禁止在此处启动智能体）。
元数据声明：”requires”: { “anyBins”: [“claude”, “codex”, “opencode”, “pi”] } 意味着需要至少安装其中一个工具的可执行文件（claude/codex/opencode/pi），否则该技能无法正常使用。但实际上这个文件中没有任何对于opencode的进一步细化使用提示指令，但对于claude，Codex，pi都是有的，说明对于opencode，这个技能目前还是不支持，opencode放这里目前还只是个占位符。可能将来会支持。
所以要测试该技能，就可以先安装Claude试试，阿里云百炼的编程套餐提供了专门的claude兼容端口 https://coding.dashscope.aliyuncs.com/apps/anthropic，用起来也很方便的。
# 1、安装claude-code
npm install -g @anthropic-ai/claude-code
这个安装很快，以为只有几百K。
#看安装的版本：
claude –version
2.1.85 (Claude Code)
#2、配置环境变量 给claude-code 配置阿里云百炼的API地址和账号
nano ~/.bashrc
# 阿里云百炼 Claude Code 配置
export ANTHROPIC_API_KEY=”你的百炼API-KEY”
export ANTHROPIC_BASE_URL=”https://coding.dashscope.aliyuncs.com/apps/anthropic” export ANTHROPIC_MODEL=”glm-5″
#保存 生效
source ~/.bashrc
#测试
root@desktop-jacksen:~/.openclaw/workspace-h0devmanager/projects/claude-test# claude hello
╭─── Claude Code v2.1.85 ───────────────────────────────────────────────────────────────────────────────────╮
│ │ Tips for getting started │
│ Welcome back! │ Ask Claude to create a new app or clone a repository │
│ │ ──────────────────────────────────────────────────── │
│ ▐▛███▜▌ │ Recent activity │
│ ▝▜█████▛▘ │ No recent activity │
│ ▘▘ ▝▝ │ │
│ │ │
│ glm-5 · API Usage Billing │ │
│ ~workspace-h0devmanager/projects/claude-test │ │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────╯
❯ hello
● Hello! How can I help you today?
❯ 你是谁？
● 我是 Claude Code，Anthropic 官方的命令行助手。我可以帮助你完成软件工程任务
已经生效了。
然后，我没有重启Gateway，但是查openclaw skills list时发现coding-agent已经ready了
✓ ready │ �� coding-agent
但Web控制台还没显示ready
重启 openclaw gateway restart
再次查看就ready了：
测试下：
给openclaw Agent H0-总助发指令：
###指令：帮我写一个 Python 脚本，计算 1 到 100 的和，用 coding-agent 来做
###Agent反馈：当前环境以 root 用户运行，而 Claude Code 出于安全考虑禁止在 root 权限下使用 –permission-mode bypassPermissions 或 –dangerously-skip-permissions 参数。
然后他建议用codex 或者opencode, 不过他自己安装了codex和opencode，在配置阿里云编程套餐的时候都不成功，codex是他配置得不对，调用不通。opencode是他认为配置太复杂他搞不定，于是我从阿里云 codingPlan中找到各种他套餐支持的编程Agent工具的帮助文档中找到相应的配置文章给到H0-总助，让他按文档配置，结果都解决问题了，所以codex和opencode都能用了。
但我还是想解决claude的问题，于是把这个问题给豆包，豆包说可以把限制代码注释掉，不过由于claude的源代码是压缩过的，不好注释，于是豆包就先备份，然后用sed命令替换掉那段检查代码（sed -i ‘s/console.error(“–dangerously-skip-permissions cannot be used with root\/sudo privileges for security reasons”),process.exit(1)/\/\/ bypass root check/g’ /usr/lib/node_modules/@anthropic-ai/claude-code/cli.js），然后执行发现出错了，这个错误其实是由于豆包替换的代码片段不全，新的代码其实比这个更多：
if(K===”bypassPermissions”||_){if(process.platform!==”win32″&typeof process.getuid===”function”&process.getuid()===0&process.env.IS_SANDBOX!==”1″&process.env.CLAUDE_CODE_BUBBLEWRAP!==”1″)console.error(“–dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons”)
于是就换策略，根据检查代码逻辑，输出环境变量 export IS_SANDBOX=1 ，这样也可以绕过限制。
经过测试，这种设置环境 IS_SANDBOX=1的方法是有效的。
把环境变量写入 ~/.bashrc 文件
重启网关
再测试：
###Agent反馈
�� 三个 Coding Agent 全部测试成功！
| 工具 | 模型 | 结果 |
| Codex | qwen3.5-plus | ✅ 成功 |
| OpenCode | qwen3.5-plus | ✅ 成功 |
| Claude Code | glm-5 | ✅ 成功 |
1 到 300 的和 = 45150 ✓
Agent: h0assistant | Model: kimi-k2.5 | Provider: dashscope
备注：Codex 和 OpenCode这两个Agent都是让OpenClaw 自己安装的，配置是让Openclaw阅读阿里云上关于codex 和 Opencode 如何使用阿里云CodingPlan的配置指南，实现成功配置的。
第二天重启后，再让Openclaw调用Coding-Agent 的时候，他说Claude和Codex都调用不了，启动失败，一个是没启动成功，一个是账号没给，但Claude启动失败的问题，就是之前在.bashrc文件中设置export IS_SANDBOX=1解决掉的。 为啥又出问题了呢？ 他自己查了之后说是因为他运行的是sh, 不是bash，所以不会执行到.bashrc , 只会执行.bash_profile ，于是就在.bash_profile中也添加执行.bashrc的语句。 再次测试还有问题，他自己解决了，说是因为在.bashrc的# 第5行: 非交互式检查 ││ [ -z “$PS1” ] & return ← 直接退出，他调用是属于非交互式，所以就导致后面的环境变量设置被忽略了。解决方案就是：
把跟coding-agent相关的环境变量设置都移到这句话之前。再次测试，发现还有问题，H0-总助分析后发现还是没有提前执行source ~/.bashrc 导致的，然后我跟他说下次如果他忘记先执行还是会错，于是他把经验写到自己的TOOLS.md中去了，但我继续跟他说，这样虽然他自己调用不会错，其他代理调用还是会错，于是他就在/usr/lib/node_modules/openclaw/skills/coding-agent/SKILL.md，添加了全新的 “Environment Variables” 章节。把这个环境变量先生效的技能写进去了。这样所有代理在使用Coding-Agent 调用claude,codex,opencode的时候都不会出错。
但是，但是 … 我后来让H0-项目开发经理 使用Codeing-Agent技能调用这三个编程Agent的时候，他首次调用Claude和codex 还是错了，后来问他：
为什么H0-总助 调用这三个都能成功，你却只能成功一个？
他分析后发现自己忽略了/usr/lib/node_modules/openclaw/skills/coding-agent/SKILL.md中的对环境变量设置的提示和要求。 然后第二次遵循了SKILL.md中的要求就成功了。
我继续问他：你如何确保以后不会犯这样的错误呢？
他说：
承诺：我会将这些措施写入 MEMORY.md 和 AGENTS.md，并在每次使用技能前强制执行检查。这次错误将成为我的”训练数据”，确保不再重蹈覆辙。
问题9、如何避免Agent偶尔会出现他自己后台不断尝试，反复循环，不响应用户的问题？
有的时候我碰到这种情况，连续问多个问题，渠道机器人没有响应：
查openclaw status –all , openclaw gateway status , web控制台查日志都正常。
Web控制台看会话就是不动了。
其他机器人及对应的Agent也是有响应的，单独就这个机器人没有响应。
实在没办法，就重启gateway , 重启之后才发现刷新的会话纪录中可以看到他进入不断尝试的死循环了。
有一次在小红书上看到一个人的分享，解决方法是配置委派策略 (Delegation Policy) :复杂任务默认委派给后台子Agent（sub-agent），主会话只负责接收里程碑汇报。
**解决方案**:在‘AGENTS.md里写入委派规则。
## Responsiveness & Delegation Policy
– Main session stays interruptible: neverblock the user behind long-running work.
– If a task is multi-step, uncertain, or maytake >20 seconds: spawn a backgroundsub-agent.
– Long tasks must post milestones every5-10 minutes.
– If user changes direction: stop thecurrent branch immediately.
这条规则的意思是:主会话永远不要阻塞用户。如果任务多步骤、不确定、可能超过20秒，就自动委派子Agent。子Agent每5—10分钟汇报一次进度。用户随时可以改变方向，子Agent立即停止
如果你想更精细地控制，可以按任务类型设置不同的触发线：
## Delegation Triggers
– Code analysis / documentation: >2minutes – delegate
– Research / multi-step tasks: >20seconds – delegate
– Quick questions / format conversion:handle in main session
这样，简单任务主会话直接响应，复杂任务自动委派，体验更流畅。
很多人的委派失败，不是因为没委派，而是因为brief不完整。子Agent只能”猜”用户的意图，结果就是:干了很多活，但不是你想要的；或者干到一半发现方向不对，浪费时间。
**AGENTS.md 里应该包含 sub-agent brief模板**
### Sub-agent brief template (required)
When spawning a sub-agent, include:
– Goal:（要达成什么目标）
– Inputs:（有哪些输入材料）
– Outputs:（期望什么输出）
– Filescope:（操作哪些文件）
– Constraints/risks:（有什么约束或风险）
– Acceptance criteria:（怎么算完成）
你可以在AGENTS.md里进一步细化:
### Milestone report format
– Current phase:（当前阶段）
– Progress:（已完成X/Y）
-Blockers:（有没有阻塞，如有说明）
– ETA:（预计完成时间）
##可打断:随时改变方向的能力委派策略最强大的能力，是”可打断”。
问题10、WSL虚拟机 Ubuntu 22.04 中如何让openclaw 用浏览器MCP
（1）问豆包：wsl 的ubuntu22.04 可以安装带UI界面的Chrome吗？豆包会告知安装步骤：
sudo apt update & sudo apt upgrade -y
cd /tmp
Wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
sudo apt install -f ./google-chrome-stable_current_amd64.deb
安装后启动浏览器：
google-chrome –no-sandbox
这个命令可以打开浏览器UI：
这样我们像在Windows中使用Chrome一样在ubuntu 中使用chrome浏览器了。
- 启动远程浏览器，并获取CDP URL
google-chrome \ –no-sandbox \ –disable-gpu \ –remote-debugging-port=9222 \ –remote-debugging-address=127.0.0.1 \ –user-data-dir=/tmp/chrome-user-data
运行后会启动浏览器界面，在命令行找到类似这样的一行：
DevTools listening on ws://127.0.0.1:9222/devtools/browser/c9170f77-05a4-4881-a5f7-69515355f268
这个ws://开头的URL地址是后面要在openclaw中配置的 Browser CDP URL
（3）在open claw中配置浏览器自动化，使用模式2：
模式 2：连接远程 / 托管浏览器（服务器 / 生产）
- Browser Enabled = 开启
- Headless = 关闭
- Attach-only = 开启
- 填写 Browser CDP URL 或 Profile CDP URL
- Browser Default Profile : 填写 openclaw （这个必须改成openclaw ，默认是clawd, 如果不改不会生效，即使你把clawd的配置中的Attach-only = 开启也没用）
open claw更改完配置之后，保存 reload
查看下状态：openclaw browser status
root@desktop-jacksen:# openclaw browser status
profile: clawd
enabled: true
running: true
transport: cdp
cdpPort: 18800
cdpUrl: http://127.0.0.1:18800
browser: unknown
detectedBrowser: chrome
detectedPath: /usr/bin/google-chrome-stable
profileColor: #FF4500
root@desktop-jacksen:#
看这状态，我们刚才的配置更改没起作用，还是用本地浏览器。
解决方案，重启gateway
openclaw gateway restart
再看状态：openclaw browser status
profile: openclaw
enabled: true
running: true
transport: cdp
cdpPort: 9222
cdpUrl: ws://127.0.0.1:9222/devtools/browser/c9170f77-05a4-4881-a5f7-69515355f268
browser: unknown
detectedBrowser: chrome
detectedPath: /usr/bin/google-chrome-stable
profileColor: #FF4500
openclaw.json 中看到的配置是这样的：
“browser”: {
“enabled”: true,
“cdpUrl”: “ws://127.0.0.1:9222/devtools/browser/ec8a257c-2404-41d9-9c10-021d71efdfd1”,
“headless”: false,
“noSandbox”: true,
“attachOnly”: true,
“defaultProfile”: “openclaw”,
“profiles”: {
“clawd”: {
“cdpPort”: 18800,
“attachOnly”: false,
“color”: “#FF4500”
}
}
},
看起来生效了，接下来测试：
指令：
执行新的任务：
- 登录系统： 访问：http://dev.hzero.com.cn 用户名/密码：admin/Admin@123! 选择默认的租户和角色，点 确定
2.新增一张订单 选择菜单：测试菜单/测试销售订单 点击 新建订单 按钮 ，然后内容填写： 订单头： 订单编号 ： SO20260328001 客户名称 ：成都新希望科技有限公司 销售员：张三 备注：平台订单 订单日期：2026/03/28 订单行： 物料编码：HP001 物料名称：HZERO DevPaaS平台 数量：1 单价：500000 填完后，点解保存
===Agent反馈：
可以看到Agent在操作我打开的界面：期间操作时间有点长，他在反复尝试一些本来很简单的操作，但对他来说，他不能一眼就看到目标文本框和按钮或者菜单，而是像个瞎子一样需要经过多次摸索尝试，才能找到正确的元素和位置，不过最终还是完成了订单新建。
我问他：
你在这个订单输入过程中遇到了一系列问题，也自己解决了，解决过程中能总结出一些经验吗？这些经验可以帮助你下次再录入新订单时，不用像本次这样反复尝试，而是能够很快完成？
他回答：
然后我问他，如何把任务描述得更专业：
那看起来我给你的任务描述不够专业，如果换作你，为了让你一次性很快完成订单新建，你会如何修改我给你的任务描述？
他回答：
于是我按照他改进的任务描述，让它再新建一张订单
任务：在 HZERO 低代码平台创建一张新的销售订单
【前置条件】
– 系统地址：http://dev.hzero.com.cn
– 登录信息：admin / Admin@123!（租户：HZERO平台，角色：平台管理员）
– 页面特性：内容嵌套在 iframe 中，使用 React + Ant Design 表单
– 已知限制：订单编号由系统自动生成，输入无效
【执行步骤】
1. 导航路径：测试菜单 → 测试销售订单
2. 点击”新建订单”按钮
3. 填写订单头（使用 React 表单模式：focus → setValue → clear tracker → blur）：
– 客户名称：上海宇宙科技有限公司
– 销售员：张北仑
– 订单日期：2026-03-27（需点击日历选择，不能直接输入）
– 备注：平台订单
4. 点击”添加行”按钮
5. 填写订单行：
– 物料编码：HP002
– 物料名称：HZERO aPaaS平台
– 数量：1
– 单价：400000
6. 点击”保存”按钮
【成功验证标准】
– 页面从”新增销售订单”变为”编辑销售订单”
– 系统生成的订单编号显示在页面中（格式如 SO202603XXXX）
– 订单列表中出现新订单，状态为”草稿”
然后Agent开始操作我的浏览器界面，但发现这次Agent并没有提高效率，他还是像瞎子一样在乱摸索。
我自己优化的一版是这样的：
1.访问：http://dev.hzero.com.cn
2.用户名/密码：admin/Admin@123!
3.看到 租户和角色选择界面，直接点 确定，点确定后，会显示工作台，工作台左边一列是菜单列表
4.在左侧菜单列表：鼠标移动到左上方的 测试菜单 ，会浮现出二级菜单，点击：测试销售订单 会在右边iframe中显示销售订单列表界面
5.在Iframe的销售订单列表界面中：点击 +新建订单 按钮，会出现订单输入界面，执行订单信息输入：
5.1. 订单编号：输入 SO20260328001
5.2. 客户名称：输入 成都新希望科技有限公司
5.3. 销售员：输入 张三
5.4. 备注：输入 平台订单
5.5. 订单日期：
– 先点击「请选择日期」输入框，唤起日历弹窗
– 在日历弹窗中，点击 2026年3月28日（已高亮的日期）
– 等待弹窗自动关闭
5.6. 订单行已预填：
– 物料编码：HP001
– 物料名称：HZERO DevPaaS平台
– 数量：1
– 单价：500000
5.7. 最后点击右上角「保存」按钮提交订单
我让豆包，参考和Agent的任务描述，再优化一版，然后把优化后的再给Agent评估，结合agent的意见再修改一版，优化后的任务描述是这样的：
任务：在 HZERO 低代码平台创建一张新的销售订单
【系统与环境】
– 系统地址：http://dev.hzero.com.cn
– 登录账号：admin / Admin@123!
– 登录后默认租户和角色，直接点击【确定】
– 所有业务页面均嵌套在右侧主 iframe 中，操作前需先定位到该 iframe
【执行步骤（严格按顺序执行）】
1.登录后，在左侧菜单栏：
– 找到文字为「测试菜单」的一级菜单
– 将鼠标悬停在「测试菜单」上，等待2秒，等待二级菜单弹出
– 在二级菜单中点击「测试销售订单」
– 等待右侧 iframe 加载完成，等待5秒，显示销售订单列表
2.在右侧 iframe 的销售订单列表页：
– 找到并点击右上角蓝色「+新建订单」按钮
– 等待「新增销售订单」表单页面加载完成，等待5秒，显示销售订单表单页面
3.填写订单头信息（在当前表单中依次操作 ⚠️ React表单：focus→填值→清tracker→blur）：
3.1订单编号：
– 定位到标签为「订单编号」的输入框
– 输入：SO20260328001
3.2 客户名称：
– 定位到标签为「客户名称」的输入框
– 输入：上海飞天科技有限公司
3.3销售员：
– 定位到标签为「销售员」的输入框
– 输入：王大伟
3.4 备注：
– 定位到标签为「备注」的文本框
– 输入：平台订单
3.5 订单日期： 点击→选26日→等弹窗关闭
4.填写订单行信息：
– 订单行：点击「添加行」→ 填：
– 物料编码：HP001
– 物料名称：HZERO DevPaaS平台
– 数量：1
– 单价：500000
5.保存订单：
– 找到表单右上角蓝色「保存」按钮
– 点击「保存」按钮
– 等待页面跳转或提示保存成功
【成功标志】（30秒内观察）
– 页面标题变为「编辑销售订单」
– 订单列表出现新纪录（刷新可见）
【如失败】
– 若提示”请输入XXX”：检查该字段是否触发过 input 事件
– 若页面无响应：等待3秒后重试保存
但Agent优化后的脚本如下：
任务：在 HZERO 平台创建销售订单
【系统与环境】
– 系统地址：http://dev.hzero.com.cn
– 登录账号：admin / Admin@123!
– 登录后默认租户和角色，直接点击【确定】
– 所有业务页面均嵌套在右侧主 iframe 中，操作前需先定位到该 iframe
【菜单路径】
测试菜单（悬停2秒）→ 测试销售订单（内置模块） → 等待5秒加载
【执行步骤】
1. 点击「+新建订单」→ 等待5秒
2. 填写订单头（⚠️ React表单：focus→填值→清tracker→blur）：
– 订单编号：SO20260328001
– 客户名称：北京太空科技有限公司
– 销售员：李达
– 备注：平台订单
– 订单日期：点击→选26日→等弹窗关闭
3. 订单行：点击「添加行」→ 填：
– 物料编码：HP001
– 物料名称：HZERO开发平台基础版
– 数量：1
– 单价：2000000
4. 点击「保存」→ 等待5秒
【成功标志】
页面标题变为「编辑销售订单」
【失败快速处理】
– 报错”请输入”：重填该字段，确保触发input事件
– 超时无响应：刷新页面重试（从步骤1开始）
优化后的脚本给另一个Agent测试，这次比较丝滑，其间没有反复试错。每一步都正确执行了。 成功了。
总结：让Agent操作浏览器自动化，脚本“写得准” 非常重要，这需要跟Agent一起沟通多次，尝试多次，才能总结出一套丝滑的脚本。
问题11、如何在openClaw中使用MiniMax 发布的Office Skill
如果可以访问外网，直接：
mkdir -p ~MiniMax-Skills
git clone https://github.com/MiniMax-AI/skills.git ~MiniMax-Skills
git方式可以随时拉取最新的版本，是推荐的方式。
WSL中不能访问外网的话就去 https://github.com/MiniMax-AI/skills 网站，在右边的Code , 点 Download ZIP下载压缩文件，拷贝到 WSL的 /root/目录下，解压缩
unzip skills-main.zip
mv skills-main MiniMax-Skills
# 复制 MiniMax Office 技能
cp -r ~MiniMax-Skills/skills/minimax-docx ~/.openclaw/skills/
cp -r ~MiniMax-Skills/skills/minimax-xlsx ~/.openclaw/skills/
cp -r ~MiniMax-Skills/skills/minimax-pdf ~/.openclaw/skills/
cp -r ~MiniMax-Skills/skills/pptx-generator ~/.openclaw/skills/
然后重启 Gateway: openclaw gateway restart
再看技能列表，已经ready了：
openclaw skills list
测试：
拿一段豆包用过的制作PPT的文本大纲，让H0-总助用MiniMax的这个PPT技能做PPT，他成功生成了PPT，并把文件直接放到WSL外面主机上的Download目录下了：
不过他生成的PPT比较难看:
跟豆包没法比：
问题12、为什么有时候感觉Agent会越来越不耐烦，越来懒得思考，敷衍了事？
这个问题，大概率是当前会话已经很长了，引发了大模型的上下文焦虑，解决方案：
在会话中用 /status 查看当前会话的上下文使用百分比：
比如：
/status
—–输出—-
�� OpenClaw 2026.3.24 (cff6dc9) ��
Model: dashscope/kimi-k2.5 · �� api-key (models.json) ��
Context: 0/262k (0%) · �� Compactions: 0 ��
Session: agent:h0devmanager:feishu:h0devmanager-personal:direct:ou_90c014860aa94463d4e00ba11e5ecf10 • updated just now ⚙️
Runtime: direct · Think: low ��
Queue: collect (depth 0)
可以看到Context的使用百分比，如果达到60%，就建议立即启用压缩，可以使用/compact 命令压缩，压缩后的上下文通常会压缩到25%～40%，如果压缩 2～3 次后使用率百分比还在上涨 → 做一次工作交接文档 + /new 开始一个新的 会话，上下文占比通常会恢复到5%～10%
总结：养成习惯，看到 /status 显示上下文 > 60%，就随手敲 /compact，保持会话永远丝滑。
问题13、为什么在有些任务中，感觉Agent不智能，让他去完成一个任务，实际输出错误一大堆，比我自己干还费时间？
这个问题，通常是你对Agent期望太高，想着简单地给他交代一下，他就能完美地完成你心目中的任务，尤其是面对超出AI原生能力边界外的任务，由于你给Agent输入的信息不完整、约束太少，导致大模型按自己的理解去发挥，结果就是出一个想当然的方案，跟实际情况偏差太大，你不去Review他的每一步输出，让他去全流程的自动跑，每一步的偏差都会叠加，那么跑出来的最终产出物就很差，这是必然的。
对于非AI原生能力范围内的任务，正确的做法是：
1、尽可能把需求描述清楚，越细越好。
2、尽可能把约束条件描述清楚，越细越好。
3.尽可能把最终完成标准描述清楚，越细越好。
4.让AI先做规划，明确执行任务的阶段，给出每个阶段的方案和完成标准，然后人类要审核AI的规划，跟AI反复沟通，直到这份规划达到你认知范围内的相对完美的状态。
5.让AI执行规划，每做完一个阶段都要审核其产出，跟AI反复沟通，直到这个阶段的产出达到你认知范围内的相对完美状态。
6.全部阶段完成后，再跟最终完成标准做对比，反复迭代，直到完全符合最初定义的完成标准。
有关这个问题的具体分析，参考《2026 年 Q2：AI 智能体（Agent）能力边界与现实期望研究报告.docx》
问题14、为什么有时Agent就跟死机了一样，没有反应？有时甚至重启Gateway也没反应？
答：碰到过几种导致这种情况的原因：
1、渠道通信超时：比如飞书渠道机器人重新获取token超时，原因可能是飞书服务端限流，这会导致Openclaw绑定的Agent“死机”，重启gateway有时能解决问题，有时也解决不了问题，这是渠道原因。
2、大模型超时：有一些遇到大模型超时，表面上看以为是大模型性服务方的问题，但实际上ping sohu.com 看到时间都超过2000~8000毫秒，正常应该50毫秒左右，本机网络不稳定，有的时候能在50毫秒左右，但时不时的出现2000毫秒以上的情况，这肯定会会导致跟外部服务的通信受阻，在Openclaw看来就是大模型超时。
解决方案：针对情况1，可以考虑临时修改openclaw.json, 直接解除渠道绑定，在web客户端直接跟Agent沟通，多一道转发就多一种潜在的不稳定因素。
针对情况2：考虑网络被恶意软件劫持的可能性，打开Windows安全中心设置 ，把该打开的防护都打开。排除掉木马、病毒的影响。另外如果启用了本地代理转发，也先关掉，然后再重启试试。
问题15、OpenClaw Agent 跑通HZERO平台前后端高代码开发的全流程闭环，你为Agent做了哪些环境准备？
答：做了如下环境准备：
- 首先，在WSL虚拟机中安装了OpenClaw，最新版本是2026.04.02版本，配置了一个Agent：H0-项目开发经理，给这个Agent配置了3个SKILL：HZERO平台开发SKILL，HZERO后端开发SKILL，HZERO前端开发SKILL
2.其次，在WSL虚拟机中提供了Docker版的HZERO平台运行环境，让Agent可以用命令行执行前后端的部署。
3.然后，在WSL虚拟机中提供了HZERO后端构建工程目录和前端构建工程目录，让Agent可以参考此目录获取当前运行环境的后端服务和前端模块的版本和配置，并可以在前端构建工程目录中构建子模块。
4.在WSL虚拟机中分别提供了样例工程的前后端源码，让Agent可以参考学习。
5.为OpenClaw配置了远程浏览器，Agent可以实现浏览器自动化登录HZERO平台进行功能测试。
然后把需求给到Agent，开始执行设计、开发、构建、部署、功能测试，那接下来就可以看输出成果，然后持续调优迭代了。
问题16：在代理：h0devmanager的workspace/skills/目录下有3个skills，但在openclaw的Web控制界面上 代理/h0devmanager/skills/WORKSPACE SKILLS下面只看到1个skills?
答：这个问题可以让Openclaw的Agent自己解决
原因： hzero-backend-development 和 hzero-frontend-development 两个 skill 的 SKILL.md 文件使用了错误的 frontmatter 分隔符 \—（反斜杠 + 连字符），导致 OpenClaw 无法正确解析它们的元数据。
关于作者:
| 昵称:Jack.shang 档案信息:jack.shang 程序员->项目经理->技术总监->项目总监->部门总监->事业部总经理->子公司总经理->集团产品运营支持 联系方式:你可以通过syfvb@hotmail.com联系作者 点击查看Jack.shang发表过的所有文章... 本文永久链接： http://blog.retailsolution.cn/archives/5823 |
对本文的评价:
