Kriki Coach AGENT DESIGN
Kriki Agent / User-side Operating Blueprint

不是陪你聊天，
而是和你共同维护今天。

Kriki Agent 把身体状态、今日意愿和现实约束，转化为一份可执行的今日计划；在用户看见的每个结果背后，它持续完成感知、组装 Context、决策、执行、回读与学习。

10 秒晨间意愿后台运行可追踪持续计划状态现实变化即重排次日结果验证
打开 Agent 后台 ↓先看 Agent 原理 →
Kriki is active07:06 · TODAY
MORNING DECISION

今天状态不错，可以正常推进，但不需要全力冲刺。

你昨晚睡得很好，恢复良好。结合下午的连续会议，我把训练安排在 18:10，并保留一些余量。

今天想训练中等强度即可
工作较忙15:00–18:00 会议
感觉不错主观状态已确认
Today · Running PlanCONFIRMED
优先完成高认知工作进行中
步行 15 分钟，保持下午精力
中等强度训练 35 分钟
开始恢复流程，23:10 前上床
01 / North Star

替用户完成从“知道”到“怎么做”的 0→1。

用户不是把生活交给 Kriki 管理，而是向 Kriki 索要一份有专业依据的行动底稿。计划服务于用户，决定权始终属于用户。

USER JOB

“给我一份今天怎么过的参考方案。”

用户不想先读完睡眠、HRV、负荷和趋势，再自行完成判断与规划。他需要先有一个可参考、可修改的起点。

→
AGENT RESPONSIBILITY

“我先替你形成方案，再与你确认现实。”

Kriki 给出专业默认值；用户可以接受、协商、忽略。任何偏离都只会触发重新规划，不会被定义为失败。

身体状态+今日意愿+现实约束→持续运行的今日计划
02 / Inside The Agent

用户只看到一句话，Agent 已经完成了一串工作。

用同一场景的前台与后台双视角，理解 Kriki 如何从触发开始，经过算法、Context、决策和 Runtime，最终改变真实计划。

USER VIEW07:05
MORNING CHECK-IN

“今天想训练，下午会比较忙。”

用户只花十秒确认意愿和现实。Kriki 随后直接给出一份可以采用或调整的今日方案。

接受今日计划18:10 中等强度训练 35 分钟
改一下调整时间、强度或固定事项
为什么这样安排展开依据、数据质量和边界
AGENT TRACE / MORNING_PLAN

后台正在发生什么

TARGET < 2.0s
01
触发引擎TRIGGER
检测新睡眠数据基本完整，用户打开晨间会话。
event: morning_ready
Run / #A214
02
状态算法HEALTH PIPELINE
睡眠、HRV、静息心率、近期负荷相对个人基线计算恢复与可用能力。
recovery 78 · confidence .86
BodyState
03
Context BuilderRETRIEVE + SELECT
只召回当次决策需要的目标、偏好、今日意愿、会议约束和历史有效策略。
12 facts selected / 3 sources
DecisionContext
04
教练决策POLICY + MODEL
比较理想方案与现实可执行方案，生成主方案、替代方案、风险边界和下一判断点。
goal: perform_without_overreach
DecisionPacket
05
计划写入STATE SERVICE
创建结构化 Running Plan，保存版本、固定事项、动作依赖和重排条件。
plan v1 · next_check 17:45
WRITE / Plan
06
沟通与执行RUNTIME
生成用户可读表达，同步 App 与 Watch，并安排训练前检查，而不是只返回一段文本。
render + schedule + observe
3 Actions
USER VIEW16:42
REALITY CHANGED

“今晚临时要加班，跑不了了。”

用户不需要回到计划编辑器，也不会收到责备。Kriki 从用户现在的位置重新规划今天剩余部分。

新计划已准备取消训练，切换为恢复日
今晚仍想简单活动生成 8 分钟低负荷替代动作
保持原计划用户仍拥有最终决定权
AGENT TRACE / PLAN_RECONCILIATION

一句话如何改变真实系统

PLAN v3 → v4
01
意图理解NLU / LLM
将自然语言拆成可计算约束：训练不可执行、工作负荷增加、结束时间未知。
constraint.add(work_overtime)
StateDiff
02
计划冲突检查RULE ENGINE
定位受影响动作、依赖和提醒，判断原计划已失效但长期目标未改变。
conflict: workout@18:10
ConflictSet
03
重新决策POLICY + MODEL
根据剩余时间与今日负荷，比较取消、移动和降级三条路线，选择恢复日方案。
route: cancel_and_recover
DecisionPacket
04
原子化更新PLAN SERVICE
生成新版本，并保证所有触点同时读取 v4，避免页面与提醒状态不一致。
commit plan:v4
WRITE / Plan
05
工具执行TOOL ADAPTERS
撤销训练提醒、更新 Watch 下一步、设置加班结束后的轻确认。
cancel · update · schedule
3 Tool Calls
06
等待观察RUNTIME
不立即宣称成功；等待工作结束、活动负荷与睡眠结果，形成下一次 Observation。
await: end_of_day
Pending
USER VIEW次日 07:08
RESULT VALIDATION

“昨天少练是合适的，今天恢复回到了正常范围。”

用户看到的不是一份数据日报，而是昨天的选择与今天结果之间谨慎、可理解的连接。

继续今天的计划恢复正常负荷，但仍保留余量
查看验证依据预测、执行和实际结果的对照
这次不准确用户纠正会进入反思流程
AGENT TRACE / OUTCOME_REVIEW

Agent 如何学习，而不是随便记住

LEDGER / #I083
01
结果回读OBSERVATION
读取实际活动、睡眠、次日恢复和用户主观感受，区分数据缺失与真实未执行。
actual_load 42 · recovery +9
Outcome
02
干预对账LEDGER
把当时状态、建议、预期结果、用户选择和实际结果放在同一条记录中比较。
prediction_error: low
Intervention
03
归因约束CAUSAL GUARD
检查压力、饮酒、疾病和睡眠等混杂因素，只允许概率表达，不把一次相关性说成因果。
claim: possible_contribution
SafeClaim
04
记忆门控MEMORY POLICY
单次事件只留在干预账本；重复出现且置信度足够后，才升级为个人模式记忆。
pattern_count 4 / threshold 3
WRITE / Pattern
05
策略更新PERSONAL MODEL
提升“高压工作日主动降训练负荷”策略的个人先验，但保留用户意愿优先级。
strategy_weight +0.12
UPDATE / Prior
06
进入下一循环AGENT LOOP
新的个人规律进入今天的 Context，但只占有限权重，继续由当下状态与现实决定。
next: morning_plan
Loop Continues
算法不是 LLM恢复、负荷和基线偏移优先由可验证算法计算。
Context 不是全量历史只选择本次决策真正需要的事实与记忆。
回答不等于执行计划、提醒和 Watch 必须由 Runtime 真实写入。
一次结果不等于规律干预账本先记录，多次验证后才进入长期记忆。
03 / One Day Loop

Agent 的主产品，是一份会随一天变化的计划。

用户只需要在早晨交代意愿，在现实发生变化时说一句话；读取、判断、生成、更新和跟踪尽量由 Kriki 完成。

醒来前

Kriki 完成初步状态判断

读取昨夜睡眠、恢复信号、近期负荷和个人基线，形成“今天能承受什么”的初步边界。

后台准备 · 不打扰用户，不先展示一堆数据。
07:05

用户用 10 秒提交今日意愿

今天要不要训练？是否有特殊安排？主观感觉如何？也可以直接说：“下午三个会，晚上想跑步。”

iPhone · 选择题优先，自然语言补充。
07:06

Agent 生成并确认今日计划

给出今日策略、行动时间、强度边界、避免事项和备选方案。用户接受或修改后，形成 Running Plan。

iPhone · 先看结论和动作，依据按需展开。
白天

在真正影响决策的时刻介入

训练前、负荷超预期、疲劳上升或恢复窗口临近时，Kriki 只给当下最相关的判断与动作。

Watch / 通知 · 当前一步，而不是完整报告。
变化时

现实改变，计划立即重排

“今晚要加班”“比早上更累”“训练取消了”。这句话会更新计划、提醒和后续动作，而不是只得到聊天回复。

对话 / 快捷操作 · 改变真实计划状态。
睡前

轻量收束今天

自动读取已完成事项，只询问数据无法知道的感受与现实事件，再给一个简短的恢复收尾动作。

iPhone / Watch · 1 次确认，不做作业式复盘。
次日

连接建议与结果，继续学习

判断昨天的计划是否适合、预测是否接近结果，以及类似情形下下次应怎样做得更好。

晨间计划 · 概率表达，多次验证，不冒充因果。
04 / User-facing Modes

同一个 Agent，在一天里承担四种教练角色。

不是四个功能模块，而是同一份计划在不同情境下的四种工作方式。切换下面的模式查看。

MODE / MORNING PLANNER

先给默认方案，再让用户协商。

Agent 读取身体状态，并通过少量问题补足今日意愿和特殊安排，生成一份可以直接参考的计划。

触发新睡眠完成，用户晨间打开。
关键输入恢复、近期负荷、今日训练意愿、特殊安排、主观感受。
产品输出今日策略 + 时间化动作 + 强度边界 + 备选方案。
WHAT USER GETS
“今天可以正常训练。我建议 18:10 做 35 分钟中等强度，结束后不再追加负荷。”

用户可以：接受 · 改一下 · 为什么 · 告诉你变化

MODE / LIVE COACH

只在此刻需要决策时出现。

Agent 不持续刷存在感。它比较计划与真实状态，只在一个动作会改变结果时介入。

触发训练临近、负荷异常、疲劳变化、恢复窗口到来。
关键输入Running Plan、当前时刻、已完成负荷、新观察。
产品输出现在做什么、做到什么程度、何时重新判断。
WHAT USER GETS
“今天的负荷已经够了。原定训练改为 20 分钟轻松步行，我会在晚间再看恢复情况。”

Watch 上只显示当下动作；完整依据留在 iPhone。

MODE / REPLANNER

用户偏离后，继续规划通往目标的路线。

一句现实变化不是聊天素材，而是结构化状态更新。Agent 随即修改计划、提醒和后续策略。

触发用户主动说明变化，或系统发现计划已不可执行。
关键输入变化事实、固定事项、可让步事项、当前负荷。
产品输出取消、移动、降级或替换动作，并说明影响。
WHAT USER GETS
“今晚要加班，训练取消。今天改为恢复日；22:50 后不再安排额外任务，明早重新判断。”

不评判、不劝返，基于用户当前位置继续规划。

MODE / REVIEWER

Coach 也要对自己的建议负责。

Agent 比较判断、建议、执行和结果，区分一次性事件与稳定规律，决定哪些内容值得学习。

触发日终轻反馈、次日新数据、周度复盘。
关键输入干预账本、真实执行、主观感受、次日状态。
产品输出建议是否适配、预测偏差、需要更新的个人规律。
WHAT USER GETS
“过去 4 次类似高压工作日，取消高强度训练后，你第二天的恢复通常更稳。”

多次验证后再形成模式，不把单次相关性说成因果。

05 / State, Not Chat

对话不是产品本体，计划状态才是。

真正的 Agent 不能只在聊天里口头答应。用户输入必须改变 Running Plan、提醒和下一次判断所使用的 Context。

01 / UTTERANCE

用户说

“今晚要加班，跑不了了。”

02 / INTERPRET

识别变化

训练不可执行；工作负荷上升；睡眠窗口可能后移。

03 / UPDATE

更新计划状态

取消训练，替换恢复动作，重新计算晚间边界。

04 / EXECUTE

改变真实触点

撤销训练提醒，更新 Watch 下一步，新增睡前提醒。

05 / OBSERVE

之后回读

工作结束时间、实际负荷、睡眠与次日恢复。

原计划 · 18:1035 分钟中等强度训练
22:40 开始睡前恢复流程
→
新计划 · 已确认训练取消，晚间只保留 8 分钟放松
23:20 触发“直接收尾”模式
06 / Proactive Intervention

主动，不等于多说；只在会改变选择时出现。

介入由“触发条件 + 价值判断 + 合适触点 + 用户偏好”共同决定。没有明确行动价值，就保持安静。

关键时刻触发条件优先触点用户看到什么Agent 后台动作可执行动作边界
晨间计划新睡眠基本完整 + 用户醒来APP状态判断 + 今日意愿确认状态算法 → Context 组装 → 创建 Plan v1接受、调整、查看依据数据不完整时标记初步判断
训练前训练临近，当前状态与晨间不同WATCHAPP是否练、练什么、做到什么程度回读当前负荷 → 边界规则 → 必要时重排开始、降级、改时间、取消异常症状优先停止并提示就医
负荷超预期实际活动明显超过计划边界WATCHNOTICE剩余负荷建议阈值触发 → 计算剩余容量 → 更新后续动作取消后续动作、切换恢复不以惩罚或焦虑驱动
计划失效错过动作或用户告知现实变化CHATAPP新的可执行路线解析约束 → 冲突检查 → Plan 原子化换版确认新计划不要求用户回到原路线
恢复窗口临近建议上床时间且当天负荷偏高WATCHNOTICE一个明确收尾动作检查提醒策略、静默偏好与今天实际结束时间开始、延后、今晚忽略遵守提醒频率与静默偏好
异常风险多源指标显著偏离或用户报告不适APP不确定性、风险和下一步安全规则优先 → 限制模型输出 → 医疗升级路径停止训练、观察、寻求医疗帮助不诊断，不用确定性口吻
07 / Running Plan

计划不是一段建议，而是 Agent 持续维护的对象。

所有触点都从同一份计划状态读取，避免 App 说训练取消了、Watch 却还在提醒的系统割裂。

PLAN / 2026-07-19 / V3

保持输出，不再累积疲劳

基于恢复 78%、今日训练意愿和下午连续会议。

固定事项15:00–18:00 连续会议
当前动作高认知工作，12:00 前完成
训练18:10 · 中等强度 · 35 分钟
边界热身心率明显偏高时降为 20 分钟
备选若会议延长，取消训练并切换恢复日
下次判断17:45 · 训练前确认
01

今日策略

用一句话定义今天身体资源应该怎样分配。

02

时间化动作

Now / Next / Later / Tonight，而不是一串无优先级建议。

03

固定与弹性

区分不可改变的现实、可移动的动作和可以放弃的动作。

04

决策边界

明确什么变化会触发降级、取消或再次询问用户。

05

版本与依据

记录为什么修改、由谁确认，所有触点读取同一版本。

Draft系统已生成，尚未给用户
Proposed方案已展示，等待协商
Confirmed用户确认当前版本
Active触点开始按计划运行
Replanned现实变化后产生新版本
Completed当天已结束，等待结果
Evaluated写入干预账本并决定是否学习
08 / Decision Packet

Agent 每次不是“生成一句建议”，而是产出一份可执行决策包。

决策包把输入证据、目标、约束、方案、动作、置信度和下一观察点结构化，语言只是它面向用户的一种渲染结果。

DecisionPacket / MorningPlanTRACE #A214
triggermorning_ready
body_staterecovery: 0.78 · sleep: 89 · confidence: 0.86
goalmaintain_performance_without_fatigue_debt
constraintsmeetings 15:00–18:00 · wants_training: true
primary_planwork_focus → walk_15m → workout_35m → sleep_23:10
fallbackmeeting_overrun → cancel_workout → recovery_mode
guardrailwarmup_hr_high → reduce_to_20m
actionsplan.write · watch.update · reminder.schedule
next_observe17:45 workout_precheck
健康算法

处理 HealthKit 原始样本、数据质量、个人基线、恢复与负荷特征。

DETERMINISTIC
规则与策略

处理安全边界、强约束、医疗升级、计划冲突和停止条件。

POLICY
推理模型 / LLM

理解用户表达、权衡多目标、生成候选方案、解释依据和参与协商。

REASONING
Agent Runtime

维护 Context 与 State，校验决策包，调用工具、写入计划并回读真实结果。

EXECUTION
记忆系统

保存事实、阶段、工作上下文和干预账本，并通过门控决定何时形成长期模式。

LEARNING
09 / Trust & Sovereignty

专业判断要明确，用户主权也要明确。

Kriki 的可信不是来自强势语气，而是判断有依据、边界可见、操作可撤回、长期分寸一致。

CONTROL / 01

结论可解释

先给结论，用户需要时一层展开关键依据与数据质量。

CONTROL / 02

置信度可见

区分确认事实、模型推断和仍需验证的假设。

CONTROL / 03

自由修改

接受、调整、忽略都不会失去服务，拒绝不是失败。

CONTROL / 04

不责怪用户

现实变化后重新规划，不制造羞耻、焦虑或控制感。

CONTROL / 05

医疗边界

异常信号只做风险提示和升级建议，不替代诊断。

10 / Necessary Framework

底层框架只为一件事：让用户侧闭环真实、连续、可信。

大模型负责理解与推理；Runtime 负责状态、工具、权限、执行、回读和停止条件。每一层都必须能映射到用户价值。

01 / SENSE

感知

健康数据、用户表达、计划执行和环境变化。

02 / CONTEXT

上下文

为当前决策提取必要状态、目标、现实与历史。

03 / DECIDE

教练决策

主方案、替代方案、风险边界、置信度和介入时机。

04 / PLAN STATE

计划状态

结构化 Running Plan、版本、依赖、触发和下一判断点。

05 / ACT

执行

更新计划、提醒和 Watch 触点，必要时向用户确认。

06 / OBSERVE

回读

检查用户行为、工具结果和真实身体状态是否变化。

07 / LEARN

学习

更新个人模式、有效策略与协作偏好。

稳定档案目标、限制、基础偏好和已确认事实。
阶段状态近期目标、睡眠债、训练阶段和压力周期。
工作记忆今日意愿、临时安排、当前计划和对话状态。
干预账本当时判断、给出建议、用户选择、实际结果与偏差。
Data & Feature LayerHealthKit 同步、去重、数据完整度、个人基线与身体特征。OUTPUT / BodyState
Context & Memory按当前任务召回目标、现实、偏好、计划状态和历史证据。OUTPUT / DecisionContext
Decision Engine算法、规则与模型共同形成主方案、替代方案和风险边界。OUTPUT / DecisionPacket
Plan & Tool Runtime计划版本、提醒、Watch 触点、幂等执行、失败重试与真实回读。OUTPUT / Actions + Observation
Trust Harness置信度、权限、医疗边界、Trace、审计、预算与安全停止。OUTPUT / Governed Run
11 / MVP Boundary

第一版只证明：用户愿意每天向 Kriki 要一份计划。

先把计划的具体性、低输入成本、现实重排和结果反馈做成闭环，再扩展更多设备、连接器与长期目标。

MVP 必须成立

读取 Apple Health 核心恢复与负荷数据
10 秒内完成晨间意愿提交
生成具体、时间化、可修改的今日计划
用户一句话即可触发计划重排
App、Watch 与通知读取同一计划状态
日终轻反馈与次日结果验证
完整记录每次干预与实际结果

首版暂不追求

自动接管用户完整日历和工作安排
复杂 MCP 连接器与生活服务自动执行
多 Agent 编排与角色化协作
疾病诊断或确定性健康预测
一次覆盖所有目标与所有穿戴设备
计划请求率用户是否每天回来获取计划
确认 / 修改率计划是否值得用户参与
行动参考率是否至少参考一项建议
重排使用率现实变化时是否想到 Kriki
缺失感2–4 周后，没有 Kriki 是否会慌
ONE-SCREEN DEFINITION

当计划作为真实状态持续存在，用户输入能改变它，系统触点会同步执行它，结果又会反过来修正下一次决策，Kriki 才真正成为 Agent。

有目标今天的身体资源如何分配。
有状态计划知道自己进行到哪里。
有行动改变真实计划与触点。
有观察用实际结果继续决定。