如果你已经把自己的 OpenClaw 跑起来了让它帮你收邮件、记会议、定时整理文件那这篇就是接着往下走的进阶路线。很多人把 OpenClaw 装完、配好一两个技能就觉得到头了其实真正把这类开源智能体框架用出价值靠的是四件事技能Skills、多 Agent 协作、省钱策略、安全加固。这四件事看着是四个方向实际上是一整套工程思维怎么让 agent 更可控、更可扩展、更省成本、更不容易闯祸。这篇没有废话全是实操层面的东西。适合已经用过 OpenClaw 基本功能、想把当前“玩具级”用法升级成“生产力级”用法的朋友如果你是零基础建议先跑一遍官方快速开始再回来读这篇会顺很多。下面所有配置片段、目录结构和代码示例都来自我实际折腾过的方案你可以直接抄抄完再按自己的场景改。1. 进阶前先认清 OpenClaw 的“边界”1.1 技能、多 Agent、省钱、安全其实是一件事先说一个我踩过之后才明白的道理OpenClaw 这类框架的真正难点不是“怎么让它跑起来”而是“怎么让它跑得稳、跑得便宜、跑得不出事”。很多新手一上来就在单个 agent 里堆技能一个 agent 身上挂了十几个能力结果上下文越来越长响应越来越慢一次误操作把临时目录里的东西全清理了或者在循环重试里烧掉了大量 token。这些问题看起来是不同方向根源都指向同一个地方你没有给 OpenClaw 设定边界。技能是能力边界多 Agent 是职责边界省钱是成本边界安全是权限边界。把这四块想清楚OpenClaw 才真正从“一个能聊天的终端工具”变成“一个可信赖的自动化同事”。所以我不建议你跳跃着只看某一段尤其是省钱和安全这两章一定要配合前面技能和多 Agent 的设计一起读否则你根本算不准哪里在浪费钱也说不清到底该给哪个 agent 多大权限。1.2 三种典型用法决定你需要哪种进阶我接触过的 OpenClaw 用法基本可以分成三类每类需要的进阶深度完全不同单人自动化跑在本机替你做文件整理、日报汇总、信息抓取。这种场景技能系统是核心多 Agent 可以先不碰。小团队协作几个 agent 分管不同数据源比如一个管财务数据、一个管项目进度、一个管客户消息最后由主控 agent 汇总。这时候多 Agent 架构就是重点。对外服务OpenClaw 作为后端能力被其他系统调用可能是 webhook 触发可能是定时任务。这种场景安全优先级最高省钱策略也要提前设计否则上线第一天费用就可能失控。你在动手前先问自己一句我现在的 OpenClaw 是哪种用法如果是第一种直接看第 2 章如果是第二、三种建议把全文都读一遍因为多 Agent 和安全的方案必须在一开始就设计好事后补救的成本很高。2. 技能系统OpenClaw 的能力扩展核心2.1 一个技能的最小结构长什么样OpenClaw 的技能skill本质上就是一个“可以被 agent 调用的小程序”。最标准的做法是每个技能一个目录目录里放一个描述文件和可执行脚本。以自定义技能为例我习惯用这样的结构~/.openclaw/skills/generate_report/ ├── skill.json ├── run.sh ├── main.py ├── requirements.txt └── templates/ └── report_template.md其中skill.json是这个技能的“身份证”OpenClaw 靠它识别技能名称、功能描述、参数格式。一个最小例子长这样{ name: generate_report, description: 根据指定日期生成工作日报输入日期输出 Markdown 报告文件, version: 1.0.0, input_schema: { type: object, properties: { date: { type: string, description: 日期格式 YYYY-MM-DD } }, required: [date] }, output_schema: { type: string, description: 生成的报告文件路径 }, timeout_seconds: 120, allowed_actions: [read, write, exec] }注意几个细节description字段写得越具体越好因为 OpenClaw 的模型是根据这段描述来决定“什么时候应该调用这个技能”的。写过模糊描述的都知道模型经常在不该触发的时候触发技能或者该触发的时候完全忽略你。另外timeout_seconds一定要设否则一个技能脚本卡死会拖住整个 agent 会话。2.2 技能触发、参数校验与执行权限技能写好了OpenClaw 内部会经过一条链路模型先根据用户的意图匹配技能描述接着按input_schema校验参数然后决定以什么权限执行。这是很多教程忽略的地方你的技能代码本身要假设参数是不可信的。模型生成的参数可能格式不对、越界、甚至带有注入成分所以脚本里开头必须先做参数校验。我举个反面例子某位同事写了一个“根据城市名称查天气”的技能脚本直接拼 URLcurl https://weather.example.com/api?city${CITY_NAME}如果模型传入的不是城市名而是一段 shell 命令这个脚本就有风险。正确做法是用 Python 而不是 shell 拼参数并且在拼接前用严格的白名单校验import sys, json import urllib.parse city sys.argv[1] if not re.fullmatch(r[\u4e00-\u9fa5A-Za-z\s]{2,20}, city): raise ValueError(invalid city name) url https://weather.example.com/api?city urllib.parse.quote(city)在这个环节你有几个权限选项。OpenClaw 里常见的执行权限包括只读read-only、可写文件write、可执行命令exec、可联网network。我的经验是大部分技能根本不需要exec和network同时开放。比如整理本地文件的技能只需要read和write不需要network抓取网页信息则只需要network和read临时文件。把权限压到最低后面安全章节就会省很多事。2.3 技能实战定时生成日报的完整拆解光说理论太抽象我拿一个真实在用的“日报生成”技能完整走一遍。这个技能解决什么问题每天早上OpenClaw 从我的项目日志目录读取昨天的变更记录调用大模型总结成条目再渲染成 Markdown 日报最后发送到团队的内部通知机器人。技能目录结构~/.openclaw/skills/daily_report/ ├── skill.json ├── main.py └── templates/ └── report.md.j2main.py的核心逻辑import os, sys, json, datetime, subprocess def get_changes(date_str: str) - list[str]: log_dir os.environ.get(PROJECT_LOG_DIR, ./logs) log_file os.path.join(log_dir, fchanges_{date_str}.log) if not os.path.exists(log_file): return [] with open(log_file, r, encodingutf-8) as f: return [line.strip() for line in f if line.strip()] def summarize_with_llm(changes: list[str]) - str: prompt 请将以下工作记录整理成三条以内的日报要点语言简洁。\\n \\n.join(changes) # 调用 OpenClaw 内置的模型接口不直接访问外部 API result openclaw_llm_complete(prompt, max_tokens300) return result.strip() def render_report(date_str: str, summary: str) - str: from jinja2 import Template with open(templates/report.md.j2, r, encodingutf-8) as f: tpl Template(f.read()) return tpl.render(datedate_str, summarysummary) if __name__ __main__: date_arg sys.argv[1] # 严格校验日期格式 datetime.datetime.strptime(date_arg, %Y-%m-%d) changes get_changes(date_arg) if not changes: print(json.dumps({ok: True, message: 当天无记录})) sys.exit(0) summary summarize_with_llm(changes) report render_report(date_arg, summary) out_path freports/daily_report_{date_arg}.md with open(out_path, w, encodingutf-8) as f: f.write(report) print(json.dumps({ok: True, file: out_path}))这里有一个很关键的实战细节不要把外部 API key 写在脚本里。我在这个技能里用的是 OpenClaw 内置的模型访问能力由框架统一管理密钥。如果技能里确实要调用外部 HTTP API我建议密钥从环境变量读取而不是硬编码。另外脚本最后输出的是 JSON 字符串而不是随意打印一堆日志这样 OpenClaw 才能稳定地拿到结果并反馈给用户。很多新手技能“失效”其实不是逻辑错了而是 stdout 输出格式太乱导致框架解析失败。2.4 技能避坑清单技能是 OpenClaw 扩展能力的核心也是翻车率最高的地方。我整理几条踩过的坑技能脚本一定要有幂等性。同样输入跑两次结果应该一致或可预期。日报技能如果重复执行必须覆盖旧文件而不是追加内容否则第二天你会看到三份拼接在一起的报告。别把大模型调用放在技能脚本里无限重试。很多技能失败是因为模型接口偶发超时代码里写个 for 循环重试 10 次每次 30 秒直接把技能超时撑爆。合理做法是重试 3 次每次间隔递增超过就报错返回。注意临时文件位置。技能统一的临时目录要放在 OpenClaw 工作目录下的tmp/并且用完清掉不要随手写到系统临时目录甚至项目根目录。后续做安全管控时这种乱写文件的习惯会带来很多麻烦。技能描述里不要写“任何时候都可以调用”这种话。尽量写清楚触发条件比如“当用户询问昨天的日报”“当检测到前一天的工作日志存在”。描述太宽泛模型就容易误触发。3. 多 Agent 协作从单兵到团队3.1 什么场景才需要多 Agent单 Agent 为什么撑不住很多人一听多 Agent 就兴奋觉得“多个总比一个强”结果把配置搞得非常复杂最后跑不起来。我的建议是先用单 Agent 把业务跑通当你明显感觉到单 Agent 吃力时再考虑拆分。什么样的信号说明该拆了一个典型场景是你让一个 agent 同时处理“财务数据整理”“客户消息回复”“项目进度跟踪”三个任务共享同一个上下文窗口。前几轮还行等到上下文里混了三种业务的信息后模型开始串线回客户消息时引用财务报表里的数字整理项目进度时突然聊起客户投诉。这就是上下文串扰。另一个场景是某个任务执行时间很长比如批量抓取几百个网页单 agent 的所有其他请求都被卡在后面排队整体延迟不可接受。多 Agent 解决的就是这两个问题职责隔离和并行执行。它不是把单个 agent 复制几份而是让不同的 agent 拥有不同的技能包、不同的上下文、甚至不同的底层模型。比如财务 agent 专门挂账务类技能消息 agent 专门挂回复模板两者互不干扰。3.2 一种稳妥的协作架构协调者加工人多 Agent 的架构方案有很多什么网状、环状、树状听起来很炫但真正稳定耐用的是“协调者coordinator工人worker”模式。协调者负责拆解任务、分发结果、汇总输出工人只负责执行不关心任务从哪里来、做完给谁。我搭过一套三个 agent 的最小可行配置一个 coordinator、一个 worker_a数据抓取、一个 worker_b报告生成。任务流程是用户向 coordinator 提出请求coordinator 判断需要数据把抓取任务发给 worker_aworker_a 执行完把结果存到共享状态库并通知 coordinatorcoordinator 再让 worker_b 基于最新数据生成报告。这套架构在配置文件里的样子大概是agents: coordinator: role: coordinator model: stable-medium skills: [task_router, summary] max_concurrent_tasks: 2 worker_a: role: worker skills: [web_crawler, data_extractor] capabilities: [network] permissions: [read, write] worker_b: role: worker skills: [report_renderer, email_sender] capabilities: [exec] permissions: [write] queue: type: redis address: localhost:6379 topic_prefix: openclaw_task_注意几点coordinator 的技能尽量精简它只做任务路由和结果汇总不要给它挂一堆业务技能否则你等于又造了一个“全能 agent”出来worker 之间不直接通信所有消息都通过 coordinator 转发这样出了问题好排查每个 agent 单独设permissions数据抓取 agent 不需要发邮件就坚决不给邮件技能。3.3 上下文、记忆与状态共享怎么设计多 Agent 最容易被忽视的是状态同步。单 Agent 时上下文窗口天然是记忆多 Agent 后每个 agent 有独立上下文谁都不记得谁做过什么。如果协调者只是简单地把任务分发下去再收集结果中间过程的状态就丢了。我采用的方案是“外部状态库”。所有需要跨 agent 共享的数据统一放到一个本地状态文件或者轻量数据库中并且记录一个简单的自增任务 ID。以刚才的抓取加报告流程为例worker_a 抓完数据后会在状态库里写入{ task_id: 20250621, status: data_ready, data_file: tmp/crawled_20250621.json, rows: 1284 }coordinator 轮询到这个状态后才发起 worker_b 的报告生成任务。这个“状态持久化”设计虽然多写几行代码但能避免大量“上下文丢失”导致的逻辑混乱。还有个好处是系统重启后可以根据状态库恢复未完成任务agent 挂了不至于全盘重来。这里要特别提醒不要让多个 worker 同时写同一个状态文件。并发写会互相覆盖结果数据直接损坏。我是用加锁的方式每个任务派发时先取一个独占文件锁处理完再释放。如果你用 Redis 或数据库作为状态库也要注意原子操作否则就老老实实串行处理。3.4 多 Agent 的常见失误与避免办法多 Agent 不是银弹配置不好反而比单 Agent 更慢更乱。我把实际运行中遇见过的高频问题列一下任务分配不均衡coordinator 把所有复杂任务都丢给同一个 worker其他 worker 闲置。解决为每个工人设max_concurrent_tasks和任务类型路由规则并在路由时简单算一下当前负载。互相等待形成死循环worker_a 在等 worker_b 的数据worker_b 又在等 worker_a 的确认。解决禁止 worker 之间直接依赖所有依赖关系必须经过 coordinator 且只允许单向箭头。上下文越拖越长每个任务结束后coordinator 把完整结果都塞给下一个 worker导致上下文爆炸。解决只传摘要和关键字段完整数据放文件或状态库。输出解析失败worker 返回的不是标准 JSONcoordinator 解析不了。解决严格规定所有工人必须输出 JSON并且安排在技能里做输出格式校验校验不过就自动重试一次。4. 省钱实操把 API 预算压到三成4.1 钱到底花在哪里了聊省钱之前先弄明白 token 消耗的大头在哪。根据我自己的账单分析OpenClaw 跑日常任务时成本占比最高的是这几项长上下文随会话持续累积、任务失败后的盲目重试、同一个模型被反复调用来处理简单任务、以及日志输出里塞满了完整的大模型返回结果。尤其是上下文累积这一项很多人没概念。单 Agent 会话如果你不主动清理上下文每一轮都在涨而 token 费用是跟着上下文长度“双向收费”的输入也会越来越贵。有一次我让一个 agent 连续跑了一百多轮问答最后一轮光输入就烧掉几万 token而那轮任务本身只是问一句“现在几点了”。这就是典型的慢性烧钱。4.2 五条亲测有效的省钱手段我在自己部署里实践过一套组合拳总体能把 API 成本压到原来的三分之一左右而且没有明显牺牲结果质量模型分级路由为不同任务分配不同能力的模型。日常分类、关键词提取、格式转换这类简单任务用轻量小模型复杂推理、写作、代码审查用强模型。OpenClaw 的配置文件里可以写路由规则比如“token 数小于 100 的补全走小模型”实现成本很低收益却非常大。上下文裁剪每轮任务结束后把对话历史中的工具调用细节、中间输出裁剪掉只保留最终结论和必要的用户意图。可以把完整历史转存到本地日志文件需要复查时再打开。缓存重复请求同一用户的同一类请求如果 24 小时内已经有过相同或高度相似的结果直接复用。我自己跑定时抓取场景时经常出现连续几天请求内容完全一样的情况缓存能直接省掉这部分费用。批量合并且并发限制对于大量小请求合并成一个大请求处理减少重复的 prompt 开销同时限制并发数量防止某个瞬间同时拉起几十个 agent 导致费用峰值。硬性额度上限在配置里设定每日 token 上限达到上限后新任务进入队列等待或直接拒绝。这个不是省钱技巧是求生手段防止某个错误的循环任务一晚上烧掉整月预算。4.3 成本与质量的平衡点在哪里省钱不是一刀切地“都用最便宜的模型”。我见过有人为了省钱给所有任务配小模型结果复杂任务频繁生成低质量结果返工调用的 token 反而更多。合理的做法是给任务分优先级或者复杂度等级。以我自己为例任务分成三级基础任务比如定时抓取、格式化输出用小模型标准任务比如日常问答、信息摘要用中档模型关键任务比如代码审查、大段文档撰写、复杂数据分析用强模型并放行较长上下文。分级之后再看成本你会发现大部分开销其实集中在少数关键任务上。基础任务即使量非常大因为单次便宜且可以大批量处理整体占比反而小。这个分布一旦建立起来你就能很清晰地看到“哪些任务在烧钱”而不是对着月度总额发愁。5. 安全加固让 OpenClaw 不做“闯祸的 agent”5.1 权限边界先收窄再放开OpenClaw 跑在本地时很多人习惯直接让它以当前用户身份运行文件系统随便访问网络随便连命令随便执行。这在只跑 hello world 的时候没问题一旦技能多了、任务复杂了就非常危险。我给 OpenClaw 定过一个基线所有能力默认关闭按需开放。具体来说每一类技能都明确声明自己需要什么权限然后由框架层统一控制。如果某个技能需要读开发目录下的日志那就只给它读这个目录的权限不开放整个用户目录需要连外部服务就只允许访问指定域名列表需要执行命令就把它限制在专用工作目录内。这套“最小权限”原则单 Agent 时就要做多 Agent 时更是刚性要求因为每个 worker 的权限应该窄到只剩下自己那点活。5.2 密钥和敏感信息怎么管我见过最离谱的配置是有人把外部服务的 API key 直接写在skill.json的description字段里理由是“这样模型调用时能自己带上去”。结果日志一打印密钥直接暴露在审计记录里。正确做法是所有密钥放进环境变量或者系统级密钥管理服务中技能代码运行时从环境变量读取OpenClaw 的日志记录层自动对形似密钥的字符串打码。如果技能脚本需要把敏感数据写入文件也要注意文件权限设为 600用完即删。在多 Agent 架构里还要特别注意共享状态库不能存放密钥或敏感字段。之前我们提到 worker 把数据写入共享状态库这里就要做一个脱敏步骤入库前把邮箱、手机号、密钥、姓名等字段替换为占位符需要时再通过专门渠道取原始值。5.3 敏感动作的二次确认机制有些操作的破坏力特别大比如删除文件、批量发送消息、修改数据库、执行高风险命令。我的建议是不要在 agent 工作流里放开这些操作的自动执行。OpenClaw 可以配置“高风险动作审批”当 agent 想执行某个危险技能时先暂停生成一个确认请求只有用户明确回复一个预设的确认口令比如“confirm DANGEROUS_ACTION”才真正执行。实操中我觉得最实用的做法是为高风险技能设置独立执行目录。普通技能跑在共享工作区高风险技能必须把参数写入一个专门的目录然后由外部脚本监听该目录并执行执行前检查确认标记文件。这样即使 agent 被恶意提示词诱导它最多生成一个待执行的“危险任务文件”没有用户手动确认外部脚本不会动执行。这个机制简单、可靠而且不依赖模型的安全对齐。5.4 审计日志怎么记才有效安全系统里最容易被忽略、出事时最有用的就是审计日志。OpenClaw 本身会记录一些运行日志但那是技术日志不是审计日志。审计日志要记录的是业务层面的“谁做了什么”至少要包含触发来源、任务类型、执行 agent、使用的技能、涉及的文件或接口、结果状态、耗时。我自己维护一张简单的任务审计表时间触发来源Agent技能目标资源结果耗时2025-06-21 09:00:12定时任务coordinatordaily_report/reports/daily_report_20250621.md成功3.2秒2025-06-21 09:03:45用户对话worker_aweb_crawlernews.example.com失败0.8秒这张表不需要很复杂但一定要固化保留。出现问题时你能快速定位是哪个技能、哪个 agent、操作了什么资源。另外建议对“失败任务”单独加一份日志很多安全问题恰恰藏在反复失败的尝试里——比如有人连续试探删除文件如果每次都被权限拦下审计日志里就会有一串醒目的失败记录。6. 实战技巧与排查实录6.1 任务挂起不动先看这四层OpenClaw 用久了几乎每个人都遇到过任务莫名其妙挂起的情况。我先说你最不需要做的事不要在 UI 界面反复点重试那不是排查是赌博。我的排查顺序是四层先看任务状态再看队列堆积然后看技能日志最后看外部依赖。第一层运行openclaw agent status或查看 dashboard确认任务是被哪个 agent 接走的、当前处于什么状态。第二层检查消息队列积压如果 Redis 里堆积了大量未消费任务可能是某个 worker 已经崩溃或者处理速度跟不上。第三层打开对应技能的运行日志看脚本执行到哪一步停了是卡在网络请求上还是在等待文件锁。第四层检查外部依赖比如调用的 HTTP 接口是否超时、数据库连接是否断了。按照这个顺序排查绝大多数挂起问题能在十分钟内定位。6.2 上下文溢出和循环重试的止损方案上下文溢出是多轮任务里的常客尤其是那些“连续对话数小时”的场景。我的止损方案是在配置里加一条硬性规则当上下文 token 数接近阈值时强制触发一个“上下文整理”技能——把当前会话中已经完成的任务结果摘要化然后把完整历史归档到本地文件之后对话从摘要继续。这个方案比简单粗暴地清空上下文要好因为主要意图和重要结论不会丢。循环重试则是另一个大坑。技能脚本里写了重试结果外部接口持续报错脚本就一直重试直到触发timeout_seconds然后模型又判断“任务未完成”再次自动调用形成死循环。应对方法是两层限制技能内部重试次数不超过 3 次每次退避增长1 秒、2 秒、4 秒OpenClaw 层面的任务级限制设定max_invocations同一个技能在单个任务流里最多调用 N 次超过后直接返回失败并通知用户。6.3 环境问题路径、依赖与时区很多 OpenClaw 技能脚本“在作者机器上能跑到用户机器上就挂”几乎都是三个问题路径写死、依赖缺失、时区不一致。路径方面不要在脚本里写绝对路径/home/xxx/openclaw/xxx一定要用相对路径或者从环境变量读取工作目录。依赖方面每个技能最好有独立的虚拟环境不要把一堆依赖全局安装否则技能 A 升级库之后技能 B 突然运行不了。时区方面日志、任务调度、时间戳尽量统一用 UTC 存储只在展示时转成本地时区。我吃过一次亏某个定时任务因为本地时区配置问题每天提前八小时执行生成的日报日期全错。6.4 常见问题速查表现象可能原因解决方式任务一直处于 pendingworker 未启动或崩溃检查 worker 进程状态重启并查看启动日志技能触发不准skill.json 中 description 太宽泛重写描述明确触发条件和输入格式多次调用同一技能但结果一样上下文被裁剪缺少关键前提检查任务上下文摘要是否保留了必要约束费用骤增循环重试或上下文膨胀设置 max_invocations、每日 token 上限、上下文整理agent 能访问我不希望它访问的目录权限边界未设置按技能最小化配置 read/write 白名单状态库数据被覆盖多 worker 并发写同一状态加文件锁或用 Redis 原子操作或串行化写入升级后技能全部失效依赖或路径变动升级前备份配置升级后先跑一遍全部技能的 dry-run 测试6.5 配置备份和升级前的稳定操作进阶用户一定要养成一个习惯把 OpenClaw 的配置目录做成 git 仓库。技能、配置、状态模板都是文本文件用 git 管理之后每一次改动都有记录出问题可以快速 diff 和回滚。多 Agent 架构下这一点尤其重要因为一次改配置可能波及多个 worker你根本记不住之前哪个版本是好的。另外升级 OpenClaw 之前先跑一遍所有技能的内置测试。我自己的做法是写了一个简单的 shell 脚本遍历所有技能目录逐个执行--dry-run检查是否能正常解析参数并生成计划动作最后再跑几个关键任务的真实执行测试。全部通过才升级主程序否则先冻结版本把问题定位完再走升级流程。用 OpenClaw 这么长时间我最大的体会是它不是一个“装完就完事”的工具是一个需要持续调整和约束的系统。技能、多 Agent、省钱、安全每一块单独拿出来都不复杂难的是把它们整合在一起让 agent 在无人值守时也表现得可靠。最后再分享一个小技巧给所有高风险技能加一个--dry-run模式在正式执行前让 agent 先输出“它打算做什么”。这个模式平时不消耗多少 token但能在自动化任务上线前预演一遍流程我靠它避开过好几次配置错误引发的误操作。
