首页
呈现今日判断、负荷范围、方案和完成进度。
从产品体验到数据源，每一层只承担一种责任
这张图用于统一当前业务责任和处理关系，不是已经确认的部署拓扑、接口或开发方案。已经确定的是 Flutter iOS 客户端承接用户行动、自研健康算法在 App 内形成正式结果、Agent 负责解释与计划且不另算健康结果；三方怎样通信和协作仍需形成正式技术架构。
产品体验→Agent 决策→健康计算→核心状态→数据源与集成
先验证通信链路，再共同确定正式技术架构
产品完善正式需求期间，Flutter、Agent 和服务器团队并行工作，但试验结果不能替代后续评审。
现有材料是参考输入当前 Demo、产品蓝图、既有 PRD 和本页帮助团队理解业务，不直接交付开发。
先跑试验性通信 Demo用固定模拟数据和 trial-v0 临时对象跑通任务发起、Context、Agent 结果与状态返回、应用展示和失败可见；临时页面、字段、Prompt 与业务规则默认不进入生产。
三方确认正式方案共同确定职责、通信对象与内容、状态归属、接口、异常处理、环境、日志和监控。
当前分层先说明业务责任，闭环说明业务流转
架构图先回答“每一层负责什么”，再单独说明“计划如何被执行、验证并影响下一次决策”。它不预先决定服务怎样部署、谁直接调用谁，以及最终使用什么接口。
五层责任参考从用户体验一路落到底层数据源。
平台与治理横切账号、权限、订阅、版本和隐私贯穿所有层。
反馈闭环独立表达执行、完成、回顾和调整不是第六层。
用户看到和操作的产品请求与动作向下 · 数据与结果向上底层事实与外部输入
LAYER 01产品体验层展示已有结果，收集用户操作，不在页面里重新计算。
本周计划
呈现周目标、优先事项、完成标准和当前进度。
今日数据
解释睡眠、恢复、负荷和数据可信程度。
Kriki 对话
解释结果、讨论变化并承接需要确认的修改。
历史与回顾
读取当时保存的计划、完成情况和回顾结论。
通知与语音
触达用户，或快速补充时间、感受和现实条件。
LAYER 02智能体决策与编排层理解任务、组织上下文、调用能力并完成可验证的写入。
AGENT RUNTIME负责决策与任务编排，不替代健康算法
只在制定、调整、回顾或沟通任务中启动；页面浏览和历史查看只读取已有结果。任务触发读取输入快照组装任务上下文调用 Skill 与工具生成结构化输出用户确认 / 正式工具写入读回验证
组装任务上下文为当前任务选择必要、有效且已授权的信息，不加载无关历史。
每项信息保留来源、对象版本、更新时间、权限范围和冲突状态；输入快照变化会使未提交任务重试、替代或过期。
任务定义与状态任务类型、触发原因、目标、当前状态、资源限制和停止条件。
健康评估快照睡眠、恢复、负荷、数据质量、个人基线和评估时间。
计划与执行状态长期指标、阶段方向、本周计划、今日方案和当前执行进度。
用户目标与现实约束长期目标、近期诉求、时间、器械、感受、伤病和临时变化。
记忆与验证证据已确认偏好、相似安排的历史结果，以及仍待确认的规律；用户本次明确输入优先于旧记忆。
能力、权限与安全边界可调用的算法、Skill 和工具，以及数据权限、风险等级和安全规则；Agent 不进行医疗诊断。
计划决策阶段方向、本周计划和今日方案。
变化处理比较影响、提出替代并保存新版本。
回顾、沟通与提醒解释并形成结论；只在有新结果、需要确认或计划变化时触达用户。
长期指标状态→阶段方向→本周计划→今日方案
LAYER 03健康计算与规则层将健康数据计算为睡眠、恢复、负荷和长期指标，并执行计划与安全规则。
健康数据接入
Flutter 复用 Fitbeing 的 Apple Health 链路，完成同步、选源、去重、时间和数据质量处理。
睡眠 / 恢复 / 负荷算法
从 Fitbeing 手表固件迁入 Flutter App，根据个人基线生成三项健康结果及完整依据。
只由 App 内自研健康算法计算长期指标模型
只按已批准、带版本的指标目录计算 Age、长期趋势、观察周期和判断可信度；当前 Demo 候选不自动进入生产。
计划与安全规则
按已批准周目标目录版本限定目标范围、运动边界、替代方式和确认条件。
完成与回顾计算
统一计算完成情况，并比较计划、执行和身体变化。
LAYER 04核心数据与状态层保存目标、计划、执行和回顾等权威状态，让页面、Agent 和服务读取同一版本。
健康数据、评估与长期指标
保存带来源和质量状态的健康数据，以及睡眠、恢复、负荷、Age 与长期趋势；评估结果绑定已批准指标目录版本、个人基线、计算窗口、算法版本和可信度。
用户目标与现实约束
保存长期目标、近期诉求、偏好、时间、器械、身体限制和用户纠正。
计划决策与版本
保存阶段方向、本周计划和今日方案；每次调整创建新版本并保留原版本。
执行账本
结算日执行事实和周累计结果，不把预计贡献提前计入完成进度。
回顾与干预验证
比较计划、实际执行和身体变化，形成日回顾、周回顾和干预验证结果。
对话、通知与长期记忆
保存消息与任务关联、通知状态，以及经过确认后可持续使用的长期信息。
LAYER 05数据源与系统集成层提供外部事实和系统事件，不参与产品决策。
Apple Health
活动、心率、睡眠等授权原始数据和来源时间。
首版由 Flutter iOS 客户端接入用户输入
目标、时间、器械、感受、完成记录、修改和纠正。
现实情况以用户主动提供为准iOS 系统事件
账号、时区、权限、通知、订阅状态、前后台和网络变化。
由系统触发，不让 Agent 猜BUSINESS FEEDBACK LOOP业务反馈闭环，不是第六层
今天的方案只有在被执行、记录并观察到后续身体变化后，才可能影响下一轮决策。
今日方案
明确做什么、做多少、边界和替代方式。
实际执行
全部完成、部分完成、替换、跳过或中止。
完成记录
设备或用户提交后，系统按统一规则计算。
回顾身体变化
比较计划、实际完成和之后的健康结果。
调整后续决策
结论为有效、无效、证据不足或继续观察。
↺回顾结果可以调整阶段方向、本周计划、今日方案和长期记忆；单日波动不会直接改写长期目标。
每类结果只能由一个系统生成
其他页面和任务可以读取、解释或申请修改，但不能另外保存一份。
| 结果或数据 | 谁负责生成 | 哪些地方会用 | 什么时候更新 |
|---|---|---|---|
| 睡眠 / 恢复 / 负荷结果含数据时间、质量、个人基线和算法版本 | 自研健康算法 | Agent、首页、今日数据、历史、回顾 | 有新数据或算法升级时重新计算；历史保留当时的结果。 |
| 长期指标状态Age、已批准指标目录及版本、趋势与可信程度 | 长期指标模型 | 阶段方向、个人方向、产品蓝图相关页面 | 根据一段时间内可比较的数据更新；一天的计划不能直接修改它。 |
| 阶段方向当前改善重点、周期和结束条件 | 阶段方向任务 | 本周计划、今日方案、首页、对话 | 重新评估后保存新版本；本周计划和今日方案不能反过来修改它。 |
| 本周计划已批准周目标目录及版本、优先级、完成规则和指标关联 | 周计划任务 | 今日方案、首页、完成记录、周回顾、对话 | 用户可以随时提出修改；确认影响后保存新版本，已经完成的记录不变。 |
| 今日方案行动、运动量、上限、停止条件和替代方式 | 日方案任务 | 首页、通知、对话、日回顾 | 用户的实际情况变化时可以调整；只改之后的行动，不改已经发生的记录。 |
| 完成记录实际完成情况、数据来源和计算规则 | 完成情况计算服务 | 首页、本周计划、日 / 周回顾、历史 | 只接受设备记录或用户主动记录；纠错时保留修改记录。 |
| 回顾结果计划是否有效，以及现有数据能否支持判断 | 日 / 周回顾任务 | 之后的计划、历史、Agent 任务 | 有新数据时更新判断，但不能为了提高完成率而修改历史记录。 |
| 长期记忆稳定偏好、实际限制和多次确认的规律 | 记忆检查任务 | 之后的 Agent 任务 | 只有用户纠正或多次可比较的结果可以加入；用户可以查看、纠正和删除。 |
正式需求和技术方案需要覆盖的三条业务流程
后续 PRD 和技术方案要分别写清楚什么时候开始、形成什么结果、怎样保存，以及失败怎么处理。
早上生成今日方案
- Apple Health 完成数据同步和质量检查。
- 自研算法计算并保存睡眠、恢复和负荷结果。
- Agent 读取当前阶段、本周进度和用户实际条件。
- 生成今天的行动、运动量、停止条件和替代方式。
- 保存今日方案并重新读取；成功后首页展示同一版本。
用户情况变化后调整计划
- 用户说明时间、身体或其他条件的变化。
- Agent 比较当前方案和可以怎样调整。
- 说明目标、完成规则、运动量和风险会怎样变化。
- 需要时让用户先确认，再保存新计划版本。
- 重新读取成功后，首页、本周计划和对话一起更新。
完成后判断计划是否有效
- 设备或用户记录实际完成情况。
- 日 / 周回顾读取当时的计划和完成记录。
- 读取之后的身体变化和实际情况变化。
- 判断结果是有效、无效、证据不足还是需要继续观察。
- 只有回顾结果或用户纠正可以影响之后的计划。
正式 PRD、技术方案和测试需要保留这些产品规则
这些是已经明确的业务边界，但具体怎样实现仍由正式技术架构和接口方案决定。
浏览页面不能启动 Agent 或重新计算
打开、返回、滚动、展开、切换日期和查看历史都只读取已经保存的结果。
Agent 不计算睡眠、恢复和负荷
健康结果、Age、权限、目标范围和完成情况都由对应的算法或服务计算。
本周计划不直接沿用上周
每周计划都由大目标和当前阶段决定；上周只能提供完成记录和身体变化，不能直接决定下周目标。
修改计划不能改掉历史记录
用户可以随时提出修改；系统说明影响并保存新版本，但已经完成的记录保持不变。
同一次完成只能计算一次
设备自动识别和用户手动记录需要去重；感受只作为之后制定计划时的参考，不能算作完成。
保存后再读一次，才算成功
Agent 说“已完成”不算成功；计划、完成记录、消息或记忆必须保存并重新读取确认。