JPMorgan Ask David：企業級 AI Agent 的關鍵不是聊天，而是評估、分工與人類最後一哩
這篇 Threads 提到 JPMorgan Private Bank 投資研究團隊在 LangChain Interrupt 分享的 Ask David。影片原題是「How JP Morgan Built An AI Agent for Investment Research with LangGraph」，內容比一般「公司導入 ChatGPT」有價值得多，因為它展示的是企業級 agent 真正需要的架構與治理。
Ask David 的場景不是聊天客服，而是投資研究。JPMorgan 的研究團隊要管理數千個 investment products / funds，每個產品背後都有多年資料、文件與分析模型。當 financial advisor 在客戶會議中被問到「某檔基金為什麼終止？」時，過去需要找研究團隊、查歷史狀態、讀文件、比較相似基金，再整理成對客戶有用的答案。這是高風險、高資料密度、強 domain knowledge 的工作。
Ask David 的名字不是單純用 David 本人命名，而是 Data, Analytics, Visualization, Insights, Decision-making Assistant。
官方分享裡的架構大致是：
-
Supervisor agent：負責理解使用者意圖、拆解問題、派工給 sub-agents，並管理短期與長期記憶；必要時觸發 human-in-the-loop。
-
Structured data agent：把自然語言轉成 SQL query 或 API call，再用 LLM 摘要資料。
-
Unstructured data / RAG agent：處理 email、meeting notes、presentations、PDF、video/audio recordings 等非結構化資料。資料會先 preprocess、vectorize、放進 database，再由 RAG agent 檢索。
-
Analytics agent：接 JPMorgan 自家的 proprietary models / APIs / programming libraries。簡單查詢用 ReAct agent 呼叫 API；複雜問題則用 text-to-code generation，但執行需要 human supervision。
-
Personalization node：同一份答案會依使用者角色調整。due diligence specialist 可能需要很細的細節；advisor 可能只需要客戶可理解的摘要。
-
Reflection node：用 LLM judge 檢查答案是否合理；如果不合理，就重跑，而不是硬交付。
-
Summarization / memory update：最後摘要對話、更新記憶、回傳答案。
這套設計的重點不是「有很多 agent」，而是每個 agent 都對應不同資料型態與工作責任：結構化資料、非結構化文件、專有分析模型、個人化、反思檢查。這和單純把一堆職稱塞進 prompt 完全不同。
JPMorgan 分享的三個 lesson learned 更值得記：
第一，start simple and refactor often。Ask David 不是一開始就畫出複雜 multi-agent 圖。他們從 vanilla ReAct agent 開始，接著做 specialized RAG agent，等單一 agent 表現穩定後才整合成 supervisor + multi-agent flow，最後才用 subgraphs 支援不同意圖。這是正確的企業導入路徑：先把小迴路跑穩，再擴大架構。
第二，evaluation-driven development。生成式 AI 專案開發期可能比較短，但評估期很長。JPMorgan 的建議是 evaluation 要早做，而且要分層做：主流程要評估，sub-agent 也要獨立評估。不同任務要選不同 metrics，例如 summarization 看 conciseness，tool call 看 trajectory evaluation。更重要的是：evaluation 不一定一開始就需要完整 ground truth；先評估、再 review，review 過程會逐步累積 ground truth examples。
第三，keep humans in the loop。官方分享提到，通用模型套到特定 domain，準確率通常可能低於 50%；透過 chunking、search algorithm、prompt engineering 可以拉到約 80%；workflow chain / subgraph 可以把 80 推到 90；但 90 到 100 是最難的 last mile，而且在金融這種 billions of dollars at stake 的場景，不一定應該追求 AI 自動拍板。因此 Ask David 必要時仍會 consult real David。
Threads 作者自己的補充也值得保留：他跑 subagent 大半年，最常翻車的是「判官」那一關。沒有 LLM-as-judge 在出稿前挑刺，前面的 agent 很容易偷懶；但連 JPMorgan 都把最後一哩交回人類，表示個人或小團隊更不能省掉最後的人工 review。
我的判斷：Ask David 的價值不是告訴我們「multi-agent 很潮」，而是給了一個企業級 AI agent 的最低標準：
- 先用 supervisor 做意圖判斷與派工，不要讓單一 prompt 扛全部責任。
- 按資料型態拆 agent：SQL/API、RAG、專有模型、code execution 要分開治理。
- 每個 sub-agent 都要能獨立評估，不然你不知道弱點在哪。
- LLM judge 是必要的 reflection layer，但不能把它當終局保證。
- 高風險決策必須 human-in-the-loop，尤其是金融、法務、醫療、商務決策。
- 從 ReAct / RAG 小流程開始，不要一開始就做大而全的 agent orchestra。
對 Hermes / BigIntTech 的落地啟示：我們做 subagent workflow 時，重點不是再多生幾個 agent 名稱，而是建立「評估節點」與「人工責任邊界」。如果任務會對外發布、影響金錢、代表公司立場，最後就應該有 real David / real Allen / real Kate 的責任檢查，而不是讓 agent 自己閉環到底。