「蚂蚁阿福」& Google PHA：从产品到技术架构，Agent App与传统App的差异

「AI + 大健康」一直是一个充满挑战的领域。最近想要尝试探索，并以此练习自己的 Agent 产品思维。

在体验蚂蚁阿福，试图看懂它的产品逻辑时，我一直在思考一个问题：如此丝滑的体验，底层的技术到底是如何实现的呢？背后是有一套通用的 Agent 范式吗？

为此，我找到了谷歌发布的一篇关于 Personal Health Agent（PHA）的架构论文。

如果说蚂蚁阿福是前端的产品展示（What），那么 Google PHA 论文则揭示了背后的技术架构（How）。这篇文章是我尝试把这两者打通的思考：从产品表象深入到技术实现，以此窥探从传统 App 进化到 Agent App 的全过程。

一、「蚂蚁阿福」Agent 产品拆解

未来的 Agent App 是什么样的呢？

很长一段时间里，我都陷入了一个思维误区，认为 Agent 就等于 Chatbot，界面越简单越好，最好只有一个对话框，其他什么都不要。

但蚂蚁阿福给我展示了一个更有说服力的答案：Agent 不应只是一个聊天的窗口，更应该是一个智能服务的容器。需要重新用 Agent 思维把医疗健康场景做一遍，实现从「人找服务」到「服务找人」的跃迁。

1、架构思维：Agent 作为场景容器

如果只用一个通用的对话框来解决所有问题，这可能会导致对话发散，用户也不知道这个 AI 到底能干嘛。

蚂蚁阿福的做法是拆分出多个独立的智能体：

- AI 诊室：专门负责问诊，流程严谨。从症状描述、多轮追问、给出预判，到最后直接弹出挂号卡片，完成了一个从咨询到交易的闭环。 - AI 找医生：结合传统 Tab 筛选，专门解决找医生的难题。 - 药管家：一个工具型智能体，负责识别药盒、管理药箱、提醒吃药，甚至连接购药服务。 - 健康小目标：专门负责长期的打卡和监督。针对慢病管理或健康习惯，它变身教练，帮用户拆解目标，每天监督打卡。

每一个 Agent 就是一个被封装好的垂直应用，它有独立的 Prompt、独立的工具集（Tools）和独立的记忆（Memory）。这会让用户感觉到自己不是在用 App，而是在和医生、药师、健康教练对话。

2、融合思维：LUI 与 GUI 共存

在体验「AI 找医生」时就可以看到 LUI（语言交互）与 GUI（图形交互）的完美融合：用户可以用对话描述病情，但筛选医生时，它依然保留了传统的科室列表、医生卡片、筛选 Tab。

- 对于描述症状，自然语言效率最高。 - 但对于「从 10 个医生里选一个」，列表对比效率最高。

这就是「双模态」设计要解决的问题：在任务流的哪一个环节用 Chat，哪一个环节用卡片，哪一个环节用按钮，才能实现效率的最大化。

3、闭环思维：从「连接工具」到「执行专家」

以前的医疗产品在告诉用户去哪里挂号、跳转网页之后就不管了。但蚂蚁阿福利用其生态优势展示了 Agent 的核心定义：感知、决策、执行。

- 感知：多模态输入（拍药盒、拍体检报告、拍皮肤患处）。 - 决策：基于医疗大模型的推理（是看皮肤科还是过敏科）。 - 执行：直接在 App 内调用支付宝、医疗健康的接口，完成挂号、买药、支付。

Agent ≠ 聊天机器人，执行力才是灵魂。

4、情感思维的注入：人格化与信任感

如果问医疗产品最难的是什么？是信任。

蚂蚁阿福建立了一个「阿福」的 IP 形象，并引入了真实医生的「AI 分身」，绑定真实专家的姓名、头衔、知识库，甚至会展示医学思考路径（引用了什么文献，依据是什么）。

在 Agent 发展的早期，这种「人格化」设计正如乔布斯当年提出的「拟物化」：用木纹书架让用户适应电子阅读。阿福的白大褂形象和专家头衔，就是用户对 AI 逐步走向信任的桥梁。

这是一层必要的温情外衣。

但随着 AI 的不断进化，这层人类的皮肤终会脱落。未来的 Agent 将不再局限于模拟人类医生，而是一个纯粹的理性体：基于数据的绝对理性与极致执行。那时我们将不再向一个虚拟人求助，而是直接向医学真理提问。

那么，在未来到来之前，我们需要构建怎样的技术地基呢？Google PHA 论文向我们揭示了这个更远的未来。

二、Google PHA 架构与多智能体协同

论文开篇便直击痛点：个人健康问题具有极高的多模态和上下文依赖属性。

- 数据异构：既有结构化的时序数据（心率、步数），又有非结构化的文本（病历、主诉）。 - 需求复杂：用户的问题往往是模糊的，比如「我怎样才能睡得更好？」这需要从数据分析到医学推理，再到行动建议的完整闭环。

此外，在医疗场景下，单一的 LLM 往往存在两个致命弱点：

- 幻觉风险：一本正经地胡说八道，这在医疗领域是不可接受的。 - 能力割裂：一个能安抚情绪的模型，可能算不对心率趋势；一个能查阅文献的模型，可能不懂如何激励用户去跑步。

因此，Google 提出了一个多智能体架构，包含一个协调器和三个核心的专家智能体。

1、数据科学智能体：一个会写代码的 Agent

它能直接读取用户的 Apple Watch 原始数据（CSV、JSON），通过编写 Python 脚本来分析相关性。

- Stage 1（Plan）：将用户的自然语言（「我最近是不是运动越来越少了？」）转化为结构化的统计分析计划。 - Stage 2（Code）：生成 Python 代码，在沙箱环境中执行，并具备自修正机制——如果代码报错，会将错误信息回传给 LLM 进行 Debug，最多重试 5 次。

场景还原：用户问「我最近睡眠不好和血压有关系吗？」

它不是简单地调用 web search，而是直接拉取用户过去 30 天的睡眠数据和血压录入记录，跑一个皮尔逊相关系数分析，然后告诉用户：「数据显示，当你深度睡眠少于 1 小时，次日收缩压平均升高 5mmHg。」

它不是靠 LLM 脑补数值，而是真正在跑代码算统计学显著性。

2、领域专家智能体：严谨的医学顾问

在 Google 的论文中，DE Agent 连接了 PubMed、NCBI 等权威医学数据库，并具备极强的逻辑推理能力：

- ReAct 范式：采用 Reason-Investigate-Examine 循环。 - 工具调用：挂载了 Google Search、NCBI、Data Commons 等权威医学 API。 - 上下文感知：不仅仅检索知识，还会根据用户的特征（如年龄、性别）和既往病史对知识进行个性化过滤。

它不仅是做 RAG，还有自我反思机制。如果信息不足，它不会瞎猜，而是会生成追问：「具体是左腹还是右腹痛？」

3、健康教练智能体：系统的心理咨询师

这个 Agent 接受过动机访谈的专门训练，负责多轮对话、目标设定和动机激发。

- 动机访谈：Prompt 设计融入了心理学技巧，不是生硬地给建议，而是通过积极倾听和背景澄清引导用户。 - 模块化状态机：内部细分为个性化教练模块、建议模块和总结模块，动态判断何时该倾听，何时该给出 SMART（具体、可衡量、可达成、相关、有时限）的目标建议。

场景还原：用户说「今天太累了，不想去跑步了。」

此时它不会只是简单地加油打气。它会先调用后台数据，发现用户昨晚深睡不足，于是基于生理状态给出建议：「我看到你昨晚深睡只有 40 分钟，现在的疲惫是身体在求救。强行跑步反而可能受伤。不如我们把今天的『5 公里跑』调整为『15 分钟冥想』？既能算作打卡，又能帮你恢复精力。你觉得怎么样？」

它关注的不是机械的指标达成，而是用户当下的最佳状态。

4、核心大脑：Orchestrator 与协作流

拥有了三个专家还不够，PHA 真正的技术护城河在于其 Orchestrator（协调器）的设计。

当用户输入一句话，首先接待用户的便是 Orchestrator。它不负责具体看病，它的任务是理解意图和分发任务：

- 意图识别：首先分析用户 Query，将其分类为四种关键用户旅程——知识问答、数据洞察、健康建议、症状评估。 - 动态分发：根据意图，动态指定一个主 Agent 和若干辅助 Agent。比如用户问「如何根据我上周的数据改善睡眠？」，主 Agent 是教练（给建议），辅助 Agent 是数据科学家（先去拉取数据分析）。 - 查询反思：这是最精彩的一步。在回答用户之前，主 Agent 会进行自我反思——「我现在的信息够了吗？」「我是否需要去查一下他的 Fitbit 数据，而不是傻傻地问用户『你昨晚睡了几小时』？」这一步大大降低了用户的输入负担，实现了数据多跑路、用户少打字。 - 记忆更新：每一轮对话结束后，关键实体、用户偏好和生成的洞察会被写入长期记忆，确保持续服务的连贯性。

Google PHA 实际上构建了一套「数字生命系统」。在医疗这种容错率极低的领域，一个什么都懂一点但经常胡说八道的 Chatbot 远远不够，需要一个各司其职的专家会诊团。

虽然论文指出目前这只是一个 Research Prototype，但这种「后台极度复杂，前台极度简单」的处理方式，或许就是 Agent 应用的终极形态。

当看懂了这套架构，再回过头看传统的医疗 App，会发现它们之间像是存在一种物种层面的代差。

三、Agent 应用与传统 App 的本质区别

从阿福的产品体验到谷歌的技术架构，我逐渐意识到 Agent App 绝不是给传统 App 加上一个 LLM 对话框这么简单，这是一次从交互形式到系统架构的彻底重构。

可以用一个冰山模型来概括。

1、交互层（冰山之上）：从「导航」进化为「意图」

传统 App 是菜单式的：它把功能陈列在复杂的菜单里，把用户当成操作员。要挂号，就必须懂它的层级结构（首页 → 科室 → 医生）。此时 App 是懒惰的，只有图形界面，用户必须自己点击来拆解任务。

Agent App 是生成式的：它把用户当成老板。只需要表达意图（「我头疼」），界面不再是固定的，而是根据需求动态生成的（LUI 确立意图 + GUI 高效展示）。

传统 App 是人适应系统、人找服务；Agent App 是系统适应人、服务找人。

2、架构层（冰山之下）：从「既定程序」进化为「专家协同」

这是最本质的区别。

传统 App 是确定性的逻辑代码：点击 A 按钮跳转 B 页面，路径是被程序员写死的。一旦需求超出预设（比如「我想根据心率找医生」），系统不仅无法处理，甚至无法理解。数据在各个功能模块间也是孤立的。

Agent App 是概率性的智能编排：当用户提出需求时，后台没有固定的代码在跑，而是一个 Orchestrator 在指挥。它会根据用户的意图，动态决定是先让数据专家 Agent 去拉取手环数据，还是让医学专家 Agent 去查阅文献，亦或是让健康教练 Agent 来安抚情绪。

传统 App 交付的是功能（提供挂号入口）；Agent App 交付的是解决方案（分析数据 → 筛选医生 → 完成挂号）。

此外，所有 Agent 共享一份全息记忆。用户在「药管家」上传的胃药记录，下一秒就会被「健康教练」读取，并在饮食建议中自动避开伤胃的食物。这种牵一发而动全身的主动服务能力，才是 Agent 应用的灵魂所在。

最后

Google PHA 论文里写道：「目标是赋能而非替代临床医生。」这句话点破了 Agent 的本质：它不是为了取代人类，而是为了专业边界的延伸。

传统 App 是被动的「工具」，不用它，它就在那里躺着；Agent App 是主动的「伙伴」，它始终在线，见微知著。

或许，AI 医疗的终极愿景，就是让用户感觉不到它的存在，但健康却如影随形。