核心用法
TriCore 是一套面向资源受限环境的 Agent 底层记忆与认知基础设施。其核心设计思想是"存储与计算解耦"：禁止 LLM 直接读写大文件，所有状态变更必须通过 tools/memctl.py 引擎路由。架构分为三层：Brief 层（MEMORY.md 微型档案指针）、Living 层（WORKING.md 运行任务流）、Stable/Volatile 层（知识库与临时日志）。
Agent 使用时须遵循三大法则：(1) 读取历史必须使用原生 memory_search 语义检索，禁止直接 read 灌入大文件；(2) 所有落盘操作（日志、任务、知识）只能调用 memctl.py 子命令（capture/work_upsert/kb_append）；(3) 任何 Cron 或自动化脚本在部署前必须通过 memctl.py lint 合规检查。
显著优点
1. Token 效率极致化：检索优先机制将上下文输入控制在碎片级别，显著降低低资源环境的 API 成本。
2. 架构硬约束：原生 Linter 机制在运行时拦截非法文件写入，杜绝传统 Agent 散乱生成 task_plan.md 等孤岛文件的问题。
3. 认知技能套件：内嵌重构版的 Planning、ReAct、Self-Evolution 三大认知模板，可直接作为 Agent 能力基座。
4. 状态机确定性：Code-First 设计将模糊的自然语言状态管理转化为可审计、可回滚的命令行操作。
潜在局限
- 环境依赖严格：必须依赖 OpenClaw v2026+ 的
memory_search/memory_get原生工具，以及 Python 3.6+ 运行时，迁移成本较高。 - 冷启动复杂度：旧版
MEMORY.md需人工介入迁移，Agent 需主动调用命令完成遗产分发，无法全自动完成。 - 进化技能受限：
self-evolution.md需额外安装agent-browser技能及网络/写权限，只读沙盒中无法生效。 - 学习曲线陡峭：与传统 Prompt-based 记忆管理差异大，Agent 需重新理解"命令代理"范式。
适合人群
- 运行在长期低 Token 预算、需要精确成本控制的生产级 Agent 系统。
- 追求可审计、可复现状态变更的企业级 Agent 部署场景。
- 愿意投入 upfront 架构改造以换取长期维护简洁性的技术团队。
常规风险
- 误操作数据丢失：
install.sh的自动迁移逻辑若被 Agent 忽略，可能导致历史记忆未正确分发而沉淀在 archive 目录。 - Linter 过度拦截：激进的正则规则可能误伤合法但非标准的 Shell 命令，需人工介入调整。
- 检索盲区：完全依赖语义检索意味着若 embedding 质量不佳，关键记忆可能无法召回。
- 生态锁定：深度绑定 OpenClaw 特定版本工具，跨平台迁移需重构工具调用层。