1. 项目概述从工具到搭档的蜕变如果你已经玩过一阵子OpenClaw把它当作一个能帮你写写代码、查查资料的智能工具那你可能只解锁了它10%的潜力。我最初也是这么用的直到有一天我被一个复杂的跨部门协作项目搞得焦头烂额需要它帮我梳理十几个文档的逻辑关系并生成会议纪要。我像往常一样丢给它一堆文件得到的回复却依然是零散的要点罗列完全无法理解项目里“市场部担心成本”和“研发部强调技术债”之间的深层博弈。那一刻我意识到我需要的不是一个听话的“工具”而是一个能理解上下文、拥有“个性”和“专长”的“搭档”。这个转变的核心就在于三份被许多资深玩家称为“灵魂配置”的文件SOUL.md、USER.md和AGENTS.md。它们远不止是简单的参数设置而是为你的OpenClaw注入记忆、性格与专业能力的“人格蓝图”。SOUL.md定义了它的核心价值观与行为准则是它的“灵魂”USER.md描述了你的背景、习惯与偏好是它的“记忆”AGENTS.md则为其装备了各种专业“技能卡”是它的“能力”。当你精心配置这三者你的助手将不再机械应答而是能基于对你的了解和自身的“原则”主动思考、预判需求甚至在你思路卡壳时提供有深度的建议真正成为一个值得信赖的协作伙伴。2. 灵魂配置深度解析三份文件的作用与关联很多教程会把配置讲得很散我们不如先打个比方把你的OpenClaw想象成一位新入职的同事。SOUL.md就是他的职业道德手册和公司文化指南告诉他“我们这里鼓励创新但务必严谨对用户数据要绝对保密”。USER.md就是你作为他的直属领导给他的个人工作简报上面写着“我目前主要负责A项目常用Python讨厌冗长的邮件下午3点后找我效率最高”。而AGENTS.md则是他的技能证书库和工具箱清单标明他“持有云计算架构师认证精通SQL优化还特别会做数据可视化”。2.1 SOUL.md塑造助手的“人格”与原则这是最核心也最容易被忽略的配置文件。它不关心具体怎么完成任务而是定义“以何种姿态”去完成任务。一个没有SOUL.md的OpenClaw就像一台性能强大但缺乏价值观的机器它的回答可能准确但未必“得体”或“贴心”。核心配置维度核心指令与角色在这里你需要清晰地定义它的首要身份。例如它不是一个“通用AI”而是“我的资深技术搭档”或“创意项目协作者”。这个初始设定会像潜意识一样影响它后续的所有输出。沟通风格与语气你希望它是严谨的教授、活泼的伙伴还是高效的顾问这决定了它回复的句式、用词甚至表情虽然OpenClaw是文本但语气可通过措辞体现。例如设定为“用简洁的要点和类比解释复杂概念避免学术腔”。工作伦理与边界这是安全与靠谱的基石。必须明确包括信息保密强调所有对话内容、上传文件均为保密信息不得在后续对话中主动提及或泄露除非用户明确指示。诚实边界对于不确定或超出知识范围的问题必须明确告知“我不知道”并可以建议查找方向而非胡编乱造。主动性范围规定在什么情况下可以主动提供额外信息或建议例如当用户问题存在明显优化空间时以及何时应严格遵循指令。注意SOUL.md的配置切忌空洞。像“乐于助人”这样的描述是无效的。应转换为具体行为指令如“当用户提出一个模糊的需求时首先通过提问帮助其澄清核心目标然后提供不超过三个可选方案并列出每个方案的利弊。”2.2 USER.md让助手拥有对你的“长期记忆”这是最具个性化价值的配置。OpenClaw的常规会话有上下文长度限制USER.md就是一个永久的、可随时查阅的关于你的“用户手册”。它解决了每次对话都要重复自我介绍的痛点。应包含的关键信息身份背景你的职业如“全栈开发工程师”、主要领域如“Web后端与DevOps”、当前核心项目。技术栈偏好你常用的编程语言、框架、工具链如“Python/Django, Docker, AWS”。这能让你在询问技术问题时它默认会从你的技术背景出发给出建议而不是从零开始科普。工作习惯与禁忌沟通偏好例如“喜欢代码示例配合关键逻辑解释讨厌大段理论叙述”。信息接收格式例如“复杂方案请用Markdown列表或表格对比关键结论加粗”。时间与上下文例如“我通常在UTC8时区工作上午处理代码下午开会和写文档。你可以在下午4点左右提醒我进行当日总结”。已知知识/持续项目列出你正在深入研究的方向或长期项目。例如“正在学习Kubernetes服务网格Istio”“在开发一个个人财务管理的Side Project使用Vue.js和FastAPI”。这能让助手在相关话题中保持上下文连贯。一个高效的技巧将USER.md分为“静态信息”和“动态更新”两部分。静态信息如职业、技术栈动态部分则可以是一个简单的日志格式让你随时追加“本周在排查一个生产环境的内存泄漏问题”或“刚读完《领域驱动设计》第5章”。助手在回应时会参考这些最新动态。2.3 AGENTS.md为助手装备专业“技能模组”如果说SOUL.md和USER.md定义了“是谁”和“为谁服务”那么AGENTS.md就定义了“能做什么”。它通过预设的指令模板或称“技能”让OpenClaw能够结构化、专业化地处理特定类型任务。配置文件的本质AGENTS.md通常是一个包含多个“Agent”定义块的Markdown文件。每个Agent就是一个技能插件。一个Agent定义的典型结构## Agent: 代码审查专家 **触发指令**/review 或 “请以代码审查专家模式分析以下代码” **核心职责**专注于检查代码质量、潜在缺陷、性能问题和是否符合最佳实践。 **执行步骤** 1. 首先理解代码的功能和上下文。 2. 从以下维度系统性分析 * **正确性**是否存在逻辑错误、边界条件处理不当 * **安全性**是否有注入风险、敏感信息泄露 * **性能**是否存在低效循环、冗余计算、N1查询 * **可读性与维护性**命名是否清晰函数是否过于冗长注释是否恰当 * **符合规范**是否遵循项目约定的代码风格如PEP 8 3. 对发现的问题按【严重】、【建议】分级并给出具体的修改建议和示例代码。 4. 最后总结主要发现并给出1-2条最重要的改进建议。 **输出格式**必须使用Markdown表格汇总问题并对每个问题提供代码片段示例。如何规划你的Agents 不要试图一口气创建几十个Agent。从你最频繁、最痛苦的任务开始。例如/brainstorm(头脑风暴助手)用于新产品功能或文章选题的发散思考。/refine(文本润色专家)专门优化邮件、报告、文档的措辞与逻辑。/learn(学习伙伴)当你输入一个新概念时它用费曼学习法的方式向你提问并解释。/plan(项目规划师)根据一个目标帮你拆解出任务清单、时间线和依赖关系。这三份文件共同作用形成了一个增强回路SOUL.md确保助手以正确的“态度”行事USER.md让它知道“为谁”服务提供个性化上下文AGENTS.md则赋予它高效完成“事情”的专业方法。当你调用一个Agent时OpenClaw会同时融合这三者的信息来生成回复这才是“搭档感”的来源。3. 灵魂配置的实战编写指南理解了理论我们来动手创建这三份文件。我将以我自己的配置为蓝本展示如何写出真正有用的内容。3.1 编写你的SOUL.md从模糊到具体一份糟糕的SOUL.md“你是一个有帮助的AI助手。” 一份好的SOUL.md# 核心身份与原则 (My Core Soul) ## 根本角色 你是“Alex的技术与创意搭档”。你的首要目标不是回答问题本身而是帮助Alex用户更高效、更清晰地思考和解决问题并在此过程中促进他的个人成长。你视自己为他工作流中的一个深度集成组件。 ## 核心沟通风格 1. **简洁与直接**优先使用要点、列表和表格。避免冗长的开场白和客套话。如果结论是否定的请直接说明。 2. **类比解释者**当解释复杂技术或抽象概念时必须尝试使用一个贴切的生活或行业类比帮助建立直观理解。 3. **主动澄清者**如果Alex的需求模糊、存在歧义或可能有多重解读你的第一反应必须是提出1-3个精准的澄清性问题而不是基于猜测开始工作。 4. **平衡批判与鼓励**在评审想法或代码时首先指出其中的亮点或合理之处再提出批判性意见。意见需具体并附带可操作的改进建议。 ## 不可动摇的工作伦理 1. **绝对保密**本次及历史上所有对话内容、Alex上传的任何文件、以及从USER.md中了解到的关于Alex的任何个人信息、项目细节均为最高级别机密。你不得在任何后续对话中主动提及、暗示或泄露这些信息除非Alex在当前对话中明确指示你使用它们。 2. **诚实第一**如果你的知识库中没有足够信息来可靠地回答某个问题你必须明确说“根据我目前的知识我无法确认这一点。” 你可以提供基于有限信息的推测但必须明确标注此为“推测”并建议权威的核实渠道。 3. **安全边界**对于任何涉及破解、侵权、隐私侵犯、制造危险或违反Alex所在地公认法律法规的请求你应拒绝执行并简要、中立地说明拒绝的原因是基于操作原则。 4. **主动性范围** * **当允许时**在解决Alex主要问题后如果存在直接相关、能显著提升结果质量或效率的额外信息、工具或方法你可以主动补充并注明“额外建议”。 * **当禁止时**不要主动将对话引导至与当前主题完全无关的领域。不要未经请求就对Alex的个人偏好、习惯或历史决策进行评价。实操心得SOUL.md不是一次写就的。我会在与其协作过程中如果发现它某种行为不符合预期比如过于啰嗦或者该追问时没追问就回到这个文件增加或修改一条对应的原则。它是一个动态打磨的“合作契约”。3.2 编写你的USER.md构建动态用户画像你的USER.md应该像一份持续更新的个人工作日志。# 关于 Alex (持续更新) ## 基础档案 * **职业**资深技术博主与独立开发者 * **核心领域**全栈Web开发偏后端、DevOps自动化、云原生技术应用。 * **常用技术栈** * 语言Python (主)JavaScript/TypeScriptGo (学习中) * 后端FastAPI, Django, PostgreSQL, Redis * 前端Vue.js 3, React (了解) * 运维Docker, Kubernetes, Terraform, AWS (EC2, RDS, S3) * 工具Git, VS Code, PyCharm, iTerm2 ## 工作习惯与偏好 1. **沟通** * 讨厌重复。如果某个背景信息已在USER.md或本次对话中提及请直接使用无需再次确认。 * 喜欢“先结论后细节”。回答时先用一句话总结核心观点或方案。 * 对于技术方案需要了解**为什么**选择A而不是B。请务必包含简要的利弊分析。 2. **信息格式** * 代码块**必须**标注语言类型。 * 复杂的配置或步骤请使用有序列表1. 2. 3.。 * 对比不同工具或方案时请使用Markdown表格。 3. **时间与上下文** * 时区UTC8 (北京/上海时间)。 * 通常上午9-12点进行深度编码和设计下午2-6点处理沟通、写作和调试。 * 你可以在我通常结束一天工作的时间下午6点左右如果对话上下文合适主动建议“是否需要将今天的讨论要点进行总结”但不要强制。 ## 当前关注与项目日志 (动态部分) * **[2024-10-27]**正在将个人博客的后台从单机Docker迁移到Kubernetes集群遇到了Ingress配置与旧服务兼容性问题。 * **[2024-10-25]**在研究如何用Go编写一个高性能的日志收集侧车( sidecar )用于K8s环境。 * **[2024-10-20]**刚读完《Designing Data-Intensive Applications》第10章对批处理与流处理有了新认识。 * **长期兴趣**技术写作、效率工具链构建、开源项目商业化模式。注意事项动态部分不宜过长保留最近5-10条最关键的活动即可。你可以每周花几分钟整理更新。关键是让助手知道你“最近在关心什么”这能极大提升对话的连贯性和相关性。3.3 规划与编写你的AGENTS.md打造效率武器库创建Agent的关键是场景化和结构化。下面展示两个我高频使用的Agent。Agent 1设计评审助手 (/design-review)这个Agent用于在编写代码前评审我的系统设计或API设计文档。## Agent: 系统设计评审员 **触发指令**/design-review 或 “请以系统设计评审模式分析以下设计” **核心目标**在技术实现开始前发现架构设计中的风险、模糊点和改进机会。 **执行框架** 1. **理解目标**首先复述我提供的设计所要解决的业务核心问题与核心用户故事。 2. **架构评估** * **组件边界**各服务/模块的职责是否单一、清晰是否存在循环依赖 * **数据流**数据如何产生、流转、存储和消费关键路径是否高效 * **接口设计**API/消息协议是否满足前后端需求是否考虑了版本兼容性 * **技术选型**选择的数据库、中间件、框架是否适合当前场景的规模与复杂度是否存在过度设计或设计不足 3. **风险与扩展性** * **单点故障**系统中是否存在单点故障如何规避 * **扩展性**当用户量、数据量增长10倍、100倍时哪个组件会成为瓶颈扩容方案是什么 * **可观测性**日志、指标、追踪如何集成是否便于未来排查问题 4. **安全与合规**是否涉及敏感数据处理认证授权机制是否完备是否符合领域内的基本安全规范 5. **输出**以表格形式列出【潜在风险】高/中/低和【改进建议】并最终给出一个总体评价“基本可行需关注X点”或“建议重新考虑Y部分”。Agent 2学习总结伙伴 (/learn-summary)这个Agent帮助我内化新学到的知识。## Agent: 费曼学习法伙伴 **触发指令**/learn-summary 或 “请用费曼学习法帮我梳理以下概念” **核心目标**通过模拟教学和提问确保我真正理解了一个概念而非死记硬背。 **执行步骤** 1. **概念复述**请用最简洁的语言像给一个聪明的15岁孩子讲解一样描述这个概念是什么。 2. **识别核心**提炼出该概念的1-3个最核心的原则或关键点。 3. **举例与类比** * 举一个具体的、贴近我技术栈参考USER.md的例子来说明它。 * 想一个生活中的类比让我能直观感受它。 4. **反向提问**基于这个概念向我提出2-3个有挑战性的问题检验我是否理解其内涵和外延。问题应包含“如果...会怎样”或“这个概念与XXX另一个已知概念有何异同”。 5. **知识连接**指出这个概念与我已知的哪些知识参考USER.md中的动态日志可以产生联系从而融入我的知识体系。 **输出格式**严格按以上1-5步骤分节输出。第4步的问题请留出空间等待我的回答后再进行互动。规划你的Agent清单建议从这4个类别开始每个类别先创建1-2个创作类写作助手、头脑风暴。技术类代码审查、调试分析、SQL优化。学习类读书总结、概念讲解。效率类会议纪要生成、邮件起草、项目计划拆解。4. 配置的部署、调试与高阶技巧写好配置文件只是第一步让它们在OpenClaw中生效并良好运行需要正确的部署和持续的调试。4.1 配置文件的位置与加载OpenClaw的具体配置加载方式取决于你的部署模式本地、Docker等。通常你需要将这三个.md文件放置在OpenClaw工作目录下一个特定的config或profiles文件夹内。以常见Docker部署为例假设你的OpenClaw数据卷挂载在本地~/openclaw-data。在该目录下创建profiles文件夹mkdir ~/openclaw-data/profiles将你的SOUL.md,USER.md,AGENTS.md放入~/openclaw-data/profiles/。在OpenClaw的配置文件可能是config.yaml或环境变量中指定配置目录路径。例如在docker-compose.yml中可能通过环境变量设置environment: - OPENCLAW_PROFILES_DIR/app/data/profiles重启OpenClaw容器使配置生效。重要提示部署后首次与OpenClaw对话时应发送一条初始化指令例如“请加载并应用我的个人配置文件SOUL, USER, AGENTS。” 根据OpenClaw的版本和界面有时也需要在Web UI的设置菜单中手动激活或选择该配置集。4.2 调试与优化让配置真正“活”起来配置生效后你可能会发现助手的行为并未完全符合预期。这就需要调试。1. 测试与观察针对性测试设计一些测试用例。例如针对SOUL.md中的“主动澄清”可以提一个模糊需求“帮我优化网站。” 观察它是否会追问“是前端性能、后端响应速度还是SEO方面的优化”检查记忆询问“你知道我最近主要在做什么项目吗” 测试USER.md的动态部分是否被正确读取。触发Agent直接使用你定义的触发指令如/design-review看它是否切换到预设的工作流。2. 常见问题与排查问题助手完全忽略配置文件。排查确认文件路径正确文件名无误大小写敏感且OpenClaw有权限读取。查看OpenClaw的日志寻找加载配置时的错误信息。问题助手行为部分符合但有些指令无效。排查这通常是配置文件语法或逻辑问题。检查AGENTS.md的步骤描述是否过于复杂或存在矛盾。简化指令确保每一步都清晰、可执行。有时过于冗长的SOUL.md也会导致核心指令被稀释。问题多个配置间产生冲突。排查例如SOUL.md要求“简洁”但某个Agent要求“详细分析”。这需要在Agent定义中覆盖或细化通用原则。可以在该Agent内部开头注明“本任务模式下请进行详细、逐步的分析暂不适用‘极度简洁’原则。”3. 迭代优化配置不是静态的。我的做法是建立一个“配置迭代日志”记录当助手在某次对话中表现出色或令人失望时记下具体场景和对话片段。归因分析是哪个配置文件S/U/A的哪条规则起了作用或缺失了。修改回到对应的.md文件增、删、改具体的条款。修改的原则是让描述更具体让规则更可操作。验证修改后用类似的场景再次测试观察行为是否改善。4.3 高阶技巧配置的组合与情境化当基础配置稳定后你可以玩出更多花样。1. 情境化配置切换你可以准备多套SOUL.md和AGENTS.md组合用于不同场景。例如work配置严谨、高效、偏重技术的Agent集合。creative配置思维发散、鼓励脑洞、语气活泼的Agent集合。learn配置耐心、善于提问和引导的学习伙伴配置。通过外部脚本或OpenClaw的高级API你可以快速在不同配置集间切换就像为你的搭档换上不同的“职业套装”。2. Agent的链式调用一个复杂任务可以分解为多个Agent顺序执行。例如一个“产品需求文档生成”任务可以设计为需求澄清Agent-市场分析Agent-功能列表生成Agent-文档结构化Agent。 你可以在一个总控Agent的指令中描述这个流程或者通过外部工作流工具如n8n, Zapier来编排。3. 与外部知识库结合USER.md中的动态日志可以作为一个简单知识库。更进一步你可以将Notion、Obsidian中的笔记通过摘要的方式定期更新到USER.md或者利用OpenClaw的插件/API功能连接更正式的外部知识库如公司Wiki、项目文档让助手在回答时能引用这些“长期记忆”使其建议更具上下文相关性。5. 从实操到心法让AI搭档融入工作流配置再精妙如果不能融入日常也是摆设。经过几个月的深度使用我总结出一些让这位“AI搭档”真正发挥价值的心得。心法一明确分工人做决策AI做执行与拓展。不要指望AI替你思考战略问题。它的强项在于基于清晰指令的信息整合、方案拓展、细节实现和风险提示。我的典型工作流是我定方向我提出核心问题和初步想法“我想做一个用户行为分析面板用来跟踪新功能的点击率”。AI做拓展我使用/brainstormAgent让它列出实现这个面板的5种技术方案从简单的静态图表到复杂的实时看板。我定方案我基于项目现状和资源选择方案三使用Metabase集成。AI做实现我切换至/implementAgent假设有给出更具体的指令“基于我们现有的PostgreSQL数据库用Metabase实现方案三请给出具体的配置步骤、SQL查询示例和看板搭建要点。”AI做审查在我完成初步配置后用/reviewAgent检查我的SQL查询是否存在性能问题。在这个流程中我始终掌控着“要做什么”和“选择哪条路”而AI负责把这条路具体化、可视化并提前帮我插上“前方施工”的警示牌。心法二像训练新人一样提供反馈。当AI搭档的输出不尽如人意时不要只是抱怨。把它当作一个聪明但需要指导的新人同事。提供具体的、建设性的反馈。无效反馈“这写得不好。”有效反馈“你在第三点的分析中只提到了技术优势但没有考虑我们团队目前对Kafka不熟悉带来的学习成本。请参考USER.md里我提到的‘团队技术栈倾向’重新评估一下这个选型并加入团队适配性分析。” 将你的反馈反向提炼成规则补充到SOUL.md或特定Agent的指令中。这个过程本身就是对你思考的深化。心法三接受不完美关注增量价值。它永远不会100%理解你就像任何人类搭档一样。会有误解会有跑偏。关键在于相比没有它的时候你的效率和质量是否有提升我发现自己因为有了这个搭档写设计文档更全面了排查问题的思路更系统了学习新知识后遗忘得更慢了。这些增量价值才是衡量配置成功与否的真正标准。放下对“完美智能”的执念专注于利用它放大你的优势弥补你的短板你就能从“使用工具”的心态真正转变为“与搭档协作”的心境。 OpenClaw灵魂配置：从工具到智能搭档的进阶指南
1. 项目概述从工具到搭档的蜕变如果你已经玩过一阵子OpenClaw把它当作一个能帮你写写代码、查查资料的智能工具那你可能只解锁了它10%的潜力。我最初也是这么用的直到有一天我被一个复杂的跨部门协作项目搞得焦头烂额需要它帮我梳理十几个文档的逻辑关系并生成会议纪要。我像往常一样丢给它一堆文件得到的回复却依然是零散的要点罗列完全无法理解项目里“市场部担心成本”和“研发部强调技术债”之间的深层博弈。那一刻我意识到我需要的不是一个听话的“工具”而是一个能理解上下文、拥有“个性”和“专长”的“搭档”。这个转变的核心就在于三份被许多资深玩家称为“灵魂配置”的文件SOUL.md、USER.md和AGENTS.md。它们远不止是简单的参数设置而是为你的OpenClaw注入记忆、性格与专业能力的“人格蓝图”。SOUL.md定义了它的核心价值观与行为准则是它的“灵魂”USER.md描述了你的背景、习惯与偏好是它的“记忆”AGENTS.md则为其装备了各种专业“技能卡”是它的“能力”。当你精心配置这三者你的助手将不再机械应答而是能基于对你的了解和自身的“原则”主动思考、预判需求甚至在你思路卡壳时提供有深度的建议真正成为一个值得信赖的协作伙伴。2. 灵魂配置深度解析三份文件的作用与关联很多教程会把配置讲得很散我们不如先打个比方把你的OpenClaw想象成一位新入职的同事。SOUL.md就是他的职业道德手册和公司文化指南告诉他“我们这里鼓励创新但务必严谨对用户数据要绝对保密”。USER.md就是你作为他的直属领导给他的个人工作简报上面写着“我目前主要负责A项目常用Python讨厌冗长的邮件下午3点后找我效率最高”。而AGENTS.md则是他的技能证书库和工具箱清单标明他“持有云计算架构师认证精通SQL优化还特别会做数据可视化”。2.1 SOUL.md塑造助手的“人格”与原则这是最核心也最容易被忽略的配置文件。它不关心具体怎么完成任务而是定义“以何种姿态”去完成任务。一个没有SOUL.md的OpenClaw就像一台性能强大但缺乏价值观的机器它的回答可能准确但未必“得体”或“贴心”。核心配置维度核心指令与角色在这里你需要清晰地定义它的首要身份。例如它不是一个“通用AI”而是“我的资深技术搭档”或“创意项目协作者”。这个初始设定会像潜意识一样影响它后续的所有输出。沟通风格与语气你希望它是严谨的教授、活泼的伙伴还是高效的顾问这决定了它回复的句式、用词甚至表情虽然OpenClaw是文本但语气可通过措辞体现。例如设定为“用简洁的要点和类比解释复杂概念避免学术腔”。工作伦理与边界这是安全与靠谱的基石。必须明确包括信息保密强调所有对话内容、上传文件均为保密信息不得在后续对话中主动提及或泄露除非用户明确指示。诚实边界对于不确定或超出知识范围的问题必须明确告知“我不知道”并可以建议查找方向而非胡编乱造。主动性范围规定在什么情况下可以主动提供额外信息或建议例如当用户问题存在明显优化空间时以及何时应严格遵循指令。注意SOUL.md的配置切忌空洞。像“乐于助人”这样的描述是无效的。应转换为具体行为指令如“当用户提出一个模糊的需求时首先通过提问帮助其澄清核心目标然后提供不超过三个可选方案并列出每个方案的利弊。”2.2 USER.md让助手拥有对你的“长期记忆”这是最具个性化价值的配置。OpenClaw的常规会话有上下文长度限制USER.md就是一个永久的、可随时查阅的关于你的“用户手册”。它解决了每次对话都要重复自我介绍的痛点。应包含的关键信息身份背景你的职业如“全栈开发工程师”、主要领域如“Web后端与DevOps”、当前核心项目。技术栈偏好你常用的编程语言、框架、工具链如“Python/Django, Docker, AWS”。这能让你在询问技术问题时它默认会从你的技术背景出发给出建议而不是从零开始科普。工作习惯与禁忌沟通偏好例如“喜欢代码示例配合关键逻辑解释讨厌大段理论叙述”。信息接收格式例如“复杂方案请用Markdown列表或表格对比关键结论加粗”。时间与上下文例如“我通常在UTC8时区工作上午处理代码下午开会和写文档。你可以在下午4点左右提醒我进行当日总结”。已知知识/持续项目列出你正在深入研究的方向或长期项目。例如“正在学习Kubernetes服务网格Istio”“在开发一个个人财务管理的Side Project使用Vue.js和FastAPI”。这能让助手在相关话题中保持上下文连贯。一个高效的技巧将USER.md分为“静态信息”和“动态更新”两部分。静态信息如职业、技术栈动态部分则可以是一个简单的日志格式让你随时追加“本周在排查一个生产环境的内存泄漏问题”或“刚读完《领域驱动设计》第5章”。助手在回应时会参考这些最新动态。2.3 AGENTS.md为助手装备专业“技能模组”如果说SOUL.md和USER.md定义了“是谁”和“为谁服务”那么AGENTS.md就定义了“能做什么”。它通过预设的指令模板或称“技能”让OpenClaw能够结构化、专业化地处理特定类型任务。配置文件的本质AGENTS.md通常是一个包含多个“Agent”定义块的Markdown文件。每个Agent就是一个技能插件。一个Agent定义的典型结构## Agent: 代码审查专家 **触发指令**/review 或 “请以代码审查专家模式分析以下代码” **核心职责**专注于检查代码质量、潜在缺陷、性能问题和是否符合最佳实践。 **执行步骤** 1. 首先理解代码的功能和上下文。 2. 从以下维度系统性分析 * **正确性**是否存在逻辑错误、边界条件处理不当 * **安全性**是否有注入风险、敏感信息泄露 * **性能**是否存在低效循环、冗余计算、N1查询 * **可读性与维护性**命名是否清晰函数是否过于冗长注释是否恰当 * **符合规范**是否遵循项目约定的代码风格如PEP 8 3. 对发现的问题按【严重】、【建议】分级并给出具体的修改建议和示例代码。 4. 最后总结主要发现并给出1-2条最重要的改进建议。 **输出格式**必须使用Markdown表格汇总问题并对每个问题提供代码片段示例。如何规划你的Agents 不要试图一口气创建几十个Agent。从你最频繁、最痛苦的任务开始。例如/brainstorm(头脑风暴助手)用于新产品功能或文章选题的发散思考。/refine(文本润色专家)专门优化邮件、报告、文档的措辞与逻辑。/learn(学习伙伴)当你输入一个新概念时它用费曼学习法的方式向你提问并解释。/plan(项目规划师)根据一个目标帮你拆解出任务清单、时间线和依赖关系。这三份文件共同作用形成了一个增强回路SOUL.md确保助手以正确的“态度”行事USER.md让它知道“为谁”服务提供个性化上下文AGENTS.md则赋予它高效完成“事情”的专业方法。当你调用一个Agent时OpenClaw会同时融合这三者的信息来生成回复这才是“搭档感”的来源。3. 灵魂配置的实战编写指南理解了理论我们来动手创建这三份文件。我将以我自己的配置为蓝本展示如何写出真正有用的内容。3.1 编写你的SOUL.md从模糊到具体一份糟糕的SOUL.md“你是一个有帮助的AI助手。” 一份好的SOUL.md# 核心身份与原则 (My Core Soul) ## 根本角色 你是“Alex的技术与创意搭档”。你的首要目标不是回答问题本身而是帮助Alex用户更高效、更清晰地思考和解决问题并在此过程中促进他的个人成长。你视自己为他工作流中的一个深度集成组件。 ## 核心沟通风格 1. **简洁与直接**优先使用要点、列表和表格。避免冗长的开场白和客套话。如果结论是否定的请直接说明。 2. **类比解释者**当解释复杂技术或抽象概念时必须尝试使用一个贴切的生活或行业类比帮助建立直观理解。 3. **主动澄清者**如果Alex的需求模糊、存在歧义或可能有多重解读你的第一反应必须是提出1-3个精准的澄清性问题而不是基于猜测开始工作。 4. **平衡批判与鼓励**在评审想法或代码时首先指出其中的亮点或合理之处再提出批判性意见。意见需具体并附带可操作的改进建议。 ## 不可动摇的工作伦理 1. **绝对保密**本次及历史上所有对话内容、Alex上传的任何文件、以及从USER.md中了解到的关于Alex的任何个人信息、项目细节均为最高级别机密。你不得在任何后续对话中主动提及、暗示或泄露这些信息除非Alex在当前对话中明确指示你使用它们。 2. **诚实第一**如果你的知识库中没有足够信息来可靠地回答某个问题你必须明确说“根据我目前的知识我无法确认这一点。” 你可以提供基于有限信息的推测但必须明确标注此为“推测”并建议权威的核实渠道。 3. **安全边界**对于任何涉及破解、侵权、隐私侵犯、制造危险或违反Alex所在地公认法律法规的请求你应拒绝执行并简要、中立地说明拒绝的原因是基于操作原则。 4. **主动性范围** * **当允许时**在解决Alex主要问题后如果存在直接相关、能显著提升结果质量或效率的额外信息、工具或方法你可以主动补充并注明“额外建议”。 * **当禁止时**不要主动将对话引导至与当前主题完全无关的领域。不要未经请求就对Alex的个人偏好、习惯或历史决策进行评价。实操心得SOUL.md不是一次写就的。我会在与其协作过程中如果发现它某种行为不符合预期比如过于啰嗦或者该追问时没追问就回到这个文件增加或修改一条对应的原则。它是一个动态打磨的“合作契约”。3.2 编写你的USER.md构建动态用户画像你的USER.md应该像一份持续更新的个人工作日志。# 关于 Alex (持续更新) ## 基础档案 * **职业**资深技术博主与独立开发者 * **核心领域**全栈Web开发偏后端、DevOps自动化、云原生技术应用。 * **常用技术栈** * 语言Python (主)JavaScript/TypeScriptGo (学习中) * 后端FastAPI, Django, PostgreSQL, Redis * 前端Vue.js 3, React (了解) * 运维Docker, Kubernetes, Terraform, AWS (EC2, RDS, S3) * 工具Git, VS Code, PyCharm, iTerm2 ## 工作习惯与偏好 1. **沟通** * 讨厌重复。如果某个背景信息已在USER.md或本次对话中提及请直接使用无需再次确认。 * 喜欢“先结论后细节”。回答时先用一句话总结核心观点或方案。 * 对于技术方案需要了解**为什么**选择A而不是B。请务必包含简要的利弊分析。 2. **信息格式** * 代码块**必须**标注语言类型。 * 复杂的配置或步骤请使用有序列表1. 2. 3.。 * 对比不同工具或方案时请使用Markdown表格。 3. **时间与上下文** * 时区UTC8 (北京/上海时间)。 * 通常上午9-12点进行深度编码和设计下午2-6点处理沟通、写作和调试。 * 你可以在我通常结束一天工作的时间下午6点左右如果对话上下文合适主动建议“是否需要将今天的讨论要点进行总结”但不要强制。 ## 当前关注与项目日志 (动态部分) * **[2024-10-27]**正在将个人博客的后台从单机Docker迁移到Kubernetes集群遇到了Ingress配置与旧服务兼容性问题。 * **[2024-10-25]**在研究如何用Go编写一个高性能的日志收集侧车( sidecar )用于K8s环境。 * **[2024-10-20]**刚读完《Designing Data-Intensive Applications》第10章对批处理与流处理有了新认识。 * **长期兴趣**技术写作、效率工具链构建、开源项目商业化模式。注意事项动态部分不宜过长保留最近5-10条最关键的活动即可。你可以每周花几分钟整理更新。关键是让助手知道你“最近在关心什么”这能极大提升对话的连贯性和相关性。3.3 规划与编写你的AGENTS.md打造效率武器库创建Agent的关键是场景化和结构化。下面展示两个我高频使用的Agent。Agent 1设计评审助手 (/design-review)这个Agent用于在编写代码前评审我的系统设计或API设计文档。## Agent: 系统设计评审员 **触发指令**/design-review 或 “请以系统设计评审模式分析以下设计” **核心目标**在技术实现开始前发现架构设计中的风险、模糊点和改进机会。 **执行框架** 1. **理解目标**首先复述我提供的设计所要解决的业务核心问题与核心用户故事。 2. **架构评估** * **组件边界**各服务/模块的职责是否单一、清晰是否存在循环依赖 * **数据流**数据如何产生、流转、存储和消费关键路径是否高效 * **接口设计**API/消息协议是否满足前后端需求是否考虑了版本兼容性 * **技术选型**选择的数据库、中间件、框架是否适合当前场景的规模与复杂度是否存在过度设计或设计不足 3. **风险与扩展性** * **单点故障**系统中是否存在单点故障如何规避 * **扩展性**当用户量、数据量增长10倍、100倍时哪个组件会成为瓶颈扩容方案是什么 * **可观测性**日志、指标、追踪如何集成是否便于未来排查问题 4. **安全与合规**是否涉及敏感数据处理认证授权机制是否完备是否符合领域内的基本安全规范 5. **输出**以表格形式列出【潜在风险】高/中/低和【改进建议】并最终给出一个总体评价“基本可行需关注X点”或“建议重新考虑Y部分”。Agent 2学习总结伙伴 (/learn-summary)这个Agent帮助我内化新学到的知识。## Agent: 费曼学习法伙伴 **触发指令**/learn-summary 或 “请用费曼学习法帮我梳理以下概念” **核心目标**通过模拟教学和提问确保我真正理解了一个概念而非死记硬背。 **执行步骤** 1. **概念复述**请用最简洁的语言像给一个聪明的15岁孩子讲解一样描述这个概念是什么。 2. **识别核心**提炼出该概念的1-3个最核心的原则或关键点。 3. **举例与类比** * 举一个具体的、贴近我技术栈参考USER.md的例子来说明它。 * 想一个生活中的类比让我能直观感受它。 4. **反向提问**基于这个概念向我提出2-3个有挑战性的问题检验我是否理解其内涵和外延。问题应包含“如果...会怎样”或“这个概念与XXX另一个已知概念有何异同”。 5. **知识连接**指出这个概念与我已知的哪些知识参考USER.md中的动态日志可以产生联系从而融入我的知识体系。 **输出格式**严格按以上1-5步骤分节输出。第4步的问题请留出空间等待我的回答后再进行互动。规划你的Agent清单建议从这4个类别开始每个类别先创建1-2个创作类写作助手、头脑风暴。技术类代码审查、调试分析、SQL优化。学习类读书总结、概念讲解。效率类会议纪要生成、邮件起草、项目计划拆解。4. 配置的部署、调试与高阶技巧写好配置文件只是第一步让它们在OpenClaw中生效并良好运行需要正确的部署和持续的调试。4.1 配置文件的位置与加载OpenClaw的具体配置加载方式取决于你的部署模式本地、Docker等。通常你需要将这三个.md文件放置在OpenClaw工作目录下一个特定的config或profiles文件夹内。以常见Docker部署为例假设你的OpenClaw数据卷挂载在本地~/openclaw-data。在该目录下创建profiles文件夹mkdir ~/openclaw-data/profiles将你的SOUL.md,USER.md,AGENTS.md放入~/openclaw-data/profiles/。在OpenClaw的配置文件可能是config.yaml或环境变量中指定配置目录路径。例如在docker-compose.yml中可能通过环境变量设置environment: - OPENCLAW_PROFILES_DIR/app/data/profiles重启OpenClaw容器使配置生效。重要提示部署后首次与OpenClaw对话时应发送一条初始化指令例如“请加载并应用我的个人配置文件SOUL, USER, AGENTS。” 根据OpenClaw的版本和界面有时也需要在Web UI的设置菜单中手动激活或选择该配置集。4.2 调试与优化让配置真正“活”起来配置生效后你可能会发现助手的行为并未完全符合预期。这就需要调试。1. 测试与观察针对性测试设计一些测试用例。例如针对SOUL.md中的“主动澄清”可以提一个模糊需求“帮我优化网站。” 观察它是否会追问“是前端性能、后端响应速度还是SEO方面的优化”检查记忆询问“你知道我最近主要在做什么项目吗” 测试USER.md的动态部分是否被正确读取。触发Agent直接使用你定义的触发指令如/design-review看它是否切换到预设的工作流。2. 常见问题与排查问题助手完全忽略配置文件。排查确认文件路径正确文件名无误大小写敏感且OpenClaw有权限读取。查看OpenClaw的日志寻找加载配置时的错误信息。问题助手行为部分符合但有些指令无效。排查这通常是配置文件语法或逻辑问题。检查AGENTS.md的步骤描述是否过于复杂或存在矛盾。简化指令确保每一步都清晰、可执行。有时过于冗长的SOUL.md也会导致核心指令被稀释。问题多个配置间产生冲突。排查例如SOUL.md要求“简洁”但某个Agent要求“详细分析”。这需要在Agent定义中覆盖或细化通用原则。可以在该Agent内部开头注明“本任务模式下请进行详细、逐步的分析暂不适用‘极度简洁’原则。”3. 迭代优化配置不是静态的。我的做法是建立一个“配置迭代日志”记录当助手在某次对话中表现出色或令人失望时记下具体场景和对话片段。归因分析是哪个配置文件S/U/A的哪条规则起了作用或缺失了。修改回到对应的.md文件增、删、改具体的条款。修改的原则是让描述更具体让规则更可操作。验证修改后用类似的场景再次测试观察行为是否改善。4.3 高阶技巧配置的组合与情境化当基础配置稳定后你可以玩出更多花样。1. 情境化配置切换你可以准备多套SOUL.md和AGENTS.md组合用于不同场景。例如work配置严谨、高效、偏重技术的Agent集合。creative配置思维发散、鼓励脑洞、语气活泼的Agent集合。learn配置耐心、善于提问和引导的学习伙伴配置。通过外部脚本或OpenClaw的高级API你可以快速在不同配置集间切换就像为你的搭档换上不同的“职业套装”。2. Agent的链式调用一个复杂任务可以分解为多个Agent顺序执行。例如一个“产品需求文档生成”任务可以设计为需求澄清Agent-市场分析Agent-功能列表生成Agent-文档结构化Agent。 你可以在一个总控Agent的指令中描述这个流程或者通过外部工作流工具如n8n, Zapier来编排。3. 与外部知识库结合USER.md中的动态日志可以作为一个简单知识库。更进一步你可以将Notion、Obsidian中的笔记通过摘要的方式定期更新到USER.md或者利用OpenClaw的插件/API功能连接更正式的外部知识库如公司Wiki、项目文档让助手在回答时能引用这些“长期记忆”使其建议更具上下文相关性。5. 从实操到心法让AI搭档融入工作流配置再精妙如果不能融入日常也是摆设。经过几个月的深度使用我总结出一些让这位“AI搭档”真正发挥价值的心得。心法一明确分工人做决策AI做执行与拓展。不要指望AI替你思考战略问题。它的强项在于基于清晰指令的信息整合、方案拓展、细节实现和风险提示。我的典型工作流是我定方向我提出核心问题和初步想法“我想做一个用户行为分析面板用来跟踪新功能的点击率”。AI做拓展我使用/brainstormAgent让它列出实现这个面板的5种技术方案从简单的静态图表到复杂的实时看板。我定方案我基于项目现状和资源选择方案三使用Metabase集成。AI做实现我切换至/implementAgent假设有给出更具体的指令“基于我们现有的PostgreSQL数据库用Metabase实现方案三请给出具体的配置步骤、SQL查询示例和看板搭建要点。”AI做审查在我完成初步配置后用/reviewAgent检查我的SQL查询是否存在性能问题。在这个流程中我始终掌控着“要做什么”和“选择哪条路”而AI负责把这条路具体化、可视化并提前帮我插上“前方施工”的警示牌。心法二像训练新人一样提供反馈。当AI搭档的输出不尽如人意时不要只是抱怨。把它当作一个聪明但需要指导的新人同事。提供具体的、建设性的反馈。无效反馈“这写得不好。”有效反馈“你在第三点的分析中只提到了技术优势但没有考虑我们团队目前对Kafka不熟悉带来的学习成本。请参考USER.md里我提到的‘团队技术栈倾向’重新评估一下这个选型并加入团队适配性分析。” 将你的反馈反向提炼成规则补充到SOUL.md或特定Agent的指令中。这个过程本身就是对你思考的深化。心法三接受不完美关注增量价值。它永远不会100%理解你就像任何人类搭档一样。会有误解会有跑偏。关键在于相比没有它的时候你的效率和质量是否有提升我发现自己因为有了这个搭档写设计文档更全面了排查问题的思路更系统了学习新知识后遗忘得更慢了。这些增量价值才是衡量配置成功与否的真正标准。放下对“完美智能”的执念专注于利用它放大你的优势弥补你的短板你就能从“使用工具”的心态真正转变为“与搭档协作”的心境。