homent-system

作者：Hyrilx

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

这不是一个单纯的智能家居面板，而是一套 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

意图-行动体系约束 Agent 边界

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 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，并生成 action result 与 action log。
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、知识库、流程规范与工具箱如何协同

这一部分是项目的另一个重点：Homent 不只是在开发一个 Agent，还把“如何让 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 源头保持一致。
协同效果：前三个文件负责“如何理解和沉淀上下文”，这些审查文件负责“如何证明流程仍然可执行”。

文档自迭代

每次实现都把经验沉淀回下一次执行上下文

Homent 的自迭代不是把聊天记录长期保存，而是把已验证的事实放进稳定位置：根文档保存系统事实，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 -> Agent Server -> Agent Runtime -> 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 规则：闭环不仅停在本地通过，还要求可回滚、可同步到项目远端。

未来方向

扩展更多真实设备和 capability，但坚持 contract-first、CoreAdapter 映射、刷新后状态验证和 e2e 保护，不引入裸 MIoT 任意动作。
增强 AutomationPolicy：时间条件、场景条件、来源可信度、风险解释、用户可配置规则，以及主动轮询默认开启前所需的可观测性。
增强记忆治理：语义总结、用户辅助冲突处理、生命周期筛选、可编辑修正和学习规则的专用可视化。
把 ActionPlan 从顺序审批执行扩展到更丰富的场景模板、部分失败恢复和显式补偿策略；在安全模型明确前不声称事务回滚。
扩展 ScheduledAction 的自然时间解析、非 power 动作、过期策略、修改能力和重复任务，但仍保持 Runtime 队列而不是浏览器或设备侧定时器。
让主动 Agent 从低风险单动作逐步扩展到更复杂的跨设备协同，同时保持多步骤计划审批、审计和可解释失败结果。
继续把开发经验沉淀进 docs、skills、scripts 和自动校验，使 LLM 开发流程本身也可复用、可审查、可迭代。

技术总结

Homent 的核心价值在于把 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 等验证脚本。