Skip to Content

24b - 自定义 Agent 开发教程

本文是《AI Agent 实战手册》第 24 章第 2 节。 上一节:24a-插件架构 | 下一节:24c-自定义集成教程

概述

OpenClaw 的核心设计哲学是”文本即系统”(Text-as-System)——Agent 的角色、行为、工具权限和调度策略全部通过 Markdown 文件和 JSON 配置定义,而非硬编码的 Python 类或 TypeScript 模块。本节提供从零构建自定义 Agent 的完整教程,覆盖角色定义(SOUL.md / IDENTITY.md)、工具绑定与权限策略、调度与触发机制(Heartbeat / Cron / Webhook)、输出通道配置以及多 Agent 协作模式,帮助你将 OpenClaw 从通用助手打造为专属领域 Agent。


1. Agent 角色定义

OpenClaw Agent 的”人格”由一组 Markdown 文件构成,这些文件在每次 Agent Turn 开始时被读取并注入系统提示词。理解这些文件的职责划分是构建自定义 Agent 的第一步。

核心身份文件体系

~/.openclaw/workspace/ # 或 agentDir 指定的目录 ├── SOUL.md # 哲学层:Agent 是谁(价值观、世界观) ├── IDENTITY.md # 表现层:Agent 如何表达自己(风格、语气) ├── MEMORY.md # 记忆层:Agent 积累的长期知识 ├── HEARTBEAT.md # 行为层:Agent 主动做什么(定时检查清单) ├── AGENTS.md # 入口层:会话启动规则和 Agent 列表 ├── GOALS.md # 目标层:高层目标和胜利条件 ├── TASKS.md # 任务层:中层里程碑 ├── GUIDELINES.md # 约束层:安全围栏和权限规则 └── TOOLS.md # 工具层:可用工具和使用规则
文件职责加载时机修改频率
SOUL.md定义 Agent 的核心哲学、价值观和沟通风格每次 Agent Turn极少(设定后基本不变)
IDENTITY.md定义 Agent 的具体用途、能力边界和行为规则每次 Agent Turn偶尔(角色调整时)
MEMORY.md存储长期事实、项目约束、用户偏好每次 Agent Turn频繁(Agent 自动更新)
HEARTBEAT.md定义定时主动行为的检查清单Heartbeat 触发时按需(添加/移除检查项)
GOALS.md高层目标和可量化的胜利条件每次 Agent Turn按项目阶段更新
GUIDELINES.md安全围栏、禁止操作、权限矩阵每次 Agent Turn极少

SOUL.md 编写指南

SOUL.md 是 Agent 人格的”灵魂”文件,定义的是 Agent 是谁,而非 Agent 做什么。OpenClaw 官方模板的开头是:“You’re not a chatbot.”——这句话奠定了整个设计基调。

核心原则:SOUL.md 应该回答三个问题:

  1. 这个 Agent 的核心信念是什么?
  2. 它如何看待与用户的关系?
  3. 它的沟通风格是什么?

SOUL.md 模板

# Soul ## Core Philosophy 你是一个 [角色定位]。你的核心使命是 [使命描述]。 ## Values - **[价值观 1]**:[具体说明] - **[价值观 2]**:[具体说明] - **[价值观 3]**:[具体说明] ## Communication Style - 语气:[正式/随意/技术性/友好] - 回复长度偏好:[简洁/详细/视情况而定] - 使用 emoji:[是/否/适度] - 语言:[中文/英文/双语] ## Relationship with User 你和用户的关系是 [合作伙伴/助手/导师/同事]。 当用户犯错时,你会 [直接指出/委婉建议/提供替代方案]。 当你不确定时,你会 [明确说明/请求澄清/给出最佳猜测并标注]。 ## Boundaries - 你不会 [边界 1] - 你不会 [边界 2] - 当被要求做超出能力范围的事时,你会 [处理方式]

DevOps Agent 的 SOUL.md 示例

# Soul ## Core Philosophy 你是一个经验丰富的 DevOps 工程师。你相信自动化优于手动操作, 可观测性优于猜测,渐进式变更优于大爆炸部署。 ## Values - **可靠性第一**:任何操作都先考虑回滚方案 - **最小权限**:只请求完成任务所需的最低权限 - **透明沟通**:每个操作前说明意图,操作后报告结果 ## Communication Style - 语气:专业但不冷漠,像一个靠谱的同事 - 回复长度:操作类简洁,解释类详细 - 使用 emoji:适度(✅ ❌ ⚠️ 用于状态标记) - 语言:中英双语(技术术语保留英文) ## Relationship with User 你和用户是平等的技术伙伴。你会主动提出风险警告, 但最终决策权在用户手中。当检测到危险操作时, 你会明确标注 ⚠️ 并要求确认。 ## Boundaries - 你不会在未经确认的情况下执行破坏性操作(rm -rf、DROP TABLE 等) - 你不会存储或传输密钥、密码等敏感信息 - 当被要求做超出能力范围的事时,你会推荐合适的工具或人员

IDENTITY.md 配置

IDENTITY.md 定义 Agent 的具体用途和行为规则,是 SOUL.md 的操作化延伸。如果说 SOUL.md 是”我是谁”,IDENTITY.md 就是”我具体做什么”。

IDENTITY.md 必需结构

# Identity ## Definition [1-2 句话定义 Agent 的具体角色和职责范围] ## Rules | # | Rule | |---|------| | 1 | [具体行为规则] | | 2 | [具体行为规则] | | 3 | [具体行为规则] | ## Decision Table | Situation | Response | |-----------|----------| | 遇到未知错误 | 先查日志,再搜索文档,最后请求用户帮助 | | 用户请求超出权限 | 说明原因,建议替代方案 | | 任务耗时超过预期 | 每 5 分钟汇报进度 | | 多个任务冲突 | 按优先级排序,询问用户确认 |

DevOps Agent 的 IDENTITY.md 示例

# Identity ## Definition 我是团队的 DevOps 自动化助手,专注于 CI/CD 管线维护、 基础设施监控和部署自动化。我的工作范围覆盖 AWS 基础设施、 GitHub Actions 工作流和 Kubernetes 集群管理。 ## Rules | # | Rule | |---|------| | 1 | 所有部署操作必须先在 staging 环境验证 | | 2 | 修改基础设施配置前必须生成 terraform plan | | 3 | 监控告警响应时间不超过 2 分钟 | | 4 | 每次操作后更新 MEMORY.md 中的操作日志 | | 5 | 涉及生产环境的操作必须等待用户确认 | ## Decision Table | Situation | Response | |-----------|----------| | 收到 P1 告警 | 立即通知用户,同时开始诊断 | | 部署失败 | 自动回滚,收集日志,生成事后分析 | | 资源使用率 > 80% | 发送预警,建议扩容方案 | | 证书即将过期 | 提前 30 天提醒,提供续期步骤 |

人格与行为风格

OpenClaw 支持通过 Hook 系统实现动态人格切换,让同一个 Agent 在不同场景下展现不同的行为风格。

场景化人格配置

{ "hooks": { "internal": { "enabled": true, "entries": { "soul-context": { "enabled": true, "file": "SOUL_WORK.md", "schedule": { "weekdays": ["mon", "tue", "wed", "thu", "fri"], "hours": { "start": "09:00", "end": "18:00" } } } } } } }

⚠️ 安全提醒:动态人格切换功能(如内置的 soul-evil Hook)虽然设计用于上下文自适应,但也可能被恶意 Skill 利用来植入持久化后门。务必定期审查 SOUL.md 的变更历史。详见 24a-插件架构 中的安全分析。


2. 工具绑定与权限

OpenClaw 的工具权限系统是其安全架构的核心。通过多层策略栈,你可以精确控制每个 Agent 能使用哪些工具、在什么场景下使用。

工具推荐

工具/功能用途价格适用场景
openclaw.json全局工具策略配置免费(内置)所有 Agent 配置
Tool Profiles预设工具集合(minimal/coding/messaging/full)免费(内置)快速配置基线权限
Tool Groups工具分组简写(group:fs, group:runtime 等)免费(内置)批量权限管理
Provider Policy按模型提供商限制工具免费(内置)多模型安全隔离
Docker Sandbox容器化执行环境免费(Docker CE)高风险操作隔离
gVisor用户态内核沙箱免费(开源)深度隔离

工具白名单/黑名单

OpenClaw 使用 tools.allow(白名单)和 tools.deny(黑名单)控制工具访问,黑名单优先级高于白名单

基本配置语法

// openclaw.json { "tools": { "allow": ["group:fs", "group:web", "browser"], "deny": ["exec", "bash", "process"] } }

配置规则

规则说明示例
deny 优先同时出现在 allow 和 deny 中时,deny 生效allow: ["*"], deny: ["exec"] → exec 被禁用
大小写不敏感工具名匹配忽略大小写"Browser" 等同于 "browser"
通配符支持* 匹配所有工具deny: ["*"] 禁用所有工具
分组简写group:* 展开为多个工具group:runtime = exec + bash + process
空 allow如果 allow 引用的工具都不存在,OpenClaw 忽略白名单防止配置错误导致 Agent 完全瘫痪

可用工具分组

group:runtime → exec, bash, process group:fs → read, write, edit, apply_patch group:sessions → sessions_list, sessions_history, sessions_send, sessions_spawn, session_status group:memory → memory_search, memory_get group:web → web_search, web_fetch group:ui → browser, canvas group:automation → cron, gateway group:messaging → message group:nodes → nodes group:openclaw → 所有内置 OpenClaw 工具(不含插件工具)

7 层策略配置

OpenClaw 的工具权限检查经过 7 层策略栈,从上到下依次收紧:

┌─────────────────────────────────────────────────────────┐ │ Layer 1: Profile(认证配置文件) │ │ → tools.profile 设置基线:minimal / coding / │ │ messaging / full │ ├─────────────────────────────────────────────────────────┤ │ Layer 2: Provider(模型提供商) │ │ → tools.byProvider 按提供商/模型限制工具 │ │ → 只能收窄,不能扩展 Profile 的范围 │ ├─────────────────────────────────────────────────────────┤ │ Layer 3: Global(全局策略) │ │ → tools.allow / tools.deny 全局白名单/黑名单 │ ├─────────────────────────────────────────────────────────┤ │ Layer 4: Agent(Agent 级别) │ │ → agents.list[].tools 每个 Agent 独立配置 │ ├─────────────────────────────────────────────────────────┤ │ Layer 5: Group(通道安全级别) │ │ → 私聊 vs 公共频道的工具差异 │ │ → 公共频道自动剥离高风险工具 │ ├─────────────────────────────────────────────────────────┤ │ Layer 6: Sandbox(沙箱限制) │ │ → 文件系统访问范围、网络限制 │ ├─────────────────────────────────────────────────────────┤ │ Layer 7: Subagent(子 Agent 授权) │ │ → 父 Agent 授予子 Agent 的权限子集 │ └─────────────────────────────────────────────────────────┘

实际配置示例——多层策略叠加

{ // Layer 1: 基线为 coding 配置 "tools": { "profile": "coding", // Layer 2: Google 模型只允许最小工具集 "byProvider": { "google-antigravity": { "profile": "minimal" } }, // Layer 3: 全局禁用危险工具 "deny": ["group:runtime"] }, // Layer 4: 特定 Agent 覆盖 "agents": { "list": [ { "id": "devops", "tools": { "profile": "full", "deny": ["canvas"] } }, { "id": "support", "tools": { "profile": "messaging", "allow": ["slack"] } } ] } }

自定义工具注册

通过 Plugin API 可以注册自定义工具,扩展 Agent 的能力边界:

// src/tools/deploy-check.ts import type { PluginApi } from '@openclaw/types'; export function register(api: PluginApi) { api.registerTool({ name: 'deploy-check', description: '检查指定环境的部署状态和健康度', parameters: { environment: { type: 'string', description: '目标环境:staging | production', enum: ['staging', 'production'] }, service: { type: 'string', description: '服务名称(可选,默认检查所有服务)', optional: true } }, execute: async ({ environment, service }) => { const endpoint = process.env.DEPLOY_API_URL; const url = service ? `${endpoint}/status/${environment}/${service}` : `${endpoint}/status/${environment}`; const response = await fetch(url, { headers: { 'Authorization': `Bearer ${process.env.DEPLOY_API_KEY}` } }); const data = await response.json(); return { environment, services: data.services, overallHealth: data.health, lastDeployAt: data.lastDeploy, version: data.version }; } }); }

注册后,在 openclaw.json 中控制该工具的访问权限:

{ "agents": { "list": [ { "id": "devops", "tools": { "allow": ["deploy-check", "group:fs", "exec"] } }, { "id": "support", "tools": { "deny": ["deploy-check"] } } ] } }

3. 调度与触发

OpenClaw Agent 的”主动性”来自其事件驱动架构。Agent 并非真正”活着”,而是通过精心设计的调度机制在特定时刻被唤醒执行任务。

Heartbeat 配置

Heartbeat 是 OpenClaw 最核心的主动调度机制——Gateway 按固定间隔向 Agent 发送心跳信号,Agent 读取 HEARTBEAT.md 决定是否需要采取行动。

配置步骤

步骤 1:在 openclaw.json 中启用 Heartbeat

{ "agents": { "defaults": { "heartbeat": { "every": "30m", "model": "anthropic/claude-sonnet-4-5", "target": "telegram", "to": "+8613800138000", "prompt": "Read HEARTBEAT.md if it exists. Follow it strictly. Do not infer or repeat old tasks. If nothing needs attention, reply HEARTBEAT_OK.", "ackMaxChars": 300, "activeHours": { "start": "08:00", "end": "22:00" } } } }, "timezone": "Asia/Shanghai" }

Heartbeat 配置参数说明

参数类型默认值说明
everystring"30m"心跳间隔(支持 15m1h2h30m,设为 0m 禁用)
modelstringAgent 默认模型心跳使用的模型(可选用更便宜的模型节省成本)
targetstring"last"输出通道(telegram / whatsapp / discord / last
tostring目标用户/频道 ID
promptstring内置默认心跳触发时发送给 Agent 的系统提示
ackMaxCharsnumber300非紧急消息的最大字符数
activeHoursobject全天活跃时间窗口,窗口外不触发心跳

步骤 2:创建 HEARTBEAT.md 检查清单

# Heartbeat Checklist ## 早间(8:00-8:30) - 检查 Gmail 中标记为"紧急"的未读邮件 - 拉取今日日历事件 - 获取本地天气 - 生成格式化的早间简报发送到 Telegram ## 全天(9:00-18:00) - 每 30 分钟扫描收件箱,仅提醒 VIP 联系人的邮件 - 如果日历事件在 15 分钟内开始,发送提醒 ## 晚间(18:00) - 汇总 Slack #engineering 频道的未读消息 - 检查 Todoist 中是否有逾期任务 ## 任何时间 - 如果航班在 12 小时内起飞,检查状态并发送更新 - 非紧急事项不要在 22:00-08:00 之间打扰我

步骤 3:测试心跳

# 手动触发一次心跳 openclaw message send --system '{"event": "heartbeat"}' # 查看日志确认 openclaw logs --tail 20 # 预期看到:[Heartbeat] Agent processed heartbeat → HEARTBEAT_OK

成本提示:Heartbeat 每次触发都会消耗 Token。使用 Claude Opus 4.5 时,每天约 $5-30(取决于频率和上下文大小)。建议心跳使用更便宜的模型(如 Claude Haiku),仅在需要复杂推理时切换到高端模型。

Cron 定时任务

Cron 提供精确的时间调度能力,适合需要在固定时间点执行的任务。与 Heartbeat 的区别在于:Heartbeat 是”感知型”(检查是否需要行动),Cron 是”执行型”(到点就做)。

三种调度模式

模式语法用途示例
At--at "2026-03-15 09:00"一次性定时任务20 分钟后提醒我开会
Every--every "6h"固定间隔重复每 6 小时检查一次 PR
Cron--cron "0 9 * * 1"Unix cron 表达式每周一 9:00 生成周报

CLI 创建 Cron 任务

# 每天早上 8 点发送简报(隔离会话) openclaw cron add \ --name "Morning Briefing" \ --cron "0 8 * * *" \ --tz "Asia/Shanghai" \ --session isolated \ --message "生成今日简报:1. 未读邮件摘要 2. 日历事件 3. 天气预报 4. 待办事项" # 每 30 分钟检查 GitHub PR(主会话) openclaw cron add \ --name "PR Review Check" \ --every "30m" \ --session main \ --message "检查我的 GitHub 通知,标记需要我 review 的 PR" # 一次性提醒(20 分钟后) openclaw cron add \ --name "Meeting Reminder" \ --at "in 20m" \ --message "提醒:产品评审会议即将开始"

JSON 配置方式

{ "cron": { "jobs": [ { "id": "morning-briefing", "name": "Morning Briefing", "schedule": "0 8 * * *", "timezone": "Asia/Shanghai", "session": "isolated", "model": "anthropic/claude-sonnet-4-5", "message": "生成今日简报...", "target": "telegram", "enabled": true }, { "id": "weekly-report", "name": "Weekly Report", "schedule": "0 17 * * 5", "timezone": "Asia/Shanghai", "session": "isolated", "message": "生成本周工作总结报告", "target": "slack", "to": "#engineering", "enabled": true } ] } }

主会话 vs 隔离会话

维度主会话(main)隔离会话(isolated)
上下文共享用户对话历史全新空白上下文
隐私可能引用私人对话内容不会泄露历史信息
模型使用 Agent 默认模型可指定不同模型
适用场景需要上下文的跟进任务独立的定时报告
会话 ID复用主会话cron:<jobId>

Webhook 触发

Webhook 允许外部系统通过 HTTP 回调触发 Agent 行为,是连接第三方服务的关键机制。

配置 Webhook 端点

{ "webhooks": { "github-deploy": { "path": "/webhook/github", "secret": "${GITHUB_WEBHOOK_SECRET}", "agent": "devops", "events": ["deployment_status", "workflow_run", "pull_request"] }, "stripe-payment": { "path": "/webhook/stripe", "secret": "${STRIPE_WEBHOOK_SECRET}", "agent": "finance", "events": ["payment_intent.succeeded", "invoice.payment_failed"] }, "sentry-alert": { "path": "/webhook/sentry", "secret": "${SENTRY_WEBHOOK_SECRET}", "agent": "devops", "events": ["issue.created", "issue.resolved"] } } }

Webhook 安全最佳实践

  1. 始终验证签名:使用 secret 字段配置 HMAC 签名验证
  2. 限制事件类型:通过 events 字段只接收需要的事件
  3. 指定目标 Agent:通过 agent 字段路由到专门的 Agent
  4. 使用 HTTPS:生产环境必须通过反向代理(Nginx/Caddy)提供 TLS

事件驱动模式

OpenClaw 的所有输入最终都汇入统一的事件队列,遵循”5+1”模型:

┌──────────────────────────────────────────────────────────┐ │ 事件驱动调度总览 │ │ │ │ 用户消息 ──┐ │ │ Heartbeat ─┤ │ │ Cron ──────┼──→ 事件队列 ──→ Agent Turn ──→ 动作执行 │ │ Webhook ───┤ ↑ │ │ Hook ──────┤ │ │ │ A2A ───────┘ 同一会话内 │ │ 严格顺序执行 │ └──────────────────────────────────────────────────────────┘

调度方式选择决策树

需要 Agent 主动行为? ├── 否 → 仅响应用户消息(默认模式) └── 是 → 需要精确时间点? ├── 是 → 使用 Cron │ ├── 一次性 → at 模式 │ ├── 固定间隔 → every 模式 │ └── 复杂调度 → cron 表达式 └── 否 → 需要上下文感知? ├── 是 → 使用 Heartbeat(带 HEARTBEAT.md 检查清单) └── 否 → 外部系统触发? ├── 是 → 使用 Webhook └── 否 → 使用 Agent 间消息(A2A)

4. 输出通道配置

OpenClaw 支持 12+ 消息平台,Agent 的输出可以路由到任意通道组合。

多平台消息路由

通道配置概览

通道集成方式配置复杂度适用场景价格
TelegramBot API个人助手、团队通知免费
WhatsAppBaileys(Web 协议)客户沟通、移动端免费(非官方)
DiscordDiscord.js团队协作、社区免费
SlackSlack API企业团队免费(基础)/ $8.75/人/月起
iMessageAppleScript 桥接macOS 用户免费
Web UIWebSocket浏览器访问免费
TerminalCLI最低开发调试免费
MS TeamsPlugin企业环境需 Teams 许可
MatrixPlugin隐私优先免费(自托管)
Voice CallPlugin语音交互按通话计费

多通道路由配置

{ "channels": { "telegram": { "enabled": true, "token": "${TELEGRAM_BOT_TOKEN}", "allowedUsers": ["+8613800138000"] }, "discord": { "enabled": true, "token": "${DISCORD_BOT_TOKEN}", "guilds": ["1234567890"] }, "slack": { "enabled": true, "token": "${SLACK_BOT_TOKEN}", "channels": ["#engineering", "#alerts"] } }, "agents": { "list": [ { "id": "devops", "heartbeat": { "target": "slack", "to": "#alerts" } }, { "id": "personal", "heartbeat": { "target": "telegram", "to": "+8613800138000" } } ] } }

通道优先级

当 Agent 需要主动发送消息时(如 Heartbeat 或 Cron 触发),通道选择遵循以下优先级:

  1. 显式指定:配置中 target + to 明确指定的通道和目标
  2. 最后使用target: "last" 发送到用户最近一次交互的通道
  3. 默认通道:Agent 配置中的默认通道
  4. 回退:如果所有通道不可用,记录到日志

按事件类型路由

{ "agents": { "list": [ { "id": "devops", "routing": { "heartbeat": { "target": "slack", "to": "#ops-alerts" }, "cron": { "target": "telegram", "to": "+8613800138000" }, "webhook": { "target": "discord", "to": "#deploy-log" } } } ] } }

格式适配

不同通道对消息格式的支持不同,Agent 会自动适配:

格式特性TelegramDiscordSlackWhatsAppTerminal
Markdown✅ 部分✅ 完整❌ mrkdwn❌ 有限✅ 完整
代码块
图片
文件附件
按钮/交互✅ Inline✅ Components✅ Block Kit
消息长度限制4096 字符2000 字符40000 字符65536 字符无限制

提示:在 SOUL.md 中可以指导 Agent 根据当前通道调整输出格式。例如:“在 Telegram 中使用简洁格式,在 Slack 中使用 Block Kit 富文本。“


5. 多 Agent 配置

Agent 配置文件结构

OpenClaw 支持在同一个 Gateway 实例上运行多个 Agent,每个 Agent 拥有独立的工作空间、会话存储和认证上下文。

AGENTS.md 入口文件

# Agents ## Agent Registry | ID | Role | Channels | Status | |----|------|----------|--------| | personal | 个人助手 | Telegram, Terminal | Active | | devops | DevOps 自动化 | Slack, Discord | Active | | research | 研究助手 | Web UI | Active | | support | 客服 Agent | WhatsApp | Active |

openclaw.json 多 Agent 配置

{ "agents": { "defaults": { "model": "anthropic/claude-sonnet-4-5", "heartbeat": { "every": "30m" } }, "list": [ { "id": "personal", "default": true, "agentDir": "~/.openclaw/agents/personal", "model": "anthropic/claude-sonnet-4-5", "tools": { "profile": "full" }, "heartbeat": { "every": "30m", "target": "telegram", "activeHours": { "start": "08:00", "end": "22:00" } } }, { "id": "devops", "agentDir": "~/.openclaw/agents/devops", "model": "anthropic/claude-sonnet-4-5", "tools": { "profile": "coding", "allow": ["deploy-check", "group:runtime"] }, "heartbeat": { "every": "15m", "target": "slack", "to": "#ops-alerts" } }, { "id": "research", "agentDir": "~/.openclaw/agents/research", "model": "google/gemini-2.5-pro", "tools": { "allow": ["group:web", "group:fs", "group:memory"], "deny": ["group:runtime"] }, "heartbeat": { "every": "0m" } }, { "id": "support", "agentDir": "~/.openclaw/agents/support", "model": "anthropic/claude-haiku-4", "tools": { "profile": "messaging" }, "heartbeat": { "every": "5m", "target": "whatsapp" } } ] } }

Agent 隔离边界

┌─────────────────────────────────────────────────────┐ │ Gateway 进程 │ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Personal │ │ DevOps │ │ Research │ │ │ │ Agent │ │ Agent │ │ Agent │ │ │ ├──────────┤ ├──────────┤ ├──────────┤ │ │ │ 工作空间 │ │ 工作空间 │ │ 工作空间 │ │ │ │ 会话存储 │ │ 会话存储 │ │ 会话存储 │ │ │ │ 认证上下文│ │ 认证上下文│ │ 认证上下文│ │ │ │ SOUL.md │ │ SOUL.md │ │ SOUL.md │ │ │ │ MEMORY.md│ │ MEMORY.md│ │ MEMORY.md│ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ ↕ ↕ ↕ │ │ 完全隔离:文件、会话、凭证互不共享 │ │ (除非通过 sessions_spawn 显式通信) │ └─────────────────────────────────────────────────────┘

多 Agent 协作模式

模式 1:编排者模式(Orchestrator)

一个主 Agent 负责任务分发,子 Agent 负责执行:

<!-- 主 Agent 的 IDENTITY.md --> # Identity ## Definition 我是团队编排者,负责接收用户请求并分发给专业 Agent。 ## Delegation Rules | 任务类型 | 委派给 | 方式 | |---------|--------|------| | 代码相关 | devops | sessions_spawn | | 研究调查 | research | sessions_spawn | | 客户沟通 | support | sessions_spawn | | 其他 | 自己处理 | 直接执行 |

模式 2:对等协作模式(Peer-to-Peer)

多个 Agent 通过共享 MEMORY.md 或消息传递协作:

{ "agents": { "list": [ { "id": "coder", "agentDir": "~/.openclaw/agents/coder", "tools": { "profile": "coding" } }, { "id": "reviewer", "agentDir": "~/.openclaw/agents/reviewer", "tools": { "allow": ["group:fs", "group:web"], "deny": ["write", "edit", "exec"] } } ] } }

模式 3:AI 委员会模式(Roundtable)

多个 Agent 对同一问题提供不同视角,由用户或编排者综合决策。详见 24d-Agent间通信


实战案例:从零构建一个 DevOps Agent

以下是一个完整的端到端案例,展示如何从零构建一个专注于 DevOps 自动化的 OpenClaw Agent。

需求分析

  • 监控 GitHub Actions 部署状态
  • 每天早上发送基础设施健康报告
  • 响应 Sentry 错误告警
  • 通过 Slack 和 Telegram 双通道通知
  • 限制只能访问 DevOps 相关工具

步骤 1:创建 Agent 工作空间

# 创建目录结构 mkdir -p ~/.openclaw/agents/devops cd ~/.openclaw/agents/devops # 创建核心文件 touch SOUL.md IDENTITY.md MEMORY.md HEARTBEAT.md GUIDELINES.md

步骤 2:编写 SOUL.md

# Soul ## Core Philosophy 你是一个经验丰富的 DevOps 工程师,信奉"自动化一切可自动化的事物"。 你的核心原则是:可靠性 > 速度 > 成本。 ## Values - **可观测性优先**:任何操作都要有日志和指标 - **渐进式变更**:小步快跑,每次变更都可回滚 - **最小权限**:只请求完成任务所需的最低权限 ## Communication Style - 语气:专业、简洁、直接 - 使用 emoji 标记状态:✅ 成功 ❌ 失败 ⚠️ 警告 🔄 进行中 - 技术术语保留英文,说明用中文 - 紧急事项用 🚨 开头 ## Boundaries - 不在未经确认的情况下执行生产环境变更 - 不存储或传输密钥和密码 - 遇到不确定的情况,先报告再行动

步骤 3:编写 IDENTITY.md

# Identity ## Definition 我是团队的 DevOps 自动化助手,专注于 CI/CD、基础设施监控和部署管理。 ## Rules | # | Rule | |---|------| | 1 | 生产环境操作必须等待人工确认 | | 2 | 所有部署先在 staging 验证 | | 3 | 告警响应时间 < 2 分钟 | | 4 | 每次操作后更新 MEMORY.md | | 5 | 使用 terraform plan 预览基础设施变更 | ## Decision Table | Situation | Response | |-----------|----------| | P1 告警 | 🚨 立即通知 + 开始诊断 | | 部署失败 | 自动回滚 + 收集日志 + 通知 | | 资源 > 80% | ⚠️ 预警 + 扩容建议 | | 证书 < 30 天 | 提醒 + 续期步骤 |

步骤 4:配置 HEARTBEAT.md

# DevOps Heartbeat Checklist ## 每次检查(每 15 分钟) - 检查 Sentry 是否有新的 P1/P2 错误 - 检查 GitHub Actions 是否有失败的工作流 - 如果有异常,立即通过 Slack #ops-alerts 通知 ## 早间(8:00-8:30) - 生成基础设施健康报告(CPU、内存、磁盘、网络) - 检查 SSL 证书过期时间 - 汇总昨晚的部署记录 - 发送到 Telegram ## 晚间(18:00) - 生成今日 DevOps 操作摘要 - 检查是否有未关闭的告警 - 发送到 Slack #engineering

步骤 5:配置 openclaw.json

{ "agents": { "list": [ { "id": "devops", "agentDir": "~/.openclaw/agents/devops", "model": "anthropic/claude-sonnet-4-5", "tools": { "profile": "coding", "allow": ["deploy-check", "group:web", "group:automation"], "deny": ["canvas", "image"] }, "heartbeat": { "every": "15m", "model": "anthropic/claude-haiku-4", "target": "slack", "to": "#ops-alerts", "activeHours": { "start": "00:00", "end": "23:59" } } } ] }, "webhooks": { "github": { "path": "/webhook/github", "secret": "${GITHUB_WEBHOOK_SECRET}", "agent": "devops", "events": ["deployment_status", "workflow_run"] }, "sentry": { "path": "/webhook/sentry", "secret": "${SENTRY_WEBHOOK_SECRET}", "agent": "devops", "events": ["issue.created"] } }, "cron": { "jobs": [ { "id": "infra-report", "name": "Daily Infrastructure Report", "schedule": "0 8 * * *", "timezone": "Asia/Shanghai", "session": "isolated", "agent": "devops", "message": "生成完整的基础设施健康报告,包括所有服务的状态、资源使用率和告警摘要。", "target": "telegram" } ] }, "timezone": "Asia/Shanghai" }

步骤 6:验证和测试

# 验证配置 openclaw doctor # 启动 Gateway openclaw gateway start # 测试心跳 openclaw message send --agent devops --system '{"event": "heartbeat"}' # 测试 Webhook(模拟 GitHub 部署事件) curl -X POST http://localhost:18789/webhook/github \ -H "Content-Type: application/json" \ -H "X-GitHub-Event: deployment_status" \ -d '{"deployment_status":{"state":"success"},"repository":{"full_name":"my-org/my-app"}}' # 查看日志 openclaw logs --agent devops --follow

案例分析

这个 DevOps Agent 案例展示了几个关键设计决策:

  1. 双模型策略:心跳使用 Claude Haiku(便宜、快速)做常规检查,复杂任务使用 Claude Sonnet(更强推理能力),月成本从 ~$150 降至 ~$40
  2. 24/7 心跳 + 活跃时间通知:Agent 全天监控,但非紧急通知只在工作时间发送
  3. 工具最小权限:基于 coding profile,额外允许部署检查和自动化工具,禁用不需要的图像/画布工具
  4. 双通道路由:紧急告警走 Slack(团队可见),日报走 Telegram(个人查看)
  5. Webhook 集成:GitHub 和 Sentry 事件直接触发 Agent,无需轮询

避坑指南

❌ 常见错误

  1. SOUL.md 写成了任务清单

    • 问题:把具体任务和操作步骤写进 SOUL.md,导致 Agent 人格定义与任务执行混淆。SOUL.md 应该定义”我是谁”,而非”我做什么”
    • 正确做法:SOUL.md 只写价值观、沟通风格和行为边界;具体任务放在 HEARTBEAT.md、GOALS.md 或 TASKS.md 中
  2. Heartbeat 间隔设置过短

    • 问题:将心跳间隔设为 5 分钟甚至更短,导致 Token 消耗飙升(Claude Opus 每天可达 $30+),且频繁的 Agent Turn 可能产生重复通知
    • 正确做法:大多数场景 30 分钟足够;紧急监控场景用 15 分钟;使用便宜模型(Haiku)处理心跳;设置 ackMaxChars 限制非紧急消息长度
  3. 多 Agent 共享 agentDir

    • 问题:多个 Agent 指向同一个工作目录,导致 MEMORY.md、会话状态和凭证互相覆盖,产生不可预测的行为
    • 正确做法:每个 Agent 必须有独立的 agentDir;需要共享信息时,通过 sessions_spawn 或共享文件系统目录(非 agentDir)实现
  4. 忽略 Group 层策略导致公共频道泄露

    • 问题:在 Discord 公共频道中,Agent 仍然可以执行 exec 命令,可能被其他用户利用执行恶意命令
    • 正确做法:理解 7 层策略栈中 Group 层的作用——公共频道自动剥离高风险工具;在 tools.deny 中显式禁用不应在公共场景使用的工具
  5. Cron 任务使用主会话导致上下文污染

    • 问题:定时任务使用 session: "main" 运行,任务输出混入用户对话历史,影响后续交互质量
    • 正确做法:除非任务确实需要对话上下文,否则始终使用 session: "isolated"

✅ 最佳实践

  1. 先单 Agent 后多 Agent:大多数需求一个配置良好的 Agent 即可满足。只有当确实需要不同安全上下文、专业领域或通道行为时,才引入多 Agent
  2. 心跳用便宜模型:Heartbeat 的常规检查不需要强推理能力,使用 Claude Haiku 或 GPT-4o-mini 可节省 70%+ 成本
  3. IDENTITY.md 必须有 Decision Table:明确的决策表让 Agent 在遇到边界情况时有据可依,减少不可预测行为
  4. 版本控制身份文件:将 SOUL.md、IDENTITY.md、GUIDELINES.md 纳入 Git 管理,追踪变更历史,防止恶意修改
  5. 渐进式开放工具权限:从 minimal profile 开始,逐步添加需要的工具,而非从 full 开始逐步禁用
  6. 为每个 Webhook 配置独立 secret:不要多个 Webhook 共用同一个密钥,降低单点泄露的影响范围

相关资源与延伸阅读

资源类型说明
OpenClaw 官方文档 - Tools 官方文档工具策略配置完整参考,包括 Profile、Group 和 Provider 策略
How to Customize OpenClaw: Markdown-Based Configuration Guide 教程基于 Markdown 的 Agent 自定义完整指南,覆盖所有核心文件
Schedule Proactive OpenClaw Tasks with Heartbeat in 15 Minutes 教程Heartbeat 配置的 15 分钟快速入门,含完整配置示例
OpenClaw Cron Jobs - Building Proactive AI Automation 深度指南Cron 调度系统详解,对比 Heartbeat vs Cron 的使用场景
OpenClaw Multi-Agent Orchestration Advanced Guide 深度指南多 Agent 编排高级指南,覆盖隔离边界和协作模式
Building Multi-Agent Systems with OpenClaw 案例分析多 Agent 架构实战案例,含”关注点分离”设计模式
Implement Enterprise RBAC for OpenClaw in 45 Minutes 安全指南企业级 RBAC 实现,覆盖白名单、Agent 隔离和沙箱策略
The file that gives your OpenClaw agent a real personality 教程SOUL.md 深度解析,如何创建不会”破角色”的持久人格
How Clawdbot Plans Tasks 技术分析Agent 任务规划机制详解:反应式循环、心跳、Cron 和多步工作流
OpenClaw Soul & Evil: Identity Files as Attack Surfaces 安全研究身份文件作为攻击面的安全分析,含 soul-evil Hook 机制解析

参考来源


📖 返回 总览与导航 | 上一节:24a-插件架构 | 下一节:24c-自定义集成教程

Last updated on