Matthew Berman 如何组织并保护自己的 OpenClaw 系统

NVIDIA 首席执行官 Jensen Huang 在开场表示，企业和软件公司需要智能体战略。我花了大量时间配置 OpenClaw，希望分享一些让助手更易使用和维护的实践。这些是我的配置选择，并不保证每个系统都有相同表现。

最简单的改进之一是按主题拆分对话。一个很长的聊天会混合无关话题，让回到之前的任务变得别扭，也会把许多无关上下文放进对话中。我使用一个只有我和机器人参与的 Telegram 群组，分别为日常工作、客户关系、知识库和定时更新建立主题。

在我的配置中，每个主题都有自己的会话和聚焦的上下文，让我更容易在另一项工作进行时继续之前的对话。我发现这有助于智能体保持主题，也方便我整理工作。同样的原则可以用于其他支持适当线程功能的消息平台。

语音消息是另一个实用的移动端入口。我按住 Telegram 的麦克风按钮，说出问题或任务，就能收到回复，不必输入长提示词。我用它提问、布置任务和提出编程请求。具体可用功能取决于消息集成和助手配置。

这期视频的赞助商是 here.now，这项服务可以发布智能体创建的静态页面、图片和 PDF 等内容。我让智能体发布一份埃菲尔铁塔介绍，然后把页面改成纯文本。Berman 说，未认领的页面会在 24 小时后过期，创建账户认领后可延长使用；服务条款和价格可能变化。

我不会用一个模型完成所有任务。录制视频时，我的大部分主对话和编程使用 Anthropic 模型，GPT-5.4 作为备用，Grok 用于搜索，Gemini 用于视频和研究，Nomic 用于嵌入，Qwen 用于本地工作。这些是我的个人选择，会随着模型、可用性和配额变化而调整。

主模型负责规划和委派，因此我通常倾向于在这里使用能力较强的模型。简单工作用小模型可能更快、更便宜。OpenClaw 有模型和备用模型配置，我可以用 `/status` 查看主会话；分配并非完全确定，所以我仍会检查实际运行的是哪个模型。

在我的配置中，我也可以为特定线程指定模型：简单问答线程可能不需要与困难编程任务相同的模型。按工作选择模型有助于管理 token 用量、延迟和成本。小模型是否够用，应根据实际任务来衡量。

我正在探索用微调的本地模型替代适合的前沿模型任务。对于邮件标注，我收集了带标签的示例并训练了一个 90 亿参数的 Qwen 模型；在我自己的使用中，它在这一特定任务上的表现与 Opus 4.6 相当。这是我的个人经验，不是全面比较或已发表的基准；本地硬件和训练仍有成本。

我将较长的任务委派出去，这样我继续对话时主智能体不会被阻塞。我的规则是，预计超过十秒的工作就委派，包括编程、搜索、多步骤处理、文件操作以及日历或邮件工作。简单回复、澄清和快速读取由主智能体处理。委派仍然可能失败或选择错误的路径。

主智能体可以给子智能体分配不同的模型，也可以调用 Cursor Agent 或 Claude Code 等编程工具。工具可以执行任务，通过子智能体将摘要返回主智能体。我倾向于尽早委派：简单任务选择便宜的模型，需要时再选择能力更强的模型。

不同模型对提示词结构的反应可能不同，因此我为不同模型系列维护独立版本的指令文件。我以各服务商的提示指南为起点，并告诉 OpenClaw 使用哪些文件。我关于大写字母或否定指令的例子只是经验法则，不是普遍规则；应结合具体任务和模型测试提示词。

我保留一套主要指令和一套单独的备用指令，每晚运行任务比较它们。任务检查两套指令的实质内容是否一致，同时反映各模型的提示建议。把这一安排写进文档，有助于智能体选择正确的版本。

定时任务，也称 cron，可以在我不必每次提出请求的情况下执行重复工作。我将许多日常维护任务分散到夜间，那时我较少使用系统，可以减少资源竞争并管理滚动使用额度。例如检查任务运行状况、提示词和配置的一致性，以及备份。

其他任务每隔几个小时运行，包括同步 HubSpot 和 Asana，以及检查个人信息或密钥。定时安排让重复工作更方便，但任务仍需要监控：身份验证失败或其他错误可能影响多个依赖它的任务。

安全很重要，因为智能体可以读取不可信的外部内容并使用强大的工具。提示注入是指在网页、邮件或其他材料中放入指令，试图让智能体偏离授权任务。我把输入材料视为可能不可信，并使用多种防御；没有任何单一扫描器能保证捕获所有攻击。

我的第一层使用常规代码扫描输入文本中的可疑模式和异常字符。第二层使用模型扫描器审查通过第一层的材料，给出风险分数并在必要时隔离内容。模式匹配和模型审查都可能漏掉攻击或误判无害内容，因此我不会把它们当作完整的安全边界。

我还检查输出内容中是否包含密钥和个人身份信息，并积极进行脱敏。有时这意味着我必须明确授权分享安全的信息。脱敏是另一道保障，而不是能够检测出所有敏感数据的证明。

我严格限制权限：助手可以读取我的邮件，但不能发送；可以读取 Box 文件，但不能删除。破坏性操作需要我的批准。即使前面的筛查失败，这些限制也能约束注入指令或智能体失误可能造成的影响。

另一个担忧是“耗尽钱包”：攻击者可能发送大量材料，消耗安全扫描器使用的模型预算。失控循环也可能带来类似费用。我的运行时治理通过支出上限、调用量限制和循环检测来约束这两种情况。

我保留日志，以便调查故障而不是靠猜测。每天早上我让系统检查夜间错误并提出修复方案。演示中的 Google 身份验证问题影响了收件箱刷新和依赖日历的每日简报，此外还有一个较小的代码错误。日志可能包含敏感信息，因此需要谨慎管理访问权限和保留期限。

我定期用定时任务检查 OpenClaw 更新，汇总更新日志并更新安装。安全修复很重要，但自动更新和重启也可能干扰系统；测试和恢复方案会有所帮助。合适的更新频率取决于部署方式。

我建议根据自己的工作负载比较订阅访问与 API 定价。我介绍了自己配置中使用服务商订阅的方法，但允许的集成、使用限额和价格各不相同。应查看具体应用的最新服务商条款和文档，而不是假设所有 OAuth 或 SDK 用法都获准；[OpenAI 介绍了在参与应用中支持的套餐使用方式](https://help.openai.com/en/articles/20001542-using-your-chatgpt-plan-in-other-apps-and-sites)。

文档让系统更容易运行。我维护产品需求文档、工作流说明、工作区组织说明、提示指南和安全笔记，也用一个经验文件记录错误。每天的任务会比较文档、代码和提交记录，找出遗漏，但生成的更新仍需审查。

Git 记录代码版本，使我们能够检查最近的改动或恢复到较早状态。我还把快照推送到 GitHub，作为设备之外的一份副本。不在 Git 中的数据库、图片和 PDF 需要单独备份；我用 Box 保存这些文件。只有能够恢复的备份才有用。

测试用于检查代码是否按预期运行。我的简单例子是验证二加二是否等于四；对于实际系统，测试应覆盖有意义的行为和失败情况。日志、文档、版本控制、独立备份和测试都有助于管理不断演进的智能体系统。

为了减少定时任务带来的打扰，我把低优先级通知汇总成每三小时一份的摘要，把较高优先级事项汇总成每小时一份。助手不可用等关键事件会绕过汇总，立即通知我。如果摘要指出值得调查的问题，我可以要求更多细节。

最后，我更喜欢在 Cursor 等独立编程环境中构建和修改 OpenClaw 系统，而用 Telegram 进行日常交互。也可以使用 Codex、Claude Code 或文本编辑器。对我来说，专门的开发界面比聊天窗口更方便检查代码和迭代。