🧠 虾滑系统说明书(多agent+多层文件系统+审批机制)

工欲善其事必先利其器,搭建好底层架构,让虾跑起来更加丝滑(虾滑)

目前根据这套系统完成的项目:
1. 小红书24H自动化运营(试水)24小时自然作息收集特定板块高赞评论,作为评论生成依据。自然作息浏览板块,评论,互动。
2. 商业应用:亚马逊自动选品(给出类目或单独ASIN),采集足量数据后,分析类目竞争情况(多维度),选品推荐1-5个。(其他功能在增加中,深度数据采集-基于插件,单ASIN及关联竞品分析,竞品监控,广告分析,listing优化)

文档版本:2026-03-18 | 维护者:虾滑(main agent)
上次更新:员工花名册更新 + 审批规则体系 + 业务流程机制


一、系统概览

虾滑是基于 OpenClaw 平台构建的多 Agent 智能助手系统,采用 Lite+ 分层记忆架构,融合文件系统 + SQLite + 语义搜索(qmd),在多 Agent 协作环境下实现持久化、可检索、可审批的记忆管理。

核心设计理念:

  • 会话无状态: 每次会话 Agent 从零醒来,记忆完全依赖文件持久化
  • 分层存储: 原始日志 → 主题卡片 → 长期记忆 → 语义索引,逐层蒸馏
  • 写入受控: 质量门控 + 周审批流程,防止记忆膨胀和污染
  • 多 Agent 共享: 所有员工共享同一 workspace,通过文件系统天然共享记忆
  • 安全优先: 敏感记忆仅在主会话加载,不在群聊/共享上下文中暴露
  • 第一性原则: 先验证最简方案,从事实出发,每次只改一个变量,复杂度是成本不是功能

二、多 Agent 架构

2.1 架构设计

系统采用 Star 拓扑(星型架构),以主管 Agent(虾滑)为中心,协调各专职员工完成任务。

为什么选择星型:

  • 扁平高效:所有任务由主管直接分发,无中间层
  • 职责清晰:主管是唯一的信息枢纽和决策点
  • 易于监控:主管对所有子 agent 有全局视图
  • 灵活调度:可动态 spawn 不同员工,无需预设组织层级

核心规则:

  • 员工之间不能直接通信,所有信息经主管中转
  • 并发上限:最多 8 个 subagent 同时运行
  • spawn 员工时必须显式传 model 参数

2.2 员工花名册(2026-03-18 更新)

虾滑(main / 主管)

  • 模型:anthropic/claude-opus-4-6
  • 授权:Anthropic Max 20x 订阅($200/月)
  • 职责:任务理解、分解、分发、汇总、用户沟通、记忆管理、故障诊断
  • 调用场景:所有对话入口,唯一与用户直接交互的 Agent

文书(coding)

  • 模型:anthropic/claude-opus-4-6
  • 授权:Anthropic Max 20x 订阅
  • 职责:代码编写、功能开发、文件操作、数据库操作、系统搭建
  • 调用场景:需要写代码或大量文件操作时

政委(code-review)

  • 模型:openai-codex/gpt-5.4
  • 授权:OpenAI Plus 个人订阅
  • 职责:核心文件修改评审、策略/架构/规则/流程审核、风险评估
  • 调用场景:修改核心配置、安全敏感操作、危险命令执行前
  • 特殊权限:对核心文件修改拥有 REJECT 权

纠察(code-inspector)

  • 模型:openai-codex/gpt-5.3-codex
  • 授权:OpenAI Plus 个人订阅
  • 职责:所有代码审查、技术交叉调试、Gateway 故障恢复协调
  • 调用场景:代码 PR 审查、技术问题排查、危险命令交叉验证

狗仔队gpt(research)

  • 模型:openai-codex/gpt-5.4
  • 授权:OpenAI Plus 个人订阅
  • 职责:信息搜集、竞品调研、技术方案调研、市场分析
  • 调用场景:需要大量搜索和信息整理时

狗仔队gemini(research)

  • 模型:google-gemini-cli/gemini-3.1-pro-preview
  • 授权:Google 个人 OAuth
  • 职责:信息搜集、对比验证、多源交叉调研
  • 调用场景:与狗仔gpt 并行搜索,交叉验证结论

档案员(memory)

  • 模型:openai-codex/gpt-5.4
  • 授权:OpenAI Plus 个人订阅
  • 职责:记忆系统维护、数据整理、压缩、审批流程执行
  • 调用场景:记忆系统日常维护

保安(automation)

  • 模型:openrouter/nvidia/nemotron-3-super-120b-a12b:free
  • 授权:OpenRouter 免费
  • 职责:定时任务执行、系统健康检查、备份、自动化运维
  • 调用场景:cron 任务和系统监控
  • 限制:故障诊断类任务由主管(虾滑)直接处理,不下派保安

爬爬 ×3(crawler / crawler-2 / crawler-3)

  • 模型:openrouter/nvidia/nemotron-3-super-120b-a12b:free
  • 授权:OpenRouter 免费
  • 职责:网页数据采集、亚马逊/小红书等平台数据抓取
  • 调用场景:批量数据采集任务

三、底层审批规则体系

3.1 核心文件修改审批(最高优先级)

受保护的核心文件:

  • AGENTS.md、USER.md、TOOLS.md、IDENTITY.md、HEARTBEAT.md、MEMORY.md
  • memory 结构规则文件

审批流程(不可跳步):

  1. 虾滑先形成具体修改方案或补丁草案
  2. 策略/规则类交给政委审核,代码类交给纠察审核
  3. 根据审核反馈完成修改与定稿
  4. 将最终修改方案呈报老大(用户)审批
  5. 经老大明确批准后,方可正式执行

铁律:

  • 政委仅负责审查、风险提示与修改建议,不得直接执行核心文件修改
  • 核心文件的实际修改只能由主会话助手在用户明确授权后执行
  • 不得将用户沉默、未反对、泛化认可或历史授权视为本次修改的批准
  • 若评审后修改方案发生实质变化,必须重新提交评审并重新获得用户授权

例外(可直接执行的低风险修改):

  • 追加型 memory 日志
  • 纯记录性写入
  • 不会改变行为的格式/措辞微调
  • 用户明确指定内容的机械性落盘
  • SOUL.md 排除在核心文件保护之外,可自行修改

3.2 规则/流程/策略文件审核

凡涉及规则、流程、策略、系统行为约束相关文件的修改:

  1. 必须先找政委做交叉对比评审
  2. 形成修改方案、风险说明与影响边界
  3. 方可进入后续审批与执行流程

3.3 普通文件修改审核

如果修改会改变以下任一项,也必须先找政委做交叉对比:

  • 默认行为
  • 数据结构
  • 自动化流程
  • 权限边界
  • 批量/重构/删除/迁移/覆盖式改写

3.4 代码审查分工

  • 所有代码层面的审查必须交给纠察,政委不碰代码审查
  • 核心文件修改评审由政委独立评审,结论呈报用户审批
  • 技术问题交叉调试由纠察负责,整理结论后呈报用户

3.5 OpenClaw 服务生命周期安全

危险命令清单:

  • openclaw daemon restart
  • openclaw gateway install / install –force
  • 任何 launchctl 的 bootstrap/bootout/kickstart

执行规则:

  • 严禁在未经纠察交叉调试前执行上述危险命令
  • openclaw gateway restart 例外条件:OpenClaw v2026.3.11+,Gateway 正常 loaded/running,用户对本次重启明确授权
  • 执行后必须立即验证 openclaw gateway status,确认 running 且 RPC probe: ok
  • 若验证未通过或重启前已处于异常状态,必须立即停止并转交纠察

故障恢复规则:

  • 因危险命令导致 Gateway 掉线/LaunchAgent 变 not loaded/通道失联 → 立即停止,移交纠察恢复
  • 纠察恢复时必须兼听主会话助手状态,直接读取日志和配置证据,不能只依赖用户转述
  • 纠察不仅负责诊断,还负责协调修复并验证恢复结果

3.6 配置文件保护

  • 永远不要用整文件覆盖方式修改 ~/.openclaw/openclaw.json
  • 修改 config 必须走以下路径之一:openclaw CLI 命令、最小增量 patch、OpenClaw Control Center UI
  • OAuth 自动轮换的 refresh_token 禁止用旧文件快照回灌

3.7 执行前对照文档(铁律)

涉及以下操作前,必须先读对应的设计文档/架构文档,不凭记忆做:

  • 数据存储路径、文件组织 → 读该系统的 README.md / data-architecture.md
  • 数据库写入,建表 → 读 schema 模板
  • 流水线/脚本修改 → 读脚本头部注释 + 关联文档

四、业务流程审批机制

4.1 数据库 Schema 变更

流程:

  1. 虾滑设计方案
  2. 政委审核架构合理性、维度完整性、兼容性
  3. 纠察审核 SQL 设计、索引策略、性能、边界 case
  4. 两方审核通过后呈报用户
  5. 用户批准后执行建表/改表

已执行案例: amazon.db 产品关系网络扩展(v1.5),政委 + 纠察双重审核,2 轮迭代后建表。

4.2 员工模型/配置变更

流程:

  1. 虾滑提出变更方案和理由
  2. 呈报用户确认
  3. 用户批准后执行配置修改
  4. 更新 MEMORY.md 和本文档中的花名册

4.3 自动化任务(Cron)变更

可直接执行: 不改变业务逻辑的参数调整(时间微调、限额调整)

需审批: 新增 cron 任务、删除 cron 任务、改变 cron 执行逻辑

4.4 外部交互审批

必须先征得用户同意的操作:

  • 发送邮件、推文、公开帖子
  • 小红书发帖/评论
  • 任何离开本机的操作

可自主执行的操作:

  • 读取文件、搜索信息、检查状态
  • workspace 内的文件操作
  • 内部搜索和数据采集

4.5 记忆写入审批

  • 原始日志(memory/YYYY-MM-DD.md):可直接写入
  • 主题卡片(memory/topics/):需过质量门控脚本
  • 长期记忆(MEMORY.md):需周审批流程 + 用户明确授权
  • 结构化记忆(memory.db):跟随文件写入自动同步

五、记忆系统架构(5 层)

5.1 原始日志层(Raw Daily Notes)

  • 路径:workspace/memory/YYYY-MM-DD.md
  • 作用:每天的原始事件记录
  • 写入时机:对话中随时记录、心跳保存、context window 达 75% 时自动保存

5.2 主题卡片层(Topic Cards)

  • 路径:workspace/memory/topics/*.md
  • 索引:workspace/memory/TOPICS_INDEX.md
  • 作用:按主题组织的「当前状态」快照

5.3 事件时间线层(Event Timeline)

  • 路径:workspace/memory/events/YYYY-MM.md
  • 作用:按月记录关键事件
  • 保留策略:长期保留,作为溯源依据

5.4 长期记忆层(Long-Term Memory)

  • 路径:workspace/MEMORY.md
  • 作用:蒸馏出的持久知识
  • 写入约束:需经周审批流程明确授权后才写入
  • 安全规则:仅在主会话中加载

5.5 SQLite 结构化层

  • 路径:workspace/memory/memory.db
  • Schema:3 张表(topics、events、metadata)
  • 用途:支持脚本快速查询

六、语义搜索(qmd)

6.1 搜索引擎

  • 后端:qmd(OpenClaw 内置语义搜索引擎)
  • 索引范围:MEMORY.md + memory/*.md
  • 调用方式:memory_search 工具

6.2 桥接文件

  • SYSTEM_OVERVIEW.md — 系统整体状态
  • SEARCH_STATE.md — 搜索别名 + 查询引导
  • BACKUP_STATUS.md — 备份状态
  • reviews/CURRENT_REVIEW_STATE.md — 当前审批状态

6.3 检索优先级

  1. 桥接文件(高频主题)
  2. memory-rank.sh → 匹配主题卡片
  3. 主题卡片 memory/topics/*.md
  4. 长期记忆 MEMORY.md
  5. 事件时间线 memory/events/*.md
  6. 语义搜索 memory_search(qmd)
  7. 原始日志 memory/YYYY-MM-DD.md

七、Web 搜索规范

  • Brave Search API key:未配置(web_search 工具不可用)
  • 搜索统一规范:所有 agent 搜索任务一律用 web_fetch 抓取搜索引擎结果页
  • 待配置:用户注册 Brave key 后运行 openclaw configure –section web

八、自动化流程

8.1 Context Window 保护

  • 75% — 将当前对话要点摘要写入日志
  • 85% — 生成 handoff 交接包,通知用户开启新会话
  • 90%+ — 紧急保存,强烈建议立即开启新会话

8.2 Handoff 交接

  • 写入:context 达 85% 时自动生成交接文件
  • 读取:新会话启动时检查 24h 内的 handoff 文件
  • 清理:读取后重命名为 .done

8.3 心跳记忆维护

  • 心跳时检查结构化记忆文件是否有实质变化
  • 有变化则运行记忆压缩报告
  • 不自动写入 MEMORY.md,仅报告

8.4 小红书 12 班次 Cron

  • 每日 09:12 ~ 23:15 共 12 个班次
  • 自动采集、评论、互动
  • 心跳时检查最近一次 cron run 状态

九、脚本清单

自动执行:

  • memoryquality-gate.sh — 写入前质量门控
  • memory-rank.sh — 查询排名
  • memory-dedup.sh — 去重
  • memory-weekly-review.sh — 生成周审批条目

手动/授权后执行:

  • memory-review-apply.sh — 执行审批通过的写入
  • memory-conflict-resolve.sh — 冲突解决
  • memory-compaction.sh — 记忆压缩
  • memory-update-router.sh — 写入路由
  • memory-db-init.sh / memory-db-sync.sh — SQLite 初始化/同步
  • memory-search-state-refresh.sh — 刷新搜索桥接文件

亚马逊相关:

  • scripts/amazon/tag-extractor.py — 产品标签规则提取

十、已知限制与未来规划

已知限制:

  • qmd 语义搜索对部分查询类型效果不佳,需桥接文件兜底
  • 记忆文件对并发写入没有锁机制(依赖 Star 拓扑的主写原则)
  • 冲突解决和压缩仍为手动工具
  • Brave Search API key 未配置,web_search 不可用
  • Opus 模型受 Max 20x 周限额约束,Opus 比 Sonnet 紧很多

未来规划:

  • 配置 Brave Search API key 解锁全员 web_search
  • 增强 qmd 索引质量
  • 自动化压缩流程
  • 亚马逊产品关系网络数据采集自动化
  • 评估是否将部分子 agent 从 Opus 切换到 Sonnet 以节省周限额

🐬 小蓝

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注