项目实训开发日志（五）：BabyMind：基于多Agent和RAAG的科学育儿辅助平台

Attachment20

215人浏览 · 2026-04-18 21:26:04

Attachment20 · 2026-04-18 21:26:04 发布

进入这一阶段后，团队的开发重点进一步从“业务数据能否录入和展示”，转向“系统能否真正具备智能问答和模块联动能力”。换句话说，前几周我们解决的是“系统里有什么数据、这些数据怎么组织”，而这一周我们更关注“系统能不能理解家长的问题、调用已有知识与数据，并输出结构化、可联动的回答”。

因此，本周我们围绕以下几个方向展开了开发：

统一问答入口设计与实现；
RAG知识库接入与检索流程搭建；
健康、时间轴、营养三类问题的多Agent路由；
问答结果与健康记录、疫苗计划、成长时间轴之间的联动；
Android端问答页面、会话历史与上下文追问能力的完善。

相比前几周主要围绕单个业务模块推进开发，这一阶段的工作更接近BabyMind项目的“智能核心”，也是我们从普通业务系统逐步走向“科学育儿辅助平台”的关键一步。

一、本周整体完成内容

1、完成统一问答入口设计与后端接口接入

本周后端最重要的工作之一，是建立统一的AI问答入口。我们没有将健康、时间轴、营养等问题拆成多个互相独立的问答接口，而是优先设计了一个统一入口，由系统在后端完成问题分流和处理。

目前已经完成：

统一问答接口 POST /api/v1/qa/ask
问题路由预览接口 POST /api/v1/qa/route-preview
问答历史列表接口
问答历史详情接口
与宝宝档案上下文绑定的问答能力
会话ID与会话标题的保存逻辑

这样做的主要目的是降低用户使用成本。对于家长来说，真实问题往往并不会严格按“健康问题”“营养问题”“时间轴问题”分开出现，而是天然带有交叉性。例如“宝宝发烧了，这周疫苗还能不能打”这样的问题，既涉及健康，也涉及疫苗安排。因此，本周我们优先完成了统一问答入口，让系统能够先接住问题，再决定应该调用哪一类处理逻辑。

这一部分能力的完成，也意味着BabyMind开始拥有一个真正面向用户的智能交互入口，而不是只有多个相互独立的业务页面。

2、完成RAG知识库接入与基础检索流程搭建

为了避免AI问答完全依赖模型“直接生成”，本周我们继续推进RAG能力的落地。当前项目已经具备本地知识资料整理、文档切分、向量化写入和检索调试等基础能力。

目前已完成的工作包括：

按健康、营养、成长发育、疫苗等方向继续整理知识文档；
统一知识库目录结构；
接入Chroma向量数据库；
实现知识文档切分与写入逻辑；
完成按问题内容进行语义检索的基础流程；
增加知识库手动入库接口与调试检索接口。

当前知识库内容主要继续围绕以下方向组织：

health
nutrition
development
vaccine

在此基础上，系统进一步把这些资料映射到健康、时间轴和营养三类问答集合中，为后续多Agent回答提供支撑。

这一部分工作的意义在于：BabyMind的问答能力开始具备“基于资料回答”的基础，而不是简单调用大模型直接输出自然语言。对于育儿健康类项目来说，这一点非常重要，因为系统后续不仅要回答得流畅，更要回答得有依据、有边界。

3、实现健康、时间轴、营养三类问题的多Agent路由

在完成统一问答入口和RAG基础接入之后，本周我们进一步推进了多Agent路由逻辑，让不同类型的问题进入不同的处理链路。

当前系统已经初步支持以下三类问答路由：

健康问题
时间轴/疫苗/成长提醒问题
营养/辅食/喂养问题

目前的路由机制主要结合问题关键词、上下文内容以及优先级进行判断。虽然这一阶段还没有引入特别复杂的自动规划机制，但已经完成了可运行的多Agent分流原型。

本周这部分工作的完成，使系统具备了以下能力：

健康类问题优先走RAG健康问答链路；
时间轴类问题能够读取提醒、疫苗计划和成长事件数据后再回答；
营养类问题能够结合宝宝月龄、喂养阶段、过敏原和饮食限制生成个性化结果；
用户也可以在前端界面中手动选择更偏向的Agent模式。

相比此前“功能模块各自独立”的状态，这一阶段的系统已经开始具备按问题类型智能分工处理的能力，也更接近项目最初设想中的多Agent协作结构。

4、推进结构化回答与业务模块联动

本周除了完成问答流程本身之外，我们更关注另一个问题：AI回答能不能继续影响系统内部的业务数据。

如果系统只是给出一段回答，然后停留在聊天页面，那么它本质上仍然只是一个普通问答工具。为了让BabyMind真正形成“智能辅助平台”的闭环，本周我们继续推进了问答结果与健康记录、疫苗计划、成长时间轴之间的联动逻辑。

当前已完成或初步实现的联动包括：

健康类问答结果可以输出结构化字段，例如核心结论、操作步骤、注意事项、风险等级、是否建议就医；
高风险健康问答可以尝试自动生成健康记录；
健康记录可以继续影响疫苗计划中的延期逻辑；
延期后的疫苗状态能够同步进入成长时间轴；
营养类问答可以结合饮食禁忌、过敏原和既有健康记录生成更贴近宝宝情况的建议。

这意味着系统内部开始出现一条更完整的数据链路：

统一问答 → 问题路由 → RAG/结构化处理 → 健康记录或营养信息提取 → 疫苗/时间轴联动

对项目整体来说，这比单纯“多了一个聊天功能”更有意义。因为项目中的不同模块终于不是并列摆放的页面，而是开始基于真实数据相互影响。

5、完善Android端问答页面与会话历史

在前端部分，本周团队同步推进了Android端问答交互页面和会话历史能力，使后端的统一问答接口能够真正被用户使用起来。

目前前端已补充或完善的能力包括：

AI问答页面；
会话历史列表页；
会话详情页；
基于当前宝宝上下文发起提问；
多轮追问时携带对话上下文；
基于 session_id 组织会话记录；
根据不同Agent类型展示不同回答内容；
自动建档成功后跳转健康记录详情。

本周前端问答页面的重点，并不是追求复杂动画或高度美化，而是先把“输入问题—获取回答—保留上下文—查看历史—继续追问”这一条交互链路跑通。这样后续无论继续补充语音输入，还是丰富结构化内容展示，都已经有了稳定的页面基础。

6、继续补充问答、RAG与联动相关测试

为了保证当前阶段开发的统一问答和联动能力不是停留在“能跑一次”的原型状态，本周后端也继续补充了部分测试和调试逻辑。

当前已覆盖或补充的方向包括：

Agent路由测试；
RAG服务相关测试；
健康问答自动建档链路测试；
营养推荐与问答结合测试；
疫苗延期与时间轴联动测试；
部分集成流程测试。

虽然当前测试还远未覆盖全部情况，但相比前几周主要集中在基础接口联调，这一阶段我们已经开始更关注“模块之间能否形成稳定业务链路”这一问题。

二、本周核心代码与模块

本周核心代码主要集中在以下几个方向：

1、统一问答与历史记录

app/api/routers/qa.py
app/schemas/qa.py
app/services/agent_router_service.py
app/models/qa_history.py

主要负责统一问答入口、问题路由、问答历史保存和会话数据组织。

2、RAG知识库与检索能力

app/services/rag_service.py
app/api/routers/knowledge_base.py
app/services/embedding_client.py
data/knowledge_base/...

主要负责知识文档读取、切分、向量入库、语义检索和调试接口。

3、健康记录联动

app/services/health_record_service.py
app/api/routers/health_records.py

主要负责从高风险健康问答结果中自动提取信息并生成健康记录，同时推动后续疫苗联动逻辑。

4、疫苗与时间轴联动

app/services/vaccine_service.py
app/services/timeline_service.py
app/api/routers/vaccines.py
app/api/routers/timeline.py

主要负责在健康记录变化后调整疫苗计划状态，并把相应结果同步进成长时间轴。

5、Android端问答交互

frontend/app/src/main/java/com/babymind/ui/screens/QAScreen.kt
frontend/app/src/main/java/com/babymind/ui/screens/QAHistoryListScreen.kt
frontend/app/src/main/java/com/babymind/ui/screens/QAHistoryDetailScreen.kt
frontend/app/src/main/java/com/babymind/ui/viewmodel/QAViewModel.kt
frontend/app/src/main/java/com/babymind/ui/viewmodel/QAHistoryViewModel.kt

主要负责问答页面、上下文追问、历史会话和结构化结果展示。

三、本周遇到的问题与解决思路

1、统一问答并不等于所有问题都走同一套处理逻辑

一开始我们也考虑过是否可以简单地把所有问题都交给同一个问答流程处理，但在实际推进时很快发现，这样做虽然实现简单，却不利于后续模块协同。

例如健康问题更依赖知识检索和风险判断，时间轴问题更依赖宝宝现有业务数据，营养问题又需要结合月龄、过敏原和饮食限制。如果全部走完全相同的处理逻辑，回答会变得非常泛化。

因此本周我们采用了“统一入口 + 后端路由分流”的方式，既保证用户交互简单，也保留不同模块独立处理问题的能力。

2、RAG不能只追求“能检索到”，还要关注回答结构

我们在继续推进RAG接入时，也越来越明确一个问题：对于BabyMind这样的育儿项目来说，检索到资料本身还不够，后续回答必须尽可能稳定、清晰、结构化。

因此本周我们继续强化了结构化输出约束，让健康类回答优先输出“核心结论、操作步骤、注意事项、风险等级”等字段，而不是只返回一整段自由文本。这样不仅便于前端渲染，也便于后续自动建档和风险联动。

3、问答结果与业务数据联动时需要谨慎处理边界

健康问答结果自动生成健康记录，看起来是一个很自然的功能，但真正实现时会遇到边界问题。例如哪些情况可以自动建档，哪些情况只适合停留在问答层面；哪些高风险字段应触发疫苗延期，哪些只作为提示保留。

因此本周我们在推进自动建档时，优先选择较明确的条件，例如高风险等级、建议就医、影响疫苗安排、影响饮食安排等，而没有一开始就让所有回答自动写入系统。

4、前端会话历史不能只保存“单条问题”

在前端问答页面推进过程中，我们也发现，如果只简单保存单条历史记录，那么用户后续查看时会觉得信息比较碎片化，不容易还原一整次咨询的过程。

因此本周我们在会话历史部分增加了 session_id 维度，让历史记录能够以“会话”为单位组织，而不是仅按单条消息堆叠。这使得BabyMind的AI交互体验更接近真实使用场景，也为后续继续追问和智能摘要打下了基础。

四、阶段性成果

经过这一阶段开发，BabyMind项目已经从前几周的“业务模块逐步成型”，进一步进入到“智能问答能力开始形成系统闭环”的阶段。

本周最重要的阶段性成果主要体现在以下几个方面：

系统已经具备统一问答入口，不同类型问题可以从同一个接口进入；
RAG知识库开始真正参与健康类问答流程；
系统初步具备健康、时间轴、营养三类问题的多Agent路由能力；
AI回答开始不再只是展示结果，而是能进一步联动健康记录、疫苗计划和成长时间轴；
Android端已经形成问答、历史、上下文追问的基本交互闭环。

如果将当前系统能力概括为一条链路，可以表示为：

                用户提问
                        ↓
                统一问答入口接收问题
                        ↓
                系统判断问题类型并路由到对应处理逻辑
                        ↓
                RAG检索或读取已有业务数据
                        ↓
                生成结构化回答
                        ↓
                必要时自动生成健康记录或影响后续疫苗/时间轴状态
                        ↓
                问答结果与会话历史在前端展示和保存

相比之前主要完成数据录入、记录与展示，这一阶段的项目已经开始体现“智能平台”而不仅仅是“记录工具”的特征。

五、下周计划

下一阶段我们计划继续推进以下内容：

继续补充和清洗育儿知识文档，完善RAG知识库；
优化健康、时间轴、营养三类问题的路由准确性；
继续完善问答结果的结构化字段；
推进更多问答结果与系统业务模块之间的联动；
优化前端问答页面与历史会话展示；
逐步推进语音输入输出与统一问答链路结合；
继续补充测试用例，提升统一问答和联动功能的稳定性。

总体来看，这一阶段是BabyMind从“多业务模块并行开发”转向“AI能力开始整合业务模块”的关键阶段。后续我们会继续在现有基础上推进RAG、多Agent协作和前后端联动，使项目更加接近最初设想中的科学育儿辅助平台目标。

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

深入理解 AI Agent · AGENT #02：Agent 的四大核心机制，拆开来看每个都在干什么

AI Agent技术社区

MCP协议开发实战：从零搭建AI Agent工具链

本文介绍了MCP协议在AI工具链中的应用与实践。MCP协议旨在解决异构工具集成难题，为AI模型提供标准化、安全的工具调用接口。文章详细解析了MCP的核心架构，包括Server、Client、Transport等组件，以及通信流程与安全模型。通过实战示例，指导读者开发计算器和文件系统工具Server，并集成到Claude等AI客户端中。进阶部分展示了如何构建复杂工具链，包括API集成、数据库查询和多