让家里的硬件自己会思考：一套开源智能硬件 Agent OS 的本地化架构、Skill 机制与长期记忆全拆解

本文由 莫潇羽@源码七号站（www.fuyuan7.com）撰写，转载请注明出处。

快速摘要

这篇文章拆的是一个叫 Anima 的开源项目，它本质上是一套"智能硬件 Agent OS"——跑在你家本地网络里，把灯、空调、加湿器、净化器、音箱这些设备，从"被动等一条指令"变成"会感知、会决策、会学习"的智能体。它的核心是四块拼起来的：Brain（基于 LangGraph 的决策中枢）、Skill（每类设备一个的领域知识包）、Memory（三层、可证据化的长期记忆）、Adapter（把动作翻译成米家/MIoT 等真实协议）。整套系统本地优先，习惯数据尽量不上云，目前已经能接入小米米家设备并跑通完整闭环。

我自己把它的仓库、架构图和源码目录翻了一遍，最大的感受是：它没在"做一个更花哨的遥控器"这件事上较劲，而是认真想了一个问题——能不能让设备自己理解你什么时候需要什么，然后主动行动。下面我会把它的设计思路、每个模块怎么协作、怎么在本机跑起来、怎么接米家，连同我踩到的坑和适用边界，一次性讲透。术语第一次出现我都会用大白话解释，新手也能跟下来。

想看完整拆解，往下翻。

一、先把问题讲清楚：传统智能家居到底卡在哪

聊一个新项目之前，我习惯先把"它想解决的痛点"摆明白，否则架构讲得再漂亮，也只是空中楼阁。

智能家居这个概念喊了快十年，但很多人买了一堆设备回家，折腾两周之后基本只剩两种用法：要么掏手机点开 App 一个个开关，要么对着音箱喊一句"打开客厅灯"。这其实不叫智能，这叫"换了个遥控器"。真正让人疲惫的，是下面这几件事。

（一）联动规则太脆，生活节奏一变就崩

绝大多数智能家居的"自动化"，本质是一条条 if-this-then-that 的规则。你设定"晚上七点自动开灯""湿度低于 40% 就开加湿器"，听起来很美，问题是这些规则全是写死的阈值。

可现实生活根本不是按阈值走的。今天你加班到十点才回家，七点那条开灯规则就成了空开一晚上的浪费；周末你睡到中午，工作日设好的早间唤醒灯光反而把人吵醒。规则不会因为你今天状态不同而变，它只会机械执行。结果就是：你不断地去 App 里改规则、加条件、设例外，最后维护这些规则花的精力，比手动开关还多。

我自己折腾下来的体会是——只要一套系统需要你不停地去"教它新规则"，它就还没真正智能。

我印象很深的一次：给家里配了套"回家自动开灯+开空调"的联动，逻辑是检测到手机连上家里 Wi-Fi 就触发。听着挺好，结果有阵子我在家办公，手机一整天都连着 Wi-Fi，这条规则压根不会触发，反倒是有天我下楼取个快递、手机短暂断网再重连，灯哗一下全亮了。规则不懂"我其实没离开家"，它只认那个死板的触发条件。这种"规则理解不了真实情境"的别扭，几乎是所有阈值式自动化的通病。

（二）设备只会被动等指令，不会主动判断

更深一层的问题在硬件本身的角色定位上。今天市面上的智能设备，传感器有了、联网有了、能被远程控制也有了，但它们绝大多数时候都在干一件事：等命令。等手机来一条、等语音助手来一条、等某条预设规则被触发。

它不会主动问一句"现在屋里是不是太干了，要不要我开一会儿加湿"，也不会注意到"主人这周连续三天都把空调调到 26 度睡觉，那以后默认就给到这个温度"。每一台设备都是一座信息孤岛，彼此之间也不商量——加湿器开它的、空调吹它的，谁也不知道对方在干嘛，更别说协同。

（三）思路得反过来：从"能被控制"到"会主动判断"

把上面两点合起来看，你会发现传统方案的核心假设是错的。它默认"人是决策者，设备是执行器"，所以拼命优化"怎么让设备更好地被控制"。

而真正想要的那种体验，需要把这个假设倒过来：让设备具备一定的判断力，能读懂环境和你的习惯，在安全边界内自己拿主意。 你不再是那个时刻盯着 App 的人，而更像一个偶尔发话、平时被照顾的人。

这件事这两年之所以变得有可能，是因为大模型（LLM，就是 ChatGPT、DeepSeek 这类能理解自然语言、能做推理的模型）成熟了。LLM 天然擅长"在一堆混乱信息里做判断"，这恰好就是写死的 if-then 规则最缺的能力。于是一个很自然的想法冒出来：能不能给家里的硬件，配一个"会思考的大脑"？

Anima 就是顺着这个思路做出来的一次完整尝试。

二、Anima 是什么：一个跑在本地网络里的"硬件智能运行时"

Anima 这个名字来自拉丁语，意思是"灵魂"。这个命名挺点题——它想给本来只会被动响应的硬件，注入一点"自己会想事情"的能力。

官方给它的定位是一句话：面向智能硬件的开源 Agent OS。 这里有两个词得先掰开讲。

（一）什么是 Agent OS / Agent Runtime（白话版）

先说 Agent。在 AI 圈，Agent（智能体）指的是这么一种程序：它能感知环境、能自己规划该做什么、能调用工具去执行，而不是被动地一问一答。普通聊天机器人是"你问我答"，Agent 是"你给个目标，我自己拆解步骤、动手把它做完"。

举个智能家居里的对照就更清楚了。传统语音助手是这样：你说"打开空调"，它就打开空调，一对一，你不说它就不动，你说错了它也照做。而一个 Agent 是这样：你说"我有点热"，它会去想——现在几度、湿度多少、你平时怕不怕冷、是开空调还是开个风扇就够、要不要顺手把窗帘也拉上挡太阳。它把"一个模糊的意图"翻译成"一串具体的、协同的动作"，这就是智能体相比助手的跃迁。前者是执行器，后者更像个会权衡的管家。

再说 OS / Runtime。这里的 OS 不是 Windows、安卓那种操作系统，而是一种比喻——它是一层运行时底座，负责把"设备""大脑""记忆""动作"这些零件统一管起来、让它们协同运转。你可以把它理解成"智能硬件的运行时环境（Runtime）"：设备接进来由它登记、状态由它维护、决策由它统一调度、动作由它派发出去。

合起来，Anima 就是一个跑在你本地网络里的智能硬件 Agent Runtime。它干这么几件事：

• 自动发现设备：在局域网里扫一圈，把能控制的硬件登记进来，维护它们的实时状态。
• 维护长期记忆：从你明确说出的偏好、以及重复出现的行为里，慢慢学出你的习惯。
• 用 LLM 当大脑做规划：把环境信号、设备状态、历史记忆、技能知识揉在一起，让大模型规划该做什么动作。
• 把决策落到真实硬件：通过适配器（Adapter）把抽象的动作翻译成具体设备听得懂的协议指令。
• 给你一套观测和控制面板：自带 Dashboard、REST API 和 CLI，方便你观察、调试、控制和扩展。

（二）四个关键能力：可感知、可决策、可学习、可扩展

如果要用四个词概括它跟"设备控制面板"的本质区别，就是这四个：可感知、可决策、可学习、可扩展。

可感知，是说它持续读取环境和设备状态，知道"现在屋里什么情况"。可决策，是说它不止做"开/关"，而是结合场景、舒适度、安全边界来判断"现在该不该动、动到什么程度"。可学习，是说它会把你的偏好沉淀成长期记忆，越用越懂你。可扩展，是说新增一类设备时，你主要是给它补一个"知识包"，而不是去改它的核心代码。

这四点后面每一块我都会单独拆，这里先有个整体印象。

（三）技术栈一览

为了让你心里有底，先把它的家底列出来。这套东西不是 PPT，是真能跑的工程，主要技术栈如下：

从语言占比看，它大头是 Python（约七成）加 TypeScript（约两成多），是一个典型的"Python 后端 + React 前端"的全栈项目，用 pnpm 管前后端依赖、用 uv 管 Python 依赖。许可证是 Apache-2.0，属于商用比较友好的开源协议（但真要商用，相关素材和依赖的授权还是得自己核一遍）。

为什么它敢叫自己"OS"而不只是"App"或"工具"，这个命名其实透着野心。App 是装在系统上的一个应用，而 OS 是承上启下的底座——它定义了"设备怎么接进来、能力怎么组织、决策怎么调度"这一整套规范。Anima 把设备接入、知识封装、决策编排、记忆沉淀都抽象成了可替换、可扩展的标准件，谁都能照着规范往里加新设备、新技能、新协议。从这个角度看，"OS"这个词用得不算虚——它确实是在为智能硬件这件事，立一套底层的运行规范，而不只是又写了个能开关灯的小程序。

（四）"本地优先"是它的底色

还有一个特别值得拎出来说的设计取向：本地优先（local-first）。

它的核心运行时跑在你自己的机器上，设备控制尽量走局域网完成。这意味着你家什么时候开灯、几点睡觉、习惯把空调调到几度，这些数据默认留在本地，不需要先上传到某家公司的云端再绕回来。对隐私敏感的人来说，这一点的分量，比多几个炫酷功能要重得多。

当然，"本地优先"不等于"完全离线"。它的大脑要调用 LLM，如果你用的是云端大模型，那一次推理还是会把必要的上下文发给模型服务方——这部分后面讲配置时我会专门提醒，包括怎么选更稳妥的方案。

三、整体架构：信号怎么进来、决策怎么出去

光知道有四块零件还不够，得看它们怎么串成一条能转起来的流水线。这一节我用一条"完整闭环"把整个系统讲通。

（一）驱动它运转的信号有哪些

Anima 不是只靠你说话才动。它的运转由好几类信号驱动，任意一个都可能触发一次思考：

• 用户的对话请求（你主动发话）
• 设备发现（局域网里冒出一台新设备）
• 传感器状态更新（温湿度、空气质量变了）
• 定时任务（每隔一段时间主动巡检一次）
• 设备动作的执行反馈（上一个动作做完了，结果回来了）

这些信号进入 Anima 的核心（Core）之后，会被汇总成一份"当前环境快照"，交给大脑去理解。

（二）一条完整的决策闭环

把核心流程拉直了看，它是一个清晰的环：

设备发现 → 大脑规划 → 技能决策 → 适配器执行 → 状态校验 → 历史/记忆学习
                ↑                                              │
                └──────────────（反馈回流，影响下一次决策）──────┘

翻译成人话：先把家里有什么设备摸清楚（设备发现）；大脑结合环境、记忆、技能能力规划出该做什么（大脑规划）；具体到某类设备，由对应的技能把"目标"转成"结构化动作"（技能决策）；适配器把动作翻译成真实协议指令打到设备上（适配器执行）；动作做完后回读一下设备状态，确认到底执行成没执行成（状态校验）；最后把这次的对话、动作、结果统统写进历史，后台再从历史里慢慢提炼出更稳定的长期记忆（历史/记忆学习）。

关键在最后这一步回流：这次学到的东西，会沉淀下来，影响下一次决策。用得越久，它对你这个家的"画像"就越准。这是它和"写死规则"最本质的区别——规则是静态的，而这套环是会自我进化的。

这里多说一句为什么"状态校验"这一环不能省。很多自动化系统是"发了指令就当成功了"，但现实里设备可能离线、可能指令丢了、可能执行了一半。Anima 在动作之后专门回读一次设备的真实状态，确认到底成没成——这看似多此一举，实则是让系统"对自己的行为有自知之明"的关键。只有知道上一步到底成没成，下一步的规划和学习才站得住脚，否则记忆里记的全是"我以为我做到了"的假账。

（三）用一张图看懂数据流

文字描述容易抽象，画成流程图就直观多了：

flowchart TD
    A[用户请求 / 设备发现 / 传感器更新 / 定时任务] --> B[Anima Core 汇总信号]
    B --> C[Brain 大脑：结合设备状态 + Memory + Skill 上下文做规划]
    C --> D[Skill 技能：把高层目标转成结构化动作]
    D --> E[Adapter 适配器：映射到 MIoT 等真实协议]
    E --> F[真实设备执行]
    F --> G[状态校验：回读设备实际状态]
    G --> H[History / Memory：写历史、后台提炼长期记忆]
    H -. 反馈回流 .-> C

这张图里，每一层只干一件事、边界清楚：Core 负责汇总、Brain 负责想、Skill 负责把想法具体化、Adapter 负责落地、Memory 负责沉淀。这种"职责单一、层层解耦"的设计，是它后面能不断扩展新设备、新协议的底气所在。接下来就一层一层往里钻。

四、Brain：中枢决策层，也是一条安全红线

Brain（大脑）是整个系统的智能中枢。它的活儿，是把用户对话、设备状态、环境信号、记忆、技能能力这一堆东西合并起来，最终吐出一份"可执行的计划"。

但它最值得讲的，其实不是"它有多聪明"，而是"它被管得有多严"。我先讲它怎么思考，再讲它的缰绳在哪。

（一）为什么用 plan-and-execute，而不是放任 LLM 乱点

Anima 的大脑用的是 LangGraph 来编排流程，走的是 planner / executor（规划器 / 执行器） 这套模式，业内一般叫它 plan-and-execute（先规划、后执行）。

这里要给新手补一句背景。让大模型当 Agent，常见有两种玩法。一种叫 ReAct，思路是"想一步、做一步、再想一步"，每做一个动作都得回去问一次大模型——灵活，但慢、贵，而且容易在中途跑偏。另一种就是 plan-and-execute：先让大模型一次性把整件事的步骤全想清楚，列出一份计划，然后照着计划一步步执行；执行完再回头看看，要不要重新规划。

后者的好处很实在：因为不用每个动作都麻烦那个又大又贵的规划模型，所以更快、更省；而且强迫模型"先把整个任务从头到尾想一遍"，往往规划质量更高、更少漏步骤。对智能家居这种"一句话可能牵动好几台设备"的场景，这种先谋后动的方式更稳。

我画个简化流程帮你建立直觉：

flowchart LR
    U[用户意图 / 环境变化] --> P[Planner 规划器：拆出多步计划]
    P --> X[Executor 执行器：执行计划中的一步]
    X --> J{检查：任务完成了吗}
    J -- 没完成 --> P
    J -- 完成 --> R[输出结果 + 写回状态]

注意那条从"没完成"绕回规划器的循环线——这就是 plan-and-execute 比一根筋执行强的地方：第一版计划没奏效，它能根据实际进展重新规划，而不是傻乎乎地把错误执行到底。

（二）统一入口与"主动巡检"

Brain 对外有一个统一的聊天入口 /api/chat。无论你是闲聊、下达任务还是问状态，都从这个口子进去，由大脑统一理解、统一调度。这种"单一入口"的设计让整个系统的行为更可预测，也更好调试。

更有意思的是它的定时 brain tick机制——简单说，就是大脑每隔一段时间会自己醒一次，主动巡检一遍当前环境，看看需不需要做点什么。

这一点正好补上了第一章说的痛点。传统设备是"被问才动"，你不喊它就不管;而有了定时 tick，Anima 可以"主动"地发现"现在屋里有点干""空气质量降下来了"，然后在它的权限范围内自己处理。从"被动响应"到"主动照顾"，这个 tick 是关键开关之一。

围绕一次决策，Brain 还做了两件容易被忽略但很重要的事：技能执行前，它会先把相关上下文（环境、设备能力、记忆）拼装好再交给技能；动作执行后，它会做状态校验、并把这次交互写进 history。前者保证决策有据可依，后者保证系统知道"自己到底干了啥、成没成"，也为后续学习留下了原料。

（三）大模型后端：兼容就好，选择很多

Brain 的大模型后端走的是 OpenAI 兼容（OpenAI-compatible）协议。这是个非常实用的设计——只要某个大模型服务对外提供 OpenAI 风格的接口，理论上就能接进来。

这意味着你的选择面很宽：可以接国内的 DeepSeek、豆包这类服务，也可以用本地部署的 Ollama 兼容端点把模型彻底跑在自己机器上。具体怎么配、国内环境下怎么选更稳妥，我放到第八章"动手"部分细讲，那里还有一段必须看的合规提醒。

（四）安全红线到底在哪

这一节我留到最后，是因为它是 Brain 设计里我个人最看重的一点。

官方把它的设计理念写得很直白：Brain 的目标不是让 LLM 随意控制设备，而是让它在明确的技能边界、设备能力和安全规则之内做决策。

这句话翻译过来，就是一条很硬的安全红线。大模型再聪明，也有"胡说八道"（业内叫幻觉）的时候，你绝不希望它脑子一热把门锁打开、把电器全开起来。Anima 的做法是给大脑套上三层缰绳：

• 技能边界：每类设备能做什么、不能做什么，由对应的 Skill 事先框定，大脑只能在框内出牌。
• 设备能力：动作必须落在设备真实支持的能力范围内，凭空想象的动作发不出去。
• 安全规则：对门锁、安防、强电这类高风险设备，默认采取保守策略。

官方在安全说明里也专门强调过：对门锁、安防、强电这类设备，自动化要保守；Dashboard 和 API 不要直接暴露到公网；小米 token、大模型密钥这些敏感信息只放在可信环境里。这部分我在第八章会再展开成一份"部署底线清单"。

（五）走一遍：一句"屋里有点闷"背后发生了什么

光讲机制有点干，我用一个生活化的例子，把这一章的零件串起来给你看一遍。

假设晚上你随口说了句"屋里有点闷"。这句话从 /api/chat 进到大脑里。规划器（Planner）不会傻乎乎只盯着"闷"这个字面，它会先把当前的环境快照拿出来——温度多少、湿度多少、空气质量怎么样、现在几点、你平时这个点的偏好是什么（这就是 Memory 里 L1、L2 在发挥作用）。

接着它做规划：闷，可能是空气不流通，也可能是温度偏高、湿度偏大。于是它拆出一个多步计划，比如"先查空气质量，再判断要不要开净化器，顺带看看温度要不要微调"。然后交给执行器（Executor）一步步落地：调用 air_purifier 技能查空气质量、必要时开净化模式，调用 air_conditioner 技能微调温度——而且因为现在是晚上，技能里"睡眠安静策略"会让它倾向于低噪运行，不会哐哐开到最大档。

每个动作做完，系统都会回读设备实际状态校验一遍，确认真的执行了；这次的对话和动作结果会写进 history。如果你接下来回了句"对，这样舒服多了"，这条正向证据就会进入记忆提炼流程，慢慢沉淀成"主人晚上偏好的舒适设置"。

你看，整个过程里没有一条写死的 if-then 规则。它是"理解意图 → 调专业知识 → 在安全档位内动手 → 校验 → 学习"这么一条活的链路。这就是 Agent 和传统自动化最直观的区别。

一句话总结这一章：Brain 让设备变聪明，但真正让人敢用的，是它给"聪明"上了锁。

五、Skill：设备智能的最小单元

如果说 Brain 是会思考的大脑，那 Skill（技能）就是大脑赖以做出"专业判断"的知识储备。这块是 Anima 设计里我觉得最巧的地方之一，值得多花点笔墨。

（一）它不是函数，也不是 prompt，而是"设备领域知识包"

很多人一听"技能"，第一反应是"不就是一个函数调用嘛"，或者"不就是一段提示词嘛"。在 Anima 里，Skill 比这两者都重。它是一个设备领域知识包——把某一类设备"该怎么聪明地工作"这件事，完整地打了个包。

举个例子你就懂了。"开加湿器"是个函数调用，但"现在是冬天、屋里开着空调本来就干、湿度掉到 35% 了、而且主人正在睡觉所以得小档静音运行"——这一整套判断，靠一个函数是表达不出来的，得靠知识。Skill 装的就是这种知识。

（二）一个 Skill 长什么样

每个 Skill 的目录结构是高度规范化的，长这样：

SKILL.md            # 技能元信息：适用哪些设备、工作规则是什么
references/
    knowledge.md    # 领域知识：这类设备的舒适模型、常识、注意事项
    decide.md       # 单次决策用的提示词：这一刻该不该动、动多少
    learn.md        # 长期学习用的提示词：从历史里提炼这类设备的偏好
scripts/
    actions.py      # 结构化动作的执行入口

拆开看就很清楚了：knowledge.md 是"这类设备的常识库"，decide.md 管"此刻怎么决策"，learn.md 管"长期怎么学习"，actions.py 则是真正能落地执行的动作出口。一个 Skill 把"知识 + 当下决策 + 长期学习 + 可执行动作"四件事整整齐齐地收在一个文件夹里。

（三）内置技能清单

Anima 自带了一批开箱即用的技能，覆盖了家里最常见的几类设备和一些系统级能力：

这里有两个技能特别想点一下。

一个是 coordinator（协同器）。它解决的正是第一章吐槽的"设备各干各的"问题——让加湿器知道空调在干嘛、让多台设备围绕同一个目标商量着来，而不是互相打架。

另一个是 skill_creator（技能生成器）。这是个很有"自举"味道的设计：你用大白话描述一个新需求，它能帮你生成一个自定义技能的骨架。换句话说，这套系统具备了一定的"自己长出新能力"的能力。

这一点的想象空间挺大。传统智能家居加一个新玩法，往往得开发者写代码、发版本、用户再更新;而有了技能生成器，理论上你只要把需求说清楚，系统就能帮你把骨架搭出来，你再补充细节。它把"扩展能力"这件事的门槛，从"会编程"往"会描述需求"的方向拉了一大截。当然，现阶段它生成的更多是骨架而非成品，真正能用还得人去打磨，但这个方向本身，代表了一种"让系统参与构建系统"的有趣思路。

如果内置技能不够用，你可以在 skills/custom/ 目录下放自己的技能，让 Anima 学会新设备的行为或者你家特有的工作流。

（四）Skill 的完整生命周期

Skill 在 Anima 里不是"写好就摆那儿"的死代码，它有一条完整的生命线：

flowchart LR
    A[设备能力：自动发现 / 用户定义] --> B[Skill Creator 生成技能]
    B --> C[Skill Bank 技能库：登记、可被检索]
    C --> D[Planner 规划时按环境/状态/记忆选用合适技能]
    D --> E[技能把高层目标转成结构化动作]
    E --> F[经 Adapter 作用到真实设备]
    F --> G[执行结果回流到 Memory 与 learned profile]
    G -. 让下次决策更贴合习惯 .-> C

顺着这条线走一遍：设备能力（不管是自动发现的，还是你手动定义的）可以进到技能生成器里，被整理进"技能库"供大脑检索；执行时，规划器根据当前环境、设备状态和记忆，挑一个合适的技能出来；技能把高层目标转成结构化动作，经适配器作用到真实设备上；执行结果再回流到记忆和"已学习画像"里，让以后的决策更懂你。

所以官方那句话说得很准：Anima 里的 Skill 不是一次性的函数调用，而是一个可以被创建、注册、检索、执行、并通过反馈不断改进的"设备智能单元"。

（五）为什么新增设备要优先写 Skill

最后讲一个工程上的设计原则，这条对想动手扩展的人很关键：新增一类设备时，优先去扩展 Skill，而不是把设备策略硬编码进 Brain 或 Adapter。

道理其实很朴素。如果你把"加湿器冬天该怎么调"这种逻辑写死在大脑里，大脑就会越来越臃肿、越来越难维护，每加一类设备都要动核心代码，风险极高。而把策略沉淀到独立的 Skill 包里，大脑保持精简、只管调度，设备知识各自独立、互不干扰——加新设备就是加一个文件夹的事。这种"核心稳定、能力外挂"的架构，才撑得起长期演进。

六、Memory：可证据化的三层长期记忆

如果说 Skill 是"这类设备的通用知识"，那 Memory（记忆）就是"关于你这个人的专属知识"。这是 Anima 最有辨识度的设计，我个人也认为是它区别于普通自动化系统的灵魂所在。

直接把所有历史一股脑塞给大模型？不行——又贵、又慢、还容易让模型被无关信息带偏。Anima 的解法是给记忆做了分层 + 证据化两件事。

（一）三层记忆，各管一段

记忆被分成 L1、L2、L3 三层，粒度从粗到细：

L1 Core Identity（核心身份）
    每次请求都加载的极简偏好摘要，比如一句话的 preferences_summary。

L2 Memory Directory（记忆目录）
    给规划器看的"目录"：有哪些已学习画像、有哪些记忆主题。

L3 Memory Detail（记忆细节）
    在某个设备技能真正执行前，按设备类型和任务检索出来的详细长期记忆。

为什么要分三层？核心是为了在"长期学习"和"上下文控制"之间取得平衡。我做个对照表你就明白每层的取舍了：

这套设计的精妙之处在于：L1 始终轻量，保证每次请求都带着对你的基本认知；L2 提供一份目录，让规划器先知道有什么、再决定查什么；L3 只在真正需要时才加载确认过的详细记忆。这样既不会因为塞太多历史而拖垮上下文，又不会因为信息太少而决策失准。系统对外暴露记忆的方式也很克制——大脑用 get_planner_context() 拿目录级上下文，技能执行时用 get_skill_context(device_type) 按设备类型拿细节，各取所需。

（二）"证据晋升"：候选记忆怎么变成确认记忆

分层解决的是"怎么用"，证据化解决的是"信不信"。这是我最喜欢的一个设计。

一条记忆不是你随口一说、它就当真的。Anima 给每条记忆都带了一套"证据档案"，关键字段包括：

• claim_type：这条记忆是什么类型——明确偏好、隐含偏好、作息规律、设备别名、约束条件、还是家庭背景。
• positive_evidence / negative_evidence：支持它和反对它的证据分别来自哪里。
• status：它现在处于什么状态——候选（candidate）、已确认（confirmed）、已否决（rejected）、还是已过期（stale）。

每次交互，系统都会在 history.json 里给它生成一个 event_id，作为后续提炼记忆的原料。后台会从历史里提取出"候选记忆"，然后按证据多少决定要不要把它晋升为已确认记忆。

最关键的一条规则是：默认只有已确认（confirmed）的记忆，才会真正进入技能决策。 候选记忆只是"嫌疑人"，证据不足时它影响不了真实的设备控制。这就避免了"偶然一次的反常行为"被误当成长期习惯——比如你某天临时把空调开到很低，系统不会立刻就把这当成你的偏好写死，而是先存为候选，等后续证据。

打个比方，这套机制有点像法庭办案：先有线索（候选），再凭证据定罪（晋升为确认），证据不足就先押着（保持候选）甚至撤案（否决）。设备控制这种"做错了有真实后果"的事，就该这么谨慎。

为了让你对 claim_type 那几类记忆更有体感，我各举一个生活化的例子（都是通用化的虚构场景，方便理解）：

• 明确偏好：你直接说过"我喜欢睡前把灯调成暖黄色"——这是你亲口表达的，证据最硬。
• 隐含偏好：你从没说过，但系统观察到你连续多晚都