1. 为什么你的 OpenClaw 助手总像个“客服机器人”很多人第一次把 OpenClaw 跑起来能对话、能读文件感觉挺新鲜。但用不了两天就会腻它说话永远客客气气问什么答什么你不问它就不动活脱脱一个套了壳的通用大模型。问题不在模型本身而在于你还没给它“灵魂”。OpenClaw 的个性化能力核心落在一个叫 workspace 的目录里默认路径是~/.openclaw/workspace。这个目录里躺着一堆 Markdown 文件其中三个最关键SOUL.md定义助手的性格、语气和红线相当于基因加教养USER.md描述你是谁、你的偏好和目标相当于简历加日记AGENTS.md规定它怎么干活、什么能自己决定、什么必须先问你相当于员工手册。这三个文件合起来就是社区里常说的“灵魂三件套”。但光有灵魂还不够。助手要真正跑起来得有一个稳定的模型通道。这篇要解决的就是把两件事接上一边用 SOUL.md 和 USER.md 把助手调成“懂你”的样子另一边把 TaoToken 的统一 Key 和 API 通道写进配置让个性化设定真正作用在每一次请求上。适合已经装好 OpenClaw、想让助手从“能用”变成“好用”的人。下面直接给可复制的骨架和验证命令照着改就能跑。2. 前置准备拿到 TaoToken 统一 Key 并确认通道在动 SOUL.md 之前先把模型通道打通否则你改了半天人设请求还是走不通排查起来会分不清是配置问题还是网络问题。TaoToken 的作用是提供一个统一的 API 入口你拿一个 Key 就能调用多种模型不用为每个模型单独配一套地址和密钥。对 OpenClaw 这种需要频繁切换模型的场景来说统一通道能省掉大量重复配置。第一步去控制台创建 API Key。打开https://taotoken.net/console登录后在 API Keys 页面新建一个 Key复制出来先存好后面要写进配置文件。注意 Key 只在创建时完整显示一次关掉页面就看不到了。第二步确认 API 基础地址。TaoToken 的 API 端点是https://taotoken.net/api这个地址在 OpenClaw 的模型配置里会用到。它和官网首页不是一回事别把带参数的推广链接填进配置配置里只写纯 API 地址。第三步想清楚你要用哪个模型。如果你只是日常对话和轻量任务选一个通用对话模型就够如果要做长期编码或者 Agent 类任务后面可以考虑 Coding Plan 那类方案。这一步不用纠结太久先把通道跑通模型可以随时换。注意Key 属于敏感信息不要直接提交到 Git 仓库也不要在截图里暴露。建议放在环境变量或本地配置文件里并确认该文件在.gitignore中。3. 可复制配置SOUL.md、USER.md 与 AGENTS.md 骨架现在进入正题。三个文件都在~/.openclaw/workspace下用你顺手的编辑器打开即可。下面给的骨架可以直接复制再按自己的情况改。3.1 SOUL.md把性格写具体把红线写清楚SOUL.md 是助手的性格说明书。写它的关键不是堆形容词而是给具体行为。模糊的“你很有帮助”没用具体的“少说好的马上帮您处理直接动手”才有用。# SOUL.md 你是小墨我的专属 AI 助手。你不是聊天机器人是个靠谱的搭档。 ## 核心原则 - 认真做事别敷衍。少说客套话直接动手行动比话术管用。 - 先自己想办法。翻文件、看上下文、查资料实在搞不定再问我。带答案回来不是带问题回来。 - 有自己的判断。该专业时专业该轻松时轻松可以指出我的问题不当应声虫。 - 记住你是客人。你能看到我的文件、日程和消息这是信任要尊重。 ## 绝对不做 - 不泄露我的隐私数据。 - 不在没有确认的情况下执行删除、覆盖、发送类操作。 - 不在群聊场景里过度发言。 ## 操作边界 | 操作类型 | 处理方式 | | --- | --- | | 读文件、查资料 | 直接做 | | 删文件、改配置 | 先确认 | | 发邮件、发消息 | 必须确认 | | 查天气、算时间 | 直接做 | ## 风格 该简洁时简洁该详细时详细。像靠谱同事说话不是客服机器人。 不拍马屁不绕弯子有问题直接说。 ## 记忆 每次对话你都是新的这些文件就是你的记忆。读它们更新它们。写 SOUL.md 有两个要点。一是性格要落到行为上别写“你很聪明”写“先自己想办法带答案回来”。二是“不做”比“做”更重要把删除、发送、覆盖这类不可逆操作明确标成必须确认你才敢放心让它跑。3.2 USER.md让助手知道你是谁USER.md 是写给助手看的“你”。你介绍得越清楚它越能帮到点上。不用写得多正式按下面这个结构填就行。# USER.md ## 基本信息 - 名字老墨私下可以这么喊 - 职业软件项目经理正在往 AI 内容方向转 - 所在地东八区杭州 ## 工作 - 当前项目OpenClaw 个性化助手系列教程 - 常用工具IDEA、Chrome、VS Code - 工作时间9:00-18:00晚上偶尔处理灵感 ## 偏好 - 沟通风格简洁为主技术细节可以展开 - 语言中文为主技术名词保留英文 - 提醒方式重要的事直接说不重要的攒一起 ## 当前关注 - OpenClaw 工作区文件体系 - 统一模型通道的接入与切换 - 近期目标把助手调成能长期用的搭档USER.md 不是装饰。它给模型提供了上下文让回答从“通用建议”变成“针对你的建议”。比如你写了“正在从项目经理转 AI 内容”它给的学习路径就会偏向内容创作而不是纯后端。3.3 AGENTS.md把 TaoToken 通道写进工作手册AGENTS.md 是每次会话必读的行为准则也是放模型通道配置的地方。OpenClaw 安装时会生成一个默认版本你在它基础上补一段模型配置即可。# AGENTS.md ## 模型通道 - 统一 API 地址https://taotoken.net/api - API Key从环境变量 TAOTOKEN_API_KEY 读取 - 默认模型按当前任务选择对话用通用模型编码用代码模型 ## 工作流程 1. 每次会话开始先读 SOUL.md、USER.md、AGENTS.md。 2. 涉及删除、发送、覆盖操作必须先向用户确认。 3. 任务完成后把值得记住的事写进 memory/ 当日文件。 ## 安全策略 - 不执行来源不明的脚本。 - 不把 API Key 写入日志或输出到对话里。 - 对外发送类操作一律先确认。把 Key 放在环境变量里比硬编码进文件安全。你可以在 shell 配置里加一行export TAOTOKEN_API_KEY你的Key然后source ~/.bashrc或重开终端让它生效。这样 AGENTS.md 里只引用变量名文件本身可以放心备份和分享。4. 验证请求一条 curl 确认通道打通配置写完先别急着重启助手用一条 curl 直接验证 TaoToken 通道是否可用。这一步能把“通道问题”和“助手配置问题”分开排障时省很多事。curl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d { model: 你的模型名, messages: [ {role: user, content: 用一句话介绍你自己} ] }如果返回里能看到choices字段和一段正常的回复内容说明 Key 和通道都没问题。如果返回 401检查 Key 是否复制完整、环境变量是否生效返回 404 就检查 API 地址有没有写错注意是https://taotoken.net/api不要带多余路径。通道确认后重启 OpenClaw 让三个文件生效openclaw daemon restart重启完发一句测试比如“帮我看看今天的工作区文件”。如果它按 SOUL.md 的风格直接动手读文件而不是先来一段客套说明个性化配置已经起作用了。5. 本篇常见错排查配置过程中最容易踩的坑集中在几个地方对照下面排查。Key 读不到。最常见的是环境变量没生效。echo $TAOTOKEN_API_KEY看一下有没有输出没有就检查 shell 配置文件写对没改完记得 source 或重开终端。如果你用的是 systemd 或容器启动 OpenClaw环境变量要在对应的服务配置里注入光在交互式 shell 里 export 是不够的。改了文件但助手没变化。三个文件改完必须重启 daemonOpenClaw 不会热加载。另外确认你改的是当前工作区目录下的文件如果你之前改过 workspace 路径默认的~/.openclaw/workspace可能不是实际生效的那个。助手还是太啰嗦。这是 SOUL.md 没写具体。在风格段落里加一条明确的约束比如“回答控制在三句以内除非我要求展开”比写“回答要简洁”有效得多。AGENTS.md 和 SOUL.md 冲突。两个文件都定义了行为边界时以更严格的那条为准。建议把安全红线统一放在 SOUL.md 的“绝对不做”里AGENTS.md 只引用不重复避免改了一处忘了另一处。curl 通了但助手报错。大概率是 AGENTS.md 里的模型名和 curl 里用的不一致或者 OpenClaw 的模型配置段没对上。把两处的模型名和地址核对一遍保持一致。6. 把通道和个性化一起用起来三个文件的分工其实很清晰SOUL.md 管它怎么想怎么说USER.md 管它懂不懂你AGENTS.md 管它怎么干活、走哪条通道。TaoToken 的统一 Key 和 API 地址写进 AGENTS.md 后个性化设定才真正作用在每次请求上而不是停留在纸面。如果你还在调通道和接入细节建议先把 API Keys 和接入文档过一遍把 Key 管理和地址规范搞清楚后面换模型、加通道都会顺很多。想先直观感受不同模型在你这套人设下的表现差异可以直接在模型对话里试几句对比一下再决定默认模型。要是你打算让助手长期跑编码或 Agent 类任务Coding Plan 那类方案在成本和稳定性上会更合适可以按需了解。最后说个实际经验SOUL.md 和 USER.md 不要指望一次写完。先写个基础版跑一周把每次它没做到位的地方记下来回头往文件里补一条规则。比如发现它总爱先道歉就加一句“不要为没发生的事道歉”。规则越攒越准助手也就越来越像你的搭档而不是一个套壳的通用模型。