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

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

一、工作进展

本阶段训练模块前端重写对 Agent 调度没有直接的功能影响——训练记录的新建、编辑、删除均由前端独立完成，不经过 Agent 对话链路。但训练模块的数据结构（plan 与 record 的区分、target_* 与 actual_* 的对比）直接塑造了 Agent 理解用户健身意图时的上下文结构。本阶段的核心工作是梳理这种影响，并为后续 Agent 介入训练记录场景做准备。

主要产出：

1. 分析训练记录数据结构对 Agent 意图理解的影响
2. 确认现有 Agent 工具集中训练子域工具的参数契约与前端新数据结构的一致性
3. 梳理 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 记录的动作名称会与动作库一致，后续汇总统计不会因动作名写法分散而出现误差。