摘要： Google Research 與 Google DeepMind 在 2026 年 8 月 11 日公布研究，把醫療研究系統 AMIE 帶進即時臨床視訊問診。系統以 Gemini 與 Project Astra 為基礎，由不同代理分別處理視覺、聽覺與診斷推理。研究採隨機對照模擬病患設計，文章也強調它仍是研究系統，尚未等於可部署產品。
在診間坐上幾分鐘，醫師收到的資訊遠多過主訴本身。咳嗽聽起來是什麼聲音、走進來時步伐怎麼擺、坐下那瞬間臉上掠過什麼神色，全都收進他眼裡。長久以來，AI 醫療系統最過不去的一關，正是這些非語言的線索。
2026 年 8 月 11 日，Google Research 與 Google DeepMind 公布了一項首創研究，把自家醫療研究系統 AMIE 帶進即時臨床視訊問診。研究要做的並不只是把文字介面換成視訊畫面；重點在於讓 AI 具備「看見」與「聽見」病人的能力。
架構怎麼運作：多代理分工的視訊問診系統
AMIE 的底子是 Gemini 與 Project Astra，運作上採用多代理架構（multi-agent architecture）。系統裡看不到單一大模型包辦一切，而是幾名各有專長的代理分工：一名負責讀視覺線索，一名處理聽覺資訊，第三名擔起診斷推理。
走進模擬問診的場景，AMIE 能同步掌握病人的視覺與聽覺訊號、帶出虛擬身體檢查的流程，並在對話推進時不間斷地做診斷推理。舊式醫療聊天機器人的手上只有文字，兩者的差距就在這裡——AMIE 想捕捉的，是診間裡那些病人「說不出口」的部分。
站在產品建造者的位置看，這個架構最值得記下的一點是：多模態能力沒有被硬塞進同一個模型，而是拆給不同代理各自負責。醫療屬於高風險場景，每個環節的決策邏輯都必須能被追溯，這樣的拆法因此格外關鍵。
研究方法：隨機對照與模擬病患
研究方法採隨機對照設計，參與測試的是模擬病人（patient actors）與一批初級照護醫師。團隊安排雙方各自完成模擬問診，接著把表現放在一起比對。
比對下來的結果是，AMIE 在視訊問診裡已具備專家級的能力水準。不過「專家級」三個字得小心讀：研究跑的是模擬情境，並不是真實病人。標準化、可反覆測試是模擬的強項；真實診間那股混亂與不確定，模擬則無法完整再現。
對醫療 AI 產品來說，這類研究設計屬於必經的第一關，因為它提供可量化的基準，團隊才得以在受控條件下檢查系統是否安全、是否有效。但換到產品視角，考題其實是另一個：當系統真的進入臨床環境，遇上罕見或非典型的症狀表現，它的水準還守得住嗎？
三點啟示：醫療 AI 產品設計該注意什麼
AMIE 這次的進展，對醫療 AI 產品留下三點啟示。
其一，多模態輸入屬於核心，而非選配。手上只有文字的 AI，永遠掌握不了病人「看起來」是什麼狀態。任何打算進軍醫療領域的團隊都該記住：把視覺與聽覺資料整合起來，第一天就要算進規劃裡。
其二，多代理架構讓可解釋性變得更好。醫療現場的醫生必須知道，AI 憑什麼做出某個判斷。每個決策環節在這種架構下都能單獨被審查——異常由哪個代理發現？它看到了什麼線索？比起黑箱式的端到端模型，這種做法更容易累積信任。
其三，研究與產品之間那道鴻溝依然巨大。AMIE 至今仍是研究系統，實際部署還有一大段距離。該盯住的是它驗證出的技術走向；類似功能不該急著搬進產品。
限制在哪裡，下一步往哪走
限制也一樣清楚。模擬問診涵蓋不了所有臨床情境，需要實際觸診的檢查、緊急狀況都是明顯缺口。研究裡的醫師群體清一色是初級照護醫師，其他專科的判斷標準並不在其中。此外，視訊問診還得靠攝影機品質、網路延遲這些技術條件撐著，換到真實環境可能拖累表現。
對台灣與香港的醫療科技團隊而言，AMIE 值得看的不是拿來照抄，而是它示範了 AI 醫療下一步的方向：擺脫被動的文字問答，轉為主動理解視覺與聽覺。這背後不只考驗模型能力，也考驗對臨床流程的理解夠不夠深。
如果你手上正有一個醫療 AI 產品要打造，不妨這樣自問：病人的哪些訊號，你的系統「看見」得了？這些訊號又要怎麼變成診斷依據？等這些問題都有答案，才算真正站上醫療 AI 的主戰場。