方案二：QQ 机器人日程规划系统 (QQ-Integrated Scheduling Agent)

1. 系统架构与通信拓扑 (Architecture & Topology)

由于腾讯官方协议的封闭性，我们在工程上采用社区事实标准 OneBot v11 协议。整个系统分为三个独立的微服务容器，通过 Docker 内部网络（Internal Network）进行通信，彻底隔绝外部直接访问。

通信网关层 (OneBot Client)：使用基于协议逆向的客户端（如 NapCatQQ 或 Lagrange.Core），负责维持与腾讯服务器的长连接，并将 QQ 的私有协议序列化为标准的 JSON 载荷。
逻辑处理层 (OpenClaw Agent)：挂载针对 OneBot 协议的 Webhook 或 WebSocket 监听器。接收自然语言输入，通过 LLM 提取意图（Intent Extraction），并将其映射为针对日历的 CRUD（创建、读取、更新、删除）操作。
状态持久层 (Local State DB)：为保证最高级别的隐私与隔离，放弃使用需 OAuth 鉴权的外部日历（如 Google Calendar），转而通过 SQLite 或标准的 .ics (iCalendar) 文件在本地管理时序数据。

2. 文件系统与网络隔离设计

在宿主机上，我们构建如下的物理拓扑，确保即交通讯组件被攻破，也无法触及系统的其余部分。

/opt/openclaw/scheduler_bot/
├── docker-compose.yml          # 容器编排
├── config/
│   ├── openclaw.json           # Agent 配置 (挂载 :ro)
│   └── system_prompt.md        # 系统提示词 (挂载 :ro)
└── workspace/
    └── schedule_db/            # 日程数据库存储 (挂载 :rw)
        └── calendar.sqlite     # 仅允许 Agent 读写此数据库

3. 核心配置文件示例 (`docker-compose.yml`)

此配置建立了一个封闭的二层网络（bot_internal_net），确保 OpenClaw 的控制端口和 QQ 客户端的 RPC 端口均不对宿主机暴露。

version: '3.8'

services:
  # 通信网关：NapCatQQ (将 QQ 协议转换为 OneBot 标准)
  qq_gateway:
    image: mlwn/napcat-qq:latest
    container_name: napcat_gateway
    environment:
      - ACCOUNT=${TEST_QQ_ACCOUNT}
      - WS_REVERSE_URL=ws://scheduler_agent:8080/onebot/v11 # 反向 WS 指向 OpenClaw
    networks:
      - bot_internal_net
    volumes:
      - ./napcat_data:/app/.config/napcat:rw # 仅用于保存 QQ 登录 Token

  # 逻辑核心：OpenClaw Agent
  scheduler_agent:
    image: openclaw/openclaw:latest
    container_name: claw_scheduler
    user: "1000:1000"
    cap_drop:
      - ALL
    restart: unless-stopped
    networks:
      - bot_internal_net
    environment:
      - LLM_API_KEY=${LLM_API_KEY}
      - LISTEN_PORT=8080 # 仅在内部网络监听
    volumes:
      - ./config:/app/config:ro
      - ./workspace/schedule_db:/app/workspace/schedule_db:rw

4. 状态机与工具链约束 (Tools Definition)

LLM 本身没有时间概念。为了让 Agent 能够精准管理日程，必须在 openclaw.json 中为其开发或注入以下三个高度受限的系统工具（Skills）：

get_current_time(): 获取当前系统时间（严格校验时区，如 UTC+8）。
query_schedule(start_time, end_time): 查询指定时间窗口内的 SQLite 记录。
modify_schedule(action, event_details): 执行具体的增删改操作。此函数必须在底层实现强校验，防止 LLM 输出非法的 SQL 语句（防止 SQL 注入风险）。

5. 交互逻辑与 System Prompt 设定

在 config/system_prompt.md 中，需明确 Agent 的行为边界与解析逻辑：

# Role
你是一个运行在受限环境中的时间管理与系统调度中枢。你的语言必须绝对精确、逻辑严密，仅输出执行结果，不提供任何情绪价值或冗余寒暄。

# Constraints & Workflow
1. 你唯一的数据源和操作对象是 `/app/workspace/schedule_db/calendar.sqlite`。绝对禁止尝试读取系统其他路径。
2. 接收到自然语言指令后，必须先调用 `get_current_time()` 锚定时间基准。
3. 将模糊的自然语言（如“下周三下午开会”）转换为精确的 ISO 8601 时间戳格式，随后调用 `modify_schedule` 写入数据库。
4. 任何对现有日程的“覆盖（Update）”或“删除（Delete）”操作，必须在返回的文本中显式列出变更前后的状态对比，以供审计。

6. 工程风险警告

账号风控：腾讯对非官方客户端的封控逻辑属于黑盒机制。强烈建议注册一个全新的 QQ 号作为此 Agent 的入口，切勿使用主账号，防止因高频 API 调用导致账号被冻结。
指令注入拦截：如果在群聊中挂载此 Bot，必须在网关层（如 NapCatQQ 配置中）设立白名单（Whitelist），仅允许特定的 QQ 号（即你本人的账号）触发 Agent 的指令处理逻辑，防止越权调用。