十个配置，让我的 OpenClaw 从聊天机器人变成自主执行体
作者：Kaostyl (@kaostyl)
以下是我做的十项配置，让 OpenClaw 从一个聊天机器人蜕变为真正的自主操作者：
1⃣ 把记忆拆成 5 个文件，而不是 1 个
别再把所有东西一股脑塞进 https://t.co/Be5Xdc9UsF 了。拆开来： - https://t.co/OrzLkm5r0r → 崩溃恢复（agent 重启时最先读取） - https://t.co/htttxcZsvo → 记录每一次犯错，只记一次，绝不重蹈覆辙 - https://t.co/noS3IaCe33 → agent 每 4 小时做一次自我复盘 - https://t.co/mAPMQ09IJ7 → 每个项目的当前状态 - 每日日志 → 原始上下文，7 天后删除
为什么要这样做：agent 只加载它需要的内容。一个文件 = 臃肿的上下文 = 迷糊的 agent。
2⃣ 给每个技能加上"何时使用 / 何时不用"
没有这个，你的 agent 大约有 20% 的概率选错技能。
反面示例： "description": "Deploy websites"
正面示例： "description": "Deploy files to cPanel. USE WHEN: uploading files, creating domains. DON'T USE WHEN: buying domains (use registrar skill), managing DNS (use Cloudflare skill)"
这就是给 agent 的大脑写 if/else 路由。
3⃣ 设置一个 https://t.co/snp6Guwnlv 检查清单（不超过 20 行）
心跳每 ~30 分钟运行一次，保持精简： - 检查活跃任务是否停滞（超过 2 小时没有更新） - 归档膨胀的会话（>2MB） - 每 ~4 小时做一次自我审查
重活交给 cron 任务。心跳 = 快速健康检查，仅此而已。其他任何事都是在白烧 token。
4⃣ 所有定时任务都用 cron
心跳适合批量处理快速检查，cron 才是干正事的： - 早 6 点 → 内容调研 - 早 8 点 → 技术新闻摘要推送到 Telegram - 晚 6 点 → 每日总结
每个 cron 任务在独立会话中运行。没有上下文串扰，不会因为加载完整对话历史而浪费 token。
5⃣ 让 agent 验证自己的工作（但不要让它自己打分）
在 https://t.co/FTZIb5NZIy 中加上这段： "Every sub-agent MUST validate its own work. But I also verify the result before announcing to the user. Never take a sub-agent's result for granted."
构建的 agent ≠ 审查的 agent。这一条规则就能解决 80% 的质量问题。
6⃣ 按任务类型分配模型
不是每个任务都需要最贵的模型： - 读文件、提醒、内部事务 → 快速/便宜的模型 - 外部网页内容（文章、推文） → 只用最强模型 - 编码任务 → 中档模型 + 扩展思考
为什么外部内容要用最强模型？弱模型更容易被恶意网站的提示注入攻击。这不是杞人忧天——我亲身经历过。
7⃣ 会话卫生——积极归档
超过 2MB 的会话 = 迟钝的 agent、混乱的上下文、昂贵的每一轮对话。
设置自动归档： - >2MB → 归档 - >5MB → 告警 - 每日日志 → 每周轮转
你的 agent 应该保持轻量。如果它每轮都要加载几兆的历史记录，那就是在烧钱，而且会越来越笨。
8⃣ 写一个真正有个性的 https://t.co/45YKCeaRkI
默认的 agent 听起来像企业客服机器人。改掉它： - 给它起个名字 - 定义沟通风格（"直截了当，不说废话"） - 设定边界（"发邮件前先问我"） - 允许它有自己的观点（"你可以不同意我"）
一个有个性的 agent 能捕捉到更多边界情况，因为它是真正在投入地处理任务，而不是生成安全但泛泛的输出。
9⃣ 三行代码实现崩溃恢复
在 https://t.co/FTZIb5NZIy 中加上： "On startup: read https://t.co/OrzLkm5r0r FIRST. Resume autonomously. Don't ask what we were doing — figure it out from the files."
你的 agent 一定会崩溃。会话一定会重启。没有这个配置，它醒来后一脸茫然地问"我该做什么？"有了这个，它会从中断处继续。零停机。
🔟 子 agent 需要的是明确范围，不是自由
生成子 agent 时： - 明确定义它能操作的范围 - 给出清晰的成功标准 - 设置超时（否则它们真的会永远跑下去） - 绝不让两个 agent 写同一个文件
把它们当承包商，不是员工。明确需求 → 交付 → 结束。
这里的规律是：以上每一条建议都是关于结构，而不是提示词。
你的 agent 能力上限，取决于围绕它搭建的基础设施。