homent-system

作者：Hyrilx @github

把 LLM Agent 接入真实米家设备，并用工程边界约束它的行动

Homent 是一个 local-first 的智能家居 Agent。它把模型接到真实米家设备前，先用 contracts、CoreAdapter、MCP Server、 Agent Runtime、Agent Server 和 Web UI 划清运行边界。模型可以理解和建议，实际写设备时仍要经过审批、审计和回归验证。

分层模块化米家真实接入意图-行动安全体系记忆驱动 LLM 决策调度 / 动作计划 / 习惯学习自闭环开发基础设施

技术命题 1

先划清层边界

设备协议、能力暴露、Agent 决策、人机交互和跨层合约分开处理。这样 fake adapter 可以跑确定性测试， real adapter 可以接真实米家，MCP 层屏蔽设备协议，Agent Runtime 不感知 MiHome 细节。

技术命题 2

从固定自动化到可学习 Agent

固定自动化通常只有两种模式：用户发指令，或者条件触发动作。Homent 增加了一条 Agent 决策链路：系统读取家庭状态、近期事件和长期记忆，再让 LLM 给出建议或主动 tick。策略层决定自动执行、要求审批，还是直接拒绝。

技术命题 3

记忆和轮询让系统有上下文

Agent Memory 记录偏好、长期指令、自动化规则和决策摘要。Proactive Tick 周期性读取 HomeContext、近期事件和记忆。 delayed one-shot、comfort preference、habit learning 和 memory maintenance 让这些记录进入后续决策，而不是只停留在存储层。

技术命题 4

把意图和动作分开

LLM 不直接写设备。Web UI 产生的是 UserIntent，Agent Runtime 生成受验证的 ActionProposal， AutomationPolicy 决定自动执行、要求审批、拒绝或无动作，最终写入必须产生 ActionResult 与审计日志。

背景与目标

难点在于安全托付

把 LLM 接入智能家居后，风险不再只是 UI 交互做得好不好。模型可能误解意图，生成设备不支持的动作，甚至把动作发到错误设备上。 Homent 的目标很明确：Agent 可以观察、记忆、规划和行动，但行动前必须穿过固定边界。

现在仓库已经跑通 fake 闭环、真实 MiHome adapter、MCP HTTP transport、默认 OpenAI-compatible LLM planner、长期记忆、 proactive tick、延迟一次性动作、多步骤动作计划、舒适偏好学习、习惯学习、记忆生命周期维护、Agent HTTP API、Web UI cockpit，以及覆盖跨层链路的 E2E 测试。

6核心边界：contracts / CoreAdapter / MCP / Agent Runtime / Agent Server / Web UI

4控制链路核心产物：ActionProposal / ActionPlan / ActionResult / ActionLogEntry

1唯一设备写入路径：Agent Runtime -> MCP Client -> MCP Server -> CoreAdapter

架构介绍

按系统分层理解，而不是按箭头依赖硬记

这张图把当前模块放到同一张分层图里：左侧是贯穿全系统的合约轴，中间是运行时业务分层，右侧是部署、测试和工具设施。它表达的是“职责在哪一层”，不是要求记住每一条 crate 依赖。

各模块展开

每个模块都有明确边界，也有自己的内部结构

这里按“模块做什么、内部由什么组成、和谁协同”来讲。听众可以顺着一次请求或一次设备写入往下看，也能看出这些层为什么要分开。

协议与模型层

Contracts：跨层语义的单一事实源

内部组成

contracts/*.schema.json：定义 action、agent、agent interaction、memory、context、device、entity、event、MCP tools、proactive agent、service 等模型。
crates/homent-contracts：Rust 侧共享类型，供 Core、MCP、Agent、E2E 使用。
generated/ts/homent-contracts：前端 @homent/contracts 类型包，供 Web UI 使用。

主要语义

UserIntent 表达用户输入，避免 Web UI 直接构造设备写入。
ActionProposal、ActionResult、ActionLogEntry 构成提案、执行和审计链路。
ActionPlan 表达多步骤场景；ScheduledAction 表达延迟一次性动作。
AgentInteractionResult、AgentMemoryRecord、ProactiveTickResult 支撑聊天、记忆生命周期和主动轮询。

协同方式

跨层变化先改 schema，再检查 Rust/TS 类型和 E2E，避免每层各自定义 wire model。
just contracts 与 just check-contracts 用来发现生成物漂移。

设备抽象层

CoreAdapter：把真实设备协议收敛到统一能力接口

`homent-core-api`

只定义 CoreAdapter trait、事件流类型和适配器错误，不包含米家协议。
读接口覆盖单实体、批量缓存读、显式刷新读；写接口接收 ActionRequest 并返回 ActionResult。
refresh_entity_states 专门服务显式刷新和写入后的状态校验。

`homent-core-mihome`

FakeMiHomeAdapter 是默认 deterministic 本地闭环，支撑测试和本地开发。
RealMiHomeAdapter 封装 Xiaomi 账号、OAuth、MIoT Cloud、MIoT spec、Cloud MIPS、云端读写和事件观察。
内部按 config、mapping、action、fake、mihome 等子模块组织。
当前显式支持 power、brightness、temperature、mode、color temperature、target humidity、fan level、curtain position 等 contract action。

协同方式

上层只看到 Entity、EntityState、EntityCapability、HomeContext 和 ActionResult。
Real adapter 缓存 inventory、spec 和普通状态读；显式刷新或写后校验走 fresh path。
真实写入成功不只看云端返回，还要刷新后确认归一化状态匹配目标值。

能力边界层

MCP Server 与 MCP Host：把设备能力变成可审计工具边界

`homent-mcp-server`

依赖 homent-core-api，不依赖 homent-core-mihome 的实现细节。
HTTP transport 暴露 list_entities、read_entity_state(s)、write_entity_action、get_home_context、recent events 和 health。
write_entity_action 是设备写入边界，会产生审计记录；但提案创建和审批策略不在这一层。

`homent-mcp-host`

是薄部署入口，按 HOMENT_ADAPTER=fake|real 选择 Fake 或 Real adapter。
读取本地运行时配置，启动 MCP HTTP transport；不创建 proposal，不审批 action，不暴露 Agent API。
让 fake 和 real 共用同一个 MCP Server，从而保证测试路径和真实路径形态一致。

协同方式

Agent Runtime 通过 McpClient 抽象访问 MCP，而不是链接设备或协议 crate。
Web UI 的写入请求必须先变成 UserIntent，再由 Runtime 通过 MCP 写入。
MCP health 是服务可用性观察，不会触碰真实设备。

Agent 决策层

Agent Runtime：LLM、记忆、策略、调度和审计的核心

Planning 子系统

OpenAiCompatibleLlmPlanner 是正常启动时的默认决策核心，输出 reply、memory operations、单动作 proposal 或多步骤 action plan。
普通消息和 proactive tick 都会携带经过筛选、脱敏、限量的相关记忆，让长期偏好进入 LLM 决策上下文。
模型可以输出一个 validated proposal，或一个 bounded sequential ActionPlan；两者不能同时出现。
Planner 只发送 prompt-scoped alias，不发送 raw EntityId 或米家协议元数据；输出必须经过 alias、action、参数、risk 和 capability 校验。

Memory / Policy / Scheduler

JsonFileMemoryStore 保存偏好、长期指令、自动化规则和紧凑决策摘要，并维护 status、confidence、expires_at、supersedes。
舒适偏好会从当前温湿度上下文中形成结构化 memory；重复回家后开灯等模式会被阈值化提升为 inspectable automation rule。
AutomationPolicy 决定 auto execute、require approval、reject 或 no-op。
Proactive scheduler 由 Agent Server 托管定时器；delayed one-shot queue 由 Runtime 在 tick 中处理，due action 仍走策略和 MCP 写入边界。

行动闭环

低风险 light/switch power 和 brightness 可在策略通过时自动执行；temperature 和 mode 仍要求审批。
多步骤动作计划必须以整体 pending plan 呈现给用户，审批后按顺序执行；当前没有事务回滚语义。
所有写入都通过 McpClient，并生成 ActionResult 与 ActionLogEntry。
DeterministicPlanner 仍用于 focused tests 和显式开发 fallback，不是正常默认决策核心。

HTTP 适配层

Agent Server：把 Runtime 安全暴露给 Web UI

API 面

设备与事件：/api/world/devices、单设备状态、recent events。
交互与审批：messages、streaming messages、intents、proposal approve/reject、action-plan approve/reject。
运行状态：agent state、service status、action logs、memory、scheduled actions、proactive tick/status/config。

内部适配

HttpMcpClient 实现 Runtime 的 McpClient trait，只通过 MCP HTTP 访问设备能力。
runtime_factory 正常启动时构造 LLM planner；缺少 LLM API key 时启动失败，避免静默降级。
Streaming message API 以 NDJSON 返回 reasoning_content、answer delta 和最终结果。

安全与体验

HOMENT_WEB_UI_ORIGINS 控制 trusted browser origin，低风险 Web UI 写入才允许自动执行。
设备 overview 有 HTTP cache；显式刷新和写后 reconcile 走 fresh read。
Agent API 可以在线报告 MCP offline，并给出本地重启提示，但不在浏览器执行 shell 命令。

人机交互层

Web UI：只表达意图、审批和观察，不直接控制设备协议

Dashboard

显示 Agent chat、streaming thinking、当前 focus、pending intent、approvals、recent events 和 service monitor。
显示真实 Agent state、memory count、proactive polling 状态，而不是占位 host metrics。
聊天走 streaming message API；reasoning_content 只作为短期 UI 内容，不进入记忆和日志。
显示 pending action plan、scheduled action、memory status/confidence/expiry 等 Agent 状态，不只显示单次 proposal。

Devices

读取 DeviceOverview，渲染实体、状态值和可写能力。
点击控件时构造 UserIntent，先做本地投影并标记 Syncing，再等待 Agent API 返回执行结果或 pending proposal。
新增控件仍必须由 capability 支撑：色温、目标湿度、风速档位、窗帘位置等都通过 UserIntent 进入 Runtime。
成功写入后只刷新受影响实体；失败或返回 pending 时恢复之前投影状态。

Settings / 服务支撑

读取 proactive status，使用 PUT /api/agent/proactive-config 调整后台轮询。
提供可复制的 just dev-agent、just dev-mcp-host 等提示，但不执行本地命令。
前端 mock data 只保留在 fixture tests 中，不作为真实运行路径。

验证与工程设施

E2E、Justfile 与 Scripts：把架构约束变成可执行检查

`crates/homent-e2e`

fake_mihome_event_loop 验证 fake 观察、写入和事件闭环。
four_layer_agent_interaction_flow 验证 Web intent 到 Runtime、MCP、Core 的四层链路。
llm_agent_decision_flow 与 natural_memory_proactive_agent_flow 覆盖 LLM 决策、记忆和 proactive tick。

`justfile`

fmt、lint、test、typecheck 覆盖基础质量门禁。
check-all 串起 Rust、contracts、boundaries、doc-context、前端 lint/test/build。
dev-mcp-host、dev-agent、dev-web、dev-real 组织本地运行栈。

`scripts/`

generate-contracts.sh 与 check-contracts-clean.sh 保护 contract-first 流程。
check-boundaries.sh 防止 Agent/Web UI 绕过 MCP/Core 边界。
check-doc-context.sh 保证文档路由、skills 和上下文保留流程没有断链。

米家接入与可扩展性

把米家实现放在最底层，向上只暴露统一能力

RealMiHomeAdapter 负责真实 Xiaomi 账号绑定、凭据加载、运行态凭据刷新、云端 inventory、MIoT spec、REST 写入和云端事件观察。这些细节都留在 homent-core-mihome 内部。上层只看到 Entity、EntityState、EntityCapability、HomeContext 和 ActionResult。

如果以后接入新的设备来源，只需要实现 CoreAdapter，不必重写 Agent、MCP 或 Web UI。FakeMiHomeAdapter 和 RealMiHomeAdapter 共用同一个 trait，所以 fake E2E 和真实验收走的是同一条产品路径。

新增 MiHome 控制能力也沿着这条路径扩展：先定义明确 ActionType，再由 CoreAdapter 映射到可写 MIoT property， Runtime 负责风险与审批，Web UI 只在 capability 存在时显示控件。

意图-行动安全体系

模型给建议，系统来把关

这里不把“理解用户说什么”和“真的去写设备”放在一起。用户表达、模型规划、系统提案、策略裁决、设备写入和审计记录分成几步。 LLM 可以处理自然语言，但拿不到直接写设备的权限。

LLM 决策核心

Agent Server 正常启动时使用 OpenAiCompatibleLlmPlanner。Planner 将 HomeContext 脱敏成 prompt-scoped aliases，同时注入相关记忆、近期事件和 proactive 输入，要求模型输出结构化 JSON，并在 Runtime 内把别名映射回真实实体。

提案验证

系统验证 entity alias、ActionType、参数类型、风险级别和目标设备可写能力。无效模型输出不会成为 pending action，更不会写设备。

自动执行范围

当前仅允许低风险 light/switch power 与 light brightness 在策略通过时自动执行。温度、模式、色温、湿度、风速、窗帘位置和多步骤计划保持审批。

真实写入验收

RealMiHomeAdapter 只有在 MIoT set 返回成功、刷新后的归一化状态也匹配目标值时，才把写入判为成功。

开发基础设施

Skills、知识库、流程规范与工具箱如何协同

这个项目还有一层工作：让 LLM Agent 能长期改这个仓库，而且每次都能找对边界、跑对检查、留下可追溯的上下文。

Skills 体系

homent-doc-context 是所有非平凡工作的入口，约束先读路由文档和相关上下文； homent-feature 管跨层需求，要求计划、评审、TDD、check-all 和验收； homent-review 负责计划评审与提交前审查； homent-debug 在 check-all、E2E 或集成失败时接管定位； contracts、core、mcp、agent-runtime、web-ui 各有 owning skill，限制修改只能落在本层职责内。

在流程里，它把“下一步怎么做”写成可重复的操作规程。

知识库架构

SYSTEM.md 定系统目标，ARCHITECTURE.md 定依赖方向和边界， CONTRACTS.md 定跨层模型语义，PLANS.md 定里程碑； docs/README.md 是文档路由表； plans/ 保存实施范围和状态； docs/decisions/ 保存 ADR； docs/agent/context-retention.md 规定上下文保留与交接。

在流程里，它让 Agent 从仓库事实启动，而不是靠上一轮聊天。

流程规范

普通需求要求从 main 开独立分支，先写顶层计划并通过 homent-review Plan Review Mode，再获得明确批准；实现阶段按受影响层 TDD，结束跑 just check-all；提交前做 Superpowers review 与 Homent pre-submit review； UI 相关做 Browser/Chrome 验证，设备相关做可逆真实设备验收，最终合并回 main 后再次全量验证。

在流程里，人审目标、计划、风险和验收，不逐步指挥每个实现动作。

工具箱

just 汇聚 fmt、lint、test、typecheck、contracts、check-contracts、check-boundaries、check-doc-context、check-remote、e2e、check-all 和 push-all； scripts 保护 contracts clean 和 layer boundaries； fake adapter、fake LLM endpoint 和 E2E 支撑不依赖真实云端的回归； Browser/Chrome 用于真实 UI； dev-real 串起 real MCP host、Agent Server 和 Web UI。

在流程里，验证要落到命令和证据上，不能只靠感觉。

开发体系清单

开发设施可以拆成几类

这些文件和命令服务同一个目的：让 LLM 在复杂仓库里工作时，不丢边界、不忘事实，也不跳过验证。

Homent 本地 Skills

homent-doc-context：选择本次任务需要读取的文档，决定经验应该沉淀到 plan、ADR、handoff 还是 skill。
homent-feature：跨 contracts、Core、MCP、Agent、Web UI 的需求交付流程，约束计划、评审、TDD 与验收。
homent-review：计划评审和提交前审查，重点检查层边界、合约漂移、设备写入安全和测试证据。
homent-debug：接管 just check-all、E2E、集成失败和真实验收失败，要求先复现再修复。
homent-contracts：维护 schema、Rust crate、TS package 与跨层语义一致性。
homent-core-adapter、homent-mcp-server、homent-agent-runtime、homent-web-ui：分别约束设备协议、工具边界、Agent 决策和 UI 交互的 owning scope。

通用流程 Skills

writing-plans：把需求拆成可审查、可执行、可验证的实施计划。
test-driven-development：先建立失败测试或缺口证据，再做最小实现。
systematic-debugging：问题修复时先保留症状、复现、定位根因，避免猜修。
receiving-code-review 与 requesting-code-review：把评审变成技术事实校验，不做表面同意。
verification-before-completion：在声称完成前必须有命令、浏览器或真实设备验收输出。

知识库与上下文层

AGENTS.md：顶层架构、层边界、测试命令、交付规则和完成标准。
docs/README.md：文档路由表，避免每次任务全量读取文档树。
SYSTEM.md、ARCHITECTURE.md、CONTRACTS.md、PLANS.md：稳定系统事实。
plans/0001-0017：feature plan、实施状态、验收证据和未完成上下文。
docs/decisions/*：长期 ADR；docs/agent/context-retention.md 与 handovers 负责 Agent 续接。

合约与安全语义

contracts/*.schema.json 是跨层协议源头；Rust 和 TypeScript 类型都从这里收敛。
UserIntent 把用户表达结构化，避免 UI 直接构造设备写入。
ActionProposal、ActionResult、ActionLogEntry 定义提案、执行结果和审计链路。
AgentMemoryRecord 与 ProactiveTickResult 支撑长期记忆、主动轮询、习惯学习和可解释主动行为。
ActionPlan 与 ScheduledAction 分别支撑多步骤动作编排和延迟一次性动作。
AutomationPolicy 把自动执行、审批、拒绝、无动作写成显式策略，模型不能自由发挥。

工具箱与验证设施

just fmt/lint/test/typecheck 覆盖基础格式、Rust lint/test 和前端类型检查。
just contracts、check-contracts、check-boundaries 防止生成物漂移和层依赖越界。
just check-doc-context 检查文档上下文链路，避免流程说明和执行入口脱节。
just check-remote 与 just push-all 固化 GitHub remote 和分支备份要求，避免本地闭环无法交付。
just e2e、just check-all 提供跨层回归闭环。
FakeMiHomeAdapter、fake LLM endpoint、dev-mcp-host、dev-agent、dev-web、dev-real 支撑 fake 到 real 的分级验收。

流程规范与人在环外

需求级：独立分支、顶层计划、plan review、用户批准、分层 TDD、check-all。
提交级：Superpowers review、Homent pre-submit review、Conventional Commit、remote 检查、push-all、合并回 main 后再次验证。
验收级：UI 走 Browser/Chrome；设备写入走可逆真实验收；失败回 owning skill 或 homent-debug。
文档级：稳定行为、边界、合约、安全姿态或 workflow 变化必须回写到对应文档或 skill。
人的角色：审目标、审风险、审边界、审证据；具体执行交给 Agent 和工具链。

关键文件解读

文档上下文体系的三个核心文件

这几份文件处理的是 LLM 开发里最容易乱的事：下一次会话从哪里开始，哪些事实可信，经验放到哪里，哪些内容不能写进长期文档。它们会参与 Agent 执行流程，不只是面向读者的说明文档。

`.agents/skills/homent-doc-context/SKILL.md`

定位：Homent 非平凡任务的本地 skill 入口，负责把“先理解上下文再动手”变成固定动作。
启动规则：要求先读取 AGENTS.md、docs/README.md，再按任务类型选择对应 owning skill 和相关设计文档。
路由职责：判断本次任务属于需求、调试、合约、Core、MCP、Agent Runtime、Web UI、审查还是文档维护，并把 Agent 带到正确上下文。
沉淀规则：实施计划进入 plans/，长期架构决定进入 docs/decisions/，未完成上下文进入 handover，可复用操作规程进入 skill。
安全约束：明确禁止把凭据、原始本地设备信息、完整运行日志、对话全文和构建产物写入长期文档。
作用：它像开发前置检查器，让每次 Codex 会话都从仓库里的稳定事实开始。

`docs/README.md`

定位：整个文档树的路由表，告诉 Agent 面对不同问题应该先读什么、改什么、不要全量扫什么。
系统事实入口：系统目标读 SYSTEM.md，架构和层边界读 ARCHITECTURE.md，跨层模型语义读 CONTRACTS.md。
模块路由：Core、MCP、Agent Runtime、Web UI、LLM 决策、主动轮询、记忆、审计和真实设备验收都有对应文档或 README 入口。
变更路由：行为、边界、合约、安全姿态、workflow 或长期决策变化时，必须写回对应根文档、ADR、plan、handover 或 skill。
作用：它减少上下文加载成本，也避免多个文档各说各话。技术分享里可以把它理解为工程知识库索引层。

`docs/agent/context-retention.md`

定位：Agent 上下文保留协议，定义什么时候需要保留执行上下文、保留到哪里、保留到什么粒度。
任务开始：要求确认需求类型、相关文档、已有 plan/ADR/handover，并避免在缺少上下文时直接改代码。
执行期间：如果发现新的边界、合约、安全、验收或 workflow 事实，需要判断它是临时执行状态还是长期系统事实。
结束检查：最终输出前做 retention checkpoint，确认是否需要更新计划、ADR、handover、根文档或 skill。
恢复能力：未完成工作要写进 handover 和 plan，让下一个 Agent 能接上风险、状态和验证证据。
作用：它把“自迭代”限制在经过验证的工程事实上，避免把短期猜测写成长期规则。

配套审查与验证文件

AGENTS.md：把四层架构、层边界、测试命令、交付流程和完成标准放在仓库入口，约束所有 Agent 工作。
.agents/skills/homent-review/SKILL.md：定义 Plan Review 与提交前审查，重点看边界、合约、设备写入安全、测试证据和文档沉淀。
justfile：把分散命令收敛成 fmt、lint、test、typecheck、contracts、e2e 和 check-all。
scripts/check-doc-context.sh：验证文档路由、上下文保留规范和本地 skills 的引用没有断链。
scripts/check-boundaries.sh 与 scripts/check-contracts-clean.sh：分别检查层依赖是否越界、合约生成物是否和 schema 源头保持一致。
配合方式：前三个文件说明怎么理解和沉淀上下文，这些审查文件验证流程仍然可执行。

文档自迭代

做完的经验，要回到下一次能读到的地方

这里不长期保存聊天记录。能留下来的只有验证过的工程事实：根文档放系统事实，plans 放执行状态，ADR 放长期决策，skills 放可复用操作规程。

LLM 自闭环开发流程

人在环外：人管目标和验收，Agent 管执行闭环

这里说的“人在环外”只针对开发执行。人不逐步指挥每个实现动作，主要审查计划、边界和验收证据。设备安全层面仍然保留人工审批和审计。

跨模块需求实现流程

从合约到真实设备验收的完整闭环

单模块需求实现流程

模块内红绿闭环与边界回归

问题修复实现流程

从复现到防线沉淀的修复闭环

迭代进程、现状与未来

从仓库初始化到当前 main：feature plan 与 bugfix 时间轴

时间轴按当前 git 历史和 plans/0001-0017 整理。能看出系统如何从初始化、fake 闭环、真实米家、四层架构， LLM 决策核心、记忆/主动 Agent，一路迭代到 delayed one-shot、动作计划、舒适偏好、习惯学习、记忆维护和 MiHome 动作扩展。

当前现状

main 已包含 plans/0011-0017 的第一版能力：记忆进入 LLM planning、延迟一次性动作、多步骤动作计划、舒适偏好、习惯学习、记忆生命周期维护和扩展 MiHome actions。
Web UI 到设备写入路径已落地：Web UI -> Agent Server -> Agent Runtime -> MCP Client -> MCP Server -> CoreAdapter。
Agent Server 正常启动默认使用 OpenAI-compatible LLM planner，无 API key 时启动失败而不是静默降级。
LLM planner 使用 prompt-scoped alias 脱敏实体，并接收相关记忆、HomeContext、近期事件和 proactive 输入。
后台 proactive polling 默认关闭，可通过环境变量或 Agent API 配置开启；手动 tick、到期 scheduled action 与 planner-driven proactive work 都走同一 Runtime 策略。
ActionPlan 已支持审批后顺序执行并逐步审计，但当前没有事务或自动回滚语义；多步骤计划不会自动执行。
ScheduledAction 已支持简单相对时间 power 请求、持久化队列、到期执行、审批恢复、列表和取消；复杂时间表达、非 power 调度和过期策略仍是后续范围。
Fake device 与 fake LLM E2E 覆盖跨层行为；真实米家 adapter 负责 discovery、read、write、event normalization 和刷新后状态校验。
MiHome 可控动作从 power/brightness/temperature/mode 扩展到 color temperature、target humidity、fan level、curtain position，但仍要求 contract 与 capability 支撑。
真实设备验收曾在 2026-05-28 使用 米家智能显示器挂灯1S 验证 set_power false -> true -> false 并恢复初始状态。
2026-05-29 对 set_color_temperature 做过真实路径验收：云端 set 返回成功但刷新状态未变化，CoreAdapter 正确判定失败，说明成功条件仍以观测状态为准。
交付流程已经补上 remote 检查和 push-all。通过本地检查还不够，分支也要能同步到项目远端。

未来方向

真实设备能力还会继续补，但仍走 contract-first、CoreAdapter 映射、刷新后状态验证和 E2E，不开放裸 MIoT 动作通道。
AutomationPolicy 还需要更细的时间条件、场景条件、来源可信度、风险解释和用户可配置规则。主动轮询要默认开启，也得先补观测和控制面。
记忆治理还比较基础，后面要补语义总结、冲突处理 UI、生命周期筛选、可编辑修正和学习规则视图。
ActionPlan 现在是顺序审批执行。下一步可以做场景模板、部分失败恢复和显式补偿策略；安全模型没定清楚前，不说事务回滚。
ScheduledAction 现在覆盖简单相对时间 power 请求。后面再扩自然时间解析、非 power 动作、过期策略、修改能力和重复任务，仍然放在 Runtime 队列里处理。
主动 Agent 可以从低风险单动作扩展到跨设备协同，但多步骤计划仍要保留审批、审计和失败解释。
开发流程也会继续沉淀到 docs、skills、scripts 和自动校验里。能规则化的经验，尽量落到文档或检查命令里。

技术总结

这套设计的重点很直接：把 LLM 的不确定性放进确定的工程边界里。模型负责理解和建议，合约负责语义，Runtime 负责策略， MCP 负责写入边界，CoreAdapter 负责真实设备协议，测试和审计负责证明系统按设计运行。

这份分享可以收束到两件事：一条是 Agent 控制真实家居的运行链路，另一条是用 LLM Agent 开发复杂系统的工程方法。

资料依据

本文基于当前仓库事实整理：SYSTEM.md、ARCHITECTURE.md、CONTRACTS.md、 README.md、docs/README.md、docs/agent/context-retention.md、 plans/0004-four-layer-runtime-flow.md、plans/0006-llm-agent-decision-core.md、 plans/0007-natural-memory-proactive-agent.md、plans/0008-webui-agent-optimization.md、 plans/0010-webui-ai-native-redesign.md、plans/0011-agent-memory-proactive-llm.md、 plans/0012-agent-multi-action-orchestration.md、plans/0013-expanded-mihome-actions.md、 plans/0014-delayed-one-shot-actions.md、plans/0015-contextual-comfort-preferences.md、 plans/0016-habit-learning.md、plans/0017-memory-lifecycle-maintenance.md、 docs/agent/intelligence-status.md、docs/decisions/*、各 crate/App README、E2E 测试与 justfile。开发流程部分还参考了 .agents/skills/*、Superpowers 流程技能、AGENTS.md 中的交付规范，以及 scripts/check-doc-context.sh、scripts/check-boundaries.sh、scripts/check-contracts-clean.sh 等验证脚本。