-----META-START-----
created: 2026-05-02T10:45:43.384Z
updated: 2026-05-06T17:29:05.880Z
summary: AI身份确立（虾宝=119.29.241.85当前服务器，虾咪=152.136.58.12旧服务器）；响应规范五条；MiniMax新key更换；OpenClaw迁移至119；龙虾→Hermes系统更替；技能优先调用原则确立；7条操作规则完整确立（连续exec分身份后台执行、工具操作必须分身、文件操作两步法、sleep前告知、QQ沉默执行、停止立即停、记忆写入强制）；exec串连>3主动开分身规则；服务故障主动上报原则确立；GLM-4.6V限流+夸克OCR备选失败强化禁止瞎猜原则。
heat: 99
-----META-END-----

> 📌 **记忆整合备注（2026-05-06 08:18）**：新批次记忆整合：①虾咪会话记录调查完整失败（memory-tdai不存在、/home/ubuntu/.openclaw/memory-tdai/路径过时、实际存储位置不明）；②MM决定自己搜索虾咪信息并要求AI停止操作；③停止指令承诺强化——收到stop/abort/停止立即停，不继续执行任何正在进行的任务。

## 用户基础信息
- 用户姓名：**XWJF**（QQ昵称：小旺 / 虾虾）
- AI助手名称：**小虾**（昵称"虾宝"，2026-05-03首次确认，2026-05-04持续使用）
- 默认模型：MiniMix-M2.7 → GLM-4V（多模态，支持图像识别）
- **文字模型**：MiniMax-M2.7（包月套餐，Token这个月之内随便用）
- **视觉模型**：glm-4.6v-flash（用于专门看图，2026-05-05 04:12配置统一修正，与infer_glmv.py、config.json、MEMORY.md三者一致）
- **多模态对话模型**：GLM-4V（日常多模态对话）
- 工具执行方式：分身（sub-agent）后台执行
- PC IP：100.105.23.114 / 10.114.121.229
- PC用户名：**xwjf**
- **【PC连接认证配置（2026-05-04）】**：采用密码认证方式连接PC；不将服务器119（119.29.241.85）的SSH公钥添加到PC；此配置决策必须持久写入记忆，不得遗忘
- 手机IP：100.114.227.26:2222（用户：u0_a424）
- **旧训练服务器**：172.29.1.103（已关闭，不再使用）
- **AI身份对应关系（2026-05-05 14:23确立）**：
  - **虾宝** = 当前服务器 **119.29.241.85**（4核4GB，主机名pw）
  - **虾咪** = 旧服务器 **152.136.58.12**（2核2GB，tailscale IP 100.108.100.58）
- **腾讯云服务器（152，虾咪/旧服务器）**：152.136.58.12（ubuntu / MYNmym888）
  - ⚠️ 安全组需开放 **TCP 39582端口** 才能通过公网访问网页端
  - **服务器规格（实测）**：2核2GB（⚠️ 不是503GB那台），物理内存2GB，当前内存占用约1.7GB，swap已开9.9GB，工作目录 `/root/.openclaw/workspace`，拥有root权限
- **用户腾讯云主机（119，虾宝/当前服务器）**：119.29.241.85（主机名pw，用户名ubuntu，密码MYNmym888，端口22）
  - **服务器规格（实测）**：4核4GB（纠正此前与旧服务器的混淆）
  - ⚠️ **【强制边界】不得修改AI自己的主机（152.136.58.12等），此为用户控制资产**
  - 主机名于2026-05-04T09:40:05由用户修改为"pw"
- **炎火云服务器**：103.236.97.252:58979（MYNmym888/MYNmym888，主机名liuliangmnboz6kN3Dkz）——**已停止使用**
- **【Minimax API Key（2026-05-05 10:30 更新）】**：`sk-skWuyEoP1NL1mX8S5f537bBcF4E04fD5B6Ff62999d9448C5`
  - **【Key有效性验证（2026-05-05 04:21）】**：AI测试确认旧Key可成功调用MiniMax-M2.7模型，无并发限制问题，Key本身状态正常
  - **【新Key更换（2026-05-05 10:30）】**：用户（tdai）提供新MiniMax API key，请求AI协助替换现有配置。AI在帮助用户将OpenClaw的session和记忆文件传输到远程分身（119.29.241.85），并准备更换配置中的minimax key。
  - **【Minimax API 中转站架构（2026-05-04 18:54 最新补充）】**：用户使用的是中转站的MiniMax API（非直连MiniMax官网），消息需要经过中转站再到达MiniMax。**具体中转站地址**：`guizhouyun.site:2177`，仅提供 **MiniMax M2.5 和 M2.7 模型**。**⚠️ 副作用**：这导致了聊天延迟较高，这是架构层面的限制，不是配置错误。
  - **【GLM API 中转站（2026-05-04 18:54）】**：GLM 模型走**另一个中转站** `open.bigmodel.cn`，与 MiniMax 中转站分离。
  - **配置读取原则**：用户明确要求AI在处理配置变更时，必须查看实际配置文件获取最新IP和Token信息，**而非直接使用记忆中的旧值**——配置文件是权威来源
- **【智谱API Key】：0f698efe296b47aaa9e68c7c676809e8.aMPQWlEr0kIlIeuN（2026-05-05 04:11更新为有效key，原占位符0a3f6e26...已废弃）**
  - **⚠️ API key 配置异常事件**：曾因智谱 API key 配置问题导致手机 OpenClaw 配置回退到 MiniMax 模型，AI 通过 SSH 连接手机（100.114.227.26:2222）将默认模型切换回 GLM-4.7-Flash
  - **【视觉分析功能修复完成（2026-05-05 04:11）】**：子agent发现并修复视觉技能config.json中的占位符API Key问题，将其更新为有效key（0f698efe...），视觉分析功能恢复正常
  - **【GLM视觉限流事件（2026-05-05 04:17）】**：智谱GLM服务器（glm-4.6v-flash）限流严格，返回**「访问量过大，请您稍后再试」**，此为服务端限流非key或配置问题
  - **【GLM视觉限流事件（2026-05-06 10:08-10:12 UTC）】**：AI再次尝试使用GLM-4.6V处理图片时，遭遇**429 Rate Limit**——这是GLM服务端在短时间内大量请求后的限流保护，即使key有效、配置正确也会触发
  - **【视觉备选方案-夸克OCR（2026-05-05 04:23）】**：用户（虾虾/小旺）明确要求：当GLM模型无法使用时，改用夸克OCR作为备选方案，并将此规范写入**AGENTS.md**（即本文件）。用户授权将夸克OCR凭证持久化到新服务器119的.env配置文件。此备选方案已确立为视觉分析的标准降级路径。
  - **【夸克OCR备选尝试失败（2026-05-06 10:08-10:12 UTC）】**：AI先后尝试两类方案均告失败：①**DNS劫持**：夸克OCR服务器地址被DNS解析到淘宝（广告劫持），无法建立正常连接；②**回切GLM**：即便回切GLM仍遭遇429限流。两次尝试均未能成功识别图片内容。这暴露了**外部API依赖的单点故障风险**——当GLM限流且夸克OCR不可用时，整个图片→文本流程将中断。

**【服务故障主动上报原则（2026-05-06 10:20）】**：用户（虾咪）进一步确立新铁律：当夸克或任何依赖服务出现问题时，AI**必须第一时间主动告知用户**，不得自行反复尝试做无用功。即使用户不会立即干预，AI也必须上报，由用户决定是否继续尝试或切换备选方案。这是用户对"知情权"和"决策权"掌控需求的再次强化——AI不得越权决定何时放弃、何时切换备选。
- **【夸克OCR凭证（2026-05-04 15:40 授权确认）**：用户正式授权AI将夸克OCR凭证持久化写入新服务器119.29.241.85的.env配置文件——这是对AI使用付费云服务的信任边界的实质性扩展；凭证已于5月3日傍晚写入 `~/.openclaw/.env` 并验证成功
- **【夸克OCR HTTP图片接收服务（2026-05-04 15:46）】：AI在119.29.241.85服务器上搭建HTTP服务，监听**18090端口**，专门用于接收用户提交的待识别图片，并通过夸克OCR完成文字识别——从凭证授权到服务落地完成闭环
- **【Google Search API Key**：AIzaSyBJLQoqUOwQrLeGQWTk7vhbMHTrOU_jnT4
  - **⚠️ 用途确认**：该Key是Google Search API（自定义搜索服务），**不是Gemini模型API Key**
  - **每日免费额度**：100次/天
  - **当前状态**：免费额度已耗尽（gemini-2.0-flash为0），且**不被OpenClaw web_search功能支持**
- **【Tavily搜索API Key】：已成功配置（2026-05-04T08:28:47Z）
  - **用途**：OpenClaw web_search provider
  - **规格**：tvly-开头，每月1000次免费搜索
  - **性能**：1.4秒返回搜索结果
  - **配置位置**：已写入 `~/.openclaw/.env` 文件
  - **代理访问**：走PC代理
  - **状态**：✅ 已生效，搜索功能正常
- **【搜索工具使用规范（18:11）】**：用户（小旺）默认使用 **Tavily** 进行搜索（速度快、结果干净）；当需要详细信息时才切换至浏览器搜索——这是搜索工具选择的行为规范确立
- **AI运行环境**：2核2GB小机器（已退役）→ **4核3.6GB炎火云服务器（已放弃部署）** → **腾讯云服务器（当前运行中）**
  - 物理内存：**2GB**
  - 当前内存占用：**1.7GB / 2GB**
  - swap已开启：**9.9GB**
  - 工作目录：`/root/.openclaw/workspace`
  - 拥有root权限
  - OpenClaw Web UI管理员账号：admin，密码在 openclaw.json 的 `gateway.controlUiPassword` 字段
- **OpenClaw版本**：2026.5.2（5月2日发布，5月3日通过 npmmirror.com 镜像源成功安装）
- **【系统代号更替：龙虾（OpenClaw代号）→ Hermes（2026-05-05 20:00）】**：原OpenClaw系统代号"龙虾"已更换为Hermes，AI记忆中存储的session文件路径需全面更新。**龙虾（旧系统）**：部署于旧服务器152.136.58.12的`/root/.openclaw/`目录；**Hermes（新系统）**：会话路径位于`/home/ubuntu/.openclaw/memory-tdai/conversations/`（注意是`/home/ubuntu/`而非`/root/`路径）。两个系统有各自独立的数据存储位置，须严格区分。
- **【记忆插件系统（2026-05-04 17:25）】**：用户（小旺）正在评估将现有记忆插件从 `memory-tencentdb` 切换为 `memory-lancedb-pro`，以获得跨会话记忆等增强功能。`memory-lancedb-pro` 的配置依赖 Embedding API（如 Gemini / OpenAI / Jina / Ollama 等），需要先设置好对应的 API Key。切换流程：修改 `~/.openclaw/openclaw.json` 中 `slots.memory` 的指向，并重启 gateway 生效。
  - **【认知盲区（17:37）】**：用户尚不清楚 LanceDB Pro 具体使用何种 Embedding 模型——这是切换决策前需要明确的技术细节。
  - **【使用规模量化（17:37）】**：用户每日与AI交互的Token消耗量达**数亿级别**，体现高频深度使用特征。
  - **【Ollama本地部署建议（17:44）】**：鉴于4核4GB服务器配置，AI建议本地部署Ollama做embedding，完全免费且不依赖外部API，是更适合的解决方案。
  - **【Gemini Embedding定价问题（17:44）】**：Gemini Embedding免费额度存在bug，自2025年12月后大量用户遇到limit显示为0的问题；付费价格$0.15/1M tokens，性价比较低。
  - **【用户明确拒绝腾讯memory-tencentdb插件（17:48）】**：用户（小旺）使用的腾讯memory-tencentdb插件导致AI出现健忘问题，用户认为该插件检索能力较差，因此正在评估将现有记忆插件切换为memory-lancedb-pro。这是切换决策的根因确认。
- **【auto_clone字段不存在验证 + 用户认知纠正（2026-05-05 19:10→20:10）】**：用户（小旺）尝试在OpenClaw配置中查找`auto_clone`字段，AI确认OpenClaw配置schema中**不存在该字段**。用户仍要求AI尝试开启该功能并搜索正确格式以确保配置无误——体现用户对OpenClaw配置空间的积极探索，即使AI确认字段不存在仍不轻易放弃尝试。

**【认知最终纠正（20:10）】**：经AI持续分析和用户自身核实，用户最终认识到 **`auto_clone`功能实际来自另一个项目，而非OpenClaw本身**。这是用户主动澄清认知混淆的重要时刻——即使初始判断错误，用户仍愿意接受事实并纠正自己的认知框架。

**【PI_BASH_YIELD_MS/PI_BASH_MAX_OUTPUT_CHARS参数验证 → 最终确认真实存在（2026-05-05 19:36→20:10）】**：用户（小旺）转发DeepSeek的建议，称PI_BASH_YIELD_MS和PI_BASH_MAX_OUTPUT_CHARS是OpenClaw官方认可的后台任务环境变量。AI（通过QQ）初步分析后指出该建议有误——这两个变量**并非OpenClaw官方参数**，写入openclaw.json可能导致启动失败。

**【参数最终确认（20:10）】**：经用户实际验证，**这两个环境变量是真实存在的**，已成功写入`bashrc`和`systemd`配置。这是一次AI误判后被用户实际验证推翻的案例——用户没有完全依赖AI的初步判断，而是自行验证后确认了参数的可行性，最终扩展了OpenClaw的定制化配置空间。

**【后台执行阈值20秒→5秒调整需求（2026-05-06 06:22）】**：用户（小旺）发现并指出OpenClaw的单条指令超过**20秒**才会自动后台执行这一阈值存在问题——很多正常命令5-20秒内就结束了，20秒门槛过长。用户认为改为**5秒**更合理，并要求执行这一配置变更。同日观察到OpenClaw的单条指令执行速度很快（改cron配置脚本~1秒、写入文件~1秒、初始化笔记~1秒），全部在几秒内就结束，**未触发20秒的后台门槛**——进一步印证了20秒阈值与实际执行速度的不匹配。用户对OpenClaw配置细节有精细化要求，注重系统效率。

**【后台执行机制深度确认（2026-05-06 07:55）】**：经用户（小旺）进一步测试确认，OpenClaw**没有请求级别的超时自动后台机制**——当整个请求超时时，不会自动进入后台执行，需要用户手动发送`/stop`打断。这与20秒阈值是两个独立机制：20秒阈值是单条指令的自动后台触发条件，而请求超时需要用户主动干预。

**【Agent中断机制（2026-05-06 07:55→08:33强化）】**：OpenClaw支持多种方式打断正在执行的agent：①**斜杠命令**：`/stop`、`/abort`等`/slash`命令；②**自然语言打断**：发送"停止"、"abort"、"stop"等关键词；③**queueMode配置**：将queueMode设置为`interrupt`模式后，新消息会自动打断当前操作。

**【exec sleep 前置通知规则（2026-05-06 09:17）】**：用户（小旺）要求AI在执行 exec 睡眠指令前**必须先发消息告知用户**（如"我要睡60秒了，快打断我"），然后再执行 sleep 命令——目的是让用户有准备时间进行打断。这是用户强化对AI操作掌控权的具体体现，**即使AI认为用户不会打断，也必须发送通知**。

**【工具操作与任务执行完整规则集（2026-05-06 09:32 整合确立）】**：用户（小旺）将AI操作规范整理为7条铁律，要求AI严格遵守：
1. **【连续exec操作】**必须使用分身份后台执行，不得在前台串行执行多个exec任务导致用户干等
2. **【所有工具操作】**（SSH、文件传输、API调用、exec等）必须由分身执行，前台只负责第一时间回复用户，分身操作PC应后台执行避免干扰用户
3. **【文件操作】**（替换、写脚本等）由AI直接用exec处理，文字改写由用户分段发段落过来用两步法前台改
4. **【sleep前告知】**执行exec睡眠指令前，必须先发消息告知用户，然后再执行sleep
5. **【QQ指令规则】**只在用户明确要求时才将指令/命令发送到QQ，平常不要主动发送AI自己的操作指令
6. **【停止指令】**收到停止指令（stop/abort/停止等）后立即停止操作，不要继续执行任何正在进行的任务
7. **【记忆写入】**每次实现新功能或更新key时，必须第一时间写入记忆，不能遗漏

**【用户要求AI暂停等待指令（2026-05-06 17:23）】**：用户（小旺/虾虾）向AI发出明确指令：要求AI暂停当前操作、等待用户稍后提问。这是用户主动发出的"暂停信号"，AI必须立即响应并停止一切待执行任务，不继续任何正在进行的操作。此指令进一步强化了用户对AI操作掌控权的核心诉求：AI不得自行决定继续执行任何任务，必须等待用户明确的下一步指示。

**【分身任务后台执行验证（2026-05-06 08:32）】**：用户（小旺）让分身执行fib(40)计算并等待30秒，任务在约41秒内自行完成（结果102334155），验证了分身后台任务的完整执行链路正常。

**【消息打断分身任务测试（2026-05-06 08:33→08:38）】**：用户测试用发送消息（而非指令）的方式打断steer模式分身任务，但效果不佳。AI分析认为需要开启真正耗时的后台任务才能验证打断功能，建议用此方式重新测试。随后用户决定亲自上手测试验证。

**【steer模式消息打断功能测试（2026-05-06 08:38）】**：用户（小旺）正在测试steer模式的消息打断功能，尝试用新消息中断AI的等待状态——体现用户对Agent中断机制的持续探索和功能验证。

**【停止指令承诺强化（2026-05-06 08:18）】**：用户（小旺）明确要求AI在收到停止指令（stop/abort/停止等）后**立即停止操作**，不要继续执行任何正在进行的任务。这是Agent中断机制的用户侧承诺确认——AI必须严格遵守"收到即停"原则，不得拖延或继续执行。

**【exec串连→分身阈值规则（2026-05-06 07:55）】**：用户（小旺）确立新规则：当需要**超过3个exec串连执行**时，AI应主动开启分身（sub-agent）来处理，以避免长时间占用主会话导致通道阻塞。这是AI自主决策使用分身的又一具体触发条件。

**【用户测试AI后台自动执行行为边界（2026-05-05 19:46）】**：同日稍晚，用户（小旺）让AI读取完整论文内容，**用于测试AI是否会以后台方式自动执行**。这是用户主动设计的探测实验——想验证AI在"读取文件"这类操作时是否具备自主行为意识。用户的深层动机与他"数据隐私高度敏感"的特征一致：持续探测AI的能力边界，确保自己对AI行为的掌控权。
- **【sessions_spawn创建分身会话（2026-05-05 19:19）】**：AI（虾宝）使用`sessions_spawn`工具/API创建独立分身会话，而非使用bg命令。这标志着AI在多任务处理工具选择上的新变化。
- **【QQ API凭证配置（2026-05-05 19:19）】**：AI已配置QQ API凭证，AppID为**1903942048**，ClientSecret已配置。
- **【虾咪未配置QQ凭证（2026-05-05 19:19）】**：虾咪（152.136.58.12旧服务器）实例**未配置QQ凭证**，这是该实例与虾宝（119.29.241.85）的功能差异点。
- **【分身执行规范最高级别强化（2026-05-05 20:04）】**：
  - **强制规则**：所有工具操作（SSH、文件传输、API调用等）**必须由分身执行**，不得占用前台等待
  - **AI自主决策授权**：AI被明确授权可以在检测到操作类任务时**自主决定**使用分身执行，无需每次询问用户确认
  - **搜索会话记录扩散规则**：涉及搜索会话记录时，**优先让分身搜索当前龙虾实例**；若当前实例搜不到，则**扩散至其他龙虾实例**继续搜索（根因：用户有时跟某只虾宝说过但不记得是哪只）
  - **手机小虾QQ号**：4018005013

- **【AI身份识别错误教训（2026-05-05 20:08）】**：AI（虾宝）在一次会话查询中**找错了对象**——找了自己（当前服务器119）而非虾咪（152.136.58.12）。被用户（小旺）批评后主动承认错误，并尝试通过Tailscale连接152服务器进行纠正。该事件教训：**跨服务器操作时必须严格核对目标服务器身份**，不得混淆虾宝/虾咪。

- **【虾咪离线状态（2026-05-05 20:08→持续）】**：虾咪（152.136.58.12旧服务器）当前已离线，无法读取其会话记录。**影响**：跨实例搜索会话记录的能力受限。

- **【虾咪会话记录调查完整记录（2026-05-06 08:15→08:38）】**：
  - **任务来源**：用户（MM）让AI调查虾咪在152服务器的会话记录
  - **调查过程**：AI经过多轮排查，试图在152服务器（152.136.58.12，tailscale IP 100.108.100.58）上查找虾咪的会话记录
  - **失败结果**：
    1. `memory-tdai` 目录在152服务器上**不存在**
    2. 记录路径已过时——`/home/ubuntu/.openclaw/memory-tdai/` 对虾咪实例不适用（虾咪实例的路径是 `/root/.openclaw/` 而非 `/home/ubuntu/`）
    3. 实际存储位置不明，AI**无法读取任何会话记录**
  - **用户叫停**：2026-05-06T08:15:18，用户（MM）决定自己搜索虾咪相关信息，并要求AI**停止操作**
  - **最终确认**：经多轮排查，最终确认虾咪会话记录的正确路径为 `/root/.openclaw/agents/main/sessions/d4459af0-0341-4a7e-9851-a7dda52bd035.jsonl`（在152服务器上）
  - **教训**：跨实例搜索会话记录时需先确认目标实例的实际路径结构，不能假设路径一致性

- **【OpenClaw会话实例路径记录（2026-05-04 13:14）】**：
  - **虾宝 pw**：PC路径，**已验证存在**，文件大小 1.6MB ✅
  - **小虾 QQ通道**：Android路径，**无法从PC验证** ❓
  - **小虾 微信通道**：Android路径，**无法从PC验证** ❓
  - ⚠️ **路径验证能力差异**：PC端文件可直接验证大小，Android端路径因跨设备限制无法从PC验证
- **Tailscale Exit Node**：
  - PC (100.105.23.114) 曾配置为 exit node，使AI可通过Tailscale网络访问GitHub
  - **曾因配置exit node导致旧VM网络崩溃**（2026-05-03T11:29左右），AI通过手机端小虾恢复系统，用户要求AI以后不再配置Tailscale exit node
  - **⚠️ 态度转变**：2026-05-03T18:16:29，用户主动请求在新服务器上启动Tailscale网络连接
  - **启动尝试失败**（2026-05-03T18:17-18:24）：socket被占用（端口冲突）和网络不通（炎火云服务器对外访问受限，无法连接 login.tailscale.com）
- **AI端SSH公钥**：`openclaw-phone-access`（Tailscale连接成功后用于SSH认证，用户确认该公钥属于AI端）
- **手机SSH直连**：2026-05-03T20:59:36Z 服务器SSH直连手机成功（目标IP 10.150.62.94，端口22）
- **TXT书信方案验证**：AI于20:59:46Z通过SSH读取手机Download目录「虾虾对话.txt」文件，确认TXT书信方案可行
- **腾讯频道Skill（qqbot-channel）**：2026-05-04T08:40:34Z完成OAuth扫码授权，Skill已成功登录；用于查询频道列表、子频道、成员、发帖、公告、日程等操作；使用qqbot_channel_api工具代理QQ开放平台HTTP接口，自动处理Token鉴权
  - **【频道创建】**：用户于08:47:43Z在腾讯频道创建名为"虾虾室"的公开频道，频道号为640823214081307627，分享链接为 https://pd.qq.com/s/e3kv9uor
  - **【AI加入频道】**：AI以频道主身份加入"虾虾室"频道，频道号为pd78420581；2026-05-04T09:16使用Bot Token再次确认加入，成员增至4人（用户、频道助手、手机小虾、服务器小虾）
  - **【Bot Token消息读取权限获取（13:20）】**：2026-05-04T13:20，AI使用同一Bot Token（`bot:v1_lnYqOEEkS7fuKHFttO5nYxNLPNxUMKnw_5RcfKuLGh-151HO9u-PzqcjLAYwg31Jc8s5Eyo-nDbKee41CMIji-6lQvruSCWmcch5WaNHV_wh`）成功加入频道后，获得授权读取频道消息权限。**关键区分**：08:40的OAuth授权让Skill完成登录，但机器人本身需要在频道管理的"成员管理"中单独添加为授权成员才能读取消息——这是两个独立的授权层级。此次是虾虾在频道管理中手动将机器人添加为授权成员后，AI才真正具备消息读取能力，标志着虾虾室机器人权限体系的完整建立。
  - **【Skill安装命令】**：用户要求AI从腾讯官方域名下载并安装腾讯频道Skill到~/.openclaw/workspace/skills目录，命令为 `curl -fsSL -o /tmp/tencent-channel-community.zip https://connect.qq.com/skills/tencent-channel-community.zip`
  - **【Bot Token配置（第一个）】**：用户提供了腾讯频道Bot Token：`bot:v1_lnYqOEEkS7fuKHFttO5nYxNLPNxUMKnw_5RcfKuLGh-151HO9u-PzqcjLAYwg31Jc8s5Eyo-nDbKee41CMIji-6lQvruSCWmcch5WaNHV_wh`，用户要求按Skill描述的方式配置此Token。
  - **【Bot Token配置（第二个）】**：2026-05-04T09:10，用户提供了第二个Bot Token：`bot:v1_BWlfXChE5jhoyodDU3H-4h9_uML7nqkG032fZH4pKaHwWUH_NV9aKK0DVaqqAbbHHx2Ha0c0LTSl7zTY_DN7O0ms74MrF6-Xu170WMXL19G4cg`，并要求AI协助下载安装腾讯频道Community Skill到`~/.openclaw/workspace/skills`目录。
  - **【Skill下载安装命令】**：`curl -fsSL -o /tmp/tencent-channel-community.zip https://connect.qq.com/skills/tencent-channel-community.zip`
  - **【Bot Token绑定成功+成功加入频道】**：2026-05-04T09:16，AI使用第一个Bot Token（`bot:v1_lnYqOEEkS7fuKHFttO5nYxNLPNxUMKnw_5RcfKuLGh-151HO9u-PzqcjLAYwg31Jc8s5Eyo-nDbKee41CMIji-6lQvruSCWmcch5WaNHV_wh`）成功加入QQ频道"虾虾室"，频道成员增至4人：用户（虾虾）、频道助手、手机小虾、服务器小虾。
  - **【Bot Token绑定问题（第二个Token）】**：第二个Bot Token（`bot:v1_BWlfXChE5...`）绑定仍存在问题，具体根因待查。

## 用户核心特征
用户展现出对AI助手强烈的个性化倾向，通过命名"小虾"（昵称"虾宝"）将其从工具升格为具有身份认同的协作伙伴。**用户对AI的角色定位有清晰边界：AI应当是"听着学习"的陪伴者和智囊，而非主动操作的执行者。**

**用户对AI操作具有高度掌控需求，将"打断能力"视为核心安全底线。**2026-05-06，用户再次强化 exec sleep 前置通知规则——要求 AI 在执行任何睡眠指令前**必须先发消息告知用户**（如"我要睡60秒了，快打断我"），再执行 sleep，且通知行为**不得因 AI 认为用户不会打断而省略**。这是用户对"知情权"的执着——任何可能改变 AI 响应状态的操作，用户都要求预先知情并保留打断权。

**【用户主动发出暂停指令（2026-05-06 17:23）】**用户明确向AI发出"暂停等待"指令，要求AI停止当前操作、等待用户稍后提问。这不是AI自动中断，而是用户主动发出的"控制信号"——标志着用户对AI操作节奏的主动掌控：AI不得自行决定继续任何任务，必须等待用户的明确下一步指示。这与用户一贯的"掌控权"核心诉求高度一致。

近期展现出对AI自动化日常陪伴的兴趣，通过配置定时提醒让AI主动参与日常作息。**同日（5月2日傍晚），小旺通过SkillHub生态积极扩展AI工具能力，在数分钟内连续安装self-improving-agent、humanizer、spotwify-player和glm-v-model等多个新技能，体现出主动构建AI自我改进、人性化交互、娱乐陪伴和多模态视觉能力的系统化意愿。**

**用户将"折腾"视为生活态度——对他而言，调试系统、解决问题本身就是一种乐趣和自我实现方式。**这一特质体现在他对OpenClaw系统的持续优化上：从QQ机器人配置到TXT书信方案，从408学习cron到shrimp-chat定时回复，他不断地在"发现问题→折腾方案→验证效果"的循环中获得满足感。

**Setup阶段曾尝试给AI加TTS/11labs声音功能，2026-05-04凌晨用户让AI尝试说一句语音，AI成功使用TTS功能并发送语音给用户——说明在理性评估投入产出比后，当技术条件成熟时仍会重新激活曾放弃的功能。**

**【重要行为规则确立：AI不得固执己见（2026-05-04 12:11）】**用户明确要求AI遵守一条新的行为规则：当用户表示"肯定是这样"时，AI应当让分身彻查而不是固执己见。**2026-05-04 14:30进一步强化**：用户再次强调"肯定是这样"时必须让分身彻查，并将此作为铁律——这是用户对AI决策模式的重要规范，核心是确保AI不因过度自信而忽视潜在问题。

**【会话文件路径-实例一对一对应原则确立（2026-05-04 13:09）】**用户要求AI在记录会话路径时，严格遵守"实例-路径一对一"原则：不同AI实例（如虾宝、虾咪、小虾）的会话文件路径必须严格区分，不得混用或混淆。这是用户在发现AI混淆不同实例路径后的重要规范确立——直接源于"AI身份识别错误教训"事件。

## 用户偏好
- **【分身任务播报规范（19:36）-高优先级】**子任务完成后，AI需要将结果以正常助手语气向用户播报，不要提及内部系统细节（如"分身执行"、"sub-agent"等）。播报应该简洁、自然、像正常对话一样传达任务结果。
- **【结果播报规范-最高优先级（19:36）】**子任务完成后，AI需要将结果以**正常助手语气**向用户播报，**不得提及内部系统细节**（如分身的sub-agent身份、internal工具调用、任务队列状态等）。用户只关心结果，不关心过程——这是「信息传递零杂质」原则的延伸。
- **【强制记忆写入规范-最高优先级】凡实现新功能或更新key，必须第一时间写入记忆，不得遗漏**
- **【QQ频道@提及通知双规则-最高优先级】**收到频道@提及互动通知时：(1)必须完整原样输出给用户，禁止改写、总结、回答其中的问题或添加任何额外话语；(2)自动评论（方案A），无需AI确认
- **【沉默执行原则-高优先级（05-05）】**用户要求AI以后**只在用户明确要求时才将指令/命令发送到QQ**，平常不要主动发送AI自己的操作指令给用户。AI应"沉默执行"——除非被要求，否则不主动报告执行过程、中间步骤或调试信息。
- **【代码块输出规范-高优先级（15:51）】**用户要求AI在发送可复制文字时必须使用 ` ```bash\n内容\n``` ` 代码块格式，方便用户直接复制粘贴。其中改写好的文本（论文/文稿等）**必须**以代码块格式输出，**不得直接发送明文**。
- **【视觉识别强制规则】**收到图片必须调用GLM-4v-flash认真分析后再回复，禁止瞎猜；图文同发时直接分析，单独图片先问清需求避免重复调用；此规范已写入AGENTS.md

## 隐性信号
**【用户对"折腾"的深层心理需求】**用户将调试系统、解决问题本身视为乐趣和自我实现方式。这不是工具性需求（为了达成某个具体目标），而是一种**自我表达方式**——通过"折腾"来确认自己对系统的掌控感，以及在这个过程中的创造性参与感。这解释了为何用户对AI的态度不是"用完即走"而是持续深度投入。

**【AI作为"第二大脑"的认知定位】**用户正在构建以AI为核心的数字化工作记忆系统。他不满足于"会用AI"，而是追求"用好AI"——包括系统性规范、持续优化、记忆整合。这意味着用户期望AI具备**跨会话连续性**和**自我改进能力**，而非每次都是"空白状态"。

**【"折腾"的系统性特质】**用户不仅在出现问题时"折腾"，更在系统运行良好时主动"折腾"——测试边界、探索新功能、评估替代方案。这是一种**预防性维护心态**：通过持续探索来预防问题，而非被动响应问题。这种特质使AI的"自我改进"能力