AI 开发者日报

• Cline、LangChain、Notion 和 Cursor 纷纷深入 Agent 平台领域：Cline 开源了重构后的 Cline SDK，并推出了带有 TUI 的全新 CLI、Agent 团队、定时任务和连接器，将其框架定位为自定义编码 Agent 的可复用基础层。LangChain 在 Interrupt 大会上发布了一大批 Agent 生命周期基础设施：LangSmith Engine、SmithDB、Sandboxes、Managed Deep Agents、LLM Gateway、Context Hub 和 Deep Agents 0.6。其中技术含量最高的是 SmithDB，这是一个专为嵌套、长时间运行且携带大负载的追踪数据而构建的可观测性数据库，据称在关键工作负载上实现了 12–15 倍 的访问加速；团队表示它构建在 Apache DataFusion 和 Vortex 之上。与此同时，Notion 的 External Agents API 允许 Claude、Codex、Cursor、Decagon、Warp 和 Devin 等第三方 Agent 直接在 Notion 内部运行，将其作为一个共享、可审查的上下文层，而非另一个信息孤岛。Cursor 扩展了云端 Agent，提供了完整配置的开发环境，包括克隆的仓库、依赖项、版本历史、回滚、受限出口和隔离的密钥。
• Agent 的用户体验正越来越多地从聊天转向长时间运行的状态管理、流式传输和编排：多个产品发布都指向了相同的设计方向。Duet Agent 提出了一种状态机框架，用于处理持续数周或数月的任务，通过父/子 Agent 协调和内存替代压缩来实现。LangChain 的开源更新增加了流式类型投影、检查点存储、代码解释器、框架配置文件和模型特定调优，所有这些都旨在提供比纯 Token 更丰富的 Agent 事件流。Tabracadabra 从自动补全演变为任何文本框中的上下文感知助手，而 VS Code 则引入了 Agent 窗口和更好的多项目任务审查。这些发布背后的架构信息很明确：生产环境中的 Agent 越来越需要持久化执行、可检查的中间状态以及工具原生的 UI 界面，而不是无状态的提示词/响应循环。

• 预训练效率与架构实验是本周最突出的研究主线：Nous Research 的 Token 叠加训练（Token Superposition Training） 修改了预训练的早期阶段，让模型先读取/预测连续的 token 包，之后再回归标准的下一 token 预测。他们报告称，在匹配 FLOPs 的情况下，实际运行速度提升了 2–3 倍，且推理时无需改动架构，该结果在 270M 到 3B 的密集模型以及 10B-A1B MoE 模型上均得到了验证。Jonas Geiping 等人 认为，当前基于消息/聊天的训练方式过度限制了智能体只能处理单一数据流，并发布了一篇关于多数据流大模型的论文，声称该方法具有更低的延迟、更清晰的关注点分离，以及更易理解的并行推理/工具使用能力；论文和代码链接见此处。δ-mem 提出了一种外部在线联想记忆模块，可附加在冻结的全注意力骨干网络上。其 8×8 状态设计据称可将平均得分提升 1.10 倍，比非 δ-mem 基线高出 1.15 倍，在内存密集型基准测试上增益更为显著。

• 后训练/压缩与数据筛选也取得了显著成果：NVIDIA 的 Star Elastic 声称，仅需一次后训练运行，就能衍生出一系列不同规模的推理模型，其成本比从头预训练整个模型族低 360 倍，且比当前最先进的压缩方法好 7 倍。Datology 在多模态大模型方面的工作，由 Siddharth Joshi 和 Pratyush Maini 重点介绍，他们认为仅靠数据筛选就能带来显著的多模态性能提升：在 2B 规模下，20 个公开 VLM 基准测试上平均提升 11.7 分，以约 17 倍更少的训练算力，比 InternVL3.5-2B 高出约 10 分；在 4B 规模下，以 3.3 倍更低的响应 FLOPs 达到了接近前沿的性能，超越了 Qwen3-VL-4B。在开放数据方面，Percy Liang 表示，下一轮 Marin 训练的数据混合集中已有 18T tokens，并且仍在征集更多的预训练、中期训练和 SFT 数据，配套的 token 查看器已在此分享。

• 开放的评估与数据集工作正与模型构建同步成熟：Kevin Li 的 SWE-ZERO-12M-trajectories 被定位为最大的开放智能体轨迹数据集：包含 112B tokens、1200 万条轨迹、12.2 万个 PR、3000 个代码仓库、16 种编程语言。Victor Mustar 指出，llama-eval 是推动 llama.cpp 社区评估更具可比性的重要一步。与此同时，Steve Rabinovich 和 Sayash Kapoor 认为，可信的智能体评估需要基于日志分析，而非仅看结果指标，因为更强的智能体会暴露出隐藏的基准测试缺陷和奖励破解路径。

• Anthropic与OpenAI在企业分发和开发者锁定上的竞争加剧：根据Andrew Curran引用的Ramp数据，4月份Anthropic在企业中的占比为34.4%，而OpenAI为32.3%，这是企业采用率首次出现明显的领先变化；The Rundown也放大了同样的数据。与此同时，Anthropic调整了计划定价策略：ClaudeDevs宣布，付费Claude计划将获得每月专用积分，用于Agent SDK、claude -p、GitHub Actions以及第三方SDK应用的编程使用。这一变化立即被重度用户解读为对订阅补贴工具的重大限制，并遭到了Theo、Jeremy Howard、Matt Pocock和Omar Sanseviero的批评。Anthropic通过另一项措施部分抵消了这种反弹——将Claude Code的每周使用限额提高50%，有效期至7月13日，这与之前宣布的2倍5小时限额提升叠加使用。

• OpenAI以Codex企业激励措施积极回应：OpenAI Devs和Sam Altman为在30天内切换的企业客户提供两个月的免费Codex使用。OpenAI还发布了更多技术平台细节，包括一篇Windows沙箱设计文章，描述了安全运行具有本地文件系统/工具访问权限的编码代理所需的本地用户、防火墙规则、ACL、写限制令牌、DPAPI和辅助可执行文件的组合。当前的竞争动态看起来已不再是"最佳模型获胜"，而更像是补贴 + 工作流控制 + 工具兼容性的较量。

• 企业采用越来越依赖于运行时/安全保障：Perplexity描述了一种硬件隔离的沙箱架构，具有VPC级隔离、短期代理令牌以及在代理操作前扫描外部内容的能力，更多细节涉及加密和自动删除功能。Aravind Srinivas将此视为Perplexity成为企业知识/研究平台的基础。更广泛的趋势是：代理供应商不再仅仅销售智能，他们销售的是有边界的执行环境。

• 递归自我改进从理念走向创业集群：最大的单一元主题是 Recursive 的发布，该公司旨在构建能够自动化科学并安全自我改进的 AI。来自 Richard Socher、Josh Tobin、Dominik Schmidt、Jenny Zhang 和 Shengran Hu 的发布帖子表明，其团队来自开放性、AI Scientist 和研究自动化领域。在相关工作中，Adaption 的 AutoScientist 旨在自动化前沿实验室之外的完整训练-研究循环，Sarah Hooker 认为大多数模型训练失败是由于研究循环的脆弱性，而不仅仅是计算资源的稀缺。

• 网络能力评估持续加剧：英国 AI 安全研究所 表示，前沿模型能够完成的网络任务长度每几个月就翻一番，而最新模型正在超越以往的趋势。Anthropic/Glasswing 的 Logan Graham 表示，Claude Mythos Preview 是首个完成 AISI 端到端网络靶场（包括 Cooling Tower）的模型，也是唯一一个在该研究所 250 万 token 上限下完成所有任务的模型。据报道，XBOW 发现了“token 对 token，前所未有的精确度”，合作伙伴的使用在数周内发现了 数千个高危/严重漏洞。来自 scaling01 的独立评论称，较新的 Mythos 版本完成网络靶场的概率为 6/10，而预览基线仅为 3/10。

• 机器人技术获得具体的长期部署演示：Figure 的 Brett Adcock 直播了人形机器人使用 Helix-02 运行完整的 8 小时自主轮班 进行包裹分拣，后续细节显示，这些机器人从摄像头像素进行推理，以 约人类水平（约 3 秒/包裹） 运行，执行 设备端推理，作为联网车队进行协调，自动更换低电量电池，并在需要时进行自我诊断/故障转移到维护 此处。这是 多机器人、长时间、无人类参与的编排 最清晰的公开演示之一，而非简短的基准测试片段。

热门推文（按互动量排序）

• Claude Code 定价与限制：@ClaudeDevs 宣布周限额提高50%，@ClaudeDevs 推出程序化积分，随后 @theo 引发了开发者强烈反弹，定价政策成为当天对开发者影响最大的新闻。

• Codex 企业级推广：@sama 为切换用户提供两个月免费 Codex 使用，以及 @OpenAIDevs 的企业级号召，标志着一次异常直接的市场反击行动。

• Figure 人形机器人8小时轮班：@adcock_brett 的直播帖子 吸引了巨大关注，是少数几条兼具技术深度和病毒传播力的帖子之一。

• Cline SDK 发布：@cline 的 SDK 发布 是互动量最高的纯技术发布之一，反映了开发者对开源编码代理工具的需求。

• Token Superposition Training（TST）：@NousResearch 的 TST 帖子 是罕见的预训练方法推文，能够广泛传播，很可能因为其核心主张——在不改变推理时架构的情况下实现2-3倍训练加速——既具体又具有重要的经济价值。

1. 高效的端侧大模型推理

• Needle：我们将Gemini工具调用能力蒸馏进一个26M参数的模型（热度：451）：Cactus Compute 开源了 Needle，这是一个仅有 26M 参数的单次函数/工具调用模型，采用"简单注意力网络"（Simple Attention Network）架构——注意力机制加门控，没有FFN/MLP层。其核心理念是：工具调用主要依赖检索、槽位提取和JSON组装，而非深度推理。该模型在 16块TPU v6e 上预训练了 200B tokens，耗时 27小时；后训练使用 2B 个Gemini合成的函数调用tokens，仅需 45分钟。据称在消费级设备上可实现 6000 tok/s 的预填充速度和 1200 tok/s 的解码速度，并在单次函数调用任务上击败了FunctionGemma-270M、Qwen-0.6B、Granite-350M和LFM2.5-350M。代码和权重采用MIT许可，托管在 GitHub 和 Hugging Face 上，架构说明详见 SAN文档。评论者认为Needle可作为轻量级路由器使用——选择工具或将查询分发给更大的LLM并附带参数——同时质疑这种无FFN/交叉注意力的方法能否推广到摘要生成等任务。一个技术提醒指出，该仓库包含Python pickle 文件，由于存在代码执行/安全风险以及Python特定的可移植性问题，这种做法已不推荐。

多位评论者聚焦于这个 26M蒸馏工具调用模型 的架构意义：它可以作为轻量级路由器，将请求分类/路由到合适的更大LLM、工具或RAG流水线，并附带正确的参数，而非自行生成完整答案。有人建议可以将其扩展为一个小型后训练模型，消费结构化RAG输出并以自然语言表达。

• 一个技术观点围绕"无FFN"这一声称展开：如果外部结构化知识始终通过工具/RAG/检索提供，模型可能不需要FFN层来在权重中存储事实知识。这意味着一种可能的设计模式：紧凑的注意力密集型模型专注于编排或基于提供的上下文进行接地，而非依赖记忆。

• 有评论者指出，发布 pickle文件 越来越少见，因为存在Python特定的依赖耦合以及反序列化时的任意代码执行风险。另有人强调，Gemini 在工具调用方面存在明显问题，包括系统提示层面的补丁（涉及工具特异性）以及避免低效文件操作（如 cat）而改用专用工具（如 grep_search），如果Gemini生成的轨迹被用作蒸馏数据，这一点可能很重要。

• 我在一台原装Game Boy Color上本地运行了一个真正的Transformer语言模型！（热度：1326）：图片展示了一台原装Game Boy Color 正在运行一个标记为 TINYSTORIES Q8 GBC 的本地Transformer演示，与帖子声称一致：Andrej Karpathy的TinyStories-260K 被转换为 INT8/定点格式，直接在设备上执行，无需PC、Wi-Fi、连接线或云端推理：图片。该项目使用 GBDK-2020、MBC5 Game Boy ROM、用于权重的bank切换卡带ROM、用于KV缓存的卡带SRAM，以及设备端的分词和提示输入；作者指出生成速度极慢，且由于重度量化和近似处理，输出多为乱码，但Transformer预填充+自回归循环确实能工作。源代码：github.com/maddiedreese/gbc-transformer。评论大多表示惊叹而非技术性讨论，将其视为一个不实用但引人入胜的概念验证——例如*"毫无用处。因此，不可或缺。"*——还有人表示有兴趣将类似实验移植到其他复古硬件上，如N64。

• 有评论者提到了一个相关的先前项目 GBALM，链接为 https://code.heni.lol/heni/gbalm。该评论未提供实现细节，但该链接可能对比较其他在Game Boy级别硬件上运行语言模型类系统的尝试有参考价值。

• 太阳能驱动的Qwen 3.6服务器（热度：449）：一位用户报告称，在一台 M1 Max 32GB 上运行本地 Qwen 27B GGUF 模型（基于 Unsloth 构建的 UD-Q4_K_XL，支持 100k 上下文），速度约为 ~10 tok/s。推理服务器由 3块100W 太阳能板供电，连接 Anker 1.25 kW 一体化电源单元；实测推理负载下功耗约为 ~80–85 W，有时降至 ~30 W，空闲功耗 ≤5 W。用户表示在 Hermes 和 opencode 工作流中性能"非常好"。评论者主要强调了Apple Silicon在离网推理场景中的实用性（低功耗），有人指出非Mac解决方案会过快耗尽电池，且冬季在完全离网环境下运行具有挑战性，尤其是在北方气候条件下。

• 一个技术相关的讨论指出，离网全屋供电系统限制了硬件选择：该评论者使用 Mac，因为替代的服务器/GPU解决方案会过快消耗电池容量。他们还强调了太阳能/离网计算的季节性可靠性问题，称波罗的海附近的冬季非常困难，因此计划转向混合供电方案。

• 别再浪费电了（热度：1104）：一位用户报告称，在RTX 4090上运行 llama.cpp 的 llama-server，使用 Qwen3.6-27B-UD-Q4_K_XL.gguf 模型，参数设置为 --flash-attn on、-ngl all、-ctk q4_0 -ctv q4_0 和 -c 262144，GPU功耗始终受 nvidia-smi -pl N 设定的功耗上限限制，意味着实际板卡功耗会跟随配置的上限。他们的观察是：降低GPU功耗上限可以将功耗削减至约 40%，而不会实质性损害解码/令牌生成吞吐量，同时还能减少热量和噪音；有评论者补充说，预填充对功耗更敏感，但从 450W 降至 270W 时，性能下降据报告仅为 15–20%（取决于模型）。评论者呼吁将预填充/提示处理与解码的基准测试分开，因为解码吞吐量可能掩盖功耗限制导致的性能退化。另一位用户表示，由于连接器/散热问题，他们已经对RTX 5090进行了功耗限制，并可能根据这些结果进一步降低上限。

• 用户们讨论了GPU功耗限制对本地推理的影响，具体来说，将RTX 5090从 450W 降至 270W 对解码/令牌生成（tg）吞吐量影响不大，而预填充（pp）性能下降更明显，但根据模型不同仅为 15–20%。这表明在解码占主导的推理工作负载中，可能存在有利的效率权衡。

• 一位评论者提到因担心连接器或硬件过热而对 5090 进行功耗限制，另一位则提到对 3090s 进行大幅功耗限制以减少夜间运行的噪音。技术启示是：激进的功耗限制可以在不按比例降低LLM推理吞吐量的情况下，显著改善散热/噪音和能效，尤其是在解码密集型工作负载中。

• TextGen 现已推出原生桌面应用——LM Studio 的开源替代品（原 text-generation-webui）（热度：795）：oobabooga/TextGen 已从 text-generation-webui 重构为一款便携、免安装的 Electron 桌面应用，支持 Windows/Linux/macOS 平台。该应用采用自包含的 user_data 存储，并通过 GitHub releases 提供 CUDA、Vulkan、仅 CPU、ROCm 以及 Apple Silicon/Intel macOS 的构建版本。该应用定位为开源版的 LM Studio 替代品，具有以下特性：零出站请求、支持 ik_llama.cpp 以使用 IQ4_KS/IQ5_KS 等新型量化类型、通过 ddgs 实现内置网页搜索、支持 Python/HTTP/stdio MCP 工具调用并带有审批门控、兼容 OpenAI/Anthropic 的 API（包括 Claude Code 支持）、通过 PyMuPDF 实现 PDF 提取、通过 trafilatura 实现网页内容清理，以及 Jinja2 聊天模板渲染；源代码采用 AGPLv3 协议，托管于 oobabooga/textgen。热门评论大多充满热情而非技术性讨论，重点在于对 oobabooga 的认可，以及对更私密、更开放的 LM Studio 替代方案的需求。

一位评论者指出，该项目填补了开源、私密的原生桌面端 LM Studio 替代品这一空白，与此前本地大模型用户体验方案多为网页 UI 导向而非打包应用工作流形成鲜明对比。

• 一条技术性观察指出，在使用 text-generation-webui 后，他们意识到本地大模型生态系统很大程度上围绕 OpenAI 兼容 API 收敛，这意味着只要前端和工具针对该 API 接口，通常就可以互换使用。

• 让我们从零开始构建 Claude Code！（热度：462）：图片是一张技术终端截图（非表情包），展示了一个名为 “NANO CLAUDE” 的自定义 CLI 编码代理，位于 ~/projects/nano-claude 目录下，描述为 “Claude Code · 从零构建”，并提示用户输入编码请求。该帖子链接了一个从零开始的教程视频和对应的 GitHub 仓库：YouTube、GitHub，截图可点击此处查看。评论者主要警告在项目名称中使用 “Claude” 可能会带来 Anthropic 的商标风险，并引用了此前 OpenClaw/Clawdbot 因命名问题被迫改名的案例。其他人指出类似工具已经存在，例如 opencode，或推荐 Pi 作为替代方案。

• 一位评论者认为，重新实现类似 Claude Code 的代理对于理解底层的代理/工具循环非常有价值，因为许多用户依赖这些工具却不了解模型调用、工具调用和迭代执行在底层是如何编排的。

• 另一位评论者指出 opencode 是该领域已有的实现，暗示在从头构建之前，参考这些已有的类似 Claude Code 风格的编码代理可能会更有帮助。

/r/Singularity, /r/Oobabooga, /r/MachineLearning, /r/OpenAI, /r/ClaudeAI, /r/StableDiffusion, /r/ChatGPT, /r/ChatGPTCoding, /r/aivideo, /r/aivideo

1. 现实世界中的AI Agent故障模式

• 接手了一个"氛围工程师"遗留的3个月仓库，写下了职业生涯中最爽的PR（热度：6187）：这张图片展示了一个极端的PR差异：+10,197行新增和**−3,618,778行删除**，直观印证了帖子所述——一个通过"Agent式"/氛围编码（vibe coding）生成的3个月后端仓库，积累了海量生成或冗余代码、文档、日志、密钥和未使用的处理器。作者表示，他们用Claude在一周内重写了整个仓库，在保留功能的同时替换了臃肿的架构——原本有309k行代码、240k行文档、100万+行Markdown日志、220个处理器（实际只用了约20个）、40+个密钥（实际只需要2个）——最终换成了一个更简洁的后端并补充了集成测试。评论区展示的内容大多是围绕"氛围工程师"这个术语的非技术性调侃，以及用AI辅助编码清理AI生成代码库的讽刺意味；在展示的置顶评论中，没有实质性的技术讨论。

几位评论者将这个仓库视为AI/Agent生成的技术债务的典型案例，认为随着团队接手那些缺乏传统工程规范生成的代码，"修复氛围编码烂摊子"可能会成为一个利润可观的维护细分市场。讨论还指出一个可信度差距：对"Agent式方法"的赞美往往来自非软件专业人士，这意味着生成的代码可能看起来很惊艳，但仍然需要大量的人工重构、删除和验证。

• 我为婚礼宾客做了一个AI管家。他们第二爱做的事就是尝试越狱它。（热度：2003）：这张图片是一个定制婚礼AI管家（"Aido"）的使用报告，为毛里求斯的一场目的地婚礼而建，据称通过API/MCP服务器连接了婚礼/旅行信息。数据显示了719次会话、8,678条消息和29位用户，其中最大的类别是真诚的咨询请求（35%）和越狱/黑客尝试（25%），突显出即使是低风险的私人助手也会吸引对抗性提示。图片：AI管家成绩单。评论者认为这个项目比通用聊天机器人更有趣，但对参与度感到惊讶——仅29位用户就产生了超过8,000条消息——并且觉得越狱尝试成为第二大使用场景颇为有趣。

  • 发帖人描述构建了一个两部分系统：首先是针对毛里求斯目的地婚礼的婚礼规划助手，然后是一个面向宾客的AI管家，通过MCP服务器连接到API，以便动态检索活动和旅行信息供用户使用。
  • 一位评论者指出，对于一个小规模部署来说，这个使用量非常显著：仅29位用户就产生了超过8,000条消息，这意味着异常高的参与度和/或反复的探测行为，比如越狱尝试。
  • 有人提出了关于可观测性和消息日志记录的隐私担忧：一位评论者询问宾客是否对发帖人能够阅读他们的交互感到不适，这对于任何存储或检查用户消息的个人活动聊天机器人来说都是一个相关问题。