1. 项目概述OpenClaw Agents 是什么如果你和我一样对把大语言模型LLM塞进一个能真正干活的“数字员工”感兴趣并且对数据隐私和完全控制权有执念那么tim-dickey/OpenClaw-agents这个项目绝对值得你花时间研究。简单来说这不是一个独立的 AI 应用而是一个专为开源个人 AI 助手OpenClaw打造的、可下载、可编辑的“智能体角色库”。想象一下你部署好了 OpenClaw它就像一个空有强大算力但不知如何是好的“白板大脑”。你需要告诉它“现在请你扮演我的私人助理 Aria。” 这个“扮演”的过程就需要一份详细的角色设定说明书。OpenClaw-agents项目提供的正是这样一份份已经由社区精心编写和测试过的“角色说明书”Agent Personas和“技能模块说明书”Sub-Agent Modules。从帮你整理晨间简报的个人助理到擅长代码审查的开发伙伴再到能管理团队站会的虚拟 Scrum Master这里都有现成的、高质量的模板。它的核心价值在于让你跳过从零开始设计提示词Prompt的漫长试错过程直接获得一个行为稳定、功能明确的 AI 助手并且所有数据都在你自己的机器上完全私有。2. 核心概念解析Agent 与 Sub-Agent 的设计哲学要玩转这个项目必须吃透 Agent智能体和 Sub-Agent子智能体这两个核心概念。这不仅仅是命名上的区别更代表了一种模块化、可组合的 AI 系统设计思想。2.1 Agent你的专属数字人格一个 Agent就是一个完整的、具备独立人格和职责的 AI 角色。在 OpenClaw 的语境下它不仅仅是一段提示词而是一个包含以下维度的综合定义体身份与人格名字、背景故事、沟通风格是严谨专业还是幽默风趣。这决定了 AI 回应的“味道”。核心职责与目标明确这个 Agent 存在的意义。例如“Aria”的目标是“为用户提供高效、个性化的每日简报”。能力范围与限制明确它能做什么更重要的是不能做什么。比如一个“创意写作”Agent 可能被设定为不处理财务数据。行为准则与约束这是安全性和可控性的关键。包括伦理规则如不生成有害内容、操作边界如未经确认不执行系统命令以及与其他 Agent 的交互协议。上下文与记忆定义它如何利用 OpenClaw 的持久化记忆功能是记住整个对话历史还是只关注最近几次交互项目中的 Agent 文件通常是agent.md就是用结构化的 Markdown 或 YAML frontmatter 来封装这些信息的“角色卡”。加载它就等于为你的 OpenClaw 实例注入了一个特定的灵魂。2.2 Sub-Agent可复用的技能插件如果说 Agent 是一个“全栈员工”那么 Sub-Agent 就是一个“专项工具人”。它的设计初衷是解决复杂任务下的关注点分离和代码复用问题。专注单一任务一个 Sub-Agent 只做好一件事。例如web-researcher只负责根据查询进行网络搜索并返回结构化摘要email-manager只负责分类收件箱和起草回复草稿。可被多个 Agent 调用这是 Sub-Agent 最强大的地方。你的“执行助理”Agent 和你的“项目经理”Agent 都可以在需要时调用同一个task-trackerSub-Agent 来记录任务。这避免了功能重复保证了行为一致性。标准化接口Sub-Agent 通过明确定义的输入指令、参数和输出结构化数据、文本与父 Agent 通信。这种契约化的设计使得组合变得可靠。在实际使用中一个强大的“执行助理”Agent如项目中的 Maxwell的配置文件里会声明它依赖email-manager和task-tracker等 Sub-Agent。当用户向 Maxwell 说“帮我看看邮件并总结一下”Maxwell 作为“大脑”会理解指令然后调用email-manager这个“手”去执行具体的邮件处理任务最后整合结果回复给用户。注意这种“主从”架构并非 OpenClaw 独有但OpenClaw-agents项目为其提供了开箱即用的、经过验证的实现极大地降低了使用门槛。理解这一点是你能否高效定制和创建新 Agent 的关键。3. 项目结构与内容深度剖析克隆仓库后你会发现其结构非常清晰体现了严谨的工程化思维。这不仅仅是文件的堆砌更是一套最佳实践的展示。3.1 核心目录Agents 与 Sub-AgentsOpenClaw-agents/ ├── agents/ # 主智能体库 │ ├── personal/ # 个人效率类 (如Aria - 每日简报) │ ├── professional/ # 专业职场类 (如Maxwell - 执行助理) │ ├── developer/ # 开发者类 (如Hex - 代码审查员) │ ├── creative/ # 创意内容类 (如Lyra - 内容写手) │ ├── team/ # 团队协作类 (如Velocity - Scrum教练) │ └── _template/ # 创建新Agent的模板文件 ├── sub-agents/ # 子智能体库 │ ├── research/ # 研究类 (如web-researcher) │ ├── communication/ # 通信类 (如email-manager) │ ├── productivity/ # 生产力类 (如task-tracker) │ └── data/ # 数据分析类 (如data-analyst)每个类别下的具体 Agent/Sub-Agent 都是一个独立的文件夹里面至少包含README.md: 介绍该角色的功能、用法和配置项。agent.md或sub-agent.md: 核心的配置文件/提示词文件。可能还有config.yaml、examples/等辅助文件。这种分类方式不仅方便查找也暗示了智能体设计的领域划分思想。当你需要创建一个新的“财务分析师”Agent 时参考professional/下的例子会比参考creative/下的更合适。3.2 质量保障双引擎Evals 与 Tests这是该项目超越许多同类“提示词合集”项目的精华所在。它引入了软件工程中的质量保障理念。evals/目录 - 确定性离线评估 这里存放的是“测试用例”或“验收标准”。通常以 JSON 或 YAML 格式定义。例如对于email-managerSub-Agent可能会有一个 eval 文件描述一个模拟的收件箱场景和期望的输出结构如哪些邮件该标记为重要回复草稿应有的语气。它不直接运行而是作为一份可审查的、描述“正确行为应该长什么样”的规范文档。这对于团队协作和代码审查至关重要。tests/目录 - 可执行的行为契约测试 这里使用的是像pytest这样的真实测试框架。这些测试是可运行的能够自动调用 Agent/Sub-Agent喂给它输入并断言其输出是否符合预期。这支持了TDD测试驱动开发工作流你可以先为你想让 Agent 具备的新行为编写测试当然会失败然后去修改agent.md中的提示词直到测试通过。这为智能体的迭代开发提供了坚实的反馈循环。实操心得对于个人用户你可能不会一开始就写复杂的测试。但理解这套机制的价值在于当你自定义的 Agent 行为出现偏差时你可以参考evals/里的用例来手动验证或者学着写一个简单的pytest来自动化排查问题这能极大提升调试效率。3.3 文档与贡献指南docs/目录下的文件是必读的尤其是agent-spec.md和sub-agent-spec.md。它们定义了编写一个合格配置文件的“语法”比如 frontmatter 里应该包含哪些字段name,version,description,sub_agents依赖列表等。遵循这些规范能保证你的 Agent 与 OpenClaw 主程序和其他社区 Agent 良好兼容。.github/下的工作流和 ISSUE_TEMPLATE 则展示了成熟的开源项目协作方式。如果你想贡献自己的 Agent从提交 Issue 讨论开始到使用模板创建再到发起 Pull Request整个流程都有引导并且 CI持续集成会自动运行相关的测试来验证你的提交是否符合基础规范。4. 从零开始部署、配置与深度定制实战假设你已经按照 OpenClaw 主项目的说明在本地或自己的服务器上部署好了 OpenClaw 核心程序。接下来就是让OpenClaw-agents项目中的角色为你所用。4.1 基础使用四步法获取角色文件# 克隆整个仓库如果你想浏览或贡献 git clone https://github.com/tim-dickey/OpenClaw-agents.git # 或者直接进入 GitHub 仓库页面找到心仪的 Agent点击进入其文件夹直接下载 agent.md 文件。放置到正确路径 根据你的 OpenClaw 配置找到其指定的agents和sub-agents目录。通常这会在配置文件中指明如~/.openclaw/agents/。将下载的agent.md文件放入agents/下的一个子文件夹例如agents/personal/aria/将sub-agent.md放入sub-agents/下的对应子文件夹。保持目录结构清晰便于管理。加载与激活 重启你的 OpenClaw 服务或者在支持热重载的情况下发送重载指令。之后你就可以在连接的聊天应用如 Telegram中通过Aria或预设的唤醒词来调用这个新的 Agent 了。初步验证 用简单的指令测试。例如对 Aria 说“早上好”或“今天的简报是什么”观察其回应是否符合 README 中的描述。4.2 深度定制打造你的专属智能体直接使用社区模板很棒但真正的威力在于定制。以下是我根据经验总结的定制流程第一步解构与模仿选一个最接近你需求的现有 Agent例如你想做一个“技术文档翻译专家”可以借鉴creative/lyra和developer/hex。仔细阅读它的agent.md分析其结构系统提示词System Prompt开头部分定义了角色的核心身份、规则和约束。这是人格的基石。能力描述如何描述自己的技能是列表还是自然段落上下文处理它如何利用历史对话有没有设定记忆窗口Sub-Agent 调用它是如何声明和使用子技能的学习其调用语法。第二步定义你的角色骨架新建一个文件夹和agent.md文件。使用_template/中的模板作为起点。首先填充 frontmatter元数据然后构思系统提示词。这里有个关键技巧使用清晰的分层和标记。# 角色TechDoc Translator (Alex) ## 身份 - 你是 Alex一位拥有10年经验的资深技术文档工程师和本地化专家。 - 你精通中英文对IT、云计算、软件开发等领域术语有深刻理解。 ## 核心目标 将用户提供的英文技术文档API参考、用户手册、错误代码等准确、流畅地翻译成中文并保持术语一致性和技术严谨性。 ## 绝对规则 1. 绝不意译可能导致歧义的技术术语优先采用行业公认译法。 2. 对于没有公认译法的新术语在首次出现时提供英文原文并用括号标注。 3. 不翻译代码片段、命令行和特定品牌/产品名称除非有官方中文名。 4. 保持原文的格式标记如 代码、**加粗**、标题层级。 ## 工作流程 1. 请求用户提供需要翻译的英文文本或文档链接。 2. 进行翻译并附上“术语处理说明”部分列出本次翻译中处理的特殊术语及其依据。 3. 提供翻译后的中文文本。 ...这种结构化的提示词比一大段散文式的描述更能让 LLM 稳定地理解并执行复杂角色。第三步集成 Sub-Agent 与工具思考你的 Agent 是否需要分解任务。比如你的翻译专家 Alex 可能依赖一个terminology-validatorSub-Agent专门检查术语一致性。一个format-preserverSub-Agent确保 Markdown、代码块等格式在翻译后不被破坏。 你可以在agent.md的 frontmatter 中声明这些依赖并在系统提示词中描述调用它们的条件和方式。第四步创建你自己的 Evals 和 Tests这是保证定制质量、避免“提示词漂移”的关键。即使只是一个简单的 eval JSON 文件// evals/alex/basic_translation.json { input: Translate the following error message: Connection timeout after 30 seconds. Check your network configuration and firewall rules., expected_contains: [连接超时, 30秒, 网络配置, 防火墙规则], expected_not_contains: [意译的网络用语, 口语化表达] }手动或自动运行这些评估能确保你对提示词的修改没有破坏核心功能。踩坑实录早期我定制一个 Agent 时只改了系统提示词没更新对应的测试。几轮迭代后Agent 的行为已经偏离初衷但我直到用户抱怨才发现。自那以后我为任何非微小的改动都配上至少一个简单的测试用例。5. 高级技巧与疑难问题排查5.1 性能优化与成本控制OpenClaw 运行在你自己的机器上但背后的 LLM 推理无论是本地模型还是通过 API 调用云端模型仍有成本。上下文长度管理Agent 的提示词本身会占用上下文窗口。避免在系统提示词中堆砌无关细节。将不常用的背景信息或参考数据移到外部知识库让 Agent 学会在需要时去查询这需要 OpenClaw 的插件或工具支持。Sub-Agent 的精准调用在父 Agent 的提示词中明确描述“在什么情况下调用哪个 Sub-Agent”。模糊的指令会导致不必要的、耗能的子任务触发。例如“处理邮件”应明确为“调用 email-manager 子智能体处理我的收件箱”。缓存策略对于web-researcher这类可能重复查询相同信息的 Sub-Agent考虑在其实现中如果涉及自定义代码或通过 OpenClaw 的中间件层增加对常见查询结果的缓存避免重复调用网络或 LLM。5.2 常见问题与解决方案速查表问题现象可能原因排查步骤与解决方案Agent 无响应或认错身份1. 配置文件未正确加载。2. 系统提示词冲突或被覆盖。1. 检查agent.md文件是否放在正确的目录权限是否正确。2. 重启 OpenClaw 并查看日志确认启动时是否加载了你的 Agent。3. 检查 OpenClaw 的主配置确认是否设置了全局默认提示词与你的 Agent 提示词冲突。Agent 行为与描述不符1. 提示词描述模糊或有歧义。2. 上下文被历史对话污染。1.精炼提示词使用更具体、无歧义的指令。多用“必须”、“禁止”、“步骤一、二、三”等明确词汇。2.设计上下文清洗策略在提示词中约定当用户发送“/reset”或开始新话题时Agent 应主动忽略之前的无关对话。3.运行 Evals用设计好的测试用例验证行为定位是哪个环节的指令出了问题。Sub-Agent 未被调用1. 依赖未声明或声明错误。2. 父 Agent 的调用指令错误。1. 检查父 Agentagent.md的 frontmatter 中sub_agents列表是否包含了正确的子智能体 slug文件夹名。2. 检查父 Agent 系统提示词中关于如何调用 Sub-Agent 的描述是否与 OpenClaw 的实际调用 API 匹配。参考官方sub-agent-spec.md。3. 查看 OpenClaw 运行日志看调用请求是否发出以及 Sub-Agent 端是否有错误日志。Agent 响应速度慢1. LLM 推理速度慢本地模型。2. 提示词过长或 Sub-Agent 调用链过长。1. 对于本地模型考虑使用量化版本或更小的模型。2.优化提示词移除冗余描述使用更简洁的表达。3.简化工作流评估是否所有 Sub-Agent 调用都是必要的能否合并步骤。考虑让一个 Sub-Agent 处理更多关联任务减少调用次数。记忆功能混乱OpenClaw 的记忆存储/检索策略与 Agent 预期不符。1. 在 Agent 提示词中明确说明它应如何利用记忆。例如“在回答关于项目X的问题时优先检索最近一周内与‘项目X’相关的对话记忆。”2. 查阅 OpenClaw 文档了解其记忆模块的配置选项调整检索相似度阈值或记忆长度。5.3 从使用者到贡献者当你定制出好用的 Agent 后可以考虑回馈社区。贡献流程非常规范前期沟通在 GitHub 上使用new-agent.md模板提交 Issue描述你的 Agent 想法、目标用户和核心功能。等待维护者或社区反馈。开发与测试Fork 仓库使用_template创建你的 Agent。务必同时编写至少基础的evals和tests来验证其核心行为。这能极大提高你的 PR 被合并的概率。文档与示例编写清晰的README.md说明使用场景、配置方法并提供一到两个生动的交互示例。提交 PR确保你的代码和提交信息符合CONTRIBUTING.md中的规范。CI 会自动运行测试确保你的提交不会破坏现有功能。这个过程本身就是对如何设计一个健壮、可维护的 AI 智能体的一次绝佳实践。我个人在深度使用和定制多个 Agent 后的体会是OpenClaw-agents项目的价值远不止于提供模板。它更像一个精心设计的“实验室”通过其清晰的结构、质量保障体系和社区规范潜移默化地教你如何以工程化的思维去设计和迭代 AI 智能体。它让你意识到一个可靠的 AI 助手其核心不仅仅是强大的基础模型更在于那一套定义其行为边界、工作流程和协作方式的“规则与灵魂”。而这一切的掌控权通过 OpenClaw完全握在你自己手中。