已在跑 Gateway 的开发者把 OpenClaw 接进真实仓库后，最先撞墙的多半不是「模型叫不醒」，而是AGENTS.md、Skills 与 bootstrap 注入把上下文撑满，再叠加 memory_search 与日常 memory/*.md 混用，排障时很难判断「到底是哪一层在烧钱」。📌 本文给出六类可写进工程公约的痛点、promptMode 与 bootstrap 策略对照表、三条可与日志对齐的上下文口径、最小可用的 AGENTS.md 与配置片段、六步调参 Runbook；并与《OpenClaw 三平台安装》《doctor 装后排错》《provider 路由与降级》《Docker 网络分诊》《通道接入》互补——前序篇解决起不来与连不上，本篇解决能跑但上下文不可控。
OpenClaw 在 2026 年的运行时通常会在启动阶段注入一批仓库文件（如 AGENTS.md、Skills、身份与工具说明），并把记忆检索拆成「启动注入」与「按需搜索」两类路径。若团队没有约定哪些内容进 bootstrap、哪些走 memory_search，很快会出现：每次对话都携带巨大静态前缀、工具调用链变长、费用与延迟同步上升。建议把下列六条与近一周的 token 估算、工具失败率与平均轮次放在同一仪表板。
minimal / none 用于合适场景。memory/*.md，再依赖 memory_search 全表扫描，IO 与嵌入成本都会上升；应规定摘要进库、原文走外链或对象存储。把这六条与《Docker 网络》里的「Gateway 正常 vs 模型层失败」分层思路对齐，你会更快判断问题是上下文策略还是网络/provider。
下表用于评审：目标是同一仓库在不同任务形状下可预测的 token 上限，而不是追求「提示词写得漂亮」。具体键名以你当前 OpenClaw 版本与配置格式为准。
| 维度 | bootstrap 注入（启动期） | memory_search / memory_get（按需） |
|---|---|---|
| 典型内容 | AGENTS.md、核心 Skills 摘要、身份与工具边界 | 日期化笔记、决策记录、长文附录 |
| 失败表现 | 每轮都慢、费用高、无关前缀多 | 检索不到、命中过宽、重复读取 |
| 调参抓手 | 总字符上限、分段注入、promptMode | 索引粒度、文件命名、摘要策略 |
| 与 promptMode | full 默认注入最多；minimal 适合子代理省略非必需段 | 不替代 bootstrap；减少「为了省 token 把关键边界只放 memory」 |
| 协作约束 | 需要代码评审与版本号 | 需要保留审计字段（谁写入、何时过期） |
| 远程 Mac 场景 | 大仓克隆在云端，注意同步延迟与权限 | 高频写入要防止与本地笔记本抢写冲突 |
下列指标可用日志与粗略 token 估算采集；数值是工程占位，请用你们基线替换。
agents.defaults.bootstrapTotalMaxChars 一类上限（键名随版本变化，以官方配置为准）。memory_search 返回后被模型实际采纳的比例（可用人工抽检或二次确认标记）；MRH 过低说明索引或摘要质量欠账，MRH 过高但 BEL 也高，说明重复内容在多处冗余存放。2025–2026 周期内，多模型路由与动态上下文估算（社区 issue 方向）会继续演进；即便启用更聪明的路由，仓库侧噪声仍会直接决定上限，因此 BEL/TLI/MRH 依然值得保留。
若你在评审里需要向非开发角色解释，可把 BEL 类比成「每次对话都要先读完的员工手册页数」，把 TLI 类比成「同一件事被反复请示的次数」：两者都不解决时，加模型参数往往只是在更贵的纸上继续印同样厚的册子。
# AGENTS.md（示例：只写「永远成立」的边界，细节放 Skills 或 memory） ## 仓库角色 - 本仓库是 xxx 服务；默认分支 main；发布节奏见 docs/release.md。 ## 工具边界 - 未经评审不改 CI 密钥与生产配置；数据库迁移必须双人复核。 ## OpenClaw 约定 - Skills 目录：.openclaw/skills/（示例路径，按你们实际） - 长文决策：写入 memory/YYYY-MM-decisions.md，并在正文第一行写摘要。
注意：不要把内部客户名、未脱敏日志与完整密钥写进会被 bootstrap 的段落；若必须保留，改用按需检索并限制可见范围。
minimal 或等价策略，并记录对照实验（延迟、成功率、费用）。memory_search 热区保留全文。当现象是「偶发超时」时，团队常急于换模型或加卡；若 BEL 与 TLI 未监控，容易把噪声上下文误判为基础设施不稳。建议沿用《Docker 网络》中的分层顺序：先确认 Gateway 与通道健康，再查 provider，再查仓库侧提示词；这与《通道接入》篇的「三层分诊」一致，只是把最上层换成上下文预算。
实操上可为每次排障工单增加最小复现四元组：① 当时生效的 promptMode 与已知 BEL 区间；② 最近一次修改 AGENTS/Skills 的合并请求链接；③ memory_search 查询词与返回条数；④ Gateway 日志中与工具调用相邻的片段。四元组齐全时，多数「神秘变慢」能在半小时内判定是提示词膨胀还是下游依赖，避免在聊天频道里来回甩锅。若团队使用子代理或并行任务，请把每条分支的上下文上限写进同一台账，否则汇总视图会被「只看主会话」误导。
个人设备上的短期试验往往把大段提示词与临时密钥混在全局配置里，难以审计；一旦迁到 CI 或共享远程 Mac，目录权限与同步延迟会让 AGENTS 与 memory 出现看不见的分叉。把仓库上下文策略写清，再配合独占的远程构建/常驻环境，才能把 Agent 工作流变成可复盘、可交接的工程资产。
纯依赖碎片化云桌面或临时虚拟机也能跑 OpenClaw，但在长期在线、固定目录与低漂移工具链上通常不如独占物理远程 Mac 稳定；当团队要把 Gateway 与大型 monorepo 同机或同区部署时，上下文与磁盘 IO 会同时成为瓶颈。MACCOME 在新加坡、日韩、香港与美东美西提供 Mac Mini M4 / M4 Pro 与弹性租期，适合承载「常驻 Gateway + 大仓克隆」的组合；公开租赁说明可与本文 BEL 上限同一行对齐，先把环境与目录策略写死，再迭代 Skills。
试点建议：先在一周内把 BEL 压到团队目标区间，再评估是否增加模型档位或通道数量，避免用更大模型掩盖仓库噪声。
常见问题
网络和模型问题去哪篇？
Docker 与 CLI 请看《Docker 网络分诊》；模型链请看《provider 路由》。