1. 为什么需要“数字打工人”OpenClaw 子 Agent 定时任务能解决什么如果你手里有一台常年运行的服务器或者维护着几个小项目大概率经历过这样的场景半夜服务挂了第二天早上才发现磁盘悄悄写满直到某个接口报错才后知后觉每天重复的巡检、日志清理、状态汇报占用了大量本该用来写代码的时间。这些事技术含量不高但必须有人盯着。OpenClaw 的子 Agent 加定时任务就是把这部分“盯梢”工作交给一个能自己判断、自己动手的程序我把它叫做“数字打工人”。OpenClaw 本身是一个支持多 Agent 协作的自动化框架你可以把它理解成一个调度中心主 Agent 负责接收任务和汇总结果子 Agent 负责执行具体动作定时任务负责在指定时间唤醒它们。它适合谁适合有一定 Linux 基础、会写简单 Shell 脚本、希望把重复运维工作自动化的开发者。你不需要是运维专家只要能看懂 curl 和 ssh 命令就能跟着这篇把最小闭环跑起来。这篇要交付的东西很具体用 TaoToken 统一 Key 接入模型服务配置好 settings.json 和 config.toml 两个骨架文件再设置定时任务触发 Shell 和 SSH 操作。最终效果是你只负责看推送它负责干活。整个过程我会把可复制的配置片段、验证命令、以及我踩过的坑都写清楚你照着做就能跑通。在开始之前先明确“数字打工人”的能力边界。它能做的是按固定频率检查服务状态、发现异常后尝试重启、把结果汇总成消息推给你、遇到复杂问题调用模型分析原因。它不能做的是替代你写业务代码、处理需要人工决策的复杂故障、在没有授权的情况下操作生产数据库。把边界划清楚后面配置起来心里有数。我试过把这套东西用在一个个人项目上服务器是一台 2 核 4G 的云主机跑着 Nginx 和一个 Node 服务。之前每周至少手动登录检查两次配好之后基本不用管只有收到告警才上去看一眼。下面从接入配置开始一步步来。2. TaoToken 统一 Key 接入settings.json 与 config.toml 骨架配置OpenClaw 要调用模型能力需要一个稳定的 API 通道。TaoToken 提供统一的 Key 和 Base URL把模型调用集中管理避免在多个配置文件里散落不同的密钥。这一章先把接入配置做完后面所有子 Agent 和定时任务都复用这个通道。先拿到 Key。访问 TaoToken 的 API Keys 页面https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite创建一个新 Key复制出来备用。注意这个 Key 只在创建时显示一次丢了就得重新生成。拿到之后我们分两个文件来配置settings.json 管模型和运行时参数config.toml 管 Agent 和定时任务的骨架。先看 settings.json。这个文件通常放在 OpenClaw 的工作目录下比如~/.openclaw/settings.json。它的作用是告诉 OpenClaw 用哪个模型、走哪个 API 地址、超时多久。下面是我实测可用的片段你把 Key 替换成自己的{ model: { provider: openai-compatible, baseUrl: https://taotoken.net/api, apiKey: sk-你的TaoToken密钥, modelId: claude-sonnet-4-20250514, timeoutSeconds: 120, maxRetries: 2 }, runtime: { workspace: ~/.openclaw/workspace, logLevel: info, logDir: ~/logs } }这里有几个参数需要说明。provider填openai-compatible因为 TaoToken 的 API 兼容 OpenAI 的调用格式。baseUrl固定为https://taotoken.net/api不要加多余的路径。modelId按你实际要用的模型填我用的 Claude 系列在长文本分析和代码理解上比较稳。timeoutSeconds给 120 秒因为有些分析任务需要读日志再推理时间太短会中断。maxRetries设 2网络抖动时自动重试避免误报。再看 config.toml。这个文件管 Agent 定义和定时任务的骨架通常放在~/.openclaw/config.toml。它和 settings.json 的分工是settings.json 管“用什么模型”config.toml 管“谁在什么时间做什么”。下面是骨架[gateway] host 127.0.0.1 port 8765 [agent.main] name main description 主控 Agent负责任务分发和结果汇总 model default sessionTarget isolated [agent.fixer] name fixer description 修复子 Agent负责执行 Shell 和 SSH 操作 model default sessionTarget isolated allowedTools [shell, ssh] [cron.monitor] name 服务器存活监控 agentId main schedule every 1h enabled true [cron.morning-report] name 每日晨报 agentId main schedule 0 9 * * * enabled truegateway段是本地调度服务的监听地址保持默认即可。agent.main是主 Agent所有定时任务默认由它接收它再决定是否派给子 Agent。agent.fixer是专门干活的子 AgentallowedTools里只给了shell和ssh这是最小权限原则避免它误操作其他资源。cron段先定义两个任务骨架具体的 payload 我们在下一章填。配置写完后用一条命令验证模型通道是否通curl -s https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:回复 OK}],max_tokens:10}如果返回的 JSON 里choices[0].message.content包含 OK说明 Key 和 Base URL 都没问题。这一步很关键后面所有子 Agent 都依赖这个通道通道不通定时任务跑起来也是白跑。如果返回 401检查 Key 是否复制完整如果返回local proxy failed检查 baseUrl 是否写成了带路径的地址。排障细节在第五章展开。3. 可复制配置子 Agent 定时任务触发 Shell 与 SSH 的完整片段上一章的 config.toml 只是骨架这一章把定时任务的 payload 填完整让子 Agent 真正能触发 Shell 和 SSH。OpenClaw 的定时任务支持两种调度方式every按间隔重复cron按表达式定时。我们分别配一个监控任务和一个晨报任务覆盖这两种方式。先配监控任务。它的逻辑是每小时执行一次检查脚本如果发现异常先告警再调用修复子 Agent 尝试重启最后汇报结果。在 config.toml 的[cron.monitor]下面补充 payload[cron.monitor] name 服务器存活监控 agentId main schedule every 1h enabled true [cron.monitor.payload] kind agentTurn message 执行 ~/scripts/check-server.sh。 如果输出包含「异常」 (1) 先告警服务器异常正在尝试自动修复 (2) 调用 fixer 子 Agent 执行 ~/scripts/fix-server.sh (3) 再次执行 check-server.sh 确认状态 (4) 汇报最终结果 如果输出包含「正常」不输出任何内容。 要求不要回复 HEARTBEAT_OK不要调用 message 工具每步操作简短汇报。 [cron.monitor.delivery] mode announce这里的关键设计有三点。第一schedule every 1h表示每小时触发一次OpenClaw 内部会换算成毫秒。第二sessionTarget在 agent 定义里已经设为isolated意味着每次任务在独立会话里跑不会污染主对话的上下文。第三message 里写了条件判断正常时静默只有异常才输出避免每小时都给你推一条“一切正常”的骚扰消息。再配晨报任务。它用 cron 表达式每天早上 9 点触发汇总昨日服务器状态、今日天气和待办事项[cron.morning-report] name 每日晨报 agentId main schedule 0 9 * * * enabled true [cron.morning-report.payload] kind agentTurn message 生成今日晨报包含 (1) 昨日服务器监控结果读取 ~/logs/server.log 最后 20 行 (2) 今日天气查询所在城市天气 (3) 今日待办读取 ~/notes/todo.md 格式简洁清晰每项 2-3 句话。 要求不要回复 HEARTBEAT_OK不要调用 message 工具直接输出晨报内容。 [cron.morning-report.delivery] mode announcecron 表达式0 9 * * *的含义是分 时 日 月 星期这里表示每天 9 点 0 分。如果你只想工作日推送改成0 9 * * 1-5即可。注意时区问题OpenClaw 默认用系统时区如果你的服务器是 UTC 时间9 点会变成北京时间下午 5 点需要在 settings.json 里显式指定时区或者用带偏移的 ISO 时间。接下来写两个 Shell 脚本。检查脚本放在~/scripts/check-server.sh#!/bin/bash SERVERhttps://your-server.com TIMEOUT10 RESPONSE$(curl -s -o /dev/null -w %{http_code} --max-time $TIMEOUT $SERVER/health) if [ $RESPONSE 200 ]; then echo 服务器正常 (HTTP $RESPONSE) exit 0 else echo 服务器异常 (HTTP $RESPONSE 或无法连接) exit 1 fi修复脚本放在~/scripts/fix-server.sh#!/bin/bash SERVERuseryour-server.com SERVICEnginx echo 尝试重启 $SERVER 上的 $SERVICE... ssh $SERVER sudo systemctl restart $SERVICE echo 重启成功 || echo 重启失败两个脚本都要加执行权限chmod x ~/scripts/*.sh。修复脚本依赖 SSH 免密登录配置方法在第五章。这里要提醒一句SSH 操作的目标是你自己的服务器不要把它指向生产数据库或未经授权的第三方主机。子 Agent 的allowedTools只给了 shell 和 ssh但权限控制的第一道关还是你自己的脚本内容。配置写完后用openclaw cron list查看任务是否注册成功。正常输出会列出任务名、调度间隔、启用状态和下次执行时间。如果任务没出现检查 config.toml 的 TOML 语法尤其是多行字符串的引号是否配对。4. 验证请求与成功结果从手动触发到自动闭环配置写完不代表能跑这一章做验证。验证分三步先手动触发单个任务确认脚本能执行再模拟一次故障确认告警和修复链路通最后看日志确认整个闭环有记录。第一步手动触发监控任务。用openclaw cron run jobId命令jobId 从openclaw cron list的输出里拿。触发后观察终端输出正常情况会看到类似这样的流程[monitor] 执行 check-server.sh [monitor] 输出服务器正常 (HTTP 200) [monitor] 正常状态静默退出如果脚本本身有问题比如 curl 命令写错或者服务器地址不通这里会直接报错。先确保手动执行~/scripts/check-server.sh能返回预期结果再让 OpenClaw 去调。第二步模拟故障。临时停掉服务sudo systemctl stop nginx。然后再次手动触发监控任务。预期输出应该是[monitor] 执行 check-server.sh [monitor] 输出服务器异常 (HTTP 000 或无法连接) [monitor] 告警服务器异常正在尝试自动修复 [monitor] 调用 fixer 子 Agent [fixer] 执行 fix-server.sh [fixer] 输出重启成功 [monitor] 再次检查 [monitor] 输出服务器正常 (HTTP 200) [monitor] 汇报服务器已恢复看到这个流程说明子 Agent 调用、Shell 执行、SSH 远程操作、结果回传都通了。如果卡在某一步比如 fixer 子 Agent 没被调用检查 config.toml 里agent.fixer的定义和主 Agent 的 message 里是否明确写了“调用 fixer 子 Agent”。第三步看日志。监控日志在~/logs/server.log告警记录在~/logs/alerts.log。用tail -f实时观察tail -f ~/logs/server.log tail -f ~/logs/alerts.log日志里应该能看到每次检查的时间戳、HTTP 状态码、以及修复动作的记录。如果日志文件不存在先手动创建touch ~/logs/server.log ~/logs/alerts.log。OpenClaw 不会自动创建日志文件这是很多人第一次跑会踩的坑。验证模型通道是否在子 Agent 里正常工作可以单独发一个分析请求。比如手动触发一个子 Agent 任务让它分析一段日志{ task: 读取 ~/logs/server.log 最后 50 行分析是否有异常模式输出 3 条以内的结论, runtime: subagent, mode: run, timeoutSeconds: 300 }如果返回的结论合理说明 TaoToken 的模型通道在子 Agent 里也通了。这一步验证的是“数字打工人”的智能部分前面验证的是“手脚”部分两者都通最小闭环才算完整。成功跑通后你可以把监控频率从每小时改成每 30 分钟或者增加磁盘、内存的检查项。但建议先让当前配置稳定运行一天观察有没有误报或漏报再逐步扩展。5. 常见错误排查401、local proxy failed、reading choices 与 OAuth这一章列几个我实际遇到过的报错以及对应的排查路径。这些错误大多出在接入配置和权限环节按顺序检查基本能解决。401 Unauthorized。这是最常见的错误说明 Key 没被正确识别。排查顺序第一检查 settings.json 里apiKey字段是否完整有没有多余空格或换行第二确认 Key 没有过期或被删除去 TaoToken 的 API Keys 页面核对第三检查请求头格式TaoToken 用的是Authorization: Bearer sk-xxxBearer 和 Key 之间有一个空格。如果手动 curl 能通但 OpenClaw 报 401检查 settings.json 的 JSON 语法尤其是引号是否用了中文引号。local proxy failed。这个报错通常出现在 baseUrl 配置错误时。TaoToken 的 API 地址是https://taotoken.net/api不要写成https://taotoken.net/api/v1或者带其他路径。OpenClaw 内部会拼接/v1/chat/completions如果你在 baseUrl 里已经带了/v1就会变成/v1/v1/chat/completions导致 404 或代理失败。另外检查网络是否能正常访问该地址用curl -I https://taotoken.net/api看返回状态码。reading choices 报错。完整报错通常是error reading choices: unexpected end of JSON input或类似。这说明 API 返回了非 JSON 格式的内容可能是空响应、HTML 错误页、或者超时截断。排查第一检查timeoutSeconds是否太短复杂分析任务给到 120 秒以上第二检查max_tokens是否设得过大导致响应被截断第三用 curl 手动发一次同样的请求看原始返回是什么。如果返回的是 HTML说明请求打到了错误的地址。OAuth 相关报错。如果你用的是 Claude Code 或类似的 OAuth 授权流程报错可能是OAuth token expired或invalid_grant。这种情况需要重新走授权流程或者在 settings.json 里改用 API Key 方式接入。TaoToken 的 API Key 方式不依赖 OAuth配置更简单推荐优先用这种方式。如果同时配了 OAuth 和 API Key检查是否有冲突通常保留一种即可。SSH 免密登录失败。修复脚本报Permission denied (publickey)说明免密没配好。步骤本地生成密钥ssh-keygen -t rsa -b 4096复制公钥到服务器ssh-copy-id useryour-server.com测试ssh useryour-server.com echo SSH OK。如果服务器上 sudo 需要密码修复脚本里的sudo systemctl restart会卡住需要在 sudoers 里给该用户免密权限或者改用不需要 sudo 的重启方式。cron 时区偏差。任务比预期早或晚 8 小时检查系统时区date %z。如果是0000说明是 UTC 时间需要在 settings.json 里加时区配置或者把 cron 表达式按 UTC 调整。更稳妥的做法是用带偏移的 ISO 时间格式比如2026-05-08T09:00:0008:00。脚本执行权限。报Permission denied时先chmod x ~/scripts/*.sh。如果还不行检查脚本的 shebang 行#!/bin/bash是否存在以及文件路径是否写对。OpenClaw 执行脚本时用的是绝对路径~/scripts/会被展开成用户主目录确认展开后的路径确实存在。日志文件不存在。grep 报No such file or directory先touch ~/logs/server.log ~/logs/alerts.log。OpenClaw 不会自动创建日志文件这是设计上的选择需要你手动初始化。建议在部署脚本里加一行创建命令避免每次重装都忘。排查完这些如果还有问题去 TaoToken 的接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite核对最新的接口格式和参数说明。文档里的示例是最权威的参考。6. 长期运行与扩展Coding Plan 与子 Agent 协作的下一步最小闭环跑通后你可以考虑把它扩展成更完整的自动化体系。这一章聊两个方向一是用 Coding Plan 降低长期调用的成本二是让多个子 Agent 分工协作处理更复杂的场景。先说成本。定时任务如果频率高、分析任务多模型调用量会累积。TaoToken 的 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite适合长期编码和 Agent 场景按套餐计费比按次调用更划算。如果你的监控任务从每小时一次增加到每 15 分钟一次或者增加了日报、周报、智能分析等多个任务建议评估一下调用量选合适的套餐。配置方式不变还是在 settings.json 里填同一个 Key套餐生效后调用会自动走套餐额度。再说协作。目前我们只配了一个 fixer 子 Agent实际场景里可以拆得更细。比如加一个analyzer子 Agent专门负责读日志、分析异常模式、给出排查建议加一个reporter子 Agent专门负责汇总数据、生成日报周报。主 Agent 根据任务类型分派给不同的子 Agent每个子 Agent 只拿到自己需要的工具权限。这样做的目的是隔离风险analyzer 只需要读日志的权限不需要 SSHreporter 只需要读数据不需要执行 Shell。配置多个子 Agent 的方式和 fixer 类似在 config.toml 里加[agent.analyzer]和[agent.reporter]段分别指定allowedTools。然后在定时任务的 message 里写明“调用 analyzer 子 Agent 分析”或“调用 reporter 子 Agent 生成报告”。主 Agent 会根据 message 里的指令路由。还有一个扩展方向是接入 MCP 协议。OpenClaw 支持通过 MCP 连接外部工具比如监控平台、云服务 API、数据库查询接口。这样“数字打工人”的能力就不限于 Shell 和 SSH还能直接查监控指标、拉云服务账单、读数据库状态。MCP 的配置在 config.toml 里加[mcp.xxx]段具体参数参考对应工具的文档。注意不要直连生产库用只读账号或者走 API 网关。最后提醒一点自动化程度越高越要保留人工确认的环节。比如自动修复可以配成“先告警等 5 分钟如果没人工干预再自动修复”避免在你不注意的时候反复重启服务。OpenClaw 的failureAlert配置支持失败重试和延迟告警合理利用这些参数能让“数字打工人”更可靠。整套配置跑下来你得到的是一个能自己检查、自己修复、自己汇报的自动化助手。它不完美但能帮你省下大量重复劳动的时间。后续要做的是根据实际运行情况调整频率、补充检查项、优化告警文案让它越来越贴合你的工作节奏。