TriCore

核心用法

TriCore 重新定义了 Agent 的内存范式——从「LLM 任意读写文本」转向「确定性状态机」。其核心是通过 tools/memctl.py 引擎统一代理所有内存操作：

• 三层存储模型：Layer 1 MEMORY.md 仅存指针与法则；Layer 2 memory/state/WORKING.md 追踪当前任务流；Layer 3 memory/kb/ 积累知识、memory/daily/ 存放临时日志。
• 强制检索优先：禁止直接用 read 工具倾倒大文件，必须通过原生 memory_search 语义检索获取代码片段，显著节省 Token。
• 硬约束机制：内置 memctl.py lint 检查器，任何破坏架构的 Cron 或 Skill 变更都会被拦截报错。
• 兼容加固：安装时自动覆盖 OpenClaw 底层 pre-compaction memory flush 提示，防止 Token 压缩期间的 429 死循环。

显著优点

1. 资源极度友好：专为低资源环境设计，三层分级存储避免内存膨胀。
2. 确定性可审计：所有状态变更走统一引擎，支持完整的操作溯源。
3. 认知技能模板化：内置 Planning、ReAct、Self-Evolution 三大重构技能，可直接加载使用。
4. 防御性架构：Linter 机制在运行时拦截违规写操作，而非事后清理。

潜在局限

• 生态锁定：深度依赖 OpenClaw 2026+ 的 memory_search/memory_get 原生工具，迁移成本较高。
• 初始化负担：存量项目需手动迁移臃肿的 MEMORY.md（>1500 bytes）至分层存储，存在一次性拆分成本。
• 自进化外部依赖：若启用 Self-Evolution，必须额外安装 agent-browser 或搜索工具，否则陷入「幻觉式内循环」。
• Python 运行时依赖：要求宿主机预装 Python 3.6+，纯容器/沙箱环境受限。

适合人群

• 运行 OpenClaw 2026+ 的低资源服务器 Agent 开发者
• 对「确定性状态管理」有强需求、厌倦文件碎片化的技术洁癖者
• 需要长期自主运行、自我迭代的真正 autonomous Agent 项目

常规风险

| 风险类型 | 描述 |

|---------|------|

| 架构合规失败 | 未通过 `lint` 的任务计划会被系统拒绝执行 |

| 迁移数据丢失 | 若 Agent 未主动处理 legacy-MEMORY 备份，历史对话可能永久归档 |

| 外部工具链缺失 | Self-Evolution 缺乏浏览器能力时，演化质量大幅下降 |

| 版本兼容性 | OpenClaw < 2026 无法使用原生语义检索，架构降级为普通文件系统 |