让 AI 跑在一个共同的底座上。 文丨林见澜 2026 年,国内医院上线 AI 项目数量快速增长,从 AI 辅助诊断、智能影像,到慢病管理、病历自动化等场景在三甲医院快速铺开,政策推动与技术成熟让医疗 AI 从试点走向规模化应用的趋势愈发明确。 但行业也正陷入一种矛盾状态:医院愿意投入、厂商愿意供给、临床愿意使用,可是真正用得顺、推得开、能持续进化的 AI 系统依然稀少。 过去几年,绝大多数医院如果用 AI,普遍采取 “科室各自采购” 模式——影像科买一套肺结节识别,病理科上一套细胞筛查,体检中心用一套报告审核,肾内科、感染科再各自建独立模型。厂商比拼的是谁在单一病种上准确率更高、响应更快,医院则在不同系统间反复对接、重复投入。 数据难以打通形成孤岛,算力各自独占造成的浪费,模型无法协同、难以复用,医生要在多个系统间切换,基层医院更是无力承担分散建设的成本与门槛。单个 AI 可以解决一个个小问题,却解决不了医院智能化转型的真问题;单点模型可以提升局部效率,改变不了的是医疗 AI“零散建设、重复投入、难以互通” 的现状。“买了很多 AI,却没有一套能用好、用透、用得久。” 成了不少医院信息科与临床科室的共同感受。 改变这一切,不需要再多一个单点模型,医院需要从底层统一算力、统一数据、统一模型和统一应用,让散落的 AI 能力在院内共享,并能随着使用自我迭代。但这涉及底层架构改造、多系统对接、临床流程适配,投入大、周期长、协调复杂。在追求快速落地的市场里,这类项目难做,回本也慢。 当行业从比谁上线的 AI 功能多,到比谁的 AI 能覆盖全院,有没有一条路径,能让医院不用在零散工具和底层平台之间二选一,既能提升具体科室的效率,又能让全院 AI 数据共享? 医院不缺模型,但还是用不起来 AI 以往烟囱式 AI 智能体,让医院、临床科室、AI 厂商三方,正在陷入一个低效循环。 烟囱式
百度重新定义 AI 竞赛积分规则的最新尝试。 文丨江思远 在早期的中国科技互联网的阵营中,百度一直是布局 AI 等前沿技术最坚定的公司之一。正因如此,一直以来,百度会在产业发展的关键时刻主动抛出自己对 AI 的前瞻判断,它们逐渐变成了在 AI 发展历程的许多关键节点上精准命中、自我实现的预言。 26 年初现象级的 AI 节点显然是龙虾的爆火出圈,而百度的判断依旧先人一步:在李彦宏看来,龙虾这件事最具标志性意义的地方在于,这是第一次 AI 因应用而不是模型受到广泛的关注,这代表了 AI 在某个维度上的全面成熟:智能体不只是一个被人类触发的工具,它应该能自主执行任务、在执行中学习、在学习中变得更强。 于是下一个问题接踵而来,当智能体开始自我进化,拿什么来衡量这个飞快进化的崭新生态? AI 行业又一次站在了岔路口,所有人都意识到旧的衡量标准不管用了,但新的度量衡应该长什么样呢?李彦宏率先给出一个答案。 衡量智能体价值的百度算法 李彦宏给出的回答是一个新的指标, DAA——Daily Active Agents,日活智能体数。这是 Create 2026 开幕式上李彦宏正式抛出的概念。含义很直接:不要数有多少人在用 AI,要数有多少智能体在替人干活、并且交付了结果。 如果只看这三个字母,会觉得它像又一个 AI 营销概念,为了发布而发明的缩写,但如果把它放回李彦宏过去两年的公开表态里,会看到一条暗线贯穿其中,主轴就是智能体的自我进化。 2024 年 7 月,上海 WAIC 大会。彼时全行业的主流叙事是寻找 AI 时代的 “微信”,达到十亿级 DAU 的超级应用被认为是大模型价值兑现的标志,而李彦宏提出了他的不同看法:“要避免掉入 ‘超级应用陷阱’,觉得一定要出现一个 10 亿 DAU 的 App 才叫成功,这是移动时代的思维逻辑。” 他把自己看好的方向说得很明确——智能体。“只要用
上行期理所当然的技术决策,到了用商业结果证明合理性的时候。 文丨赵宇 编辑丨龚方毅 “超越最好的智驾芯片,数据流架构是唯一的机会” 晚点:数据流架构很早就被提出,为什么到今天才适合用在车端 AI 芯片上?数据流不是全新概念,国内基本没有其他厂商做,国外有厂商把它应用在数据中心。 谢炎:你说得很对,数据流架构是个非常古老的概念,最早在 1970 年代提出,MIT 的 Jack B. Dennis、Arvind、高光荣教授他们提的,到现在已经几十年,但工业界落地非常少,最重要的原因是计算规模不够大。在计算和数据规模较小时,数据流架构的效率优势很难发挥和体现。 冯·诺依曼架构有个很大的优势——方便人类编程。它把存储和 IO 操作都抽象成指令,加上计算指令,以一种中心化的指令序列 step by step 推动计算任务,特别适合人脑在有限的上下文长度下做思考和编排。代价是损失了一定的计算并行度,降低了效率。但这在 AI 计算之前的时代还能忍受。而且过去也发明了乱序发射、超流水线、多级缓存、分支预测等复杂的 CPU 微架构技术来缓解。 数据流架构的优劣势正好相反,它用数据依赖图映射的硬件结构,天然高并行度,但提升了人类编程的复杂度,而且调试工作和编译器的难度也大幅提升。 所以 AI 出现前,数据流架构不成立——虽然概念很好,但落地很难。但当计算规模扩大到一定程度后,冯·诺依曼架构的瓶颈已经越来越明显。再往后走,数据流架构应该是一种更好的体系架构方式。 晚点:具体讲讲,数据流架构为什么更适合 AI? 谢炎:这得从 CPU 架构说起。CPU 就像厨房,有切菜、配菜、炒菜等工种,中间有个调度员负责发指令。这种集中式管理容易 Debug 和编程,但调度员负载很重,规模扩大后容易形成瓶颈:可能有人空闲但调度员没看到,或者有人本可以更早切菜但因为指令没到而等待。CPU 中有 30%-35% 的晶