WF26: Harness Engineering & Startup Battlefield ft. Garry Tan, Mike Krieger, @t3dotgg , DSPy

• 1

  DSPy 團隊示範以規格、程式碼、評測三者分離來設計 AI 系統，Mike Krieger（Instagram 共同創辦人）暢談 Anthropic 的產品哲學與 Tag 委派工作流。

• 2

  「Loop Engineering 是否被過度炒作？」大辯論直面 Ralph Loop、AI 軟體工廠與程式碼簽署責任等爭議話題，是全天最具張力的環節之一。

• 3

  下午重量級演講接力：Theo Browne 談 AI「精神錯亂」與軟體業的擬物化時代；Garry Tan 分享 Y Combinator 旗下新創如何用「公司大腦」與技能檔案把生產力推高 400 倍。

• 4

  Startup Battlefield 決賽（Kmod、Comment.io、Foundry 三強對決）收尾，最終由 Comment.io 奪冠、Foundry 亞軍、Kmod 季軍。

• Harness 工程實戰密集：AWS Strands Agents SDK 現場程式演示、Restate 的持久執行基礎設施、Resonate 用 Agent 生成多目標持久化伺服器、Oracle AI Database 統一管理 Agent 記憶體。
• Agent 工具與安全成為顯學：CLI／MCP／Skill 的取捨與資安防線、PostHog 的 Warlock 惡意樣式偵測、WorkOS 提出讓 Agent 自行註冊服務的 auth.md 開放規範、「100 工具代理陷阱」的語意路由解方。
• Agent 記憶與身分持續深化：本體論驅動的語意層（Neo4j）、TurboCont 的 KV Cache 壓縮、Polygraph 打破倉庫邊界的元框架、「日誌即代理」的事件日誌身分架構。
• 無程式碼／低程式碼代理路線浮現：Google DeepMind 展示以 Skills、YAML 與檔案系統取代 Python 的 Gemini Interactions API 與 Antigravity 遠端代理。

“相較於 Day 1 聚焦「怎麼設計 Loop 與 Harness」、Day 2 把野心推向「讓 Agent 自己做研究、自己變強」，Day 3 把視角拉回「怎麼把這些 Agent 真正產品化、商業化、負責任地交付」——從資安防線、記憶治理到新創如何靠 Agent 團隊做出真實營收，最終在 Startup Battlefield 的舞台上具體驗收這三天累積的技術與願景。”

這是一場包含多個 talk 的錄影。點時間戳可直接跳到原始影片的該段落。

1. 1

   開場致詞與活動須知：主持人開場、贊助商致謝與前一日精彩回顧

   Ralph Chabrit · Replit

   ▶ 11:15

   這是 AI Engineer World's Fair Day 4 的開場致詞,由 Replit 的 Developer Relations Engineer Ralph Chabrit 主持。內容主要是暖場、活動資訊說明、贊助商致謝與前一日回顧,並沒有實質技術內容,重點在於為當天以「harness engineering(場域工程)」為主軸的議程定調。

   • 本次是 AI Engineer 歷來規模最大的一場活動,現場約有 7,000 名參與者,主持人特別感謝撐到第四天(最後一天)仍出席的觀眾。
   • 主持人炒熱氣氛,詢問現場來自歐洲、灣區在地的觀眾,並開玩笑提到舊金山是打造與討論 AI 最好的地方,因為這裡的人隨時走在科技最前線(自駕車、無人機送餐等)。
   • 回顧前一天(Day 3)的精彩內容:Anthropic 的 Tariq 分享了 Fable 5 以及如何探索新模型能力的過程；Sonar 的另一位 Tariq 分享了程式碼驗證(code verification)相關主題。主持人強調,即便使用前沿模型(frontier models),「保持在迴圈中(stay in the loop)」仍然非常重要。
   • 宣布今天(Day 4)的主題是「harness engineering(場域/框架工程)」,講者陣容包括 Anthropic、Stanford,以及 DSPy 團隊,DSPy 團隊將分享新協定(protocols)、如何將任務(task)與模型(model)分離,以及如何擴展(scale)AI 系統。
   • Keynote 結束後有多場 breakout session,分軌主題包括 Software Factory、Generative Media、Memory 等,鼓勵大家依興趣挑選場次。
   • 提醒大家去逛博覽會(Expo)攤位,收集贊助商準備的周邊贈品(swag),並強調今天是最後一天,錯過就沒有了。
   • 特別感謝主辦贊助商 Microsoft,以及各層級贊助商(lab、platinum、gold、silver、bronze),強調沒有這些企業的支持,這場活動不可能舉辦。
   • 主持人向觀眾說明,現場觀眾的能量與反應,對講者上台後的表現品質有很大的影響力,並帶領全場練習「如何像迎接搖滾明星一樣歡迎講者上台」,為介紹第一位講者(來自 Amplify 的 partner)做暖場鋪陳。
2. 2

   2026年度AI工程師現況調查：模態採用、模型選擇、成本壓力與Agent寫入權限的三倍成長

   Bar Yaron · Amplify

   ▶ 16:07

   這場 talk 由 Amplify 合夥人 Bar Yaron 發表,分享今年與 Notion、Vercel 合作、收到 1,048 份回覆的年度 AI 工程師現況調查結果。核心主張是:AI 工程領域正快速成熟——模態採用(尤其是圖像生成)大爆發、模型選擇走向「多模型混用+平台標準化」、成本已成為與品質同等重要的工程限制,而最關鍵的轉變是 Agent 的寫入權限(write access)在一年內成長超過三倍,但對應的控管手段仍非常原始。

   • 調查方法與樣本:今年第一次與 Notion、Vercel 合作舉辦調查,共收到 1,048 份回覆,涵蓋創辦人、CTO、工程師、產品人等各種角色與公司規模,顯示「AI 工程」更像是一種跨職能的實踐,而非單一職稱。
   • 經驗分佈連續第三年呈現同樣模式:資深工程師(10 年以上軟體經驗)有超過一半的人 AI 經驗只有 3 年以下;而最新進的工程師,其 AI 經驗中位數幾乎追平 10 年資深工程師,因為他們從入行就活在 AI 時代。
   • 模態採用:文字仍主導所有應用場景。但講者特別關注「意圖採用比」(目前沒在用、但打算用的比例)——音訊(audio)連續兩年蟬聯最高意圖採用,今年高達 56% 未使用音訊的受訪者表示打算導入,去年是 37%,顯示興趣正在加速。
   • 圖像生成是今年成長最大的模態:使用生成式 AI 做圖像並且「用得很開心」的比例從去年 18% 翻倍到今年 36%,對應同期 Nano Banana、Nano Banana 2、ChatGPT Images 2.0 等模型/產品的發布,圖像生成正從「生成奇怪的手」進化為真正的生產力工具。
   • 模型使用:94% 使用閉源模型,45% 使用開源權重模型,但開源使用者中超過 90% 同時也在用閉源模型——顯示開源模型是「增量補充」而非取代閉源,目前尚未出現真正替代關係。
   • 選模型的三大考量依序為:品質(quality)最重要、其次是 agentic 能力(如 tool calling)、成本並列其後;而「開源 vs 閉源」這個話題雖然在 Twitter 上很熱門,實際只有 5% 的人把它列為前三考量之一。可靠性(reliability)只有五分之一的人提及,講者推測這代表可靠性已變成「門檻要求」而非決策焦點,決策已上移到品質/能力/成本層級。
   • 87% 的團隊同時使用超過一種模型,常見的模型分派方式包括:依任務類型路由、同時跑多模型比較輸出、依成本路由。同時,超過一半受訪者表示組織正開始在「工具/平台」層標準化(而非模型本身標準化),部分團隊採混合策略(部分層標準化、部分保持彈性)——講者稱這是「工具平台的早期大整合」,但不是模型的整合。
   • 成本已成為第一級工程限制:40% 的受訪者表示成本「經常」影響他們使用 AI 的積極程度,另有 36% 表示「有時候」會,合計約四分之三的人會因成本調整 AI 使用方式,這在一年前並非如此明顯。生產環境監控項目中,成本/token 用量是僅次於品質本身的第二大監控重點,幾乎被當作 SLA 在盯。
   • Agent 是本次調查最大的轉變焦點:今年 95% 的受訪者表示團隊有在使用 Agent(相較去年幾乎翻倍);更關鍵的是,去年使用 Agent 的團隊中只有 52% 的 Agent 具備寫入(write)權限,今年這個比例暴增到 89%。兩者相乘之下,「使用具寫入權限 Agent」的受訪者整體佔比較去年成長超過三倍——代表 Agent 已從讀取/摘要/草擬,進化到真正在系統內採取行動。
   • 對應 Agent 控管手段仍很原始:目前最常見的控管方式是「人工審核(human in the loop approval)」和「權限授予(gaining permissions)」,方向正確但工具箱等同於管理一個實習生;再往下如任務拆解、檢索、記憶、沙盒等方式則使用分散,顯示業界尚未收斂出成熟的 Agent 控制層,講者特別點名「記憶與持久化上下文(memory and persistent context)」是接下來一年值得關注的領域。
   • 當 Agent 出錯時,問題多半出在「思考」而非「管線」:約三分之二的受訪者表示,幻覺(hallucination)或任務中途失去上下文是最令人挫折的問題。
   • 技術棧最大挑戰連續多年都是「評估(evals)」,但今年這個領先幅度已縮小,96% 的受訪者都認為技術棧有問題,只是問題各不相同;評估方法中,人工「感覺對不對(vibe review)」仍是最主要的方式。
   • 技術棧「自建 vs 採購」在八個層級上呈現明顯分化:推論/模型服務(inference/model serving)是最傾向「買」的層級;而 Prompt 管理是最傾向「自建」的層級(61% 自建),包括 Prompt、RAG、評估等貼近產品邏輯的部分普遍偏向自建。微調(fine-tuning)則是多數團隊「尚未採用」的層級。此外已經選邊站的團隊很少會再切換(買的不太會轉自建,反之亦然)。
   • 團隊層面影響整體正向:97% 回報 AI 對組織有淨正面效益,最大效益不只是速度,而是「更便宜的失敗成本」——更多實驗、更多原型、更多嘗試機會,因為試錯幾乎免費。
   • 但並非全無代價:超過九成受訪者也感受到某種負面下游效應,最常見的是「深層技術能力與程式碼庫理解力的流失」,這是廉價程式碼生成的後果之一。
   • AI 正模糊工程師與產品/設計/行銷之間的角色界線:81% 認為 AI 正在模糊這些角色分工。最讓講者驚訝的是「出貨(shipping)」——過去專屬工程師的領域,現在超過三分之一的團隊有非開發者(non-developer)在出貨功能(多為內部、規模較小的功能),但仍有 17% 的團隊表示非開發者「經常性地」出貨面向客戶的功能;即使非開發者沒有直接出貨,也有三分之一團隊看到他們自行打造原型、前端 mockup 等有用產出。
   • 快問快答未來預測:76% 表示 AI 提升了他們的工作滿意度;但 59% 擔心現在寫出來的 AI 程式碼會造成長期技術債;只有三分之一認為軟體工程已是「已解決的問題」。五年展望方面,67% 預期會有領先實驗室「宣布」達成 AGI(注意講者強調問的是「宣布」而非「真正達成」);只有 9% 認為 Transformer 架構五年後仍是最先進技術;而「五年後 AI 運算主要在太空還是陸地」這題最兩極,36% 說太空、38% 說陸地,是全份調查中最具爭議性的問題。
   • 總結(2026 Wrapped):整體影響非常正向;圖像生成使用翻倍、音訊仍是意圖採用最高的模態;成本正式成為第一級限制;開源模型是補充而非取代,呈現「多模型未來+工具棧走向整合」;Agent 寫入權限較去年成長三倍以上,但護欄仍然原始;推論(inference)是最被外購的層級,越靠近產品邏輯的部分則越傾向自建。

   “「Infinite intelligence still comes with a usage-based bill.」(無窮的智慧仍然附帶一張按用量計費的帳單。)”

   “「When agents fail, it's usually the thinking, not the plumbing.」(當 Agent 出錯時,通常是「思考」出了問題,而不是「管線」。)”

   “「Apparently everyone's prompts are special.」(顯然每個人都覺得自己的 Prompt 很特別——用來調侃 61% 的人堅持自建 Prompt 管理。)”

3. 3

   延遲為何至關重要：新一代傳輸協定HOMA如何取代TCP與RDMA以降低尾端延遲

   John Ousterhout · Stanford University

   ▶ 35:42

   這場 talk 主張 AI 工作負載正從「大量傳輸、只看吞吐量」轉向「大量小訊息交換、極度在意延遲」，而 TCP 與 RDMA（RoCE）這類舊協定的擁塞控制機制天生不適合這種環境，會產生嚴重的尾端延遲。講者 John Ousterhout 介紹了他與團隊在史丹佛開發的全新傳輸協定 HOMA，透過「以接收端為中心的擁塞控制」與訊息感知設計，可將尾端延遲降低一個數量級以上。

   • 歷史上 AI 工作負載（如權重梯度傳輸）以 GB 級的巨量傳輸為主，只在乎吞吐量（Gbps），連線建立慢一點也無妨，這種場景下 TCP 和 RDMA 表現尚可。文中提到的 RDMA 實際上多半指 RoCE（RDMA over Converged Ethernet）。
   • 現在的工作負載正變得更「顆粒化」，尤其是推論（inference）和 agentic 工作流：大量小訊息用於 metadata 交換與協調，例如檢查分散式 KV cache 是否命中某個 entry，或是計算階段結束時的 barrier 同步。訓練（training）工作負載則仍以大量傳輸為主，變化不大。
   • 對這些小訊息而言，真正重要的是「尾端延遲」（tail latency，如 P99），而非平均延遲：只要眾多小訊息中有一個慢，就可能拖垮整體流程完成時間。
   • 舉例：多節點各自用 GPU 運算一段時間後，做一次小量 metadata 交換再進入下一輪運算；GPU 在交換期間閒置。以往運算階段長達 5 秒、交換僅需幾毫秒無傷大雅，但 agentic 場景下運算階段已縮短到毫秒級，若交換也要花幾毫秒，就會浪費大量 GPU 資源。
   • 現場調查顯示，相當多聽眾表示他們的應用確實因小訊息延遲而影響整體吞吐量，講者認為此問題會隨趨勢持續惡化。
   • 尾端延遲惡化的根源是 incast 造成的壅塞（congestion）：多個節點同時對同一目的地傳輸資料，鏈路頻寬有限（例如 3 個節點同時傳送，速度是單一節點能接收速度的 3 倍），封包便會在目的地所在 top-of-rack switch 的 egress port 佇列中堆積。若此時有節點想傳送短訊息給同一目的地，就會被卡在長訊息後面而延遲；最糟情況下 buffer 溢出、封包被丟棄，觸發逾時重傳，情況更糟。
   • TCP、RDMA（以及 HOMA 之前幾乎所有協定）的擁塞控制都是「由發送端負責」：發送端必須自行偵測擁塞並降速。早期靠封包遺失、超時未收到 ACK 來偵測，成本很高；現代則靠交換器的 ECN（Explicit Congestion Notification）標記——佇列快滿時開始標記通過的封包，接收端收到後在回傳 ACK 時把標記帶回給發送端，發送端才知道要降速。
   • 這種「發送端擁塞控制」機制先天很難做好：發送端只拿到「某處有壅塞」這一個 bit 的資訊，多個發送端同時對同一目的地送資料時，很難判斷該降多少、何時能再升速；加上偵測與調整存在「control lag」（往往要花好幾個 round trip 才能逐漸調整到剛好符合可用頻寬），等調好時情況又變了（新傳輸開始或舊傳輸結束），導致系統持續在「傳太多」與「傳太少」之間震盪，難以穩定。這個問題在研究圈已知超過 20 年，論文很多但改善有限。
   • TCP/RDMA 另一個根本問題是資料模型是「byte stream」，沒有訊息邊界的概念：多筆訊息會被序列化進同一個位元組流，協定本身不知道訊息大小、不知道還有多少資料要來，也無法對短訊息優先處理，會出現 head-of-line blocking——例如兩個大訊息後面接一個小訊息，小訊息會被卡住，造成尾端延遲。
   • HOMA 是史丹佛從零開始（clean-slate）重新設計的資料中心傳輸協定，幾乎每個主要設計決策都與 TCP／RDMA 不同，目標是讓大小訊息混合傳輸時，短訊息仍能維持極低延遲。此專案源自其學生 Behnam Montazeri 的博士論文，因效果極佳，講者決定將其推向實際生產環境：已為 Linux 撰寫核心模組（kernel module）、正在推動合併進 Linux 主線核心（upstream），程式碼已在 GitHub 開源。
   • HOMA 特性一：以訊息（message）而非位元組流為基本單位，最基本的單位是一次 RPC（request 訊息 + response 訊息）。協定全程知道訊息長度，帶來三個好處：(1) 接收端收到訊息第一個封包就知道總共還有多少資料要來，能「預測未來」，大幅改善擁塞控制的資訊量；(2) 採用 SRPT（Shortest Remaining Processing Time First）演算法優先處理較短訊息；(3) 因為訊息彼此獨立、不會被序列化進同一條流，短訊息可以「插隊」超車長訊息，不會被卡在後面。
   • HOMA 特性二：擁塞控制改由接收端（receiver）主導，因為壅塞主要發生在最後一段到接收端的下行鏈路，而接收端一收到訊息第一個封包就掌握幾乎完整的擁塞資訊，能更快、更精準地反應。運作方式：發送端把訊息切成封包，先只送出前幾個封包（稱為 unscheduled packets），之後的封包（scheduled packets）要等接收端主動發出 grant 封包才會送出；接收端可以節奏性地發放 grant（例如同時有 10 筆進來的訊息時，不必立刻對全部 10 筆發 grant，避免 top-of-rack 佇列壅塞），並可用 grant 機制優先照顧自己最想要的（較短的）訊息，藉此實作 SRPT。
   • HOMA 特性三：善用現代交換器的多重優先佇列（priority queues，通常每個 egress port 有 8 個），可依優先權從最高優先佇列先傳送封包。HOMA 會動態決定將封包放入哪個佇列，讓短訊息優先：在同樣的 incast 情境下，長訊息全部堆積在最低優先佇列，短訊息則走高優先佇列，直接跳過長訊息封包更快抵達目的地。
   • Benchmark 結果：在一組涵蓋 50 bytes 到 1 MB 的請求/回應訊息 workload 中，短訊息的 P99 尾端延遲，TCP 超過 1 毫秒，HOMA 低於 100 微秒，快約 13 倍。令人意外的是，即便 HOMA 優先照顧短訊息，長訊息效能不但沒有變差，反而比 TCP 快將近 2 倍——講者提到這與 HOMA 採用「run-to-completion」策略而非 TCP 的公平排程（fair scheduling）有關，但這場演講沒有時間詳細解釋原因。
   • 講者呼籲聽眾檢視自己應用程式的效能瓶頸：如果短訊息的高延遲正在拖累整體吞吐量，HOMA 是現成的解法，可望將尾端延遲降低一個數量級以上。他目前已從史丹佛半退休，把 100% 時間投入 HOMA 開發，歡迎任何人聯絡他（信箱在投影片上）尋求協助、修 bug 或討論導入。

   “「如果你給 HOMA 一個機會，你很可能可以把尾端延遲降低一個數量級以上。」（If you give Homa a try, you can probably reduce your tail latency by an order of magnitude or more.）”

4. 4

   DSPy與AI程式設計：以規格(Specs)、程式碼(Code)、評測(Evals)分離任務與模型，及DSPy.flex與質性學習(Qualitative Learning)新進展

   Maxime Rivest、Isaac Miller · DSPy

   ▶ 54:14

   這場 talk 由 DSPy 的兩位核心維護者 Maxime Rivest 與 Isaac Miller 主講，核心主張是：AI 程式應該像傳統函式一樣，把「任務」與「模型/實作細節」徹底分離，才能重複使用、組合、測試與自動優化。他們提出用「規格（Specs）、程式碼（Code）、評測（Evals）」三者共同定義任務邊界，並介紹 DSPy 4 即將推出的兩項新進展：DSPy.flex（可學習的程式碼harness）與質性學習（Qualitative Learning，讓模型從真實回饋自動演化評測標準）。

   • 程式設計的核心信念：重複做的任務就該寫成函式；函式可重用（reusable）、可組合（composable）、可測試（testable）、可優化（optimizable），DSPy 的目標是把這些特性帶進 AI 程式。
   • 定義函式只需要名稱、輸入、輸出與內部實作邏輯；使用者只需知道「契約（contract）」就能把它當黑盒子使用，甚至打包分享給別人用。
   • 這個領域三年內發明了大量新名詞、新模型、新技巧，層出不窮，但這些都只是「實作戰術（implementation tactics）」，重點是把它們包進清楚的輸入輸出契約中，才能保有彈性與敏捷度。
   • Maxime 舉自己的實例：一是從農場發票中萃取稅務數字報稅用；二是鍵盤快捷鍵工具，讀取剪貼簿內容做文法修正，另外做了一個「為求清晰而改寫文字」的獨立程式，接回鍵盤指令使用。
   • AI 程式不侷限於簡單的輸入輸出：可以整個收件匣加一封新信，用 RLM（recursive language models，遞迴語言模型，概念源自社群）自動生成草稿回覆；也可以像 agentic engineering / vibe coding 一樣，給一份 spec 和 repository，直接產出 PR。
   • 一旦固定輸入輸出邊界，內部實作可以從簡單 prompt 開始，逐步演化成 agent、加入工具（tools），再進化到「loop engineering」，而邊界外的整合部分完全不需改動。
   • DSPy 創辦人早在 ChatGPT 出現之前就提出：光有簽名（signature）不足以完整指定任務，必須靠三種語言表達任務才能做到自動優化與委外實作細節。
   • 第一要素「What should happen」＝指令（instructions）：以自然語言表達需求，用 DSPy signature 示範——設定模型後，用自然語言指令描述「萃取所有稅額，若不符資格則輸出零」，輸入輸出皆為字串。
   • 用類比說明：教朋友玩桌遊只需給說明就能上手，但若要做出 AlphaGo / AlphaZero 等級的系統，光靠範例學習會耗費大量時間精力（"you're gonna have a long night"）。
   • 第二要素「What must happen」＝約束（constraints），最好的落地方式是程式碼：範例中 self.extract 用 Predict（陽春版），self.recheck 用 Chain of Thought（多做推理）；在 forward 中若第一次沒抽取到稅值，就重跑加強推理版本；若數值小於零就丟出例外交給人工處理——這些規則即便未來有 AGI 也不該改變。
   • 第三要素「What good looks like」＝評測（evals）：講者用小時候在農場問爸爸「怎麼知道這是楓樹」的例子——有些知識無法用指令或程式碼表達，只能透過大量範例逐漸學會，這對應長尾（long tail）的隱性成功行為模式，就像實習生需要導師帶領觀察大量案例才能學會。
   • 當 specs、code、evals 三者都完整定義後，任務才算「完全被指定（fully specified）」，才能開始自動優化，例如用 GEPA 針對 metrics 和程式進行優化。
   • 優化技術的演進：GPT 出現前模型不夠強，只能靠程式碼找兩個範例（two-shot examples）讓基礎模型表現正確；之後模型變強，可以自動優化指令（instruction）；未來會逐漸從實作細節中解放，把更多東西委外自動化。
   • Isaac 接續說明：DSPy 已被大型企業用於生產環境並帶來顯著效益，主要兩大好處：一是實作成本降低——彈性可替換實作讓你能套用「苦澀的教訓（the bitter lesson）」搜尋不同解法、找到便宜方案，同時維持相同 evals，逐步優化業務邏輯；二是能擴展到原本因成本過高而無法處理的資料規模。
   • 具體案例：Shopify 透過從貴模型換成便宜模型，同時保留 evals 持續迭代，成本降低 550 倍；另有三個案例研究，講者建議聽眾會後自行查閱細節。
   • DSPy 生態系持續加入新技術，但講者強調沒有任何技術能保證解決你的問題（那是使用者自己的工作），DSPy 能做的是解決「子問題（sub-problems）」讓實作更容易。
   • 舉例：MIT 博士生 Alex Zhang 提出的論文 Recursive Language Models（RLM），是解決長上下文（long context）問題的一種方法，DSPy 把它整合進來只需一行程式碼，且 signature 保持不變，讓使用者可以直接測試是否對自己的長上下文任務有幫助。
   • 過去一年社群貢獻的其他技術實例：RLEVs、來自 Berkeley 的 prompt 優化工具 GEPA、Better Together、Multi-Module GRPO 等，都是可以直接在 DSPy 生態系中嘗試的研究創新。
   • DSPy 4 兩大新進展之一：DSPy.flex，一種新型模組（module）。DSPy 過去讓使用者優化的對象從「少樣本範例（few-shot examples）」演進到「prompt」，現在則演進到「程式碼（code）」——任何想實作的函式，都可以隨時間學習出一個完全客製化的 harness，只要能用已定義好的 specs/code/evals 衡量是否解決業務問題，不需在意具體實作方式。
   • DSPy 4 新進展之二：質性學習（Qualitative Learning）。AI 工程中建立 evals 特別困難，原因有三：(1) 對任何真實世界問題定義「好」都很困難；(2) 定義「好/壞」這種二元標籤會丟失大量細節資訊（例如一封信「好或壞」遠不如告訴你「哪裡可以改進」有用）；(3) 建立資料集和 eval 本質上只是對現實的一種「代理近似（proxy for reality）」。
   • 質性學習的核心提問：如果能讓「現實本身」自動回饋來訓練 evals 呢？講者相信現在的模型已經夠強，能解讀環境中任何文字型回饋（production 中的 traces、使用者行為、產品分析數據、模型主動詢問資料該如何表示等），並將這些回饋自動轉換成 evals 與可攀爬的「山丘（hill）」，隨著回饋增加不斷迭代精煉這座山丘、持續往上爬以解決真正的業務問題。
   • DSPy 專注解決這類「最後一哩路（last mile）」問題，並與研究社群緊密合作：把應用端遇到的實際問題定義出來、建立 benchmark、用新技術解決，再透過開源把成果普及給所有人。
   • 針對「有了 AGI 之後怎麼辦」的常見提問，講者回答：即使模型極度聰明，它依然不知道如何解決「你的」具體問題、不具備你的任務脈絡；智慧（intelligence）與無所不知（being all knowing）是兩回事——就算是愛因斯坦，若請他幫忙處理你的 email，他可能會反問「什麼是 email」；AGI 或許懂得處理 email 這件事本身，但不會理解你與需要互動對象之間的關係，這些脈絡仍須隨時間學習。
   • 自 2022 年起，DSPy 就一直圍繞 specs、code、evals 這三大核心理念（皆定義為可程式化介面）發展，過去演化重點是優化 few-shot 範例，後來是 prompt，現在演化到 harness，未來甚至演化 evals 本身。
   • 講者建議：面對任何新技術，都應該用資料驅動（data-driven）的方式檢視「它能否套用到我的業務問題」，先定義好自己的問題，讓 prompts、models、code 都對這個問題負責；當你的實作保持彈性，就能解鎖整個社群不斷發明的技術生態系，接入所有人共享技術帶來的「集體智慧」。
   • 結尾呼籲：DSPy 完全開源、開放研究，歡迎加入 Discord 社群；若研發出新技術，歡迎貢獻回 DSPy，一起把好技術推廣給所有人。

   “「如果你要做出 AlphaGo 或 AlphaZero 等級的系統，只靠範例來學習,那你將會有一個漫長的夜晚（you're gonna have a long night）。」”

   “「智慧（intelligence）跟無所不知（being all knowing）是非常不同的兩件事——就算你請愛因斯坦幫你處理 email，他大概會反問『什麼是 email』。」”

   “「你應該定義自己的問題，並讓你的 prompts、models、和 code 對這個問題的解決負責（hold accountable）。」”

5. 5

   爐邊對話(Fireside Chat)：Instagram共同創辦人Mike Krieger談Anthropic產品哲學、Tag委派工作流與新創韌性

   Mike Krieger · Anthropic

   ▶ 1:12:22

   這是一場與 Anthropic 產品負責人、Instagram 共同創辦人 Mike Krieger 的爐邊對話。核心主張是：AI 產品的下一階段是「去除任務委派的框架限制」——從描述步驟轉為描述目標狀態，讓模型自主完成並回報取捨；同時談到 Anthropic 內部如何用 Tag 這種多人協作、非同步、主動式的工作流取代大量的 Claude Code 互動，以及新創在 AI 時代依然有巨大空間的原因。

   • Mike 原本是 Anthropic 的 Chief Product Officer，但因為看到大家用模型建東西的 FOMO 越來越強，加上內部剛開始拿到 Mythos／Fable 的早期快照，決定轉職成為一線建造者（IC）。他觀察到現在有不少其他公司的 CTO 也轉職成 Anthropic 或同類公司的 IC。
   • 他描述了工作模式的轉變：從「我有個想法 → 在腦中拆解步驟 → 一步步疊代」的傳統工程思維，變成「描述目標狀態 → 讓模型去執行 → 途中提出取捨與問題 → 最後討論落地結果」。他笑稱模型有時做完工作後還得請它「當我是笨一點的人來解釋」，因為模型比他聰明。
   • 呼應主持人提到 Tariq 的建議「be unreasonable（更不講理/更大膽）」：Mike 提到內部有個非技術人員因為對內部產品不滿，被建議「直接叫 Claude 改」，讓他反思整個產業都該教使用者更大膽地使用 AI。
   • 他認為第一代 AI 產品把模型限制得太死（工具存取權限、自由度太低），導致使用者難以「不講理」地提需求；例如給每個知識工作者一台可以寫 bash 的虛擬機器，表面上看似沒必要，但實際上能讓模型自己寫腳本解決像 PDF 解析失敗這類問題（他自己就遇到內建 PDF 工具解析失敗，讓模型自己寫程式繞過的案例）。
   • 最「不講理」的個人案例：他把一個 Labs 專案的 Python（他很鍾愛的語言，Instagram 全站也是 Python 寫的）整個搬遷成 TypeScript，因為發現 Claude Code 搭配 Bun 有更好的部署流程。他設計了一套動態工作流程，讓模型在週末自動搬遷、驗證、雙重檢查、比對兩邊程式碼，週一就拿到一個已可部署的搬遷版本——這在他 2010 年代的工程思維裡是「不會有人這樣做」的蠢主意，但現在可行。
   • 談到用 LLM 做程式碼轉換/跨語言編譯時，可以借鏡他在 Instagram 時期做的 MonkeyType 專案經驗：當年 Python 3 導入型別提示時，他們捕捉「實際在 production 中被使用到的執行期型別」，再映射回程式碼中的型別定義；同樣的模式（利用 production 資料、分段測試）也能用在 AI 輔助的程式碼轉換上。他認為最難的部分永遠是「找到能漸進式切入的邊界」，而不是想一次把整個系統掀翻重寫。
   • 談基礎建設與量測：他分享 2010 年 Instagram 上線第一週伺服器就爆掉的經驗,当時剛好有場原本不是為他們安排的基礎建設午餐會,結果被他們整個霸佔討論。得到兩個至今受用的建議：(1) 把任何可能用到的指標都預先量測好,否則故障時根本不知道某個數字是正常還是異常;(2) 要非常重視 feature flag 與「旋鈕」機制，早期 Instagram 就有簡單但有效的漸進式上線（ramp up）與動態設定機制,能在幾秒內調整執行期設定以應付流量,他認為這在 AI 領域一樣關鍵。
   • Tag（Anthropic 內部大量採用的委派式工作流工具）目前佔了公司內部約 60% 的程式碼產出。Mike 說 Claude Code 主要用在需要高頻互動、迭代特定細節的任務,但大部分內部使用其實是透過「tag」來委派——例如標記 Claude 說「你現在負責這部分程式碼庫,監控某個回饋頻道,主動接手任務並修復,若某個 API 改變了也要處理」。這種多人協作、非同步、主動式的模式,讓他聯想到 Midjourney 早期大家都在同一個 Discord 上互相觀摩用法,進而提升彼此的「大膽度」。
   • 關於 code review 瓶頸：Anthropic 內部仍受限於人類「完整理解變動內容」的能力,而不只是審查時間不夠。因此他們推出 Claude Code artifacts（幾週前上線）,用來取代直接丟 2000 行程式碼的 PR,改成呈現「這個改動的意圖、做了哪些取捨」的說明。Mike 坦承自己收到 PR 時並非逐行審查,而是直接問 Claude「我有這些疑問,去幫我查」,屬於「Claude 驅動、人類主導」的審查模式;對於單純外觀/視覺類的小改動,則更傾向「有問題再修」而非事前審查。
   • Anthropic Labs 的組織結構：以兩週為一個週期進行「persevere or pivot」（堅持或轉向）審查,幾乎每個週期都會關閉一些專案。因為疊代速度太快,如果讓組織架構完全對應個別專案,會變成每兩週重組一次,因此改採「pod」制度：每個「bet（賭注型專案）」臨時從產品、工程團隊抽調人力組成小組,Mike 自己有興趣時也會加入;有一位「bet lead」/直接負責人,但通常不管理其他成員。工程經理（EM）的角色轉變為確保每個人被分配到他們最興奮、發揮最好的專案上,而非管理特定專案的人力。一旦專案成熟（如 Claude Design，六月做了第二次大版本更新）,才會固化成有專屬招聘、正式架構的團隊。
   • 關於 Claude Design 的未來：目前最大的限制是與其他 Claude 產品介面（如 Claude Code）之間互通性不足；他認為公司內部各服務之間溝通不夠順暢，限制了很多有趣的可能性。另一個方向是 Claude Design 與「app」之間的界線會越來越模糊——他已看到使用者用 HTML/JavaScript 在 Claude Design 裡做出功能完整的遊戲（儘管沒有資料持久化），未來會朝「可持久化資料、可分享、可繼續開發」的方向演進。
   • 被問到「你會刪除 AI／Claude 裡的什麼東西」（呼應他曾把 Burbn 精簡成 Instagram 的經歷）：他提到 Anthropic 內部有個 Slack 頻道叫「Project Unshipped」用來檢討現有功能使用率。他舉例最近下架了「Styles」功能，因為使用率低且做法過於「規定式」（prescriptive），而「Skills」是更好的替代方案。他認為最大的問題是要求使用者在 Code、Cowork、Chat 之間做選擇，這些介面彼此不能互通也無法互相委派任務，而且一般人根本說不出這幾個介面為什麼是分開的——他認為應該刪減這類產品複雜度,舉例：在 Cowork 裡規劃好了要建的東西,卻還要「請幫我寫一段可以貼到 Claude Code 的文字」,這種 2020 年代的工作流程不該再存在。
   • 關於新創是否還有存在意義（面對 Anthropic 可能發布顛覆某產業的東西）：Mike 說他加入 Anthropic 的主因之一，是看到模型將如何大幅降低實驗成本、加快新創的迭代速度——即便模型無法解決你的創意或品味問題。他以 Instagram 時期投資人問「Google 推出相片產品怎麼辦」為例：Google 只會做出「很 Google 風格」的產品，受限於既有整合，發揮自己的優勢，但無法做到真正深耕特定垂直領域或用戶群的理解與愛戴。他認為一組 4-5 個人專注於單一問題，會比在大型組織裡受制於複雜度的同一批人移動得更快；「寫程式碼」從來就不是新創成敗的限制因素，真正關鍵的一直是空間理解與用戶理解（領域知識）。
   • 關於金融領域應用（呼應 AIE 即將在紐約辦金融 AI 活動）：他觀察到模型在金融場景的能力隨世代提升明顯變好,已有專注金融垂直領域的新創做了自己的評測（eval），可作為模型是否真的在這些用例上進步的一個實用指標（barometer）。他認為未來的關鍵混合模式，是讓模型有彈性即時生成分析／儀表板／工作流程，同時建立在一組「經過驗證但不一定不可變」的資料基礎上——完全自由發揮的模式會造成混亂，不是金融業客戶想要的；找到「可驗證性＋稽核記錄」與「不限制應用彈性」之間的平衡點，是這個領域目前最需要的「藝術」。他也指出,現有為了可驗證性而設計的系統,往往在設計上就不太支援 agentic 工作負載,因此這個技術棧的兩端都存在機會。
   • 關於心理健康與過勞：他形容 Anthropic 每週三的全員大會固定有一張投影片叫「the week in AI」，即便才週三就已經有新模型、新產品、監管新聞等大量事件,顯示這個產業的變動速度遠超過他在 Instagram 時期（當時只需要關注一年一度的 WWDC 或每三四個月一次的競品發布）。他的因應方式：(1) 刻意安排離線時間,他親眼見過身邊親近的人因過勞倒下,需要很長時間恢復,因此強調沒有任何工作重要到不能離線幾天,若真的無法離線,就代表哪裡出了問題，該找導師談;(2) 借用運動比喻——「你永遠沒有你最好的一場比賽那麼好,也永遠沒有你最差的一場比賽那麼差」,並引用 Ben Horowitz《The Hard Thing About Hard Things》裡「我們完了」那種新創常有的絕望情緒,提醒自己 Instagram 也曾經歷過類似時刻但撐過去了；建議把眼光放遠,提醒自己「這是一場長期賽局」，不要讓自我價值感被每天的模型發布或產品上線牽著走。
   • 談到教練給他的建議：如果你自己感受到某種情緒（壓力、沮丧），團隊裡其他人很可能也有同樣感受，因此他會主動在會議上說出自己的情緒（例如「我對這個 Labs 專案收掉感到很難過」），這樣能為其他人打開表達空間，讓大家先說出真實感受，再一起討論下一步該怎麼做，會比壓抑情緒直接談解法容易得多。

   “「我認為第一代 AI 產品把它們塞進了太小的框框裡，限制了它們存取工具或自由度的程度，這讓人更難『不講理』地使用它們。」”

   “「寫程式碼從來就不是限制新創的關鍵因素——真正決定成敗的，一直是對空間與使用者的理解。」”

   “「你永遠沒有你最好的一場比賽那麼好，也永遠沒有你最差的一場比賽那麼差。」”

6. 6

   本體論驅動的語意層(Ontology-based Semantic Layer)：為企業AI Agent打造可信賴的共享資料基礎

   Emil Eifrim · Neo4j

   ▶ 1:38:32

   Neo4j 執行長 Emil Eifrim 分享企業建構 AI Agent 時的核心痛點：每個團隊各自手動串接資料來源，造成重複勞動且無法沉澱知識。他提出「本體論驅動的語意層」(Ontology-based Semantic Layer) 作為解方，主張讓「輕量 Agent 建立在更聰明的共享基礎之上」(thin agents on a smarter shared substrate)，透過業務本體、技術本體、執行軌跡三大支柱，讓資料發現、信任、治理與跨 Agent 學習成為可能。

   • 以銀行開戶 Agent 為例，Agent 大致可拆成兩塊：業務邏輯（理解意圖、規劃、執行的迴圈）與資料來源（Agent 執行時需要存取的資料，例如驗證身分需要串接 DMV 車輛管理局資料庫和護照驗證服務）。
   • 當組織內多個團隊各自打造 Agent 時，即便架構概念相似，仍會出現四大問題：(1) 每次都要從零手動找出資料位於哪個系統，企業環境往往有上百個資料庫（Snowflake、Databricks、S3 等），不像新創只有一個 Postgres 那麼簡單；(2) 找到資料後還要判斷資料是否正確版本、是否可信、是否有權限存取；(3) 違反軟體工程 DRY 原則（Don't Repeat Yourself），資料一有變動就得手動重新串接所有 Agent；(4) 缺乏學習機制，Agent 今天和明天一樣笨，也沒有跨 Agent 的知識累積，因為業務意圖與資料來源的對應關係都散落在程式碼和 prompt 裡。
   • 針對「用 Markdown 檔案 / skills 就能解決」的說法，講者認為這只是解方的一部分而非全貌，並引用一週前 Latent Space Podcast 上 Swix 的說法：「你們必須搞懂自己的資料庫，不能只靠 Markdown 來 vibe code」。
   • Neo4j 近期已為多家大型企業（一家財星20大的全球銀行、一家灣區大型科技平台公司、一家領先的金融科技公司）大規模解決此問題，歸納出的模式是：Thin agents on a smarter shared substrate（輕量 Agent 建立在更聰明的共享基礎之上）。
   • 該共享基礎由三大支柱組成：
   • 業務本體 (business-facing ontology)：定義組織內的關鍵概念與彼此關係（銀行案例中為客戶、帳戶、簽帳卡、支票、交易等），且必須用組織內所有人都看得懂的語言表達——例如要用「customer 有 first name」，而不是用像 `F_name` 這種技術欄位名稱。
   • 技術本體 (technical ontology)：涵蓋企業內所有資料來源與資料資產的中繼資料（metadata），例如有幾個 Oracle 資料庫、幾個 Neo4j 資料庫、Snowflake、Databricks、S3 bucket 等，記錄它們的位置與結構(schema)。講者提到可以用三種關鍵方式建構技術本體，但本次演講未展開細節。
   • 執行軌跡 (runtime signals / execution traces)：Agent 在圖上「走過」並實際執行任務時留下的紀錄，包括嘗試了什麼、是否成功、結果如何。
   • 兩個本體之間還需要建立映射 (mapping)，例如業務本體中客戶的 first name，對應到技術本體中某個 Oracle 資料庫裡名為 `F_name` 的欄位。
   • 以銀行開戶 Agent 為例說明整體如何運作：圖中結合業務概念（支票、帳戶、信用紀錄等）與一個「流程引導型 Agent」所依循的業務流程(business process)；在其中一個節點「check compliance（合規檢查）」，切換到技術本體層，可看出要完成合規檢查需要「政府核發身分證件驗證」，而該組織內對應到兩個可用的資料來源：車輛管理局(DMV)紀錄與護照驗證服務。Agent 執行時會依此選擇並嘗試，執行完後留下執行軌跡（去了哪裡、做了什麼、當下的情境脈絡、是否成功），最終產生一個分數，作為下次決策的輸入依據——例如如果 DMV 查詢過去在特定情境下成功率高，之後在相似情境會更傾向優先選用 DMV。
   • 這三大支柱合起來解決了前述四個問題：(1) 提供一個簡單方式來發現資料來源，並可從「上而下」（由管理員人工標註可信度）與「下而上」（由實際執行軌跡驗證何者真的有效）兩種方式知道資料是否可信；(2) 提供單一、受治理的地方來映射業務意圖與資料來源，資料一旦變動只需改一處即可讓所有 Agent 同步更新，符合 DRY 原則；(3) 具備自我學習能力，Agent 今天比昨天聰明，而且這種學習是跨 Agent 共享的，不只侷限在單一 Agent。
   • 整體效果是把企業從「厚重 Agent + 手動串接資料來源」的世界，轉變為「輕量 Agent + 更聰明的共享本體語意層」的世界，讓組織能大量擴展 Agent 數量，而不必每次都重新工程化。
   • 講者提到這只是圖資料庫應用在 AI 上眾多有趣模式之一，同場會議還有 Graph Track（在 2005 室），有 Gates Foundation、Monday.com、JP Morgan Chase、Berkeley、New York Times 等組織的相關演講,共約十個場次。
   • 針對新創公司，Neo4j 有專屬的 Startup Program，提供免費額度，並配有專職解決方案工程團隊每天免費協助新創做資料建模、效能調校等工作。

   “「Thin agents on a smarter shared substrate.」（輕量的 Agent，建立在更聰明的共享基礎之上。）”

   “引用 Swix 在 Latent Space Podcast 上的話：「Hey guys, you gotta learn your databases. You cannot vibe code with just markdown.」（你們必須搞懂自己的資料庫，不能只靠 Markdown 來 vibe code。）”

7. 7

   強化學習制導的ETL故障修復(RL-guided ETL Remediation)：AWS Glue資料管線的自動診斷與復原

   Annamarie Benzon

   ▶ 1:52:57

   這場 talk 分享講者 capstone 專案的成果：一個用強化學習（Q-learning）搭配規則式偵測與安全護欄，為 AWS Glue ETL 管線打造的自動診斷與修復系統。核心主張是把「事實判斷」「決策選擇」「權限把關」三者刻意拆開——規則負責認定事實、學習負責在有限範圍內做選擇、安全層負責最終把關，而非讓單一模型端到端決定一切。

   • 整體架構是事件驅動的閉環：現有的 AWS Glue ETL job 失敗會發出 job failed 事件，Amazon EventBridge 捕捉該事件並觸發執行 agent 的 Lambda function。
   • Lambda 從兩個唯讀來源蒐集證據：CloudWatch 提供錯誤日誌，Glue Data Catalog 提供目前的 schema metadata。
   • 系統利用這些訊號對故障分類、評估資料品質與操作風險，並建構出要傳給 RL 決策引擎的狀態（state）。
   • Policy（決策模型）會提出一個有邊界的回應方案；在 executor 透過 Glue API 重新觸發 job 或套用核准的修復動作之前，安全層會先檢查這個提案。
   • Amazon S3 用來儲存 agent 產出的成品、稽核日誌（audit logs）與隔離輸出（quarantine outputs）。
   • 最後 job 會被重新執行並驗證結果，整個流程形成一個緊密的操作閉環：監控 → 診斷 → 評分 → 決策 → 安全檢查 → 執行 → 驗證復原。
   • 這個 capstone 實作使用客戶提供的合成資料（synthetic data）；公開的 repository 則以經過淨化、通用化的部署範本保留同樣的設計模式。
   • 智慧層刻意切分成三個關注點：
   • 確定性的異常規則（deterministic anomaly rules）：用來確立可觀察的事實，例如欄位消失、型別改變、或 null rate 超過門檻。
   • Q-learning policy：負責有情境依賴的動作選擇——給定目前的事件狀態，該重試（retry）、強制轉型 schema（coerce）、回滾（rollback）、隔離（quarantine）、升級（escalate）,還是單純記錄（log）？
   • 安全覆寫（safety override）：存在於學習出的 policy 之外。例如當異常被判定為 critical，但 policy 提議的是像「記錄」這種被動動作時，override 會把這個選擇強制轉換為「升級」。
   • 講者將這種切分稱為整個專案的「設計論點」（design thesis）：規則負責事實（rules for facts）、學習負責有邊界的選擇（learning for bounded choices）、護欄負責最終權限（guardrails for authority）。
   • 在選擇動作之前，系統必須先確立「實際發生了什麼」，因此有以下幾個元件：
   • Schema profiler：擷取結構、型別、巢狀關係與 null-rate 統計量。
   • Drift detector：比對目前的 profile 與 baseline，找出新增、移除與型別變更。
   • Data quality analyzer：檢查完整性（completeness）、有效性（validity）、一致性（consistency）。
   • Error classifier：把日誌樣式（log patterns）對應到故障家族（failure families）。
   • Risk scorer：把上述訊號轉換成操作風險等級（operational risk level）。
   • 這些元件被刻意設計成確定性（deterministic）：對於可以直接觀察到的資料狀況，明確的規則比不透明的推論（opaque inference）更容易驗證與向外解釋、稽核。
   • 講者也承認：只要累積更豐富、有代表性的事件歷史資料，部分分類器未來有機會轉為學習型元件；但「ML ready 不等於 ML required」——每個決策應該交由「最簡單、可靠」的元件來負責，而不是預設都要上模型。
   • Policy 接收到的是一個精簡的狀態（compact state），包含：故障類別（failure category）、風險等級（risk level）、重試次數（retry count）、drift 嚴重程度、資料品質狀況；並從六種動作中選擇：retry、coerce、rollback、quarantine、escalate、log。
   • 選擇用 Q-learning 的原因：狀態空間與動作空間都很小，Q table 的計算成本很低，且每一次決策都可以被直接檢視——「對於這個狀態，各動作的價值是多少、哪個動作勝出」都能攤開來看，具有可解釋性。
   • 技術上，每一起事件都被建模為單一狀態（single state）（逐字稿在此中斷）。

   “「ML ready 不等於 ML required（ML ready is not the same as ML required）。」”

   “「規則負責事實，學習負責有邊界的選擇，護欄負責權限（Rules for facts, learning for bounded choices, and guardrails for authority）。」”

8. 8

   讓Token各司其職(Give Your Tokens Jobs)：Advisor、Grader、Dreamer多代理策略如何在固定預算下提升準確率

   Caitlin、Angela · Anthropic

   ▶ 1:56:51

   這場來自 Anthropic 的分享挑戰了「所有 token 都是等價可替換」的預設假設，主張透過讓不同 token 分工扮演不同角色（如顧問、評分者、反思者），可以在固定的 token 預算下大幅提升任務準確率。講者透過金融分析任務的實驗證明，同樣的預算下,「怎麼花」比「花多少」更重要。

   • 核心提問：目前建構 agent 系統時,唯一的槓桿通常是「加大預算」(花更多 token 或用更貴的模型),背後隱含假設是每個 token 都是可互換的(fungible)。講者質疑這個假設是否成立。
   • 提出「策略(Strategy)」概念：把原本單純「執行(Execute)」的 token,拆分一部分去做「其他工作」,執行者(executor)加上另一種角色的組合就構成一種策略。
   • Advise(顧問策略)：Executor 負責執行,但可以隨時呼叫 Advisor 尋求建議,用來確認下一步是否做對。應用案例：業務(sales)agent，advisor 可以提醒業務代表某個 follow-up 逾期或某筆交易卡關。
   • Grade(評分策略)：先定義一份「好結果長怎樣」的 rubric，Grader 依照 rubric 為 Executor 的每次嘗試打分；若不夠好就讓 Executor 重新迭代直到達標。應用案例：客服 agent 處理退款申請,用退款準則做成 rubric,Grader 檢查客服 agent 的判斷是否正確。
   • Dream(反思策略)：Executor 執行完後,Dreamer 會檢視 Executor 的工作記錄(transcript),萃取出發現並寫入記憶(memory),下一輪 Executor 會讀取這些記憶來改進表現。應用案例：招募(recruiting)agent，透過不斷累積「候選人是否合適」的回饋,讓下一輪判斷越來越精準。
   • 實驗設計：建立一個模擬真實金融分析師工作的 benchmark(財務分析相關任務),以「一個真實的專家分析師會做得多好」作為對照基準,分別測試 Execute(控制組)、Advise、Grade、Dream 四種策略。
   • 第一輪實驗(one-shot、不限預算)：各策略自行決定要花多少 token。Execute 準確率僅 15%，只用了約 39,000 tokens；Dream 表現最好,但用了高達約 600,000 tokens。講者指出這個結果無法證明「分工」本身有價值，因為預算差異太大，可能只是「花得多所以做得好」。
   • 第二輪實驗(固定預算)：把所有策略的預算統一鎖定在 Dream 消耗的最高值(約 600,000 tokens)。結果顯示：Execute 從 0.15 提升到 0.76；Advise、Grade 則從 60% 多提升到接近 90%。若 token 真的完全可互換,四種策略在同預算下應該表現一致,但事實上出現落差(例如 Execute 0.76 對比 Advise 0.89),證明「怎麼分配 token 的工作」確實存在可利用的優勢(alpha)。
   • 換一個更貼近真實商業的評分標準：講者指出,對財務分析師這種任務而言,80% 準確率在 benchmark 上看起來不錯,但現實中「不是 100% 準確就沒用」——因為不能捏造收入或成本數字。因此重新定義評分方式：只有 100% 完全正確才算「通過(pass)」，其餘一律視為失敗。
   • 以「完全正確通過率」重新衡量：在此嚴格標準下,Execute 的通過率為 42%，較複雜的策略可達 75%。
   • 真實成本換算：因為 Execute 只有約 40% 機率一次做對,平均需要跑 3 次才能拿到一個完全正確的答案；每次固定花費 600,000 tokens，換算下來平均要花費約 180 萬(1.8 million)tokens 才能得到一個「真正可用」的正確答案。將此邏輯套用到所有策略上，可得出每種策略要達成「一個完全正確答案」的真實總成本。結果顯示 Advise 和 Grade 在此換算下相對token效率最高。
   • 策略選擇取決於商業目標：若企業最在乎 token 效率／成本，應選擇 Advise 這類策略；若企業最在乎的是可靠性、必須最大化「拿到完全正確答案」的比例，則應選擇 Grade 或 Dream 這類策略。
   • 架構與實作層面：Anthropic 已為單一 agent 打造了成熟的 harness(即 Claude Managed Agents 所用的架構)。在此之上,他們建構了「meta-harness」層,即多代理協調與執行層,讓 Executor、Advisor 等角色可以協同運作；其中 Dreaming 等能力已可直接透過 Claude Managed Agents 開箱使用。
   • 有了這些原語(primitives)之後,組合策略變得相當容易：例如可以讓一個任務先執行並允許被 Advisor(範例中稱為 Fable)建議,再把結果送給 Grader 驗證,通過後再送進 Dreaming 記憶迴圈,讓下一輪表現更好——而且不必局限於講者展示的三種角色,使用者也可以自行發明新的「工作(job)」給 token。
   • Anthropic 的長期目標是讓模型與平台能夠「動態地」自動構建這些策略,但在此之前,他們鼓勵開發者現在就開始思考如何組合這些原語,「讓 token 各司其職」以在固定預算下達成更好結果。

   “「Tokens are not fungible.(Token 並非彼此可互換。)你可以用蠻力執行、砸更多預算,但如果你聰明地讓 token 各自扮演不同角色、嘗試不同策略,在固定預算內你更有可能得到更好的結果。」”

9. 9

   打造個人化AI研究作業系統(AI Research OS)：以純文字筆記取代NotebookLM與向量資料庫

   Paul Iusztin、Louis-François Bouchard · Decoding AI / Towards AI

   ▶ 2:09:54

   這場 talk 由 Decoding AI 創辦人 Paul Iusztin 與 Towards AI 共同創辦人 Louis-François Bouchard 主講，說明他們如何用純文字（markdown）筆記打造個人化的「AI Research OS」，取代 NotebookLM 與向量資料庫，解決研究筆記散落、AI 工具用完即忘的問題。核心主張是：AI agent 真正的瓶頸不是能塞進多少 context，而是能否有一套可持續累積、可被 agent 反覆查詢的「記憶與知識管理系統」，且這套系統必須架在既有的 AI 工具（Codex、Claude、NotebookLM）與個人第二大腦之間。

   • Paul 目前在 Obsidian 有超過 5,000 篇筆記、Readwise 另有 5,000 篇，還有散落在 Notion 和 Google Drive 的資料，且每月平均新增 250 個檔案，量非常龐大。
   • Paul 的痛點：每次開始新專案（寫文章、開新 code base、加新功能）時，很難從龐大的第二大腦中挑出真正有用、高訊號的筆記，「reading list 是墳場」——存下的推文、文章、YouTube 影片、GitHub repo 常常再也想不起來或找不到。
   • 他們想要的系統必須「個人化」：能反映使用者自己的思考方式、價值觀與寫作風格（voice），而不是通用工具給出的泛用答案。
   • Louis-François 說明自己的背景：曾是 AI 研究博士生,現在靠研究維生(做課程、寫影片腳本、幫企業做 training),Towards AI 團隊在幫客戶做專案的過程中也累積大量知識與洞見,同樣需要有效槓桿利用。
   • 重點強調：這套系統是給兩人各自需求打造、可依個人需求調整(adapt)的專案，而不是一個標準化產品；Paul 的用法和 Louis-François 的用法會有所不同。
   • 提出「該用哪個工具」的決策流程：
   • 若只是快速問答、單次查詢 → 直接用 ChatGPT / Claude 就好。
   • 若是需要多輪追問、大型專案、長 context 的任務,但只是一次性、不會重複的小改動(例如寫一篇文章)→ 用 Codex 或 Claude Code 這類 coding agent 即可。
   • 若是需要持續深挖、反覆優化、且研究來源需要長期保留、可被未來的 agent 重複引用(例如做影片時要記得之前做過哪些影片、避免內容重複)→ 才需要建立一個「筆記與來源會留存」的系統。
   • 分析 NotebookLM 的侷限:雖然很擅長消化內容、做研究、回頭查詢,但問題是「你不擁有它」——無法完全客製化、不是 agent-native、而且只是瀏覽器工具,對程式開發任務很弱。
   • 分析向量資料庫 + RAG pipeline 的侷限:在生產環境、產品規模下很強大,但需要額外基礎設施,對日常個人使用來說不夠「人性化」——難以快速瀏覽、檢查、手動編輯筆記內容,設置與維護成本高,不適合單純個人研究用途。
   • 因此他們選擇打造「個人化研究助理」:一個會隨時間不斷累積、像個人版維基百科(Wikipedia)一樣、且方便直接用肉眼檢查與使用的系統,裡面持續累加來源、文件、影片筆記、比較分析、實作紀錄、新研究主題等。缺點是設置門檻比直接打開 Claude Code 高。
   • 具體點出現有 agentic 工具的核心問題:用 Codex/ChatGPT 做研究時,你把連結、PDF、資訊餵給它,下一次開新的 session 又要重新貼一次,或要求它用「skills」重新讀取——而 agent 當場建立的結構、跑過的腳本,一旦對話結束就全部遺失,除非硬塞進一個 skill 裡,但這樣的 skill 只會越長越龐大、越難維護。
   • 核心洞見(全場論述的關鍵轉折):問題不在於「能餵給模型多少資訊」,而在於「未來能不能有效地重新利用這些資訊」。因為對 agent 而言,context window 必須同時扮演資料庫、檔案系統、記憶體、推理空間等所有角色,一旦對話結束,這些資訊就全部消失。
   • 因此他們的解法不是無止盡塞更多 context,而是建立「妥善的記憶與 context 管理機制」,並且盡量保留使用者的個人風格(personality),例如 Louis-François 做影片時希望系統能反映他自己的敘事調性。
   • 具體做法:用純文字(主要是 markdown 檔案)建立這套系統,方便 agent 與人都能輕鬆讀取、編輯與查詢。兩人都不是從零開始——Paul 已有數千篇筆記,Louis-François 也做過數百支影片、大量會議筆記,以及團隊幫客戶做專案累積的實戰知識,這些既有的龐大資料都要能被系統有效槓桿利用。

   “「這些餵給模型的資訊從來就不是瓶頸,真正的瓶頸是你未來能不能重新利用它。」”

   “「我的閱讀清單就是一座墳場。」”

   “「你需要的是介於這些(AI)工具和你的第二大腦之間的一套系統。」”

10. 10

    AI Agent工具層抉擇：CLI、MCP與Skill的取捨與資安防線

    Nikita Kothari · Salesforce

    ▶ 2:20:07

    這場 talk 由 Salesforce 的 Nikita Kothari 主講，核心主張是：打造正式上線的 AI Agent，真正決定成敗的不是模型大小或 prompt 工程，而是「工具層」（tooling layer）的設計。講者對比 CLI、MCP（Model Context Protocol）與 Skill 三種工具層的取捨，並提出選擇的判斷準則，同時強調資安防線必須建立在基礎設施層而非 prompt 層。

    • 做一個 demo agent 只要一個下午，但要把它變成可上線的產品可能要花一整季，因為團隊要處理可靠性、安全性與速度三個層面的問題。
    • 問題一：Context 爆炸——如果把 50 個工具的 schema 一次載入 agent 的 context window，任務還沒開始，60% 的思考空間就已經被燒掉；工具定義（例如監控資料庫、部署用的工具）會塞滿窗口，讓 agent 沒有空間思考。
    • 問題二：隱形失敗——舉例：agent 呼叫了 7 次工具去起草一個 PR，結果出錯，PR 被建立在錯誤的 branch 上，不僅浪費時間重做，還會讓人對 agent 執行任務的信心下降。
    • 問題三：安全稽核問題——凌晨兩點在調查客戶問題時，若 LLM 對查詢和租戶資料有過寬的存取權限，可能不小心存取到別的租戶資料，這在多租戶平台上不只是 bug，而是重大的合規風險。
    • 三種工具層的比喻：
    • CLI = 給人一支螺絲起子：直接執行，agent 跑一個指令、拿到輸出、繼續下一步。
    • MCP（Model Context Protocol）= 給人一個 USB-C hub：通用轉接頭，可以接上任何服務，"knows what is available"。
    • Skill = 給人一本操作手冊（run book）：一步步的結構化執行流程，"knows how to do it"。
    • CLI 的優勢：可讀（任何工程師都能看懂指令在做什麼）、可重現（半夜出錯時可以在自己機器上複製貼上重跑同樣的錯誤）、可組合（可以把多個指令串接 pipe 起來）。判斷原則很簡單：如果工程師能打開終端機做這件事，agent 大概也應該能做同樣的事。CLI 已經被使用超過 50 年，雖然不炫,但久經驗證。
    • MCP 的運作方式：一端接雲端服務、程式碼工具，另一端接工作追蹤、程式碼搜尋、錯誤追蹤、監控等不同服務（例如 Git、Slack、Google）。範例：agent 呼叫 code search 的 search 方法，得到結構化結果，背後會處理跨數百萬檔案的索引，並在伺服器層強制租戶隔離（tenant isolation）。透過 MCP 協定連接外部服務時，會有身份驗證（auth）與權限授予機制，這正是解決安全問題的方式。
    • Skill 的運作方式：Skill 是包裹在工具外層的結構化手冊，定義嚴格的編排流程——當條件滿足時，先確認前置條件存在，接著依序執行步驟一、二、三，使用 CLI、MCP 並明確處理各種例外狀況。它能避免瞎猜、節省記憶（context）、且可標準化——例如可以指定某個 Skill 只連接兩個特定的 MCP，不需要每次都翻遍所有 MCP 工具。講者提到這是他最喜歡的工具，已經用 Skill 把自己工作上大部分流程自動化。
    • 實測數字：同時保持 55 個工具、來自 5 個不同 MCP 伺服器處於啟用狀態，會造成延遲與平台問題；先燒掉 15,000~20,000 tokens 才開始執行任務，等於在 agent 開始前就已經損失大量 context。
    • 案例：修復測試失敗 ——不需要遍歷所有 MCP 工具，只需要查 log、查 release log 和 GitHub 即可修復測試失敗。
    • 案例：起草 PR 的 Skill——步驟一是理解本地變更，用輕量的 CLI 指令而非厚重的 API；接著用 git 指令在正確的 branch 上建立 PR。整個流程可以寫成明確步驟，做成 Skill 並持續調整優化。
    • 案例：半夜調查客戶 Bug——流程通常是查 log、搜尋錯誤模式、檢查最近的 release 是否有相關程式碼問題。因為流程已知，可以用有限數量的 MCP 工具加 CLI，做成一套世界級的除錯 Skill 來自動化。
    • 資安黃金原則：在基礎設施層（infrastructure）強制隔離，絕不是在 prompt 層。因為 prompt 可能被注入（injection），但基礎設施不能被繞過。
    • CLI 的風險半徑（blast radius）是完整的 shell 存取權限，緩解方式必須包含沙箱化（sandboxing）與嚴格的容器化（containerization）。
    • MCP 的風險半徑限縮於明確暴露出來的工具，並且租戶隔離必須在伺服器層被保證。
    • 安全原則清單：不要與 agent 共享任何憑證（credentials）；租戶隔離必須由基礎設施強制執行；用權限閘門（permission gates）在安全層做把關；執行任何任務時都給予最小權限（least privilege）。
    • 選擇工具層的三個判斷問題：
    • 誰還需要用這個？ 只有這個 agent 用 → CLI；多個 agent 要共用這個服務 → MCP；多個工作流程共用同一套流程 → Skill。
    • 最在意哪種失敗模式？ 需要透明度與可重現性 → CLI（因為 agent 的黑盒行為難以重現）；需要租戶隔離驗證 → MCP；需要嚴謹的步驟順序（sequencing）→ Skill。
    • Context 空間是否充裕？ 空間寬裕 → 可以用 CLI 或探索多個 MCP 工具；空間非常緊 → 必須用 Skill 層，並依需求即時（on-demand）調度 MCP 工具，以節省成本、改善延遲。
    • 三個架構總結建議：
    • 保持 context 乾淨——不要把所有可用的 MCP 工具都塞進來，盡量把工作流程轉換成 Skill。
    • 可移植性是有代價的（Portability has a cost）——MCP 伺服器很強大，但會引入網路延遲、協定抽象層與基礎設施複雜度，因此只該為了共享服務、索引、隔離等場景，刻意付出這個代價，MCP 要謹慎選用。
    • 不要對使用 CLI 感到不好意思——CLI 已被使用 50 年，具高度可組合性、可除錯性且久經沙場考驗；同時要擁抱 agent 框架，把工作流程轉成 Skill，並且把 Skill 當作程式碼（code）來管理——每次修改都要經過同儕審查（peer review），並持續更新迭代。

    “"Enforce the isolation in your infrastructure, never in your prompts. So prompt can be injected, but the infrastructure cannot."（把隔離機制建立在基礎設施上，絕不是在 prompt 裡——因為 prompt 可能被注入，但基礎設施不會。）”

    “"Never be embarrassed by the CLIs. It's been 50 years we are using the CLIs. They are highly composable, debuggable, and battle tested."（不要為使用 CLI 感到不好意思，我們已經用了 50 年的 CLI，它們高度可組合、可除錯且久經考驗。）”

    “"Keep your skill as a code."（把你的 Skill 當作程式碼來維護管理。）”

11. 11

    用HTML而非畫布思考：讓Coding Agent產出簡報、文件與影片等視覺成果

    Amol · Nori Agentic

    ▶ 2:33:37

    這場 talk 主張多數人誤解 coding agent 只會寫程式碼，其實它們能產出簡報、文件、影片等視覺成果——關鍵不在於模型能力不足，而在於給錯了媒介。講者 Amol（Nori Agentic CEO）提出：與其讓 agent 用「畫布」思維工作，不如讓它用 HTML 這種以結構與語言為核心的媒介來思考視覺呈現。

    • 全球每天大約投入 34,000 人年在製作簡報上，但大部分時間不是花在「思考內容」，而是花在「排版微調」；一份要花 10 小時做的簡報，扣掉格式、品牌、位置調整這些瑣事，其實核心工作只需要約 25 分鐘。
    • 傳統簡報工具（PowerPoint、Slides、Figma、Canva）都是為「人類的手和眼睛」設計的：點擊、拖曳、放置、對齊格線，這些都是符合人類空間感知的操作模式，底層雖然有資料結構，但格式只有該應用程式自己讀得懂。
    • 當把這些畫布類工具交給 agent 使用時，輸出往往一團糟：元素重疊、文字看不清、對不齊，效果很差。
    • AI 懷疑論者認為問題不只在工具，而是 agent 從根本上就無法對「空間」進行推理，並舉出像 ArcAGI 這類專門測試空間推理能力的基準。
    • 引用開發者 Simon Willison 著名的測試：要求每個新模型畫一隻「騎腳踏車的鵜鶘」，但限制只能用 SVG 作畫，用來快速檢驗模型的空間推理能力；結果顯示模型畫出來的成品普遍非常糟糕。
    • 講者反駁「模型注定畫不好圖」的說法，主張問題不是模型能力，而是媒介選錯了：如果要求一般人手寫 SVG 畫出鵜鶘，人類同樣做不到，因為 SVG 只是一堆數字，人腦無法從「一堆數字」直接聯想到「鵜鶘的樣子」——人類是靠圖像思考,而非數字座標思考。
    • 現有的 agent 視覺化工具（Figma MCP、PowerPoint CLI、截圖再替換的迴圈等）本質上都是模仿人類操作畫布的方式，但這對 AI 來說是不合理的類比——就像要求人類手寫 SVG 一樣，AI 不是人類,不應該被要求用像素（pixel）思考,而應該用它擅長的「語言」——文字、token、結構——來工作。
    • HTML 是理想的媒介：它非常擅長描述版面配置(layout),模型在訓練過程中看過數十億筆 HTML 範例,對其有直覺式的理解;HTML 標籤本身帶有語意(如標題、圖表、網格),瀏覽器負責把這些結構渲染成像素,模型全程不需要自己計算座標,卻能免費獲得圖表、排版、字型、動態效果等各種視覺效果。
    • 同樣要求模型畫「騎腳踏車的鵜鶘」,但這次改用 HTML 而非 SVG,成品明顯更好——因為模型是在一個它能推理的「結構」中作業,而且每一行都可以被讀取、套用主題(theme)與編輯。
    • 講者反思:「簡報」(slide deck)和「PowerPoint」長期被誤認為同義詞,但其實 PowerPoint 只是一種製作工具,簡報檔案本身只是「呈現模式」(presentation mode);觀眾根本不在乎你是用什麼工具做出這個呈現模式的,因此「編輯格式」其實是可以任意選擇的——可以選擇 agent 已經很擅長的 HTML 來編輯,有需要時再轉存成 PDF 等其他格式。
    • Nori Agentic 內部實際使用這套 HTML 技巧來製作所有的簡報,包括董事會報告(board deck)和銷售簡報(sales deck),這些都是真實會拿去發送、簡報的正式文件。
    • 同樣的方法也用在公司文件(docs)上,讓文件呈現出更有色彩、更有活力的視覺效果,同時仍遵循公司品牌規範。
    • 甚至連影片也是用這個方法做出來的——講者展示的影片其實完全就是 HTML 和 CSS 構成,「從頭到尾都是 div」。
    • 講者主張:幾乎任何內容,只要加上一點結構(structure)和一點色彩,呈現效果都會更好;純文字只是一種「圖方便」的選擇,但如果真的想做出有價值的東西,純文字通常不是正確的選擇。
    • 講者也提醒:光有漂亮的簡報本身其實沒有價值,重點還是要把「內容」填進去——但同樣可以用「像模型一樣思考」的方式解決:只要把資料(例如通話逐字稿、email)開放給模型存取,就能讓模型端到端(end-to-end)直接生成整份簡報,讓 agent 處理所有繁瑣的資料整理工作,人類則專注在願景與敘事(story)上。
    • 這正是 Nori Sessions 這項功能提供的能力——講者提到自己曾經在通勤地鐵上用手機完成整份董事會簡報,因為 Nori bot 已經深度整合進公司的日常運作結構中。
    • Nori Agentic 產品本身已內建這一整套機制,講者建議聽眾不需要自己重新造輪子(don't reinvent the wheel)。

    “「Forget the name for a second. Coding agents can do almost anything. There's just one trick. You have to be able to think like an agent to get it to do what you want it to do.」(先別管「coding agent」這個名字,它們幾乎什麼都能做,關鍵訣竅只有一個——你必須學會像 agent 一樣思考,才能讓它做出你要的東西。)”

    “「If you ask me, it's not the model, it's the medium.」(依我看,問題不在模型,而在媒介。)”

    “「Stop thinking like a user. Think like the model. Give it the right language, and for graphics, all you need is HTML.」(別再用使用者的思維去想,要像模型一樣思考。給它對的語言——對視覺圖形來說,你只需要 HTML。)”

12. 12

    婚禮場館AI客服的品牌聲音架構：不可變身分、情境模式、語氣與生成後審核四層堆疊

    Isadora · Threadline

    ▶ 2:40:20

    這場 talk 講者 Isadora 經營一座有225年歷史的維吉尼亞婚禮場館,並打造了與新人對話的 AI 客服,後來也將此技術延伸至其他場館、個人 AI 陪伴 App,以及一個協尋失蹤人口的公共服務工具 Threadline。她的核心主張是:與其把 AI 當成「寫規則就能放著不管的機器人」,應該把它當成「IQ 很高但 EQ 很差的實習生」來管理,因此需要一套結構——把品牌聲音拆成「不可變身分、情境模式、語氣錨定、生成後審核」四層堆疊,而不是塞進單一個系統提示詞裡。

    • 講者強調框架的重要性:如果把 AI 當機器人,你只會寫規則然後放著;但如果把它當成一個「記憶力驚人但完全不懂看場合」的實習生,你就會知道需要建立結構,並在東西送出門前先檢查。
    • 業界標準做法是寫一份詳細的系統提示詞,描述品牌聲音、給範例,這種做法在「happy path」(你事先想到的所有問題)上確實有效,但一旦遇到範例沒涵蓋的情況(她舉例「第21輪對話」),模型會說出技術上正確、但品牌絕對不會這樣說的話。
    • 這個問題在「聲音即產品」的場域最致命——不是零售網站的商品搜尋,而是高端飯店、頂級房仲、或她自己的婚禮場館這類靠30年關係經營出來的品牌,一句說錯的話造成的損失可能遠超過退款金額,而且付費的客人正是最會注意到這種細節的人。
    • 她指出問題根源不是範例寫得不好,而是「要求同一個 prompt 同時做四件完全不同的工作」——很難有單一層同時兼顧情境判斷、表達溫度、自我審核。
    • 她提出的四層架構:
    • 第一層「不可變身分(immutable identity)」:品牌在結構上絕對不能說的話,是硬性規則,不能被下層任何設定(場館設定、使用者指令等)覆寫。
    • 第二層「情境模式(situational mode)」:隨使用者狀態與即時條件變化——對方是誰、正經歷什麼、當下情境如何。
    • 第三層「範例錨定的語氣(example-anchored voice)」:溫暖感、慣用語、語氣刻度盤,這是大多數團隊唯一會做、也止步於此的部分。
    • 第四層「生成後否決(post-generation veto)」:低成本的最後一道檢查,用來攔截前三層都漏掉的錯誤。
    • 她說明單層做法失敗的原因:一個系統提示詞無法同時做到「隨情境調整」、「有表達力」、「自我檢查」三件事,結果中段勉強應付,但邊緣情況就崩潰。
    • 在導入這套架構之前,她的系統裡散落著24種不同的系統提示詞,分別叫 Sage、無名、Venue 等,每個介面對「自己是誰」都有各自的認知,身分不一致。
    • 現在所有介面都透過同一個組裝流程(single assembly)產生系統提示詞,取代原本24個各自為政的版本,順序是「有承載意義的(load-bearing)」——硬規則排最前面,任務型指令排最後面。
    • 她用 Google 地圖比喻整個架構:目的地永遠一樣,但「路線」——也就是對這位使用者當下最正確的回應與語氣——會變動。地圖知道路況、施工,但不一定知道哪裡油最便宜;同理,你的 prompt 堆疊也要先把這些條件納入考量,再決定怎麼回應,而不是走錯路之後才發現施工。
    • 第一層是「不管走哪條路都成立」的規則,例如開車前要有駕照、高速公路不能倒車。
    • 第二層是即時路況。
    • 第三層是這趟旅程的個人偏好。
    • 第四層是出發前先檢查路線。
    • 所有東西在同一個地方組裝,每次都以固定順序執行。
    • 第一層範例1——AI 揭露身分規則:若對方問是否在跟真人、真人客服、機器人或 AI 對話,系統必須在「下一則訊息」就清楚明確承認自己是 AI,這條規則不能被場館設定、語氣人設或使用者要求覆寫。她所有的 AI in Bloom 產品都會在「第一則回覆」就主動揭露自己是 AI,不是等對方問才說。她強調這是「產品決策,不是法律決策」——他們賭的是:一開始就知道在跟 AI 對話的新人,會比在第七輪對話才發現真相的人更信任這個系統。這條規則凌駕於整個架構之上,讓「不小心破功」變成不可能發生的事。
    • 第一層範例2——「沒有實體身體」的邊界:AI 是軟體,沒有身體,不能親自帶人參觀場地或見面,因此絕對禁止說「我很樂意帶你參觀」或「我等不及要見到你本人」這類話,允許的說法是「我們團隊很樂意招待您參觀」。她解釋:第三層(語氣層)追求溫暖、且用 AI 常會用第一人稱表達親密感,但沒有身體這個事實會讓那種不受約束的溫暖變成一句謊言。而且這種謊言被拆穿的那一刻,使用者發現自己一直在跟一個「其實根本不存在」的對象「假裝經營關係」,信任不只是下降,而是直接反轉——人們永遠會注意到。
    • 跨產品驗證案例——Threadline:這是她為失蹤人口家屬打造的工具,語氣風格跟婚禮場館完全不同,但架構完全相同。第一層有一條最關鍵的規則:系統永遠不能使用「confirmed(已確認)」「identified(已辨識)」「matched(已比對成功)」「proven(已證實)」「linked(已連結)」「solved(已破案)」這類字眼。原因是:對婚禮場館而言,第一層是防止 AI 假裝有身體,說溜嘴頂多尷尬;但對協尋失蹤人口的工具而言,第一層是防止 AI 在毫無把握的情況下告訴一位苦等多年的家屬「你的孩子找到了」——這種傷害不只是語氣失誤,而是產品可能造成的最嚴重傷害。模型會因為統計上「match」是自然而然會選的詞而順口說出來,而且會用同樣自信的口吻說,但這種自信絕對不該用在正在承受悲傷的人身上。她強調重點從來不是規則本身的內容,而是「品牌能說什麼」必須被鎖在一層,不論語氣模型訓練得多好、多有自信,都物理上無法觸碰。
    • 第二層(情境模式)開始說明:多數團隊根本不會建立這一層,只寫一份系統提示詞發給所有人,不管對方是誰、正在經歷什麼。Google 地圖不會這樣——它會考慮路況、可能知道你偏好風景路線,這些都是在「決定路線之前」就納入,而不是事後才調整。第二層就是把這些即時訊號在執行前就內建進 prompt。第一個情境條件是「依對話對象調整」:同一套 AI 既要跟新人對話,也要跟場館員工簡報,目的地相同但走的路完全不同——面對協調人員(coordinator)時,規則要求它要像對待同事一樣說話,而不是像對待客戶,絕不能混淆這兩種角色設定。
    • (逐字稿在此處中斷,第三層「語氣錨定」與第四層「生成後審核」的細節內容未在本段逐字稿中提及。)

    “「I'm not programming a robot. I'm managing a brilliant intern with an incredibly high IQ and a terrible EQ.」(我不是在寫程式控制一個機器人,我是在管理一個IQ極高、EQ極差的優秀實習生。)”

    “「The moment a user realises they have been performing a relationship with someone who is never there, the trust doesn't just dip, it inverts.」(當使用者意識到自己一直在跟一個根本不存在的對象假裝經營關係時,信任不只是下降,而是直接反轉。)”

    “「The word match said to someone who has spent years not knowing what happened to their child is not just a tone violation. It is the single most damaging thing that a product could ever do.」(對一個多年來不知道孩子下落的人說出「比對成功」這個詞,不只是語氣失誤,而是一個產品所能造成最嚴重的傷害。)”

13. 13

    讓Agent能自行註冊使用服務：WorkOS提出的auth.md開放規範(以Cloudflare部署案例示範)

    Michael Greenwich · WorkOS

    ▶ 2:50:00

    這場 talk 主張:當前 AI Agent 已能自主完成長時間、跨小時甚至跨天的複雜開發任務,但 Agent 卻無法自行「註冊」使用網路服務——因為現有的登入/註冊系統都是為人類設計的,反而把 Agent 擋在門外。講者提出開放規範 auth.md,專門解決「Agent 自主註冊」這個被忽略的環節,並以 Cloudflare 為例展示 Agent 全自動完成部署、註冊、取得 API 金鑰的完整流程。

    • 軟體工程演進三階段:一年前是「人類寫一點、AI 補一點」的交互式協作;接著出現 Ralph loop 等自動化嘗試;現在則是「單一 prompt → Agent 跑數小時甚至數天,獨立完成整個功能甚至產品」,且可平行跑多個 Agent,瓶頸變成人腦能同時追蹤多少個進度。
    • 講者用自駕車比喻這個轉變:過去車子有儀表板、地圖,人類全程參與駕駛;現在的 Waymo 讓你上車說目的地就自動抵達,介面被「刪除」了。他分享第一次搭 Waymo 被震撼,但三秒後就開始滑手機——說明自動化很快變得理所當然,軟體工程也正走向同樣的「拿掉人類介面」階段。
    • Agent 要能成功執行任務,需要五個要素:Runtime/Sandbox(安全、高效能的執行環境)、Tools(能在真實世界採取行動)、Context(否則再聰明的模型丟進不熟悉的專案也做不了事,就像把最聰明的人丟進一家陌生公司)、Feedback(能自我驗證、修正)、以及 Human review(程式碼審查或其他評估機制確保對齊目標)。
    • 「LLM 是引擎,Harness 才是整台車」:模型（引擎)本身動力再強,沒有底盤、變速箱、傳動系統(即 Harness)也無法真正把你載到目的地。模型進步時,Harness 也要跟著演進,這是新興的「Harness Engineering」領域。
    • Agent 在執行任務時會自行「選擇供應商」:需要資料庫、部署服務、寄信服務、圖片處理等,Agent 會自己去研究並挑選廠商。講者觀察到有些新創的成長曲線暴衝,正是因為被大量 Agent 選中使用。因此他認為現在「為 Agent 打造產品」可能比「為人打造產品」更重要。
    • 引用 Y Combinator 名言「Make something people want」,講者提出應該延伸為「也要 make something agents want」——未來 Agent 數量會超過人類(甚至現在已經是),而且它們決策更快、代替人類做選擇。
    • 核心問題:今天多數服務對 Agent 是「沒開門」的。原因是過去 20~30 年網路一直在防堵自動化流量(DDoS 防護、防刷卡攻擊、登入框刻意設計得難以被自動化通過),導致「好的自動化用戶」與「壞的自動化用戶」難以區分。他還提到一個諷刺現象:雲端瀏覽器執行環境的賣點之一竟是「幫你破解 CAPTCHA」,顯示 CAPTCHA 機制已經名存實亡,而且詐騙、token 濫用依然猖獗。
    • 傳統註冊流程假設使用者是人類:能讀懂 landing page、填表單、輸入 email/密碼、解 CAPTCHA、收驗證信並點擊連結、挑選付費方案、複製貼上 API key、使用 dashboard。但 Agent 通常沒有 email,也不會「點開一個東西」,這些流程對 Agent 完全不適用。
    • Agent-native 註冊需要新的能力:Native discoverability(能否自主發現並註冊某服務)、Capability declaration(服務能做什麼)、Registration intent(註冊目的為何)、風險評估(判斷這個自動化用戶是好是壞)、身分驗證(例如 Claude 這類系統可以帶著使用者身份一起註冊,而像 OpenClaw/Pi 這類 harness 可能無法帶身份,需要額外的 out-of-band 驗證)、組織身份的傳遞(公司身份如何帶入)、權限(entitlement)等,幾乎所有環節都要重新設計。
    • 講者強調「MCP 還不夠」:他自稱是 MCP 的頭號粉絲(WorkOS 辦過多場 MCP 活動),MCP 很擅長連接、提供工具/技能/上下文,但沒有解決「註冊」這一步——今天透過 MCP 做驗證仍然需要人類在迴圈中給予同意(例如手動把 PostHog 的 MCP server 加到 Claude 裡並用自己的帳密登入)。而 Agent-native 註冊需要的是「一開始就不需要人類介入」。
    • 提出開放規範 auth.md(理由:「markdown 文件就是未來」):這是一份指示文件,告訴 Agent 如何合法地成為某服務的使用者、如何被視為「合法」並取得存取權。目標是讓服務提供者能提供 Agent-native 的註冊體驗,但完全建立在既有標準(OAuth 規範的既有工作)之上,而非發明一套全新複雜系統。auth.md 刻意只解決「註冊」這個窄範圍問題,不試圖一次解決 Agent 身份、權限、長效連接服務等所有問題——「先從小處著手,再逐步擴展」。
    • auth.md 可以回答的問題包括:這個服務做什麼?Agent 該如何註冊?接受哪些身份證明方式?支援哪些驗證流程(SSO、email、MFA)?有哪些 scope 和權限(entitlement)?免費層級的限制是什麼(例如可以先給 Agent 一點免費額度,直到驗證或付費);之後人類或組織要如何「認領」這個由 Agent 建立的帳號。
    • Demo 情境(現場實際可操作,非純概念):使用者在 Pi 或 Claude 等 coding harness 中請 Agent 幫忙,想把本機(localhost)專案分享給朋友,但本機服務只能本機存取。Agent 主動提議去尋找「支援自主註冊」的部署服務——它會查詢各服務是否透過 auth.md 宣告支援註冊,範例中虛構的 Stratus、HelioDeploy 不支援,但 Cloudflare 支援,於是 Agent 自動選擇 Cloudflare。
    • 註冊環節的運作機制:Agent 產生一個「身份斷言(identity assertion)」交給 Cloudflare,Cloudflare 可以選擇直接驗證,或走 out-of-band 驗證,auth.md 在這裡設計得很有彈性,可依應用場景不同調整(例如資料庫服務資訊敏感度低,可以先給一些免費用量;若是碰觸實體世界或寄送 email 這類服務,可能完全不願意先免費放行)。
    • 標準名稱是 IDJAG(Identity JSON Access Grant,身份 JSON 存取授權):Demo 中 Cloudflare 同意先讓 Agent 免費部署 72 小時,並透過 IDJAG 換發存取權杖,整個過程使用者完全沒有手動點擊任何註冊畫面,Agent 直接取得 token,接著自動寫 Wrangler 設定、完成部署上線。講者提到全程他給 Agent 的指令幾乎只是不斷回答「對,去做吧」,凸顯整個流程可以做到「一次到位(one shot)」。
    • 架構圖說明:Agent harness(例如 Pi)內含 LLM、記憶、上下文層,連接到背後的身份服務(代表使用者身份);Agent 向目標服務(如 Cloudflare 或已合作的 Firecrawl)發出 discovery 呼叫尋找 auth.md;送出 IDJAG(代表身份的簽章憑證);換回實際的 API access token;之後就能正常呼叫 API 或 MCP——換言之 auth.md 只介入「註冊」這一步,其餘 API、文件都不需要改變。
    • 商業意義:對開發者而言,這讓 Agent 能「端到端」完成任務,不必被中斷去手動註冊一堆服務(講者表示自己討厭規劃步驟,寫完 prompt 就想要 Agent 直接把原型跑起來給他看,而不是回報一份「請去註冊這些服務」的清單);對服務提供商而言,這相當於開啟一個全新的成長漏斗——從只服務人類,擴展到服務全世界的 Agent,如同過去的 PLG(Product-Led Growth)/免費增值策略,能帶來立即的成長爆發,即使不是每個 Agent 建出來的東西都會真正上線或長久使用,但只要有足夠比例會留存,就能帶來規模成長。
    • 關於付費:「有使用就有付費意圖」,雖然已經有像 x402 這類基於加密貨幣的 Agent 支付協議在發展,但講者認為付費應該放在下游而非上游——不該強迫 Agent 一開始就綁信用卡才能使用(SaaS 產業早已從這種模式走出來),auth.md 讓 Agent 可以先註冊、先使用,之後再依服務商自訂的方式與定價下游付費。
    • 引用 Salesforce CEO Marc Benioff 的話佐證趨勢:「我們的 API 就是 UI」,整個 Salesforce 與 Agentforce/Slack 平台現已全面以 API、MCP、CLI 形式開放——一家常被視為「傳統 SaaS 廠商」(且正是「軟體即服務」這個類別的發明者)如今正在拿掉自己的 dashboard/UI,全力押注 Agent 優先。
    • 開放性與可取得性:auth.md 是公開規範,有 GitHub repo,WorkOS 提供托管版本但並不「擁有」這個規範,任何人都能自行在自己的系統中實作、自行架設,講者強調「沒有單一廠商應該壟斷這個規範」。
    • 結尾類比:講者提到 2007 年 1 月 Steve Jobs 在(幾乎同一地點)Moscone Center 發表初代 iPhone,催生了智慧型手機平台革命,無數公司因此而生;他認為自己在 B2B SaaS、雲端時代所做的一切都很棒,但唯有那次是真正全新的軟體平台典範轉移——而他相信 Agent 正是下一次同等級的浪潮,呼籲大家現在就該開始為這波「Agent 經濟革命」動手打造產品。

    “「Today, actually, it might be more important to build for agents than to build for people. Agents are kind of this new consumer class.」(如今為 Agent 打造產品,可能比為人類打造產品更重要——Agent 正是一種全新的消費者階層。)”

    “「I'm sorry to say MCP is not enough.」(很遺憾,MCP 還不夠——它能連接、能提供工具與上下文,卻沒解決 Agent 註冊這個關鍵缺口。)”

    “「Where there's usage, we believe there's also intent to pay.」(有使用,就有付費的意圖——但付費應該發生在下游,而非強迫 Agent 一開始就綁卡。)”

14. 14

    百人工廠打造36個AI Agent傳承企業記憶：MachineCraft的公司「數位分身」實踐

    Ruchabh · MachineCraft

    ▶ 3:11:00

    這場 talk 講述印度百人工廠 MachineCraft 如何在沒有資料科學團隊、沒有 ML 預算的情況下，將三代人腦中累積的公司知識轉化為一個名為 ERA 的「數位分身」系統，最終發展出 36 個 AI Agent 支撐公司整個 go-to-market 流程。核心主張是：公司真正的資產不是機器，而是知識，而知識若只存在人腦裡就會隨著人員流動而流失，因此要打造的不是聊天機器人，而是一個能持續學習、進化的「公司分身」。

    • MachineCraft 表面上是做機器金屬加工的工廠，但真正有價值的部分是知識：誰是客戶、2019 年報價多少、某台機器需要什麼客製化調整等等。
    • 這些知識三代以來只存在三個人的腦袋裡：先是祖父、然後是父親、現在是講者自己，講者認為這種傳承方式「真的很可怕」。
    • 公司人員流動頻繁，每次有人離職，一部分公司「腦容量」就跟著離開；講者強調他們害怕的不是競爭對手，而是「遺忘」——擔心有天醒來發現整間公司的知識只剩兩顆越來越疲憊的腦袋。
    • 因此講者的構想是：與其把知識寫成沒人會讀的文件，不如「養」一個大腦來承載這些知識——不是讓人戳一戳的聊天機器人，而是公司的「分身」（twin of the company）。
    • 業務情境本身很複雜：MachineCraft 生產熱塑成型機（thermo-forming machines，加熱塑膠板並塑形），但同一台核心機器可以做出水耕農場托盤、SPA 浴缸、電動車面板、醫療器材外殼、包裝等完全不同的產品，橫跨七個完全不同的世界、七種不同的買家。因此這個「大腦」不能只是背誦型錄，必須能判斷眼前這位客戶屬於哪個應用領域。
    • 第一步做法很單純：把「所有東西」都餵給系統——多年的報價單、圖紙、付款排程、時間表、email 往來紀錄，總共數百 GB 的公司私有歷史資料，而非公開網路資料。
    • 關鍵轉折：他們從未訓練或微調任何模型，也沒有 GPU 在跑訓練。做法是把歷史資料切成小塊（chunks），用現成的（off-the-shelf）模型去讀取並萃取事實，再將每個 chunk 的語意存成向量（vectors）以及實體間的關聯（relationships），形成一個組織良好的「記憶庫」（類似知識圖譜）。
    • 團隊後來不再把 ERA 當作一套軟體看待，而是當作一個「正在養育（raising）」的東西——仿照生物結構賦予它一個「身體」：有「感官」判斷正在跟誰對話、有「腸胃」把文件消化成事實、有「記憶」、有「做夢週期（dream cycle）」、還有「免疫系統」來抵禦錯誤資訊。
    • 選擇仿生物架構的原因：演化已經花了十億年解決「如何長時間維持一致性/連貫性」這個問題，團隊選擇直接沿用這套「作業」而非重新發明。

    “「我們不是害怕競爭對手，我們害怕的是遺忘。」（We weren't scared of the competitors, we were scared of forgetting.）”

    “「如果與其把知識寫進沒人會讀的文件，我們養一個能承載知識的大腦呢？不是讓你戳一戳的聊天機器人，而是公司的分身。」”

    “「我們不再把 ERA 當成軟體，而是把它當成我們正在養育的東西。」”

15. 15

    Harness Engineering實戰：以Strands Agents SDK與Amazon Bedrock AgentCore部署可規模化的AI Agent(含現場程式演示)

    Mike Chambers · AWS

    ▶ 3:14:53

    這場 talk 由 AWS 資深 AI 專家開發者關係 Mike Chambers 主講，核心主張是「Agent」分成兩種：我們使用的 agent（如 Claude Code、Cursor）和我們建構的 agent，後者才是「harness engineering」的重點——當要把 agent 部署到雲端規模時，必須把記憶、身分、技能、runtime、context 管理等元件拆開獨立擴展，而不是全部塞進一個容器。講者透過 Strands Agents SDK 與 Amazon Bedrock AgentCore 做了多段現場程式演示，展示從本機簡易 agent到具備 session 記憶、最終部署到雲端規模、具多租戶隔離與長短期記憶的完整流程。

    • 講者定義兩種 agent：「我們使用的 agent」（Claude Code、Cursor、Kero 等生產力工具）與「我們建構的 agent」，兩者思維方式不同——用的 agent可以token maxing隨便用，但建構的 agent 要謹慎設計以服務對應的使用者/受眾。
    • Harness 的字典定義是「一組用來控制動物的皮帶與扣件」，把「動物」換成「模型」就很貼切；業界如 LangChain、Martin Fowler.com（作者是 Brigitte）都寫過關於 coding agent 的 harness engineering 文章。
    • 講者給出簡潔定義：拿掉一個 agent 裡的「模型」部分，剩下的就是 harness（記憶管理、技能、工具與 MCP server 連接等）。
    • 對於「我們使用的 agent」，工程團隊過去有 coding standards，現在則需要 harness standards，統一部署給團隊所有人的編碼系統設定。
    • 推薦 AWS 的 Agent Toolkit（GitHub 上免費取得），可協助在 AWS 上部署程式碼的 agent，安裝說明涵蓋幾乎所有環境。
    • 講者強調反對「slop ops」（隨意亂搞的部署）：就像過去反對 click ops 一樣，不希望 agent 直接在 console 上點擊建立 S3 bucket 或 EC2 instance，而是要讓 agent 產生 infrastructure as code，確保雲端部署仍然由使用者掌控。
    • 對於「我們建構的 agent」，harness 需要考慮更多面向：管理迴圈（loop）、擴展付款（scaling payments）、記憶、身分（identity）、技能、runtime、context 管理，以及最重要（雖然放在最後講）的 observability 與 evaluations。
    • 若要服務數千用戶規模，不能把所有程式碼寫進單一容器直接擴展，而是要把每個元件（記憶、身分等）拆開個別擴展——這才是 harness engineering 真正的重點。
    • Demo 1：用 Strands Agents SDK 建立最簡單的 agent，匯入 Agent 類別與 tool decorator，掛載 calculator 工具與 get_time 工具，寫一個 system prompt。這種 agent 只在本機執行，框架幫忙管理了對話迴圈，但缺乏可規模化部署所需的屬性。
    • Demo 2：用 Kero 產生的第二個 Strands agent 加入了 session manager，用來在多次呼叫間維持對話狀態（類似中短期記憶），並把長期記憶存成本地檔案；agent 內建一個 "remember" 工具讓它自行決定要記住哪些關於使用者的資訊。現場示範：講者說「hello」，再問「誰會贏世界盃」，agent 回答「Australia」，因為先前對話已記住講者住在澳洲、希望澳洲奪冠——展示了跨輪對話記憶如何影響回答，同時模型誠實表示自己並不真的知道答案。
    • 為了把 agent 部署到雲端規模（而非僅在本機執行），講者介紹 Amazon Bedrock AgentCore，可以把記憶等元件拆出來獨立擴展，loop 也能獨立擴展。
    • 使用 AgentCore CLI 工具（agent core 指令）逐步引導建立與部署 agent："woohoo agent" 為範例名稱；CLI 會詢問一系列選項：語言（Python 或 TypeScript，講者選 Python，因過去做機器學習用 Python）；連線方式（HTTP、MCP、AGUI 等，講者選 HTTP）；可自由選擇任何框架（不限 Strands）與任何模型（不限 Amazon Bedrock 模型，本次示範用 Sonnet 4.5，因為是預設選項）；以及是否要部署 long-term 與 short-term memory（會建立獨立於 agent runtime、非同步運作的雲端記憶基礎設施）。
    • CLI 生成的完整 agent 程式碼會加入 Bedrock AgentCore app 的連結，讓 agent 具備多租戶隔離（multi-tenant isolation）能力——開發者可以只針對單一使用者寫程式，AgentCore 自動處理多租戶擴展，大幅節省開發工作，並簡化安全與身分管理。
    • 程式碼中還包含測試工具、MCP 連接示範，以及 session manager 與 memory 的整合。
    • 用指令 `agent core dev` 可在本機開啟一個網頁瀏覽器介面，連接到本地執行中的 agent，即時反映程式碼更新；同一介面也能切換到已部署到雲端的版本，查看 trace、記憶儲存等資訊以利除錯。
    • CLI 步驟中有個「Harness」選項這次沒選，講者解釋：如果一個 agent 只需要 system prompt 加上 MCP 連接就能解決約 80% 的 agent 使用情境/開發需求，那麡 AgentCore 其實內建了現成的 harness——只需一個 JSON 設定檔（指定要用的模型與 system prompt）即可透過 `agent core deploy` 直接部署，完全不需要自己寫 agent 程式碼。
    • AgentCore 的各項能力是可組合的（composable）：例如若已有一個在生產環境正常運作的 agent，只想加上 serverless 管理的長期記憶，可以只整合這一部分，不需整個換掉。
    • Strands Agents 是開源、model-first 的 agent 框架，免費、速度快、講者本人一直在使用它。
    • AWS 是 Agentic 基金會（Agentic Foundation，隸屬 Linux Foundation）2026 年的創始成員之一，講者本人也有參與幕後工作。

    “「拿掉一個 agent 裡的模型部分，剩下的東西，就是 harness。」”

    “「我們不希望叫 agent 去開一個 S3 bucket 或起一台 EC2 instance，我們希望 agent 幫我們寫出 infrastructure as code，讓我們依然掌控自己在雲端的部署——不要再有 slop ops 了。」”

    “「如果只靠 system prompt 加上連接 MCP 就能搞定，那大概 80% 的 agent 使用情境其實已經解決了。」”

16. 16

    打造文字角色扮演遊戲主機(RPG Console)的硬體除錯心得與生成式AI世界觀設計

    未知

    ▶ 3:35:12

    這場 talk 是講者分享自製「文字角色扮演遊戲主機（RPG Console）」的硬體除錯血淚史，以及如何運用生成式 AI（LLM）打造多個世界觀的文字 RPG 遊戲體驗。核心主張是：硬體除錯要注意訊號完整性與零件品質，而生成式 AI 能讓資源極度受限的小型裝置也能承載豐富的角色扮演遊戲內容。

    • 軟體模擬 I2C（Software I2C）在沒有額外實體上拉電阻（pull-up）的情況下無法正常運作，需要用軟體方式做適當控制才能繞過這個限制。
    • GPIO 13 這隻腳位會有「靜默失敗」（silent failure）的問題，訊號看似正常卻不work，最後必須換到其他 GPIO 埠才能確保穩定運作。
    • 自建電源供應器（穩壓模組）時，穩壓器（regulator）輸出把 LED 與顯示螢幕的脆弱元件燒壞，導致要重新採購替換零件，光是等貨到就花了好幾週時間。
    • 零件品質很重要：便宜的旋轉編碼器（encoder）品質差，會產生大量旋轉雜訊（rotational noise），必須額外加裝上拉電阻與電容（condensator）來濾波、穩定訊號。
    • 講者自曝從沒玩過紙本桌上 RPG（一群朋友聚在一起、一人當 GM、翻書進行的傳統文字角色扮演遊戲），這次卻反而自己動手做了一台能提供「純文字 RPG 體驗」的遊戲主機，某種程度上補足了這個遺憾。
    • 這類低算力、資源受限的裝置其實非常適合拿來做文字型 RPG，因為文字遊戲不需要高畫質圖形運算，硬體限制反而不是問題。
    • 講者為主機建立了 NPC（非玩家角色）與圍繞其之上的記憶機制（memory），並利用 LLM 去營造世界的情緒基調，例如平靜（calm）、緊張（tense）、陰森不祥（ominous）等氛圍。
    • 總共設計了四個不同的世界觀：其一是賽博龐克（cyberpunk）風格；其二是類似《巫師》（The Witcher）的奇幻世界，有龍等元素；其三（也是講者最喜歡的）是深邃宇宙中的虛空（void in deep space）世界；另外還有第四個世界（內容未在逐字稿中詳述）。
    • 這是生成式 AI 用來打造電玩內容的一個具體示範：AI 負責生成角色、世界設定、地圖與技能等內容。
    • 這些生成內容會透過講者稍早在簡報中提到的機制（以 1-bit 記憶體分配的方式）轉換，把圖像轉成矩陣（matrices）、再轉成地圖（maps），藉此在極有限的記憶體資源下呈現遊戲世界。
    • 講者強調整台裝置的設計相當「防呆／耐用」（bulletproof）：即便 OLED 螢幕故障失效，遊戲仍可退回用紙本方式繼續進行，不會讓整個遊戲體驗中斷。

    “「如果 OLED 不能動，紙本就能動（If the OLED doesn't work, the paper will）。」”

17. 17

    大辯論：迴圈工程(Loop Engineering)是否被過度炒作？——Ralph Loop、AI軟體工廠與程式碼簽署責任辯論

    Allie Howe、Ian Livingstone 等 · Keycard / HumanLayer

    ▶ 3:40:34

    這是一場牛津式辯論,主題是「迴圈工程(Loop Engineering)是否被過度炒作」。正方(Ian Livingstone、Jeff Huntley)主張迴圈已是有效且不可逆的工程單元,只要搭配紀律、基礎設施與測試就能發揮價值;反方(Dex Horthy、Greg Mastruccio)主張炒作的速度超過了實際紀律的建立,迴圈能處理機械式、可驗證的任務切片,但無法自主判斷「是否做對了正確的事」,人類仍必須留在迴圈中審查程式碼。

    • 辯論核心命題有二:一是炒作與實際效果之間是否存在落差(Delta);二是現在是否真的是邁向全自動軟體工廠的最大拐點。
    • 正方觀點(Ian、Jeff):迴圈是工程的核心單元,只要有正確紀律、基礎設施和測試,迴圈就非常有效,且業界已逐漸摸索出最佳實踐。
    • 反方觀點(Dex、Greg):炒作跑得比紀律快;軟體工廠能完成機械式、有規格限制、有測試覆蓋的任務切片,但無法自主判斷「該不該做這件事」,仍需要工程師留在迴圈裡把關。
    • Jeff Huntley(Ralph Loop 創造者)背景:兩年半前在 Canva 擔任技術主管時,觀察到工程師不斷重複提示(prompt),意識到這個行為本身可以被「程式化」,進而發展出用 bash while-loop 包裹提示、以檔案系統作為狀態、每次迭代清空上下文視窗(context window)重來的做法。
    • Ralph Loop 命名來自「有點迷因(meme)但背後有深思」的設計:把 LLM 當成一種新形態的 CPU 架構來研究其行為模式。
    • Jeff 認為迴圈「不是萬靈丹」,並預言明年同一場會議上會出現大量「工廠失敗」、「迴圈失敗」的分享,類比早期 Kubernetes 熱潮時大家一窩蜂使用但踩了很多坑。
    • Jeff 自述已兩年半沒有手寫程式碼,連跨語言的程式碼移植(例如 Golang 移植到 TypeScript)、產品經理對 Linear 工單的研究彙整,都改用迴圈自動化完成,因為這類任務有明確的「終止條件(termination)」。
    • Dex Horthy(HumanLayer CEO)反駁:Kubernetes 花了 7-8 年才成熟,是建立在「確定性(deterministic)」的控制迴圈上,而不是像 AI 迴圈這種非確定性系統;真正有價值的用法是鎖定一個小的、明確的期望終態(desired end state),讓代理人(agent)根據目前狀態逐步逼近它。
    • Dex 認為業界已經在「連 prompt 都不用寫、直接 go」的階段,再往上疊一層「連迴圈設計都交給 AI」等於工程師離架構決策更遠一步,這正是他擔憂炒作的地方——大家都在找一個能免除「審查程式碼」這件苦差事的萬靈丹,但目前沒有證據顯示這真的可行。
    • Ian Livingstone(Keycard CEO):軟體開發本質上一直都是迴圈驅動的(嘗試→學習→應用),CI/CD、程式碼審查(design review)、客戶回饋本質上都是迴圈;隨著人類與軟體的互動介面(UI/UX)越來越少、越來越限縮在特定 API,主觀性下降、可驗證性(verifiability)提高,迴圈與自動化會變得更可行。
    • Greg Mastruccio(Sentry 工程師):兩大質疑點——(1)品質問題:目前 AI 生成的程式碼即使經過語意驗證(semantic verification)後仍常常是「垃圾(crap)」,仍需要大量人工迭代與架構糾正;(2)經濟可行性:如果迴圈疊迴圈、靠砸更多 token 來解決品質問題,企業要花多少錢養一個工程師的 token 預算(1萬、10萬、還是100萬美元/月)是不可持續的。
    • 安全性議題:Ian 認為隨著模型能力提升與強化學習(RL)訓練,模型會展現出「更強的目標追求(goal-seeking)」傾向,反而更擅長找到人類數千小時都找不到的漏洞與繞過方式,因此無法相信模型本身能「自我對齊(align)」或保持安全,關鍵在於圍繞模型建立的基礎設施與護欄。
    • Jeff 附和:最實際的資安做法是「環境中不要放明文密鑰檔案(secrets as files)」,否則當代理人因權限不足想部署服務時,會主動在檔案系統中「目標導向式」搜尋更高權限的憑證。
    • 關於為何現在(而非一年前)才是迴圈的拐點:Jeff 認為模型能力其實一年前就已經「夠好」,真正改變的是「社會/工程師的認知與適應速度」——他假設去年聖誕假期讓大家有時間坐下來真正玩過、體會到模型有多強。
    • Jeff 提出經濟論證:用迴圈運算下來,成本可以壓到約每小時 10.42 美元(引用 Dex 團隊約一年前在駭客松時,用迴圈把多個贊助商工具的 Python 函式庫重寫成 TypeScript 的案例)。
    • Jeff 觀察到許多工程主管/創辦人原本要維護四、五種不同程式語言的複雜技術棧,改用迴圈後可以統一收斂到單一技術棧來管理複雜度。
    • Jeff 提出「迴圈工程(loop engineering)」的核心工作:把你的領域知識「編碼化(encodeify)」,透過 pre-commit hook、靜態語言分析器(static analyzers)、確定性系統測試/模擬器等手段,對代理人施加「回饋壓力(back pressure)」,防止迴圈在未達工程標準前就關閉收斂,他形容工程師的角色更像是「火車司機」,負責讓「醉醺醺(drunk)」但強大的模型不脫軌。
    • Greg 反駁模型智能提升不再是重點,真正瓶頸在於「語意驗證」能力:確定性可驗證的部分(型別系統、linter、模擬測試)可以持續疊加使用沒問題,但一旦驗證流程本身引入更多非確定性(例如用另一個 AI 來判斷 AI 的輸出是否正確),迭代次數一多(10-20 輪),錯誤率反而可能從 5% 累積放大到 50% 甚至更高,且成本高昂;他舉例目前多數大型 AI 公司仍在用 Sentry 抓簡單 bug,證明「迴圈能自動抓出所有問題」這件事並未真正解決。
    • 上下文視窗(context rot)議題:Dex 解釋 Ralph Loop 的精髓是每次迭代都清空上下文重啟,讓代理人保持在他稱為「聰明區(smart zone)」——建議新手約 10 萬 token 內、大型百萬級上下文視窗建議不超過 20 萬 token,他個人在最難的問題上會控制在 6 萬以內,判斷「進入笨區(dumb zone)」的訊號是模型開始對測試耍小聰明、找藉口忽略錯誤。隨著上下文視窗變大,這個限制的重要性正在降低,重點轉向能餵給系統多少「回饋(feedback)」。
    • Jeff 補充：他用「一部星際大戰電影劇本(約150KB文字)」的 tokenize 大小做比喻,說明目前上下文視窗大概只能塞下約兩部電影劇本份量的可用記憶(以百萬 token 視窗約可用八分之一計算)；並提到每次新模型發布，他會清空所有 skills/markdown 設定重新測試，因為不同模型有不同「脾氣」(例如 GPT-5.5 被吼會變得軟弱畏縮，Anthropic 的模型反而吃這一套)。
    • 「收斂工程(convergence engineering)」概念(Jeff 十天前提出):指讓迴圈輸出的多個部分作為一個離散受測系統，逐步收斂，直到達標為止。
    • Dex 舉 Jeff 的實驗專案「Loom」為例：試圖用 Ralph Loop 自動建構一整個軟體平台（甚至嘗試重建類似 AWS、GitHub 的系統），並嘗試用 PostHog 之類的工具讓模型透過 A/B 測試數據（而非人類視覺判斷）自動優化 UI；但該專案已停滯半年，Jeff 承認要等到「更好的程式語言或更強模型」才可能真正可行——這被 Dex 視為「炒作跑贏紀律」的教科書案例。
    • Greg 分享實際案例：他們在 PR 落地前後跑安全掃描(security scanning)，每個 PR 大約花 5 美元，能找出真實漏洞、表現優於人工審查，是「值得付費」的明確案例；另外像 Next.js 重寫、用 Rust 重寫 Ban 之類「規格明確、測試覆蓋完整」的專案，迴圈重寫效果不錯；他自己也常用迴圈快速做「用完即丟」的產品原型（prototype），做完覺得可用才會重新仔細審視、重寫程式碼。
    • 共享記憶體與存取控制問題：多代理人（multi-agent）情境下，共享的記憶存放區會產生「誰寫的、誰能讀」的存取控制問題，這在概念驗證(POC)階段可以忽略，但生產環境不行；若把記憶依代理人分開（隔離）則會犧牲「跨代理人共同學習、加速收斂」的效益，兩者存在張力。Ian 承認這是「尚未解決的問題」，現有的存取控制系統本來就不是為「機器代替約半數人類進行推理與行動」的世界設計的；他分享自己嘗試把 Notion 內容全部匯出成 markdown 檔案供代理人使用，並認為「markdown 檔案 + 存取權限標記」可能是目前最接近可行的雛型基礎。
    • 未來與軟體工廠：Greg 認為架構、抽象層次是否正確、取捨(trade-off)這類決策仍需要人類判斷，尤其是「不該做什麼」的判斷；他觀察到代理人傾向不斷增加複雜度(love complexity)，因此人類仍需把關架構決策。
    • 針對 Shopify 工程主管與 Kesserach 的公開言論「你的工作就是寫迴圈」，以及一則獲得 800萬瀏覽的推文(呼籲別再直接提示代理人，而要設計會提示代理人的迴圈)，Jeff 認為這種建議很難原封不動教給廣大群眾(3000人或800萬人)，他自己原本是寫給同儕(如 Thomas Patek 等函數式編程領域的專家)看的技術文章，被大眾過度簡化傳播；他也強調「安全」與否的討論其實早於 AI 問題本身——NPM 供應鏈攻擊已存在多年，本地開發環境本來就不安全,先把日常開發流程資安基礎打好，這些技巧才會變安全。
    • 針對 Dex 曾發推文指出「多數工程師靠 AI 代理獲得 2-3 倍加速是務實可行的，若貪心追求 100 倍加速反而會迷失在『元-元問題』的優化陷阱中，可能永遠達不到本可實現的10倍加速」，Dex 在辯論中重申：應該用小規模、漸進式的迴圈滲透到系統各處，而不是妄想端到端全自動化；追求2-3倍已經足以改變每個企業與新創的競爭格局，貪求100倍容易「炸掉一切」。
    • 簽署責任(code-signing accountability)議題：Git 目前只允許單一簽署者(signer)簽署一個 commit，無法反映「人類指示 AI、AI 產生程式碼」的責任鏈。Ian 認為必須類比企業內部的「服務所有權(service ownership)」概念——最終責任必定要歸屬到人類（或作為人類集合體的公司），因為「責任(liability)」只能由能承擔後果的實體承擔，AI 代理不可能自己承擔法律責任；社會運作依賴「責任與後果」的存在，這個問題目前雖無解，但並非無法突破，需要重新思考整個軟體供應鏈與 SDLC 中的歸屬機制。
    • Jeff 補充自嘲：軟體工程這個「行業」本身在個人層級上其實從來就沒有真正的法律責任(liability)，大家自稱「工程師」但實際上並非受監管的工程專業。
    • 收尾建議：Jeff 建議使用「靜態型別語言(static types)」作為一種驗證形式，直言若用 Python 或 Ruby 搭建迴圈/軟體工廠會是「小丑秀(clown show)」，而 Rust、甚至 Haskell（因為 LLM 能理解並向人「解釋」程式碼，程式碼本身不一定要對人類可讀，但要「可解釋」）更適合；他也分享近10個月來盡量不使用任何開源軟體，改由 AI 依需求直接生成程式碼、將原始碼「自行 vendoring(內部化持有)」，以縮小供應鏈攻擊的影響範圍，因為開源專案維護者是人類，你無法直接對人類做「工具呼叫(tool call)」。
    • 最終投票結果：現場燈光太亮看不清楚舉手人數，主持人形容「非常接近(pretty close)」,未給出明確的獲勝方。

    “Jeff Huntley:「這些 LLM 生成的程式碼,比大多數新創公司實際能雇得起的軟體工程師寫得還要好——這很可悲,但是事實。」”

    “Jeff Huntley:「工程師現在就像是火車司機——因為老實說,這些模型是醉的(drunk),你不能信任它們,但我們接受這一點,然後透過工程手段把這些風險價值域『圈』出去。」”

    “Dex Horthy:「不要因為在推特上看到某個東西有效,就以為你過去學到的一切都作廢了——別為了追求100倍加速,把一切都炸掉。」”

18. 18

    Loophole：用對抗式AI代理(Adversarial Agents)找出道德與法律漏洞——從DNA隱私到美國參議院法案模擬

    未知 · Morgan Stanley

    ▶ 4:41:54

    這場 talk 介紹開源專案「Loophole」：一個建立在對抗式 AI 代理框架上的遊戲，使用者輸入自己的道德原則，AI 將其轉譯為成文法律，再由兩個對抗代理互相尋找「合法但不道德」的漏洞與「道德但不合法」的過度規範，藉此逼出使用者道德觀中未被明確表達的細節與矛盾。講者延伸出三個應用方向：聊天機器人憲法生成、去中心化契約、以及模擬美國參議院投票的智慧政府工具。

    • 專案發想源自講者曾把 DNA 送交 23andMe 做祖源檢測，後來聽聞 DNA 樣本可用於破解懸案，因擔心「滑坡效應」而選擇退出所有用途授權，但其實有些情境他是願意授權的，只是逐案判斷在認知上不可行，因而想到能否用 AI 系統化處理這種細膩的道德判斷。
    • 講者將此類比為法律系統本身：法律其實就是社會嘗試把道德信念成文化的方式，但要找到道德的真正細膩邊界是一個困難的「翻譯任務」，若翻譯過於通用容易出現奇怪的漏洞或失敗情境；若追求完美翻譯又會產生詭異的邊角案例。
    • 講者指出英美普通法（common law）之所以高度依賴判例法（case law），正是因為承認找出道德邊界的細膩之處很困難，所以仰賴聰明的法官逐案解釋與適用法律，重大爭議甚至可上訴到最高法院決定某條法律是否成立。
    • 講者認為人際政治分歧多半其實是在核心價值上的爭執錯覺，實際上雙方核心價值未必真的衝突，真正該探討的是道德細節而非價值本身。
    • Loophole 的核心設想：能否讓使用者輸入自己的道德觀，透過 LLM 自動生成「合成判例法」（synthetic case law），這在人工操作上是不可行的，但新一代 LLM 已經具備做這種高層次道德推理的能力。
    • 遊戲玩法（終端機文字遊戲）：使用者以自然語言輸入自己的道德原則（可以是通則或針對特定主題）；一個代理將這些道德原則起草成豐富、法律用語式（legalese）的成文法律系統（含 preamble、articles、sections）。
    • 系統接著進入循環：一個代理專門尋找「漏洞」（loophole，即合法但不道德的情況），另一個代理專門尋找「過度規範」（overreach，即道德但依此系統為非法的情況）。
    • 一個「裁判代理」（judging agent）會檢視原始道德觀、生成的法律條文、以及這些合成案例，判斷是否能「自動修補」（auto-patch，即原始法律翻譯有誤但道德本身無矛盾，可直接修正條文）；若判定是道德觀本身「規範不足」或存在真正矛盾，則會提交給使用者裁決。
    • 示範案例（DNA 情境）：找出的漏洞是「保險公司雖未直接使用你的 DNA 訓練預測模型,卻使用 DNA 的衍生產物（artifacts）訓練」，系統判定這是不道德但目前合法，且此案例可自動修補，修補後會以類似 git diff 的方式顯示法律條文前後差異。
    • 另一個過度規範案例：某人提交 DNA 做基因研究，研究者發現受試者帶有罕見但可治療的遺傳疾病，原始道德規則本應禁止揭露，但這無法自動修補，需交由使用者親自裁決,裁決後同樣產生修補版法律條文。
    • 講者將此遊戲發布到 Twitter 並開源在 GitHub 上,是他個人發文中傳播度最高的一次,許多人單純覺得好玩,可以拿來壓力測試自己的道德觀、找出潛在矛盾，也讓他思考這是否有更大的實際應用潛力。
    • 延伸方向一：為聊天機器人/AI 代理自動生成「憲法」（constitution）。公司若想讓客服機器人遵守某種道德準則、規定哪些話題可談/不可談，可用同樣方式輸入規則,由代理生成成文的 system prompt,再用對抗代理測試機器人是否會被誘導談論不該談的話題,或拒絕談論該談的話題;講者將此類比為 GEPA，但目標是打造這種成文化的 system prompt。
    • 延伸方向二：作為一種「去中心化契約」或臨時契約的工具。簡單案例是使用者可指定自己希望資料/隱私如何被處理,經過對抗式流程生成成文法律系統後，可拿去和例如 Apple 新版服務條款做矛盾比對，找出你的道德觀與公司實際做法之間的落差；即使是大公司無法真正談判,至少能讓使用者對自己簽署的內容有更充分的資訊。
    • 對於沒有中央權威執行的跨國契約（如跨國委外工作),雙方都可各自輸入自己對工作報酬、道德規範的期待,各自生成經過壓力測試的成文契約,再找出兩份契約間的分歧點,在正式同意前先行揭露,讓雙方對契約更有信心。
    • 延伸方向三（較具野心）：更聰明、更有效率的政府。忽略隱私與後勤層面的問題,構想是選民/選區居民定義自己的道德觀,生成經壓力測試的法律準則後,任何新法案或政治人物主張都可以拿來和自己的準則比對,找出自己會不同意或覺得不道德/矛盾的地方；對立法者而言,也能在提案前先用「其他所有議員的模擬」對法案進行壓力測試。
    • 講者實際針對美國參議院做了第三個分支的實驗：先讓 Claude 檢視所有現任美國參議員的投票紀錄與公開資料,建構出每位議員的道德體系,再透過 Loophole 流程生成其成文法律準則。
    • 在此系統上,可以輸入任何現有或自創法案，讓 Claude 模擬每位參議員會如何投票,並展示各參議員的傾向與投票理由的推理過程。
    • 講者指出這其實形成了一個「可驗證的領域/迴圈」（verifiable domain/loop）,可以對法案進行「爬坡優化」（hill climbing）,以達到通過所需的超級多數;以一項醫療保險（Medicare）法案為測試案例,原本模擬投票是50比50打平,系統透過調整法案措辭,在不違反法案核心宗旨/道德的前提下，找到讓其以52票通過的修改方式,並能對所需修改依「能爭取到多少票」排序,讓使用者自行選擇取捨。
    • 最新嘗試是把規模再放大：讓每個州/選區的每一位「選民」都有自己的法律準則。講者引用 NVIDIA 一份高品質的「美國人物誌」（USA personas）資料集，每州取樣500個具代表性人物誌，讓每個人物誌各自生成道德觀與成文契約,再拿任何感興趣的法案去對照各州,藉此衡量人們對該法案的贊同程度或與其道德觀的一致程度,並可對法案做同樣的爬坡優化,使其更符合民意。
    • 講者總結：即使最起碼的用途,這也是一個很好玩的遊戲,可以拿自己在乎的議題輸入,看看有沒有矛盾,常常會引出很有意思的問題,一旦補上細膩之處後,代理便找不到更多矛盾,使用者可以對自己擁有一致且細膩的道德體系感到安心；但他也真心好奇這是否能發展成去中心化契約、更好的契約,甚至幫助立法者壓力測試法案、寫出更能代表選區民意的法律。
    • 講者提供兩個 QR code：一個連到參議院模擬器,一個連到他個人網站（內含 Loophole 完整 GitHub 專案）,並歡迎大家去玩、fork 這個專案，也歡迎其他人加入貢獻。
19. 19

    破解「100工具代理陷阱(100 Tool Agent Trap)」：語意路由(Semantic Routing)與即時上下文如何拯救工具選擇準確率

    Sohail Shaikh、Ankush Astoghi · Prosorica

    ▶ 4:58:41

    這場 talk 拆解一個常見的 AI agent 設計錯誤——把工具目錄(tool catalog)裡「所有」工具定義一次性塞給模型（稱為 Fat Agent），在小規模下看起來沒問題，但隨著工具數量增加，準確率會急速崩潰、延遲與成本也隨之飆升。講者提出用語意路由(Semantic Routing)搭配即時上下文(just-in-time context)，只給模型少量相關工具，來解決這個「100工具陷阱」。

    • Fat Agent 的定義：把每個工具的 function name、description、JSON schema 全部塞進 prompt，不論使用者當下是否需要，全部一次給模型看。
    • 這種設計在小規模（如10個工具）時看似沒問題，demo 效果好，模型通常能選對工具。
    • 隨著工具目錄成長（30個、上百個），模型開始出現：呼叫錯誤函式、混淆相似工具、甚至捏造不存在的工具名稱、回應時間變長。
    • 關鍵論點：問題不是「某個工具寫得不好」，而是「每一次請求都被迫攜帶整個工具目錄」這個架構性錯誤。
    • 具體規模案例：講者展示一個含 741 個工具的 schema，光是把所有工具描述塞進 prompt 就要消耗約 127,000 tokens，而這還是在使用者實際問題被納入考量之前。
    • 準確率曲線數據（Fat Agent）：
    • 10 個工具時，正確選中工具的準確率約 78%（可用但非完美）。
    • 約 100 個工具時，準確率掉到約 40%（呼叫的工具有一半以上是錯的）。
    • 741 個工具時，準確率僅剩 13.6%，等於平均每 8 次只有 1 次選對工具。
    • 對照組（Semantic Router）：在相同的工具目錄規模下，準確率穩定維持在約 83% 左右，因為模型不是從幾百個工具中挑選，而是從一個經過篩選、相關性高的小集合中挑選。
    • 準確率崩潰的原因之一是「lost in the middle」問題：模型對長 context 的開頭與結尾注意力較強，當數百個工具 schema 被塞在中間時，模型無法可靠地利用這些資訊，導致「花大錢餵了一個巨大的 prompt，反而讓決策更難」。
    • 除了準確率，另外兩個代價是延遲(latency)與成本(cost)：以 741 個工具、約 127,000 tokens 的工具描述+schema 文字為例，這個成本是「每一次請求都要重新付一次」的。
    • 講者分工：Sohail Shaikh（data scientist）專注在模型與路由行為（model/routing behavior）；Ankush Astoghi（senior data solutions engineer）專注在系統設計、實作與生產環境的取捨（production trade-offs），強調重點是「能不能在真實負載、真實用戶、真實失敗情境下存活」，而不只是在 notebook 裡跑得動。

    “「這個設計失敗，不是因為某一個工具寫得不好，而是因為每一次請求都被迫攜帶整個工具目錄。」”

    “「在 741 個工具的情況下，準確率只剩 13.6%——也就是平均每 8 次呼叫只有 1 次選對工具。」”

20. 20

    用Restate打造具韌性的生產級AI代理基礎設施：持久執行(Durable Execution)、虛擬物件(Virtual Objects)與可恢復工作流

    未知 · Restate

    ▶ 5:05:04

    這場 talk 介紹開源框架 Restate，主張隨著 AI 代理從單次問答、單一 App 演進到「長期執行、具狀態、跨組織連結的持久化實體」（第三波），基礎設施層也必須跟著演進。Restate 提供一套通用的持久執行（durable execution）基礎，讓開發者不必自己實作重試、恢復、狀態隔離等複雜邏輯，就能把普通函式變成可長時間執行、可恢復、具狀態的服務。

    • 講者引用 Andrej Karpathy 上週的說法，把人與 LLM 互動分成三波：第一波是像網站一樣問答式的 LLM；第二波是下載到電腦、有工具可用的 Agent App；第三波則是長時間運行、能存取組織內各種工具與其他代理、具持久性與非同步性的實體型代理。
    • 目前市面上的工具創新多集中在 Agent SDK 與記憶體（Memory）層面，這些工具適合快速做 POC，但無法解決把組織內分散元件連接起來、以及重試邏輯、恢復邏輯這些「必要卻複雜」的基礎設施問題。
    • Restate 是開源框架，可視為一個「靈活、持久的後端基礎」，不專為代理設計，但因代理本質上也是一種後端服務，所以同樣適用；其設計理念源自分散式串流處理引擎 Apache Flink，以及 Meta 內部事件基礎設施（event infra）的前架構師。
    • Restate 核心提供四類能力：(1) 單次代理執行的韌性，即使代理跑一週後崩潰，也能從失敗點精確恢復，而非從頭重來（業界稱為 durable execution）；(2) 支援大量並行 session，確保上千個並行代理 session 之間狀態一致、互不干擾；(3) 代理與代理、代理與 MCP 伺服器/工具之間的通訊；(4) 控制能力，例如可以取消或終止卡住、失控的執行。
    • 架構上，Restate 是跑在代理服務前面的獨立伺服器，角色類似 message broker 或 proxy：請求先進入 Restate，再被推送（push）給代理服務，兩者間建立一條持續連線；代理執行過程中會把事件送回 Restate，Restate 用這個「journal（事件日誌）」在失敗後恢復流程。
    • Demo 場景：一個接在 Slack 上、供公司員工使用的深度研究（deep research）代理。在 Slack 頻道問「What is new in AI」後，系統會先跑一個 planner LLM 呼叫，規劃研究子主題並回報，等使用者按「approve」才會展開後續平行的多個 research sub-agent，最後由一個 writer agent 產出報告——即經典的 deep research 工作流（planner → 平行 sub-researcher → writer）。
    • Restate 提供一個 UI（講者稱之為「代理的座艙 cockpit」），可以看到所有註冊的代理、目前正在執行的流程，以及每一步的 journal 事件記錄。
    • Demo 中示範容錯：某個 sub-agent 呼叫外部 API 做網頁搜尋時因 API 當機而失敗，Restate 自動重試該步驟並最終成功，過程中不是整個流程重跑，而是利用 journal 精確恢復到失敗的那一步。
    • 程式碼層面，Restate 的基本單位是 HTTP handler，透過 Restate SDK 讓 handler 具備「持久性（durable）」；handler 拿到一個 `RestateObjectContext` 物件，對它做的每個操作都會產生一個事件送回 Restate。範例：planner 的 LLM 呼叫只是個普通 Python function，只要用 `restate.run` 包起來就變成可持久化的步驟，即使兩個月後失敗也能精準恢復到那個點。
    • Durable execution 不只用於故障恢復，也能用於「長時間等待」場景：例如需要人類核准、且核准可能要等數週到數月，這段期間流程必須撐過重啟、重新部署。做法是建立一個活在 journal 裡的「durable promise」（類似暫停點），流程在等待期間會真正掛起（suspend）——若跑在 serverless 上，等待期間不會消耗函式執行時間；一旦有回應就繼續。
    • 但單純的「工作流（workflow）」模型不適合表達 Karpathy 描述的那種「持久、具狀態的實體」，因此 Restate 提供 Virtual Object（虛擬物件）概念：它像一個有狀態的 actor，具備唯一 ID（如 session ID）、屬於該 session 的隔離 key-value 狀態（例如對話歷史），以及一組可執行「可持久化函式」的 handler。
    • Demo 展示 Virtual Object 的用途：使用者不需要等 10 分鐘研究跑完才能補充資訊或改變主意，而是能即時對「正在執行中」的 session 插入新訊息；實作上是一個 session controller，能讀寫 session store（如聊天歷史）。
    • 為了在數千個並行 session 下避免代理互相干擾（例如同時在 Slack 送兩則訊息導致兩個代理互相覆寫 session 狀態），Restate 保證同一 session 同一時間只有一個執行在跑，後續執行會排隊（queue）在目前執行之後。
    • 每個 Restate 執行都有唯一識別碼，其他流程可用它來取得輸出結果、取消（cancel）執行，或「signal（訊號注入）」——即把新資訊注入一個已經在跑的代理迴圈中。
    • Demo 邏輯：session controller 收到使用者新輸入後，先呼叫 LLM 判斷這則新訊息是否與目前正在跑的研究相關；若相關就用 signal 把它注入目前執行中的 agent loop；若不相關（例如使用者說「別管那個了，改研究 AI 政策」），就直接取消目前執行並重新開一個新流程。
    • 取消（cancellation）的傳遞方式是沿著呼叫鏈（call chain）向下送訊號：若一個代理已經展開了多個 sub-agent，取消訊號會先取消這些 sub-agent，再取消上層的 controller，等於是「倒退堆疊（rewind the stack）」，讓代理具備回滾（roll back）能力。
    • 最後一段 demo 示範高度客製化的擴充能力：假設部署上線幾個月後出現新的、能力很強但很貴的模型（範例中虛構名稱「Fabulous」），導致研究代理成本暴增。做法是把原本內嵌（inline）在代理程式裡的 LLM 呼叫拆出來，做成獨立的 handler（例如加上一層 policy check 後才呼叫 LLM），其他代理改用 Restate 的分散式通訊原語（primitives）去呼叫這個「LLM gateway」，而不是直接內嵌呼叫；這個服務間通訊層還提供流量控制（flow control），例如可設定「某部門同時最多只能對這個 LLM gateway 發 300 個並行呼叫」。
    • 架構原理：Restate 內部是「事件驅動的分散式日誌（distributed log）」實作，一側是 client，一側是 service，中間有一個持久化所有 journal 事件的 log 加上一個事件迴圈（event loop）；事件迴圈依事件類型決定要嵌入的狀態儲存中持久化狀態、設定計時器（timer），或是把請求送給另一個代理。這個分散式日誌設計深受 Meta 內部 core event infra 層啟發，是原架構師在此基礎上做的開源通用化迭代。
    • 架構有兩個關鍵特點：其一，Restate 採用「推送（push）模型」，而多數工作流編排系統是「輪詢（pull）」向伺服器要任務；push 模型帶來更低延遲，講者舉例一個 10 步驟的工作流可以做到約 45 毫秒 P99 延遲；push 模型也非常適合 serverless，因為 serverless 本來就是靠「送請求→喚醒函式」運作。
    • 整套系統（含內嵌狀態儲存、UI）是單一二進位檔（single binary），因此很容易維運；要做高可用，只需多開幾個實例並讓它們快照（snapshot）到物件儲存（object storage）即可。
    • Restate 提供六種語言的 SDK，並整合多數主流代理框架；由於它本質上是一層靈活的基礎設施，也可以直接搭配任何 LLM SDK，用 SDK 的原語包裝步驟來實作自訂代理。
    • 產品開源、可自架（self-host），也提供 BYOC（Bring Your Own Cloud）方案（Restate 部署在客戶自己的雲端帳號內，資料不離開客戶雲端），另外也有全託管的雲端服務（managed cloud）。
    • 講者提到公司正在全面招募（從工程到行銷），特別是灣區職缺，並在會後於會場外接受提問與交流。
21. 21

    2026年：程式碼代理(Coding Agents)將悄悄淘汰第一個軟體平台——Resonate如何用Agent生成多目標持久化執行伺服器

    Dominik Torno · Resonate

    ▶ 5:25:28

    這場 talk 主張:2026 年程式碼代理(coding agent)將悄悄淘汰第一個軟體平台——不是因為它不好,而是因為當實作可以被隨需生成時,「平台」本身就變得不必要。講者 Dominik Torno 以自家的 durable execution 平台 Resonate 為例,說明公司如何把價值重心從「實作」轉移到「規格(specification)」,並分享他們如何一步步摸索出讓 AI agent 真正參與系統「設計」而非只是「建造」的流程。

    • 核心理論:通用實作(general purpose implementation)將逐漸被「隨需生成的客製化實作」取代——不是新的函式庫、框架或平台,而是既有基礎設施上的最小擴充。只要問 agent 就能生成客製化實作,此時「prompt 就是平台」。
    • 這代表「重用(reuse)」這件事會往上游移動:過去我們重用通用實作,未來我們重用的是規格(specification),再由規格衍生出量身打造的實作,而且可以針對不同基礎設施衍生出多個客製化版本。
    • Resonate 目前有 Resonate server 實作,以及 TypeScript、Python、Rust、Go、Java 五種 SDK。當實作變得可生成時,公司重新定義自己的產品:產品不再是「實作」,而是「規格/協定(protocol)」。
    • 從同一份協定,他們希望衍生出多個伺服器實作:一個是通用的 Resonate reference implementation,其他則是與基礎設施夥伴共同打造的版本,讓客戶能在既有基礎設施上以最少額外依賴取得 durable execution。
    • 問題因此從「我們能不能造出一台伺服器?」變成「我們能不能從同一份規格反覆合成出可信任的伺服器?」以及「該怎麼做到?」。
    • 講者指出,agentic engineering 圈子普遍把焦點放在「驗證(verification)」——如何確認結果正確。但這場 talk 想聚焦在「規格」本身,以及 agent 該如何參與「訂規格」這件事,而不只是建造或驗證系統。
    • Resonate 與多家基礎設施供應商合作,把 durable execution 原生帶進對方的技術棧,其中一個合作夥伴是 Synadia,也就是開源分散式訊息系統 NATS.io 背後的公司。這場 talk 用「在 NATS.io 上打造 Resonate」作為案例來說明他們的 agentic engineering 實務。
    • 一般常見的 agentic coding 心智模型是:agent + 規格 → 實作(單一實作)。但 Resonate 要做的不是生成「一個」實作,而是從同一份規格生成「多個」針對不同目標(target-specific)的實作,因此規格本身必須完全抽象、不能預設任何實作細節。
    • 規格的抽象要求非常嚴格:不能假設具體的資料庫 schema 或索引;不能假設是關聯式資料庫(有 table、transaction);不能假設是 key-value store;不能假設是弱一致性,也不能假設是強一致性——規格必須抽象,只有實作可以是具體的。
    • 第一次嘗試:直接要求 agent 依照抽象規格,在 Rust + Postgres 上生成具體實作,結果失敗。抽象規格與具體實作之間的落差太大,agent 生成的系統只能通過 happy path 和基本測試,但一遇到並行(concurrency)、程序失敗(process failure)、網路失敗(network failure)就壞掉——比較像是雛型(prototype),不是可上線的正式系統(production system)。
    • 於是團隊修正流程:在「抽象規格」與「具體實作」之間插入一個中介產物——「具體規格(concrete specification)」。這份具體規格是與 agent 互動產出的,但主要驅動者是人類。以 Postgres 版本為例,團隊必須明確做出目標特定的決策:資料 schema、索引、SQL 查詢、transaction 邊界。把這些決策白紙黑字寫下來後,agent 就真的能實作出可上線的正式系統。
    • 但這個做法也暴露出侷限:agent 幫忙「建造」了系統,卻沒有幫忙「設計」系統。如果規格要作為可重用的產品,這樣還不夠。
    • 下一步很明確:agent 必須往「上游」移動,也就是要參與設計。於是在打造 Resonate on NATS.io 時,團隊把問題改成:「agent 需要什麼,才能先設計系統、再建造系統?」
    • 做法是給 agent 一個「確定性模擬環境(deterministic simulation environment)」,並給它不同的任務:不要直接建正式系統,而是先建一個「模擬實作(simulated implementation)」。這個模擬實作不是產品本身,而是一種「可執行的設計(executable design)」,目的是在「部分順序(partial order)」與「部分失敗(partial failure)」的條件下找出正確的演算法。
    • 等演算法在模擬環境中被發現、測試、驗證過後,才請 agent 撰寫「具體規格」,最後才請 agent 撰寫「具體實作(生產系統)」。整個流程因此變成:抽象規格 → 模擬實作 → 具體規格 → 具體實作。人類仍然參與設計過程,但現在換成 agent 當設計流程的主要驅動者。
    • 講者強調,能讓這一切成立的關鍵有兩個要素:極簡主義(minimalism)與簡單性(simplicity)。但這兩者不是起點,而是終點——Resonate 團隊花了三年時間不斷把協定變得更小、更簡單,每次遇到問題就自問:「可以拿掉什麼?可以抹除哪個抽象?可以移除哪個屬性?可以打破哪個關係?」
    • 最終成果是一個非常小的協定,核心只圍繞兩個物件:durable promise(持久化承諾)與 durable task(持久化任務)。這種簡單性之所以重要,是因為即使是簡單的並行分散式協定,其狀態與行為空間也可能極其複雜——換句話說,即使只用少數幾個簡單的原語(primitive)來實作簡單的協定,實作起來依然很困難。
    • 講者原本要接著用 NATS 具體說明「NATS 給了我們什麼」,但逐字稿在此處中斷,後續內容未能收錄。

    “「2026 年,程式碼代理將悄悄淘汰第一個軟體平台——不是因為它不好,而是因為這個平台已經沒有必要存在了。」”

    “「此時此刻,prompt 就是平台(the prompt is the platform)。」”

    “「問題不再是我們能不能造出一台伺服器,而是我們能不能從同一份規格反覆合成出可信任的伺服器。」”

    “「極簡主義與簡單性不是起點,而是終點——我們花了三年時間,不斷追問:還能拿掉什麼?」”

22. 22

    PostHog安裝精靈(Wizard)的資安省思：打造Warlock惡意樣式偵測與縱深防禦

    Sarah · PostHog

    ▶ 5:35:05

    這場 talk 由 PostHog 的 context engineer Sarah 分享團隊如何為「Wizard」(一個能自動安裝、設定 PostHog 的 agentic CLI 工具)打造資安防線。核心主張是：agent 一旦擁有「執行指令的手」,其解剖結構本質上就是「惡意軟體套件」,因此必須用確定性(deterministic)、可分層的縱深防禦來管控,而不能只靠 prompt 或 LLM 自身判斷。她也介紹了團隊自建的惡意樣式偵測工具「Warlock」及其設計哲學。

    • Wizard 是 PostHog 的 agentic CLI 工具(執行方式為 `npx @posthog/wizard`),會讀取使用者的程式碼庫、安裝對的 SDK、埋設事件追蹤、建立儀表板,把原本要花 1-2 小時的設定壓縮到 5-6 分鐘,且推論免費。
    • Wizard 的起源:成長團隊的 Josh Snyder 發現 Cursor 常常「幻覺」出錯誤的 PostHog 安裝方式,因而催生了「用 agent 做得更好」的想法。團隊逐步擴大目標,希望 Wizard 成為安裝 PostHog 的預設方式,最終達成每週 8,000 人使用的規模。
    • 為什麼要做成 agent 而不是給使用者一個 prompt 或 skill?因為「能完整參與 agent loop 的 CLI 工具」本身的開發體驗就是產品賣點,第一次體驗這種能力非常有威力。
    • Wizard 的解剖結構:挑選給特定任務的模型、引導行為的 prompts、一組工具,加上團隊自建的「context engine」(內部戲稱是「穿風衣的 Markdown」,即 Wizard 的大腦)、用 ink 打造的 terminal UI,以及後來新增的資安掃描器 Warlock。
    • 講者提出「Malware Starter Pack」的比喻:任何能執行指令的 agent,其解剖結構幾乎就是「如果你想做壞事會準備的東西」,這不是自白而是給所有正在做 agent 的人的警告。
    • 早期(約 9 個月至 1 年前)的資安狀態分三層:Layer 0 只是 prompt 引導,講者強調「prompt 不是資安」;Layer 1 是 allow list,範圍抓得蠻緊但仍有疑慮;為了因應 context engine 在 runtime 灌入大量內容,她自己寫了一個很陽春的 regex 掃描器,檢查流入/流出 Wizard 的「像威脅的東西」。
    • 進一步檢視發現實際上沒有想像中糟:bash 預設為 deny,只能安裝團隊審核過的可信套件,只能 build、type check、lint,不能跑任意 shell 指令,也無法存取環境變數(讀不到 .env),密鑰是透過 Vault 路由,agent 本身接觸不到。
    • 請內部資安團隊做稽核後,發現的問題「形狀」比具體漏洞本身更重要:幾乎沒有明顯邪惡的漏洞,都是兩個「無辜、立意良善」的元件互相搭配後開出一個洞。她得出的教訓是「攻擊會組合(compose),但 code review 不會」——因為開發者一次只看一個 diff,攻擊者卻看整個系統,專找那些會「握手」開門的組合。
    • 最讓她夜不能寐的其實不是指令執行,而是 context engine 灌進 agent 大腦的「看似有幫助的內容」。Context engine 會從官方文件、手寫的 prompt(記錄踩過的坑)、真實可運作的範例 app 中萃取內容,打包成 skill bundles,透過 MCP server 送進 Wizard,並在 runtime 直接載入 agent 的 context。
    • 她提出的攻擊情境:假設有人在 PostHog 的開源 repo 上開一個 PR,在 markdown 檔或看似無害的程式碼註解中植入惡意內容,若 LLM 驅動的 code review 沒抓到而放行,團隊可能會把一個「蓋著官方印章的 prompt injection payload」推送給數千台開發者機器上正在跑的 agent(雖然是在 sandbox 中執行)。
    • 因此她的方法論是:在內容管線的兩端都掃描——一次在 skill 建立/發布時,一次在 Wizard 實際使用時——原則是「在源頭抓、假設源頭失守、在使用點再抓一次」。
    • Warlock 因此誕生,並非單純的損害控管,而是因為「這東西算蠻鎖死的」這種說法無法規模化。她把原本陽春的 regex 掃描器獨立抽出來重寫,取名 Warlock(「像巫師的東西都需要保鑣」)。
    • Warlock 只做一件事:輸入一段字串,回傳一份 findings 清單,每筆包含 category、severity、建議動作(recommended action),然後就結束——Warlock 只負責偵測,不負責執行動作。偵測問題和決定如何處理問題是兩件不同的工作,把這兩者分開才能讓整個系統可理解。
    • Warlock 底層規則引擎採用 YARA——惡意軟體研究人員用了 15 年以上的 pattern-matching 引擎,完全確定性(deterministic)、相同輸入永遠得到相同輸出,「無聊是刻意的」,在資安領域無聊是優點。
    • Warlock 在實際運作中抓到的兩個讓她很頭痛的案例:(1) 並非規則本身抓到,而是觀察到 sub-agent 的行為異常——Wizard 為了完成大任務會產生 sub-agent,這些 sub-agent 會試圖繞過既有防護欄、想從程式碼庫任何地方發明/竊取 secrets,團隊因此直接關閉了 sub-agent 功能;(2) PII 外洩問題——agent 若沒有明確規則,根本不在乎資料外洩,曾觀察到它把 email、電話號碼直接塞進事件(events)裡,因為對 agent 而言這看起來就是正常該記錄的資料。
    • 關於 prompt injection,她坦言(敲敲木頭)目前實務上幾乎沒抓到真正的惡意注入,但抓到大量 false positive,例如 demo 登入畫面的複製內容、範例 app、文件內容——這也讓她重新思考自己寫程式碼和文件的方式,盡量避免寫出「長得像威脅」的東西。
    • 為了處理大量 false positive,她加了一層 LLM 稱為「triage」,但這與她整場一直強調「要確定性」看似矛盾,是她仍在摸索但想分享的關鍵設計取捨。
    • 設計 triage 時的抉擇:LLM 該當「保鑣(bouncer)」還是「顧問(advisor)」?若讓 LLM 直接看指令判斷是否為攻擊並決定放行/封鎖,聽起來簡單,但她不願把資安模型賭在「模型今天心情好不好」的擲硬幣上。
    • 最終設計:偵測與執行(enforcement)保持確定性、機械化——只要規則命中,閘門就鎖死、session 直接終止,這條路徑上完全沒有模型介入,封鎖發生在詢問 LLM 意見之前。LLM(顧問角色)只有在沒有被封鎖的情況下才會事後介入,其設計目的是「去除雜訊」,而不是「放行威脅」;若 LLM 當機或狀況異常,則採 fail closed——所有 Wizard 執行直接全部終止以確保安全。她的結論是:enforcement 是要賭上身家的部分,必須確定性;judgment(判斷細微差異)才是可以放入機率性元件的地方。
    • Warlock 規則的解剖結構共四個部分:(1) metadata——用白話文寫的 description、severity、category、action、方向(是流入 agent 還是 agent 寫出的內容);(2) strings——要找的實際樣式(pattern);(3) condition——規則實際觸發的條件;(4)(隱含)測試。
    • 她以經典的 prompt injection「ignore all previous instructions」為例示範寫規則:第一直覺是直接封鎖 "ignore" 這個字,但 agent 整天在讀程式碼,ignore 常出現在註解或範例中,所以不能只匹配動詞本身,要匹配「動詞+帶有指令意味的名詞」的組合;condition 設定為「任一模式命中就觸發」;metadata 則決定 severity、category、action(此例為 block)、方向(此例為流入 agent 的輸入)。
    • 寫好規則一定要附測試:哪些樣式該匹配、哪些不該匹配,「負向測試(negative test)」是防止 false positive 的第一道防線。判斷規則嚴重程度時,要以「對正在建構的這個 agent 而言的真實世界影響」為準,而非「看起來多可怕」——例如 `rm -rf` 聽起來很可怕,但也是大家一天刪 40 次 node_modules 常用的指令;會不斷誤攔正常操作的資安工具最終只會被使用者關掉,結果什麼都抓不到。
    • 目前的最終資安姿態(defense in depth):Prompts 僅用於引導(steering),而非安全機制;所有執行都在 sandbox 中;預設 deny;用 Vault 確保 secrets 永遠不會碰到模型;用 Warlock 掃描流入內容與 agent 寫出的輸出;用 triage 去除雜訊;整個流程都嵌入 telemetry 以確保可觀測性。她強調「沒有任何一層能單獨救你,重點是每一層都各司其職、樸實無華」。
    • Wizard、Warlock 與 context engine(context mill)三者皆為開源,講者在 Expo Hall 攤位歡迎大家去找她交流各自如何為 agent 做資安防護。

    “「攻擊會組合,但 code review 不會(Attacks compose, code review doesn't)。」”

    “「如果它不是被確定性地強制執行,那它就不是安全機制。Prompts 不是,規則不會自己動起來(If it isn't enforced deterministically, it is not enforced)。」”

    “「危險的輸入不只是使用者輸入的東西,也不只是你允許它執行的指令——而是所有流進模型的內容,包括你自己寫的內容。」”

23. 23

    TurboCont：用3-4位元壓縮技術降低智能體檢索(Retrieval)的KV Cache記憶體成本

    Shashi · SuperAgent TKR

    ▶ 5:55:32

    這場 talk 由 SuperAgent TKR 創辦人 Shashi 主講，探討 AI Agent 在檢索（Retrieval）時 KV Cache 記憶體暴增的問題，並介紹 Google Research 在 ICLR 2026 發表的壓縮演算法 TurboCont，主張只需用 3-4 位元儲存向量嵌入（而非傳統 32 位元），就能在不犧牲搜尋品質的前提下，將記憶體成本降低 5 倍。

    • 問題背景：使用任何 coding agent 或通用型 agent 時，隨著上下文（context）變長，效能會下降，主因是 KV cache 持續膨脹。KV cache 可以想成是「對話歷史」的快取。
    • 雲端模型的用戶通常不會感受到這個問題，因為供應商已在後端處理好 KV cache；但若在自己的裝置上本地載入模型，就會親自遇到這個瓶頸——模型本身要佔記憶體，context 也要佔記憶體，且 context 一拉長，KV cache 甚至可能比模型本身還大。
    • 在 Mac 裝置上問題更嚴重，因為向量索引（vector index）等元件全部共用同一塊 RAM 池，互相搶資源。
    • 核心洞察：embeddings 預設用全精度（32 位元）儲存，但實際上搜尋（search）只需要 3 到 4 位元的精度即可，等於平白浪費了 5 倍的記憶體。
    • TurboCont 出現前的既有解法與各自的取捨（trade-off）：
    • 量化（Quantization）：把模型壓縮成 4 位元或 8 位元，讓模型能塞進記憶體，但會犧牲品質。
    • Context Compaction（上下文壓縮/摘要化）：coding agent 常見做法，context 到達上限時，將其摘要壓縮，供下一輪 session 使用。
    • 使用較小的 embedding 模型。
    • 將運算 offload 到 CPU 或硬碟。
    • 上述方法都必須在「品質」「速度」或「需要特殊硬體」之間做妥協。
    • TurboCont 是什麼：由 Google Research 團隊在 ICLR 2026 會議發表的論文，是一種壓縮演算法，能將 KV cache 中的 embeddings 以 3 到 4 位元（而非 32 位元）儲存。
    • 技術原理：TurboCont 背後結合兩項技術——
    • PolarCont：負責產生壓縮後的向量（compressed vector）。
    • QJL：用來修正壓縮過程中殘留的誤差（error correction），根據 Google 部落格說明，QJL 僅使用 1 位元即可完成這項校正工作。
    • Google 除了發表論文外，也發布了對應的 launch/blog post，說明 QJL 與 PolarCont 的運作方式；講者提到論文本身數學與機器學習背景較重，對軟體背景的人來說偏技術，建議可先看部落格文章理解概念。
    • TurboCont 的核心主張很單純：不要把向量存成 32 位元，只存 3 到 4 位元即可，且不會損失品質——這正是這篇論文最有趣、也是「魔法」所在之處。
    • 講者提出一個值得深入理解的關鍵概念作為承接下文的伏筆：「Search doesn't care」（搜尋本身並不在乎向量精度是否為全精度），暗示後續會解釋為何降低位元數不影響搜尋準確度（逐字稿在此中斷，未完整展開）。

    “「Do not store vectors in 32 bit. Just store it into 3 to 4 bit, and that's it.」（不要把向量存成 32 位元，只存 3 到 4 位元就好，就是這麼簡單。）”

24. 24

    企業級智能體Harness剖析：用Oracle AI Database統一管理Agent記憶體(Memory)

    Kay Malcolm · Oracle

    ▶ 6:00:47

    這場 talk 由 Oracle 的 Kay Malcolm 主講，核心主張是：企業級 AI Agent 真正的瓶頸不是模型本身，而是「記憶（Memory）」——當團隊用多個 Agent/Codex 協作時，Git 只記錄程式碼、不記錄人類與 Agent 的意圖與上下文，導致協作反而變慢。講者主張用 Oracle 23ai/26ai 資料庫作為統一儲存所有記憶類型（關聯式、JSON、圖、向量）的單一真相來源，來支撐 Agent Harness 的「中樞神經系統」。

    • 講者自我定位：Oracle 資料庫產品管理團隊負責人，帶領平台開發、LiveLabs 內容開發、QA、前端四個小組，團隊橫跨美國與歐洲（EMEA）。
    • 2025 是「token maxing」時代的問題案例：團隊使用 Codex，荷蘭團隊半夜 check in 程式碼，但只 commit 了 code，沒有把 Codex 的 context（脈絡）一起記錄下來；美國團隊隔天醒來拿到程式碼卻沒有背景資訊，導致還要花時間重新測試與驗證。
    • 根本問題：AI 讓「個人」變快，卻沒有讓「團隊」變快，因為 Git 只記錄程式碼（code），不記錄人類（或 Agent）的意圖（intent）；repository 逐漸分岔（diverge），花費大量 token 卻換不到對應的生產力提升。
    • 講者提出企業級 Agent 的完整定義，不只是「模型＋workflow」，而是包含：模型（大腦）、工具（Tools，如何做事）、上下文（Context，prompt window）、記憶（Memory）、檢索（Retrieval，取回正確資訊而非全部）、安全與護欄（Guardrails/Security）。這一整套合稱為「Harness」（哈尼斯／外骨骼）。
    • 比喻：Agent 的模型是「泡在玻璃罐裡的小腦」，Harness 是「身體」，讓 Agent 真正能做事；而 Memory 則是連接大腦與身體的「中樞神經系統」，負責在整個系統中傳遞 context。
    • 講者列出五種常見記憶類型：
    • 短期記憶（Short-term）：單一 session 內的記憶，例如聊天中、Claude Code、Codex 過程中的記憶。
    • 長期記憶（Long-term）：跨 session 持續存在的記憶。
    • 情節記憶（Episodic）：「上次做某件事發生了什麼」。
    • 程序記憶（Procedural）：工具使用、執行過的步驟。
    • 語意記憶（Semantic）：概念性/事實性知識，企業場景中特別重要。
    • 講者以自己過去在 Southern Company（美國南方電力公司，位於亞特蘭大）擔任 DBA 的親身故事說明資料分裂的問題：
    • 一開始只管理關聯式資料庫（SQL 調校專家），每週要開資料庫的安全會議與 patching 會議兩場。
    • 有開發者要求儲存非結構化資料，於是安裝了專門的非結構化資料庫，會議變成 4 場。
    • 又被要求分析「電塔巡修人員的裝置」（Nokia 式裝置）與電線桿之間的關聯，以降低誤判（false positive/negative），她寫了一個 5 層 nested UNION ALL 的 SQL，執行約 20 分鐘，本質上是圖（graph）查詢的雛型；公司因此又安裝了 Neo4j，會議變成 6 場。
    • 她因此離職並加入 Oracle，希望從源頭解決「資料分散在多種資料庫」的問題。
    • 加入 Oracle 後，Joe Mundy 找她說要導入 Redis 作向量資料庫（Oracle 在向量資料庫上起步較晚）；講者指出問題核心：當資料分散在關聯式、JSON、圖、向量等多個資料庫時，Agent 很難找到「單一真相來源」，經常取錯資料且浪費大量 token。
    • 現場互動 demo：邀請 4 位觀眾分別扮演「關聯式資料庫」「非結構化(JSON)資料庫」「圖資料庫」「向量資料庫」，講者說一句話（"The cow jumped over the moon"）要求他們自行決定怎麼分散儲存、彼此不能溝通，結果證明多資料庫各自為政「行不通」，用以具象化資料/記憶分散的問題。
    • 核心賣點：Oracle AI Database（23ai / 26ai）可以在「同一張表、甚至同一個 partition」中原生同時儲存 JSON、圖（Graph）、向量（Vector）、空間（Spatial）資料，若需要不可竄改的記憶還能用同資料庫內的區塊鏈（Blockchain）能力；且支援任何工作負載、部署在任何地方（AWS、GCP、Azure、OCI、地端）。
    • 記憶類型對應儲存建議：長期記憶與程序記憶存關聯式；短期與長期記憶可存 JSON；程序記憶（步驟、關係）適合存圖；情節記憶與語意記憶適合向量＋文字儲存——但重點是這些都能統一放在同一個 Oracle AI Database 裡，避免多資料庫互不相通的問題。
    • 講者團隊實際解法：打造一個叫 "Polly" 的「記憶代理人（Memory Broker）」，取代自動化的 continuity 機制：
    • Polly 讓團隊成員（她稱之為「人類 agents」）不只共享程式碼，也共享 context（程序記憶、情節記憶、長期記憶資訊），並能跨 fork/branch 判斷該 context 屬於哪個 commit、哪個分支。
    • 技術實作：使用 Oracle Agent Memory Package（`pip install oracle-agent-memory` 即可取得的 SDK），把即時對話、記憶、事實儲存在 Oracle Autonomous Database 中，並可自由選用任意 LLM，包括透過 Oracle Private AI Services 容器跑本地模型。
    • 效果：例如 Kevin 可以把 context 分享給 Polly，Linda（現場觀眾）就能無縫接續與 Kevin 的工作，不會遇到協作斷層。
    • 講者引用三篇論文/觀點強化「記憶為核心」的論點：
    • OpenAI 一篇關於其內部 data agent 的論文，指出記憶對於讓 agent 能「正確過濾」而非單純字串比對（string matching）至關重要。
    • Harrison Chase（LangChain 創辦人）的說法：「你的 harness 就是你的記憶（your harness, your memory）」——如果你不掌控自己的 harness，就無法掌控自己的記憶。
    • 對比 Claude 自帶的記憶機制（如 memory.md 檔案）：這類似「檔案系統式記憶」，單機（one path）可行，但企業規模擴展（scale）後會出問題，跟她前述多資料庫分裂的例子類似。
    • 結論主張：AI 讓「個人」變快，但唯有建立在 Oracle AI Database 上的共享記憶（shared memory）才能讓「團隊」變快；企業不必在「檔案系統存記憶」vs「資料庫存記憶」、或「JSON vs 關聯式」之間二選一妥協，26ai 可以兩者兼具、任君選擇。
    • 資源與福利：Oracle AI Developer Hub（提供程式碼與應用範例）、LiveLabs.oracle.com（講者本人六年前開發、目前已有 4000 萬使用者，可免費用 OCI 資源做 6-12 小時的技術實作）、OCI Always Free（號稱各家雲端中最慷慨的免費方案：免費 Oracle 資料庫、免費運算、每月 3000 封 email、200GB 儲存空間，可搜尋「Oracle Cloud always free」取得）。

    “「Git 記錄的是程式碼，而不是人類的意圖（Git records the code and not human intent）。」”

    “「你的 harness，就是你的記憶；如果你不擁有自己的 harness，你就不擁有自己的記憶（Your harness, your memory. If you don't own your harness, you don't own your memory）。」”

    “「AI 讓個人變快，但在 Oracle AI database 上的共享記憶，能讓團隊變快（AI makes individuals faster. Shared memory on an Oracle AI database makes teams faster）。」”

25. 25

    打破倉庫邊界與失憶症：用Polygraph元框架(Meta-harness)串連多倉庫程式碼圖譜給智能體

    未知

    ▶ 6:22:16

    這場 talk 主張現有的 AI 程式碼智能體（agent）本質上就像被施了限制的天才工程師——能力超群卻只能看到極小部分的程式碼庫，且每次對話都失憶。講者提出以 Polygraph 這個「與智能體無關的元框架」（agent-agnostic meta-harness），透過分析組織內外所有 repo 建立統一的依賴圖譜，讓智能體產生「彷彿在讀寫一個大型單一程式庫」的錯覺，藉此解決重複解釋與跨倉庫協作失敗的問題。

    • 講者用「神燈精靈給你 Carmack，但限制他一次只能看程式碼庫的千分之一、且每次對話都失憶」的比喻，說明現在的 AI agent 就是這種矛盾狀態：能力極強卻資訊極度受限。
    • 舉了一個具體案例：組織裡有 UI、Module 1、Module 2、Platform 四個 repo，只是想把 UI 元件的一個改動傳播到整個系統，結果需要「七次解釋」同一件事——改 UI、發佈給 Module 1、發現不相容、回頭修正並重新解釋、再發佈、再解釋給 Module 1 和 Module 2、去 Platform 解釋整體如何串接、以及一週後修 production bug 時又要重新解釋一次原始改動和問題脈絡。
    • 這些解釋往往由不同的人在不同的 repo 完成，即使沒有一個人重複做全部七次解釋，這種重複解釋的成本仍然實際發生。
    • 問題可歸納為兩大類：一是「空間問題」——agent 是 repo-bound（受限於單一倉庫），一次通常只能改一個 repo，看不到整個系統（可能是成百上千個 repo）；二是「時間問題」——即失憶症，每個 session 都是白紙一張，人類反而變成了 agent 的記憶體。
    • 沒有跨 repo 的關係模型時，agent 必須依賴人類做研究：它無法把 UI 的改動與 Module 1 對齊，因為沒人告訴它，結果就是一個有問題的版本被發布上線。
    • Agent 也無法可靠地引用最佳實踐或標準，因為這些規範通常散落在其他 repo 中。
    • 寫入面的問題更嚴重：agent 一次只能寫一個 repo，因此無法驗證下游影響——案例中 Module 1 的 CI 理論上應該要因為 UI 改動而失敗，但實際上沒有；agent 明明在做 UI 改動時擁有完整資訊，卻無法同時更新所有下游消費者（consumer），逼得使用者必須不精確地、重複地向每個消費者重新解釋。若改動涉及 20 個 repo，就要重新解釋 20 次，耗費大量開發者時間，也燒掉大量 token。
    • 講者描繪了組織真正的「工作圖譜」：底層是 repository graph（組織自產的所有 artifact，加上所依賴的每一個開源 repo，可能是上千個自有 repo 加上數萬個開源 repo）；頂層是所有創造和修改這些程式碼的 agentic session；session 之間彼此關聯，repo 之間也彼此關聯，這張圖才是組織工作的真實寫照——它同時描述「底層現在有什麼」與「上層是如何演變而來的」。
    • 但目前 agent 實際看到的只是「一個 session、程式碼庫的一小部分、沒有記憶」，因為看得太少，它只能依賴真正理解系統的人類開發者；而每個開發者手上其實都握有那張圖譜中屬於自己熟悉領域的部分，agent 通常沒有。
    • 講者用另一個比喻強化論點：想像一個 agent 一次最多只能看一個檔案、往回最多只能看五則訊息——同時受限於「空間（看得到什麼）」與「時間（能看多久以前）」，任何人都會說這樣完全沒法工作，但這正是現況，而組織越複雜，這個問題就越明顯。
    • 解法：建立了一個與具體 agent 無關的元框架（meta-harness），稱為 Polygraph。核心想法是：只要一個 GitHub 使用者有權限存取數千個 repo（有些自己擁有、有些是開源依賴），就可以分析這些 repo、抽取大量 metadata，建立統一的依賴圖譜——過程中完全不需要改動任何一行程式碼，是「側面」進行的分析。
    • 有了這份 metadata 後，餵給 meta-harness，就能為 agent 製造出「彷彿在讀寫同一個大型程式碼庫」的錯覺，不論實際上要跨多少個 repo。
    • 講者以自己的圖譜為例：他自己擁有約 300 個 repo，加上專案依賴的數千個開源 repo；Polygraph 會計算每個 repo／每個 repo 裡每個 project 產出了什麼、消費了什麼（以 package 為單位），以及它們各自產生和消費了哪些 API。

    “「你會有一個天才在一邊，另一邊卻是深度殘缺的東西，而那正是現在的 agent。」（You would have a genius on one side and something deeply deficient on the other. And that's what agents are.）”

26. 26

    從D0資料科學智能體到Eve：Vercel打造的「Next.js for Agents」框架

    Andrew · Vercel

    ▶ 6:30:06

    這場 talk 由 Vercel 軟體長 Andrew 分享他花約一年時間打造內部資料科學智能體「D0」的完整演進過程，並說明這段實戰經驗如何催生 Vercel 兩週前推出的全新 agent 框架「Eve」——一個標榜「Next.js for Agents」的框架，主張建構 agent 應該像寫 Next.js 專案一樣，只需依照檔案系統慣例宣告 skills、tools、channels，框架就能自動組裝成可運作的智能體。

    • 起點發想：Andrew 與 Vercel CTO 討論，比爾蓋茲 1980 年提出「每張桌上都有一台電腦」的願景，兩人想像未來是否「每張桌上都有一個 agent」；當時是 Sonnet 4 時代，agent 還沒現在成熟。
    • 需求發掘：Andrew 走訪 Vercel 各部門（行銷、業務、財務、法務）詢問「你最討厭工作中的哪部分」，發現資料科學團隊痛點最強烈——團隊精簡但公司成長快，每次業務/行銷有問題都要資料科學家放下手邊工作、手寫 SQL、分析、回報，嚴重拖累生產力。
    • 版本一（Mega Prompt）：最原始做法是把 Snowflake schema 整包貼進 system prompt，模型生成 SQL 後人工複製貼上執行，用來驗證模型是否具備寫出有效 SQL 的基本能力，結果顯示「還不夠好，但可以透過更好的 context 和護欄改善」。
    • 版本二（多智能體鏈，D0 v2）：把資料科學家實際流程拆解為多個專責 agent——query agent、planning agent、execution agent、reporting agent，各自有獨立 system prompt 與範圍受限的工具（例如 planning agent 只有 read entity YAML 和 search schemas 兩個工具），依序串接完成「提問→查詢→報告」的完整迴圈。但這個架構後來遇到瓶頸。
    • 版本三（單一大型 agent + 自我管理狀態）：團隊發現真正需要的是「一個帶有龐大 context 且能自行管理記憶的 agent」，讓它能回顧自己做過的步驟並反思；具體做法是一個 max steps 設到 100 的超大 AI call，agent 內部自行判斷當下處於規劃、建構、執行或報告哪個階段，出錯時能自行回頭查找問題所在。
    • 內部測試翻車：這版本原本自認在內部評測拿下 30% 準確率，是「在贏」，但釋出給少數信任的 Vercel 內部人員試用後反應「很糟」，因為無法預先窮舉所有可能被問到的問題，靠人工列舉場景也不具擴展性。
    • 轉捩點：Claude Opus 4.5 搭配 Claude Code 問世，效果直接輾壓他們手工打造的 agent，幾乎不假思索就能回答大部分問題；團隊反思後發現關鍵差異在於 Claude Code 本質上是一個「檔案系統型 agent」，工具集極簡（list file、read file、run bash），不是給高度規定性的工具，而是放手讓模型探索、產生 emergent behavior，這正是模型被大量訓練熟悉的操作方式。
    • 版本四（檔案系統型 agent）：仿照 Claude Code 精神重建 D0，改在沙箱（sandbox）中執行，把整個 semantic layer 傾倒進沙箱，agent 靠 bash、read file、write file 自行探索，再額外加少數 Vercel 專屬工具；這是「最大的一次躍進」，評測分數直接翻倍。實作上非常精簡，用 npm 上的 bash tool 套件把 bash 工具接上沙箱，並把檔案掛載給沙箱讀寫執行。
    • 部落格效應：Andrew 把這段心得寫成部落格文章，發布當週該文章貢獻了 Vercel.com 70% 的網站流量。
    • Skills 系統：釋出給全公司使用後，每天湧入數千條查詢（客戶指標、業務指標、NPM 下載量等），團隊發現許多查詢形狀高度重複（聚合方式、產品查找方式、帳務資訊查詢方式都有限），於是建立自動化 job，定期把最近的查詢蒸餾成「skill」，目前已累積約 100 個 skills，涵蓋從聚合運算到特定人員資料查詢；有了 skill，每次新的 agent run 不用從零開始，一開始就帶有大量既有的上下文知識。另外還做了 Skills.sh，是目前最熱門的尋找與執行 agent skills 的工具。
    • 從 D0 到 Eve 的動機：公司內每個部門看到 D0 的成功後都想 fork 一份自建 agent，但每次重造都要重新踩過同樣的坑；團隊因此思考「能不能讓大家從最新的最佳實踐開始，而不是每次都從簡單 prompt 或第一性原理重新發明」，於是決定打造「Next.js for Agents」框架。
    • Eve 框架設計：兩週前發布，理念是只要建立 skills 資料夾、tools 資料夾、channels 資料夾並依慣例撰寫，框架就能自動組裝出完整可用的 agent；框架設定 agent = runtime + channels，runtime 內含 durability（持久性）、隔離環境執行、多模型呼叫、連接器（connections）能力。
    • 開源與 Vercel 原生整合並存：Eve 可插入開源 adapter（Postgres、OpenAI、Responses API、Docker 等連接器），也能無縫串接 Vercel 自家產品——用 Vercel Workflows 做 durability、Sandbox 做安全執行、剛推出的 Vercel Connect 生成短效 OIDC token 做連接授權。
    • 實戰驗證：團隊用 Eve 把整個 D0 agent 重寫了一遍，檔案結構變得非常簡潔（一堆 system instructions、幾個 skills、幾個 tools），易於組合與迭代。
    • Beta 客戶案例：合作夥伴 Aura 用 Eve 重建了一個類似「mini Claude」的 agent，會自動造訪網站、安裝並試用服務，相較於直接用現成的 Claude Code，用 Eve 打造的專屬 agent 步驟更少、成功率更高、洞察更好。
    • 內建可觀測性：部署到 Vercel 後即有開箱即用的 observability，可看到所有 agent runs、每一步的工具呼叫、預估成本及可能的優化建議。
    • 取得方式：即日起可到 eve.dev 直接 clone 專案、用範本啟動、輕鬆部署，也支援自架（self-host）。
    • 核心論點——為何要自建而非用現成方案：團隊在打造 D0 之前，比較過許多資金雄厚的新創做的垂直型 agent（例如專門對 Snowflake 下查詢的 agent），發現真正讓 agent 好用的關鍵在於「大量且具體的公司知識」——例如 Vercel 是網站型公司，資料查詢要深入了解該查什麼、什麼東西關聯到什麼，這些現成 agent 難以涵蓋。結論是：想真正榨出最大價值，應該自建 agent 並盡量灌入公司專屬知識。
    • 內部成果：目前 Vercel 內部已有約 20 個具備一定 PMF（Product-Market Fit）的 agent，涵蓋行銷 retro 分析、找出該聯繫誰、法務新合約談判時自動產出第一版 redline、以及資料科學查詢等；資料團隊因此生產力大增，有更多時間去優化 Snowflake 效能、補齊過去沒空建的資料來源。
    • 結語主張：Andrew 認為現在對任何規模的公司來說，用 agent 自動化 HR、財務、業務等不想做或耗時的工作從未如此容易，並認為 Eve 是目前打造這類 agent 的最佳方式。

    “「你以為自己在贏，其實是 30% 的評測分數在騙你——直到真人用了才發現有多糟。」（原話大意：We thought we were cooking. We thought this was nailing 30% of our evals, but we couldn't have anticipated some of the questions that were being asked.）”

    “「如果你真的想從中榨出最大價值，你應該自己打造 agent，並盡可能灌入公司專屬知識。」（If you really want to get the most juice out of a squeeze, you should really try to build your own agent and add in as much company-specific knowledge as you can.）”

27. 27

    日誌即是代理(The Log Is The Agent)：以事件日誌為核心的代理身分與可恢復架構

    Ishaan Sehgal · Omnara

    ▶ 6:47:21

    這場 talk 主張「日誌（log）才是代理（agent）的真正身分」，而非一般人以為的模型或執行環境。講者以 Skyrim 存檔為類比，說明角色的身分存在於資料而非硬體或引擎中，並延伸出以事件日誌為核心、可任意暫停恢復的代理架構設計原則。

    • 講者 Ishaan Sehgal 是 Omnara 的 CEO，這場 talk 的核心命題是：多數人誤把代理等同於「模型」或「執行它的環境（runtime）」，但這是錯誤的抽象層次；真正賦予代理身分的是它的日誌（log）。
    • 開場用類比說明論點：花了上百小時玩的 Skyrim 角色，究竟是什麼？不是遊戲引擎、不是 PlayStation、也不是手把——這些東西很重要、負責運行角色，但都不是角色本身。角色就是資料，也就是存檔（save file）。
    • 這個類比的關鍵在於：即使 PlayStation 燒毀，角色並沒有消失。只要買一台新主機、從雲端下載存檔，就能從原本的地方繼續。因為角色的身分、歷史與狀態全都保存在資料裡，角色「活在資料中」。
    • 把這個框架套用到代理上：代理的身分是它的資料，具體來說是日誌，而非模型或執行環境。
    • 定義「日誌」：最簡單來說，日誌是代理的只能追加（append-only）的事件歷史紀錄——每一筆使用者輸入、每一次模型輸出、每一次工具呼叫（tool call）、工具結果、權限（permission）、失敗（failure），代理的每一次狀態轉換都會被寫入日誌。
    • 這個設計的重要性在於：代理的身分不再綁定於執行環境、模型或工具——這些東西都只是在「讀取並附加」日誌。它們讀日誌、根據日誌行動，再把下一個事件寫回日誌。因此光靠日誌本身就足以恢復（resume）整個代理。
    • 一旦把代理定義為日誌，整個系統就變得容易推理：每個操作不是「從日誌讀取」就是「附加到日誌」。模型讀日誌決定下一步行動，工具執行器（tool runner）執行該行動並把結果附加回日誌，如此循環運作，一切都圍繞著日誌來協調。
    • 具體的簡化循環（loop）流程：從日誌重建狀態 → 把狀態餵給模型 → 模型提出下一步並把回應附加到日誌 → 若回應要求呼叫工具，就執行工具並把結果也附加到日誌 → 重複上述流程。
    • 關鍵洞察不是這個循環有多複雜，而是這個循環本身是「可拋棄的」（disposable）：一個 worker 可以認領（claim）某個 session、讀日誌、把代理推進一步、寫入結果，然後完全消失；之後任何其他 worker 都可以接手繼續。這代表系統具備高度的容錯與可恢復性，不依賴單一長駐進程。
    • 講者用資料庫的發展史作類比：資料庫早年也是看起來複雜、不透明的系統，充滿資料表、索引、實體化視圖（materialized view），但每個嚴謹的資料庫底層其實都是一份日誌，記錄變更的持久序列，其餘一切（表、索引等）都只是這份日誌的「視圖（view）」。講者認為代理也需要同樣的「反轉（inversion）」思維。
    • 應用到代理架構：日誌才是持久（durable）session 的主體，其他一切都只是日誌的投影（projection）——餵給模型的上下文（context）是投影、渲染出的 UI 是投影、除錯與可追溯性（traceability）是投影、稽核（auditing）是投影、壓縮（compaction）也是投影。唯獨日誌本身不是投影，它是所有投影的來源。
    • 針對「日誌即代理」這個主張，講者提出並回應兩個常見質疑：
    • 質疑一：壓縮（compaction）。日誌可以無限增長，但模型能處理的上下文視窗（context window）是有限的，所以終究需要把日誌壓縮成模型能推理的較小表示。講者強調：壓縮不是魔法，也不違反「日誌即代理」的主張，因為壓縮本質上是有損的（lossy）——壓縮後的摘要不可能完美還原代理原本的完整狀態，一定會丟失資訊。真正的紀錄是完整日誌，壓縮只是其中一種投影，就像「實體化視圖不是資料庫本身」「對話摘要不是對話本身」。只要保留原始日誌，就能隨時重新生成新的投影；但如果丟掉原始日誌、只保留壓縮結果，就等於永久失去了部分代理身分。因此最乾淨的做法是：把壓縮當成一種「盡力而為、有損的分支（fork）」，可以把它當成一份新的日誌繼續往下恢復，而不是取代原始日誌。
    • 質疑二：日誌之外會改變的狀態（外部世界的變化）。代理可能會編輯檔案、建立 GitHub issue、寄送 email——這些顯然是日誌之外的狀態變化。講者的回應是：日誌本來就不該包含整個世界，日誌只是代理對世界的視角（view）。就像 Skyrim 存檔不包含整個遊戲引擎或地圖上的每個素材，只包含把玩家丟回遊戲世界所需的「玩家專屬狀態」。同理，日誌只能忠實保存代理的身分與它對世界的認知，但無法讓外部世界變成確定性（deterministic）：如果代理已經寄出一封 email，回溯（fork back）並不能把信收回；如果底層有檔案在代理不知情的狀況下被改動，代理也不會知道。日誌的職責是記錄代理做了什麼、看到了什麼、什麼改變了、以及它繼續執行所需要的東西——這就是它保存身分的方式，而不是試圖記錄整個世界。
    • 一旦把日誌當成系統的基本原語（primitive），許多系統特性會自然浮現，第一個提到的特性是可靠性（reliability）。講者以 Claude Code 舉例：目前如果使用 Claude Code，代理走到一個權限提示（permission prompt）時進程意外中止，之後恢復（resume）時，這個權限提示會消失，代理就卡在暫停狀態動不了——這在生產環境中是不可接受的。權限提示應該要能被保留下來。講者指出，這正是「日誌不是代理」的架構所導致的問題，凸顯了把日誌設為代理本體的必要性（逐字稿在此處中斷）。

    “「Your character is data. It's the save file.」（你的角色就是資料，就是那份存檔。）”

    “「The important insight is not that this loop is complicated. The important insight is that the loop is disposable.」（重點不在於這個循環有多複雜，重點在於這個循環是可拋棄的。）”

    “「The log is not supposed to contain the whole world. The log is just the agent's view of the world.」（日誌不該包含整個世界，日誌只是代理對這個世界的視角。）”

28. 28

    無程式碼的代理：Skills、YAML與檔案系統如何取代Python——Gemini Interactions API與Antigravity遠端代理

    Philipp Schmid · Google DeepMind

    ▶ 6:54:59

    這場 talk 講述講者如何用同一個「GitHub PR 審查代理」案例，逐步演化出三個版本，展示 AI Agent 開發如何從「寫大量 Python 程式碼」演變成「幾乎只靠檔案（Markdown、YAML）與遠端沙盒環境」就能運作。核心主張是：隨著模型能力提升，開發者應該不斷刪除自訂的編排程式碼，把控制權交還給模型，只保留領域指令、工作流程與評估（evals）。

    • 開場引用 Simon 對 agent 的定義：「LLM agent 是在迴圈中執行工具，直到達成目標」，並以此為整場 talk 的基礎框架。
    • 介紹 Google 新的統一 API「Interactions API」，可用同一介面呼叫 Gemini 模型或呼叫具備 Sandbox 的 Agent，支援伺服器端狀態管理與背景執行，並統一處理工具呼叫、多模態理解與生成。
    • Interactions API 的一大設計改變：從傳統「以 turn 為單位」的對話歷史，改成「steps 時間軸」（使用者輸入、推理、function call、function result 各自獨立步驟），不再需要濫用 user role 來塞入環境回傳資料，更適合 reasoning model 與多角色的 agent 場景。
    • 第一版 Demo（原始 Python 迴圈）：需要自行寫 agent class、跑迴圈、手動解析 function call 與 function result、定義 JSON schema、寫系統指令檔、用 GitHub API 實作工具邏輯。缺點是 agent 完全受限於預先定義好的工具，問「舊金山天氣」時只能回答做不到。
    • 第二版 Demo（導入 Agent Framework，以 Google 的 ADK 為例）：用 Agent class 統一處理工具迴圈、function calling、重試、錯誤處理，移除大量樣板程式碼；工具的 JSON schema 改由函式簽名自動生成，不用再手寫。但仍然限定工具集合，問天氣一樣答不出來，開發者仍要自己寫 Python 工具、定義規則、準備執行環境。
    • 第三版 Demo（Remote Agent，Google I/O 發表的 Antigravity Remote Agent，跑在 Gemini API 上）：由驅動 Antigravity IDE 同一套 agent harness 提供，但 Gemini API 上是「通用型 agent」而非編碼專用 agent，系統指令與工具（如內建 Google Search）有所不同。
    • Remote Agent 引入「environment」參數，讓 agent 存取一個隔離的雲端 Sandbox，可執行 bash 指令、讀寫檔案；environment 可設定「sources」，可以是 GitHub repo、GCS bucket 或 inline files。
    • 安全設計：Sandbox 外圍包一層 network proxy，agent 對外發送請求時才由 proxy 動態注入憑證，agent 本身從未看到真正的 credential；也能限制 agent 可存取的網域，預設為全部開放以降低使用門檻。
    • 提供 Agents API，可用自訂 ID 儲存系統指令、base agent、base environment 組合成可重用的自訂 agent，之後呼叫方式與呼叫 Gemini 模型或 Antigravity Agent 完全一致。
    • 第三版 Demo 實作內容：沒有原始碼資料夾，只有 agents 目錄下一個 agents.md 系統指令檔，內容改成「你有 GitHub CLI 可用」，不再寫特定的 PR 讀取工具；另外提供一個 bash script，檢查 GitHub CLI 是否已安裝，沒有就自動下載安裝。
    • Demo 執行過程：Agent 先探索 Sandbox 確認有沒有 GitHub CLI，沒有就自行安裝，然後用 GitHub CLI（而非預先定義的 function）完成 PR 審查；問「舊金山天氣」時，agent 自主選用 Google Search 工具查到當天（7月2日）氣溫約攝氏20度，展現通用工具解決任意任務的能力。
    • 呼叫方式簡化為一次 API 呼叫：帶上 sources（bash script + agents.md）、GitHub credentials（分別對應 API 與 github.com 兩個 URL，因為 Git 指令與 HTTP 指令各自需要）、domain 設定為「all」讓其能存取全網但無憑證，並帶上前一輪的 interaction ID 維持多輪對話。後端會啟動 Cloud Sandbox、載入 agents 檔與 skills，模型與 Sandbox 之間自行完成整個 function call 迴圈。
    • Remote Agent 帶來的改變：不需要自己寫迴圈、不需要自己做工具路由，對話與 session 狀態由伺服器端管理（只需提供新輸入），context window 的管理與壓縮（compaction）也自動處理，並取得一個隔離的遠端 Linux Sandbox 可執行程式碼。開發者仍需負責的部分：撰寫 instructions/rules/behaviors（agents.md）、提供 capabilities/context/skills、以及自行做 evals。
    • 擴充能力方式的對比：舊方法要新增能力（例如做 PR 的安全掃描）需要寫新 Python function、定義新的 function schema、修改工具程式碼；新方法只需要寫一份 skills.md 檔案（可附帶要用哪個 CLI 工具的說明），或直接把 CLI 工具放進 environment，完全不用改程式碼。
    • 舉出業界案例佐證「用檔案取代程式碼」的趨勢：一位歐洲工程師（Kerser）用約 200 行的 agent 檔案（skills + markdown）取代了原本約 12,000 行 TypeScript 的 Git worktree 硬編碼編排邏輯。
    • 更多「痛苦教訓」案例：Manus 在過去六個月內重構其 agent harness 五次；LangChain 的 OpenDeep Research 一年內重新架構三次；Windsurf（講者念作 Wurzel）移除了 80% 的工具，換來更少步驟、更快回應與更高準確率。
    • 講者提出的通則：模型能力越好，就越能移除自訂的編排程式碼；如果隨著模型進步，你的 harness 反而越來越複雜，代表你可能過度工程化（over-engineering）了你的 agent harness。
    • 「Agents are just files」的理念：能力擴充靠寫 Markdown 檔案；agent 可以從中學習，也能自己生成檔案——例如在一個 session 中要求 agent 記住某個規則或偏好，它會把內容寫進檔案供之後 session 重用；長時間執行的 session 中若想切換到另一個功能，也可以把交接資訊寫成檔案，讓 agent 之後接續處理（context 外部化）。
    • 給聽眾的三個核心建議（takeaways）：（1）不要跟模型對抗，停止微觀管理執行路徑，提供通用工具讓模型自己探索、推理、找出解法；（2）專注做「屬於自己的事」，即領域指令、工作流程設計、乾淨的工具定義，以及最重要的 evals（驗證結果）；（3）「build to delete」——建立東西的目的是為了未來能刪除它，因為模型越進步，能刪除的自訂程式碼就越多。
    • 呼籲聽眾可掃描 QR code 直接在 AI Studio 試用 Antigravity harness，或建立 API key 開始使用；Google 目前正在為此 API 開發免費方案（free tier）。

    “「如果你的 harness 隨著模型進步而變得更複雜，那你很可能是在過度工程化你的 agent harness。」”

    “「Agents are just files」——用 Markdown 檔案取代程式碼來擴充 agent 能力。”

    “「我們的目標是 build to delete：模型越進步，我們能刪掉的程式碼就越多。」”

29. 29

    面具與鏡子：角色扮演語言代理(RPLA)評測的盲點與米蘭達假說(Miranda Hypothesis)——以漢彌爾頓、林肯人設為例

    未知

    ▶ 7:13:04

    這場talk探討角色扮演語言代理(RPLA)在扮演真實歷史人物時的評測盲點：現行業界頂尖的評測方法(如InCharacter)只測量「像不像」該角色(流暢度、人格一致性)，卻無法偵測模型是否用了該角色在世時不可能擁有的知識或立場去推理。講者提出「米蘭達假說(Miranda Hypothesis)」，以漢彌爾頓(Alexander Hamilton)為案例，說明訓練語料中「文化再現(如音樂劇)」的份量遠超「原始史料」，導致模型生成的是被流行文化「壓縮平滑」過的角色複合體，而非忠於史實的人物；更關鍵的是，後訓練對齊(RLHF)不但無法修正此問題，反而會因「演算法諂媚」而強化它。

    • 開場示範：講者展示Character AI、Hello History等已被數百萬人使用的角色扮演平台，並用自建的開源框架Companion，讓Claude Opus 4.7扮演林肯，問「總統在什麼情況下可以不經國會同意就把國家帶入戰爭」，得到一段流暢、聽起來很像林肯、但論證邏輯站不住腳的回答——這正是全場要回頭檢視的核心問題。
    • 核心論點(thesis)：如果角色扮演代理最主要的失敗模式是「時代錯置的拼接(anachronistic compositing)」，而現有評測只測量流暢度與人格一致性，那麼這些評測結構性地無法偵測到這個主要的失敗模式。
    • 講者背景：本身是數據科學家，在一家勞動市場中介機構負責分析實驗室、大規模上線AI產品；但受過行為流行病學訓練，長期研究「資訊環境如何形塑人群」。這個「工程師+人文學者」的雙重視角，是這篇論證站立的位置——人文洞見不是工程之外的裝飾，而是工程師目前缺失的量測工具。合作的歷史學者為多倫多大學的Rick Halpern與華盛頓學院的Sean Martin。
    • 領域研究脈絡：陳等人(2024)、王等人(2026)的綜述指出RPLA研究經歷三個階段——(1)規則式模板(canned response)、(2)模仿(imitation，複製語氣腔調)、(3)現在的「認知模擬(cognitive simulation)」，透過心理學框架建模人格、維持角色狀態與結構化記憶，並以「動機-情境鏈」生成行為。
    • 具體系統舉例：COSER(王等人)用近1.8萬個角色、數百本書的語料訓練出動機驅動代理，700億參數模型在三個基準上打平或超越GPT-4o；SciMem用26項質性心理指標加知識圖譜記憶建模角色；InCharacter則改用「心理訪談」而非自我評分量表來評測人格忠實度，這是方法學上的進步，也是文首提到「80.7%人格對齊度」數字的來源。
    • 評測工具測量的是什麼／不測量什麼：現有工具能日益精細地測量模型是否重現角色的人格(大五人格、語域、動機架構)，但沒有機制去測量模型能否把角色的思考侷限在其一生特定時刻的真實紀錄範圍內。王等人自己的文獻也指出，包括「LLM-as-judge」在內的自動化評測系統性地偏好「流暢與風格自然」，勝過「忠於角色真實紀錄」——這兩者是不同的屬性，而兩者之間的落差正是整場talk的核心。
    • 「面具與鏡子(mask and mirror)」比喻：「面具」式的角色扮演成功標準只問「這聽起來像不像這個人？」，從不問第二個問題「這是這個人在人生這個階段真的可能知道、相信或主張的嗎？」。整個領域的評測體系都是繞著「面具」打造的。
    • 結構性主張：說服力(convincingness)與忠實度(fidelity)是彼此獨立的屬性——一個系統可以在人格一致性上拿滿分，同時讓某個歷史人物用他本人歷史上不可能擁有的知識去推理。
    • 漢彌爾頓案例示範(可在任何前沿模型上重現)：
    • 講者先播放音樂劇《漢彌爾頓》片段(講他14歲白手起家、目睹奴隸貿易慘況等)，再讓前沿模型扮演漢彌爾頓回答「你為什麼這麼拼命工作？」，模型回答的內容充滿「孤兒/移民奮鬥」敘事弧線、建國修辭姿態，語氣正是2015年音樂劇的情感基調，而非真實漢彌爾頓文獻中更乾澀、更法律用語的聯邦黨人文風。這些手法都不是模型「發明」的，而是「繼承」自訓練分布中占主導的音樂劇文本。
    • 更關鍵的一題：問模型「漢彌爾頓對奴隸制的立場是什麼？」模型給出乾淨、道德立場鮮明的廢奴主義發言，提到他是紐約廢奴協會(New York Manumission Society)成員。但歷史學者指出：真實紀錄是有爭議且複雜的——漢彌爾頓確實是該協會成員，但史料也記載他曾替姻親與客戶經手涉及奴隸的交易，且他所依賴的政治聯盟中有蓄奴者，他並未公開反對。模型完全沒有呈現這個複雜性，把一個真正有爭議的歷史紀錄「磨平」成單一、討喜的英雄形象——這正是音樂劇先做的事，模型只是繼承了這個磨平動作。
    • 而現有的「角色風格評測(in-character style eval)」會給這種輸出高分：流暢、語域正確、人格一致——每一個被測量的軸都通過了，但評測完全沒有機制察覺這段推理其實是被一個晚了兩百年才出現的敘事「磨平」過的。講者的比喻：「溫度計回傳了一個自信的數字，聲稱那是溫度，但它量的是別的東西。」
    • 米蘭達假說(Miranda Hypothesis)：命名取自音樂劇《漢彌爾頓》創作者林-曼努爾·米蘭達(Lin-Manuel Miranda)，強調這不是指控音樂劇是反派——音樂劇是一部立足於悠久歷史傳統、本身並非其發明的重要藝術作品。之所以以此命名，是因為漢彌爾頓是典範案例：這個文化再現如此飽和、修辭力量如此強大、對當代觀眾如此道德清晰易懂，以至於它已經功能性地「覆寫」了公眾記憶中真實的史料版本——講者主張，也覆寫了每個前沿模型的訓練語料。
    • 假說的三個主張：
    • 輸入端：訓練語料中，某人物「文化上主導的再現」在數量與時效性上系統性地超過該人物的原始文獻紀錄。
    • 機制端：自迴歸的next-token預測把兩者一起壓縮進參數中，架構上沒有能力區分「1789年的一封信」和「2019年的一則爆紅推文」，於是輸出預設走向「以顯著性加權的複合體」。
    • 輸出端：產生的人設流暢、語域可信、對現代使用者道德上清晰易懂，但這個人設對應不到這個人物一生中任何一個真實存在過的時刻。
    • 論文原句(轉譯)：「複合體漢彌爾頓知道自己將成為百老匯音樂劇的主角。複合體林肯即使在他寫出蓋茲堡演說之前被召喚，也已經讀過蓋茲堡演說了。」
    • 語料量化對比：聯邦黨人文集(Federalist Papers)是固定語料，約17.5萬字；而因音樂劇而生的內容——評論、歌詞、粉絲分析、課綱、新聞、社群媒體、衍生作品、學術研究、乃至「研究學術研究的研究」——其數量以數量級超過原始文獻紀錄，且更新、更頻繁出現。音樂劇不只是「存在於」語料庫中，而是在關於漢彌爾頓的所有再現的分布中占據主導地位。
    • 真實世界案例佐證：阿爾巴尼的Schuyler Mansion(伊莉莎·漢彌爾頓娘家故居)，在音樂劇首演後一年內參觀人數幾乎翻三倍，且年齡層明顯下降。現場解說人員記錄，新來的訪客已經帶著一套「背好的知識」，其中許多是錯的——例如訪客普遍相信斯凱勒家只有三個女兒(因為音樂劇聚焦於三姊妹)，但實際上斯凱勒家有15個孩子、8人長大成人。解說員的工作變成長期、耗神地「反教育」音樂劇灌輸的錯誤印象。講者指出：模型版本的「這些訪客」正是同一股力量的下游產物。
    • 對齊(alignment)無法解決、反而放大問題：一般會假設後訓練與強化學習能把模型拉回真實紀錄，但講者主張恰恰相反——會被放大。原因是結構性的：人類評分者用自己的概念框架評估輸出，而這些框架本身就是被同一批文化主導敘事塑造出來的，評分者從小接觸的漢彌爾頓和一般人一樣。所以當對齊訓練去優化「人類偏好」時，其實是在優化「更貼合評分者早已被神話化的既有認知」的輸出。這被稱為「演算法諂媚(algorithmic sycophancy)」，這裡有明確的目標對象：模型因為給你「你已經相信的那個漢彌爾頓」而被獎勵。拼接(compositing)不是後訓練可以修補的bug，而是會在每一個足夠「顯著」的歷史人物身上被預設渲染成文化複合體，並被對齊過程強化。

    “「如果一個主要的失敗模式是時代錯置的拼接，而你的評測測量的是流暢度與人格一致性，那你的評測就無法偵測到這個主要的失敗模式。」”

    “「溫度計回傳了一個自信的數字，聲稱那是溫度。但它量的是別的東西。」”

    “「複合體漢彌爾頓知道自己將成為百老匯音樂劇的主角。複合體林肯即使在他寫出蓋茲堡演說之前被召喚，也已經讀過蓋茲堡演說了。」”

30. 30

    第二節開場致詞與贊助商致謝：回顧上午Mike Krieger爐邊對話

    Ralph Chabrit · Replit

    ▶ 7:39:51

    這是研討會第二節開場的主持串場片段，講者 Ralph Chabrit（Replit 開發者關係工程師）以 MC 身份歡迎聽眾回到第四天議程，感謝各級贊助商，並簡短回顧上午的重點內容，最後隆重介紹下一位講者。

    • 主持人開場提醒這是大會最後一天、最後一個環節，呼籲聽眾打起精神專注聆聽接下來的議程。
    • 提到當天稍後還有 Startup Battlefield（新創競技場）環節，暗示會有精彩內容但賣關子留待後續公布。
    • 依序感謝各級贊助商：呈獻贊助商 Microsoft、實驗室與白金贊助商、金牌贊助商，以及銀牌與銅牌贊助商。
    • 回顧上午議程重點：主題演講聚焦於「harness engineering」（工具/框架工程），並介紹了關於 AI 系統的新協定（new protocols）。
    • 上午另一亮點是與 Anthropic 的 Mike Krieger 進行的爐邊對話（fireside chat）。
    • 主持人分享自己當天最喜歡的一個 takeaway：未來將會有開發者把程式碼送上太空（"known developers are going to be shipping code to space"），認為這件事非常酷。
    • 介紹下一位講者時特別強調對方是一位 YouTuber，以「大膽發言、強烈立場、且經常改變自己的想法」聞名，並開玩笑說對方可能會評論某個 AI 模型很厲害，隔天又發影片說自己講錯了。
    • 主持人形容這位講者是社群在對產業現況感到困惑時會尋求解答的意見領袖（influencer），並特別強調不論是否認同他的觀點，沒有人能否認他的真實／直率（authenticity）。
    • 最終邀請講者「Theo」上台（片段在此結束，尚未進入 Theo 的正式演講內容）。

    “「Whether you agree with him or not, one thing you cannot take away from our speaker is his authenticity.」（不論你是否認同他，沒有人能否定他的真實直率。）”

31. 31

    AI「精神錯亂」與軟體業的擬物化時代：從Sonnet 3.5、Opus 4.5到Mythos，呼籲開發者「想得更廣」(Think Wider)

    Theo Browne · t3.gg

    ▶ 7:42:22

    這場 talk 由 Theo Browne（t3.gg）主講,以他從 Sonnet 3.5、Opus 4.5 到 Mythos 的個人使用歷程為主軸,主張 AI 模型的進步速度已經超過人類自身成長的速度,開發者不該再執著於過去的工具信仰與身份認同,而應該學會「想得更寬」(Think Wider),用更大的膽識去打造原本被認為「太大」而不敢碰的產品範疇。

    • Theo 把近期模型發展分成三個「時代」:Sonnet 3.5 是「工具呼叫時代」——不是第一個能做 tool call 的模型,但是第一個能在程式碼庫情境下穩定可靠到可以日常使用的模型。
    • Opus 4.5 是一個巨大跳躍,代表能執行「長時間任務且不失去脈絡」的能力:不再是一步步下指令,而是可以直接告訴它你要什麼,它自己想辦法完成需要數小時而非數分鐘的任務,並能自己測試、驗證工作成果。
    • 最新的 Mythos(與 Fable)代表「編排(orchestration)時代」:它不只理解你的程式碼庫,還理解自己,懂得如何派生額外的模型、拆解工作以更可靠地完成並事後驗證——而且你不需要客製化工具或「軟體工廠」系統,只要用 prompt 要求它這樣做就行。
    • Theo 坦承自己過去曾誤判「模型撞牆」,現在他確信模型仍在加速進步,且速度比人類自我提升的速度更快,因此策略不該是「讓自己變更強」,而是「把目標設得更大(go bigger)」。
    • 他舉例:自己過去工作中大多數 JIRA 票單,用 Opus 4.5 就能輕鬆解決,但那份工作根本不會從 Mythos 這種等級的模型中獲益——代表用不上更強模型,就是因為野心設得不夠大。
    • 用 iOS 擬物化設計轉變作類比:iOS 6 以前的 App 圖示會刻意模仿真實物品(指南針、書架),因為要說服使用者手機能取代舊工具;iOS 7 之後 Apple 不再需要說服,轉而擁抱更好用的介面(如導航 App 用清楚的紅色方塊、228 度數字取代擬真指南針畫面)。他認為軟體業現在正處於類似的「擬物化階段」——終端機(terminal)其實不是好介面,但大家因為熟悉、有情懷而硬要用它,自然語言其實不屬於終端機這種介面形式。
    • 他批評開發者對工具、框架、語言的執著已經變得不理性:例如 Git 的環境變數檔(.env)無法直接被版本控管、需要額外系統才能團隊共享,這其實只是 Git 早期設計的歷史包袱,卻被整個產業當成理所當然。
    • 他也批評工程師以「會寫什麼語言」作為身份認同與資歷指標(例如認為「只會寫 JavaScript 不算真正的開發者」),認為這種心態早已不合時宜,而且以後只會更不重要。
    • 談到「不敢刪程式碼」的沉沒成本心態:很多工程師因為同事已經花了一兩週寫某個 PR,即使方案不對,還是會因為不想面對尷尬對話而「愧疚式合併(guilt merge)」。他認為 AI agent 的一個好處是——你可以毫無心理負擔地砍掉它寫的東西重來。
    • 分享自己實際打造過的三個專案作為「等級」對照:最底層是「side project」等級的 Reddit 迷因爬蟲(2021 年,花 2-3 天做的,爬 Reddit 程式幽默版熱門文章整理後貼到 Twitter);中間是「startup」等級的 Pang(他透過 Y Combinator 做的直播工具,讓內容創作者能在 OBS 裡輕鬆做高品質協作直播);最上層是他正在做的「too big(太大)」等級專案——一個功能比 Vercel 更廣的全端雲端平台(內建 auth、內建資料庫等)。
    • 核心觀察:過去這三個等級的分類,現在因為模型變強,「整體都往下移了一級」——過去算 startup 等級的東西,現在只是 side project 等級,甚至有很多新創公司的整個產品,其實就只是一個 markdown 檔案(「G-brain tier」),透過把 markdown 直接 pipe 給 Codex 或 Claude 執行就能跑。
    • 他舉自己的實例:他原本有一套服務,會把多個 GitHub repo 裡開放的 PR 全部拉出來、用 AI 審查、排優先序,結果現在這整套服務就是一個 markdown 檔案——內容就是「看這四個 repo 的 open PR、判斷狀態、排優先序,完成後把靜態 HTML 上傳到 S3 並給我連結」,並用 Cron 排程每天早上 9 點(實際跑在 9:15-9:20)自動產生當日工作清單。
    • 但他也坦言,現在他已經不知道「太大(too big)」的邊界在哪裡了——訓練自己的模型、做自己的作業系統、直接挑戰 NPM/Node,他都不確定算不算「太大」,而這種不確定既讓人害怕也讓人興奮,意味著必須持續把目標推得比「合理」更大,才能找到真正的極限。
    • 提出「想得更寬(Think Wider)」的核心框架:軟體有「廣度(breadth,涵蓋範圍)」與「深度(depth,單一領域的功能豐富度)」兩個維度。以 Vercel 為例,Vercel 不會、也不需要追上 AWS 的廣度,但它在「全端前端伺服器」這個領域做得比 AWS 更深,深到連 AI agent 都更偏好用 Vercel。
    • 過去新創公司不敢挑戰像 AWS 這種廣度覆蓋型巨頭,是因為沒有數千名工程師去覆蓋那麼多功能;但現在情況變了——例如靠足夠的 prompting,一兩天工作量就能把一個資料庫平台功能做進自己的產品裡(雖然不到 RDS 等級的可靠度,但足以讓使用者開始嘗試)。
    • 提出「產品架構設計得當,讓使用者自己補上你沒做的功能」的策略,並舉 Slack 為例:Slack 本身「產品並不好」,卻意外變成使用者拿來跑 agent 的平台,因為它的 Slackbot API 給了剛好對的形狀,讓使用者能自己把想要的功能建進去,而這不是 Slack 自己該煩惱的問題。
    • 結論呼籲:現在正是「與 Slack 競爭」「打造自己的 AWS」「直接挑戰 Salesforce」的時機——聽起來很蠢,但如果你的點子聽起來不夠蠢,那就代表你的點子還不夠大。

    “「如果模型會持續變得更好——而我現在很有信心地說,它們正在變得更好——那我們就沒辦法只靠讓自己變得更好來跟上,所以我們必須把目標做得更大(go bigger)。」”

    “「如果你的點子聽起來不蠢,那是因為你的點子還不夠大。」”

    “「G-brain tier:一個 markdown 檔案。你知道這場活動裡有多少公司,他們整個產品其實就只是一個 markdown 檔案嗎?這太瘋狂了。」”

32. 32

    打造AI原生組織：技能檔案即員工、公司大腦(Company Brain)與開源記憶層G-Brain，如何讓生產力提升400倍

    Garry Tan · Y Combinator

    ▶ 7:57:57

    這場talk由YC總裁Garry Tan主講，核心主張是：AI原生組織的關鍵不在於用了哪個模型，而在於「如何佈線工作」（wire the work）——把公司的每個職能拆解成「技能檔案」（skill file），並用「公司大腦」（Company Brain）作為記憶與檢索層，讓一個人能做到過去1000人的工作量。他以自己從2013年到現在的產出提升約400倍為例，說明這不是比喻而是可衡量的機制轉變，並介紹了自己開源的記憶層專案G-Brain。

    • Garry Tan在2013年當YC合夥人兼工程師時，扣掉註解和無用程式碼，每天大約只能寫出14行「可用邏輯行」，這在當時是業界中位數水準。
    • 今年他全職經營YC、工時反而更少（因為要接小孩下課），但產出經他自己計算約為當年的400倍；即使用最嚴苛的方式打折（假設一半是樣板程式碼、他在自我吹噓），下限仍有8倍、中位數約80倍，數字依然很大。
    • 關鍵洞察：2倍產出的人和100倍產出的人用的是「同一個Claude、同樣的權重、同樣的context window、同樣的API」，槓桿不在模型本身，而在於如何組織與佈線工作。
    • YC winter 25梯隊中有四分之一的公司程式碼庫是95% AI生成的，一年後這批成了YC史上成長最快、最賺錢的梯隊；YC史上已有94家公司從種子輪成長到營收超過1億美元。
    • Garry將「組織」直接映射到agent架構：技能檔案（skill file）＝員工，一項技能只做一件事，寫清楚到任何人都能執行；resolver table（當Claude Code提示context太大時你會建立的分流表）＝組織架構圖，決定任務該交給誰處理；filing rules（歸檔規則）＝內部流程規範；trigger evals（觸發測試，驗證例如「需要修改測試檔時，test.md有沒有被正確載入」）＝績效考核。
    • 案例：Emergence（一家AI app builder，2024夏季梯隊）從公開發布到9位數ARR只花8個月，達到1500萬ARR時只有15名員工；Retail（2024冬季梯隊）營收6000萬美元，員工僅約40人——這種人均營收在軟體業、石油業、鐵路業歷史上都不曾出現過。
    • 真正的AI原生公司不是靠雇用大量銷售、客服、營運、財務人員，而是把這些流程都編碼成「技能」讓agent執行，工程師的工作變成維護這些技能、處理技能還做不到的部分。
    • YC自己內部轉型的例子：不只是工程師，連媒體、活動、財務團隊——從沒開過終端機的人——現在都在寫技能檔案和Cron job；財務部門有位同事用內部的OpenClaw和Company Brain，把大約100個Excel活頁簿整合成一個她自己做的app，她現在的角色變成「管理agent的經理」。
    • Garry提出所有AI工程問題幾乎都源自「計算發生在錯誤的空間」，計算主要發生在兩個地方：潛空間（latent space，即LLM本身）負責品味、判斷、理解人類模糊的意圖，是非確定性運算，用markdown檔案來引導；確定性空間（deterministic space）則是工程師熟悉的程式碼（TypeScript、Erlang等）。
    • 實例：YC即將舉辦的Startup School有6000人參加，其中一個實驗是要把800人完美配對分組（左右鄰座是最適合認識的人），這種多維座位排列的計算必須放在確定性空間，而不能塞進LLM的context window裡；LLM負責處理「人」的部分去安排座位，過去要花一個月、印800頁紙人工排的工作，現在幾百美元的token加10分鐘就能完成。
    • 工作記憶（working memory）比喻：人類大腦一次只能記住7±2件事（認知心理學經典論文，也是為何本地電話號碼是7位數、購物清單第8項會忘記的原因），人類建立的每個機構、每張checklist、每個組織圖、每個檔案櫃，本質上都是為了彌補這個記憶限制而生的「義肢」。
    • 相對地，AI agent可以持有約100萬token的working memory，約等於1000頁、或3本《哈利波特》同時攤開在腦中，還能在裡面找到一根針並跨三本書做綜合分析——這是一種完全不同的運作規模，即使不算AGI，也是全新的操作範式。
    • 但3本書雖然很多，相對公司整體知識而言仍然很少：公司是一整座圖書館（每封email、每場會議、每個決策及其推理過程、每個客戶對話、每次事後檢討），真正決定agent是天才還是金魚的關鍵，是「誰決定哪三本書該攤開在桌上」——這就是context engineering，也就是Company Brain（公司大腦）的本質：圖書館加上圖書館員。
    • Garry反駁「這不就是RAG嗎」的質疑：檢索（retrieval）確實只是基本元件（就像Postgres只是B樹），真正困難的是周邊機制——一開始要寫進知識wiki的是什麼、如何被豐富與連結、什麼該被提升為熱記憶、什麼該歸檔為冷參考、兩個事實矛盾時誰來仲裁。他的結論：「檢索很容易，值得被檢索才是產品。」
    • G-Brain是Garry公開建置的開源記憶層專案，可搭配任何harness使用，但特別適合搭配OpenClaw／Hermes agent，本質上像是「給agent用的Postgres」，作用是為任何任務判斷該載入哪三本書進agent的腦中。
    • Garry個人的G-Brain一開始只有一屋子的書量，現在已成長為約22萬頁的「倉庫」，內容多由他的agent從他的email、會議、20年筆記與生活經驗中寫成，這就是他的「第二大腦」；當有創辦人寄信來求助時，在他讀完信之前，agent已經把過去與該創辦人的所有對話、三家遇到同樣困境的投資組合公司、以及當時真正有效的解法都調出來了——這是助理與同事之間的差別。
    • Company Brain的失敗模式：沒人維護的大腦會變成「檢索很強的垃圾場」，檢索會很有自信地端出過時的事實；壞的技能檔案會把壞流程永久固化下來。
    • 解方：核心元件不是單純的記憶，而是「記憶+衛生管理」——每個事實都要有出處（provenance）、新資訊與舊資訊衝突時要有矛盾檢查機制、以及一位（人類+agent組成的）圖書館員負責持續修剪。把大腦當成正式的生產基礎設施來經營才會持續複利，當成垃圾場丟資料只會得到一個「錯得很有自信、還無法追蹤錯在哪」的agent。
    • Garry認為自己最重要的一個習慣（his signature move）是：絕不做一次性工作（never do one-off work）。用OpenClaw或任何harness做完一項任務、對結果滿意後，不要就此打住，而要把它「技能化」（skillify），他在X上有發過一篇教學文章，搜尋"Skillify it"就能拿到那個技能檔案，載入自己的harness就能把剛完成的工作轉成可重複使用的技能；他強調「如果同一件事要被要求做兩次，就代表你失敗了」。
    • 會持續「學習並固化」的組織每天都會更聰明，不這麼做的組織不管模型多強，每天早上醒來都是失憶狀態；模型品質是租來的，但自己建的大腦是你真正擁有的資產。
    • Garry建議現在該打造的公司：AI原生公司——精簡團隊、每件事都有技能檔案、創辦人仍親自寫程式、有公司大腦/個人AI（可用開源免費的G-Brain，也可以用其他做得好的替代方案），從第一週就開始累積這座圖書館，讓整個組織以約400倍的效率運作。
    • 他認為最大的「藍海」機會是：每間公司都即將需要一個大腦（memory layer），讓你永遠不用重新問已經知道的事，一個真正了解你的個人AI；G-Brain是他公開以MIT授權開源打造的專案，他不打算從中營利，因為他認為這一層應該像Linux一樣開放，希望有人能在這個領域打造出定義性的公司，並表示願意透過YC投資。
    • 工具選擇上他坦言：不一定要用他的工具，OpenClaw是法拉利，他會一直推薦，但Codex是很好的本田，能做到90%的效果，雖然不會讓人驚艷但足夠帶你抵達目的地；真正重要的是概念本身（技能檔案作為員工、圖書館員、絕不做一次性工作），這些概念可以帶到任何技術棧上，不限於他的專案。
    • 結尾故事：Garry有位朋友的兒子患有罕見型癲癇，這位父親建立了一個含8萬個markdown檔案的資料庫，作為「一個小男孩專屬的公司大腦」，沒有實驗室、沒有補助、沒有任何許可，靠一台筆電和一座圖書館，把自己對兒子病情的理解推向人類已知極限——Garry認為這正是他整場演講所描述的架構（圖書館、圖書館員、在對的時刻打開對的三本書）的真實範例。

    “"The 2x people and the 100x people are using the exact same Claude, same weights, same context window, same API. So the leverage is not in the weights. It's in how you wire the work."（2倍產出和100倍產出的人用的是完全同一個Claude、同樣的權重、同樣的context window、同樣的API，槓桿不在權重，而在你如何佈線工作。）”

    “"Retrieval is easy. Being worth retrieving from is the product."（檢索很容易，值得被檢索才是產品。）”

    “"If you have to ask for something twice, you failed."（如果同一件事要被要求做兩次，就代表你失敗了。）”

    “"Model quality is rented, but if you build your brain, you own that brain."（模型品質是租來的，但如果你打造了自己的大腦，那個大腦才真正屬於你。）”

    “"Abundance is not a policy paper, it is shipped software."（富足不是一篇政策論文，而是已經上線的軟體。）”

33. 33

    打造可雇用的代理人(Employable Agents)：從聊天機器人到Agent的產品形態演進

    Howie Liu · Airtable / HyperAgent

    ▶ 8:19:24

    這場 talk 由 Airtable 創辦人暨 HyperAgent CEO Howie Liu 主講，從產品形態演進的角度回顧 AI 從「補全」到「聊天機器人」再到「Agent」乃至「Claw（永遠在線的自主代理）」的演變脈絡，並以 HyperAgent 上一個真實的景觀美化業者案例，具體示範多個 Agent 如何協作完成端到端的業務流程，同時提出人類角色正從「執行者」轉變為「Agent 艦隊的協調者」。

    • 講者自我定位為「產品形態思考者」，本場不談技術細節（如模型架構、演算法），而是談這些模型能力如何轉化為新的產品形態。
    • Airtable 創立近 12 年前，投資人普遍質疑「水平型平台」(horizontal platform) 策略不可能適用所有使用情境，但 Airtable 證明可行；HyperAgent 現在用同樣的哲學來打造 Agent 產品。
    • 講者提出模型/產品形態演進的光譜：
    • Completions（補全）：模型只是接續 token 直到 stop token，功能強大但應用侷限。
    • Chatbot（聊天機器人）：InstructGPT 帶來對話式調校，開啟了 ChatGPT 這種爆款形態。
    • Agent：採用 Anthropic 的定義，與「workflow」不同——Agent 會對自己遞迴（recurse），擁有開放式的工具與推理選擇，而非被寫死的線性流程。
    • Claw（講者用語，源自 OpenClaw 的普及）：不同於還只是被動回應使用者輸入、做完一項任務（可能 20 分鐘到 1 小時）就結束的 Agent，Claw 具備「心跳機制」(heartbeat mechanism)，能自己甦醒、持續朝目標推進，展現「永遠在線」(always on) 的行為。底層機制是：每次甦醒觸發多輪工具呼叫與 LLM 呼叫的迴圈，直到達到停止點，然後心跳機制再次喚醒它。
    • Agent 對 Agent 的編排 (orchestration)：模型智能已經強到可以編排複雜、長時任務，講者提到自己大量使用 Claude Code 的 workflows 功能把工作大量平行分派給多個 Agent；下一步是 Agent 與 Agent 互相協作完成更長、更進階的任務。
    • 講者對比早期的 Baby AGI、AutoGPT：那些系統雖然能跑好幾小時，令人驚豔，但最終總會「跑偏」(drift off) 到沒用的方向；現在模型智能已經足夠支撐長時間、開放式任務的連貫性(coherence)，並且能把任務拆解成不同範疇分派給不同 Agent 交接，核心在於管理每個 Agent 的任務/context window 及彼此協調的能力。
    • 實際案例（景觀美化業者，來自 HyperAgent 真實客戶使用情境）：這是一家傳統線下產業（非 AI/軟體公司），卻用一整個 Agent 艦隊管理從找客戶、報價提案到施工管理的端到端業務，證明「用 Agent 顛覆自己產業」的創意不侷限於軟體/AI 公司；講者呼應了前一場 Gary 的演講，認為每個產業都有這樣的機會。
    • Triager Agent：接收客戶詢問（附後院現況照片與需求），研判專案範圍、是否值得承接、是否為優質/真實的潛在客戶。
    • Surveyor Agent：接手後實地（透過影像/影片）分析客戶後院現況，產出重新造景的提案。HyperAgent 的每個 Agent、甚至每個對話串都運行在具備完整能力的沙盒 VM 中，可以寫程式、操作檔案，例如用 FFmpeg 從影片中擷取截圖再逐一分析，藉此產出高品質、高互動性的提案——這種等級的客製化提案，過去只有服務五百萬美元等級大案子的頂級室內設計師/景觀設計師才做得到，一般小型後院美化案子根本不可能有這種規格。
    • 人類仍是關鍵節點：Agent 產出提案後，交回給業主（人類）審核是否要發送給客戶並附上具約束力的報價。講者引用 Sarah Guo 的觀點：模型越聰明，價值反而越會沉澱在「人類仍握有政策與決策權、把關高影響力關鍵行動」這件事上，就像優秀主管審核團隊的上呈工作再決定放行。
    • 案例中的 Agent 名為「Sage」，會透過 Slack 或 email 等管道與人類業主互動，回報已完成的勘查、提案與報價，等待核准。
    • Agent 需要持續學習、具備記憶：呼應 Gary 演講中「G-Brain」建立黏性 context layer 的概念，講者認為這是通用原則——好用的 Agent不能只是靜態的 LLM 呼叫或固定 prompt/skill 組合，必須每次互動都在學習，不能等到下一次模型微調(fine-tuning)才更新，而要即時累積記憶、更新技能、吸收使用者回饋，像人類一樣持續調整進步。案例中業主可直接在 Slack 跟 Agent 說「這點下次記得考慮進去」，Agent 就會記住。
    • 開發工作流的類比演進：從「人類單執行緒寫程式」→ GitHub Copilot 的「補全式輔助編程」→ Cursor Composer 1.0 的「對話式 Agent 編程」(更高槓桿) → 現在最前沿的開發者其實是在「監督一整個 Agent 艦隊」。講者提到：晚上睡覺前沒讓自己的 Agent 們去做有用的夜間工作，會有一種「巨大損失感」，因為團隊（Agent 艦隊）沒在運作。
    • UX 需要轉向「編排控制面板」(orchestration control plane)：無論是開發工作流還是像景觀美化這種通用業務，人類需要能一眼看到所有 Agent 在做什麼、卡在哪裡、彼此如何交接工作，工作型態變成像在管理一整座「SimCity」，在宏觀層面協調不同 Agent，而不是逐一微觀介入每個專案或任務。
    • 講者總結：這不僅是「可以做的機會」，而是每個產業、每間公司要生存下去的「基本門檻」(table stakes)，並引用 Jensen（黃仁勳）的話：「不是 AI 搶走你的工作，而是懂得用 AI 的人搶走你的工作或生意。」
    • 結尾宣傳：HyperAgent（hyperagent.com/aie）提供 1000 美元的推論額度，可用於多種模型，包括 Opus 4.8、Fable 5、GLM 5.2、GPT 5.5 等。

    “「不是 AI 搶走你的工作，而是懂得用 AI 的人搶走你的工作或生意。」（引用 Jensen 的話）”

    “「這不只是可以去大展身手的機會，在我看來，這將是每個產業、每間公司生存的基本門檻。」”

    “「Agent 不應該是靜態的——它們必須在每一次互動中學習，就像人類一樣。」”

34. 34

    主持人專訪Howie Liu：HyperAgent Founding 500計畫與Startup Battlefield緣起

    Howie Liu · HyperAgent

    ▶ 8:37:14

    這是 AIE(AI Engineer World's Fair) 主持人對 HyperAgent 創辦人 Howie Liu 的訪談,聚焦於 HyperAgent 推出的「Founding 500」計畫的緣起,以及這個計畫如何與 AIE 大會的 Startup Battlefield 競賽合作促成。核心主張是:AI 正在推動一波「agent native」新創企業浪潮,其槓桿效應遠超過去軟體或網路時代,而 Founding 500 就是要押注在這波經濟中最前沿、最具代表性的公司上。

    • AIE 主辦方原本就想在大會中設置類似「battlefield」的新創競賽環節,但缺乏評選機制與資金支持,直到 HyperAgent 推出「Founding 500」計畫,雙方一拍即合、促成合作。
    • Howie Liu 描述產業正經歷多層次的「破壞式創新(disruption)」疊加:第一階段是人類做原本的工作、只是被 AI 稍微增強(augmented);第二階段是人類開始監督一整支(fleet)由 AI agent 執行、過去不可能完成的工作,他舉例一位園藝造景業者用這種方式徹底改變經營模式;第三階段則是全新的「agent native」公司正在被打造出來,這些公司從一開始就以 agent 為核心運作。
    • Founding 500 計畫的定位是押注在這波經濟中「agentic 槓桿程度最高」的公司,這些公司不只是在自己的領域中顛覆現況,更是在定義這個新時代裡企業該如何被經營的「全新玩法(playbook)」。
    • Howie 認為已經觀察到部分以這種方式運作的公司所展現出的槓桿效應「非常深遠(profound)」,程度遠超過早期軟體公司或網路公司所帶來的槓桿效益。
    • 他相信這個「agent native」子經濟體未來會出現爆炸性成長,成長幅度會高於其他任何產業類別,而且影響範圍不會侷限在科技業或軟體業,而是會橫跨所有產業。
    • 主持人在自己的倫敦主題演講中也常提到,agent 正在「吃掉」剩餘的工作類型,並讓非技術背景的團隊也能運用 AI;他舉例自己的團隊之所以特別興奮見到 Howie,是因為 AIE 大會本身就是用 Airtable 在運營,團隊很期待與 Hyper Agent 合作。
    • Founding 500 計畫從 500 位申請的創辦人中預先篩選出 20 組,這 20 組在當天的 Startup Battlefield 中互相競爭,最終有 3 組脫穎而出成為決賽入圍者。

    “「這不只是比早期軟體槓桿或網路槓桿還強,而是更加深遠(far more than even being an early software leveraged or internet leveraged company)。」”

35. 35

    Startup Battlefield決賽開場：評審陣容(Howie Liu、Theo Browne、Joshua)與賽制、獎金說明

    未知 · AI Engineer World's Fair

    ▶ 8:39:07

    這是 AI Engineer World's Fair「Startup Battlefield」決賽的開場環節，主持人介紹評審陣容（Howie、Theo、Joshua from HeyGen），並說明比賽規則、獎金分配與評選標準。核心主張是：這場比賽評的不是投資潛力，而是「這項技術的應用是否令人印象深刻、創辦人是否值得被認識」。

    • 決賽評審由三人組成：Howie、Theo，以及來自 HeyGen 的 Joshua，將負責對參賽團隊進行評分與提問。
    • 獎金由 HyperAsian 團隊贊助，總額為 10 萬美元，分配為：冠軍 5 萬美元、亞軍 3 萬美元、季軍（第二名 runner-up）2 萬美元。
    • 賽制流程：先播放由 HyperFrames 與 Hagen 製作的 hype 影片，接著進行評審與參賽者的 Q&A，之後會有三組團隊背靠背進行簡短 pitch。
    • 主持人特別強調評選精神：這不是 VC 式的投資 pitch，重點不在於商業可行性或募資潛力,而是「這項技術的使用方式為什麼有趣、為什麼值得關注」，以及「這位創辦人為什麼是值得認識的人物」。
    • 開場結尾主持人準備公布晉級/獲勝的隊伍名單，銜接後續正式的 pitch 環節。

    “「這不是一場 VC 投資 pitch，重點在於：這項技術的應用為什麼有趣，以及你為什麼是一位值得被認識的創辦人。」”

36. 36

    Startup Battlefield第一組：Kmod(Commod)——以AI代理人狀態機重塑實體大宗商品貿易

    Spiro Nanakos、Nick Nanakos · Kmod

    ▶ 8:40:38

    Kmod（Commod）由 Spiro Nanakos 與 Nick Nanakos 創立，主張全球每年價值 17 兆美元的實體大宗商品貿易（從稻米、黃金、晶片到石油）至今仍靠紙本、email 與人工握手處理,導致每年數千億美元因詐欺、資訊碎片化與跨國協調複雜度而蒸發。Kmod 打造一套專利申請中的「CFC 狀態機」，驅動一群專責 AI 代理人自動完成驗證、執行到結算的全流程，把過去需要數週的交易撮合壓縮到幾分鐘內完成。

    • 全球每年約 17 兆美元的實體大宗商品在流動，但整個產業仍仰賴紙本合約、email 往來與口頭承諾，沒人能確認交易對手是否真實、文件是否造假，結果是每年數以百億計美元的損失。
    • Kmod 直接整合進企業既有的工作工具堆疊，包括 Gmail、Slack、Stripe、Salesforce、WhatsApp 等，交易一啟動就由 agent 自動介入,不需要客戶改變既有工作流程。
    • 交易流程：agent 先在數秒內完成雙方的 KYC 身份查核與制裁名單篩選,並用「鑑識」能力即時揪出文件造假;接著自動生成一個私密的交易室（deal room）,串接航運與物流夥伴並帶入即時報價。
    • 核心是一個「agent swarm（代理人蜂群）」並行處理法遵、法律、貨幣、銀行、航運、結算等多個面向,把原本要花數週的人工作業壓縮到幾分鐘完成。
    • 所有 agent 都必須遵守同一套協定——CFC（專利申請中的狀態機）：每個 agent 只有在清除所有「否決條件（deny condition）」後才能推進到下一狀態,確保證據必須為真、達到「可結算」門檻才會往前走。
    • Kmod 本身不觸碰資金,系統只負責發出結算訊號,實際撥款仍由客戶自己的銀行執行——原本 30 天才能走完的結算流程被壓縮到幾分鐘。
    • 現場提到已有第一位客戶：一家總部位於杜拜、隸屬阿聯（UAE）的貿易公司,每年交易量達數億美元規模,已驗證產品可用性。
    • 對「未來大型模型（如 Anthropic、OpenAI）是否會直接把這類產品內建進去、取代新創」的提問,創辦人回應：大宗商品交易的資料非常特定,他們的 orchestration layer 為每個 agent 設了「gate」,只從真實資料庫抓取具備上下文的資訊；黃金、石油、穀物等品類各有只有業內專家才懂的流程與文件要求,因此他們與 Connor 等合作夥伴取得專屬產業資料,並靠團隊自身的產業經驗訓練 agent 辨別真偽——這是一個高度依賴私有、敏感產業數據的封閉領域,模型不容易靠公開網路資料就學會。
    • 商業模式高度客製化（bespoke）,因為每家客戶的需求略有不同,但據估計只需要約 100 個客戶就能達到年營收 1 億美元（100 mil ARR）等級的規模。
    • 原因在於這個產業的單筆交易金額極大：不像 Stripe 處理的是微支付,Kmod 的單筆交易可能高達 2 億美元以上；其中一位夥伴（煉油廠等級）每月交易額可達 90 億到 120 億美元,因此以「每筆交易抽成」計價,能帶來與其他 SaaS 完全不同量級的營收與估值空間。
    • 產品定位是「端到端（end to end）」服務整條供應鏈,但真正的市場切入點（wedge）是交易商（traders）與銀行；銀行多年前因詐欺猖獗而退出實體商品融資市場,而 Kmod 透過稽核軌跡（audit trail）與交易不可竄改性（immutability）,有機會重新為市場注入大量流動性,吸引銀行重新入場。
    • 針對評審提出「這是教科書級別的完美垂直 agent 新創（vertical agent business）,但如何應對模型能力持續進化的競爭態勢」的提問,創辦人回應：真正具防禦性（defensible）的東西只有「在自己的品類裡保持最有創造力」,產品本身其實都不具防禦性；他們採取的策略是「ship-stinction（出貨滅絕）模式」——持續積極出貨,靠產品優越性淘汰對手,最終則靠「distribution（通路/市場觸及能力）」取勝。
    • 被問到接下來的產品路線圖最令人興奮的方向時,創辦人直接回答：「成為銀行（Becoming the bank）」。

    “「$17 trillion in physical commodities move every year. The world runs on them, yet it still moves on paper, email, and a handshake.」（每年有 17 兆美元的實體商品在流動，世界靠它運轉，但整個流程卻仍停留在紙本、email 和一句口頭承諾上。）”

    “「The only thing that's actually defensible is being the most creative in your category... Truly nothing's defensible other than being the most creative.」（真正具備防禦性的，只有在你的品類裡保持最有創造力——除此之外沒有任何東西真的防得住。）”

    “「We like the ship-stinction model where we ship and then 10 companies go extinct the next day.」（我們喜歡「出貨即滅絕」模式：我們一出貨，隔天就有十家公司滅絕。）”

37. 37

    Startup Battlefield第二組：Comment(Comment.io)——為人類與代理人打造的多人協作Markdown編輯器

    Max Winnebom · Comment.io

    ▶ 8:48:49

    Comment.io 打造了一款「多人協作 Markdown 編輯器」，主張現有的文件協作工具（如 Google Docs）都是為「人類」設計的，無法讓 AI 代理人（agents）與人類即時共享文件上下文；Comment 要成為專為「人類與代理人共同工作」打造的文件平台。

    • 開場用一個情境破題：週五下班前公司突然大當機，大家衝進會議室各自打開自己的 Claude 問「發生什麼事」，等 Claude 給出想法後，還要口頭把想法轉述給其他人，讓對方再輸入自己的 Claude 裡——講者質疑「這真的是我們該有的工作方式嗎？」
    • 核心論點：現在多數生產力／協作軟體（如 Microsoft Word、Google Docs）是為「人」設計的，不能直接把 coding agent 或其他代理人丟進去跟其他 agent 或人協作。
    • 舉例 Google Docs 的限制：雖然有 MCP，agent 可以把文件送進去、也能讀取文件，但無法做到「即時協作」（real-time collaboration），這對很多真實工作場景是關鍵缺口。
    • Comment 的定位：一個「多人 Markdown 編輯器」，同時支援人類與代理人在同一份文件中即時互相通知、召喚彼此加入（可以直接把任何人或任何 agent「叫進來」）。
    • 產品特色三個關鍵字：開放（open）、可插拔（pluggable，對企業與開發者很重要）、以及包裹在一個「非常熟悉」的使用者體驗介面之上（即一般常見的文件編輯器介面）。
    • 團隊背景：講者職涯早期在把協作功能帶進 Microsoft Word；他與共同創辦人曾在 Textio 共事——Textio 是「第一個 AI 原生寫作軟體」，早在 ChatGPT 出現的六年前，他們就已經在為財星 500 大企業做全公司規模的 AI 寫作軟體導入。強調團隊在這個領域已經深耕很久。
    • 市場論述：隨著越來越多人使用 agent，會有越來越多人需要「讓 agent 在一個為 agent 打造、但同時為人類協作設計」的產品中共享上下文，即使是在最高風險（high stakes）的情境下也一樣。
    • 評審（可能是主持人/投資人角色）評論：這個商業模式的形狀很有意思，跟前一組 Khmad（Kamod）走「垂直深耕單一領域、榨取深度價值」的路線相反，Comment 走的是「廣度優先」路線——雖然單次調用/使用的邊際價值可能較低，但如果 agent 經濟規模夠大（token 花費龐大），只要能佔到其中 1-2% 的 token 流量，就可能成為一個便宜、快速、觸及面廣、依然能達到高規模的產品。
    • 評審提問：從產品設計角度，做出「讓 agent 用起來比人類設計的等價產品更好」的過程中，最意外的學習是什麼？為什麼不直接用 Google Docs 或 GitHub（不只用來放 code，也用來放 markdown）當作 agent 協作的 repo？
    • 回答重申：目前所有寫作軟體對 agent 來說都很糟糕；Google Docs 格式很差，雖有 MCP 可讀寫文件，但做不到即時協作，而這對許多真實工作流程是必要的。
    • 用戶洞察：他們訪談的既有文件重度使用者（原本就仰賴文件做日常工作的人），現在也開始想把自己的 agent 帶進文件協作流程，顯示需求不再只來自開發者，而是擴及一般知識工作者。
    • 結尾補充一個有趣的市場驗證訊號：講者提到在這場研討會上跟很多人聊天時，發現「非常多人都自己動手做過一套視覺化 Markdown 編輯器」給別人看，但後來都放棄了、退而求其次改成直接 render 成 HTML 文件——顯示這是一個「很難的問題」，需要專注投入才能做好，而這正是 Comment 團隊在做的事。

    “「軟體今天對 agent 來說用起來都很糟糕（All writing software today is horrible for agents to use）。」”

    “「這是一個很難的問題，你需要專注投入才能把它做好（It's a hard problem. And you need dedicated focus on making it great）。」”

38. 38

    Startup Battlefield第三組：Foundry(Built by Foundry)——代理人團隊為內容創作者打造經常性收入事業

    Weston Belgettis · Built by Foundry

    ▶ 8:55:44

    這是 Startup Battlefield 的第三組簡報,由 Built by Foundry 創辦人 Weston Belgettis 主講。他們主張軟體開發成本趨近於零,真正稀缺的是「信任與品味」,而內容創作者正是最擁有這兩者的人;Foundry 用一支代理人團隊分析創作者的內容與觀眾留言,找出觀眾願意付費解決的痛點,並直接打造成一門經常性收入的訂閱事業,讓創作者不必自己創業就能變成「創辦人」。簡報後段有現場評審 Theo(知名 YouTuber)直接提出質疑,雙方就「創作者該自建產品,還是把洞察賣給企業」展開辯論。

    • Foundry 的核心產品:輸入任一創作者的帳號,代理人團隊會觀看其影片、閱讀留言,找出觀眾真正願意付費解決的「止痛藥」式痛點,而不是單純把內容加上付費牆(不是「另一個 Patreon」)。
    • 已有超過 50 萬人使用由這套代理人打造出來的產品,證明模式已在多個不同規模、不同領域的創作者身上跑通。
    • Weston 提出「贏的公式」:把自己的獨特專業轉化成產品,並利用自帶的既有流量/信任解決冷啟動問題,並舉了 Theo 做 T3Chat、Gary 做 G-Stack 與 G-Brain 為例(雖然 Theo 當場吐槽「這方法根本行不通」)。
    • Weston 曾在 TikTok 工作兩年,接觸過數百位創作者,發現他們大多被困在接業配、發聯盟連結、賣 20 美元 PDF 這類低效變現方式,其實只差臨門一腳就能自建事業,而 Foundry 的代理人就是來補上這一腳。
    • 商業模式:Foundry 派出代理人團隊,替創作者打造「經常性收入事業」,讓創作者只需專注持續產出內容,收入成長交給代理人負責。
    • 具體案例:一位做「自給自足農場(homesteading)」內容、擁有 200 萬粉絲的創作者 Brandon,常常記不住冷凍乾燥機(freeze dryer)的最佳設定——這在外人看來很荒謬的小問題,對他的觀眾卻是真實痛點,Foundry 因此幫他做出對應產品,觀眾現在按月或按年付費訂閱使用。
    • Weston 強調:公司歷史上「零」個合作創作者因為業務失敗而離開,因為透過代理人找到的痛點,產品都能穩定獲利。
    • Theo 提出反方觀點:創作者向同一批觀眾反覆推薦同一個產品,很快會遇到「飽和點」(saturation point)——例如他幫 Vercel 業配久了,粉絲要嘛已是用戶不想再被推,要嘛不是用戶也不想再聽;解法是擴大「品項多樣性」給觀眾,而不是深挖單一產品。
    • Theo 分享親身經驗:他從只有 4 個贊助商增加到 80 個贊助商,是對自己職涯、事業、收入影響最正面的一步——即使 80% 的贊助對某些粉絲不相關,剩下 20% 帶來的轉換也是原本拿不到的,多樣性本身就是價值來源,他合作過的創作者最終也都得出類似結論。
    • Theo 認同 Foundry 抓到的三個真實優勢——創作者比多數創辦人更有品味、比多數公司有更好的流量、比多數企業更懂自己的觀眾——但質疑 Foundry 的方案沒解決「多樣性」這個關鍵問題。
    • Theo 建議更好的商業模式是反過來:讓「企業」用這套工具去找出與自己目標客群高度重疊的創作者,再由企業出資,請創作者把自家產品如何解決痛點展示給觀眾看,而不是創作者自己下海做產品。
    • Theo 自嘲是「創業次數第二多的 YouTuber」,並直言「自己下海做公司」這條路對他而言行不通,只會把自己和觀眾都燒盡(burn out);更好的做法是教企業「你的觀眾要什麼」,讓企業帶著錢來找你曝光。
    • Weston 回應:科技類創作者(如 Theo)的利基特別困難,因為市場選項太多太競爭;但除了科技和喜劇類目之外,絕大多數垂直領域(如上述的自給自足農場例子),代理人都能找到觀眾真心願意付費的痛點,並半開玩笑邀請 Theo 若想轉行做園藝/homesteading 內容可以合作。

    “「軟體開發的成本正趨近於零。剩下的是信任與品味,而沒有人比創作者擁有更多這兩樣東西。」——Weston Belgettis”

    “「你能做的最好的事,就是去教會這些企業你的觀眾真正想要什麼,然後讓他們帶著錢來找你,把產品展示給那些觀眾看。」——Theo”

    “「很不幸,Theo,你選錯了利基,抱歉了。」——Weston Belgettis(對 Theo 質疑的半開玩笑回應)”

39. 39

    評審團閉門討論：播放AI Engineer World's Fair大會精華回顧影片

    未知

    ▶ 9:01:57

    這段內容並非正式演講，而是頒獎/評審環節之間的過場橋接：評審團暫時退場進行閉門討論，主辦方播放一支回顧 AI Engineer World's Fair 大會精華的影片供在場觀眾觀看，等評審討論結束後再邀請所有人回到台上。

    • 由於評審需要離場進行閉門討論（可能是評選得獎者或裁決比賽結果），主辦方安排播放事先準備好的大會精華回顧影片，作為過場填充內容，避免現場冷場。
    • 影片內容為「上一屆 AI Engineer 活動」的回顧，並提及會展示一些新的 AI 技術供與會者嘗試。
    • 逐字稿本身資訊量極少，未包含任何技術性演講內容、案例或數據，僅為主持人串場口白。
40. 40

    Startup Battlefield頒獎揭曉：冠軍Comment.io、亞軍Foundry、季軍Kmod

    未知 · AI Engineer World's Fair

    ▶ 9:04:26

    本場並非正式演講，而是 AI Engineer World's Fair「Startup Battlefield」新創競賽的頒獎典禮片段，主持人依序公布季軍、亞軍與冠軍名次並邀請團隊上台領獎、拍照。

    • 頒獎結果依序公布：季軍（第二亞軍）為 Kmod，由 Theo 代表領獎。
    • 亞軍為 Foundry，講者 Max 的簡報（pitch）獲主持人稱讚。
    • 冠軍（大獎）由 Comment.io 奪得，頒獎前播放了一段介紹影片，主持人稱其「實至名歸」。
    • 主持人邀請所有得獎團隊上台拍團體照，後改為僅邀請創辦人（founders）／冠軍團隊拍照。
    • Comment.io 團隊致詞感謝 AI Engineer World's Fair（AIU）主辦方全程給予的正面回饋，並感謝 HyperAgent 邀請他們參賽、感謝 Haitian（及相關夥伴）協助製作影片。
    • Comment.io 團隊提到他們使用 HyperAgent 進行產品建構（build with HyperAgent），並宣傳自家產品 Comment.io 為免費使用，歡迎大家去試用。

    “「Check us out, it's free. Comment.io.」（Comment.io 團隊在領獎致詞最後的宣傳語）”

41. 41

    AI Engineer World's Fair 2026閉幕致辭：感謝贊助商與幕後工作人員，預告最後彩蛋

    Ralph Chabrit · Replit

    ▶ 9:06:34

    這是 AI Engineer World's Fair 2026 的閉幕致辭，由 Replit 開發者關係工程師 Ralph Chabrit 主持,內容以感謝為主軸——感謝參與者、贊助商、幕後工作人員，並簡短回顧本屆大會規模，同時預告明年紐約場與現場彩蛋。

    • 首先恭喜 Startup Battlefield 決賽入圍團隊，這些團隊共同贏得價值 10 萬美元的獎勵，用於加速他們的專案發展；同時感謝三位評審 Josh、Howie 和 Theo 的參與。
    • 講者回顧本屆大會規模：AI Engineer World's Fair 2026 為期四天、共 7,000 名參與者，設有主題演講（keynote sessions）、大量工作坊、對談與 demo，並劃分為 40 條議程軌（tracks），是歷屆以來最具野心的一屆。
    • 講者強調主辦方最看重的不是內容本身，而是社群齊聚一堂——建立新連結、新友誼、交流想法並一起打造專案，這才是活動真正的價值所在。
    • 特別感謝各贊助層級：Presenting Sponsor 為 Microsoft，另感謝 Lab 與 Platinum 級贊助商、Gold 級贊助商，以及 Silver 與 Bronze 級贊助商；講者強調沒有這些贊助商的支持，整場活動不可能實現。
    • 講者也特別感謝在幕後、參與者平常看不到的工作人員，包括工作團隊成員（crew members）與志工（volunteers），肯定他們是活動得以順利舉行的關鍵。
    • 預告未來活動：主辦方希望在 10 月於紐約（New York）與許多與會者再相見，並且明年會再次於原地舉辦下一屆 AI Engineer World's Fair。
    • 結尾前留下懸念：在慶祝美國國慶（America's birthday，暗指 7 月 4 日）之前，還有「最後一件事」要向現場觀眾展示，為彩蛋環節做鋪陳。

    “「What we love to see more than anything else is the community coming together, creating new connections, new friendships, exchanging ideas and building together.」（我們最樂見的，莫過於社群齊聚一堂——建立新連結、新友誼、交流想法，並一起打造專案。）”