Livis Agent 任务大师

理想汽车的车机「任务大师」是一套面向智能座舱的自定义“快捷指令”。用户可以基于车辆与环境状态，按「如果……就……」预设触发规则，并自由编排语音提醒、车控调节等作为执行项。

远期完整体验将进一步打通车、手机与眼镜的能力：条件可以在一个终端被感知，动作可以在另一个终端被执行。 例如：

在这个任务中，车辆充电状态与用户离车状态共同构成触发条件，眼镜负责通知用户。这要求任务能够跨端调用状态、判断条件，并在相应终端执行动作或交付结果。

但迈向这一完整体验需要分阶段推进。由于技术栈隔离和研发资源有限，移动端 MVP 无法一次性接入车机的全部原子能力，也没有移植车机社区与分享码体系。

定时只是任务的一种触发条件。未来，条件还可以由环境、地点或设备状态触发。因此，移动端需要延续车机的基础任务模型：

这套分类用于组织任务；各端当前可调用的条件与动作，仍受实际接入能力限制。

在此基础上，我继承车机的配置组件、容器与任务卡信息结构，适配手机的屏幕尺寸、触控方式与信息密度。

共享任务模型后，各终端仍需要承担不同的工作。车机保留复杂配置与分享生态；眼镜承接当下的语音意图；手机同时提供自然语言表达、精细管理与长内容阅读。

以周期性内容任务为例，用户可以直接在 IM 中提出：

AI 解析后，在同一对话中以任务卡反馈任务名称和执行时间。用户可以就地确认系统创建了什么；之后需要调整条件、频率或状态时，再进入 App 的任务管理界面。

语音与 IM 承接任务发起，GUI 提供结构化配置与管理。这样的分工，让眼镜上的即时表达能够衔接手机上的后续控制。

任务可能在创建数小时或数天后触发。但本项目面对的 IM 架构，无法为任务结果建立独立、聚合的会话（Session），结果会随时间分散在不同会话中。

这带来两个连续的问题：用户看到一条主动消息时，如何知道它来自哪个任务？没有及时阅读的重要内容，之后去哪里找？

任务消息混排在当前活跃会话中。当一条“下午 3 点了，记得站起来拉伸放松一下哦！”出现在天气问答之后，用户可能不知道它是哪个任务触发的；出现失败或报错时，也难以回溯对应任务。

我比较了三种方式：在消息流中嵌入任务卡片、在回复操作栏提供任务入口，以及在任务消息前加入标签。判断的重点是：用户能否在开始阅读时，就知道这是一条任务消息，以及它来自哪个任务。

我选择方案 3｜任务消息前置标签。 在正文前加入「任务 · 任务标题名称」，让用户先识别任务属性与来源，再阅读执行结果。它保留了来源上下文，又避免完整任务卡占用过多内容空间；相比回复末尾的入口，来源信息也更早进入阅读视线。例如，「任务 · 站立提醒」之后直接呈现提醒正文，让任务与结果的关联在阅读开始时就明确。

这一选择需要占用原有的 COT 思考过程入口，带来一定的 IM 框架改造成本。我接受这部分改造成本，优先保证来源识别发生在阅读之前，而不是让用户读完结果后再寻找任务入口。

来源标签解决了单条消息的理解，但周期性简报仍可能埋在不同会话中。我进一步区分任务管理、结果交付与内容发现的职责：

对于“5 分钟后提醒我关火”这样的即时提醒，设计重点是及时触达；对于 AI 硬件周报这样的长内容，完整结果保留在 IM，首页提供未查收内容的发现入口。

用户从首页发现周报，再进入对应 IM 会话阅读和追问。首页承担未查收内容的发现，不等同于完整执行历史；这一方案优先解决重要内容分散、难以被发现的问题。

我完成了 App 与智能眼镜任务体验从 0 到 1 的信息架构与核心界面设计，将三项判断落实到具体交互：

• 统一任务结构：延续「如果……就……」模型、配置结构与任务卡逻辑，适配移动端当前可用能力。
• 连接创建与管理：为眼镜语音、IM 自然语言和 GUI 创建明确分工，并衔接 App 中的结构化管理。
• 区分任务与结果：用文字标签说明主动消息的来源，用首页入口帮助用户发现未查收内容。

本阶段仍受车机能力接入范围和 IM 架构限制。统一任务模型，也不意味着车机、手机与眼镜的所有任务已经进入同一个任务池；账号与设备权限、任务可见范围、完整执行历史及跨端失败兜底，仍需进一步明确。

这次项目中，我的核心判断是明确哪些结构需要统一，哪些体验需要分端适配，以及哪些问题需要在现有架构内分层解决。它使有限能力下的 MVP 能够形成具体的创建、管理与交付路径，也明确了后续跨端协同仍需补齐的边界。