一个连续一周每天睡四小时、跟OpenClaw死磕到凌晨三点的实战派，把那些装逼犯嘴里“完美运行”背后的所有屎山代码和隐蔽雷区，一次性全给你刨出来
这不是那种你看完就忘的软文教程。这是一份用连续一周每天凌晨四点还在翻错误日志换来的实战病历本。从新旧版本打架抢端口导致无限重启，到子代理把整个项目删了还不报错，再到TUI界面永远显示“无输出”结果只是因为没给机器人发条微信——所有没人告诉你的坑，这里全有，连命令行都给你写好了，直接复制粘贴就能救命。
别信那些一天搞定的鬼话，老子整整修了一周
我连续跑多代理调度跑了一周多。OpenClaw这东西，它终于开始往我想要的方向走了。
但你猜怎么着？全网所有人都在告诉你他们的系统完美无瑕，他们一天就搞定收工了。
放屁。
全他喵是谎言。
我搭建的时候，但凡能崩的东西，全崩了，一个没落下。字面意义上的“每一个环节”。
所以我接下来要说的，是我撞上的每一个烦到想砸电脑的问题，是那些所谓“高级用户”从来不会告诉你他们其实也踩过的雷，是那些真正让这坨东西稳定跑起来的配置文件。不管你是只跑一个代理，还是带着十个子代理跑整支队伍，不管你是代码大神还是刚打开终端的新手——这才是我当初起步时做梦都想要的那份参考手册。
这不是安装指南。这是优化求生手册。
别看完就扔。给我存书签，给我保存下来。下次你的OpenClaw又抽风的时候，回来翻它。
新旧版本打架抢端口，装完直接无限重启，你管这叫升级？
如果你是从老版本clawdbot升上来的，好消息是安装器本身会处理迁移。它把你的.clawdbot目录挪到.openclaw，再建个符号链接指回去，配置、灵魂文件、记忆、工作区全给你搬过去，clawdbot包也留着当兼容层。
听起来挺贴心对吧？
真正要命的是它没清理干净的东西。
老版本的clawdbot-gateway.service有时候还在跑，新版本的openclaw-gateway.service也跑起来了，两个服务同时伸手抢端口18789。然后你就看见新网关反复重启，错误日志永远一句话：“另一个网关实例已经在监听中”。
你以为是OpenClaw崩了。
其实是它自己跟自己打架，前任现任抢一个端口，系统直接死循环。
装新版之前，先把老家伙彻底送走：
bash
systemctl --user stop clawdbot-gateway.service
systemctl --user disable clawdbot-gateway.service
rm -f ~/.config/systemd/user/clawdbot-gateway.service
systemctl --user daemon-reload
然后卸载老版npm包，顺手翻翻垃圾堆：
bash
npm uninstall -g clawdbot
去/usr/local/bin/clawdbot和/usr/local/lib/node_modules/clawdbot看一眼，有残骸就直接清掉。这些遗留文件不会报错，它们就安静地躺在那里，等你装完新系统之后从背后给你使绊子。
做完这套，全新安装OpenClaw，你原有的工作区文件它自己就能认出来。别偷懒，我偷过，代价是三个小时翻日志。
代理挂起、崩溃、沉默二十分钟，这他妈居然是正常现象
你24小时不关机跑代理，它就会给你演一出三幕剧：挂起，崩溃，然后毫无解释地沉默十几二十分钟。
这不是你配置错了。
这是这东西的常态。
解决方案不是什么玄学调参，而是直接承认它会死，然后写个脚本给它收尸。
写个最简单的看门狗脚本，每15分钟去ping一下网关的健康检查接口。没响应？直接整个重启。你不应该像个保姆一样蹲在服务器前面手动点重启。
bash
#!/bin/bash
while true; do
curl -f http://localhost:18789/health || systemctl --user restart openclaw-gateway
sleep 900
done
三行代码，解决你每晚被警报吵醒的问题。这玩意儿比你盯着日志有用一万倍。
内置诊断工具能救命，很多人不知道带--fix参数才是完全体
OpenClaw有个内置诊断命令叫openclaw doctor。一次检查你的配置、网关、频道、工作区、权限全给你扫一遍。
大多数人跑完看一眼就关了。
但真正有用的是那个--fix参数。
bash
openclaw doctor --fix
这玩意儿会自动修复权限错误、补全缺失目录、清理过时配置项、更新废弃的服务路径。改配置之前它会先备份，不动你的API密钥，不碰你的密码。升级之后觉得系统不对劲？跑一遍。插件装完系统抽风？跑一遍。什么都没改但是突然崩了？还是跑一遍。
有些用户说不加--fix参数效果更好，因为不加只检查不修复，先看报告再手动修，心里更有底。你自己试，哪个顺手用哪个。
你的服务器只要暴露在公网，三小时内必被暴力破解，这不是危言耸听
互联网是个烂地方。你的服务器只要开了端口，扫描器几小时内就会摸过来，密码字典直接往你脸上糊。
最低限度防护：
bash
apt install fail2ban -y
ufw allow 22
ufw enable
但说真的，最好的安全策略是根本不开端口。
用Cloudflare Tunnel或者Tailscale。你的服务器根本不需要在公网上有任何开口。然后在OpenClaw配置文件里，把gateway.bind设成"loopback"，网关只监听本地。没开端口就意味着没有攻击面，没有攻击面意味着你凌晨三点不用爬起来应急。
json
"gateway": {
"bind": "loopback"
}
插件装完整个网关瘫了，不是运气差，是你一次性装太多
插件很强。插件也能把你整个网关干碎。
刚装完插件，重启，网关起不来了。
第一步不是去翻你的主配置文件。先去gateway.err.log看具体报错。十有八九错误信息里直接写着插件名。
bash
openclaw plugins disable <插件名>
重启。搞定。
养成一个习惯：每次只装一个插件，装完立刻确认网关能正常重启。
别一次性装三个，然后三个里面不知道哪个是炸弹，还得一个一个卸了试。这种蠢事我干过一次，花了四十分钟才知道是第二个插件的问题。你完全可以不踩这个坑。
代理说“干完了”，结果代码根本没跑，仓库还是空的
这是我见过最多的问题，没有之一。
代理不干活，活干一半停在那，或者说“已完成”但明眼人一看就知道屁都没干。
核心真相：代理的自主程度，完全取决于你的指令有多精确。
你的指令含糊，代理的行为就含糊。你没定义什么叫“干完”，代理就会自己定义一个，而且它的定义极其宽容。
在AGENTS文件里写死规矩：
每次代理声称"完成"时，必须附带仓库名、分支名和提交哈希。
必须用实际命令验证工作成果，不能只说"我检查过了"。
设计心跳循环，在未完成任务腐烂几小时之前就抓住它。
代理不是懒。它是在严格执行你指令里的模糊地带。把模糊地带清掉，行为立刻变。
回退列表塞太多模型，代理会精神分裂
你在回退列表里塞了五六个模型，Claude、GPT、开源全混在一起。
然后代理处理同一个任务，前一半用Opus做深度推理，后一半切到某个便宜模型开始胡编乱造。输出质量忽高忽低，你都不知道这任务是成了还是废了。
回退列表最多2到3个模型，且必须是同一家供应商。
全用Anthropic，或者全用OpenAI。不要在同一个回退链里混两家。
模型配置直接在配置文件里手写，别用TUI图形界面，也别用GUI。那些界面有时候保存不上，你改完重启发现设置全没了，又得重来一遍，浪费时间。
如果用免费模型，永远放在回退链的最后，永远不作为核心任务的主力模型。免费模型是安全网，不是地基。
一个靠谱的回退配置长这样：
json
"model": {
"primary": "anthropic/claude-opus-4-6",
"fallbacks": ["anthropic/claude-sonnet-4-20250514", "anthropic/claude-haiku-4-5"]
}
出错自动切换，你的代理永远不会因为模型挂了而哑火。
TUI界面永远显示“无输出”，你折腾半天配置，其实只是忘了给机器人发条消息
这个问题让我抓狂了三个小时。
TUI界面里每条回复都显示“无输出”，你检查配置、检查网络、检查API密钥，全都对，但就是没输出。
如果你用--deliver参数配置了Telegram推送，但是你从来没给你的机器人发过任何一条私信，那整个输出管道会被这个失败推送直接堵死——不只是Telegram发不出，是所有输出全卡住。
解决方案蠢到我不想承认：
打开Telegram，给你的机器人发条消息，随便发什么都行。
管道立刻解封，所有输出开始正常流动。
就这。
代理正忙着处理请求，新消息来了，直接消失
代理在处理一个耗时很长的工具调用，这时候你或者用户发了新消息进来。
这些消息去哪了？
垃圾桶。无声无息地丢了。
发消息的人以为你收到了，其实代理那边根本不知道这回事。
启用队列模式：
json
"messages": {
"queue": {
"mode": "collect"
}
}
每条消息都进队列，按顺序处理。就算代理在处理长任务时五条消息同时涌进来，一条都不会丢。
不想给向量数据库付钱？QMD本地搜索能打
OpenClaw的QMD后端让你在本地跑BM25关键词搜索、向量搜索、重排序，全流程不上云。
你需要先装qmd二进制：
bash
bun install -g qmd
然后在配置里切后端：
json
"memory": {
"backend": "qmd"
}
默认的内置后端其实已经支持混合搜索了，QMD的优势是多了一层本地重排序，还能索引工作区以外的多个外部文件夹。
代价是更复杂的组件依赖，更高的CPU和磁盘占用。如果你的记忆集很小，而且基本都是工作区的Markdown文件，内置混合搜索完全够用，不用硬上QMD。
另外注意：第一次查询会很慢，因为QMD会在你发起首次搜索时下载本地模型，三百多兆。
Telegram回复秒回，一眼假，正常人没这么快的
你在Telegram或者Discord上跟人聊天，对面200毫秒就回。
正常人谁打字这么快？
任何稍微留心的人都知道：这是机器人。
json
"humanDelay": {
"mode": "custom",
"minMs": 800,
"maxMs": 2500
}
回复延迟在0.8到2.5秒之间随机分布。像人一样“正在输入”的节奏感，而不是机器瞬间弹回。
就这一个细节，别人跟你代理互动的感受会从“跟工具打交道”变成“跟人聊天”。差别巨大。
代理和子代理根本不是一回事，九成人都混着用
代理是你的团队成员。每个代理有自己的独立人格、自己的工作区、自己的灵魂文件、自己的模型、自己的职责。
把它当成你的员工：
CEO代理管战略和对外沟通
CTO代理管技术决策
CMO代理管内容和市场
他们都是顶层成员，永久存在，随时可用。
子代理是临时的背景打工人。你团队里的任何一个代理都可以召唤子代理来处理某个具体任务，同时主会话不被阻塞。子代理在隔离会话里干活，干完汇报，然后归档。
他们是一次性临时工，不是固定团队成员。
关键区别：默认情况下，子代理不能再召唤子代理。
这是故意设计的。防止代理链条无限套娃，指数级燃烧你的API额度。社区有人提过需求要把这个做成可配置，但目前就是只能嵌套一层。
控制团队成员能召唤谁，设允许名单：
json
{
"id": "ceo",
"subagents": {
"allowAgents": ["cto", "cmo", "cro"]
}
}
CEO可以以CTO、CMO、CRO的身份召唤子代理。CMO不能以CTO身份派活，除非你明确允许。
这就是一套清晰的组织层级，没有混乱的跨部门派遣。
全员标配最贵模型？那是烧钱，不是架构
不是所有代理都需要Opus。
CEO需要强推理能力来做调度和决策。CTO需要代码优化模型。COO跑日常运营任务，用便宜轻量的完全够。
正确模式：
CEO用Opus，处理复杂推理和战略决策
CTO用Codex，写代码干技术活
COO用Haiku，跑快速运营任务和常规协调
全局配置里设好默认模型，然后每个代理单独覆盖。
json
"agents": {
"defaults": {
"subagents": {
"model": "anthropic/claude-haiku-4-5"
}
}
}
子代理跑个快速调研任务，根本不需要Opus。全局给子代理设便宜模型，顶层代理按需用贵的。这才是控制成本又不牺牲质量的方法。
默认并发数保守到令人发指，你硬件能扛就往上拉
OpenClaw默认保守，主要是怕你把系统跑死。
两个关键参数：
json
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8
}
maxConcurrent控制顶层会话同时跑多少个。subagents.maxConcurrent控制子代理会话并行数量。
你的硬件如果扛得住——直接往上拉。更高并发意味着你的多代理系统是真在并行处理任务，而不是把所有活堵在一个队列里。
子代理不能生孙子，这是硬编码，别想了
前面说了，子代理默认不能再召唤子代理。
OpenClaw硬编码了这个限制。原因很实在：防止代理链条无限蔓延，一边套娃一边烧你的钱。
真正能跑起来的架构是： 顶层代理（CEO、CTO、CMO）各自召唤子代理做后台任务，子代理拿到任务，一次性干完，汇报，结束。
没有更深的嵌套，没有子代理再召唤子代理的链条。
社区确实在讨论可配置的覆盖方案，比如设allowNesting: true，或者在子代理工具允许列表里加sessions_spawn。但默认行为之所以是默认行为，就是因为它对大多数人是最稳妥的选择。
保持扁平化委托：顶层代理把大任务拆成原子单元，每个单元由一个子代理完成并返回。就这一层，够了。
所有对外沟通由CEO统一发声，别让技术总监跟客户闲聊
你的团队里每个代理都有自己的工作区、个性和模型。
但所有对外通讯，必须经过一个代理——CEO或你指定的主要联系人。
Telegram → CEO
Discord → CEO
CTO、CMO、COO → 仅限内部
专精代理待在内部，只干自己的活。一个人形代理负责所有面向人类的频道。
这样做的好处：不会出现冲突回复，对外保持统一口径，你的专精成员不用分心去做客服。他们只管干活，CEO负责对外汇报。
跨工作区复制文件是给自己挖坟
别在两个代理的工作区之间复制文件。
过几天你就会发现，同一个配置文件在两个工作区里内容不一样了。谁是最新版？不知道。
用符号链接：
bash
ln -s ~/workspace/state ~/workspace-cto/state
一个主代理写入，其他人只读这个链接指向的文件。
文件系统本身就是你的协调协议——简单、可靠、不需要任何花哨工具。
灵魂文件、代理规则、身份标识，三份文件各司其职，别往一个筐里塞
大多数人要么直接跳过这一步，要么把所有东西全塞进同一个文件。
OpenClaw把身份拆成独立文件，每个文件服务唯一的目的。
灵魂文件定义你的代理是谁——不是它能做什么，不是它怎么配置，是它本质上是谁。它的哲学，它的语气，它的边界，它的人格。
代理规则文件定义操作规则和行为指令。
身份文件定义展示信息，比如显示名和头像。
灵魂文件是让你团队里每个代理感觉像不同的人，而不是同一个模型换了几顶帽子。
OpenClaw默认的灵魂文件模板开头是这么写的：
> “你不是一个聊天机器人。你正在成为某个人。”
就是这个思路。你写的是人物角色卡，不是配置文件。
CTO代理的灵魂文件可能是这样：精确、怀疑、证据优先。讨厌模糊需求，喜欢技术细节，会对不明确的指令反问。CMO代理的灵魂文件则是另一种：创意、战略、品牌意识，关注叙事和定位。
同一个底层模型，完全不同的思考模式。
写灵魂文件的核心原则： 具体优于泛化，真实观点优于安全立场，清晰边界优于开放灵活。如果别人读完你的灵魂文件，无法预测这个代理在陌生情境下会怎么反应，那就是写得还不够具体。
每个代理在每次会话启动时都会读自己的灵魂文件。它被注入系统提示词，成为代理身份的根基。如果代理修改了自己的灵魂文件，它会告诉你——因为那个文件就是它的身份认知，它进化的时候你理应知道。
json
"agentDir": "~/.openclaw/agents/cto/agent"
每个代理指向自己的专属目录。灵魂文件放在工作区，跟代理规则、用户规则在一起。
子代理把整个项目删了，日志里什么都没有
有个故障模式我排查了很久。
子代理在一个正在跑开发服务器的仓库里执行了rm -rf .next。
然后开发服务器悄无声息地死了。没有报错，没有崩溃日志，就只是……停了。
解决方案： 子代理只能用tsc --noEmit做类型检查（只检查不构建）。只有拥有这个工作区的顶层代理才能碰开发服务器。
子代理永远不直接跟运行中的进程交互。它们只做隔离任务，干完，汇报，结束。
五个子代理同时干完活，宣布队列堵死，网关超时
五个子代理任务完成时间差不多，同时向父代理汇报。
宣布队列堵了。
网关等不及，直接超时。
两个对策：
1. 对非关键的子代理，设cleanup: "delete"，宣布完成立即归档，不留在队列里占位。
2. 任务启动时间错开，别让所有子代理都正好同一秒干完。
另外记住：宣布是尽力而为。如果网关在宣布过程中重启了，那些结果就丢了，不会补发。
定时任务里写模型别名，系统不认识你是谁
你在cron配置里写“haiku”。
系统问：哪个haiku？Claude Haiku？哪个版本？你他妈谁啊？
永远用完整模型字符串：
anthropic/claude-haiku-4-5
不是haiku，是anthropic/claude-haiku-4-5。
这能省掉你半夜爬起来查“为什么定时任务跑了但好像没用对模型”这种破事的时间。
会话跑太久，上下文里塞满垃圾，代理开始胡言乱语
长会话跑下来，上下文里堆积的全是旧工具输出。几个小时前的API响应，已经过时的文件内容，早就完成的任务结果。
代理还在引用这些垃圾信息，因为它不知道哪些是当前有效的。
json
"agents": {
"defaults": {
"contextPruning": {
"mode": "cache-ttl",
"ttl": "30m",
"keepLastAssistants": 3
}
}
}
当会话里最后一次调用Anthropic API的时间超过30分钟，修剪机制触发，把内存上下文里过大的工具结果裁掉。它不碰你磁盘上的会话历史，只是下次发请求给模型的时候，内容更精简。
最后3条助手回复不动。
巨大的额度节省。代理也不再被过期信息干扰。
上下文压缩之前不让代理存盘，活该丢记忆
OpenClaw压缩上下文窗口之前，你应该让代理先把重要信息写到磁盘。
否则压缩机制会删掉代理还没来得及落盘的信息。
json
"compaction": {
"mode": "safeguard",
"memoryFlush": {
"enabled": true
}
}
压缩运行前，代理会获得一个静默回合，把重要笔记写入memory/YYYY-MM-DD.md。
没存盘的上下文，不会被静默丢弃。
MEMORY文件太大，中间全被截断，代理根本不知道有过那些内容
记忆文件和其他工作区文件每次消息都会注入代理上下文。
OpenClaw有引导预算，限制一次性加载的工作区内容总量。当单个文件超过这个预算，它会被截断。
截断规则是70/20/10：头70%、尾20%，中间全切掉。
没有错误提示，没有警告，聊天里什么都没显示。代理只是不知道那个巨大文件中间写的是什么。
保持MEMORY文件精简。详细信息拆分到memory/子目录下的独立文件里，代理按需读取。
把MEMORY当作索引，不是数据库。你在索引里写指向具体文件的指针，而不是把所有内容直接塞进MEMORY。
心跳飘忽不定，今天往这发明天往那发，因为你没锁目标
默认心跳目标是“last”——代理最近用过的频道。
你同时在Telegram和Discord活跃，心跳就在两个频道之间跳来跳去。今天报平安发到Telegram，明天又发到Discord。
明确指定心跳目标：
json
"heartbeat": {
"target": "telegram"
}
锁死它。
机器人有管理员权限但读不了某些频道，权限检查逻辑有缺陷
你的机器人挂着管理员帽子，进某些频道就是读不了消息。
这不是你配置错了。
这是OpenClaw权限检查器对管理员权限与频道拒绝规则的交互处理有问题。
解决方案： 在机器人需要访问的每个频道，显式添加机器人角色允许规则。
别指望管理员权限能自动渗透到所有子频道。它按理说应该能做到，但OpenClaw目前就是没正确解析。
Boot文件是你重启时的救命稻草，九成人根本没用过
这个文件每次网关重启都会执行。
把它当成你的启动检查清单——自动运行。
我自己的Boot文件会检查服务器健康状态、验证分支状态、跑安全审计。每次重启，代理开始干活之前，Boot文件先确保整个环境是坚固的。
bash
openclaw hooks enable boot-md
这能抓住那种日积月累的隐性故障：服务器配置飘移、分支不一致、权限变动——都在变成大问题之前被它翻出来。
出事之后第一反应是翻配置？错，第一反应是翻错误日志
网关崩了。
你的本能：去翻配置文件、翻代码、翻插件设置。
停。
先开gateway.err.log。
每次我自作聪明，不去读日志而是自己猜哪里错了，都会把问题搞得更糟。日志直接告诉你发生了什么。
从日志开始。永远是日志。
记忆系统不是只有两个层，大多数人整个架构就错了
OpenClaw官方记忆系统有两个层。
MEMORY文件是你策划过的长期记忆——存决策、偏好、持久事实。而且它只在私聊会话加载，群聊不加载，保护敏感信息。
memory/YYYY-MM-DD.md是每日日志，只追加不修改，原始记录。代理会话开始时读今天和昨天的文件，保持连续性。
这套两层系统是默认配置。
但如果你跑任何复杂系统，应该拆得更细：
memory/active-tasks.md当实时任务追踪器——记录进行中的任务、等待中的任务、被阻塞的任务。这是你的崩溃恢复存档。
memory/projects.md存项目级上下文，不每天变动。
memory/lessons.md存代理长期学到的模式和修正，让它不再重复踩同一个坑。
核心原则： 代理每次会话都是全新启动，这些文件就是它的大脑。
如果你把所有东西都倒进MEMORY，你立刻撞上2万字符上限，而且代理每次都加载当前任务根本不需要的上下文。但如果你拆得聪明，MEMORY就变成索引，指向具体细节文件，代理按需深入读取，而不是每次会话都背着整部历史。
记忆搜索系统索引memory/下的所有文件。即使代理启动时没加载某个文件，当对话需要它时，搜索功能也能把它找出来。
心跳和定时任务是两回事，混着用必出事
很多人混着用这两个词，然后纳闷为什么自己的自动化要么浪费额度要么根本不干活。
它们用途完全不同。
心跳在主会话里按固定间隔运行。默认每30分钟一次。代理醒来，读心跳文件，过一遍检查清单，判断是否有事需要你注意。没有就发个静默的心跳正常信号，继续睡，不刷通知。心跳适合把多个周期性检查打包成一次代理行动：比如扫一遍收件箱、看日历、审待办任务——都在同一个代理回合里完成，带着完整的对话上下文。
定时任务在精确时间点运行，独立隔离会话。每个任务有自己的上下文，想指定模型就指定模型，想指定推送目标就指定推送目标。不加载完整对话历史浪费额度。到点就触发，不管主会话在干什么。
规则： 需要周期性检查、且能从对话上下文中获益的——用心跳。需要在特定时间点精确执行、且需要隔离环境的——用定时任务。
bash
openclaw cron add \
--name "晨间简报" \
--cron "0 7 * * *" \
--session isolated \
--message "生成今日简报：天气、日历、置顶邮件" \
--model opus \
--announce \
--channel telegram
每日内容创意早6点跑，凌晨2点跑调研爬虫，早8点跑技术监控。每个都在隔离会话里，独立上下文，任务之间不交叉污染。
社区反馈的一个坑： 如果心跳文件是空的（或只有注释），有些定时任务会错误跳过。有已知bug和修复方案。如果你的定时任务一直显示“空闲”就是不触发，检查心跳文件里至少有一行非注释内容。或者直接用隔离会话目标，彻底绕过心跳调度器。
代理会崩溃，网关会重启，这是必然的，你的系统必须接受这个现实
24小时不间断运行，代理必崩，网关必重启。
你要的不是永不崩溃的系统——你要的是崩溃后能自己爬起来的系统。
模式极简： 在memory目录维护一个active-tasks.md文件。
任务开始时，写入文件。召唤子代理时，记下会话密钥。任务完成时，更新状态。任务失败时，记录错误。
然后在Boot文件里加一步：每次网关重启，读active-tasks.md。
代理恢复上线，读这个文件，看到哪些任务正在进行，自动恢复执行。不需要你问“我们刚才在做什么？”它从文件里就知道了，从断点继续干。
这跟之前的压缩保护配合。上下文压缩前，代理把重要状态刷到磁盘。Boot在启动时恢复，压缩保护在长会话里保障不丢——崩溃恢复两端都守住了。
处理外部内容必须用最强模型，别省这个钱
你的代理读任何外部内容：邮件、网页、推文、文章。
用你最强的模型处理所有外部内容摄入。
弱模型对抗提示词注入的能力差太多了。恶意网站、被篡改的邮件里藏一句精心构造的指令，弱模型直接被带偏。强模型难拐得多，防御能力强很多个数量级。
内部任务：读本地文件、设提醒、操作工作区——Sonnet或Haiku足够了。内容是你自己生成的，可信。
但代理从互联网抓取内容，或者处理未知发件人邮件——必须经过最强模型。
这也是为什么之前说的按代理覆盖模型和定时任务指定模型非常重要：你的内部运营代理可以跑便宜，你的对外接口代理必须跑贵。
心跳文件20行就够了，写多了是烧钱
每次心跳执行，心跳文件内容加载进代理上下文，燃烧你的额度。
默认间隔30分钟。一份臃肿的心跳文件，一天下来烧掉的额度够你再跑好几个正经任务了。
控制在20行以内。 就是一份简单清单：
- 检查活跃任务时效性
- 检查会话健康（归档过大会话）
- 每隔几小时自我审查
- 标记任何紧急事项
够了。
重活让定时任务干，带隔离会话的那种。心跳的职责是发现问题，不是解决问题。心跳发现有问题，它应该做的是提醒你，或者触发一个定时任务去干活。不是自己每30分钟写一份报告、生成内容、跑复杂分析。
OpenClaw文档写得很直接：
> “保持心跳文件短小，以最小化额度开销。”
字面意义执行。
技能路由逻辑全写在描述字段里，九成用户根本没意识到
你装了好几个技能包。
代理怎么决定用哪个技能？技能YAML头部的名字和描述。
技能体内容只有代理已经决定触发这个技能之后才会加载。
这意味着你整个路由逻辑全在描述字段里。
每个技能描述必须写清楚“何时使用”和“何时不使用”。没写这些触发条件，代理就会乱选技能。你想调编码技能，它调了个调研技能。你想要状态检查，它跑了个部署流程。
这就是你在给代理写if/else逻辑。
每个技能描述都要明确：
- 什么上下文中激活这个技能
- 什么上下文中不要激活这个技能
- 这个技能做什么 vs 不做什么
OpenClaw技能文档反复强调：描述是主要触发机制，所有“何时使用”信息必须放在这里，不是在技能体里面。
持续运行一周后真正能扛住的架构
我现在跑通了的模式——你自己用也要先审计，别直接抄，哪怕让OpenClaw帮你审：
你组建一支专精代理团队，每个代理有自己的灵魂文件、独立工作区、指定模型。
一个代理（CEO）处理所有对外通讯，Telegram、Discord、你挂的所有频道。
团队其他成员（CTO、CMO、你需要的任何角色）待在内部，专注于自己的专精领域。
团队里任何一个代理都可以召唤子代理做后台任务，不阻塞主会话。这些子代理完成原子任务，汇报，结束。
共享状态存在符号链接文件里，所有人都读同一个事实源。
上下文自动修剪。
记忆保持精简。
Boot文件每次重启抓取系统漂移。
错误日志是第一诊断工具。
这个工作量，30%是搭建，70%是调试你根本不知道存在的底层基础设施。
这个比例不会变。
但当你知道去哪里翻，调试速度就完全不一样了。