用Codex给OpenClaw做了个大手术

自从Minimax退订后，一直用的是公司自建的模型，智谱5.1和Ds4-flash，都还是200K的上下文。平常用在Openclaw执行已有的技能还是没有问题的，但是随着Openclaw版本升级，各种记忆配置文件越来越复杂后，其实一直运行不畅，之前让Minimax优化也解决不了问题，还老是限流，也因为这个原因，投诉很久终于取消了订阅，后用自建模型，尽管都说ds4-flash有多牛，但实测，仍然不能解决我在openclaw使用中遇到的大部分问题。

在看了国内各大模型的各种评测和产品吐槽后，还是选择了GPT，毕竟claud已经无底线的风控我们了，而GPT还处于灰色地带，限制没有这么严，不过订阅plus也是废了大周章，又是美区账号，又是礼品卡，还要用解码平台。不过好在最后成功订阅，第一时间用codex给我的openclaw做了个诊断，codex确实还是牛，每个问题都是一次性解决，找的又准又快，以下内容就是订阅PLUS后做的一次大手术。

问题表现

某智能体使用 199K 上下文、16K 最大输出模型时出现：

Auto-compaction could not recover this turnCompaction timed out

目标会话从 2026-08-21 16:21 左右开始。日志时间线显示：

根本原因

模型上下文和 reserveTokensFloor 实际均已正确加载：

contextWindow = 199000maxTokens = 16000effectiveReserveTokens = 50000promptBudget = 149000

问题不是“没有触发自动压缩”，而是压缩成本和保留策略不合理：

1. 1. keepRecentTokens: 50000 保留内容过多；
2. 2. maxHistoryShare: 0.7 允许历史占据的上下文比例过高；
3. 3. 第一次压缩记录的切点没有有效删除足够多的旧消息；
4. 4. qualityGuard.maxRetries: 1 会在摘要质量不达标时再请求一次模型；
5. 5. 第二次压缩正好撞上 timeoutSeconds: 300；
6. 6. 飞书每会话队列还有约 300 秒放行上限，旧任务未终止时新消息可能并发，产生 Session changed while starting work。

解决方法

没有简单扩大超时时间，而是减少每次压缩需要处理和保留的内容：

{  "mode": "safeguard",  "timeoutSeconds": 300,  "reserveTokens": 16384,  "reserveTokensFloor": 50000,  "keepRecentTokens": 20000,  "maxHistoryShare": 0.5,  "model": "DeepSeek-V4-Flash-0731",  "qualityGuard": {    "enabled":true,    "maxRetries": 0  },  "midTurnPrecheck": {    "enabled":true  }}

核心变化包括：

• • keepRecentTokens 从 50,000 降至 20,000；
• • maxHistoryShare 从 0.7 降至 0.5；
• • 质量检查保留，但重试次数从 1 降至 0；
• • 压缩模型改为响应更快的 Flash 模型；
• • 保留 50,000 token 的全局安全预留，避免影响大输出模型；
• • 对已经恢复失败的会话使用 /new，而不是反复在损坏映射上执行 /compact。

当前结果

新参数已经写入当前配置。它从根本上降低了压缩输入和二次请求成本，但仍需用新的长会话验证压缩是否稳定落在 300 秒以内。

同时形成了使用原则：连续处理大量文章或包含很多大工具结果时，不应长期复用同一会话；每批任务或约 5～10 个大对象后应开启新会话。

二、web_fetch 在 WSL 中无法稳定访问外网

问题表现

智能体使用 web_fetch 时出现：

• • Google 请求超时；
• • Bing 和百度能返回，但搜索质量差或进入验证码；
• • 部分站点出现 404；
• • 某些域名被判定为私网或特殊地址并拦截；
• • Clash TUN 切换期间还影响了飞书长连接。

根本原因

Gateway 进程虽然继承了：

HTTP_PROXY=http://127.0.0.1:33210HTTPS_PROXY=http://127.0.0.1:33210

但当时未设置：

tools.web.fetch.useTrustedEnvProxy

该版本默认值为 false，因此“Gateway 能走代理”不等于“web_fetch 会使用代理”。WSL 直连 Google 会超时，而经 33210 代理可以正常返回。

另一类拦截：

Blocked: resolves to private/internal/special-use IP address

来自 SSRF 安全保护。Clash TUN 或 fake IP DNS 可能把公网域名解析为特殊地址，因而触发拦截；这不是工具崩溃。

解决方法

开启：

"tools": {  "web": {    "fetch": {      "enabled":true,      "useTrustedEnvProxy":true    }  }}

该设置让 web_fetch 使用受控的 HTTP/HTTPS 环境代理，同时继续保留 SSRF 防护。

修复后对 wuzhao 的一个真实会话进行了复查：

这说明代理修复已经生效，剩余失败主要是上游瞬时波动、404、验证码或正文解析限制。

当前结果

web_fetch 当前已启用并使用可信环境代理。后续调用策略仍应限制为：

• • 搜索阶段最多使用少量查询和单一搜索源；
• • 只抓取 3～5 个权威原文链接；
• • 搜索结果页限制在约 6,000～8,000 字符；
• • 正文页面限制在约 12,000～20,000 字符；
• • 单个超时请求只重试一次，并更换来源；
• • 不要无限重试验证码和不可提取页面。

三、Web Search 实际未启用

问题表现

智能体为了“搜索”，直接使用 web_fetch 抓 Google、Bing、百度或 DuckDuckGo 的搜索结果页面，造成大量重复请求、验证码、raw HTML 和上下文浪费。

根本原因

当前配置为：

"search": {  "enabled":false,  "provider": "gemini"}

同时没有发现已经配置可用的 Gemini、Google、Brave、Exa 等搜索凭据。Google 插件虽在 allowlist 中，但并未形成可用的标准搜索链路。

解决方法

本轮只完成能力边界审计，没有擅自启用外部搜索服务：

• • web_search：根据关键词发现网页，当前不可用；
• • web_fetch：读取已经知道 URL 的网页，当前可用；
• • Browser：适合 JavaScript、登录态和反爬页面。

当前结果

Web Search 仍未启用。后续需要先选择 provider、配置凭据，再开启 tools.web.search.enabled 并做真实查询验证；不能只把 enabled 改为 true。

四、飞书 WebSocket 批量重连

问题表现

多个飞书账号会在同一时刻批量打印：

[ws] reconnectunable to connect to the server after trying 1 timestimeout of 15000ms exceeded

排障过程中发现，单纯改变 NO_PROXY 或只限制 active-memory 都不能解释所有 reconnect。

根本原因一：active-memory 同步阻塞

active-memory 在主回复前同步运行记忆子智能体。旧配置允许一次记忆查询阻塞 60 秒，实际曾出现：

active-memory task timed out after 166552msembedded run timeout随后多个 WebSocket reconnect

它既会增加主回复延迟，也会在多智能体并发时放大网关压力。

根本原因二：memory-core dreaming 全量后台任务

即使 active-memory 暂时只保留 main，凌晨仍出现 reconnect。进一步对齐日志后发现：

• • 03:00 左右启动 Memory Dreaming Promotion；
• • dreaming 会处理全部 11 个 workspace；
• • 03:09 事件循环利用率达到 0.994；
• • P99 延迟约 12.8 秒，最大延迟约 84.8 秒；
• • 同一秒 11 个 WebSocket reconnect；
• • 健康监控随后统一重启 10 个断开的飞书连接；
• • 后续还出现 Gateway RSS memory pressure。

memory-core dreaming 不受 active-memory.config.agents 限制，所以“只给一个 Agent 开 active-memory”不能阻止它遍历全部 workspace。

根本原因三：代理不能稳定维持飞书 WebSocket

去掉 Feishu 域名的 NO_PROXY 后，TCP 连接确认经过 127.0.0.1:33210。普通模型 HTTPS 持续正常，但飞书 WebSocket 仍每隔数分钟成批握手超时。

这表明代理的普通 HTTPS 能力正常，但 WebSocket CONNECT、空闲连接保持或连接回收策略存在偶发问题。

因此最终结论是两类 reconnect 并存：

1. 1. 伴随事件循环或内存压力的批量重连，来自网关内部记忆任务阻塞；
2. 2. 不伴随网关阻塞、只有 15 秒握手超时的重连，来自代理长连接路径。

解决方法

限制 active-memory

当前稳定性参数为：

{  "allowedChatTypes": ["direct"],  "queryMode": "message",  "promptStyle": "precision-heavy",  "timeoutMs": 15000,  "cacheTtlMs": 30000,  "circuitBreakerMaxTimeouts": 2,  "circuitBreakerCooldownMs": 300000,  "persistTranscripts":false}

治理原则是：

• • 不再把整个会话交给记忆子智能体，只使用当前消息；
• • 超时从 60 秒收紧到 15 秒；
• • 连续两次超时后熔断 5 分钟；
• • 使用缓存避免相同问题重复调用；
• • 逐个 Agent 开放，不一次性恢复全部智能体。

排障中曾只保留 main 做隔离试验，其他智能体暂时不经过 active-memory。

关闭自动 dreaming

当前配置为：

"plugins.entries.memory-core.config.dreaming.enabled":false

这不会关闭 Ollama embedding、Memory Search、索引或 active-memory，只停止凌晨自动遍历全部 workspace 的记忆整理。需要晋升记忆时可手动执行：

openclaw memory promote --agent main --apply

保持代理问题独立观察

不再通过反复切换 NO_PROXY 混合排障。关闭重负载记忆任务后，如果仍有单纯的 15 秒 WebSocket 握手超时，应单独更换或调整支持稳定 WebSocket 长连接的代理出口。

当前结果

网关内部的两项主要负载源已经得到限制：active-memory 被收窄并设置熔断，自动 dreaming 已关闭。

代理路径的偶发 WebSocket 握手超时尚不能视为彻底解决，需要继续按日志类型区分观察。不能再把所有 reconnect 都归因于 Ollama、NO_PROXY 或 active-memory 中的某一个。

五、Ollama 已配置但没有真正成为 Embedding Provider

问题表现

配置中已有：

"memorySearch": {  "provider": "ollama",  "model": "bge-m3"}

但日志提示：

memorySearch.provider="ollama" is configured,but no loaded plugin registered a memory embedding provider

记忆搜索因此退化为 FTS/关键词搜索。

根本原因

Ollama 服务和模型本身没有问题：

• • 127.0.0.1:11434 正常监听；
• • bge-m3 已安装；
• • /api/embed 成功返回 1024 维向量。

真正原因是 OpenClaw 内置的 Ollama 插件虽然存在，但不在 plugins.allow 中，plugins.entries 也没有启用它，因此 embedding adapter 没有注册。

解决方法

将 ollama 加入插件白名单并启用：

"plugins": {  "allow": ["ollama"],  "entries": {    "ollama": {      "enabled":true    }  }}

重启后验证插件加载和向量接口，并对使用该 provider 的 Agent 重建索引。

当前结果

当前配置已经满足：

plugins.entries.ollama.enabled = trueplugins.allow 包含 ollamamemorySearch.provider = ollamamemorySearch.model = bge-m3

Ollama embedding provider 已正常加载，不再退化为仅关键词检索。

六、记忆索引的正确恢复流程

问题表现

需要明确以下两个命令的区别：

openclaw memory index --force --agent anget1openclaw memory status --index --agent agent2

原因

两者都会触及索引，但目的不同：

更换 embedding provider、模型、scope 或分块方式后，旧索引身份可能不兼容。OpenClaw 不会自动把全部历史重新嵌入。

解决方法

形成了逐步恢复流程：

1. 1. 先确保 Ollama provider 已加载；
2. 2. 对准备启用记忆的 Agent 执行 memory index --force；
3. 3. 用 memory status --deep 验证；
4. 4. 再把该 Agent 加入 active-memory；
5. 5. 每次只增加一个 Agent，观察超时和 reconnect 后再扩大范围。

当前结果

main 已执行过完整索引重建。当前 active-memory 只作用于 main；如果后续恢复其他 Agent，应继续遵循“先建索引、再加入、单个观察”的流程。

七、某智能体执行 /status 没有可见回复

问题表现

执行 /status 后收到：

⚠️ This reply completed without visible content. The turn may have been interrupted; please retry or ask me to recover from recent context.

日志显示：

visible channel turn dispatched with no queued reply payloadssent no-visible-reply fallbackreplies=0

根本原因

channels.feishu.allowFrom: ["*"] 只控制普通消息是否允许进入，不授予所有者级斜杠命令权限。

配置中已经显式存在 commands.ownerAllowFrom，因此 /status 会单独校验命令所有者。该智能体对应的id当时不在名单中，命令处理没有形成可见回复。

解决方法

将以下 ID 加入 commands.ownerAllowFrom：

feishu:ou_2faa862ada05323211faaa9e09c4bc

随后重启 Gateway，使需要重启的配置真正生效。

当前结果

当前 owner 列表已包含该 ID，Gateway 当前进程启动于 2026-08-28 22:50。还需从对应飞书账号执行一次 /status 做端到端回归。

九、某智能体长任务沉默

问题表现

当天日志中观察到：

• • 5 次主会话约 300 秒后被逐出；
• • 14 次长时间运行警告；
• • 2 次中止信号；
• • 3 次队列过载或故障转移错误；
• • 用户至少两次主动询问“进度呢”。

根本原因

原规则以模型的耗时预测为主：预计超过 10 分钟则委派，预计超过 5 分钟则汇报。它的问题是：

• • 外部 API、浏览器、构建、测试和重试耗时无法提前可靠预测；
• • 规则只在开始时判断，任务中途扩大后没有升级动作；
• • OpenClaw 的委派提示不会自动迁移已经运行的主会话；
• • 主会话最终撞上飞书 300 秒队列、工具等待和上下文压力。

解决方法

将 angent1/AGENTS.md` 改成“任务形态预判 + 运行中升级”。

开始前遇到以下形态应直接委派：

• • 多文件、多对象或批处理；
• • 调研、实现、测试等多个阶段；
• • 构建、测试、后台进程或外部等待；
• • 多个外部 API、模型、OCR 或 Browser；
• • 可以明显拆成独立部分。

运行中出现以下信号必须升级：

• • 命令仍在运行、出现 PID 或后台进程；
• • 已连续调用约 4 次工具且仍有后续阶段；
• • 进入第二轮实现、测试或修复；
• • 出现重试、超时、过载、上下文压力或长运行警告；
• • 任务范围明显扩大。

升级时记录检查点、委派剩余工作、向用户报告状态并结束当前飞书回合。进度更新改为事件触发，5 分钟只作为最大静默上限。

当前结果

旧的时间预测规则已被替换，无需重启 Gateway。该修改解决的是决策机制，仍需通过后续真实长任务统计逐出次数、主动进度率和用户追问次数。

十、Browser 从预启动附加改为按需托管

问题表现

原 Browser 只连接 Windows Chrome 的：

http://127.0.0.1:9222

且使用 attachOnly: true。只有 Windows Chrome 已经以 CDP 模式启动时才能使用。

根本原因

唯一 Profile 是外部附加型，OpenClaw 不负责浏览器进程生命周期。环境中其实已有 WSL Chrome 和 WSLg，但没有配置成托管 Profile。

解决方法

改成双 Profile：

"browser": {  "enabled":true,  "defaultProfile": "openclaw",  "profiles": {    "openclaw": {      "executablePath": "/usr/bin/google-chrome",      "attachOnly":false,      "headless":true,      "cdpPort": 17254,      "color": "#FF4500"    },    "windows-chrome": {      "cdpUrl": "http://127.0.0.1:9222",      "attachOnly":true,      "color": "#00AA00"    }  }}

默认使用 OpenClaw 托管的 WSL Chrome；确实需要 Windows 登录态时，显式选择 windows-chrome。

配置校验中解决的三个错误

1. 1. defaultProfile、profiles 错放在 plugins.entries.browser：它们必须位于根级 browser；
2. 2. 显式 Profile 缺少 color：当前 schema 要求提供颜色字符串；
3. 3. 托管 Profile 只有 executablePath：当前 schema 仍要求 cdpPort 或 cdpUrl，因此增加空闲端口 17254。

当前结果

配置已经通过 JSON 校验，Gateway 已重启并加载。还需完成一次冒烟测试：在没有预启动 Chrome 的情况下访问测试网页，确认 Chrome 进程和 17254 端口按需出现。

总结

三个任务合并后可以看到，OpenClaw 的主要问题并非来自单个配置项，而是多个边界互相叠加：

• • 上下文压缩既受 token 保留策略影响，也受模型速度和飞书 300 秒队列影响；
• • 飞书 reconnect 既可能来自代理长连接，也可能来自记忆任务导致的事件循环阻塞；
• • 配置了 Ollama provider 不代表插件已经注册；
• • Gateway 有代理环境不代表 web_fetch 默认使用代理；
• • 技能文件存在不代表某个 Agent 实际能发现并正确路由到它；
• • 流式输出只能改善展示，不能替代任务拆分、超时治理和主动进度。