医疗 Agent 与其他 Agent 的根本差异在于：如果是代码 Agent，代码出错 retry 就行，但医疗对专业性的要求极高，一个致命回答背后可能就是一个家庭的悲剧。与此同时，整个医疗领域遵循一套完整的循证逻辑，所有诊断都必须依据指南和教科书，构成严密的推演链条。然而大模型本质上是非确定性的，而医疗场景恰恰追求确定性。所谓确定性，医疗场景追求的是可解释、可复现、符合指南的推理过程，而不是简单要求每次输出完全一致，可大模型很难保证这一点。

此外，大模型长期记忆的缺失在医疗场景中格外突出——用户的病症、症状、慢性病往往是长年累月的，比如一位高血压患者可能已患病几十年，现在得了新病，你的诊断就需要结合他过去数年甚至数十年的情况。

最后还要面对风险合规问题，医疗涉及大量隐私与数据安全。举个例子，在阿福上，不仅能解决医疗问题，也能解决心理问题。国内有相当比例的人存在心理困扰，经常有人问“我想自杀怎么办”。这时你绝不能引导他自杀，而是要做疏导；如果识别到情况严重，我们触发高危干预流程，联动专业支持渠道进行处置，事实上我们也确实拯救过一些想自杀的人。

正因为这些痛点，医疗领域研发范式跟传统模式产生了巨大差别。传统研发遵循需求、设计、开发、测试、上线的路径，是代码驱动的 TDD，靠人工 QA 验证，变更周期长，以往做一个功能可能耗费两周甚至一个月，这适合确定性需求——所谓确定性需求，就是点一个按钮该提示什么、下单能不能成功，整个路径都是确定的。

从传统业务到搜索推荐时代，迭代变成一周一到两次，由数据和 AB test 驱动。研发主要围绕特征工程与模型训练展开，去搭建一个 platform，支撑算法高效地编写代码、构建特征并快速上线，关注 CTR、CVR、转化率等线上指标。这一场景适合效果可被量化的地方。

到了 Agent 时代，迭代效率基本上以天为单位。这一阶段的牵引方向是 Benchmark，因为它衡量的是能力，而能力与线上指标挂钩。但光衡量能力可能不够，因为它给出的方向有时会偏掉，你可能觉得该往 A 方向走，上线后却发现用户行为并不匹配，那就要及时调整，所以我们又引入了 Badcase。研发模式也变得完全不同：过去功能靠代码实现，大模型出来后，改动要么是改 prompt，要么改 search、加工具，要么干脆换模型。如果模型仍满足不了，以前的思路是改代码，现在则是把这些逻辑全部转化为数据，用数据去训练模型，这就是代码数据化。它是一种 Badcase 驱动、快速迭代的模式。为什么迭代效率必须快？因为一个架构师，既要为技术负责，也要为业务输赢负责。全球范围内很多在做医疗领域，产品都是迭代出来的。最早我们更偏向 AI 工具，但今年我们越来越多地往 Harness 方向走。在这个方向上差距非常显著，有的人可能只能提效百分之二三十，但真正厉害的人可以提效十倍。

有一套架构支撑这套研发范式。最底层，不管做 model 还是 Agent，都得考虑场景独特的数据。对医疗来说，核心数据就是看病的指南、书籍、权威网页，同时阿福还提供挂号等服务，需要医生、医院数据，还有后训练的数据。有了数据，上面是模型和 Agent。我们有 Agent model，还涉及到 Agent RL，这部分我们得提供 Agent ENV、tool environment 和 reward service。再往上就是大家关心的 Agent 层，一般包括 search、记忆、Agent 的研发范式，还有多智能体，最上面是应用层和客户端。左边支撑框架的迭代效率，右边是整个风险防控，迭代这么快，肯定不能出事。

迭代的核心是 Evolution and Badcase。评测集是重中之重，一定要快速建设好。医疗没有一个唯一的 validation，不像数学和代码能跑单元测试直接验证，它是多 rubric 的，你得回答到点上。比如感冒怎么治疗，你必须回答到感冒是自限性疾病，可以自愈，可以通过休息，也可以通过吃药。你只回答吃药没回答休息，这道题就答错了，类似很多问题都不是唯一解。有了 Benchmark 之后，怎么自动化评估，怎么人工终审，都很重要，现在我们的自动化评测耗时已经从过去的 12 天缩短到了小时级。

评测集最好的建设起点其实是 Badcase，不管是业务专家还是其他团队。这里有个最大的误区，就是大家把 Badcase 等价于质量评测，很多团队直接丢给质量团队负责。但纯由质量团队负责大概率要失败，因为质量团队和评估团队需要的能力不一样。评估本质上决定模型的方向，评测就是在定义模型的能力。

而 Badcase 是你产品上线后的各种问题，我们有多条反馈渠道。上线前有种子用户内测，所有 badcase 都要归类分析；正式灰度上线后，还有种子用户、用户体验群、社区运营，这些渠道的 badcase 都要分拣归类，这是最重要的资产。你看 Anthropic 为什么能把 code 做到最佳，因为他们有最优秀的工程师，最优秀的工程师知道怎么用。所以你只要积累足够多的 badcase，产品一定会是最好的。有了渠道，要把这些 badcase 动态分拣，是产品需求还是功能不完善，慢慢分解再走迭代。如果是模型能力或系统框架不足，就要放到 Benchmark 里作为定期发布项。还有核对与巡检，去年我们通过 badcase 巡检出很多问题，比如大模型的“复读机”问题，已经从最开始的十万分之五降到了目前万分之二左右。还有风险场景，比如我们内部测试时发现大模型偶尔会说自己是医生，会帮用户打电话，这就是风险场景，一定要通过围栏把风险防控住。

有了这些手段，不能全靠人工。复杂的事情简单化，简单的事情流程化，流程的东西自动化，只有自动化才能沉淀下来。评估完了之后怎么上线？除了看评估，我们还会持续关注线上用户指标和监控。我们发现用户耗时跟留存是成正比的，于是就把这个加到了指标里。

接着要建立双循环：评 Benchmark，有 Badcase，反馈之后一定要定期把发现的 badcase 加回到 Benchmark 里。因为 Benchmark 一定会随着时间 overfitting，不管国内国外，一个榜单发布两年基本就不能用了，本质上不管有意无意都会造成数据泄露，榜单就 overfitting 了，之后就只能把它当回归集用。有了 badcase 一定要做根因分析，我现在花时间最多的就是天天看这些 badcase 和做根因分析。

方案优化反而好办，想清楚了都能交给 AI 做。花时间更多是效果验证，怎么搭建一个环境让 AI 能自主验证，这是最难的。其实这是一次基础设施的好机会，你可以选择从零开始把基础设施重新做一遍。现在公司从上到下经历的平台太多，你可以在 K8S 之上重做一套 AI native 友好的基础设施，因为你后面会发现评估会成为瓶颈。假设你的 Agent 能自主写代码，10 个工程师每人 10 个 Agent，100 个 Agent 在同一个代码库疯狂改，你怎么去做评估？这正是我们正在解决的问题。

怎么做一个可靠的评估？比如说，100 道题波动是 3%，1000 道题波动也是 3%左右。如果你有个评测集，为了业务效果提升一个点就推上线，你反复评测总会撞上一次高分，这说明你的评估不可靠。所以数据集必须稳定，首先数据要有区分度，不能有明确二义性，人看不明白的机器肯定也看不明白，评测集的对错要能分得清楚。其次，评测集要有区分度，如果你评自己的 Agent、评 Claude、Codex、千问、MiniMax，大家都得 80 分，那这个评测集毫无价值，必须能评出能力差距。

第二是样本量，当然越多越好，但受限于真实环境，至少从 10 条、100 条开始慢慢完善，这个阶段肯定有巨大波动。比如 100 道题，一次评 80 分一次评 83 分，这 3 分可能只是波动，不是你真实的策略迭代，那你就得接受这种波动。怎么接受？就是评估完后，花大量时间去 review 底线问题有没有守住，如果底线不变就可以推全，如果底线变多了就不能推。

第三，样本够了谁打分？要么人打，要么机器打，我们都知道"taste is all your need" ，你的裁判就是机器。我们当然最希望有足够多优秀的医生或工程师来打分，但这不太可能。所以怎么把大模型的偏好跟人的偏好对齐，这是一个非常漫长的过程，一定要花时间。一个场景大概得一两个月，先在人与人之间做一致性评估，产生人际间的一致性分数，再拿人去跟机器校准，直到机器跟人校准对齐。这个工作你不得不做，在评估上花再多时间都是值得的，因为评估方向偏了，你整个产品方向就偏了。

医疗对话涉及症状、检查结果、用药、既往史，单次会话信息量远超其他领域，医疗不可能一次对话就把问题描述清楚，用户通常携带大量检查检验报告，都是 PDF 加图文混合的，还要多轮对话。在我们的实际评测中国内模型上下文一般是 128K 或 256K，但真到了 64K 往往会出现 lost in the middle、recall、ACC 指标会跌，最佳上下文长度大概就在 32K 到 64K 之间。还有一个问题是用户会检索最新材料或指南，这些指南报告动不动几十页 PDF，如果全放入主上下文会造成严重污染。

我们的解决方法借鉴了 Claude 和 Codex 的完整上下文策略，但最大的区别是，Claude code 和 Codex 更偏项目管理式的上下文进度，而我们的管理更聚焦于关键信息以及关键信息冲突。我们之前以为大模型能够充分理解非结构化信息，后来发现最好还是把百分之二三十的关键信息结构化，因为完全结构化又没法 scale，所以最后取了个平衡。如果你的业务不是特别复杂，可以先从结构化开始干，一般是结构化加非结构化混合着来。然后是上下文压缩策略，核心就是提取关键信息。我们在第一轮和第十二轮压缩，这些策略是通过自动化实验和评估搜索得到的。另外在模型上下文达到 20K 时我们也会做压缩，这也是 AI 跑出来、评估了各种模型后的结果。压缩时，我们会把用户 query 全部保留，用户的问题远比模型的回答更重要。再者就是渐进式策略，这个思路很自然，就像读论文读指南，先给模型看目录，让它判断是否需要读，需要读再去读。目前渐进式体验下来效果是最佳的。

主子 Agent 的上下文共享，比如一篇论文几十上百 K，确实没法全加载到主上下文，这时候我们就把任务委派给子 Agent。非必要不要搞 multi-agent 架构，它的收益不大，除非你真的遇到了特别长的上下文。没有长上下文需求的时候，尽量让架构越简化越好。还有一些小细节，比如上下文返回的时候不要返回原文，可以返回一个 index。就像你读了一个目录，知道它是第几章，不用把整个章节文章都返回，就返回一个 index，在主文件里再去 retrieve。Agent 最大的问题就是概念非常多，但最终决定 Agent 的不是概念，而是每个细节你做得扎不扎实。

我们在 25 年 6 月份开始做 Agentic RAG，那会儿 Agentic 这个概念在业界刚起来。我们面临的挑战，一个是很多时候依赖强检索，而且一次检索不够。我们需要时效性，同时面临的是多跳问题。比如“肝功能不好加发烧，能吃什么药、怎么吃以及怎么报销”，这就是一个多跳问题。早先我们做的就是 RAG，做一次检索让模型回答，后来发现这样会出现很多 corner case，回答得并不好。解决复杂问题的难点，其实就是怎么激发模型去做多次的 Agentic 行为。那怎么能激发模型变 Agentic 呢？就是你让它解足够难的问题，它自然就这样了。于是问题就变成了：怎样合成足够难的问题。

在医疗领域合成问题有自己的特性。怎么合成一个符合逻辑的多跳问题？这抽象到原始问题就是，什么是一个符合逻辑的多跳，那其实就是知识图谱。我们用的是最长子问题从知识图谱里抽象出来，再把它模糊化，然后让模型答对。你把它激发出来，持续训练就 OK 了。后面就是怎么样合成高质量的轨迹，这就涉及到现在比较火的一些概念，一般叫在线蒸馏或者思路链重写。那时候我们用强模型来合成问题，会用国外的 Claude、Gemini 或者 GPT。这时就要有一些技术判断了。如果今天蒸馏的是一个偏写作的业务场景，应该蒸馏 Gemini；如果分析战略框架，就蒸馏 Gemini；如果是强工具调用、依赖工具调用很多的场景，那蒸馏 Claude。GPT 在用户体验上比较好，比如那些小词汇的写作。如果做的是交互场景，写 HTML 这种，其实是 Gemini 最强的。

当时我们大概投入了 6 个人，做了两三个月，最后把模型做上去了，刷成了 Sota。我们把所有的模型数据、训练框架都开源了，还写了一篇技术报告，把细节全公开了。为什么公开？因为我们是后来者，当时千问是第一，我们刷完榜变成第一，作为后来者只有把技术细节公开得更详细，别人才能关注到我们。后来千问跟 Mirrorman 的方案，其实跟我们也一模一样，大家看他们的技术报告就知道。

对于复杂多跳问题跟医疗，我们使用 Agent 的框架加循证医学检索，可以理解为是一种 pico 检索。第一层做意图识别、做多跳问题分解、做检索策略路由。第二层是循证检索，得知道这个问题要检索哪些循证指南、文献、药品、医保政策。第三层是信息的多元融合，所有的指南、书籍都得打上业务分、权威分。当信息发生冲突时，还要有一套业务的冲突解决方案，这个时候就必须依赖专家。当然如果不依赖专家，更快的方案是找一个比较好的模型。如果数据不能泄露，就用国内模型；觉得无所谓就用国外模型，用模型打个分，然后跟专家的一致性去比对，如果你觉得比专家做得好，那就可以用了。

记忆，尤其是在医疗上很难。第一，用户的数据管理太复杂，用户有长期和短期的症状。第二，各种设备数据，IoT 设备、手表，还有医院的部分数据，用户授权后把医院数据同步给我们，今天血压高、明天血压低，这些数据到底能不能用来做分析？第三，模型的问题，我们看到很多七八十轮甚至上百轮的多轮对话，用户很容易出现话题漂移。数据融合的难度也非常高，用户今天说我血压高，但量出来血压又不高；用户说他不对某个东西过敏，但报告上又显示他过敏，或者报告显示不过敏但他本人说自己过敏，这种信息冲突的融合就非常难。

然后是个性化决策与安全控制。很多人网上看病是因为有隐私问题的，涉及隐私的信息、高风险信息不能泄漏不能乱用，比如用户在你这买了某些病种的药，如果你知道他是这个病，在没有用户授权的情况下你是不能用的。个性化信息如果记了很多，但一旦出错代价就非常大，尤其是我们现在做不同年龄的婴幼儿和儿童，治疗方案完全不一样，只要一个记错，代价非常大。还有效果评估，需要建一个覆盖足够多用户画像、足够多病症的评估体系，难度非常大。

另外，用户在医院看病，医生一般会告诉你这个病是什么原因。AI 看病也一样，但如果是 AI 产品，用户对 AI 产品的耐心通常很有限，解释性做得不好，他就觉得你这产品不行。可是解释得越多，你可能暴露的用户数据就越多，哪怕用户授权了，有时候也会出问题。比如男性的一些隐私问题，你给他推荐一个药的时候，如果告诉他是基于他某方面的问题推的，很多时候会让他愤怒。隐私与合规的要求也非常高，在医疗里面所有的数据都要可审计。在中国，医疗数据泄露超过 50 条就有可能要坐牢的。所以我们的成本是所有的东西都要单独存储，所有的东西都要可审计。

我们的方案跟业界区别不大，最大的区别在于，我们有一个病例级别的长期记忆，是以人的生命周期和病程推理来推进的。对医疗来说，忘记什么比记住什么更重要。比如用户最近有个感冒，过段时间不感冒了，你得把它遗忘掉。遗忘机制其实是更重要的，而现在一般的 Agent 遗忘机制做得还没那么好。第二个区别是，数据冲突时，一般是需要让用户去确认的，这在医疗里是特有的，也算一种产品设计。第三个区别是业务特性方面，我们的用户中有大量是替别人问的，比如问“我家小孩”“我父母有什么病”，这时候最大的难点就是，你怎么区分当前是给自己问还是给别人问。所以第一层我们有一个类似用户角色的概念，不同数据可能要放在不同的角色下。但不同的角色之间还是有冲突，比如用户有两个女儿，他说“我的女儿”时，你怎么判断是大女儿还是小女儿？他前一个月问了一堆问题，现在又说“我女儿今天吃得不好”，你该用谁的信息？这挺难判断的。我们的主体识别做得还算 OK，但我们采取的是百分之百确认才用，不确认就不用、不结合冲突信息的策略，尤其在医疗上不敢激进。Gemini 我自己体验下来，做得就比较激进，每次问它问题它都要过度结合我的身份。我们则是一定要百分之百确认才结合，不确认就先不管。在技术实现上，我们有用户的结构化信息，包括病程也都是结构化的，还有一个重要的遗忘机制。除了结构化信息，我们还有一路 summary，两路结合。坦白讲，现在国内外的记忆都做得不是特别好，我用各种记忆产品都有各种问题。

我们做了一些用户满意度实验，发现整个耗时对用户体验的提升影响非常大。不管是语言模型还是多模态模型，本质上语言模型就是 prefill 和 decode。Prefill 是你丢给它的前面那些东西它会做 prefill，是计算密集型的推理；后面 token by token 的解码，是 IO 密集型的。

首先，如果为了快，最好前面已经计算好了，就是 KV cache，也就是 prompt 缓存。如果你改上下文策略，千万不要把 KV cache 搞丢了。其次，prefill 的优化，你可以把 prefill 节点跟 decode 节点做分离。以前你放在一台机器上，prefill 和 decode 会互相影响，因为通信的时候如果再过来一个请求，prefill 可能就卡住了。最简单的就是分离，做得更强一点的话，你可以把 prefill 换成计算能力强的卡，decode 换成 HBM 高的卡，比如搭配国产的寒武纪卡，它的 prefill 计算节点比较强，但 decode 不行，decode 就换成其他的卡。第三，做计算压缩，prefill 一般是计算密集型的，常用 BF16 计算，我们可以把它压成 FP8 或 INT8 计算，prefill 节点的负担就降下来了。现在为什么像 Kimi 的推理速度还行，它就是用了 QAT 训练做 W4A16，推理就比较快。第四是一些业务策略，因为大模型的 prefill 越长，推理时间越长，整个并行策略要么是 TP，一般就是 TP/PP，但长上下文时你可能要 SP 切分。这时候你把大于 32K 的请求换到其他机器，小于 32K 的用一种部署策略，这些都是非常正常的处理方式。

多模态的模型也一样，就多一个 Encoding 部分，Encoding 是多模态视觉部分，很耗时，那你就把 Encoding 再拆出来，就是 EPD，套路都一样。至于 TPOT，就是一个 token 产生的耗时，取决于它的 HBM 和模型参数。那就有一种思路，能不能降低模型参数？比如 Speculative Decoding，用小模型预测，大模型验证，这种技术就可以。或者模型裁剪，把层数裁少，但裁层会影响效果。我建议大家最简单的就是用 Speculative Decoding 这类方案。我们自己也开源了，在 SpecFog 社区开源了蚂蚁百灵模型的 1T 加速方案，大概能提升个两倍，以前 50 token 每秒，现在用这个方案后能到 120 token 每秒，节省了非常大的成本。还有长短分离也是类似的思路。

去年整个业界在做 Agent RL，今年也还是比较火。其实如果你是一个系统工程师，很多方案你遇到那个场景时肯定也能想到。最早训练框架和 Agent 代码是耦合在一起的，Agent 框架一改，训练框架里的依赖包和推理就会互相冲突，Agent 就起不来了，最简单的办法就是把它做分离。第二，我们一般用 Agent judge 来做评估，但 Agent judge 的环境也不能跟 Agent 放在一块，放一块的话 Agent 没法 scale 上去。所有解决方案都是一样的：串行变并行、整体变分离。

针对模型奖励瓶颈，我们制定了 FP8 量化、异步架构及奖励服务升级的综合优化方案。秉持开源协作理念，在 DeepSeek、Kimi 等业界同类方案尚未公开代码的背景下，我们率先系统性开源了整套训练与推理技术栈，填补了社区空白，以开放生态共促大模型技术发展。