一句话里藏着五个动作
先看这个举例的请求：用户说，“把昨天跑步里动作最差的三个片段找出来，再用数字人演示正确动作。”
如果是普通的问答系统，它可能回复几句泛泛的跑步建议。但用户真正的要求包括：
- 读取训练：找到昨天那次跑步的视频或传感器记录。
- 分析动作：对整段记录做姿态与步态分析。
- 找片段：按“动作最差”的标准排序，取出三个片段。
- 生成解释：说明每个片段问题在哪里。
- 调用数字人：让数字人演示与用户动作不同的部分。
这五步里，每一步都要用工具，而且后一步依赖前一步的结果。让系统把它们连起来自己办完，就是我们所说的体育Agent。
Agent 的骨架：规划、工具与记录
一个可靠的Agent，大致由三部分构成：
- 规划：把用户的话拆成一串步骤，并且可以根据中间结果调整。
- 工具：每一步对应一个明确的工具，比如“读取训练记录”“姿态分析”“片段筛选”“数字人演示”。工具有清楚的输入输出，返回结构化结果。
- 记录：每一步做了什么、用了什么数据、得到什么结果，都要留痕，用户可以回看。
在这里，语言模型主要承担规划与表达，真正看视频、算角度的仍然是专门的姿态与分析模块。这一点与多模型协作的分工原则一致：Agent只是调度者，不应该替代专业模块。
“最差”是怎么判断的
用户说“动作最差”，看似简单，实际上需要澄清标准。Agent不应该自己悄悄定义。可行的做法是：
- 使用一个明确的评分规则，比如结合动作偏离程度、连续出现的次数与安全相关性，并在结果里说明依据。
- 对关键点置信度低的片段降低排序权重，避免因为画面被遮挡而把“看不清”当成“做得差”。
- 结果同时给出原片段和标注，便于用户核对。
关于动作分析如何区分“标准动作”和“对这个人可行的动作”，可以参考数字教练为什么需要3D动作模型。
再看一遍：这个请求怎样被拆成工具调用
把上面的五个动作对应到工具上，可以得到一条示意的调用链。名称仅为举例：
- `读取训练记录`：输入日期与运动类型“跑步”，输出该次训练的视频与传感器摘要。如果昨天有两次跑步，Agent应当先问“是早上那次还是晚上那次”，而不是随便选一个。
- `姿态与步态分析`：对整段记录逐段给出关键点、步频节奏、左右对称等结构化结果，并附带置信度。
- `片段筛选`：按事先说明的规则给各片段打分，取出排名靠前的三个，剔除置信度过低的画面。
- `生成解释`：语言模型读取结构化结果，写出每个片段的一句话说明，数字必须来自上一步的输出。
- `数字人演示`：只演示用户动作与参考动作有差异的部分，并注明这是示意性的对比演示。
每个工具都返回结构化结果，规划模块根据结果决定是继续、追问用户还是终止。如果第2步发现整段视频里人物大部分时间被遮挡，规划模块就不应该继续往下走，而应该回到用户那里说明情况。
与普通聊天助手的区别，落在哪些地方
有人会问，这和给聊天助手接几个插件有什么不同。区别主要体现在四个地方：
- 有状态：Agent知道自己已经做了哪几步、还差哪几步，而不是每次回答都从头开始。
- 有边界：它清楚哪些数据可以读、哪些操作要确认，权限是设计的一部分，而不是事后补的。
- 有核对：每个结论都能追溯到工具输出，用户可以点开原片段验证。
- 有退路：失败时知道退回哪里、告诉用户什么，而不是自行编一个完整的答案。
这些特点听上去朴素，但它们恰恰决定了Agent值不值得信任。
权限与确认：哪些事要先问
Agent与问答系统最大的不同，是它会去读数据、调用功能。所以权限设计要放在能力设计之前。
我们倾向于把动作分成三类：
| 类别 | 例子 | 处理方式 |
|---|---|---|
| 只读 | 读取已授权的训练记录、分析已有片段 | 在授权范围内自动进行，并留痕 |
| 可撤销 | 生成一个演示草稿、创建训练提醒 | 可自动完成，但用户能一键撤销 |
| 不可撤销或影响较大 | 删除记录、分享训练视频、修改训练计划 | 必须先展示内容并等待用户确认 |
另外几条规则也很重要：
- 按需授权：摄像头、蓝牙、身体数据的权限，在真正用到时再请求，不要在一开始一次性要完。
- 最小化：Agent只能读取完成当前任务所需要的数据。
- 可见可改：用户能看到Agent保存了什么，也能删除。
产品层面如何避免一开始就要一堆权限，可以参考第一次使用时为什么先问看比赛还是做训练。
失败与回退：不悄悄跳过
多步任务里，每一步都有可能失败。比如昨天那次跑步的视频质量太差、传感器数据缺了一半、数字人演示资源没有加载成功。合理的处理方式是：
- 如实说明：告诉用户哪一步没有完成，以及原因，而不是悄悄跳过后给出一份看起来完整的结果。
- 给出替代方案：视频质量差，就改用传感器数据做粗略分析，并明确标注精度有限。
- 不编造：找不到足够的片段时，只列出能确认的，不凑数。
- 可中断可续做：用户可以中途停下，或者从失败的那一步继续。
在这个例子里，如果只找出了两个置信度足够的片段，Agent应当说“只找到两个可以确认的片段”，而不是勉强凑出第三个。
主动执行的边界
“主动执行”听起来很吸引人，但体育场景里有几条明确的边界：
- 不替用户决定训练强度。Agent可以提醒、准备、建议，但是否加量、是否继续，由用户决定。
- 不在身体不适时推进计划。出现疼痛、头晕等情况时，正确的做法是停止训练，必要时咨询专业医生，这不是Agent应该去优化的问题。
- 不做诊断。心率、HRV和恢复读数只是运动表现参考，不构成医疗判断。
- 不越权采集。没有授权就不启动摄像头，不读取与任务无关的数据。
评估一个体育Agent，可以看什么
Agent的好坏不能只看回答顺不顺，而要看过程。一份朴素的检查清单如下：
- 任务被拆成了哪些步骤，用户能否在界面上看到？
- 每个结论是否能点回具体的训练片段或数据来源？
- 请求含糊时（比如“昨天”有两次训练），它是追问还是自作主张？
- 遇到失败时，它是如实说明并给出替代，还是悄悄补全？
- 涉及分享、删除、改计划这类操作时，是否等待了明确确认？
这几条都与模型的聪明程度关系不大，更多取决于产品与系统设计。
小结
从回答问题走向执行任务，意味着系统要会规划、会调用工具，也要会申请权限、承认失败并留下记录。数字体育Agent的价值不在于替用户做决定，而在于把繁琐的读取、分析与整理工作办完，再把判断权留给用户。这是一个值得认真研究的方向，也是需要谨慎推进的方向。
