AI圈人士最近在忙什麼？

最近，我參加了在舊金山舉辦的AI Engineering大會，這次經歷讓我對AI領域的現狀有了更清晰的認識。大會演講大致分為兩類：85%的參會者是來自企業的用户，他們試圖學習如何在組織中更好地利用AI；而剩下的15%則是真正處於前沿的人，他們探索了自動化軟件的深度，甚至帶回了一些“克蘇魯式”的恐怖故事。我原本期待後者會佔更大比例，但實際結果讓我有些驚訝——即使在這個高度篩選的環境中，絕大多數人仍然不知道如何有效使用AI。

AI世界每個月都有新熱點。一月份是起飛，二月份是“什麼是技能”，三月份是“每個人都必須使用Claude Code”，四月份是讓運維團隊加入，五月份是token最大化。而六月份顯然變成了“技能氾濫”月。有十幾個演講的變體都是“我們如何管理組織中創建的1000個技能？”這些演講場場爆滿，這應該能反映出大部分市場的關注點。在我的公司Nori，我們早在去年十二月就解決了這個問題（參見noriskillsets.com，一個基於開源本地技能管理客户端的團隊級包管理器）。

然而，許多關於“技能管理”的演講讓我感到失望。我認為擁有那麼多技能是一種“代碼異味”。根據我的經驗，智能體非常擅長從基本原理出發解決問題。一個技能可能會漂移、可能不會增加任何新內容、還需要管理，這更可能製造問題而非解決問題。坦率地説，我認為許多在組織中處理數百個技能文件的團隊，是因為員工樂於讓編碼智能體為各種事情生成技能，而沒有嚴格驗證它們是否真的有用。這給人一種“AI賦能”工作的假象，但實際上並非如此。

另一個讓我失望的是，很多演講都涉及某種形式的自我學習，即讓智能體閲讀轉錄並自動創建技能，以至於我專門寫了篇文章。任何沒有人類參與上下文管理的流程都會迅速失控，這正是我們最終擁有如此多技能的原因。在我看來，你不能真正依賴智能體來為你編寫好的技能。這個過程需要有意識地進行。我們發現有一種特定的格式非常有效：將技能集打包成特定組，而不是簡單地堆砌一堆技能然後加上搜索服務器。每次與智能體交互都像是從虛空中召喚一個實體，而與智能體捆綁的特定技能是獲得最高質量結果的關鍵部分。試圖讓智能體大腦“糊化”只會產生混亂的結果。

關於評估（evals），這個術語在AI領域被嚴重過載。研究人員和模型提供商使用“評估”來指代可以用於評估原始模型性能的基準測試，如SWE-Bench、Humanity's Last Exam和ARC-AGI。這些評估是人為設計的，為研究人員提供改進模型訓練的指標。而工業界部署這些模型的人使用“評估”來指代迴歸測試，用於使生產工作流盡可能確定，例如“AI是否正確標記數據”或“它是否會在客服窗口中正確回應對抗性輸入”。儘管前者對前沿人員更相關，但我認為後者是許多大型企業所考慮的，因此也是大部分聽眾所關心的。

AI在不同類型的組織中有着不同的應用方式。在科技公司和初創企業，員工主要將AI作為開發工具使用，如Cursor和Claude Code。開發者每天大部分時間都與此類界面交互，因此對AI的能力有相當深入的瞭解。然而，在其他行業如銀行和零售，工程並非核心職能，AI的主要使用方式是作為基礎設施。最常見的形式是ETL管道——一個定期從某個表提取數據、進行轉換然後加載到另一個表的過程。傳統ETL管道脆弱且需要大量API和字段的調整。LLM憑藉其固有的靈活性，有望大大簡化這一努力。但新技術從未被完全採納，尤其是在大型、行動緩慢的公司中。新技術的引入通常是作為現有系統的補充或替代。這就是為什麼AI在很多公司中落腳於ETL世界——因為這是最適合的現有形狀。不幸的是，ETL管道需要一致性和可審計性，而AI智能體兩者都不具備。

因此，token最大化在大型科技公司意味着“給個人開發者無限預算用於Claude Code之類”，而在其他地方則意味着“向這些失敗的ETL管道投入更多令牌，使其從80%正確率達到100%正確”。一種天真的方法是構建另一個AI系統來檢查第一個系統的輸出。但如果那個也失敗了呢？你可能需要構建第三個系統來檢查第二個系統的輸出。這顯然是個問題。現在token最大化已死，一些技術能力較弱的公司已將員工每月的令牌支出限制在50-100美元左右。

最後，關於雲端智能體：當Claude Code在本地運行時，它會困在你的機器上，造成巨大的安全漏洞，並且難以協調和協作。雲端智能體解決了這些問題：它們可以從任何地方訪問，集中化帶來安全、可觀測性和治理方面的優勢，並且是邁向“全自動化企業”的必要步驟。雲端智能體可以響應事件和定時器，自動執行任務。

總之，這次大會讓我清楚地看到了舊金山與其他地方之間的鴻溝。前沿人員談論的是雲端智能體和強化學習環境，而大多數觀眾則關心如何讓ETL不再糟糕。我的建議是，不要試圖讓AI系統達到100%的正確率，而是讓AI完成95%的工作，然後由人類審核剩餘部分。