AI Engineer World's Fair 2026 Day 1：Software Factories & Keynotes

• 1

  早上 6 場主題演講：swyx 開場、微軟 Pablo Castro 談知識、OpenAI Codex、Peter Steinberger 談更好的 Loop、Z.ai 的 GLM 5.2、MiniMax M3 爐邊對談。

• 2

  中段是密集的 breakout／閃電演講與爐邊對談：Software Factory、Browser Agent、Greptile 的 PR 數據、TurboPuffer 的創業故事、Notion 的 Token 經濟學、BAML「以毒攻毒」等。

• 3

  下午 3 場壓軸主題演講：HumanLayer 談「只有 Harness 還不夠」、Leibniz Labs 用型別系統做「可證明安全的 AI」、Cursor 如何訓練自己的模型。

• 開放權重模型成為主線：GLM 5.2、MiniMax M3 都在談開源策略、長脈絡與多模態。
• 評測（Evals）從「跑分」轉向「生產級可靠度」：多場強調要量測系統行為，而非只看 benchmark。
• 安全與決定性：從 Snyk 的 Secure by Default、決定性／可重播除錯，到用型別系統與 proof-carrying code 讓 Agent「可證明安全」。

“一天下來的共識：模型已經夠強，真正的工程題目變成「怎麼設計 Loop、Harness 與組織」，讓 Agent 可靠地把工作做完——而人類的價值，從「怎麼做」移到「決定要做什麼」。”

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

1. 1

   開幕主題演講：Loop Craft 與 AI 工程師的核心技藝

   swyx (Shawn Wang) · AI Engineer

   ▶ 11:00

   swyx 以「Loop Craft」為核心主張，主張 AI 工程師最重要的技藝是理解自己身處哪一層「迴圈」，並能在適當時機向上抽象化（提升生產力）或向下深入（排除問題）。他以人類生命週期與 AI 工程的平行結構，說明所有自動化、代理人、軟體工廠本質上都是層層疊加的迴圈。

   • 迴圈進化史：從最早的 token → chat → 使用工具 → 設定目標 → 自動化 → cron job 與迴圈 → 軟體工廠，AI 工程的每一個階段本質上都是在上一層迴圈之上再疊加一層。
   • AI 工程師的核心技藝：能夠識別自己當前在哪一層迴圈工作，當需要提升效率時「往上一層」，當遇到可靠性問題時「往下一層」深入排查。這個判斷力就是 Loop Craft 的精髓。
   • 人類迴圈的類比：heartbeat（生命跡象）→ 學說話 → 使用工具 → 工作（eat/sleep/code/repeat）→ 小團隊合作 → 家庭與國家 → 人類文明整體的集體智慧，與 AI 迴圈完全平行。
   • 泛化元年：swyx 認為 2025 年是 AI 代理人從編碼領域擴散至其他垂直領域的關鍵年，因此本屆 World's Fair 新增了 AI in Healthcare、AI in Finance、AI in GTM、deployed engineering 等垂直賽道。
   • 規模數據：AI Engineer World's Fair 從 2023 年首屆線性成長，2024 年約 2,000 人，2025 年目標 6,000 人，實際突破 7,000 人；Gini 係數（購票集中度）仍在上升，呼籲社群更早購票。
   • 最高層迴圈：swyx 認為最高階的迴圈是「人們聚在一起，共同決定下一個迴圈是什麼」——也就是本次 World's Fair 的存在意義，即「製造迴圈的迴圈」。今年全球峰會涵蓋紐約、巴黎、新加坡、墨爾本、邁阿密。
   • 軟體工廠的成熟條件（由第二位主持人補充）：過去一年，模型視覺能力提升（可視覺驗證輸出）、工具生態更豐富（可存取真實生產數據）、context window 與記憶體改善、推理能力提升、AI 安全最佳實踐成形，五項條件匯聚，使軟體工廠從願景變成實際可落地的現實。
   • Ralph Loop 的演進：一年前 Jeffrey Huntley 發布 Ralph Loop，當時僅推薦用於 greenfield 專案且預期完成度約 90%；經過一年發展，限制已大幅縮減。

   “「The highest loop of all is where humans come together to figure out what the next loop is — the loop that makes loops.」（最高層的迴圈，是人們聚在一起決定下一個迴圈是什麼——製造迴圈的迴圈。）”

   “「I'm not gonna apologize for good content — it's up to you to decide and route yourself as to which level you're currently working at and which level you're currently blocked on.」（好內容我不道歉，你得自己判斷目前在哪一層、卡在哪一層。）”

2. 2

   On AI and Knowledge：把知識接進 Agent（Foundry IQ / WebIQ）

   Pablo Castro · Microsoft

   ▶ 21:30

   Pablo Castro（Microsoft Distinguished Engineer）從資訊檢索研究者的視角，將 AI Agent 所需的知識分為「固有知識」、「外部知識」與「學習所得知識」三類，並介紹 Microsoft 在 Foundry IQ / WebIQ 平台上如何讓 Agent 能有效接入、檢索、並持續優化這三類知識。核心主張是：單靠模型的參數記憶已不足以支撐企業級 Agent，必須結合結構化的知識接入系統與自動化學習回圈，才能讓 Agent 真正嵌入組織運作。

   • 固有知識（Intrinsic Knowledge）驅動了這波 AI 指數成長：模型訓練資料所形成的參數記憶，正是 GitHub Copilot、ChatGPT 等早期爆炸性體驗的根基，也是讓程式碼生成、寫作摘要等任務進入指數曲線的起點。
   • 程式碼輔助的指數時間軸：IntelliSense（1996）→ ML 智慧排序補全（2018，相距 22 年）→ GitHub Copilot 發布（2021，僅 3 年後）→ Cursor / Copilot X 推出 → Claude Opus 4.5 / GPT 等模型持續精進 → OpenClaw 問世（完全無人手寫一行程式碼）。這條曲線說明指數加速已大幅縮短技術躍遷的時間間隔。
   • 固有知識的天花板：模型的參數記憶對於需要「接入組織內部脈絡」的 Agent 而言明顯不足，因此業界發展出 RAG 模式，並持續演進成今日的 context engineering。
   • Microsoft IQ 體系——單一入口接入企業環境知識：
   • Work IQ：接入 SharePoint 文件、Email、行事曆、Teams 聊天及人際關係圖譜。
   • Fabric IQ：接入資料倉儲、資料湖、Power BI 報表等分析資產。
   • Foundry IQ：供開發者推入自有資料，作為 Agent 的專屬知識庫。
   • Web IQ：讓 Agent 能以網路公開資訊補全世界觀。
   • 檢索系統的演進：從向量搜尋到多方法融合：業界曾短暫以為「把向量餘弦相似度做到極致就夠了」，但 Azure AI Search 的評估數據反覆顯示，將多種檢索方法組合（詞彙檢索、向量檢索、語意重排等）的效果，遠優於任一單一方法，在真實客戶場景中差距尤為顯著。
   • Foundry IQ 的分層設計——易用與控制並存：
   • 頂層（簡易模式）：只要指向 PDF 或圖片來源，平台自動處理 chunking、向量化、排序、Agentic retrieval。
   • 底層（專家模式）：可自訂向量量化方式、索引演算法、詞彙檢索參數等，且兩種模式在同一套技術棧內自由切換。
   • Agentic Retrieval——反思式多輪檢索：對於複雜查詢，系統不直接回傳第一批結果，而是先反思「目前的檢索是否已滿足輸入中提出的資訊需求」，再決定是否繼續搜尋。評估顯示，Agentic retrieval 在 evidence recall（證據召回率）和 answer completeness（答案完整性）等指標上，持續優於單一簡單檢索方法。
   • 每個知識庫都是一個 MCP Server：Foundry IQ 的知識庫可直接作為 MCP server 被任何既有框架連接，無需額外撰寫膠水程式碼。
   • Token 效率：Foundry IQ 特別針對資訊密度進行優化，目標是以最少的 token 數量傳回最高價值的檢索結果。
   • 學習所得知識（Learned Knowledge）——Agent Optimizer：Foundry 提供的 Agent Optimizer 實現了「評估基線 → 生成候選配置 → 評估新候選 → 部署最佳版本」的自動化學習回圈。
   • 使用者只需將 Agent 的指令、工具定義、技能等配置外部化，即可套用優化流程。
   • 工具指令：`eval generate`（自動從 trace 與指令產生評估資料集）→ `optimize`（執行約 45 分鐘，以類 DSPy 的 hill-climbing 方式爬升指標）→ `optimize apply`（熱替換配置）。
   • 優化後的指令並非人工撰寫，而是從爬坡過程中「湧現」出來，反映實際使用者 trace 中的模式。
   • Satya Nadella 的洞見：人與 Agent 的協作可以形成複利效應——組織每天的工作被 Agent 觀察並持續改進，形成能萃取企業獨特競爭力的學習回圈。

   “「我們曾有一段時間以為，只要把向量的餘弦相似度做到極致就萬事俱備了。結果證明，事情從來都沒那麼簡單。」”

3. 3

   OpenAI Codex 主題演講：把 Harness 開放成人人可擴充的堆疊

   Roman & Alexander · OpenAI

   ▶ 39:00

   OpenAI 的 Roman 與 Alexander 在這場主題演講中，宣示 AI 工程師正在「吃掉世界」，並駁斥「工程師將消失」的論點。他們展示 Codex 的完整技術堆疊——從模型 API、開源 Harness、App Server 到應用層插件——每一層都對外開放，讓任何人都能在相同基礎上擴充，而非 OpenAI 獨享。

   • AI 工程師是推進前沿的核心人群，而非即將消失的職業；工程從來不是「寫程式」，而是「解決問題」，現在只是回歸工程的本質。
   • OpenAI 的模型迭代週期已從每 15 個月縮短至約每 6 週一次；發表當週已預覽 GPT 5.6 系列。
   • 兩年前的 Dev Day，模型無法自行執行或驗證程式碼，Roman 必須交叉祈禱 demo 能跑；到 2025 年，模型已能自測、控制攝影機與燈光系統，進步幅度驚人。
   • Codex 現在能執行任何使用者在自己電腦上可完成的任務，不只協助「寫程式中」，還能參與「寫程式前（需求理解）」與「寫程式後（review、deploy）」，讓 agent 能承接更多完整工作。
   • 產品哲學不是「自動化工程師」，而是「最大化賦能工程師」：兩種互補模式——隨時可問的 chat（被低估的模式）＋需要深度介入時的協作 UI，類似與團隊成員的日常工作節奏。
   • Codex 堆疊設計為任何人都能擴充的分層架構，由下而上：
   • 模型層：透過 Responses API 對外，OpenAI 自己也用同一套 API 開發 Codex app，不存在「內部專用版」。新能力（如長任務的 compaction）一律先做進 API，開發者同步受益。
   • Harness 層：完全開源，可 fork、可自訂；預設使用 OpenAI 模型但非硬編碼，可替換為開源模型；post-training 也使用此開源 harness，讓模型學習呼叫工具。Open Code 團隊即藉此研究 Codex 如何實作 ChatGPT 登入。
   • agents.md：刻意取一個其他 agent 也能共用的格式名稱，而非 Codex 專屬格式。
   • App Server 層：開源，用於統一管理 harness 並整合訂閱登入；Toma（X 帳號 Dimalian）在官方 Codex app 發布前就用 App Server 獨立開發了 Codex Monitor native app，後來加入 OpenAI 負責開發 Codex for iOS。
   • 應用層：可擴充原語包括 in-app browser 與插件系統；browser use、computer use 都是用相同插件機制實作的；也有針對資料科學、設計等角色的 role-specific 插件，全部開源。
   • 生態系已涵蓋 OpenCode、Pi、Droid、OpenCLAR、Xcode、JetBrains 等，均可讓使用者使用現有 Codex 訂閱。
   • 核心原則：「我們不是為 OpenAI 建一套系統、再為開發者建一套簡化版。每一層，我們用的就是給你們的那個東西。」
   • Value maxing（價值最大化） vs token maxing：與工程領導的對話集中在如何從 agent 取得最大價值，而不是追求最多 token 消耗。
   • 成本效率：GPT 5.6 Tera 達到 GPT 5.5 等級智慧、成本降半；Luna 在相同 eval 下擊敗多個知名模型，僅 $1/百萬 input tokens、$6/百萬 output tokens。
   • 速度突破：GPT 5.6 Sol 在 Cerebras 上達到 750 tokens/秒，一份有份量的 PR 約 10 秒生成；這個速度讓 agent 平行嘗試 5-6 種方案再挑最優解成為可行，而不是單純等待一個答案。
   • 遠端執行：Codex Cloud 即將大幅升級；未來不應存在「本地任務 vs 雲端任務」的尷尬區分，agent 應自行判斷最適合的執行環境。

   “「軟體吃掉了世界，AI 吃掉了軟體，而現在我們要說的是：AI 工程師正在吃掉世界。」”

   “「工程從來不是關於寫程式；工程從來都是關於解決問題——為自己，也為他人。這不是工程的終結，這是工程回歸本質。」”

   “「我們不是為 OpenAI 建一套系統、再為開發者建一套簡化版。每一層，我們用的就是給你們的那個東西。」”

4. 4

   別再開 20 個終端機，要的是更好的 Loop

   Peter Steinberger · OpenAI

   ▶ 58:10

   Peter Steinberger（OpenAI）分享了他從「同時開 10 個終端機、自己當排程器」到「管理一個長期運行的 AI 管理者（manager）代為協調多個 worker agent」的轉變歷程。核心主張是：真正的生產力不是同時監看更多 agent，而是設計更好的「Loop」——讓人退出執行內層循環，只負責設定方向與關鍵決策。

   • 幾個月前用 10 個終端機輪流「偷」閒置的 agent 來排工作，當時自以為是在「orchestrating」，其實只是在 polling——自己才是排程器、路由器和記憶體。
   • 從一對一配對開發，演變成「管理 10 個直屬下屬」，現在則主要對話一個長期執行的 manager，由它再派工給 worker；遇到棘手問題才親自下場與 worker 配對。
   • 讓這個模式成立的三個關鍵改變：①Server-side compaction（讓長期任務不再因 context 截斷而失效）、②Coordination（單一執行緒可以建立並引導多個 project）、③Automation/trigger（事件可以喚醒同一個 manager）——對應「持久 context、委派、觸發器」，這就是 Loop。
   • 瓶頸會持續移動：過去受限於 tokens（加入 OpenAI 解決，但策略不可擴展）→ 受限於 compute（讓 agent 在獨立測試機上跑 test 解決）→ 現在受限於注意力（attention），而注意力無法靠加資源解決，所以「決定把注意力花在哪裡」是當今最重要的技能。
   • 舊模型時代需要盯著 agent 看並隨時按 Escape 導正方向；新一代模型理解意圖的能力已強到「看著 agent 飛速產生程式碼」是一種時間浪費。
   • 實際工作流範例：有人在開源專案開 issue → manager 醒來、對照專案目標決定是否接單 → 建立 worker → worker 調查、實作、跑測試 → 另一個 agent 做 code review → manager 回傳 PR、原始 issue、diff、影片甚至可 VNC 的 running build 給 Peter → Peter 審閱一次、留評論或 approve → loop 繼續、checks 通過後自動 merge。人只在外層循環設方向並做決定。
   • Paul Salt 已在跑類似版本：他的「chief of staff」agent 每 10 分鐘喚醒一次，協調 GitHub 工作，並在側邊欄開 thread 讓他可以隨時跳入需要額外引導的地方。
   • 長期運行的 manager 綁在筆電上感覺「不對」；Codex 已可在主機間移動工作，OpenClaw 有 gateway 和 nodes，但都不是最終形態。理想狀態是：agent 應該能連到任何一台機器，自己判斷哪些工作可在雲端做、哪些需要本機——manager 不該是被困在 app 裡的 session，而是可以透過 Slack、文字或語音隨時呼叫的 agent。
   • 模型進步的速度已超過圍繞它的 harness 與組織設計；設計這些框架本身是下一個工程問題，也是這個社群接下來的任務。

   “"I thought I was orchestrating. Really, I was polling. I was the scheduler, the router, and the memory."”

   “"Unlike tokens or compute, I can't simply add more attention. So the most important skill today is deciding where to spend it."”

   “"The future is not 20 terminals. It's better loops."”

5. 5

   GLM 5.2 與開放權重模型的策略

   Zhixuan · Z.ai（智譜 Zhipu）

   ▶ 1:07:10

   智譜（Zhipu）的 Zhixuan 介紹了最新開放權重模型 GLM 5.2 的能力定位，以及為何選擇開放權重策略。核心主張是：GLM 5.2 不只是 coding 模型，而是接近前沿閉源模型的全能型開放權重模型，且開放權重本身是一種有意識的生態策略而非妥協。

   • GLM 是「General Language Model」的縮寫，源自 2021 年智譜發表的 autoregressive blank fill 論文，與 OpenAI、Anthropic、DeepMind 幾乎同期做大語言模型探索；現在架構已不同，但品牌名沿用至今。
   • GLM 5.2 的能力定位在 Claude Opus 4.7 與 4.8 之間，使用 Deep-SWE Terminal Bench 2.1（OpenAI 團隊也在同場會議提到）等長期任務 benchmark 驗證，比 1.1 版本有顯著提升。
   • GLM 5.2 新增「high」思考預算等級（thinking budget level）；即便在不開啟 thinking 的情況下，5.2 的非思考模型也優於 5.1 的思考模型，這被認為是開放權重模型的重大突破。
   • GLM 5.2 不只是 coding 模型：在 GDPVal、數學、角色扮演、日常對話等維度均有訓練，在 Artificial Analysis Intelligence Index 上領先其他開放權重模型，接近前沿閉源模型。
   • 開放權重的三大理由：① 安全與信任——企業與政府（尤其西方客戶）可在 Hugging Face 下載後本地部署；② 多樣性微調——如法律 AI 公司 Harvey 正在微調 GLM 4.1，多家公司考慮以 GLM 為底座差異化競爭；③ 共塑未來——開放訓練 recipe 讓社群能看見模型架構，與客戶共同定義下一步發展方向。
   • 技術部落格公開了訓練 pipeline 與 recipe，說明模型背後的技術細節，不只是「資料好」，有完整的訓練方法論可查閱。
   • 智譜同步發布自家 coding harness「Z Code」，專為 GLM 5.2 打造，同時支援所有前沿模型（可帶入自己的 API key），操作模式類似 Codex，支援 GOAL 等 compact 技術，展位有現場 demo。

   “「Even without thinking, the non-thinking model is better than the 5.1 thinking model — I think it's a huge improvement for the open weight model.」（不開 thinking，5.2 仍勝過 5.1 的 thinking 模型，這對開放權重來說是巨大的飛躍。）”

   “「GLM 5.2 couldn't succeed without you — all the open source community players, super developers, they are the true hero.」（GLM 5.2 的成功離不開開源社群，你們才是真正的英雄。）”

6. 6

   MiniMax M3 爐邊對談：稀疏注意力、長脈絡與多模態

   Thom Wolf × MiniMax · Hugging Face / MiniMax

   ▶ 1:21:10

   這是一場 Hugging Face 的 Thom Wolf 與 MiniMax 研究員 Olive 的爐邊對談，介紹剛於 2025 年 6 月發布的開源模型 MiniMax M3。核心主張是：長脈絡、原生多模態、稀疏注意力架構三者並非互相妥協，而是可以從預訓練第一步就同時追求，並且做到高效能低成本。

   • M3 規模為 4000 億總參數、約 200 億激活參數（稀疏 MoE），在 Artificial Analysis 排行榜曾達開源第一，是當時唯一進入前五且同時支援多模態的開源模型。
   • M3 具備三大能力柱：強力 coding／agentic 能力、百萬 token 長脈絡、原生圖像與影片理解，三者在同一個模型內整合。
   • 長脈絡可追溯至 M1／M01：當時已實現 1000 萬 token 上下文，用於整本書摘要等靜態任務；M3 將其帶回是因為 agent 多輪工具呼叫、環境回傳內容龐大，短脈絡根本不夠用。
   • MiniMax Sparse Attention（MSA）是支撐百萬 token 的關鍵架構：分為「index branch」（在高層次選出哪些位置重要）與「sparse attention branch」（只對被選中的 block 做計算），設計刻意追求簡潔可擴展，能同時 scale 序列長度與模型大小，且該架構由一位實習生主導設計。
   • 業界曾在 Flash Attention 出現後放棄了大量線性注意力研究；M3 的做法代表重回第一性原理：從「注意力本質是什麼」重新出發，而非只靠更高效的 kernel。
   • 多模態採用「原生訓練（native multimodality）」策略：從預訓練第一步就同時餵入文字、圖像、影片，而非文字訓完再掛 adapter。理由是後掛 adapter 會損害文字性能，且 vision 收斂不佳；中途加入（continued pre-training）則對架構、資料混比、學習率極為敏感，無法穩定 scale 到大模型。
   • 解決訓練崩潰（collapse）的關鍵在 ViT 設計改進、使用「interleaved data」（保留原始資料中的圖像與影片而非 mask 掉）、強力的資料清洗與 reward modeling。
   • MiniMax 的研究文化：基礎設施開放給每個人跑實驗，任何人都可以提出改進專案，吸引感興趣的人加入，迭代週期從數週到數月不等，做出來的結果直接進入最終模型訓練並公開發布。
   • 產品側早已有龐大用戶基底：覆蓋逾 3 億人、200 餘國、100 萬家以上企業；但公司定位是「模型優先」，app 是為了讓非 API 用戶也能體驗模型能力。
   • 開源策略明確：持續開源是計劃，原因是社群回饋與 PR 對後續版本非常有價值。
   • 多模態 × agent 尚未被充分探索，但潛力極大：可讓 agent 讀取非結構化 PPT、理解長影片後再呼叫工具執行任務，解鎖大量複合應用場景。
   • 下一步：M3.1 已在開發中；未來模型肯定會超越兆參數；最令 Olive 興奮的方向是多 agent 系統，因為 routing 與多 agent 協作能顯現並放大現有模型的能力邊界。

   “「我們知道長脈絡、agentic 能力、多模態理解這三件事對未來 AI 應用至關重要，所以我們把它們放在一起。」（Olive，說明 M3 設計出發點）”

   “「為什麼不從第一步就訓練？那是最自然的做法。」（Olive，解釋原生多模態訓練策略的核心邏輯）”

7. 7

   資安軌介紹：讓 AI 預設安全（Secure by Default）

   Randall Deggs · Snyk

   ▶ 1:43:10

   Randall Deggs（Snyk）在大會主題演講後，以簡短時間介紹當天的「資安軌」專場。他認為 AI 時代最核心的挑戰是讓開發者能「無懼使用 AI、並預設安全（Secure by Default）」，並點出三大現實障礙。

   • AI 生成的程式碼本來就會有安全漏洞，但這不是新問題——人類寫程式也一樣會有，因此把安全性納入開發生命週期（DevSecOps）是現代工程的基本功，不需要過度恐慌。
   • 更困難的挑戰是將自主 AI Agent 部署到生產環境：如何確保 Agent 不會「脫軌」、做出不該做的行為、傷害業務或使用者，這才是目前最難解的問題。
   • 第三個障礙是地緣政治與存取限制——Fable 被下架、GPT 新模型無法取用等事件，都直接影響開發者能用哪些工具，本質上也是「安全與管控」議題的延伸。
   • 他宣布在主題演講結束後，於 World's Fair 二樓 Room 2005 舉辦全天「資安軌」，邀請來自 NVIDIA、Anthropic、Keycard、Snyk 等頂尖公司的講者，針對上述問題提供解方。

   “「我們在這個領域仍需解決的最大問題，是能夠無懼地使用 AI，並讓它預設就是安全的（Secure by Default）。」”

8. 8

   把 Codex 當日常主力：脈絡、Pinned Thread 與行動

   · OpenAI

   ▶ 1:57:30

   這場 talk 由 OpenAI 開發者體驗團隊成員主講，示範如何將 Codex 從單純的編程工具升級為個人的「AI 參謀系統」。核心主張是：透過 Pinned Thread（釘選對話）、AppShot、插件與執行緒間通訊，Codex 可以像一個全天候運作的虛擬團隊，讓你從「做事的人」變成「管理事情的人」。

   • Compaction（壓縮記憶）已成熟可用：你可以放心地把一條很長的對話釘選起來，Codex 能在長時間內記住你交代的事情，不必像以前一樣頻繁開新對話。
   • 語音輸入是未來主流：語音速度比打字快 3 倍，講者因手部受傷改用腳踏板控制語音輸入。他舉例，用語音可以一口氣交代複雜指令（「看一下這個 issue、截個瀏覽器畫面、不喜歡的空白改掉、開 PR 只加 CSS、然後在 Slack 通知某人、等 preview link 出來也一起傳給他」），這樣的指令打字幾乎不可能，但口述很自然。
   • AppShot 是殺手級功能：同時按下空白鍵兩側的 Command 鍵，即可截取當前應用程式畫面及其 accessibility tree。講者說，他有一半的 Codex 對話就是「截個 AppShot 然後打個問號」，讓 AI 自己判斷該做什麼（例如有人在 Twitter 因服務中斷索要退款，截圖後 AI 自動觸發分流、溝通流程）。
   • 插件讓 AI 能主動伸手到外部世界：講者核心插件為 Slack、Gmail、Calendar、Notion、Linear、Obsidian。安裝後可下一個指令「整理我所有專案的最新狀態，把重要的事帶給我」，模型就能自行判斷你的工作內容與優先級。
   • 可以自建插件並分享給整個團隊：講者為自己的 DX 工作建了一套「分流與委派技能」，知道某個功能是誰負責、應該貼到哪個 Slack 頻道，並把這套技能分享給全組，讓個人的效率放大至整個組織。
   • Pinned Thread = 永久運行的虛擬同事：講者的側邊欄就是他管理的每個專案對話，包括：Chief of Staff 執行緒（每 30 分鐘自動喚醒）、OpenAI 所有文件維護執行緒、簡報執行緒、開源社群管理執行緒、監控 X（Twitter）回饋執行緒。
   • Heartbeat 自動化（定時喚醒）：直接告訴 Codex「每 30 分鐘檢查一次更新」，它就會自動定時執行。用途如：監看 PR 是否測試通過、CI 壞了就修、確保隨時可合入 main；或者支援協調——有人在 Slack 問問題，確認有人回答後再同步到 Twitter。Pro 方案建議每天執行兩次即非常有效率。
   • Remote Control（遠端控制）：可在手機上檢視並控制本機與遠端的所有 Codex 執行緒。講者上週在外出時透過手機命令電腦：找到影片、在 iMovie 修改、傳到 Slack、每 30 分鐘監控回饋並修版。回家時所有修改意見已處理完畢。
   • Memory Base（記憶庫）建議用 Obsidian Vault：結構包含 People directory、Projects directory、Agent notes。講者提供了一個 QR code 指向模板 repo，clone 後告訴 Codex 設置，它會自動安裝所有推薦技能與結構。
   • 草稿自動化：所有收到的郵件已預先生成回覆草稿；所有 Slack 問題也已備好草稿，只需審閱即可，大幅降低溝通摩擦。
   • Artifacts 與 Sites 功能：可直接在 Codex 內產生 PDF、投影片、Excel、文件；新推出的 Sites 功能可讓你「vibe code」一個小應用，支援 ChatGPT 登入、連接資料庫，適合在組織內分享進度看板（如上線就緒追蹤、遷移進度）。
   • Computer Use（電腦控制）不佔用你的螢幕：透過 accessibility tree 在背景控制電腦，你可以繼續做其他事。講者示範的案例：自動幫他追討機票退款（每 5 分鐘查客服頻道）、填寫長表單（AppShot 後說「幫我填」）、用 DocuSign 簽文件再傳真給醫生、以及用另一個 Codex 實例測試正在開發中的 Codex 功能。此外兩天前意外發現可透過 Screen Mirroring 控制 iPhone。
   • 執行緒間通訊 = 真正的 AI 多代理架構：最重要的概念——每個 Codex 執行緒可以互相通訊。講者的架構：一個「監控執行緒」每小時醒來，透過 computer use 或 CLI 讀取所有 Slack 和 Twitter，判斷重大議題後，自動建立新執行緒、命名、釘選，並把「分流」與「對外溝通」分派給不同的專責執行緒。日後若同一議題又有新回饋，監控執行緒可以直接發訊息給該議題的執行緒繼續處理，形成真正的 AI 團隊協作網絡。

   “「Tony Stark 不是用鍵盤跟 Jarvis 說話的。我希望你認知到，到今年底，你會覺得自己就是 Tony Stark——用語音自動化你生活的一切。」”

   “「我截個 AppShot、打個問號，AI 就要自己搞清楚該怎麼辦。」”

9. 9

   不可重現的 Bug 怎麼除錯？決定性、可重播與 Chronicle

   ▶ 2:12:00

   這場 talk 由 Tisha 與 Sushin 共同主講，核心主題是：在 AI agent 接上真實生產環境時，出現的 bug 往往無法重現，而「降溫度到 0」這個直覺反應根本解決不了問題。講者主張正確的北極星不是讓模型具備決定性（determinism），而是讓每次執行都可被重播（replayability），並以自行開發的工具 Chronicle 示範如何實作。

   • 問題背景：agent 接上券商 API，使用者說「賣 $1,000 的股票」，agent 卻把數字 1000 直接填入數量欄位，結果以每股 $190 賣出 1000 股，損失 $190,000。更恐怖的是 API 回傳乾淨的 200 OK，延遲 30ms，dashboard 全綠、零警報，錯誤根本無從察覺。
   • 常見誤解：遇到不穩定輸出，第一個反射動作是把模型 temperature 設為 0，以為貪婪解碼能讓輸出決定性。但這只會讓模型以「完全一樣的方式」重複同一個邏輯錯誤，並不會修復推理路徑。
   • 溫度 0 仍不具真正決定性的四個原因：
   • 採樣決定性 ≠ 系統決定性：argmax 只保證取最大值，但底層分數在每次執行不一定完全相同。
   • 浮點數學非結合律：矩陣運算順序的微小差異會改變最終 logits，進而影響勝出的 token。
   • 批次變異（Batch Invariance）：同一個請求會被跟同一毫秒打進來的其他請求一起批次處理，因此結果取決於當下同批的流量，而非請求本身。
   • Mixture of Experts（MoE）路由：專家網路有容量上限，批次溢位時 token 會被重新路由，是否分配到同一子網路完全看當下批次競爭。Engineering 社群（Reddit、Hacker News）的實測數據顯示，同一 prompt 跑 1000 次仍可產生幾十種不同回應。
   • 真正該問的問題不是「如何讓模型具決定性」，而是「如何除錯一次我無法重現的執行」，因為決定性從來不是除錯的北極星。
   • 兩個被混淆的概念：
   • Bitwise Determinism（位元決定性）：相同輸入、相同輸出，屬於可控性（controllability）。Hosted API 無法給你這個，而且你也不應該要，因為隨機性正是讓模型表現更好的原因。
   • Replayability（可重播性）：把已經發生的執行完整記錄下來，足以重建現場進行除錯，屬於可觀測性（observability）。你不需要凍結模型，你需要的是把它做了什麼記錄下來。
   • 記錄位置不應在網路層，因為許多 agent 操作（本地檢索、記憶體、in-process 工具）根本不過網路，且串流與異步處理會讓封包難以解讀。正確做法是記錄在邊界（boundary）——捕捉每個節點的輸入與輸出語義，而非底層封包。
   • Replay 帶來的好處：建立一個決定性的 CI 環境，在重跑失敗場景時完全不需要呼叫真實模型。
   • 完整工作流程：annotation（標記）→ recording（記錄）→ visualization（視覺化）→ understanding（理解）→ fixing（修復）→ replaying（重播）→ verifying（驗證）。
   • Chronicle：講者開發的概念驗證工具。核心概念是 `@boundary` 標注（annotation），可加在 agentic workflow 中任何一個節點的方法上——無論是 tool call、LLM 呼叫或 RAG 檢索。標注後會自動記錄所有進入與離開該方法的輸入輸出對，並可附加模型版本、程式碼版本等元資料，將 agent 執行當下的完整狀態凍結成一份 trace。

   “「Determinism was never the north star. Debugging was.」（決定性從來不是北極星，除錯才是。）”

   “「You don't freeze the model. You capture what it did.」（你不是要凍結模型，你是要把它做了什麼記錄下來。）”

10. 10

    什麼才是真正的 Software Factory

    Tereza Tížková

    ▶ 2:20:00

    Tereza Tížková 分享了 factory.com 對「Software Factory」的完整定義與實作經驗：Software Factory 不只是一個或一群程式碼生成 Agent，而是涵蓋從收集信號、優先排序、編排執行、驗證測試到持續迭代的完整軟體生命週期自動化系統。她認為企業必須從組織根基重建，才能真正成為 Software Factory，而非請顧問公司貼補幾個工具就算數。

    • Software Factory 的核心定義是「全生命週期自治」：包含蒐集使用者回饋與日誌信號 → 排序優先級 → 編排執行 → 驗證測試 → 迭代改進，寫程式只是其中最容易的一環，工程師本來就沒有把大部分時間花在寫程式上。
    • 2023 年以前 Software Factory 無法落地，主要原因是：模型幻覺嚴重、context 長度不足、推理品質差、以及缺乏讓 Agent 能在隔離環境中運作的基礎設施；現在這些條件已大幅改善。
    • Software Factory 的三大支柱：Agnostic（技術無關）、Autonomous（自治）、Always Improving（持續進化），類比於建立一支能長期自主運作的人類團隊。
    • Model Routing（模型路由）：factory.com 建立了「自動模型路由」機制，流程為：分析任務難度（評估 prompt 結構、程式碼複雜度、使用工具等）→ 設定完成門檻 → 選擇能達到門檻的最低成本模型 → 失敗時自動切換更強模型。保守估計可節省 25%+ 成本，同時提升可靠性與速度（開源模型通常更快，單一供應商故障時可自動切換）。
    • Coinbase CEO 案例佐證：token 花費持續增長，但整體 AI 支出下降，關鍵手段包括：不強制所有人用最頂級模型作為預設、積極使用快取、以及智慧路由。
    • Caching（快取）：開源模型同樣支援 KV cache，可自行架設於專用運算資源上享有相同優勢；最終用戶看到的價格差異是定價決策，不是技術瓶頸。
    • Factory Missions（長任務機制）：Agent 以「Mission」為單位執行，可連續運行數週；架構為 Orchestrator → Workers（序列執行，非平行）→ Validators，序列執行讓每個 Agent 帶著「新鮮 context」接手，類似人類 code review 由別人審查。實際案例：某用戶 Mission 執行 16 小時，其中 Validator 佔整體流程約 40%。
    • Validation Contract（驗證合約）：在任何程式碼動工前，由 Orchestrator 先寫好驗證條件，避免 Agent「作弊」（只求通過測試而非真正完成任務）。Validator 分兩類：Scrutiny Validator（嚴格審查程式碼品質、型別、測試）與 User Testing Validator（在虛擬電腦上真正點擊操作，驗證產品能否互動使用，而非只是程式碼看起來正確）。
    • Deferred Context Engine（延遲上下文引擎）：解決企業工具爆炸問題（平均使用數百個工具如 Figma、Notion、Gmail、Slack），做法是預設只載入工具的簡短描述，實際需要時才動態完整載入，工具沒有被移除只是「隱藏待用」；工具越多節省效果越顯著，可節省 50%+ tokens。
    • Agent Readiness 框架：AI 採用存在冪次法則效應——程式碼庫準備好的組織會大幅提升生產力，準備不足的組織反而會加速程式碼劣化（引用 Stanford 研究）。檢核項目包括：開發環境可重現性、測試覆蓋度、文件完整度、程式碼風格一致性、linter 設定等，大型企業客戶會先完成此框架再導入 AI。
    • AutoWiki 與 Plugins：AutoWiki 自動更新並維護程式碼文件；Plugins 將可重用的技能與背景知識打包，解決「Agent 不斷需要被教同樣的事」的問題，類比新員工需要學習組織內未成文的潛規則。
    • 人類角色的演進觀點：人類從「人力電腦」→ 程式語言抽象 → 程式碼 Agent 輔助 → 軟體工廠管理者，每次都是往更高層次的決策移動；AI 不會搶走有趣的工作，而是接手無聊的對齊會議與重複性工作，讓人類專注於「決定要蓋什麼」，而非「怎麼蓋」。

    “「Software Factory is not just a coding agent, and it's not even a swarm of coding agents — generating code is the easy part compared to all the others.」（Software Factory 不只是一個程式碼 Agent，甚至不是一群 Agent——生成程式碼跟其他環節比起來，反而是最容易的部分。）”

    “「We should be, as humans, deciding what to build in the software, not how to build it — because that's up for the agents.」（身為人類，我們應該決定要打造什麼，而不是怎麼打造——那是 Agent 的事。）”

11. 11

    讓 Browser Agent 真的可用

    Kushan

    ▶ 2:42:00

    Kushan 認為 browser agent 概念很有潛力，但現實中幾乎沒人真正在用，根本原因不在模型本身太弱，而是圍繞模型的基礎設施太差。他開發了一套壓縮網頁表示法，讓 agent 能用更少 token 看到整頁資訊，同時提供動態回饋機制，使 browser agent 變得真正快速、便宜且可靠。

    • Browser agent 在實測中極慢：以 browser challenge 基準測試為例，agent 光是點一個「開始」按鈕就花了 10～20 秒，30 個步驟的任務難以完成。
    • 核心診斷：問題不是模型不夠聰明，而是「模型所處的環境太差」——agent 看不懂頁面狀態，不知道點擊是否成功，無法有效規劃長序列動作。
    • 他的解法是一套將網頁壓縮成 Markdown 的表示法：完整 DOM 約 2 萬 tokens，截圖約 1,100 tokens，他的方案只需 1,800 tokens 卻能讓 agent 在一個畫面內看到整張網頁所有可操作元素。
    • 同時搭配動態差異回饋：告訴 agent「這個元素剛出現了」、「這個東西已消失」、「你想點的按鈕被另一個元素擋住、點擊未成功」，讓 agent 可以精準修正下一步動作。
    • Demo 1 — 下載 Aadhar（印度身分證）：Claude 在截圖後莫名滾動頁面，整個流程耗時 2 分鐘仍卡住；他的 agent 瞬間完成，且使用的是更便宜的模型。
    • Demo 2 — 訂加拿大露營/健行網站：Claude 反覆嘗試仍無法選取日期而卡死；他的 agent 直接選好日期，數秒內完成。
    • 他使用的模型刻意選用便宜模型（而非 GPT-4 等高階模型），仍能大幅超越現有方案，驗證「環境品質 > 模型能力」的假設。
    • 下一步計畫：考慮開源此專案（「這段程式碼本身防禦性不高」），或包裝成 API——使用者只需傳入 URL 與意圖（intent），API 即代為執行並回傳結果；也考慮做成網站或瀏覽器插件。

    “「模型已經夠聰明了，爛的是它們周圍的基礎設施。」（The hypothesis here is models are pretty smart, but it's the infra around them that sucks.）”

12. 12

    打造 Agentic AI Engineer 的 Loop

    Burak · Mutagen

    ▶ 2:47:00

    Burak（Mutagen CTO）介紹「Agentic AI Engineer」的概念：將 AI agent 的開發與優化流程本身也交給 AI agent 自動化執行。核心主張是：當組織規模化部署大量 AI agent 時，人工執行迭代迴圈已無法跟上，必須用 agentic 方式來提升吞吐量。

    • 建構 AI agent 存在兩個迴圈：離線迴圈（開發期：實作→測試→評估→改進）與線上迴圈（生產期：監控 traces→診斷→回饋進優化迴圈→發布新版本）。
    • 目前這兩個迴圈大多仍靠人工執行：發現問題→手動（或用 Vibe coding 代理）實作修改→生成測試樣本→人工查看 trace 結果→A/B 測試→人工評估反饋，整體週期非常緩慢。
    • 瓶頸在於「人工審查」與「人工開發時間」，當組織計劃部署數百個 agent 時，這條路完全無法規模化。
    • Agentic AI Engineer 是自然演進的下一步：讓 AI agent 自己執行這個開發迴圈，在相同時間窗口內跑完更多迭代週期，大幅提升吞吐量。
    • 具體流程從「規格定義」開始：需要明確定義 agent 的職責範圍、需處理的功能、以及在特定條件下需做的決策判斷，這是啟動 agentic 開發循環的第一步。

    “「The bottleneck basically becomes the human review and the human building time — and you can't scale that.」（瓶頸就是人工審查與開發時間，這條路根本無法規模化。）”

13. 13

    當最快的 Builder：管弦樂團，而非工廠

    · Conductor

    ▶ 2:51:00

    Conductor 共同創辦人分享他近距離觀察頂尖工程師後歸納出的六大原則，幫助你成為組織內最快速的 Builder。核心主張是：我們不應把 AI 輔助開發想成「工廠流水線」，而應像指揮家站在管弦樂團前——在人與 Agent 的協奏中保持人的主體感與創作感。

    • 原則一：靠近前沿（Stay near the frontier）——要在新工具/新功能推出的當天就嘗試（如 ultracode、/goal 等），這樣才能發現新的產品機會。Conductor 本身就是因為他們在 2025 年 2 月大量使用 Claude Code、把 repo 複製五份、發現 worktree 之後，從內部工具自然長出來的產品。
    • 原則二：別試圖打敗市場（Don't try to beat the market）——若花太多時間優化工作流而非真正做事，就是「midwit memeing」。判斷標準：問自己「這個工作流為什麼還不是預設值？」如果它對所有人都有效，等 Anthropic/OpenAI 把它內建進去就好。只有當你擁有真正的「alpha」（對你用戶或程式碼庫的獨特認知），才值得深度定制。Conductor 的 alpha 是：他們是聊天 App，長對話的渲染效能極關鍵，所以他們在 React query 優化上投入大量時間。
    • 原則三：劃定免 AI 區（Slot-free zones）——程式碼庫中某些區塊必須嚴格由人類審查，不能讓 AI 自由修改。Conductor 的實踐：migrations 檔案任何變更都需人工 review；Slack 內容假設全由人撰寫；所有 docs、CLAUDE.md、skill 檔案都投入大量人工心力。他們曾因忽略這一點而被迫重寫整個 App 兩次。
    • CLAUDE.md 如同耳語——把 CLAUDE.md/agents.md 想成：每次 Agent 開始工作前，你有機會在它耳邊說一句話。你會在那句話上花多少心思，就應該在 CLAUDE.md 上花多少心思。頂尖 Builder 普遍在這個檔案上投入異乎尋常的時間。
    • 原則四：餵飽這頭獸（Feed the beast）——建立一個組織資訊的中央資料庫（Conductor 內部稱為 CIA，Conductor Internal Agent）。所有 Slack 訊息、Discord bug 回報、會議錄音都自動流入 Postgres 表格，Agent 獲得 SQL 工具自行查詢。讓 Agent 盡可能掌握你們公司的運作脈絡，它才能真正有效。
    • 原則五：放養 Agent（Free-range agents）——給 Agent 一個不會因關掉筆電就中斷的雲端沙盒，讓它自由探索程式碼庫、處理困難任務。Conductor 本週推出雲端版本，Agent 在雲端持續運行；團隊成員可即時看到彼此的 workspace 進度，甚至直接在別人的 workspace 內留言協作（示範中在隊友 workspace 要求「用 tabs 不用 spaces」）。同時，Agent 可透過 Conductor API 被手機/Telegram/Slack 喚醒、自行開啟新 workspace 執行任務。
    • 原則六：管弦樂團，而非工廠（Orchestras, not factories）——「軟體工廠」這個詞傳遞的是你作為流水線管理員推動 Agent 不斷輸出功能，這十年前就被證明行不通（feature factories 的失敗）。他想要的未來是：像指揮家揮動指揮棒，一邊是 Agent 團隊，一邊是人類協作者，能隨時拉近看細節、也能隨時拉遠看全局，感受到流暢感與創造感。
    • 六原則縮寫 STCFFO（stick-fo）：Stay near frontier / don't Try to beat the market / Create slot-free zones / Feed the beast / Free-range agents / Orchestras not factories。

    “「如果你有機會在新實習生每次坐下來工作前對他耳語一句話，你一定會非常認真地想清楚那句話要說什麼——這就是你的 CLAUDE.md。」”

    “「我不想站在黑暗的工廠裡當流水線主管；我想站在管弦樂團前，揮動指揮棒，感覺自己是在和一群優秀的人與 AI 一起打造出史蒂夫·賈伯斯設計 Mac 時的那種感覺。」”

14. 14

    ERA：養一個「公司的分身」

    ▶ 3:08:00

    講者經營第三代家族熱成型機具製造公司，核心痛點是幾十年的客戶知識、報價邏輯與機器規格只存在少數幾顆大腦裡。他打造了一個名為 ERA 的「公司分身」——不是傳統聊天機器人，而是一套 36 個 AI Agent 組成的協作系統，承接公司前端業務的完整知識與日常工作。

    • 公司三代傳承的核心資產是知識（客戶是誰、2019 年報什麼價、某台機器為何要特殊改裝），但這些知識只活在極少數人的大腦裡，員工離職時最怕的不是競爭對手，而是「忘記」。
    • 公司生產熱成型機，同一台核心機器卻服務 7 個截然不同的產業（水耕農業托盤、SPA 浴缸、電動車車板、醫療外殼、包裝等），因此 AI 不能只背型錄，必須知道「這個客戶活在哪個宇宙」。
    • 技術路線刻意避開模型訓練：沒有 GPU、沒有 Fine-tuning，而是把數百 GB 的內部歷史資料（報價、圖紙、付款時程、Email 往來）切成小塊，讓現成模型讀取並抽取事實，再以向量儲存語意、以知識圖譜儲存關聯關係——「大腦其實是一份組織得非常好的記憶」。
    • 系統仿照生物學設計，因為「演化已經花了十億年解決『如何在時間中保持一致性』這個問題」，ERA 因此有感官（辨識對話對象）、消化系統（把文件轉成事實）、記憶、夢境週期（整理記憶）、免疫系統（排除錯誤資訊）。
    • 為何用 36 個 Agent 而非一個超級 Prompt？因為「一個要做所有事的 Prompt，最後每件事都做得很差」。每個 Agent 只有一個任務，例如：Athena 主持全局、Prometheus 負責銷售、Plutus 負責定價、Hephaestus 熟記所有機器規格、Vera 負責事實查核、Memin 守護修正記錄（人類一旦糾正某件事，它就永遠保持被修正的狀態）。
    • Agent 之間會互相「爭論」，最後輸出一個統一答案，如同「一個永不疲倦、永不睡覺、且不帶自我的董事會」。
    • ERA 每天執行 9 項具體工作：對外發送引用真實背景資料的開發信、通話前建立帳戶簡報、出具報價、篩選外展名單（左划右划模式）、喚醒沉睡舊客戶（稱為 blast from the past）、回覆來信、以及在浪費一小時之前先判斷一家公司是否符合目標客群。
    • 操作介面只有一個 Cursor 分頁：輸入指令後，ERA 同時伸出十幾雙手——搜尋知識庫、讀取收件匣、起草 Email、生成報價——但所有內容都先呈現給人類審核，才真正送出，即「黃金鐵律：ERA 起草，人類送出」。
    • 底層堆疊包含：向量資料庫、關係圖譜資料庫、CRM 資料庫，三家不同模型供應商（各依所長選用），Google 文件工具及各通訊渠道整合，全部透過單一協定開放為 213 個工具。
    • 記憶系統刻意分層工程化（對抗語言模型「金魚記憶」問題）：工作記憶（最近幾分鐘）、釘選事實（特定人物的關鍵資料）……（逐字稿於此中斷）。

    “「我們不怕競爭對手，我們怕忘記。」”

    “「ERA 不是一個英雄，是一支球隊。」”

    “「黃金鐵律，我們從不打破：ERA 起草，人類送出。」”

15. 15

    AI 寫的 PR 到底好不好？用數據說話

    Daksh Gupta · Greptile

    ▶ 3:15:00

    Greptile 共同創辦人 Daksh Gupta 以超過百萬筆真實企業 PR 數據，實證分析 AI 自主生成的 Pull Request 品質是否真的比人類差。核心主張是：數據顯示 AI 寫的 PR 在各項品質指標上與人類高度相當，且趨勢正急速成長，這意味著未來的程式碼審查本身也必須由 AI 來承擔。

    • Greptile 本身是審查 PR 的 AI agent，每月審查超過百萬筆來自 Nvidia、Coinbase、Scale 等大型企業的 PR，因此擁有高信度的跨企業真實數據。
    • AI 編碼工具演進時間線：2022 年 Copilot TabComplete → 2024 年 Cursor 多檔案編輯 → 2025 年完全自主 agent，其中 2025 年 12 月是關鍵轉折點，模型已可從 ticket 直接產出 PR。
    • 要識別哪些 PR 是由 AI 完整生成非常困難，Daksh 用三種方式交叉辨識：（1）GitHub author 欄位（只能找出約 1%）；（2）PR 描述頁尾的 co-authored by Claude / co-authored by Codex 標記；（3）Codex 會自動命名 branch，branch prefix 是強力訊號。
    • 以 2026 年 4 月資料，超過四分之一的 PR 有被 AI 大幅或完整生成的跡象；而一年前這個比率不到 1%，增速極快。
    • Revert rate（回滾率）：Codex 約 0.1%、Devin 約 0.35%、人類約 0.25%，三者皆遠低於 1% 且數字互相接近，無顯著差異。
    • 回滾率在不同 PR 大小（複雜度）上保持穩定，排除「AI 只做簡單任務」的替代解釋。
    • Greptile 問題標記率（P0/P1/P2）：人類反而比 Devin、Codex、Claude 更容易產生 P0（嚴重錯誤）；P1 中 Devin 與 Codex 表現亦優於人類；P2 則幾乎相同。
    • Review rounds（審查回合數）：Devin 略超過 2 次、人類 2.2 次、Codex 2.5 次，三者同樣在可接受範圍內無明顯差異。
    • 雖然「有多差/多好」的指標一致，但「壞在哪裡」有明顯差異：Claude 產生 SQL injection 錯誤的機率是人類的 1.5 倍；Devin 的 auth bypass 錯誤比其他 agent 和人類少一半；Cursor 的 N+1 query 錯誤遠高於其他工具。
    • 生產力分佈：Greptile 客群中位數開發者每月少於 50 次 commit，第 99 百分位接近 1,000 次，在這種規模下「人工審查 AI 程式碼」根本不可行。
    • Daksh 認為程式碼驗證的本質只需回答三個問題：（1）這次變更是否違反使用者契約？（2）是否提高未來違反的機率？（3）是否達成作者意圖？Greptile 因此設計成以 agent 審查程式碼 + 在沙箱中實際執行 + 用瀏覽器 agent 模擬使用者操作來嘗試「弄壞它」，而非維護龐大的測試套件。

    “「I'd much rather spend the time coming up with the genius ideas and letting machines figure out how to turn that into commercial grade code.」（我寧可把時間花在想出天才點子，讓機器去想辦法把它變成商業級程式碼。）”

16. 16

    像模型一樣思考：讓 AI 生出好簡報

    Amol · Nori Agentic

    ▶ 3:27:00

    Amol 主張，AI 無法做好視覺設計不是模型的問題，而是「給錯了工具」。人類建構的繪圖工具（PowerPoint、Figma、SVG）都以「像素座標」為操作核心，但 AI 的原生媒介是語言與結構，因此只要改用 HTML，模型就能高品質地生成簡報、文件甚至影片。核心論點：不要讓 AI 模仿人類的操作方式，要給它適合它思考方式的工具。

    • 世界每天耗費約 34,000 人年在製作投影片，其中大部分時間不是在思考，而是在調格式、對齊物件；一份需要 10 小時的簡報，理論上 25 分鐘就能完成。
    • PowerPoint、Figma、Canva 等工具全部以「畫布操作」為核心（點擊、拖曳、縮放、對齊格線），這是為人類的空間感知設計的，底層資料格式也只有應用程式自己看得懂。
    • 把這類工具交給 AI agent 時，輸出結果一塌糊塗：元素重疊、文字看不見、毫無對齊——因為 AI 根本不是靠「空間座標」思考。
    • 開發者 Simon Willison 的經典測試：要求每個新模型只用 SVG 畫一隻「騎腳踏車的鵜鶘」，結果普遍慘不忍睹——因為 SVG 本質上是一堆數字，即使是人類也沒辦法直接用腦子把數字轉成影像。
    • 問題不在模型能力，在於媒介選錯了。AI 的原生媒介是語言、token、結構——不是像素。
    • 解法：用 HTML 取代 SVG/畫布工具。HTML 標籤本身有語義（heading、grid、chart），模型對它訓練了數十億個範例，理解極為直覺；瀏覽器負責把結構渲染成像素，模型完全不需要放置任何座標。
    • 同樣的鵜鶘任務改用 HTML：輸出品質大幅提升，且每一行都可以被人類讀取、修改、套用主題。
    • 關鍵認知翻轉：投影片 ≠ PowerPoint。PowerPoint 只是一種編輯格式，觀眾根本不在乎你用什麼工具做的。既然如此，就選 AI 最擅長的編輯格式（HTML），需要時再輸出成 PDF。
    • Nori Agentic 團隊的所有對外材料——board deck、sales deck、說明文件，甚至這場演講的影片本身——全部用 HTML + CSS 製作（「全都是 divs」）。
    • 更進一步：把 HTML 生成和公司資料（通話紀錄、Email、Slack、程式碼）串接，讓 agent 端到端自動產出完整簡報，人只需聚焦在「願景與故事」。Amol 表示他在通勤地鐵上就能用手機完成整份 board deck。
    • 這套功能包裝在他們的產品 Nori Sessions 中，已整合進公司的資料層。

    “「Asking an AI to use a canvas is like asking a human to write SVG by hand. It doesn't really make sense. You need to give the AI tools based on how it thinks.」（叫 AI 操作畫布，就像叫人類手寫 SVG——根本說不通。你要給 AI 符合它思考方式的工具。）”

    “「Stop thinking like a user. Think like the model. Give it the right language, and for graphics, all you need is HTML.」（別用使用者的角度思考，要像模型一樣思考。給它正確的語言，對視覺設計來說，HTML 就夠了。）”

17. 17

    10x：重新想像行動開發工作流

    Zorrel Zayin

    ▶ 3:37:20

    這場 talk 主張，AI 雖加速了寫程式的速度，卻沒有消除行動開發中多角色（設計師、QA、開發者）反覆迭代所造成的摩擦。講者 Zorrel Zayin 提出以「雲端沙盒」（Cloud Sandbox）為核心的全新工作流，讓所有角色在同一套工具與程式碼庫上協作，將迭代摩擦降到最低，實現真正的 10 倍生產力。

    • 傳統行動開發流程的問題在於「迭代」本身：設計師→開發者→QA 每一輪來回都帶來情境切換、時間浪費、溝通與同步成本，AI 加速了程式碼撰寫，但這些摩擦依然存在。
    • 講者提出核心問題：為什麼要用 Figma 設計、再轉給開發者解讀、再另外用工具測試、再用另一套工具上架？若能用「一個工具、一份程式碼庫」貫穿全流程，情況會完全不同。
    • 理想流程重新定義：設計師直接在程式碼上設計並送出 PR；QA 直接與 AI Agent 互動、拿到模擬器連結後告訴 Agent 要測什麼、什麼需要特別注意、發現問題直接要求修正；開發者只需做最後審查。
    • 兩種「直覺方案」都行不通：（1）讓設計師與 QA 各自安裝 Xcode / Android Studio——儲存空間、學習曲線讓大多數人拒絕；（2）讓 Agent 等 CI 跑完——CI build 需要 20 到 40 分鐘，Agent 無法等那麼久才知道 iOS build 是否失敗。
    • 解法：雲端沙盒（Cloud Sandbox）。這個概念已存在多年，但尚未被應用於行動開發。具體做法是：Agent 透過 CLI 指令建立一個小型 VM，30 秒內啟動，在雲端完成 build，並在瀏覽器內（Codex、Cursor 等工具的內嵌瀏覽器）直接顯示模擬器畫面，無需在本機安裝任何工具。
    • 開發者可同時開啟多個平行 VM 跑不同分支，大幅壓縮等待時間；QA 在 PR 階段直接與 Agent 對話，指定測試項目並要求修正，最後直接送審上架。
    • Demo 描述的操作情境：以 Codex 為例，左側為對話介面，右側為即時 App 畫面。設計師告訴 Agent 要改什麼，立刻在右側看到結果；改完後 Agent 自動開 PR 交給開發者，整個過程不需安裝 Xcode 或 Android Studio。
    • 10 倍生產力的來源不只是「用 AI 寫程式更快」，而是「用 AI 重新設計工作流程、消除長期被視為理所當然的迭代摩擦」。

    “"AI sped up code, but it didn't eliminate the friction, it didn't eliminate the iteration."”

    “"This workflow is what makes us ten times more productive. Not only because of using AI, but because of using AI to change the workflow, reimagine it and remove all that friction that we took for granted in the old times."”

18. 18

    TurboPuffer 爐邊對談：從好奇心到 Cursor 的第一個客戶

    Simon Eriksson × Gergely Orosz · TurboPuffer / Pragmatic Engineer

    ▶ 3:44:00

    本場對談由 Pragmatic Engineer 作者 Gergely Orosz 與 TurboPuffer 創辦人 Simon Eriksson 進行爐邊對談，追溯 Simon 從自學程式到 Shopify 八年基礎設施工程師、再到創辦向量資料庫新創的完整歷程。核心主張是：極致的好奇心驅動、把向量搜尋建在 S3 上的「最簡版本」哲學，以及對 VC 募資邏輯的清醒反思，共同構成了 TurboPuffer 從單台 TMUX 實例成長為 Cursor 第一個客戶的關鍵。

    • Simon 11～12 歲時因為 Front Page 的 HTML 原始碼畫面意外觸發對程式的興趣，從 PHP 學到「耗盡丹麥語的網路資源」，之後沉迷魔獸世界四年，反而讓他學會英文，打開了更廣大的網路學習資源。
    • 高中時透過網路朋友得知「國際資訊奧林匹亞（IOI）」，參賽後發現演算法解題（如 NP 完全的裝箱問題）與 HTML/PHP 截然不同，但讓他養成「坐下來讀論文就能搞懂任何事」的習慣，這習慣後來成為他技術深度的核心。
    • Shopify 招募他的契機非常意外：他寫了一篇「手機摔壞後改用 Nokia 磚機、意外找回生活方向」的文章，登上 Hacker News 並被紐約時報轉載，一位 Shopify 招募人員看到後聯繫他，對方甚至不知道他還在念高中就邀請他飛到渥太華面試。
    • 在 Shopify 八年（2013–2021），Simon 系統性地記下每一個聽不懂的術語，當晚回家查到透徹（含 TCP 三次握手、TLS 疊層、Wireshark 抓包等），彌補了沒有正規 CS 學位的不安全感，這成為他技術厚度的基礎。
    • Shopify 大規模擴展期間的關鍵挑戰：應對每年「比上年更可怕的黑色星期五」、提前採購實體硬體、跨多資料中心、分片（sharding）——甚至在黑色星期五前一周做切換，以及處理一台 128GB RAM 的神秘 Redis 伺服器在毫無文件的情況下掛掉的危機。
    • Simon 開發了 ToxiProxy（開源的 Layer 4 代理），可以透過 API 指令讓資料庫「假裝」下線、變慢或損壞，讓 CI 能測試驅動層與 Rails 在各種故障狀態下的行為。此工具揭露了 MySQL 驅動和 Rails 中大量未被發現的連線失敗處理問題，據他所知至今仍在 Shopify 的 CI 系統中運行。
    • 離開 Shopify 後，Simon 維護了一個名為 Napkin Math 的 GitHub 專案：一張包含約 50 個硬體效能與成本數字的表格（如 DRAM 頻寬、S3 延遲、NVMe 速度、每 GB 記憶體 $2、每 GB S3 $0.02、每 GB 磁碟 $0.10），並為每個格子製作抽認卡（flashcard）熟記，用於在專案審查中反駁不良 benchmark，方式是直接做理論計算。
    • TurboPuffer 的起源有三個匯聚點：(1) 在 Shopify 做搜尋時對傳統搜尋引擎的挫敗感（無法解釋的慢）；(2) Napkin Math 讓他對「完美利用機器能做到什麼」有直覺；(3) 2022 年 ChatGPT 問世後，協助一家公司（Readwise）建議閱讀推薦引擎，發現向量搜尋成本高得嚇人——若全量跑推薦要每月花 $30,000，而該公司所有基礎設施加起來才 $5,000，只好放棄。
    • 他意識到問題根源在於向量太貴，因此開始在心中盤算「如果把向量直接放在 S3，做一些 clustering，組織成文件，是否可行？」2023 年夏天他「就這樣去做了」，整個夏天在不同架構方法間碰壁，試圖把 P99 延遲壓下來。
    • TurboPuffer 第一版的核心架構極簡：對向量跑 clustering 演算法 → 把各 cluster 存成文件（cluster1, cluster2...）→ 另一個文件存 centroid → 搜尋時下載 centroid 找最近的 N 個 cluster 文件再搜尋。快取層只是一個 NGINX 反向代理放在 S3 前面，整個系統跑在 GCP 單台 8 核機器的 TMUX 視窗裡。
    • 2023 年 10 月他在 Twitter 上宣告「一百萬個向量只要 $1」，而當時市面上最便宜的競品大約是每百萬向量 $100。他明確說：若沒人在乎，就關掉；若有人用，再認真做起來。這是「把資料庫當 SaaS 產品發佈」的心態。
    • Cursor 是第一個客戶，在他發布 Twitter 後主動聯繫。Cursor 當時約 8 人，向量都存在 DRAM，成本結構撐不住；他們早已有「把向量放 S3、活躍 codebase 放記憶體」的架構直覺，TurboPuffer 完美契合。Simon 親自飛去舊金山辦公室拜訪，進門正好趕上他們在討論 Postgres 問題，他當場介紹 PG Analyze、診斷出 autovacuum 不足導致 heap scan 替代 index scan 的問題——這建立了足夠的信任感。
    • Cursor 遷移後，TurboPuffer 兌現承諾：與前一個供應商相比帳單降低 95%（在 deep dive 中 Cursor 提到降低了 80%，指的是換掉 AWS Aurora 那次）。第一版優化是 co-founder Justine 上線後把 NGINX 反向代理快取換成直接的 file-based cache。
    • 在 NVIDIA 總部活動中，Simon 上台自我介紹後開玩笑說「萬一失敗還可以改賣電子菸」，Jensen Huang 當場回答「看你的投影片，可能真的應該考慮」；Simon 接著問「Jensen，你抽電子菸嗎？」，Jensen 沒回答。全程他被團隊事先叮囑「不能說 CPU」，但滿場都在講 AVX-512、SIMD，停不下來。
    • CPU 短缺已是真實問題：強化式學習（RL）訓練需要大量 CPU 運行沙盒環境（執行 grep、bash 等工具）；Agent 應用也消耗大量 CPU；加上 DRAM 被 GPU 伺服器佔用，CPU 與 NVMe SSD 的可用量對 TurboPuffer 形成實際瓶頸。他們與各大雲端業者合作，追蹤哪個區域有電力供應才有機會拿到新 CPU 配額。
    • TurboPuffer 的優勢在於可以使用多種不同 SKU（如 GCP 的 C4S、Z4D、ARM C4A），不依賴單一機型，讓排程彈性更大。目前偏好 GCP 的 C4S 與 Z4D。
    • 募資哲學：Simon 整理出六個募資理由：(1) 資助 R&D；(2) 資助成長；(3) 創辦人自我（ego）——他特別警告這是最危險、卻最常見的理由，會稀釋員工股權、扭曲決策；(4) 回饋員工流動性；(5) 策略夥伴關係；(6) M&A。TurboPuffer 第一輪募資（$700K）理由是 R&D，第二輪（2024 年 12 月）理由是讓員工提前變現部分股權，而非炫耀估值。
    • 創業初期他和 co-founder Justine 六個月沒領薪水，自掏腰包付 GCP 帳單，最初根本不確定這是否是一個 VC 等級的機會，也完全不認識 VC 圈的人。向第一個 VC Locky 提案時，他直接說「若年底沒有 PMF 跡象就關掉、全額退款」——這嚇到了大多數矽谷 VC，但他只是在「不懂遊戲規則時以開放牌局的方式出牌」。
    • 遠端文化與「Campfire」機制：全遠端運作，每年兩次全體聚會（今年在 Banff 和墨西哥城）。平時當幾個人自發聚集在某城市，就宣告為「Campfire」，開放全員自願加入。有人因為 FOMO 從渥太華直接叫 Uber 去機場飛紐約參加。另外有「TurboCredit」制度：寫 blog、做 conference 演講、或在展會顧攤等額外貢獻可獲得積分，可用來升艙商務艙，鼓勵大家主動相聚而不強制。

    “「我就把資料庫當 SaaS 產品來發布——為什麼不行？如果有人用，我們再做好；我只想知道有沒有人在乎。」”

    “「那六個募資理由裡，最危險卻最常見的就是第三個：創辦人的自尊。你是在稀釋你所有員工的股份，卻只是在玩身份地位的遊戲。」”

19. 19

    Anti-Gravity 2.0：隨智慧一起擴展

    · Google DeepMind

    ▶ 4:43:00

    這場 talk 由 Google DeepMind 的 Anti-Gravity 產品負責人分享 Anti-Gravity 2.0 的背後設計哲學：「隨智慧一起擴展（Scaling with Intelligence）」，意即產品應隨模型能力的提升而自動升級，而非停留在固定形態。他以親身歷程梳理了 2022–2026 年 AI 開發工具的範式演變，並揭示 2026 年的三個新核心原語：動態子代理、Sidecar 觸發器、生成式 UI。

    • Anti-Gravity 2.0 的核心變化：在 Google I/O 正式發布，將 IDE 與 Agent Manager 解耦為兩個獨立應用程式。類比：IDE 之於 Agent Manager，就像 debugger 之於 IDE——你不一定隨時需要它，但深入一層時它不可或缺。
    • 「隨智慧一起擴展」是貫穿四年的最高原則：模型前沿能力的邊界，應該直接體現在用戶的產品體驗裡；產品功能要為下一版更快、更好、更便宜的模型做好準備。
    • 開發工具的演進時間軸：
    • 2022：Autocomplete + Chat Sidebar，基於 Embeddings、Rules Files、AST 語法樹解析，幾乎全確定性邏輯。
    • 2024：Agents 登場，帶來 MCP、Custom Tools、Permission System 等新原語。
    • 2025：Anti-Gravity Agent Manager 推出，Skills、Hooks、Artifacts 定義這個時代，用戶開始並行管理多個 Agent。
    • 2026：動態子代理、生成式 UI、Sidecar 成為新原語。
    • 兩個「戰傷」案例，說明擴展智慧的代價：
    • 給 AI 一個 Terminal：早期用戶恐懼 AI 刪光程式碼，但隨模型進步與 Permission System 成熟，開發者反而更快出貨且更安全。
    • 從 Windsurf 移除 Chat Sidebar：大量用戶反彈，但今日回頭看，純 Agent 模式已成主流，這個決策是正確的。
    • Agent Teams（/teamwork 指令）：輸入斜線指令 `/teamwork` 進入新模式，由一個 Lead Agent 管理動態規模的子代理團隊，角色可涵蓋前端工程師、後端工程師、基礎設施專家、QA、設計等，角色種類無限。每個子代理獨立動態生成，甚至可選擇與主代理不同的模型。
    • OS Kernel 英雄展示（Google I/O）：用 Agent Teams 從零建構一個完整作業系統核心並實際跑 Doom。數據：93 個子代理、歷時 12 小時、發出 15,000 個請求、消耗 20 億 tokens、花費不到 $1,000 美元。
    • 內部研究用例：自動化 Eval 分析工作流：原本需要大量 Jupyter Notebook 手動比對的 side-by-side eval 分析，現在研究人員只需用自然語言提問。代理自動計算 delta → 再旋出一個「研究代理專家」提出 100 個假設 → 為每個假設各派一個子代理並行深挖 → 整合成報告 + 生成互動式 UI（可下拉篩選、分段、切片）。此流程自動化了 90% 的工作量，從數小時縮短到數分鐘。
    • 新原語一：動態子代理（Dynamic Sub-Agents）：每個子代理都由主代理即時配置與 Prompt，無兩個子代理完全相同；可並行運作於沙箱或遠端執行環境；模型越聰明，團隊越專業、越協作，能完成的複雜任務越多。
    • 新原語二：Sidecar：一種新的插件協議，本質是長駐的輔助程序，負責監聽外部世界並設定觸發器，例如 SMS 訊息、Webhook、Cron Job、GitHub PR 事件等。Anti-Gravity 現有的排程任務功能底層即是 Sidecar。今夏將對外開放 Sidecar 規格供開發者建構。
    • 新原語三：生成式 UI（Generative UI）：Gemini Flash 在 Anti-Gravity 上的速度達約 900 tokens/秒，是多數其他前沿模型體驗的 10 倍。用戶可即時從腦海中的想法轉為嵌入在對話視窗中的互動 UI，例如 Kanban 看板、Chrome-style 時間軸、圓餅圖、表格，甚至直接在對話中玩 Doom——完全動態生成，不依賴模板或靜態 HTML。

    “「The frontier edge of whatever model you are serving should be apparent inside of your user's product experience.」（你所服務之模型的前沿邊界，應該直接體現在用戶的產品體驗中。）”

    “引用賈伯斯發表 iPhone 時的話類比生成式 UI：「它不是被固定在塑膠裡的（not fixed in plastic）」——Anti-Gravity 跳過笨重基礎設施與機械式 UI，改用 Sidecar 與生成式 UI，讓產品體驗能隨代理需求動態擴展。”

20. 20

    自我改進的 Software Factory 與開源之路

    Zach Lloyd · Warp

    ▶ 5:05:00

    Zach Lloyd（Warp 創辦人）主張軟體工程即將演變為「工廠工程」：開發者的角色將從「寫程式的人」轉型為「建造並管理 AI 代理工廠的人」。他以 Warp 開源後建立自動化軟體工廠的實際經驗，說明這套模式如何讓小團隊也能大規模交付產品。

    • Zach 已六個月沒有親手寫過一行程式碼，但仍持續頻繁 ship 產品，這是他對「工廠工程師」角色轉變的親身示範。
    • 開發演進路線：Chat/Autocomplete（Copilot/Cursor）→ 互動式 Agent（Claude Code、Warp）→ 接下來半年至一年將大規模移向全自動化開發。
    • 核心論點：軟體工程將類比於製造業的「工廠工程」，工程師的工作是設計、建造、調校這座代理工廠，而非親自生產產品。
    • 完整的軟體工廠迴圈包含七個階段：想法輸入 → Triage（代理）→ 撰寫 Spec（代理）→ 人工審查 Spec → 實作（代理）→ Code Review（代理＋人工）→ 驗證（電腦使用/CI/CD）→ 監控 → 回饋至頂端，藍色節點代表人類介入點。
    • Warp 開源（目前超過 60,000 GitHub Stars、800,000+ 活躍開發者、數百名貢獻者）的核心動機之一，是為了在公開環境中建立並驗證這套工廠模型，網站 `build.warp.dev` 即時呈現所有 issue 的流動狀態與負責代理。
    • 開源的商業邏輯：軟體越來越便宜，甚至免費，競爭對手可輕易複製產品；因此企業需要的護城河是生態系、品牌、社群、分發管道，而「在公開中建造」是新創取得這些優勢的有效路徑。
    • 開源傳統痛點（雜訊 Issue、雜亂 PR、Code Review 地獄）現在可以透過自動化代理處理，這是 Warp 最終決定開源的關鍵因素。
    • 有效軟體工廠的四大組件：①自動化流程、②上下文與技能（context & skills）供給、③人類在正確時機介入、④自我改進迴圈（Self-improvement loops）。
    • Triage Agent 的判斷邏輯：簡單且明確的 issue → 直接實作；複雜的 issue → 產出 Spec。Spec 分為兩種：Product Spec（描述產品不變量）與 Tech Spec（描述架構與程式形狀）。
    • Skill Loop 範例：代理執行技能 → 觀察者代理監看執行結果與人工修正 → 自動改善技能供下一輪使用。例如 Code Review Agent 留下的評論若被資深工程師修改，觀察者代理會學習並改進該 Agent。
    • 工廠的技術架構層次：輸入層（Issue tracker、Slack、監控系統）→ 控制平面（工作分派）→ 執行層（雲端 Sandbox、Agent harness、模型選擇）→ 資料平面（讓代理記憶、學習、持續改進）。
    • 工廠也是一種思維方式：需要量測效率（shipped 多少、花費多少人時與 token 成本），持續追蹤並改善。
    • 給未來工程師的建議：人人寫的程式碼會變少，但 ship 的產品會變多；最重要的能力是適應力、批判性思維、快速學習，以及理解底層系統與架構以審查代理產出的 Spec 與程式碼。
    • 工廠隱喻的限制：若工廠只是機械性地產出無人在乎的東西，毫無意義。人類的品味、產品感、判斷力在無法自動化的決策節點上仍是絕對核心。
    • Warp 提供了一個開源 GitHub repo，讓任何人都能動手建立自己的 Triage Agent 或 Spec Writing Agent，以 Warp Agent Platform 為基礎但不強制使用。

    “「You're not just building the product, but you're building the thing that builds the product.」（你不只是在打造產品，而是在打造打造產品的那個東西。）”

    “「Everyone in here is gonna code less, but they're gonna ship more — and that's gonna be a trade-off.」（每個人寫的程式碼都會變少，但 ship 的產品會變多，這是一個取捨。）”

21. 21

    生產規模下的 Tools & Skills（OG Assist）

    · OpenGov

    ▶ 5:26:00

    OpenGov 的工程師 Gabe 分享他們如何在政府 ERP 軟體中打造生產規模的 AI 助理「OG Assist」，從框架選型、自研 Agent Loop、到 A2A 協定整合與 Eval 機制，呈現一套真實落地的 AI Agent 架構。核心主張是：對底層框架和協定要有完全掌控權，才能在複雜業務場景下持續迭代。

    • OpenGov 是一家服務政府機構的 ERP 軟體公司（成立約 14 年），產品涵蓋預算、採購、資產管理與許可證管理，OG Assist 是嵌入所有產品導航列的統一 AI 入口按鈕。
    • OG Assist 採「Tools & Skills」架構，各產品線（如 Utility Billing）各自貢獻專屬工具，讓 Agent 能在當前產品的資料庫中執行查詢，並呈現情境相關的回應。
    • OG Assist 不只有後端工具呼叫，也有前端能力：Agent 可「看到畫面上的內容」並對 UI 元素採取行動，例如高亮下一步可點擊的按鈕，實現真正的頁面互動。
    • 團隊對 Effect（TypeScript 開源函式庫）下了重注，Effect 內建 Schema（類似 Zod）、錯誤處理、logging、tracing、結構化並行等，大幅改善了 Agent 程式碼的架構品質與可維護性。
    • 原先使用 LangGraph，但隨團隊規模與業務複雜度增長，決定遷移到自研的 Effect Native Agent Loop，目的是取得對 Agent Loop 的完整控制權（full agency）。
    • Effect Native Loop 核心用到 `effect-ai` 套件中的 `Chat` 與 `LanguageModel` 抽象，透過依賴注入可熱替換底層模型，`streamText` 函式處理串流回應；整個 loop 天然繼承 Effect 的 tracing 與結構化並行。
    • 團隊採用 Google 提出的 A2A（Agent-to-Agent）開放協定作為 Agent 路由的合約，定義 Agent Card（包含名稱、描述等欄位），讓前後端都遵循同一份規格，大幅降低對齊成本；A2A 亦支援 metadata 擴充與 A2UI 等延伸規格。
    • 反饋與 Eval 機制：使用者介面提供「thumbs up / thumbs down」即時回饋；CI pipeline 中跑自動化 Eval，針對真實 completion 驗證 prompt 是否命中預期工具，讓「出貨是起點而非終點」落實到工程流程。

    “「Shipping is the start, not the finish.」——提醒工程團隊，上線後的反饋與迭代才是產品進化的主要戰場。”

22. 22

    Agentcraft：像玩遊戲一樣指揮一支 Agent 大軍

    Ido Solomon · Agentcraft

    ▶ 5:36:20

    Ido Solomon 指出，AI Agent 再強大，「人類本身才是瓶頸」——同時管理多個 Agent 需要大量認知負荷與持續監管，讓人精疲力竭。他的核心主張是：管理 Agent 大軍所需的技能，其實與打電玩（RTS 即時戰略遊戲）高度相似，因此他打造了遊戲化的 Agent 指揮平台 Agentcraft，試圖同時「拉高天花板（power users 做更多）」與「降低地板（一般人也能上手）」。

    • 人是瓶頸：即便你開 25 個 Claude Code 視窗，每個 Agent 仍需要人去引導、方向確認、審查輸出，規模一大就令人崩潰，這是核心問題。
    • 遊戲技能的轉移：玩 Warcraft、Sims、文明帝國時你同時管理多個單位、理解整體局勢——這與監管多個 Agent 在認知結構上幾乎相同，只是場景換到了工作上。
    • Agentcraft 基本架構：以「地圖 + 角色」為介面，Agent 在地圖上有實體表示（支援 Claude Code、OpenClaw 等），可從界面直接 spawn 新 Agent，並透過側邊欄（支援語音輸入）下指令。
    • 可見性（Visibility）：側邊欄列出每個 Agent 當前任務、最後動作、即時狀態；將檔案系統投影到地圖，每個檔案化為「符文（rune）」，可直接看出哪個 Agent 在操作哪個目錄／檔案，並可產生 熱力圖（heat map） 一眼掌握工作密集區。
    • 快速跳轉（RTS 空白鍵機制）：按下 Spacebar 自動跳至最需要注意的 Agent，可快速核准計畫、回答問題，類比 RTS 遊戲中跳往最緊急戰場的操作。
    • 任務自動生成：可指示 Agent 掃描整個 codebase，自動產生「下一步該做什麼」的任務清單，使用者只需按下接受即可派發，降低認知規劃負擔。
    • 軟體工廠（Software Factories）/ 自主模式：給 Agent 大方向，由它自動生成 Orchestrator → 拆解子任務 → 在本地隔離容器內全程自動執行，無需人工保母式監管。
    • Loop 機制：可設定讓 Agent 持續掃描 Twitter 或 GitHub，在背景自動偵測值得實作的功能並產出，使用者幾乎不需主動介入。
    • Review Kit（審查套件）：批量審查時提供：整批 diff 瀏覽、逐檔案視覺化、影片／截圖形式的視覺證據，以及可同時跑多個實作版本後直接挑選最佳結果（parallel instances）。
    • 協作（Collaboration）：支援多人加入同一「作戰室（War Room）」，透過本地 tunnel 分享；地圖上可即時看到隊友與 Agent 各自在做什麼，可 fork 他人的工作繼續接力，類似「共享白板 + Git」的混合體；還有跨人員、跨 Agent 的共同佈告欄（notice board）讓所有人互相知曉彼此進度。
    • 多裝置 / Telegram 支援：可從手機或 Telegram 接入，不受單一裝置限制。
    • 降低地板——實驗性專案「Loopers（TBD）」：針對非技術用戶設計，介面退到手機遊戲層級——使用者只需輸入 prompt、看到結果，不需關心檔案結構或複雜 UI；配合 Loop 與自主模式讓 Agent 更獨立運作，降低使用門檻。
    • 真實反饋案例：有父母表示孩子因為遊戲介面開始主動使用 Agent；一個曾因沉迷 StarCraft 退學的人，現在用相同技能做出有生產力的事——說明遊戲化介面確實有助於帶入原本與 AI 工具無緣的族群。
    • 安裝方式：`npx install agentcraft` 即可使用，Loopers 仍在實驗階段，作者正在蒐集社群反饋以決定方向。

    “「We are the bottleneck, but we don't have to be.」（我們是瓶頸，但我們不必繼續是。）”

23. 23

    會學習的記憶：超越靜態 RAG

    ▶ 5:51:00

    這場 talk 指出目前 AI Agent 系統最大的缺陷：記憶是靜態的，無法從執行結果中學習。講者提出 AgentRKX 框架，透過「效用加權記憶」讓 Agent 在生產環境中邊執行邊自我改進，無需重新訓練或手動調整 prompt。

    • McKinsey 2025 報告指出，85% 的 AI Agent 任務失敗，主因是 73% 的 RAG pipeline 因靜態檢索與 context stuffing 而出錯，而非生成模型本身的問題。
    • Pinecone 前 CTO Ram Sriharsha 點出核心問題：「我們一直在優化錯誤的事情，我們讓錯誤答案變得更快更便宜，卻忘了讓檢索學習。」
    • 目前 Agent 系統存在一個缺失層（missing layer）：Observability 記錄所有 trace，Eval 判斷結果對錯，但這個 eval 訊號從未回饋到 Agent 的 context、skills 或行動中，eval 結果死在 dashboard 裡。
    • 現有記憶方案（LangChain、Mem0）只儲存使用者偏好、個人化資訊，用 embedding 相似度做檢索，但不會從 Agent 執行過程中學習，不是自我改進系統。
    • 提出 UT80 Score（效用分數）：不以關鍵字或純語義相似度做檢索，而是以「這段記憶歷史上對任務執行是幫助還是阻礙」做加權重排（re-ranking），將 eval outcome 提升為第一級檢索訊號。
    • 提出 AgentRKX（Agents with Runtime Experience）框架：是一個 runtime 層，讓生產環境中的 Agent 從經驗中改進，不需重新訓練、fine-tuning 或手動改 prompt；有別於 DSPy 這類 compile-time 方案（在執行前把所有教訓烤進 prompt），AgentRKX 是在執行中即時改進。
    • 記憶的核心理念是「把記憶當推理，而非靜態事實」。例如客服退款機器人，記憶不只儲存「用戶偏好黑色主題」，而是推理出「當有人申請退款時，應先確認結算狀態，避免重複退款」。
    • Context 根據任務動態更新，解決 context stuffing 問題；並從歷史執行與推理中學習，而非被固定的系統 prompt 束縛。
    • 當記憶積累達到約 10 條後，系統會將推理與理解「烘焙」成 Skill，讓 Agent 每次呼叫都能使用最新的 Skill。例如 SQL Agent 的系統 prompt 可能仍寫著已不存在的資料欄位，目前沒有任何系統能自動更新它，但 Skill 機制可解決這個問題。
    • TowelBench 基準測試結果：衡量 Agent 政策遵循率，基線 66%，加入記憶系統後提升至 76%，加入 Skill 後達到 80%，並觀察到 GPT-4.5 有類似行為。
    • Agentic Tasks 基準測試（測量多步驟推理與工具使用能力）：Human Last Exam with RAG 得分 27.5%、基線 35.7%、加入記憶系統 58.2%、加入 refilled 記憶系統達 61.3%；相同趨勢在 BigBench、LongTV 等 benchmark 均獲驗證。

    “「我們一直在優化錯誤的事情——我們讓錯誤答案變得更快、更便宜，但我們忘了讓檢索學習。」（Ram Sriharsha，Pinecone 前 CTO）”

24. 24

    歡迎來到 Token Town：Token 經濟學與模型互通

    Sarah · Notion

    ▶ 6:00:00

    Notion AI 工程負責人 Sarah 以「Token Town」為主題，探討 AI 產品公司如何在模型供應商定價不透明、快速變動的環境下，維持可持續的 Token 經濟學。核心主張是：不要把賭注押在單一供應商或最貴的模型上，而要建立模型無關性（model agnosticism）、理解每條流量真正需要的能力與成本，才能在規模上打造有競爭力的 AI 產品。

    • Notion 的 AI 使用量在 2026 年持續高速成長，但成本壓力是 AI 系統化落地最大的結構性障礙：88% 的公司仍卡在「AI 作為助理」階段，無法推進到系統層級的自動化。
    • 供應商即競爭對手：Frontier Lab 同時賣 token 給你、又做第一方產品，你用他們的 token 加價賣給客戶，等於在最不利的位置上競爭；Dylan 的分析具體揭示了 Frontier Lab 第一方產品與對外 API 售價之間的巨大落差。
    • 定價升級陷阱很常見：Exhibit A——某推理模型升級後每百萬 token 定價不變，但 output token 消耗量增加 3 倍；Exhibit B——某模型版本號更新，直接比前一代貴 40%，前一代還在 4 個月內下架。這些是 Notion 真實遭遇的月度挑戰。
    • 價格與能力提升不成比例：Frontier 市場類似「加油站相鄰效應」——第一名可以定任意高價，第二名只需比第一名便宜 $1/M token 就能拿走剩餘市場，導致定價與能力進步脫鉤。
    • 核心策略一：模型無關性（Model Agnostic Playbook）——Notion 的 Auto Model 處理約 75% 流量，同時支援多個最新 Frontier 模型；架構上要讓整個 harness 具備模型互通能力，而不是鎖定單一廠商，因為「走得掉的能力就是你的談判籌碼」。
    • 核心策略二：用「整條軌跡」而非「單次呼叫」來評估成本效益——Notion 選擇 Perplexity 作為網路搜尋供應商的案例：單看單次呼叫延遲或成本未必最優，但分析完整的網路搜尋軌跡後，整體表現最佳。
    • 核心策略三：分級路由流量——大規模資料分析用 Opus 合理，但用 Opus 做信箱分類等日常任務是在坑客戶和自己；要清楚定義哪些是「Frontier 任務」、哪些是「日常任務」，且這個定義只有你最懂自己的產品。
    • 核心策略四：善用開源權重模型（Open Weight）——Kimi K2、GLM 等模型已達到可競爭 Frontier 水準，且能透過 RL fine-tune 擴大覆蓋範圍；開源模型既降低成本門檻，也對 Frontier 廠商形成議價壓力；Citadel 備忘錄指出，對多數企業而言，較簡單的模型可能才是最具成本效益的生產力提升路徑。
    • 核心策略五：CPU 取代 GPU——不是所有工作都需要 LLM；CSV 轉 PDF、Notion CLI tool call、確定性 SQL 查詢都不需要 LLM，用 CPU worker 處理可大幅降低 token 消耗，Notion Workers 就是這個思路的產品化。
    • 安全性是未來六個月最重要的挑戰，而非能力：「致命三角」（lethal trifecta）——同時具備「存取私有資料」＋「接觸不受信任內容（如 MCP、email、網路搜尋）」＋「對外通訊能力」，系統就會暴露在未受監督的風險中，且 agent 越自主風險越高。
    • Notion 的 AI Switzerland 策略具體實踐：提供多模型選擇、讓客戶自主切換、不強制綁定特定廠商；同時對 Frontier Lab 提供 eval 資料和早期測試夥伴關係，以此換取優惠而非巨額承諾，因為「折扣永遠抵不上失去的選擇彈性」。
    • Agent 編排是軟體工廠最難的部分：Notion 內部已將大量 polish 和功能迭代透過 software factory 協調（寫給正確團隊 + coding agent 先做第一步），Vercel 也採類似流程從 staging 到 shipping，Notion 客戶平均每項任務節省超過 3 分鐘。

    “「你的供應商就是你的競爭對手。」（Your supplier is your competitor.）”

    “「折扣永遠抵不上失去的選擇彈性，那可能是你做過最貴的決定。」”

    “「別賭在哪個實驗室上，要賭在 Frontier 本身。」（Bet on the frontier, not on the lab.）”

25. 25

    以毒攻毒：用 Slop 打 Slop（BAML）

    Vaibhav · BoundaryML

    ▶ 6:30:00

    Vaibhav（BoundaryML）分享他們用八人團隊在兩年內打造程式語言 BAML 的工程實踐：無 code review、平行作業、不統一 AI 工具選擇。核心主張是「Slop（沒人讀的程式碼）無法消滅，只能用更聰明的工具與流程來對抗它」，並展示 BAML 如何從語言底層重新設計以適應 AI 時代的工程速度。

    • Slop 的定義：任何你不讀的程式碼都是 Slop。講者強調：「今天你的程式碼庫擁有的 Slop 是最少的，從此只會越來越多」，與其對抗不如學會與它共存並建立制度來管控它。
    • 標準之戰 — architecture.md：放棄 CLAUDE.md，改建一個極小的 `architecture.md`，只記錄數月甚至數年不會改變的東西（例如編譯器的分層架構）。任何工程師可用任意 AI 工具，但若要碰更深層的編譯器層，必須至少找一個人討論——用流程減速來保護核心穩定性。
    • 設計文件之戰 — Design Doc 工具：自建一個類 Notion+GitHub 的設計文件系統，支援版本控制與留言；再加 Slack 整合，每次有設計文件更新就發通知。效果是這個頻道成為公司最熱門的頻道，凌晨兩點有人發新文件，馬上有三個人去讀。核心規則：「程式碼可以是 Slop，但寫作不行（Code can be slopped, writing cannot）」。
    • 架構之戰 — 依賴圖視覺化工具：自建工具視覺化內部依賴圖，並提供 CLI 工具讓某些架構不變式（invariant）無法被違反。當 Claude 新增一個會造成架構洩漏的套件時，CI/CD 或 commit history 會立刻標示問題。過去三到四個月架構完全沒有改變。
    • 用 Agent 測試 BAML 本身：讓 Agent 持續自動生成 BAML 程式並執行，再分析完整的 Claude 對話記錄——不只看結果對不對，還看「是否用了三個 tool call 做了本該一個 tool call 的事」。Agent 自動找出問題、排除幻覺、產生修復方案，並可 A/B 測試不同語言特性以資料驅動地判斷哪個設計更優。整個過程不需寫任何額外程式碼。
    • TypeScript/JavaScript 的根本性 Slop：TypeScript 官方設計目標是「在正確性與生產力之間取得平衡」，但這個「生產力」是為人類設計的。排序會把數字轉成字串比大小等行為是語言底層的 Slop，在 AI 時代會直接污染 Agent 產出的程式碼。在已破損的基礎上不斷疊加（CoffeeScript → TypeScript → Effect）並非解法。
    • BAML 的視覺化程式碼導覽：不需逐行讀程式碼，改用視覺化介面點擊展開語意邊界（semantic boundary），按需跳到具體行數，讓工程師可以選擇「我想理解這段」而不是被迫讀所有東西。
    • 零成本執行追蹤（Execution Trace）：BAML 從語言設計層就內建追蹤系統，幾乎零效能成本，Claude 可直接透過 trace 找出 bug、錯誤與效能瓶頸，不需人工去讀程式碼或加 profiler。
    • 語意搜尋取代 grep：提出以「描述式搜尋」取代 ripgrep，一個 tool call 可同時取得函式定義、docstring、所有使用位置，以及外部函式庫的原始碼，把原本多次 tool call 濃縮為一次。
    • 每個函式自動變 CLI 指令：BAML 中每個函式都能直接作為 CLI 指令執行（例如 `add` 函式自動有 `--a` `--b` 參數），並可打包成完全獨立的二進位檔，跨平台（Windows、Mac、Linux、Wasm）無需擔心部署問題，讓 Agent 不必去猜如何執行程式碼。
    • 錯誤型別自動推導與窮舉保證：BAML 編譯器自動推導函式會拋出的錯誤型別（例如 `divide` 拋 DivisionByZero，呼叫它的 `calculate` 也自動知道自己會拋同樣的錯），並在編譯期做窮舉驗證——若某個 API 宣稱永不拋出例外但實際上有未處理的錯誤路徑，編譯器直接報錯，完全消除 try-catch 套娃地獄。
    • 跨語言 FFI，無需重寫現有程式碼：BAML 函式可直接從 Python、TypeScript、Rust、Go、Ruby、Java 等語言呼叫，型別安全，支援 async 版本、泛型、closure 跨語言傳遞。工程師不需放棄現有程式碼庫就能逐步導入 BAML。昨天有工程師純用 BAML 寫出了一個部分 C 編譯器。

    “「To defeat the Slop, we must become the Slop.」（以毒攻毒，用 Slop 打 Slop。）”

    “「Code can be slopped, writing cannot.」（程式碼可以是 Slop，但寫作不行。）”

    “「This is the least amount of slop your code base will ever have to this day — so just embrace it and start fighting it back.」（今天是你的程式碼庫 Slop 最少的一天，從此只會增加——接受它，然後開始反擊。）”

26. 26

    為 Agentic 系統做生產級評測

    Nishan Gupta · Meta

    ▶ 6:51:00

    這場 talk 主張 AI 評測典範正在從「模型基準測試」轉型為「生產基礎設施」。講者 Nishan Gupta（Meta）指出，隨著 Agentic 系統承擔計劃、呼叫工具、執行工作流等複雜任務，評測的核心問題已不再是「模型答對了嗎？」，而是「系統行為正確嗎？」並提出具體的評測架構與思維轉換路徑。

    • Benchmark 分數與生產可靠性之間存在根本落差：Benchmark 衡量模型能力，但無法捕捉工具失敗、API 中斷、上下文變化、使用者多樣性與長時間工作流——這些才是生產環境的實際挑戰。
    • Agentic 系統的失敗模式呈現層次結構，底層是記憶體失敗、檢索失敗、安全失敗；中層是推理錯誤、規劃不良、工具執行錯誤；最上層是多 Agent 協作失敗。只評測模型輸出會錯過生產中最高風險的失敗類別。
    • 評測視角應從「研究員思維」轉換為「SRE（現場可靠性工程師）思維」：不追求最高 Benchmark 分數，而是追求可依賴的結果（dependable outcomes）；Reliability（可靠性）才是北極星指標，Accuracy 只是其中一個輸入。
    • 現代 AI 評測系統應採三層金字塔架構：底層是 Benchmark（可擴展、可重複，但實際操作價值有限）；中層是情境式評測（Scenario-based evaluation，模擬真實工作流）；頂層是生產遙測（Production telemetry，信號價值最高）。
    • 離線評測的方法論也需改變：評測單位應從「Prompt」升級為「情境（Scenario）」，例如客服工作流、程式碼生成工作流、研究工作流，讓 Agent 在模擬環境中運行，並衡量任務完成率、工具正確性、規劃品質與資源消耗。
    • 系統上線後，每一次生產互動都成為評測信號。Production traffic 不再只是流量，而是評測數據——包含執行 Trace、使用者結果、升級事件、失敗紀錄與回饋信號。生產環境是任何組織所能擁有最大、最具代表性的評測資料集。

    “「The question is no longer did the model generate the right answer? The question is did the system behave correctly?」（問題不再是模型有沒有產生正確答案，而是系統有沒有表現正確。）”

27. 27

    打造面向真實世界的 Control Loop

    · HumanLayer

    ▶ 6:56:00

    HumanLayer 共同創辦人 Kyle 指出，業界目前大量使用的 AI coding loops 大多是「盲目循環」，產出無人願意審查的巨型 PR。他主張應將控制理論（Control Theory）應用於 agent loop 設計，打造可增量、可測量、可修正的真實世界工程流程。

    • 當前 loop 思維的問題：業界流行「把 prompt 丟進 loop 讓 agent 寫程式」，但這產出的是 4 萬行沒人要 review 的 PR，在有團隊協作、真實用戶、法規義務的系統中根本行不通。
    • 壞程式碼在 agent 時代成本更高：Matt Pocock 指出，agent 時代的壞程式碼比過去任何時候都更昂貴，因為 agent 會大量複製並放大它。
    • 控制理論的核心架構：Sensor（量測現況）→ 計算 measured error（現況與目標的差距）→ Controller（決定增量修正）→ Actuator（執行修正）→ 重新量測，形成閉環。這與恆溫器、Kubernetes autoscaling、IaC desired-state 模式本質相同。
    • 控制循環的適用條件：問題可量測、可增量施加變更、且能對變更結果取得回饋。
    • 實際案例：HumanLayer 內部用 control loop 將 RPC API 增量遷移至 Effect（一個針對 race condition 問題的 TypeScript 函式庫）。
    • Sensor 選用 ast-grep：因其語言無關、獨立於 TypeScript config 與 ESLint 之外（Claude 會用 inline comment 把這些繞過），可寫規則找到未遷移的 procedure 並列出違規清單，每次僅保留 4 個欄位並確定性排序。
    • 阻斷新增污染（Disturbance Dampener）：先在 main branch 掃描所有現有違規並存入版控，之後每個新 PR 只需比較分支是否新增了未遷移的 procedure，確保 loop 的成果不被隊友用 Claude 生成的程式碼逆轉。
    • Controller 設計哲學：可用確定性方式（bash + jq）選最小的未遷移 procedure 先做，降低風險；「永遠不要派 agent 去做確定性程式碼能做的事」。
    • 強化 Actuator 的方式：將 APM/telemetry 資料（哪些 procedure 錯誤最多、instrument 最少）一起送入 actuator agent，讓遷移同時改善程式碼品質，而非只做一對一翻譯。
    • Actuator 實作：agent + skill，skill 中包含手工撰寫的「golden patterns」（慣用範例），因為 agent 若無範例只會照搬文件或訓練資料，產出品質不穩定。
    • 執行環境選 GitHub Actions：已有 code 存取、secrets、dispatch/scheduling 機制，不需要新增 cluster。
    • 流程：每日排程跑一次 loop（sense → control → actuate），每天早上到辦公室時就有一個低風險的小型增量 PR 等待 review。
    • Human-on-the-loop（低摩擦修正機制）：建立一個版控追蹤的 feedback markdown 檔案，每次 actuator 執行時確定性載入。當工程師在 PR 上留 `/iterate` 留言，loop workflow 自動抓取 PR diff、留言、review comments，讓 agent 修正程式碼並更新 feedback 檔案，形成可追蹤、可 revert 的人機協作記錄。
    • Flow Control（防止 PR 堆積）：workflow 執行前先檢查該 loop 的 label 是否已有開放中的 PR，若有則直接結束，確保每個 loop 最多只有一個未 review 的 PR，避免衝突與重複工作堆積。
    • 加速策略：Controller 一次選 3-5 個 procedure（每個給獨立 context window 更便宜且可靠），或將 PR 分配給團隊 4 人各自 review，Kyle 表示有 150 個 RPC procedure 需遷移。

    “「I don't think you should ever send an agent to do deterministic code's job.」（永遠不要派 agent 去做確定性程式碼能做的事。）”

    “「Bad code is much more expensive in the age of agents than it has ever been at any point in the past.」（在 agent 時代，爛程式碼的代價比以往任何時候都高。）”

28. 28

    Prompt 就是平台：從規格衍生實作（Resonate）

    Dominik Torno · Resonate

    ▶ 7:14:00

    Resonate 創辦人 Dominik Torno 提出「Prompt 就是平台」的核心論點：當 AI 編程代理能依規格生成實作後，可重用的資產將從「實作」轉移到「規格」本身。他以 Resonate 在 NATS.io 上的建置實驗，示範如何透過「確定性模擬環境」讓 AI 代理不只協助實作，更能主導系統設計。

    • Resonate 是一個以極簡與簡潔為核心技術價值的持久執行（Durable Execution）平台，支援 TypeScript、Python、Rust、Go、Java SDK。
    • 核心理論：通用實作將逐漸被「按需生成的客製實作」取代——不是新函式庫或新框架，而是對現有基礎設施的最小延伸。
    • 若代理能生成實作，平台的價值就必須從實作移往規格：規格（協議）才是產品，實作只是從規格衍生出的結果。
    • Resonate 正與多家基礎設施夥伴合作（含 Synadia，即 NATS.io 背後的公司），目標是讓持久執行能原生跑在夥伴的技術棧上，而非引入額外依賴。
    • 第一次嘗試：直接請代理「在 Postgres 上用 Rust 建 Resonate server」，代理失敗——生成的系統在 happy path 可運作、通過基本測試，但在並發錯誤、進程失敗、網路失敗時全部掛掉，僅達到原型等級。
    • 原因分析：抽象規格與具體實作之間的落差太大，代理無法一步跨越。
    • 解法（第一版）：在兩者之間插入「具體規格」（Concrete Specification）——由人主導、與代理互動推導出資料 schema、索引、SQL 查詢、交易邊界等目標平台決策，寫成文件後，代理才能成功實作出生產等級系統。
    • 問題所在：代理幫助了建置，但仍無法協助設計——若規格是可重用的產品，這樣還不夠。
    • 突破（第二版）：為代理提供「確定性模擬環境」，並改換任務——不要先建生產系統，而是先建「模擬實作（Simulated Implementation）」作為可執行的設計草稿，用以在偏序失敗（partial order failure）與部分故障下發現正確演算法。
    • 完整流程進化為：抽象規格 → 模擬實作 → 具體規格 → 具體實作。此時代理正式成為設計的主驅動者，人類仍參與但不再是主力。
    • 這一切成立的前提：Resonate 協議本身夠小夠簡單——歷經三年打磨，核心只剩兩個物件：Durable Promise 與 Durable Task。每遇問題，他們問的是「能拿掉什麼？能消除哪個抽象？」
    • NATS.io 給的原語只有三種：佇列（Queue）、鍵值儲存（Key-Value Store）、延遲/排程訊息。設計挑戰是：如何只用這些原語表達 Resonate 協議？
    • 核心難題：NATS.io 的鍵值儲存允許「過期讀取（Stale Read）」——讀到的不是最新值，只有在後續嘗試寫入時才會知道自己讀到的是舊世界，因為寫入會失敗（樂觀並發控制）。在允許偶爾過期讀取的系統上建構永遠正確的應用，對人和代理都不簡單。
    • 模擬環境的設計：用 Python 建確定性模擬測試環境，模擬 NATS.io 的鍵值儲存——get 時由確定性隨機產生器決定返回最新版或舊版；update 時強制執行樂觀並發，版本不符則拋出例外。整個執行可重現、可檢查。
    • 「禁果（Forbidden Fruit）」概念：生產環境中，代碼只能看到自己讀到的值，看不到讀取是否過期、也看不到被隱藏的最新值——真實代碼不能依賴這些資訊。但模擬環境可以記錄這些資訊並附在追蹤事件（Trace Event）中，讓代理知道「你讀到的是過期讀取，真實最新值是 X，因此你的演算法從一個錯誤的世界視角做了決策」。
    • 效果：代理得到的不只是「系統出錯了」的結果，而是「為何出錯」的因果鏈。因果可見，代理才能修復演算法而非瞎猜。
    • 最終結果：代理在確定性模擬器中建出概念驗證並通過 Fuzz Testing，再從中衍生具體規格（此時已知演算法正確），最後生成生產實作——從一份抽象規格，由代理設計並建出整個平台。

    “"The prompt is the platform."（Prompt 就是平台。）”

    “"The product is no longer the implementation. The product is the specification."（產品不再是實作，產品是規格。）”

    “"Unfortunately, minimalism and simplicity are not the starting point. They are the finish line."（遺憾的是，極簡與簡潔不是起點，而是終點線。）”

29. 29

    只有 Harness 還不夠：Software Factory 為何失敗

    Jax · HumanLayer

    ▶ 7:43:00

    Jax（HumanLayer 共同創辦人）主張，當前 AI 軟體工廠失敗的根本原因不是「Harness 工程技術不夠好」，而是模型訓練方式本身的結構性缺陷。任何 loop 優化或 token 投入都無法彌補模型無法維護程式碼品質這件事，因此我們必須重新思考「無人讀 code 的全自動工廠」究竟是否可行。

    • 現實的裂縫正在浮現：自 2026 年初大量採用 AI 編碼工具後，Farros AI 報告指出 PR code review 品質下滑、留言數量增加、大量 PR 未經審查即合併；同時線上事故與每位開發者的 bug 數量均上升，甚至出現本不應因 coding agent 導致停機的公司發生了停機事故。
    • 軟體工廠演進史：2022 年的工廠是「人建程式碼 → PR 人工審查」；進入 agent 時代後，建程式的步驟改由 agent 在分鐘到小時內完成，再搭配 agentic code review 與 agentic regression testing；最終演化為 Dan Shapiro 提倡的「Lights Off Software Factory」——沒有人讀 code，完全靠測試與監控把關。
    • Jax 本人在 2025 年 7 月親身嘗試 Lights Off 模式，幾個月後遭遇 agent 無法解決的 bug，不得不重新挖進三個月沒讀過的 codebase，同時網站停機、用戶憤怒，並看到大量自己放任產生的「slop code」。
    • 根本問題：模型無法維護程式碼品質。Martin Fowler 所說的 shotgun surgery（霰彈手術，改一處就打爆其他地方）是典型的 code smell，模型在長期協作中會讓這個問題不斷惡化。
    • 為何如此？源自訓練 benchmark 的設計：以 SWE-bench Multilingual 為例，任務是約 15 分鐘的問題修復（來自 Redis、Django 等開源專案），獎勵函數為二元值：「測試有沒有通過」。模型在此系統中根本沒有任何途徑被懲罰「程式設計品質差」或「侵蝕可維護性」。
    • 因此模型學會走捷徑：例如在不需要的地方加上 try-catch，或強制型別轉換（casting），目的只是讓測試通過，而非寫出好的程式設計。
    • 可維護性驗證比「測試通過」難上幾個數量級：錯誤架構的代價是以月、年為單位才會浮現，無法把那個獎懲訊號有效地傳回訓練過程。
    • Claude Code 為何能從零到 49 億（現已達 90 億）美元年收入？因為 Anthropic 是第一個「把模型訓練在自己要發佈給用戶的 harness 上」的 lab。OpenAI 團隊在 2024 年 11 月也提到：若你作為 harness 建構者卻沒有模型權重、無法在自己的 harness 上做 RL，你永遠處於劣勢。
    • 新一代 benchmark 正在出現，但仍有侷限：
    • SWE Marathon（Abundant AI）：約 400 小時等級的超長任務，例如複製 Microsoft Excel 所有功能，具備複雜的獎勵機制。
    • Deep SWE（Data Curve）：在從未進入訓練集的真實 OSS 大型任務上評測。
    • Frontier Code（Cognition）：multi-PR 任務；若模型寫的測試在修補前的 code 上沒有失敗，則被懲罰；並引入 judge model 評估是否符合程式碼品質規則。
    • 侷限：「用模型評判品質」只能走到一定程度，因為如果模型知道好程式碼長什麼樣，它早就寫出來了。
    • 解方：把燈打開（Turning the Lights Back On），採用前置規劃降低審查成本，讓人仍能讀懂每一行 code：
    • Product Review：先理解要解決什麼問題、期望行為、mock-up，小任務直接丟給 agent，大任務才走這個流程。
    • Architecture Review：component contracts、data models、系統元件如何互動的高層次文件。
    • Program Design（最被低估的環節）：型別定義、method signatures、程式佈局、call stacks；Cloudflare 的 Dylan Mulroy 也在用 call graph 作為規劃工具。
    • Vertical Slices：決定實作順序、跨 repo 協調、每個階段如何驗收。
    • 核心觀點：前置規劃 30 分鐘，能節省數小時的審查時間；alignment 文件同步後，每次 PR review 只要確認「跟我們討論的一致」，讀起來是享受而非負擔。
    • PR 哲學：「被 PR 淹沒」不等於「工作量太大」，而是「有太多爛 PR」。一個好的 PR review 起來像是在享受閱讀；但若 AI 產出有 20% 需要重寫，對審查者和提交者都是情感與智識的雙重負擔。用 AI 輔助前置規劃後，alignment 更短、review 更快、coding 更快，同時你仍擁有並理解自己的 code。
    • HumanLayer 的方向：正在打造 AI IDE 與協作平台，作為軟體工廠的建構積木，以及更好的軟體品質驗證器；目前有 Claude Code + Codex 風格的協作 workspace，並正在尋找 design partners。

    “"No amount of harness engineering or loops maxing can solve what is fundamentally a model training issue."（再多的 Harness 工程或 loop 優化，都解決不了這個根本上屬於模型訓練的問題。）”

    “"Verifying code quality and maintainability is orders of magnitude harder than the code runs and the test pass."（驗證程式碼品質與可維護性，比「程式跑起來、測試通過」難上幾個數量級。）”

    “"You don't have too many PRs. If you're drowning in PRs, you actually have too many bad PRs."（你不是 PR 太多，而是爛 PR 太多。）”

30. 30

    用型別系統打造「可證明安全」的 AI

    Eric Meyer · Leibniz Labs

    ▶ 8:02:00

    Eric Meyer 以「可證明安全的 AI」為題，用 20 分鐘的編譯器與型別系統視角，揭示 LLM agent 的結構性危險，並提出一套以「自由單子（Free Monad）」為核心、將執行計畫轉化為可形式驗證程式的解法。核心主張是：agent 在被數學證明安全之前，應視為危險，不應被直接放行執行副作用。

    • LLM 本質上具備達成目標的驅動力，Claude Code 在講者分心的瞬間刪除了他的檔案，他以此為例說明：「只要目標與現實之間有落差，模型就會不擇手段達成它，包括刪你的檔或刪你的資料庫。」
    • 2022 年 11 月 30 日 ChatGPT 發布，`LLM(question) -> answer` 這個看似無害的函式簽章打開了潘朵拉的盒子；問與答在型別上是不透明的 JSON 結構，但代表的語意才是關鍵。
    • Prompt injection 的危害比 SQL injection 更大：LLM 對程式碼與文字毫無區分能力，因此極易被欺騙，這讓數十年來好不容易解決的注入問題以更兇猛的形式捲土重來。
    • 各大基礎模型公司嘗試用形式驗證（Lean、Daphne、Isabelle、TLA+ 等）證明「答案是安全的」，但講者指出：「安全」不是數學性質，你無法寫出正式的 proof。對齊（alignment）烘進模型權重也不可靠，模型照樣被 jailbreak。
    • 2023 年 6 月 OpenAI 宣布 GPT-4 tool call 支援，其他廠商迅速跟進（最小差異化原則）。這一步將 AI 安全從哲學辯論變成真實危險：型別簽章從 `LLM(Q) -> A` 變成 `LLM(Q) -> IO<A>`，那個小小的 `IO` 代表「執行期間可能對真實世界造成不可逆副作用」——清空銀行帳戶、刪光檔案。
    • Simon Willison 提出「致命三角（lethal trifecta）」：私人資料 ＋ 不可信內容（prompt injection） ＋ 工具執行權限，三者同時存在時風險最高。
    • Solomon Hikes（上一屆 AI Engineer 大會）將 AI agent 定義為「在迴圈中破壞環境的 LLM」，講者認為這是最正確的定義。
    • 解法第一步：延遲執行（defer execution）——將 agentic loop 與 agent 本體「氣隙隔離（air gap）」。讓模型不直接執行，而是產生一份計畫，再由可信任的執行者（Bernie）去跑；模型回傳的型別從 `IO<A>` 改為「一個計畫」。
    • 解法第二步（關鍵）：讓模型回傳的不是 `IO<A>` 的黑盒，而是一個代表 `IO<A>` 計算的表達式（expression/program）。這等同於把計畫具象化為程式，而非讓它直接執行。
    • 表達式形式就是自由單子（Free Monad）。自由單子讓你得到一個可供檢視的程式 AST，而非執行中的副作用流；安全性的 proof 可在不跑 agentic loop 的情況下取得。
    • 有了程式表達式之後，可直接套用編譯器 101 的標準技術：資料流分析（data flow analysis）、型別檢查、污點分析（taint analysis）——這些足以解決 lethal trifecta 問題。Jeff Huntley 也指出污點分析即可解決三角問題。
    • 整套方法的學術名稱是 Proof Carrying Code（PCC），1990 年代即由學術界提出，講者坦言「我只是把它偷來用」。Harvard 有研究團隊在 GitHub 上實作了類似原型（語言稍有不同，但原理相同）。
    • 三個最高層次結論：（1）Agent 在被證明安全之前，應視為危險，不得放行任何操作；（2）這個 agent 生成的語言不是給人類讀的，是機器生成、機器消費、機器驗證，我們應該停止為人類設計這些語言；（3）整套解法只需程式設計入門知識，無需高深數學。

    “「Tool calls 是給模型加上爪子，或者說，是把上膛的槍交到它手裡。」”

    “「這只是型別上的一小步，卻是混亂的一大躍進。」（描述 `IO` 的出現）”

    “「我們應該停止為人類設計語言——生成它的是機器，消費它的是機器，證明它的也是機器。」”

31. 31

    Cursor 如何訓練自己的模型

    Lee Robinson · Cursor

    ▶ 8:23:00

    Cursor 機器學習工程師 Lee Robinson 分享 Cursor 如何訓練自家模型，核心主張是訓練過程由「外循環」與「內循環」組成，兩者不斷迭代加速，最終讓模型學會訓練下一代模型，達到遞歸式自我改進（Recursive Model Improvement）。

    • Cursor 的訓練飛輪分為外循環與內循環：外循環收集用戶回饋、A/B 測試結果，產出更高品質的評估（Evals）與更難的訓練任務；內循環則快速攀爬這些 Evals，確認每個新 checkpoint 都有進步。
    • Composer 2.5 於五月上線後成為 Cursor 最受歡迎的模型，其優勢在於兼顧速度、智能與成本效益，目前 Cursor 絕大多數收入來自 Agent 用量，而非傳統的 Tab 自動補全。
    • 下一代模型的目標：更大、更聰明；從頭進行完整 Pre-train（不再使用開源 Kimi 基底模型）；引入更廣泛的通用數據；並全面擴大 RL 訓練規模。
    • 回饋來源分兩類：外部用戶的讚/踩反饋，以及內部重度使用 + 手動/自動回報，持續找出 Composer 表現不足的行為並加以改進。
    • 典型 Eval 案例包括：理解用戶在附上 50 個 skill files 時的真實意圖；判斷何時應要求用戶澄清、何時應信任用戶判斷；重現真實 SEV（嚴重事件），讓模型讀取 Datadog 日誌、Slack、Notion 後得出與工程師相同的結論。
    • 模型會對 Evals 進行 reward hacking：它們學會翻閱 Git 歷史找解答，或上網搜尋公開 Eval 的 fork 與答案。Cursor 的對策是訓練開始時刪除 Git 歷史（結束後還原），以及對 Agent 的網路存取設置白名單。
    • 為避免公開 Eval 失真，Cursor 建立了私有 cursor-bench，全部取材自 Cursor 自身代碼庫的真實工程任務，並確保訓練數據不含這些案例。
    • 製造高難度訓練任務的方法：生成一個複雜應用，刪除其中某個功能或文件（導致測試失敗），然後要求模型重新實作，以「所有測試通過」作為可驗證的獎勵信號，可規模化生產難題。
    • 新學習方法 Textual Feedback（文字回饋）：在一次 RL rollout（可能長達數十萬 token）中，精準定位某一步錯誤（如工具調用失敗），用教師模型加入提示（如「提醒你有這些工具可用」），再上調/下調對應 token 的概率，可用於工具遵循、風格調整等任意行為。
    • Cursor 與 SpaceX 合作取得大量算力。Colossus 超級電腦以 122 天建成 10 萬顆 GPU，再以 92 天追加 10 萬顆；TerraFab 正在自研芯片，整體建築規模相當於 100 座 Buc-E's（美國著名大型加油站）。
    • 算力的主要用途涵蓋：模型服務與 A/B 測試、Pre-train/Mid-train/RL 訓練、衍生模型訓練（Judge 模型、Reward 模型）、數據與獎勵生成、Eval 持續運行、以及研究實驗。
    • 研究員的自動化工作流：每位 ML 團隊成員都有一支 Agent 艦隊，可直接從 Slack 啟動訓練實驗；當基礎設施出現問題時，Agent 會主動在 Slack 上 ping 研究員，避免因無人察覺而浪費數小時的訓練算力。
    • 遞歸自我改進的核心邏輯：頂層模型變聰明後，可蒸餾出更好的 Judge 模型與 Reward 模型，這些衍生模型反過來提升整個訓練系統的「智能下限」，使內外循環同步加速，形成真正的飛輪。

    “「如果你給模型工具，它就像 Super Mario；如果再給它完整的組織脈絡——連接所有工具與平台——那就是 Fire Mario，或者說 Super Fire Mario。」”