許多人仍在消化 Anthropic 昨日發布的重大消息。我們藉此機會，為 AIE 新推出的「前線部署工程師 (Forward Deployed Engineer, FDE)」計畫，向全球頂尖的 AI FDE 徵才，這與 OpenAI DeployCo 和 Anthropic DeployCo 的類似舉措相呼應。
同時，AIE 也啟動了新的「創辦人計畫」，舉辦我們版本的「新創競技場 (Startup Battlefield)」，這是一場由 YCombinator 的 Garry Tan 和 Howie Lu 的千萬美元 Hyperagent 大賽共同支持的競爭性提案競賽。
如果您有興趣，請立即報名（並預訂飯店！）以獲取詳細資訊。AI 新聞：2026 年 5 月 28 日至 5 月 29 日。我們檢閱了 12 個 Reddit 子版塊、544 個 Twitter 帳號，並未發現其他 Discord 消息。AINews 網站提供所有過期刊物的搜尋功能。
提醒您，AINews 現已成為 Latent Space 的一個專區。您可以選擇訂閱或取消電子郵件頻率！Claude Opus 4.8 推出、基準測試摩擦與 API 使用便利性Opus 4.8 在一個嘈雜且評價不一的環境中推出：多個獨立基準測試結果顯示其「有所增長但並非主導」。
@arena 進行了 200 多項前端/程式碼測試，比較 Opus 4.8 與先前的 Opus 版本、Gemini 和 GLM；@theo 報告 CursorBench 顯示它比 4.7 更高效，但在誤差範圍內略遜一籌；@jerryjliu0 和 @llama_index 發現它在表格/佈局方面略有提升，但在文件解析的內容忠實度/圖表方面有所退步；@scaling01 表示在 ALE-Bench 上沒有進展，並另外指出 LisanBench 上出現了有趣的失敗模式。
從積極面來看，@jeremyphoward 發現 4.8 在程式設計方面比 4.7/GPT-5.5 更少過度代理且更具協作性，而 @leo_linsky 則稱其為 Anthropic 先前版本的一個實質性產品改進。Anthropic 還推出了一些實用的平台級別變更：@ClaudeDevs 宣布可以在對話中途加入系統指令，而不會破壞提示詞快取，並提供權威性的對話中途系統角色更新，這對於長時間運行的代理程式會話和成本控制至關重要。
然而，定價仍然是一個主要抱怨：@jeremyphoward 認為 Anthropic 在 API 負擔能力方面做得很少，部分原因是他更喜歡 GPT-5.5，因為其訂閱/API 經濟效益更容易證明。總體而言：4.8 似乎是一個針對實際使用的有意義的「生活品質」版本，而非一個徹底的基準測試重置。
代理框架、多輪強化學習錯誤與自主性基礎設施一個微妙但重要的強化學習 (RL) 失敗模式被指出：@ClementDelangue 強調了 Hugging Face 的一項深度分析，解釋了為什麼許多使用工具的多輪 RL 訓練迴圈會默默地失效。核心錯誤在於：解碼模型輸出、解析工具呼叫，然後重新詞元化更新後的對話，這可能會改變詞元化結果，導致梯度被應用到模型從未實際取樣的序列上。
建議的解決方案是嚴格遵守「詞元輸入，詞元輸出 (Token-In, Token-Out)」規則：絕不重新編碼已取樣的詞元；在不同輪次之間保持單一詞元緩衝區。@johnschulman2 強調了更廣泛的觀點，即渲染器是訊息和詞元之間基礎設施的基石，其失敗模式涵蓋訓練/測試不匹配、快取效率低下和提示詞注入風險。
代理框架 (Harness) 設計正成為一門獨立的最佳化學科：@omarsar0 提出了一項關於「有效回饋計算 (Effective Feedback Compute, EFC)」的研究，聲稱原始詞元/工具計數對代理程式的成功解釋力不足，而 EFC 的 R² 值可達 0.99，這意味著代理框架的品質比總體活動更重要。
這與 @LangChain 等產品化微調工作相符，其 Deep Agents v0.6 將代理框架設定檔視為一等公民，以比領先 API 低 20 倍以上的成本，從 Qwen/Kimi/DeepSeek 獲得強大性能，而 @hwchase17 則明確指出「不同模型需要不同的提示詞/工具」。
@vllm_project 推出了原生權重同步 API，並改進了非同步 RL 的暫停/恢復功能，隨後又增加了 fastokens，這是一個 Rust BPE 詞元分析器，旨在減少長上下文/代理程式工作負載中的 CPU 詞元化瓶頸。爭論正從「單一代理程式 vs 多代理程式」轉向「抽象化何時能帶來效益」：@OfirPress 認為當前的多代理程式系統主要提供速度提升，而非能力解鎖；@scaling01 則持相反觀點，預期群體式訓練將產生更好的規劃和超智慧行為。
無論如何，實際趨勢很明顯：越來越多的團隊正在圍繞代理程式可觀測性、追蹤和持續改進迴圈進行建構，例如 @Vtrivedy10 關於挖掘生產追蹤以進行 SFT/知識蒸餾和長週期持續學習的工作。開源模型、本地 AI 與開源軟體工具鏈的緊密整合本地優先和開源權重模型的發展勢頭持續增長：@LangChain 表示，2026 年 4 月有三分之一的 AI 團隊運行開源權重模型，比九個月前的五分之一有所增加；@EpochAIResearch 估計，開源權重模型目前落後於領先的專有模型約四個月。
在工具鏈方面，@ggerganov 推出了 llama.app，為 llama.cpp 提供了官方網站、統一安裝程式和單一 llama 入口點，旨在簡化本地部署和第三方代理程式整合。@ollama 宣布透過 Ollama 推出 OpenJarvis 作為本地優先的個人 AI，明確與史丹佛/Hazy 的「每瓦智慧 (Intelligence Per Watt)」框架相關聯。
開源基礎設施正變得更具企業級形態：@ClementDelangue 指出，Hugging Face 上約 50% 的模型和資料集現在是私有的，隨著 HF 儲存/儲存桶服務的提供而增加；這對「HF 僅是公共開源軟體基礎設施」的觀點是一個重要的修正。
@abidlabs 展示了 Hugging Face Jobs 取代 GitHub runners 進行 CPU/無伺服器 GPU CI。@DSPyOSS、@dbreunig 和其他開發者在即將推出的 4.0 版本之前，發布了重新設計的 DSPy 文件/首頁，重點放在可程式化 AI 系統的入門，而非純粹的提示詞工程。
授權和寬鬆許可正成為策略性槓桿：@kimmonismus 強調 NVIDIA 將其四個開源模型系列轉移到 Linux Foundation OpenMDW-1.1，減少了權重/程式碼/文件/資料之間的法律碎片化。新的寬鬆許可資料發布也至關重要：@keshigeyan 推出了 GPIC，一個包含 1 億對圖像的寬鬆許可語料庫，以及一個 100 萬對的視覺生成基準測試，明確具備研究和商業可用性。
Google/OpenAI 產品介面擴展：託管代理程式、Gemini Spark/Omni 與 Windows 版 CodexGoogle 正在將「託管代理程式」堆疊從 API 擴展到消費者產品：@_philschmid 展示了 Gemini API 中的託管代理程式：單一 API 呼叫即可提供一個沙盒化的 Linux 環境，具備程式碼執行、網路存取和檔案輸入/輸出功能。
在消費者端，@GeminiApp 向美國的 AI Ultra 訂閱者推出了 Gemini Spark，作為一個 24/7 的個人代理程式，可以在用戶的數位生態系統中依指示操作。Google 也持續推動 Gemini Omni 多模態生成/編輯的演示（範例、產品討論串），並宣布推出 Google Flow Agent，用於影片/電影製作中的創意工作流程（討論串）。
OpenAI 的 Codex 正朝著持久的遠端開發操作員邁進：@OpenAI 和 @OpenAIDevs 增加了在 Windows 上的電腦使用功能，包括從 ChatGPT 行動應用程式進行遠端操控。後續的使用者體驗改進包括背景代理程式的穩定識別圖示，以及在先前聊天內容中進行搜尋（@OpenAIDevs）；@reach_vb 總結了 Codex 在 Windows 控制、行動遠端存取和個人資料/任務統計方面的更廣泛更新。
另外，OpenAI 更新了 gpt-5.5 instant，根據 @michpokrass 的說法，改進了其迎合性、事實性和多語言性能。這一切都指向更垂直整合的代理程式堆疊：模型 + 代理框架 + 沙盒 + 使用者介面 + 遠端控制 + 定價/配額。
Google 正在調整 Gemini 的配額（@joshwoodward）；OpenAI 正在擴展 Codex 的操作介面；Cursor 增加了自動審查模式，並帶有基於子代理程式的審批路由（推文）。常見的模式不再是「聊天機器人」，而是帶有策略和記憶體的託管執行環境。
值得關注的研究和系統論文搜尋、檢索和記憶：@TheTuringPost 強調了哈佛/麻省理工學院的「雙向演化搜尋 (Bidirectional Evolutionary Search, BES)」，它結合了前向搜尋、後向分解和演化運算子；報告的成果包括 Llama-3.2-3B-Instruct 在 MuSiQue 上的表現從 4.0% 提升到 7.0%。
在檢索方面，@_reachsumit 指出了「潛在詞項 (Latent Terms)」，展示了可以透過稀疏自動編碼器 (SAEs) 從凍結的密集檢索器中提取出稀疏的 BM25 就緒特徵。@topk_io 開源了 Iso-ModernColBERT，以實現更高效的後期互動推論。
持續學習和信念/狀態管理：@HuggingPapers 總結了 BeliefTrack，聲稱最佳化的信念狀態管理可將長週期推理失敗率降低 70% 以上。@AndrewLampinen 認為持續學習領域過度關注干擾而非正向遷移；@victor207755822 發表了第二篇 DeliAutoResearch SKILL 論文，重點關注自我迭代和持續學習。
多模態/世界模型/機器人學：NVIDIA 相關工作包括 γ-World，一個以 24 FPS 串流的生成式多代理世界模型（推文），以及 minWM，一個即時互動式視訊世界模型框架（推文）。在機器人學方面，@_akhaliq 分享了 Qwen-VLA，而 @inventorOli 演示了 Robostral 在語言遵循和操作方面的改進。
對於始終啟用的主動代理程式，@dair_ai 提出了一項工作，用一個 220MiB 的時序圖編碼器取代大型語言模型 (LLM) 的喚醒決策，在運行速度快 4-83 倍的同時，F1 平均分數提高了 16.7。熱門推文（依互動量）OpenAI / 生物學：@OpenAI 在 Rosalind Biodefense 上宣布為公共衛生和生物防禦提供受信任的生物學工具。
Google / 消費者代理程式：@GeminiApp 在 Spark 上向美國 AI Ultra 用戶推出了其始終啟用的個人代理程式。OpenAI / 開發工具：@OpenAI 關於 Codex Windows 支援，以及 @OpenAIDevs 將電腦使用擴展到 Windows 和行動遠端操控。
llama.cpp 使用者體驗里程碑：@ggerganov 推出了 llama.app，提供統一安裝程式和 CLI 入口點，用於本地 AI。Hugging Face / 強化學習正確性：@ClementDelangue 強調了針對帶工具的多輪強化學習的「詞元輸入，詞元輸出」警告。
開源與閉源時間差距：@EpochAIResearch 估計開源權重模型目前落後於領先模型約四個月。StepFun 3.7 Flash (活動：637)StepFun 發布了 Step 3.7 Flash，這是一個多模態專家混合模型 (MoE)，總參數為 196B，其中 11B 活躍，並內建一個 1.8B 的視覺轉換器 (ViT)。
該模型宣稱可支援高吞吐量的代理程式工作流程，高達每秒 400 詞元 (TPS)，據報導可在約 128GB 記憶體的本地環境中運行。報告的基準測試結果顯示，對於一個 Flash 級別/本地模型而言，其表現異常強勁：SWE-Bench Pro 達到 56.26%，DeepSearchQA F1 達到 92.82%，HLE w/tools 達到 47.2，並在 Terminal-Bench、Toolathlon、ClawEval 和其他代理程式/工具使用任務上，相較於 Step 3.5 Flash 有大幅提升。
模型成品可在 Hugging Face 上以 BF16、FP8、NVFP4 和 GGUF 格式取得，並在發布當天即獲得 llama.cpp 支援的 PR，以及 llama.cpp#23274 中相關的 MTP 工作。評論者認為該模型在技術上有些奇特：其隱藏/思考追蹤被描述為幾乎不連貫，但最終答案卻能「完美」且與大得多（超過 1TB）的模型競爭；一位用戶表示，先前 Step 3.5 的「無限思考」問題似乎已修復。
對於本地部署，尤其是有 4x3090 級別硬體的用戶，存在謹慎的熱情，並且讚賞 StepFun 將 llama.cpp 支援上游化，而非僅維護一個分支。StepFun 在 Hugging Face 上發布了多個 Step-3.7-Flash 檢查點：BF16 (Step-3.7-Flash)、FP8 (Step-3.7-Flash-FP8)、NVFP4 (Step-3.7-Flash-NVFP4) 和 GGUF (Step-3.7-Flash-GGUF)。
一位用戶報告，先前 Step 3.5 Flash 的「無限思考」問題似乎已修復，使得 3.7 儘管仍具有奇特的內部推理風格，但更具可用性。透過 StepFun 的上游 PR (ggml-org/llama.cpp#23845)，實現了發布當天即支援 llama.cpp，這與 Step 3.5 基於分支的支援形成對比。
另一個用於 MTP 支援的社群 PR 存在於 ggml-org/llama.cpp#23274，儘管評論者指出它需要針對 Step 3.7 和當前主分支進行更新。vLLM 對 NVFP4 檢查點在 2x Pro 6k 上進行的夜間測試，在 64 個並行淺上下文請求下，達到了約 2200 詞元/秒。
報告的配置使用了張量平行大小 2、--enable-expert-parallel、--quantization modelopt、--kv-cache-dtype fp8、--reasoning-parser step3p5 和 StepFun 工具呼叫解析；vLLM 報告 GPU 鍵值快取大小為 1,667,645 詞元，對於每個請求 262,144 詞元，最大並行數為 6.36 倍。
