Category: AI

背景 某本地 AI 代理系统已经开始定期执行 HEARTBEAT 任务，并能够通过邮件发送状态报告。整体执行链路已经跑通：任务可以被触发，邮件可以正常发出，收件端也能收到报告。 不过在实际使用后，暴露出两个需要调整的问题： 第一，HEARTBEAT 执行频率过高。默认频率约为 30 分钟一次，对于日常状态汇总来说过于密集，容易造成邮件噪音。 第二，新闻摘要任务的输出质量不理想。虽然系统能够抓取公开 RSS 新闻标题并生成邮件，但内容基本停留在“标题列表 + 固定占位摘要”的层面，缺少真正可读的摘要信息。 因此，这次调整主要围绕两个目标展开： 问题一：新闻摘要内容过于粗糙 原先的新闻邮件结构大致如下： 这种输出存在明显问题： 期望的格式是每条新闻形成一个小型三语新闻卡片，例如： 这种格式的优点是： 新闻摘要任务规则的修改 原来的任务说明只要求“发送一封简洁的中文新闻摘要邮件”，这会导致 AI 代理自然倾向于输出中文简报，而不是三语新闻卡片。因此，任务规则需要明确改写。 修改后的规则重点包括： 修改后的核心目标不是“多翻译几种语言”，而是让邮件本身变成可读、可用、可追溯的国际新闻摘要。 问题二：HEARTBEAT 默认频率过高 另一个问题是 HEARTBEAT 默认频率较高。系统状态检查本身已经正常执行，但 30 分钟一次对于当前用途来说没有必要。 经过只读检查后，确认当前系统并不是通过外部定时器或 cron 控制 HEARTBEAT，而是由 AI 代理自身的配置项控制。 检查结果显示： 因此，最终修改目标是： 修改方式 修改前先进行了 dry-run，确认配置写入动作可以被接受。 示意命令如下： dry-run 成功后，再实际写入： 系统返回配置已更新，但同时提示需要重启 …

本地 AI 代理系统真正进入长期使用阶段后，最重要的问题不再只是“它能不能完成任务”，而是“它以后会不会按照稳定、可预期、边界清楚的方式完成任务”。 一次迁移、一次修复、一次浏览器调用、一次误操作事故，如果只停留在当前对话里，很快就会消失。下一次再遇到类似场景，代理可能重新犯同样的错误。 因此，迁移完成后的一个重要收尾工作，是把经验写入长期规则文件。 在这个过程中，TOOLS.md 成为最关键的文件之一。 为什么需要长期规则 AI 代理和普通脚本不同。 普通脚本只会执行写死的逻辑。AI 代理则会根据自然语言指令、上下文、工具可用性和自己的推断来决定下一步操作。 这带来灵活性，也带来风险。 如果只告诉代理： 它可能会自己推断出很多没有被允许的做法： 这些推断未必是恶意的，但可能与实际使用场景冲突。 因此，长期规则的作用不是单纯记录“怎么做”，还要记录： 对长期运行的 AI 代理来说，负面边界和正向流程同样重要。 日期记忆不适合保存持续规则 很多代理工作区会有按日期排列的记忆文件，例如： 这类文件适合记录当天发生了什么： 但它们不适合作为长期规则的唯一来源。 原因是日期文件本质上是事件记录，而不是行为规范。代理以后要决定如何调用工具时，不一定会优先读取某一天的历史记录。 例如： 这条记录能说明事情发生过，但不能保证代理以后每次用浏览器都遵守这些规则。 因此，持续规则应该写入专门的规则文件。 为什么浏览器规则应该写入 TOOLS.md 在 OpenClaw 工作区中，不同 Markdown 文件承担不同职责。 抽象上可以这样划分： 远程浏览器/CDP 能力本质上是一个工具。它不是用户偏好，也不是人格设定，也不是普通历史记忆。 它包含： 所以它应该写入 TOOLS.md。 这能让代理在以后调用浏览器时，把它当作一个受约束的工具，而不是凭当前对话临时推断。 工具规则不只是命令 一个常见误区是把工具规则写成几条命令。 例如： 这还不够。 真正可长期使用的工具规则应该包含五个层次： 以远程浏览器为例，资源定义应包括： 使用前检查应包括： 正常启动流程应包括： …

主实例迁移完成后，旧主机上往往会留下大量重复文件。 这些文件看起来像“迁移残留”，但不能直接删除。因为旧主机上可能同时保留着几类不同性质的数据： 如果不加区分地删除旧工作区，很容易误删尚未迁移的项目、迁移后仍需要的扩展资源，或者旧主机上独有的备份文件。 因此，迁移后的文件清理不能靠“看目录名猜”，而应该靠审计结果决定。 本篇记录的是一次通过相对路径、文件大小和 sha256 hash 对比，安全删除旧主机重复文件的过程。 清理前的基本局面 迁移完成后，系统已经形成新的主从结构： 旧主机上的大部分工作区文件已经迁移到新主机，但不是全部。 其中有一个大型项目目录因为新主机存储容量不足，暂时继续保留在旧主机上，作为扩展项目使用。另一个浏览器/CDP 目录也属于外部工具资源，不属于本次工作区清理范围。 因此，清理前必须先确定排除范围。 不能清理的目录 迁移后文件清理首先要明确两类禁止触碰目录。 第一类是大型项目目录。 它因为容量原因没有迁移到新主机，仍然需要继续保留在旧主机上。如果清理脚本把它当成普通迁移残留，就会造成严重误删。 可以抽象表示为： 第二类是浏览器/CDP 专用目录。 这个目录用于远程浏览器能力，属于旧主机作为扩展资源主机的一部分，不是旧 OpenClaw 主实例残留。 可以抽象表示为： 因此，清理审计范围应该是： 这个边界非常重要。否则“清理旧工作区”很容易被误解成“删除旧主机上所有 OpenClaw 相关目录”。 为什么不能直接用 rsync –delete 迁移清理中，rsync –delete 看起来很诱人。它可以让两个目录快速变成一致状态。 但在这个场景中，它并不适合。 原因是旧主机上故意保留了一些新主机没有的内容。如果直接用 rsync –delete 或类似逻辑，就可能把旧主机独有但仍然需要的文件删除。 尤其是以下几类文件： 因此，本次清理不追求两个工作区完全一致，而是只删除那些已经被确认“新主机上有同名文件，且内容完全相同”的文件。 这比 rsync –delete 更保守，也更适合迁移后的分层清理。 审计方法：相对路径、大小和 sha256 安全清理的核心是生成两边文件清单。 对旧主机工作区生成 …

在本地 AI 代理系统中，浏览器自动化是一项非常有用的能力。代理可以打开网页、搜索信息、读取页面、协助登录后台、处理表单，甚至通过 CDP 控制完整浏览器。 但浏览器自动化也有一个明显风险：如果代理没有严格区分“自己可管理的浏览器”和“用户正在使用的普通浏览器”，它就可能误伤用户的真实桌面环境。 本篇记录的是一次典型的边界事故：AI 代理本来只应该打开和关闭自己的专用浏览器，却因为使用了过宽的进程匹配，把用户正常使用的普通 Brave 浏览器也关闭了。 这不是单纯的命令错误，而是一次权限边界设计错误。 背景：主实例和浏览器分离 迁移后的结构中，OpenClaw 主实例运行在常驻主机上，桌面浏览器运行在另一台桌面主机上。 浏览器调用链路大致是： 为了隔离用户日常浏览器和 AI 代理浏览器，桌面主机上准备了一个专用 profile： OpenClaw 只能使用这个专用 profile。用户日常使用的普通 Brave profile、普通窗口、普通标签页和普通会话，都不属于 OpenClaw 的管理范围。 从设计上看，这个边界是清楚的。 但事故说明：只靠“人知道边界”不够，必须让 AI 代理的规则和命令也严格遵守这个边界。 事故经过 最初的任务很简单：让 AI 代理在桌面主机上远程打开一个可见 Brave 窗口，用于测试浏览器/CDP 能力。 代理确实打开了一个新的可见窗口。 但在打开之前，它先关闭了桌面主机上原本已经打开的普通 Brave 窗口。 随后，又让代理关闭刚才打开的浏览器窗口。结果它在关闭时，再次把用户后来重新打开的普通 Brave 窗口关闭了。 也就是说，事故不是一次偶发误操作，而是在两个阶段都发生了边界错误： 这说明代理没有把“OpenClaw 专用浏览器”和“用户普通浏览器”区分开。 真正的问题：它管理了 Brave 进程整体 …