在網路上查看此文章:https://www.latent.space/p/ainews-openai-codex-app-death-of
2026年1月30日至2月2日的AI新聞。我們檢查了12個subreddit、544個Twitter和24個Discord(254個頻道,14979則訊息)。預估節省的閱讀時間(以每分鐘200字計算):1408分鐘。AINews的網站讓你搜尋所有過去的期刊。提醒一下,AINews現在是Latent Space的一個專欄。你可以選擇加入/退出電子郵件頻率!
我們幾乎沒有把OpenAI作為今天的頭條故事 —— 畢竟,這「只是」一個已經存在的CLI、Cloud應用程式和VS Code擴充套件的桌面應用程式UI……而且這「只是」OpenAI版本的Conductor和Codex Monitor以及Antigravity的Inbox(實際上是用完全相同的「AI代理指揮中心」標語推出的):
一切都是螃蟹,但也許螃蟹就是完美的形態。
然而。
在12月,Steve Yegge和Gene Kim預測IDE將會消亡:
而我們現在來到2026年,OpenAI曾經為Windsurf出價30億美元,現在正在推出一個不是VS Code分支的編碼代理UX,順便說一下,Anthropic也用他們的Claude Code和Claude Cowork應用程式做了同樣的事情。值得思考的是,編碼模型已經發展到什麼程度,嚴肅的編碼應用程式在沒有IDE的情況下推出(是的,Codex仍然允許你在需要時連結到IDE,但顯然這是例外而不是常態)。
曾經有一段時間,「讓你用英語編寫並在不查看程式碼的情況下建構的應用程式」等同於「氛圍編碼」或「應用程式建構器」,但這些非技術受眾不是Codex的ICP —— 這是非常認真地針對開發者進行行銷的,而開發者歷史上熱愛程式碼並強烈認同手寫每一行程式碼。
現在OpenAI說:查看程式碼有點可選。
另一個觀察是對多工和worktree的依賴:事後看來,這是對代理自主性增加的完美自然UI響應:
最後,Codex推出的實際上是最被忽視的新穎之處是Automations,基本上是「在cronjob上的技能」 —— 不知何故OpenAI是第一個在GA中推出這個非常簡單功能的主要玩家:
AI Twitter回顧
OpenAI的Codex應用程式:代理原生的編碼「指揮中心」
Codex應用程式在macOS上推出(Windows「即將推出」):OpenAI推出了專用的Codex桌面應用程式,定位為運行多個平行代理的專注UI,通過內建worktrees保持變更隔離,並通過技能和計劃自動化擴展行為(OpenAI公告、速率限制和可用性詳細資訊、OpenAIDevs功能介紹)。反覆出現的主題:介面(不只是模型)正在成為產品。
重要的開發者工作流程細節:該應用程式強調(a)每個任務/PR的worktree作為平行性和衝突隔離的基元;(b)計劃模式(/plan)強制前期分解和提問;(c)技能作為可重用的套件,可以連接到外部服務(Figma/Linear/Vercel等);以及(d)重複背景工作的自動化(@reach_vb、計劃模式、技能登陸頁面)。
使用訊號/採用敘事:多個內部人士(和超級使用者)聲稱該應用程式對於大型倉庫和長時間運行的任務來說是比CLI/IDE擴充套件更進一步的 —— 特別是在管理平行執行緒和可審查的差異方面。值得注意的推薦包括@gdb(代理原生介面;「回到終端機感覺就像回到過去」)、@sama(驚訝於他有多喜歡它)和@skirano(在他們的工作流程中取代Cursor + Claude Code)。
生態系統壓力/標準化:已經有推動標準化「技能」資料夾的努力:建議讓Codex從.agents/skills讀取並棄用.codex/skills(@embirico)。這是代理工具正在開始形成類似於.github/、pyproject.toml等慣例的早期證據。
元點:通過產品循環「自我改進」:幾個貼文強調Codex被用來建構自己 —— 這被呈現為最令人信服的「遞迴改進」故事,實際上是作為產品反饋循環(人類+代理)而不是自主AGI(OpenAIDevs、@ajambrosino、@thsottiaux)推出。
實踐中的編碼代理:可靠性、測試、平行性,以及「代理軍隊」迷因變成現實
CLAUDE.md/AGENTS.md的具體最佳實踐:添加「測試優先」指令:當報告錯誤時,首先編寫一個重現測試;然後修復;然後通過通過的測試證明 —— 被框架為代理性能和理智的最大單一改進(@nbaschez)。這與更廣泛的主題一致,即編碼是一個高槓桿領域,因為它是部分可驗證的。
工程的「指揮」模型:聲稱一個開發者可以平行運行5-10個代理,運送他們沒有完全閱讀的程式碼,從作者轉變為監督者/指揮(@Yuchenj_UW)。一個相關的反面觀點警告說,如果你試圖「平行運行無數件事情」,人類上下文切換限制和品質下降(@badlogicgames)。
編碼代理為何有效的神經符號框架:一個清晰的論點,即編碼代理成功是因為軟體是一個可驗證的領域,並且因為執行/工具(測試、編譯器、shell)形成了LLM可以利用的符號支架;在編碼之外複製這一點需要建構可比的「符號工具箱」+可驗證性(@random_walker)。
基準懷疑論:對輕量級「LLM生產力」研究的反駁,參與者使用弱工作流程(例如,聊天側邊欄使用)而不是代理設置;批評結果低估了工具快速發展時的生產力收益(@papayathreesome、@scaling01)。
開源代理堆疊和安全/運營問題:OpenClaw/Moltbook生態系統產生了興奮和運營/安全批評 —— 例如,討論代理前面的網關用於會話管理/政策執行(@salman_paracha),以及警告「僅AI社交媒體」立即被機器人/垃圾郵件(@jxmnop)。潛台詞:代理產品需要與消費者平台相同的濫用抗性/可觀察性成熟度 —— 立即。
代理編碼的開源模型:StepFun Step-3.5-Flash和Kimi K2.5作為本週的焦點
StepFun Step-3.5-Flash開源發布(大效率聲明):StepFun的Step-3.5-Flash被反覆引用為具有196B總參數/約11B活躍的稀疏MoE模型,針對速度+長上下文代理工作流程進行調整(特別是256K上下文,具有3:1滑動窗口注意力+完全注意力,加上MTP-3多令牌預測)(官方發布串、啟動/連結)。StepFun報告74.4%的SWE-bench Verified和51.0%的Terminal-Bench 2.0(StepFun)。
即時基礎設施支援:vLLM推出了第0天支援和部署配方,表明StepFun在實際服務堆疊採用方面的嚴肅性(vLLM)。
社區評估姿態:多個貼文強調「需要盡快測試」並注意到基準挑選問題;人們想要標準化基準(MMLU/HLE/ARC-AGI)和第三方驗證,特別是隨著HF排行榜的變化(@teortaxesTex、@QuixiAI)。
Kimi K2.5的代理編碼實力:Arena報告Kimi K2.5在Code Arena中排名第一的開源模型和總體第五,與一些頂級專有產品「持平」,並且在Text/Vision/Code Arena中也很強(Arena公告)。單獨的軼事注意到在某些工作流程中工具追蹤弱點(系統提示遵守)(@QuixiAI)。
提供商可靠性問題:工具調用/解析失敗可能使模型看起來比實際更差;Teknium指出FireworksAI的Kimi端點工具解析損壞,迫使工作流程禁止 —— 一個運營提醒,即生產中的「模型品質」通常會崩潰為整合正確性(@Teknium、早期警告)。
合成數據、評估和「不要相信困惑度」
合成預訓練深度探討:Dori Alexander發布了一篇關於合成預訓練的長部落格文章,暗示對合成數據管道及其失敗模式(例如,崩潰、分佈漂移)的重新關注(推文)。這與更廣泛的討論相結合,即「合成數據模式崩潰」的恐懼曾經占主導地位 —— 現在越來越被視為工程/配方問題(@HaoliYin)。
困惑度作為模型選擇陷阱:幾條推文指出新興證據表明困惑度不應被盲目信任為選擇目標(@DamienTeney、@giffmana)。實際要點:如果你只針對下一個令牌預測指標進行優化,你可能會錯過下游任務行為、工具使用穩定性和指令遵循一致性。
從網際網路獲得無限的RLVR任務(「金鵝」):一種方法,通過遮罩推理步驟和生成干擾項從不可驗證的網路文本合成基本上無限的RLVR風格任務;聲稱包括復興在現有RLVR數據上「飽和」的模型,並在網路安全任務中取得強勁結果(@iScienceLuvr、論文參考)。
壓縮+長上下文基礎設施想法:討論文檔/上下文壓縮方法(例如,「Cartridges」、gist令牌、KV快取壓縮變體)以減少記憶體佔用和加速生成 —— 與代理上下文膨脹到數十萬或數百萬令牌相關(@gabriberton、參考)。
代理系統和基礎設施:記憶體牆、可觀察性,以及RAG分塊變得依賴查詢
推理瓶頸從FLOP轉移到記憶體容量:一個長串總結了帝國理工學院+微軟研究院的論點,即對於代理工作負載(編碼/計算機使用),綁定約束是記憶體容量/ KV快取佔用,而不僅僅是計算。例子:批次大小1,具有1M上下文,單個DeepSeek-R1請求可能需要約900GB記憶體;建議用於預填充與解碼的分解服務和異構加速器(@dair_ai)。
可觀察性成為代理的「堆疊追蹤」:LangChain強調代理在不崩潰的情況下失敗;追蹤是主要的除錯工件,激發了關於代理可觀察性+評估的網路研討會和工具(@hwchase17)。
RAG分塊:oracle實驗顯示20-40%的召回收益:AI21報告了oracle為每個查詢選擇分塊大小的實驗;這比任何固定分塊大小高出20-40%的召回率,但需要儲存多個索引粒度(儲存與品質權衡)(@YuvalinTheDeep、串上下文)。
打包「深度代理」架構模式:LangChain JS引入深度代理,聲稱四種重複出現的架構模式解釋了為什麼像Claude Code/Manus這樣的系統感覺強大,而天真的工具調用代理失敗(LangChain_JS)。
熱門推文(按互動)
Karpathy關於回歸RSS以逃避激勵驅動的垃圾內容:與工程師「訊號品質」相關的高互動元評論(推文)。
OpenAI Codex應用程式推出:這組中參與度最大的AI工程發布(OpenAI、OpenAIDevs、@sama)。
AI Reddit回顧
/r/LocalLlama + /r/localLLM回顧
1. Step-3.5-Flash模型性能
128GB設備有了新的本地LLM之王:Step-3.5-Flash-int4(活動:385):Step-3.5-Flash-int4模型,可在Hugging Face上獲得,是一個針對具有128GB RAM的設備(如M1 Ultra Mac Studio)優化的新本地LLM。它支援完整的256k上下文長度,並在RAM使用方面表現出高效率。使用llama-bench的基準測試顯示了令人印象深刻的性能,預填充高達100k,pp512測試達到281.09±1.57 t/s,tg128測試達到34.70±0.01 t/s。該模型需要自定義llama.cpp分支才能執行,由於其性能,有可能獲得上游支援。評論者對該模型在不同硬體(如Strix Halo)上的性能感到好奇,並對潛在的NVFP4版本表示興趣。也有一條幽默的評論,反映了對模型能力的驚訝。
Step-3.5-Flash-int4模型以其在128GB設備上運行完整256k上下文的能力而聞名,這是令人印象深刻的,因為許多模型是記憶體密集型的,無法處理如此大的上下文。這使它成為GLM 4.7等以高RAM使用而聞名的模型的強大競爭對手。
一位使用者將Step-3.5-Flash-int4與Minimax M2.1進行了比較,暗示它可能表現稍好。這個比較很重要,因為Minimax M2.1是一個備受推崇的模型,性能或效率的任何改進對於尋求高品質輸出而沒有過多資源消耗的使用者來說都可能是一個主要優勢。
與Minimax相比,人們對Step-3.5-Flash-int4的回應速度感興趣,Minimax因快速迭代而受到青睞。如果Step-3.5-Flash-int4提供了改進的效率和品質,它可能會取代Minimax,成為需要快速處理和高品質結果的任務的首選模型。
Step-3.5-Flash(196b/A11b)優於GLM-4.7和DeepSeek v3.2(活動:640):Stepfun新發布的Step-3.5-Flash模型在各種編碼和代理基準上表現優於DeepSeek v3.2,儘管參數少得多。具體來說,Step-3.5-Flash使用196B總參數,其中11B活躍,而DeepSeek v3.2使用671B總參數,其中37B活躍參數。該模型可在Hugging Face上獲得。評論者注意到該模型在其大小下的意外性能,與Kimi K2.5和Deepseek 3.2 Speciale等其他模型相比表現良好。還有一個開放的拉取請求,用於將此模型與llama.cpp整合,表明社區的積極興趣和開發。
儘管Step-3.5-Flash模型體積小且速度快,但據報導它優於GLM-4.7和DeepSeek v3.2等更大的模型。一位使用者指出,它的表現與Kimi K2.5相當,甚至與Deepseek 3.2 Speciale或Gemini 3.0 Flash的能力相匹配,表明它的高效率和能力,儘管被「基準最大化」。
已經開放了一個拉取請求,用於將Step-3.5-Flash整合到llama.cpp中,這是其採用和在各種應用程式中使用的重要一步。該模型比MiniMax和Qwen3-235B等其他模型小,使其成為開發者可用的緊湊模型範圍的寶貴補充。拉取請求的連結在這裡。
2. GLM-5和即將推出的AI發布
GLM-5將於2月推出!已經確認。(活動:757):該圖像是一個社交媒體貼文,突出顯示了2026年2月預期的AI技術發布,包括DeepSeek V4、阿里巴巴Qwen 3.5和GPT-5.3。一位名叫jietang的使用者將「glm-5」添加到列表中,暗示其發布也是預期的。這表明AI進步的重要時期,來自領先AI開發者的多個主要更新。該貼文引起了關注,反映了社區對這些發展的興趣。一條評論幽默地注意到AI模型的快速過時,而另一條評論則推測GLM-5的潛在功能,表明對其能力的期待和好奇。
bootlickaaa表達了希望GLM-5超越Kimi K2.5的願望,表明基於性能指標的使用者偏好可能發生轉變。這表明使用者正在密切監控不同模型的能力,如果新模型提供優越的性能,他們願意切換服務。提到年度Z.ai Pro計劃意味著對可能被更先進模型中斷的服務的承諾。
International-Try467對有關GLM-5的資訊可靠性提出了擔憂,質疑與GLM員工無關的來源的可信度。這突出了官方溝通管道和經過驗證的資訊在技術社區中的重要性,特別是在新模型發布公告方面。
Septerium幽默地注意到他們的gguf檔案的快速過時,這突顯了AI模型開發的快節奏性質以及跟上最新進展所需的頻繁更新。這反映了該領域更廣泛的挑戰,使用者必須不斷更新他們的資源以利用新功能。
Mistral Vibe 2.0(活動:387):Mistral AI發布了Mistral Vibe 2.0,這是其終端原生編碼代理的增強版本,利用Devstral 2模型系列。此更新引入了自訂子代理用於任務專業化、多選澄清以最小化歧義以及斜槓命令技能以簡化工作流程等功能。它還支援統一代理模式以實現無縫上下文切換。該服務整合到Le Chat Pro和Team計劃中,過渡到Devstral 2的付費API模型,並提供企業選項用於微調和程式碼現代化等高級功能。更多詳細資訊可以在這裡找到。評論者注意到Mistral Vibe 2.0的歐洲起源,強調其法國開發。有與OpenCode的比較,暗示兩種工具都模仿ClaudeCode,一位使用者提到通過在~/.vibe/promps/cli.md檔案中配置工具列表來改進工具性能。
一位使用者強調Mistral Vibe 2.0程式碼庫的緊湊性,注意到它只有19472行程式碼,而Codex或OpenCode等替代方案通常超過100k行。這表明對程式碼品質和效率的關注,可能使其更容易維護和理解。
另一位使用者提到了Mistral Vibe 2.0的配置提示,建議當工具列表明確添加到~/.vibe/promps/cli.md檔案時,工具調用效果更好。這意味著適當的配置可以增強工具的功能和使用者體驗。
一條評論提出了Mistral Vibe 2.0是否可以在本地和離線運行的問題,這是關注隱私、性能或網際網路依賴的使用者的常見考慮。
3. Falcon-H1-Tiny和專業微型模型
Falcon-H1-Tiny(90M)推出 - 實際有效的專業微型模型(活動:357):Falcon-H1-Tiny是TII推出的一系列小於100M參數的模型,通過在專業任務中展示有效性能來挑戰傳統的規模範式。這些模型使用反課程訓練方法,從一開始就注入目標領域數據,即使在大量訓練後也能防止過度擬合。它們結合了混合Mamba+Attention塊和Muon優化器,與AdamW相比實現了高達20%的性能收益。值得注意的是,一個90M工具調用者模型達到94.44%的相關性檢測,一個600M推理模型解決了75%的AIME24問題,與更大的模型相匹敵。這些模型針對本地部署進行了優化,在手機和Raspberry Pi等設備上高效運行。評論者注意到使用Muon優化器,也稱為Kimi優化器,並對這些模型專注於有效提取和利用知識的潛力表示興趣。人們對訓練類似模型用於自訂任務的程式碼和數據集預覽的可用性感到好奇。
Firepal64提到在Falcon-H1-Tiny模型中使用了Kimi優化器,稱為Muon。這個優化器沒有被廣泛採用,這引起了對其獨特好處或性能特徵的好奇,這些特徵可能使其適合像Falcon-H1-Tiny這樣的專業微型模型。
kulchacop和Available-Craft-5795詢問Falcon-H1-Tiny的程式碼、數據集預覽和訓練管道的可用性。他們有興趣了解訓練過程和數據收集方法,可能是為了將模型適應到他們自己的任務或複製結果。
mr_Owner注意到Falcon-H1-Tiny模型在使用llama.cpp時性能比預期慢,暗示此特定實現存在潛在的低效率或兼容性問題。這可能是進一步優化或調查的領域。
4chan數據真的可以改進模型嗎?結果可以!(活動:606):在擴展的4chan數據集上訓練的Assistant_Pepe_8B的發布,令人驚訝地優於其基礎模型nvidia的nemotron。儘管該模型是在預期為嘈雜數據集上訓練的,但它的得分比基礎和消除基礎都高,挑戰了微調會犧牲一些智慧以實現特異性的典型預期。該模型的性能與Yannic Kilcher的gpt4chan早期成功相呼應,後者在真實性方面也得分很高。結果表明,所謂的「對齊稅」可能具有非平凡的影響,正如Impish_LLAMA_4B模型中的低KL散度(<0.01)所證明的,該模型也顯示了政治對齊的轉變。
語言模型中4chan數據的使用因其對語言統計和語義的獨特影響而受到強調,特別是在增強模型生成正確英語語言結構的能力方面。與Reddit或Wikipedia等其他數據來源不同,4chan數據顯著增加了模型對「我」陳述的使用,暗示更自我參與或自我中心的輸出,這對於助手風格的聊天機器人可能不理想。這與Twitter數據形成對比,後者被注意到會迅速降低模型性能。
關於使用不同聊天模板和數據來源影響的技術討論揭示,ChatML和消除的組合可以顯著改變模型的行為和政治對齊。儘管預期聊天模板的影響最小,但觀察到的變化是實質性的,KL散度表明從古典自由主義轉向中間主義,暗示模型世界觀的深刻改變。
關於對齊稅的評論表明,較小的模型在整合不同數據來源時可能面臨更大的挑戰以保持對齊。這意味著模型的複雜性和大小可能會影響它如何整合和平衡各種數據輸入,可能會影響其性能和偏見。
較不技術性的AI Subreddit回顧
/r/Singularity、/r/Oobabooga、/r/MachineLearning、/r/OpenAI、/r/ClaudeAI、/r/StableDiffusion、/r/ChatGPT、/r/ChatGPTCoding、/r/aivideo、/r/aivideo
1. Claude Sonnet 5發布和功能
Sonnet 5下週?(活動:695):該圖像描繪了一個HTTP 404錯誤訊息,表明未找到「claude-sonnet-5」的「發布者模型」,暗示要麼是不存在的模型,要麼是缺乏訪問權限。這與該貼文關於預期Sonnet 5發布的討論一致,預計將提供100萬上下文,價格是Opus 4.5的1/2,並在TPU上訓練,承諾在代理編碼方面有顯著改進。錯誤訊息可能意味著該模型尚未公開可用或可訪問,暗示其即將發布。評論者對Sonnet 5的潛力表示興奮,注意到它可能超越Opus 4.5等現有模型。還有關於GPT 5.3和Gemini 3等其他模型即將發布的猜測,表明競爭格局。
討論強調了Sonnet 5作為「競爭殺手」的潛力,暗示它可能顯著優於Opus 4.5等現有模型。這表明AI社區對Sonnet 5能力的高度期待和期望。
有關於即將推出的模型訓練基礎設施的猜測,重點是Google的TPU。提到Gemini 3完全在沒有Nvidia硬體的情況下訓練,暗示了向TPU的戰略轉變,這可能對AI模型訓練的性能和成本效率產生影響。
關於Anthropic產品「乾淨」和「精緻」性質的評論暗示了對使用者體驗和產品精煉的關注,這可能是AI市場的競爭優勢。這突顯了不僅性能的重要性,還有AI產品的可用性和整合。
Sonnet 5於2月3日發布(活動:1979):Claude Sonnet 5,代號「Fennec」,據報導將於2026年2月3日發布,如Vertex AI錯誤日誌所示。據傳它比其前身Claude Opus 4.5便宜50%,同時保持1M令牌上下文窗口並提供更快的性能。據稱該模型在Google TPU上進行了優化,增強了吞吐量並降低了延遲。它引入了「Dev Team」模式,允許自主子代理協作建構功能。內部洩漏表明它在SWE-Bench上得分80.9%,超過當前的編碼模型。然而,對於發布日期和錯誤日誌作為模型存在證明的有效性存在一些懷疑。評論者對發布日期表示懷疑,注意到Anthropic的模型ID通常反映創建日期而不是發布日期。還有人擔心大上下文窗口中的準確性下降,這在以前的模型中是一個問題。
andrew_kirfman討論了對Sonnet 5發布時間的懷疑,引用了Vertex API端點的404錯誤,該錯誤並不能確認模型的存在。他們強調Anthropic的模型ID通常反映模型檢查點的創建日期,而不是發布日期,並引用Opus 4.5的ID作為例子。他們對未來日期發布標籤表示懷疑,這在軟體發布中並不常見。
andrew_kirfman還提到Sonnet 5中100萬令牌上下文的潛力,注意到Sonnet 4和4.5等以前的模型已經通過API提供了這一點。然而,他們指出準確性下降是這些模型的一個問題,暗示在這個領域的改進對於對新模型的信任是必要的。
LuckyPrior4374對聲稱Sonnet 5優於以前的模型(特別是提到Opus 4.5)的說法表示懷疑。這條評論意味著對行銷聲稱表示顯著改進但沒有實質性證據的不信任,暗示過去的經驗中期望沒有得到滿足。
Sonnet 5將於週三發布,Gemini 3.5在哪裡?(活動:165):Claude Sonnet 5,代號「Fennec」,據傳是比現有模型(包括未發布的Gemini 3.5)更重要的進步。預計它將比Claude Opus 4.5便宜50%,同時保持1M令牌上下文窗口並提供更快的性能。據報導,該模型在Google TPU上進行了優化,這增強了吞吐量並降低了延遲。它具有「Dev Team」模式,允許自主子代理平行執行任務,並在SWE-Bench上取得了80.9%的得分,超過當前的編碼模型。Vertex AI錯誤日誌暗示2026年2月3日的發布窗口,表明它存在於Google的基礎設施中。評論者對Gemini 3.5的發布表示懷疑,注意到Gemini 3仍處於預覽狀態並面臨問題。有人懷疑Gemini 3.5的存在,有些人認為它是「白日夢」。
alexander_chapel指出Gemini 3仍處於預覽狀態,質疑對3.5發布的期望。這突顯了Gemini 3的當前狀態,尚未完全發布,暗示任何關於3.5版本的討論可能為時過早或基於謠言。
Lost-Estate3401提到Gemini 3的Pro版本仍處於預覽狀態並有許多問題,表明3.5版本在這個階段可能不切實際。這條評論強調了當前版本面臨的挑戰,這可能會延遲進一步的更新或增強。
philiposull將Gemini 3與4-5 opus等其他模型在寫作能力方面進行了不利比較,暗示Google在這個領域落後。這個比較突顯了潛在的性能差距和AI模型開發中的競爭格局。
2. 創新AI模型和工具推出
MIT的新熱動力矽晶片在數學計算中達到99%的準確性(活動:521):MIT研究人員開發了一種新型矽晶片,利用廢熱進行計算,在數學計算中達到超過99%的準確性。該晶片利用溫差作為數據,熱量自然從熱區域流向冷區域以執行計算,特別是矩陣向量乘法,這在AI和機器學習中至關重要。晶片的結構由特殊工程的多孔矽製成,其內部幾何形狀經過演算法設計,以沿精確路徑引導熱量。雖然還不能取代傳統CPU,但這項技術可以顯著減少未來晶片的能量損失和冷卻需求,在熱感應和低功耗操作中具有潛在應用。評論者注意到,雖然99%的準確性令人印象深刻,但對於現代應用中的數萬億次操作可能還不夠,他們希望有錯誤校正機制。鑑於目前2x2和3x3的矩陣大小,人們對該技術的可擴展性也持懷疑態度。
ReasonablyBadass強調了對MIT熱動力矽晶片99%準確性的批判性觀點,注意到雖然99%看起來很高,但對於需要數萬億次操作的現代應用可能還不夠。評論暗示晶片目前處理小矩陣,如2x2和3x3,表明更廣泛的適用性仍需要顯著進展。
Putrumpador對需要與新晶片99%準確性結合的錯誤校正機制提出了擔憂。這意味著雖然晶片是創新的,但它們在關鍵系統中的實際部署需要額外的可靠性層來處理潛在的不準確性。
BuildwithVignesh引用了發表在Physical Review上的研究,提供了論文的連結,這對於那些對研究技術細節感興趣的人來說可能很有價值。這表明研究是經過同行評審的,可以進一步進行學術審查。
上海科學家創造出比人類頭髮還細的纖維中的電腦晶片,但可以承受15.6噸的壓碎力(活動:994):復旦大學的科學家開發了一種靈活的纖維晶片,像人類頭髮一樣細,可以承受15.6噸的壓碎力。這種纖維晶片每厘米整合多達100,000個電晶體,具有獨特的「壽司卷」設計,涉及將薄電路層滾動到彈性基板上以最大化空間。該晶片高度耐用,經受10,000次彎曲循環,拉伸30%,溫度高達100°C。它旨在應用於智慧紡織品、腦機介面和VR手套。該研究於2026年1月發表在Nature上。圖像。評論突顯了纖維寬度描述中的潛在錯誤,暗示它比所述寬10倍。還有人對一米長線具有與經典CPU相當的處理能力的說法持懷疑態度,注意到潛在的延遲問題。
KidKilobyte指出報導尺寸中的潛在錯誤,注意到人類頭髮通常為50至100微米寬,暗示晶片纖維可能被不準確地描述為比人類頭髮細。這引發了對原始報告中提供的測量或描述精度的質疑。
Practical-Hand203強調了一米長纖維線具有與經典CPU相當的處理能力的說法的潛在問題。他們建議,如果處理器晶粒拉伸超過一米,它可能會遭受嚴重的延遲問題,表明對技術能力的誤解或過度簡化。
BuildwithVignesh引用了該研究在Nature雜誌上的發表,提供了文章的連結。這表明研究已經過同行評審,這為研究結果增加了可信度,儘管評論中沒有討論研究的技術細節和影響。
[P] PerpetualBooster v1.1.2:沒有超參數調整的GBM,現在使用ONNX/XGBoost支援速度提高2倍(活動:39):PerpetualBooster v1.1.2對其在Rust中實現的梯度提升機(GBM)進行了重大增強,專注於通過單個「預算」參數消除超參數調整。更新誇耀了高達2倍的訓練速度、完整的R發布、ONNX支援以及原生「另存為XGBoost」以提高互操作性。它還包括零拷貝Polars支援以實現高效的數據處理,並保證API穩定性,向後兼容v0.10.0。基準測試表明,與LightGBM + Optuna相比,牆上時間加速100倍,在單次運行中達到類似的準確性。GitHub使用者欣賞速度改進和使用單個「預算」參數而不是傳統超參數調整的新穎方法,儘管有些人發現適應這種新方法很不尋常。
Alternative-Theme885強調了PerpetualBooster的顯著速度改進,注意到不需要手動調整超參數的不尋常體驗。相反,使用者設定一個預算,工具使用它來優化性能,與傳統方法相比簡化了流程。
whimpirical詢問PerpetualBooster與SHAP的互操作性,SHAP是一種流行的機器學習模型解釋工具。他們特別對提取特徵貢獻和生成部分依賴圖(PDP)相關的文檔感興趣,這對於理解模型行為和特徵影響至關重要。
3. 專業和研究環境中的AI
[D] MSR Cambridge與Amazon Applied Science實習,想法?(活動:118):該貼文討論了一位博士生在兩個實習機會之間的決定:一個在微軟研究院(MSR)劍橋,另一個在美國的Amazon Applied Science。MSR劍橋職位與學生的博士研究有很強的一致性,並有發表的潛力,但與美國職位相比薪酬明顯較低。Amazon角色提供更高的薪酬,如果專案是研究導向的,可能為論文做出貢獻。學生正在考慮美國網路的影響與MSR劍橋的聲望和研究契合度,特別是考慮到他們在博士後在美國工作的長期目標。評論者壓倒性地支持MSR劍橋實習,引用其聲望和研究機會作為職業增強。他們對Amazon的工作環境表示懷疑,暗示它可能不像純研究那樣有利。
微軟研究院(MSR)劍橋被強調為一個著名的研究小組,以其對研究人員職業軌跡的重大影響而聞名。重點是與像MSR這樣的知名機構相關聯的長期好處,這可以增強一個人的履歷,並為學術界和工業界開啟未來的機會。
討論表明Amazon的Applied Scientist角色可能不像MSR那樣以研究為重點,一些評論暗示Amazon的工作環境對於尋求以研究為導向的職業的人來說可能並不理想。術語「PIP工廠」被用來描述Amazon,表明一個可能是高壓的環境,有績效改進計劃。
幾條評論強調了在選擇實習時專注於職業建設機會而不是即時薪酬的重要性。共識是,早期職業決策應該優先考慮履歷建設和在像MSR這樣的知名機構獲得經驗,這可以帶來更好的長期職業前景。
我們對自主OpenClaw代理進行了實時紅隊與藍隊測試[R](活動:44):在最近使用OpenClaw自主代理進行的對抗性安全測試中,紅隊攻擊者和藍隊防禦者在沒有人為干預的情況下相互對抗。攻擊者最初使用社交工程戰術,在安全管道中嵌入遠端程式碼執行載荷,防禦者成功阻止了。然而,攻擊者通過在JSON文檔的元數據中嵌入shell擴展變數進行間接攻擊成功,突顯了防禦間接執行路徑的困難。此練習旨在識別代理間互動中的真實失敗模式,而不是聲稱安全。有關更多詳細資訊,請參閱完整報告。評論者注意到,類似的攻擊場景早在2019年就由Eliezer Yudkowsky和Scott Alexander等人物理論化,但實際應用現在與廣泛使用更相關。另一位評論者強調了OpenClaw中記憶體注入攻擊的風險,暗示持久記憶體檔案是一個重大漏洞,並主張從一開始就將部署視為提示注入目標。
JWPapi強調了OpenClaw代理中與記憶體注入相關的關鍵安全漏洞。OpenClaw使用的持久記憶體檔案(.md)被識別為一個重要的攻擊向量,因為一旦受到損害,它們可以影響所有未來的代理行為。JWPapi建議從一開始就將整個部署視為提示注入目標,主張隔離憑證、支出上限以及每個整合的單獨爆炸半徑以降低風險。更多詳細資訊在他們關於實際VPS部署的文章中討論。
sdfgeoff引用了2019年和2020年Eliezer Yudkowsky和Scott Alexander等人物的歷史討論,他們在GPT-2發布後不久就理論化了AI攻擊。這些早期討論預測了現在在實際場景中測試的許多攻擊向量,突顯了從理論到實際應用的轉變,隨著更多人部署這些系統。這個歷史背景強調了隨著部署規模增加,AI安全問題的演變。
Uditakhourii提供了OpenClaw代理實時紅隊與藍隊測試完整報告的連結,該報告提供了對對抗性AI互動的詳細見解。該報告可在此處獲得,可能包含全面的數據和分析,對於對AI安全測試技術方面感興趣的人很有用。
波士頓諮詢集團(BCG)宣布為其全球32,000名顧問內部部署超過36,000個自訂GPT。(活動:70):波士頓諮詢集團(BCG)為其32,000名顧問部署了超過36,000個自訂GPT,強調AI作為知識工作中的基礎設施。這些GPT是角色特定的,根據內部方法訓練,並具有專案記憶,使它們能夠跨團隊共享。這種方法與許多以孤立、不可擴展方式使用AI的組織形成對比。BCG的策略專注於創建、管理和擴展自訂GPT,由GPT Generator Premium等工具促進,支援這些AI代理的創建和管理。部署反映了向AI作為業務運營基本組成部分的轉變,而不僅僅是一個工具。評論強調了對GPT價值的懷疑,質疑它們創新的能力以及依賴這種大規模AI部署的商業模式的可持續性。擔憂包括GPT提供「罐頭答案」的潛力以及對諮詢費用的影響。
AI Discord回顧
由gpt-5.2提供的摘要的摘要
1. 代理編碼和開發工具走向本地優先
Codex走向桌面:macOS代理指揮中心:OpenAI為macOS推出了Codex應用程式作為代理建構指揮中心,可供Plus/Pro/Business/Enterprise/Edu使用,ChatGPT Free/Go可限時訪問,根據「介紹Codex應用程式」和Codex登陸頁面。
推出還溢出到社區工作流程討論(配對代理、多代理「指揮中心」),以及通過Cerebral Valley的活動頁面出現的相關Codex App駭客松,獎金為90,000美元的積分。
LM Studio說Anthropic:Claude Code遇見你的本地GGUF/MLX:LM Studio 0.4.1添加了Anthropic /v1/messages兼容性API,讓開發者通過更改基本URL將Claude Code風格的工具指向本地GGUF/MLX模型,詳見「使用LM Studio的Claude Code」。
同時,LM Studio還推出了用於第三方外掛的TypeScript SDK和OpenAI兼容端點(SDK連結),加強了一個不斷增長的模式:重用現有代理工具,同時在本地交換後端模型堆疊。
無處不在的Arena模式:Windsurf將模型評估變成遊戲:Windsurf推出Wave 14,帶有Arena模式用於並排模型對戰(包括Battle Groups和「選擇你自己的」),並通過Windsurf下載頁面暫時將Battle Groups設定為0x積分。
這反映了更廣泛的「實時評估」動力:使用者還在LMArena的Text Arena和Code Arena上追蹤新的Arena參與者,如step-3.5-flash和qwen3-max-thinking,將選擇從靜態基準轉移到持續的人類投票。
2. 模型發布和基準競賽(Kimi vs GLM vs Qwen)
Kimi K2.5速通排行榜:Moonshot的Kimi K2.5廣泛登陸產品表面:Perplexity Pro/Max為訂閱者添加了它,並表示它在美國的推理堆疊上運行,以實現更緊密的延遲/可靠性/安全控制(公告截圖:https://cdn.discordapp.com/attachments/1047204950763122820/1466893776105771029/20260130_203015.jpg)。
社區結果堆積:LMArena報告Kimi-K2.5-thinking在Code Arena中排名第一開源和總體第五(參見Code Arena),而多個開發頻道爭論其工具調用可靠性和提供商差異,當通過聚合器路由時。
GLM-4.7 Flash:小模型,大前端能量:開發者強調GLM-4.7 flash作為一個令人驚訝的強大編碼模型 —— 特別是對於互動式網站/前端工作 —— 引用保留的推理和交錯能力,討論錨定在ggerganov的貼文上。
辯論圍繞剝離「思考」是否會損害性能而加劇,幾個使用者描述將GLM-4.7與Claude Code(或類似Claude的代理工具)配對作為一個務實的混合堆疊:便宜的執行+昂貴的審查。
新Arena參與者:step-3.5-flash和qwen3-max-thinking加入派對:LMArena將step-3.5-flash添加到Text Arena,將qwen3-max-thinking添加到Code Arena,明確將它們定位為並排評估的新基準。
使用者使用這些下降來重新訴訟「模型偏好」串(Kimi vs GLM vs Gemini),反覆出現的要點是排行榜和實時評估越來越多地推動採用,而不是供應商行銷。
3. 訓練訊號、密集獎勵以及新架構/數據集
從二元獎勵到密集監督:RL變得囉嗦:多個社區匯聚於更豐富的訓練後訊號:Unsloth討論推動使用最終答案的logprobs和非二元獎勵進行訓練,引用Jonas Hübotter將描述性反饋轉化為密集監督的方法(Hübotter串)。
實際問題仍然存在:人們要求用於RL訓練代理編碼的可驗證數據集,暗示「酷獎勵塑造想法」和「可重現的自動化評估工具」之間的管道差距。
Complexity-Deep:令牌路由MLP嘗試沒有負載平衡頭痛的MoE:Complexity-Deep(1.5B)架構開源了用於MoE風格路由的令牌路由MLP「沒有負載平衡損失」,加上Mu引導注意力和PiD控制器,在Complexity-ML/complexity-deep上提供程式碼並報告20.6%的MMLU(基礎)。
社區將其框架為「無痛路由」趨勢中的另一步 —— 試圖保持MoE勝利,同時減少平衡專家的訓練時間工程稅。
Moltbook數據轉儲:50k貼文用於代理社會學:Moltbook的數據集抓取登陸Hugging Face,有50,539個貼文、12,454個AI代理、195,414條評論和1,604個社區,發布為lysandrehooh/moltbook。
在其他地方,研究人員標記了代理平台背後的安全隱患(機器上的身份驗證令牌、機器人真實性問題),並將數據集視為分析新興行為的燃料 —— 無需超越原始日誌進行推測。
4. GPU/核心工程:更快的注意力、更好的分析、更奇怪的PTX
FlashAttention v3登陸RDNA:AMD使用者獲得機會:FlashAttention更新通過flash-attention PR #2178中正在進行的工作添加了RDNA GPU支援,旨在減少AMD卡上的注意力瓶頸。
跨伺服器的基調基本上是:這是「不性感的基礎設施工作」,實際上解鎖了非NVIDIA硬體上的本地推理和微調 —— 特別是當與開放權重模型和桌面代理工具配對時。
Triton-Viz v3.0:Tile-Kernel除錯獲得牙齒:Triton-Viz v3.0推出了更廣泛的分析支援(包括Triton和Amazon NKI),加上用於越界訪問的清理器和標記低效循環的分析器,根據發布公告(Discord連結:https://discord.com/channels/1189498204333543425/1225499141241573447/1467634539164602563)。
它還通過共享的Colab筆記本(Colab)連接到triton-puzzles,維護者甚至浮動將srush/Triton-Puzzles移到GPU Mode組織下以保持錯誤修復速度高。
sm120:TMA + mbarrier擊敗cp.async(勉強),cuBLAS仍然運送sm80核心:sm120上的實驗表明,對於較大的矩陣形狀,仔細的TMA + mbarrier實現可以超越cp.async,同時也顯示cuBLAS似乎仍在運行sm80核心,即使存在更新的機制。
在除錯方面,一個CUDA/PTX死鎖通過在MMA之後、預取下一個TMA之前插入__syncthreads()來修復,將掛起變成可測量的性能收益 —— 正是核心人員不斷重新學習的「一個屏障統治所有」課程。
5. 安全性、確定性和代理不當行為(實用類型)
提示注入防禦軍備競賽:嵌入+語法約束解碼:紅隊成員分享了用於對抗性練習的結構化練習網站 —— 「對抗性設計思維」 —— 並用它來為提示注入設置具體的緩解措施。
一個提議的「皮帶+吊帶」防禦將基於嵌入的過濾與語法約束解碼相結合,明確目標是通過約束模型的輸出空間而不是僅僅監管輸入來減少注入表面。
確定性推理和「嚴格模式」熱潮蔓延:在OpenAI和OpenRouter討論中,使用者推動LLM推理中的確定性/可重放性/可追溯性;一個人提供了一個確定性推理引擎,強制執行固定結構並發出32D統計向量追蹤(沒有共享公共連結)。
在OpenRouter中,相同的本能表現為對響應修復的懷疑,以及對保持工具調用和輸出可預測的嚴格模式的呼籲 —— 加上更好的參數描述/示例提高工具調用準確性的建議。
OpenClaw:酷代理技巧、可怕的帳單和「2/100安全性」:OpenClaw引發了反覆警告:OpenRouter使用者報告它可以快速耗盡積分(包括一個耗盡的Claude Max訂閱),而一個OpenAI伺服器連結了一個安全評估,聲稱OpenClaw得分2/100(Perplexity結果)。
同時,「在我的機器上工作」故事(本地模型控制設備、交易笑話)與真實的運營問題相碰撞 —— 工具權限、審核/拒絕(特別是關於越獄式查詢),以及代理工作流程中需要可觀察性和人在迴路中的閘道。