2026年山东大学软件学院创新项目实训博客（六）

2026年山东大学软件学院创新项目实训博客六一、工作进展本阶段训练模块前端重写对 Agent 调度没有直接的功能影响——训练记录的新建、编辑、删除均由前端独立完成不经过 Agent 对话链路。但训练模块的数据结构plan 与 record 的区分、target_* 与 actual_* 的对比直接塑造了 Agent 理解用户健身意图时的上下文结构。本阶段的核心工作是梳理这种影响并为后续 Agent 介入训练记录场景做准备。主要产出分析训练记录数据结构对 Agent 意图理解的影响确认现有 Agent 工具集中训练子域工具的参数契约与前端新数据结构的一致性梳理 Agent 介入训练记录场景语音记账、计划调整建议的潜在路径二、详细内容1. Plan 与 Record 的数据结构对 Agent 语境的影响训练记录的核心结构是同一张表存储 plan 和 record 两种类型通过 record_type 字段区分plan 有 target_* 字段record 有 actual_* 字段两组字段在同一张表里但语义完全不同。从 Agent 的视角看这个结构影响它对用户输入的理解。当用户说「我刚练完卧推」时Agent 需要知道这是在创建一个 record 类型的完成记录而不是修改一个 plan。当用户说「我打算下周开始练卧推」时Agent 需要知道这应该创建一个 plan记录的是目标数字而不是实际数字。这两个场景的区分在对话中并不总是清晰的——用户可能说「练完卧推了做了四组每组八次」这里的「四组每组八次」是 actual_* 的数据还是 target_* 的数据答案是 actual_*但 Agent 需要从上下文判断用户说「练完」是一个完成标记说明这是 record 类型。如果用户说「我准备四组卧推每组八次」这里的「四组每组八次」是目标计划record_type 是 plan。这里的关键是「准备」这个动词和「练完」这个动词的区分。这种区分是 Agent 意图识别的核心工作不是本阶段前端的工作范畴但前端的数据结构设计需要为这种意图识别预留足够的语义空间。2. 训练子域工具的参数契约一致性在博客五时期训练子域工具的 Prompt 已经扩展了操作枚举包括了记录维护create/update/delete、当日查询、计划调整、动作库查询等操作。本轮前端重写引入了新的数据结构plan 和 record 的区分三种表单模式工具的参数契约需要确认与新结构一致。训练子域工具的核心参数结构与前端使用的 TrainingRecordCreate 类型基本对齐date、action_name、record_type、target_、actual_、calories、notes。这与前端 repository 层定义的类型在字段名和类型上完全一致说明前端的接入没有引入参数契约的漂移。3. Agent 介入训练记录场景的路径当前训练记录的创建和编辑完全由前端表单驱动Agent 在训练侧的介入场景暂时限于对话式录入即用户通过对话说「刚练完卧推四组八次」Agent 解析后调用训练子域工具写入。本阶段前端重写为这种对话式录入提供了更清晰的数据结构基础一是 plan 和 record 的语义边界更清晰了Agent 在解析用户意图时可以更准确地判断应该创建哪种类型的记录。二是 target_* 和 actual_* 的对比数据已经存在于后端Agent 在做训练质量复盘时可以引用这些数据比如「你计划卧推四组八次实际完成了四组六次重量还加了五公斤」这种复盘反馈是 Agent 提供训练建议的重要上下文。三是前端已经把动作名称的 AutoComplete 与动作库对齐用户在表单中选择的动作名称一定是动作库里存在的名称。这意味着 Agent 在记录动作名称时也可以引用动作库做校验避免「卧推」和「杠铃卧推」写法不一致导致的汇总问题。三、总结本阶段 Agent 侧工作的核心是为后续 Agent 介入训练场景做结构准备。三个要点Plan 和 Record 的数据结构直接影响 Agent 对用户健身意图的理解——「练完」创建 record「打算」创建 plan这两种语义的区分需要在 Prompt 层做显式规则覆盖。训练子域工具的参数契约与前端新数据结构一致没有因前端重写引入漂移。这保证了 Agent 调用工具时后端能正确接收和存储。前端动作库与表单的动作名对齐为 Agent 提供了动作名的标准化基础——Agent 记录的动作名称会与动作库一致后续汇总统计不会因动作名写法分散而出现误差。