Databricks（一家幫助企業集中管理大量資料的雲端平台，許多大公司用它來跑資料分析）與 OpenAI 宣布策略合作，讓 GPT-5.5（OpenAI 最新的大型語言模型，也就是驅動最新版 ChatGPT 背後的那套 AI 技術）正式進駐 Databricks 平台，同時支援 AWS、Azure、GCP 三大雲端環境。這次整合的重點不只是「多一個 AI 模型可以呼叫」，而是附帶了一套叫做 Unity AI Gateway（統一 AI 閘道，類似企業 API 管理平台，但專為 AI 設計）的治理架構——所有 AI 呼叫都必須走這個閘道，自動偵測個資外洩、防範 Prompt Injection（就是有人故意下特殊指令讓 AI 做不該做的事）、過濾有害內容，並把每筆請求完整記錄到資料庫，方便企業稽核。根據 Databricks 設計的企業文件推理基準測試，GPT-5.5 在 Agent Harness（多步驟 AI 工作流全流程評測）拿下 52.63%，對比前一版 GPT-5.4 的 36.10%，錯誤率降低了 46%，顯示這次升級在複雜任務自動化上有實質進步。
假設一家金融公司想讓 AI 自動審閱合約——以往工程師直接呼叫 OpenAI API，哪個部門用了多少費用、有沒有不小心把客戶姓名送出去、AI 做了哪些決策，全部一概不知，合規部門很難交代。整合 GPT-5.5 與 Unity AI Gateway 後，分析師只要在 Databricks 的 Genie（自然語言資料分析介面，讓人用白話文問資料問題）輸入「幫我比較這 50 份合約的付款條款，列出異常項目」，後台 Agent Bricks（自訂多步驟 AI 工作流程工具）會自動拆解任務、逐份翻閱 PDF、跨文件比對數值，最終回傳彙整報告。整個過程 Unity AI Gateway 都保有完整紀錄：誰查詢、查了哪些文件、花了多少 token（AI 運算資源的計費單位）——合規部門直接從 Delta tables（Databricks 的資料表格式）查得到，不需要再另外建稽核系統，也不需要修改任何現有流程。
OpenAI 的 Codex（一個能自動幫你寫程式的 AI 工具，類似 ChatGPT 但專門處理程式碼任務）正從桌機擴展到手機與平板，讓開發者在行動裝置上也能遙控電腦寫程式。根據 OpenAI 公布的數字，Codex 已累積超過 400 萬每週活躍用戶，每位用戶的使用量是原本的 5 倍，上線第一週就突破 100 萬次下載。與此同時，GitHub Copilot（微軟旗下的 AI 程式助手，直接內嵌在 VS Code 程式碼編輯器裡）也在強調：決定 AI 程式助手好不好用的關鍵，不只是 AI 模型本身的能力，更在於整個「執行框架」——也就是 AI 怎麼讀取你的程式碼脈絡、怎麼呼叫工具、怎麼記住狀態。這場競爭的重心正從「誰的 AI 模型最強」轉移到「誰的整合體驗最好」。
假設你是一位工程師，出門在外只帶了手機，但家裡的 Mac mini 整天開著跑任務。以前若臨時需要修改程式，只能等回家或帶筆電；現在用 Codex 行動版，你可以在咖啡廳拿起手機，直接輸入「幫我在公司網站加一個用戶登入頁面」，Codex 就會透過背景連線到家裡的 Mac mini 自動執行程式修改，完成後回報結果——手機只是遙控器，實際運算仍在家中電腦。舊做法需要用 SSH（一種讓你從遠端控制另一台電腦的技術）手動打指令，技術門檻高且容易出錯；新做法只需一句自然語言，AI 全程代勞，連原本不會寫程式的人也有機會嘗試。
這篇文章整理了 AI 代理程式（agent，就是會自動執行多步驟任務的 AI 程式）在搜尋方式、評估方法和可靠性設計上的最新社群討論。在搜尋方面，研究發現用傳統的 grep（一種文字精確比對搜尋工具，電腦用了幾十年的老技術）配合適當的 agent 框架，效果可以媲美甚至超越向量資料庫（vector DB，一種把文字轉成數學向量再做相似度搜尋的新方法）；另有實驗比較了 SDK（軟體開發套件，直接呼叫 API 的做法）和 MCP（Model Context Protocol，一種讓 AI 連接外部工具的標準協定）在實際 API 查詢任務上的效率差異，MCP 方式消耗的 token（AI 處理文字的基本單位，多消耗就多付費）高達 SDK 的 8.4 倍。在評估框架方面，社群彙整了 Terminal-Bench、GAIA、OSWorld 等多種 benchmark（基準測試，用來衡量 AI 能力的標準化考題）的全景圖，並出現新提案 FutureSim，透過回放真實世界事件來測試 AI 的持續學習和預測能力。在可靠性方面，工程師開始警覺：當 AI 系統越來越像黑盒子，用戶看不到 AI 的推理過程和中間狀態，驗證成本大增，系統整體的可理解性可能悄悄衰退，即使局部指標看起來正常。
假設我要替公司內部建一個「程式碼搜尋 agent」，讓 AI 在大型程式庫裡找到相關程式碼片段再做修改。過去常見做法是把程式碼向量化，儲存在向量資料庫，查詢時靠語意相似度撈出片段——這需要建立索引、維護向量資料庫基礎設施。但根據這篇整理的論文，直接用 grep（精確比對關鍵字的古老工具）包進 agent 框架，在程式碼任務上效果持平甚至更好，建置成本更低、延遲也更小。另一個直接可參考的數字：同樣是查詢 monday.com 的 GraphQL API，用 SDK 直接呼叫只需 1 步驟、消耗 15,000 個 token；改用 MCP 協定則要 4 步驟、消耗 158,000 個 token，費用約貴 8.4 倍。這意味著在設計 agent 架構時，不一定要選最新技術，要先衡量實際的 token 成本和任務類型，老方法有時更划算。