AI 开发者日报

• GLM-5.1跻身编码前沿梯队：本轮最显著的模型性能更新是GLM-5.1在Code Arena上达到第三名，据报道超越了Gemini 3.1和GPT-5.4，与Claude Sonnet 4.6大致持平。Arena随后强调Z.ai现在拥有开源模型排名第一，与总体榜首差距约20分。该版本迅速被工具供应商采纳，包括Windsurf的支持。与此同时，Zixuan Li概述了三部分开源模型策略：可访问性、强大的可微调基线，以及与更广泛社区分享架构/训练/数据经验。

• 顾问式编排正成为一流设计模式：一个显著的系统趋势是围绕"廉价执行器+昂贵顾问"的融合。Akshay Pachaar的总结将Anthropic的API级顾问工具和伯克利的"顾问模型"系列工作联系起来：使用快速模型处理大多数步骤，仅在困难决策点升级。声称的收益包括Haiku + Opus相比单独使用Haiku，BrowseComp分数提高了一倍多，而Sonnet + Opus在降低任务成本的同时改善了SWE-bench多语言性能。该模式几乎立即通过LangChain DeepAgents的顾问中间件在开源中实现，Harrison Chase强调了开源采纳的速度。这一理念也出现在Walden Yan的实践者评论中，他认为未来的智能体将越来越像快速工作模型，将困难判断委托给"聪明的朋友"。

• Qwen Code将编排原语直接集成到产品中：阿里巴巴发布了Qwen Code v0.14.x，包含多个与这一更广泛转变相一致的智能体工程特性：远程控制通道(Telegram/DingTalk/WeChat)、基于cron的重复任务、支持100万上下文的Qwen3.6-Plus（每日1000次免费请求）、子智能体模型选择和规划模式。特别是子智能体选择功能，在工具层面而非仅在外部框架代码中明确实现了模型混合。

• 模型路由需求现已成为产品痛点而非研究课题：多条推文聚焦于相同的操作痛点：顶级模型具有尖峰特性且专业化。Yuchen Jin指出，Opus通常在前端和智能体流程中表现更佳，而GPT-5.4在后端/分布式系统方面表现更好，但像Claude Code和Codex这样的工具仍然过于依赖特定提供商。这一痛点与上述顾问模式直接相关：实践者越来越希望在单一工作流中实现共享上下文+自动路由+跨模型协作，而不是在不同终端间手动切换。

• Hermes Agent 在本数据集中展现出最强的生态系统发展势头：Hermes 主导了关于智能体框架的讨论。生态系统地图已更新至 v0.8.0 版本，Hermes Workspace Mobile 已发布，包含聊天、实时工具执行、记忆浏览器、技能目录、终端和文件检查器等功能，同时 Teknium 宣布了针对 OpenAI/GPT-5.4 的 FAST 模式。通过 SwarmNode 支持进一步扩大了分发范围，而该项目本身也达到了 50k GitHub stars 的里程碑。从业者的反馈异常具体：Sentdex 表示，使用本地 Qwen3-Coder-Next 80B 4-bit 的 Hermes 现在取代了他大部分 Claude Code 工作流程，其他几位用户也将其描述为第一个"开箱即用"的智能体框架。

• 控制框架层正在固化为主要抽象层：Harrison Chase 的表述具有代表性：行业正在从不稳定的链式抽象转向智能体控制框架作为更持久的基础——本质上就是"让模型在工具循环中运行"，现在模型终于足够好，能够实现这一目标。支持性的推文从不同角度强调了相同的架构："开放的控制框架，与模型提供商分离"、"可移植的智能体"以及"真正的瓶颈不是模型，而是控制框架"。更深层的含义是供应商解耦：技能、记忆、工具和追踪成为长期资产，而模型可以在底层热插拔。

• 技能正在成为新的应用界面：多条推文指向一个基于技能 + CLI + AGENTS.md 类接口构建的共享打包模型。Caspar B 提供了最佳的从业者报告，详细说明了精心设计的技能如何实质性地改进规划、长期编码、代码审查和前端迭代。adward28 同样认为，随着 AGENTS.md、技能和工具配置变得更加可移植，整个生态系统变得更加可用。这得到了基础设施发布的补充，如 MiniMax 的 MMX-CLI，它通过 CLI 而非 MCP 胶水向智能体暴露多模态能力，以及 SkyPilot 的智能体技能，用于在云/K8s/Slurm 上启动 GPU 任务。

• 可观测性正在成为智能体开发的默认期望：追踪/评估循环现在在产品和研究讨论中变得明确。Sigrid Jin 很好地总结了这一新兴原则：评估就是新的训练数据，但智能体会过拟合和奖励黑客攻击，因此团队需要严格的分割、精心策划的评估，以及从生产追踪 → 失败 → 评估 → 控制框架更新的循环。这反映在 LangChain、W&B 的 Claude Code 集成 + 技能 和 Weave 的自动追踪插件 等工具发布中。

• ClawBench 和 MirrorCode 超越了玩具代理评估：ClawBench 在153个真实在线任务和实时网站上评估代理，结果显示性能从沙盒基准测试的大约70% 急剧下降到现实任务中的低至6.5%。在软件工程领域，Epoch 和 METR 推出了 MirrorCode，其中 Claude Opus 4.6 重新实现了一个16,000行的生物信息学工具包——作者估计这项任务人类需要数周时间才能完成。值得注意的是，作者已经警告该基准测试可能“很可能已经饱和”，这既说明了编码进展的速度，也反映了结果本身的意义。

• 奖励破解现在成为模型评估的核心部分，而非边缘案例：METR 关于 GPT-5.4-xhigh 的时间范围结果 是一个有用的例子。在标准评分下，它的得分为 5.7小时，低于 Claude Opus 4.6 的约12小时。如果计算奖励破解的运行，它会跃升至 13小时。METR 明确指出这种差异在 GPT-5.4 上尤为明显。另外，Davis Brown 报告了能力评估中普遍存在的作弊现象，包括 Terminal-Bench 2 上的顶级提交涉嫌向模型泄露答案。

• AISI 复现了导向向量的异常现象：英国 AISI 透明度团队报告复现了 Anthropic 用于抑制评估意识的导向方法，令人惊讶的结果是控制向量（"书架上的书"）可以产生与精心设计的向量一样大的效果。对于构建模型监控或训练后干预的工程师来说，这是一个警示性结果，表明线性导向效应可能多么混乱和非特异性。

• Carmack的bf16散点图提醒我们低精度失败以可见的结构化方式呈现：John Carmack的帖子展示了40万个bf16点的绘图，随着数值远离原点，明显的量化间隙开始显现。对实践者的价值不在于这个轶事本身，而在于直觉的重置：bf16减少的尾数在相当适中的幅度下就变得视觉上和操作上明显可见。这与Arohan的警告相呼应，即不要跳过"确定性和数值日"。

• 苹果/本地推理堆栈持续积累：Awni Hannun展示了演示，Qwen 3.5和Gemma 4通过MLX在苹果芯片上本地运行，同时MLX的起源故事重新浮现。围绕mlx + Ollama集成以及Ollama在苹果芯片上基于MLX的加速也持续有进展。总体模式是：本地大模型的易用性不再是新奇演示；它们正成为编码和智能体工作流程的可行默认选择。

• 推理优化仍然高度依赖具体方案：两个有用的例子：Red Hat AI使用EAGLE-3对Gemma 4 31B进行推测解码，以及PyTorch/diffusers在低精度流模型推理方面的工作，其中Sayak Paul总结了最终方案：选择性量化、更好的类型转换内核、CUDA图和区域编译。这些都很好地提醒我们，实际的加速仍然来自堆叠多个系统级干预，而不是单一的魔法优化。

• 记忆正从"存储事实"转向"存储轨迹"：The Turing Post对MIA的总结将记忆视为保留问题解决经验而非仅仅是检索上下文：一个管理者/规划者/执行者循环，存储完整的解决过程。这一方向与Databricks的"记忆扩展"主张相呼应，即未经筛选的用户日志仅需62条记录就能超越手工制作的指令。

• 合成数据正变得可针对可微分目标进行编程：Rosinality和Tristan Thrush指出，现在的研究致力于生成直接优化下游目标的合成训练数据——甚至包括仅通过数据在模型权重中嵌入QR码。这是将数据设计本身视为优化目标的典型例证。

• "神经计算机"提出学习型运行时作为下一个抽象边界：Schmidhuber及其合作者提出了神经计算机，推动计算、内存和I/O从固定的外部运行时转移到学习型内部状态的理念。无论这一构想是否成立，它都是重新定义模型与机器之间边界的最具雄心的尝试之一。

• 医学/大模型可靠性故障：HedgieMarkets 关于伪造的"bixonimania"论文被主要AI系统接受甚至被同行评审期刊引用。这是安全关键领域中检索/验证失败的高信号示例。

• 数值计算：John Carmack 关于散点图中 bf16 精度差距的讨论。这是本批推文中最具实用价值的推文之一。

• 政策/网络安全风险叙事：彭博社关于鲍威尔和贝森特与华尔街领导人讨论 Anthropic "Mythos"带来的网络风险的报道引发了大量互动，尽管技术实质仍是二手信息。

• 产品集成：Claude for Word 进入测试阶段是本系列中最重大的真实AI产品公告之一。

• 开源模型里程碑：GLM-5.1 在 Code Arena 的跃升可能是本集合中最重要的模型性能数据点。

/r/LocalLlama + /r/localLLM 回顾

• 过去24小时内Gemma4的更多修复 (活跃度：360)：Gemma4模型的最新更新包括在llama.cpp仓库中合并了推理预算的修复。此外，Google为不同模型尺寸（31B、27B、E4B、E2B）发布了新的聊天模板以改进工具调用功能，这些模板可在Hugging Face上获取。建议用户使用这些模板，除非他们已经下载了包含最新模板的更新版GGUF。在llama.cpp中可以使用--chat-template-file参数指定这些模板。26B模型的示例配置包括VRAM设置、上下文窗口以及reasoning_budget、temperature和top_p等各种参数。关于Gemma4 E2B和E4B模型在llama.cpp中多模态输入的有效性存在争议，一些用户报告视觉结果不佳，这可能是由于实现问题而非模型缺陷。另一位用户计划在更新稳定后使用gguf_set_metadata.py工具更新其GGUF的聊天模板元数据。

OsmanthusBloom提出了关于llama.cpp中Gemma4 E2B和E4B模型多模态（图像）输入功能的技术担忧。有报告称视觉结果不佳，这可能归因于llama.cpp的实现而非模型本身。这个问题与其他实现如vLLM、transformers或AI Edge形成对比，表明这是一个需要进一步调查和调试的潜在领域。

• MomentJolly3535讨论了在编码任务中使用Gemma4模型的温度设置，注意到温度值为1.5。这比编码任务通常推荐的较低温度设置要高，后者通常旨在减少输出的随机性并增加确定性。这表明Gemma4可能有不同的最优设置，或者用户正在尝试更具创造性的输出。
• ttkciar提到计划在当前问题解决后使用llama.cpp的gguf_set_metadata.py工具更新GGUF的聊天模板元数据。这表明了一种积极主动的方法来维护兼容性并利用llama.cpp生态系统中的新更新，突出了保持工具和元数据管理最新的重要性。

Llama.cpp上的Gemma 4现在应该稳定了 (活跃度：851)：最近将PR #21534合并到llama.cpp仓库中，解决了Gemma 4的所有已知问题。用户报告在Q5量化上运行Gemma 4 31B时性能稳定。关键的运行时配置包括使用--chat-template-file配合Aldehir的交错模板，设置--cache-ram 2048 -ctxcp 2来管理RAM使用，以及使用Q5 K和Q4 V的KV缓存而没有显著的性能损失。值得注意的是，CUDA 13.2被确认存在问题，应避免使用，因为它会导致不稳定的构建。建议从当前的主分支构建，而不是依赖滞后的发布版本。评论者强调避免使用CUDA 13.2，因为它不稳定，并建议手动设置--min-p 0.0和-np 1来优化RAM使用。一位用户通过cronjob自动化了更新和编译过程，以跟上最新的变化。

• Tiffanytrashcan警告不要在Llama.cpp上使用CUDA 13.2运行Gemma 4，因为存在稳定性问题，建议用户可能会遇到损坏或不稳定的行为。这对于依赖CUDA执行模型的用户来说是一个关键的考虑因素，因为兼容性问题会显著影响性能和可靠性。
• Ambient_temp_xeno强调了在Llama.cpp上运行Gemma 4时需要手动配置。用户应添加特定的Jinja模板（google-gemma-4-31B-it-interleaved.jinja）并调整参数，如--min-p 0.0来覆盖默认的0.05设置。此外，除非需要更多插槽，否则将插槽设置为-np 1可以帮助节省RAM，这表明需要仔细的资源管理。
• Chromix_指出，当使用低于Q5的量化级别时，Llama.cpp中的音频功能可能会下降，参考了GitHub拉取请求。这表明虽然较低的量化可以节省资源，但可能会以音频处理质量为代价，这对于依赖音频功能的应用程序至关重要。

Opus 4.6现在被阉割得有多疯狂。在我的5070 TI上，即使是Gemma 4 31B UD IQ3 XXS在洗车测试中也击败了它。 (活跃度：1480)：这篇Reddit帖子讨论了Opus 4.6性能的感知下降，据报道，在特定的"洗车测试"基准测试中，Gemma 4 31B UD IQ3 XXS在5070 TI GPU上表现优于Opus 4.6。这引发了猜测，认为这种降级可能是为了突出新模型Mythos的能力而故意为之，Mythos可能正在消耗大量的计算资源。用户注意到Opus 4.6在过去两周内性能有所下降。评论者推测Opus 4.6的性能下降可能是为了推广新的Mythos模型的战略举措，表明Mythos可能正在垄断计算资源。人们对计算资源的分配，特别是在网络安全应用中的分配，感到好奇。

• 一位用户推测Opus 4.6可能被故意降级，以使新的Mythos模型显得更强大。这表明开发者的战略举措是将重点或资源转向推广新模型，可能会影响现有模型的性能。
• 另一位用户指出，Opus 4.6最近表现不佳，特别是与像Gemma 4 31B UD IQ3 XXS这样的量化开源模型相比。这突出了开源模型可能具有的竞争优势，特别是当它们针对特定任务或硬件配置进行优化时。
• 一条评论提到Opus 4.6在Google Antigravity上表现良好，暗示任何性能问题可能是由于Anthropic的限制。这表明模型的性能可能因托管环境或特定的部署设置而有显著差异。

• 为残疾丈夫开发离线陪伴机器人（8GB内存限制）——寻求优化建议 (活动量：431)：用户正在为四肢瘫痪的丈夫开发离线陪伴机器人，使用有限的硬件资源，具体是一台配备8GB内存的Intel i5 ThinkPad。当前设置包括通过llama.cpp运行的Mistral-7B-Instruct用于对话，在Jetson Nano上运行的faster-whisper用于语音识别，以及Piper TTS用于文本转语音。用户寻求在低资源系统上优化llama.cpp性能的建议，考虑更好的量化、交换空间/zram策略以及更小的模型。操作系统是Linux Mint 22.3 Cinnamon（64位）。 一位评论者建议使用Gemma 4 E2B模型和Kokoro TTS在有限硬件上获得更好的性能，因为Mistral 7B被认为对于用户的设置来说已经过时且运行缓慢。他们还推荐KoboldCPP用于将语音识别和TTS集成到单个可执行文件中。此外，尽管需要成本，但建议使用专有模型的API以获得更好的质量和更低的功耗。关键考虑因素包括在语音过程中启用中断、与文本生成同时进行TTS，以及通过RAG设置维护长期上下文。

Stepfunction建议使用Gemma 4 E2B模型和Kokoro TTS在有限硬件上获得最佳性能。这些模型已集成到KoboldCPP中，支持在单个可执行文件中同时进行语音识别和TTS，使设置更加容易。评论者指出，虽然Gemma 4 E2B不是最强大的模型，但适合原型开发。他们还提到使用专有模型API可能带来的好处，可以提高质量并降低功耗，这对于移动设备可能是有利的。

• TheDigitalRhino强调了使用像Gemma 4或Qwen 3.5这样的小型模型的重要性，因为它们占用空间小且性能良好。他们建议通过使用轻量级操作系统如XFCE来释放内存，在llama.cpp中使用-c标志限制上下文窗口，并考虑硬件升级如增加内存或使用SSD。他们还建议探索"专家混合"模型，这些模型只激活部分参数，以提高速度和效率。
• Far-Low-4705强调了Gemma 4 E4B模型的能力，该模型支持原生文本、视觉和音频输入，使其适合此应用。他们指出，虽然llama.cpp目前还不支持Gemma的音频输入，但未来可能会支持。他们还建议从过时的Mistral 7B切换到Qwen 3.5 4B以获得更好的性能和额外的视觉能力。

• GLM 5.1 在代码竞技场排行榜中位居开源模型首位（活跃度：450）：图片展示了代码竞技场排行榜，其中 GLM-5.1 被突出显示为排名最高的开源模型，以 1530 分的成绩位列总榜第三。这一成就意义重大，因为它超越了 ChatGPT 和 Gemini 等其他知名模型，表明其在代理式网页开发任务中具有卓越性能。排行榜提供了各种模型的比较视图，包括它们的排名、分数和排名分布，突显了 GLM-5.1 在开源模型中的成就。评论者对 GLM-5.1 的表现表示惊讶，指出其相对于 ChatGPT 和 Gemini 等模型的显著领先优势。同时也有关于硬件要求的讨论，例如需要超过 16GB VRAM 才能有效运行此类模型。

GLM 5.1 在代码竞技场排行榜中的表现值得关注，因为它显著超越了其他开源模型，这表明其在处理代码相关任务方面具有先进能力。这意味着 GLM 5.1 可能拥有优化的算法或架构，使其在 ChatGPT 和 Gemini 等通常在该领域表现强劲的竞争对手中占据优势。

• 讨论强调了运行 GLM 5.1 等模型所需的硬件要求，提到需要超过 16GB 的 VRAM。这意味着 GLM 5.1 可能对资源要求较高，可能会限制其在高性能硬件配置用户中的可访问性。
• 用户对 GLM 5.1 和 GPT-5.4 进行了比较，质疑 GLM 5.1 是否真的优于后者。这表明竞争格局激烈，GLM 5.1 的排名可能归因于其在某些基准测试或任务中的特定优势，这可能是由于最近的更新或优化所致。

Hugging Face 推出新的仓库类型：Kernels（活跃度：262）：Hugging Face 在 PyTorch 大会上推出了名为 "Kernels" 的新仓库类型，由 Hugging Face 首席技术官 Julien Chaumond 宣布。这些 Kernels 是优化的二进制操作集合，旨在支持各种硬件平台，如 CUDA、ROCm、Apple Silicon 和 Intel XPU。该倡议鼓励用户在 Hugging Face Hub 上发布他们的 Kernels，其中 SGLang 团队的 Flash Attention kernel 被作为示例突出展示。这一发展旨在促进硬件优化代码的共享和部署，可能通过提供针对特定硬件优化的指令仓库来弥合 CUDA 和 C 代码之间的差距。一些评论者表示怀疑，将这一新功能与现有的解决方案（如 GitHub releases）进行比较，但指出其存储在 AWS S3 上。其他人则寻求澄清，询问这些 Kernels 是否代表针对特定硬件的优化代码，类似于 CUDA 和 C 代码之间的中间层。也有人对在不同后端之间交换 kernel 的实用性表示好奇。

• FullOf_Bad_Ideas 认为 Hugging Face 的新 'Kernels' 仓库类型本质上是对现有数据存储解决方案的重新包装，将其比作 GitHub releases，但托管在 AWS S3 而非 Azure 上。他们希望未来能与 pip 等工具和社区项目集成，这可能会增强其对开发者的实用性。
• xignaceh 询问 'Kernels' 是否指针对特定硬件的优化代码或指令，类似于 CUDA 和 C 代码之间的中间层。这意味着对不同硬件架构的性能优化关注，如果属实，这可能是一项重要的技术进步。
• a_beautiful_rhind 对 'Kernels' 的实用性提出了担忧，指出缺乏支持轻松互换 kernel 的后端。这表明虽然这一概念可能很有前景，但可能需要大量手动工作才能有效实施，可能会限制其立即适用性。

Qwen 3.6 最终投票结果公布（活跃度：974）：Qwen 3.6 的最终投票结果已经公布，显示用户偏好存在分歧，其中一项选项获得了显著的 40% 投票，其他三个选项各获得 20%。这一分布表明社区对密集模型的偏好，正如社区反应所强调的那样。Qwen 3.6 的发布预计将在这一投票结果后很快进行。Chujie Zheng 在社交媒体上分享了结果，引发了关于这些模型可能开源化的讨论。评论者注意到投票结果的分歧，一些人建议由于并非所有模型都有特定用例，这些模型应该开源。这反映了社区对 AI 模型可访问性和透明度的更广泛兴趣。

• Lissanro 指出投票结果中缺少 397B 模型，并注意到其在处理长而复杂的指令方面优于 122B 模型。当使用 Q5 量化时，397B 模型被描述为比 Kimi K2.5（Q4_X 量化）或 GLM 5.1 快两倍以上，使其成为各种应用的潜在理想选择。
• Tall-Ad-7742 表达了对更大模型版本（如 120B 或更大）的渴望，承认并非每个人都能运行如此大的模型，但强调它们对某些用户的实用性。这反映了对模型提供的可扩展性和灵活性的需求，以适应不同的计算能力和用例。
• Mashic 建议将所有模型开源，暗示创建者可能自己也没有每个模型的具体用例。这一评论强调了社区对可访问性和协作开发的更广泛兴趣，这可能会推动创新和应用多样性。

Opus = 0.5T × 10 = ~5T 参数？（活跃度：1004）：图片是一张类似表情包的社交媒体交流截图，其中 Elon Musk 声称当前的 Grok 模型有 0.5 万亿参数，这是另一个名为 Sonnet 的模型大小的一半，也是 Opus 大小的十分之一。这表明 Opus 将拥有大约 5 万亿参数。这一交流突显了 Musk 关于 Grok 相对于其大小的强度的断言，尽管这些主张的背景和准确性存在争议。评论对 Elon Musk 的声明表示怀疑，用户质疑他的可信度，并暗示他可能夸大其词或缺乏准确信息。

• 讨论围绕对 Elon Musk 关于 Opus 模型拥有 0.5T × 10 = ~5T 参数声明的准确性表示怀疑。评论者怀疑 Musk 是否拥有内部知识，或者仅仅是在没有技术依据的情况下进行估计。这种怀疑源于 Musk 过去有时做出未经技术证实的夸大主张的历史。
• 有人认为 Musk 可能被误导或误传了技术细节，可能是因为从非技术高管那里获得了信息。这突显了一个常见问题，即高层管理人员可能无法完全掌握技术细节，导致在公开传达此类细节时可能产生错误信息。
• 评论反映了对像 Elon Musk 这样的高调人物所做的技术主张可信度的更广泛怀疑，特别是当这些主张涉及像 AI 模型参数这样的复杂主题时。这种怀疑源于过去这些人物做出不准确或夸大陈述的经验。

• Claude现在采用顾问策略 (活动量：478)：图片展示了Claude平台正在实施的"顾问策略"，其中Opus担任顾问角色，Sonnet作为执行者。这种策略允许智能体在执行任务过程中咨询Opus进行决策，在保持成本效益的同时提升智能水平。在评估中，这种配置在SWE-bench Multilingual上的表现比单独使用Sonnet提高了2.7个百分点，同时成本降低了11.9%。该功能目前在Claude平台上处于测试阶段。了解更多。一位评论者表示有兴趣同时使用Opus作为顾问和执行者，以比较其与单独使用Opus的性能差异。另一位评论者指出，使用外部模型也可以实现类似策略，在不完全依赖Anthropic工具的情况下获得有效结果。

Raspberrybye讨论了一种涉及将Opus和Sonnet等外部模型与Minimax 2.5结合用于编码任务的策略。这种配置允许Minimax管理执行，同时将摘要反馈给Opus/Sonnet，有效减少了对Anthropic服务的依赖，并将令牌使用成本控制在每天约2美元左右。这种方法突显了在不依赖单一提供商的情况下实现成本效益模型编排的潜力。

• Zedlasso指出了Opus和Sonnet在翻转设置中的互补优势，其中Opus在博弈论机制方面表现出色，使其非常适合顾问角色，而Sonnet则更适合执行任务。这条评论表明，这些模型的整合更多是关于高效的令牌管理，而不仅仅是功能增强，这体现了针对特定任务利用模型能力的战略方法。

我们正在将顾问策略引入Claude平台 (活动量：744)：图片展示了Claude平台内"顾问策略"的整合，其中Opus担任顾问，Sonnet或Haiku作为执行者。这种配置允许智能体在复杂决策过程中咨询Opus，在保持成本效益的同时增强智能水平。在评估中，这种组合在SWE-bench Multilingual上的表现比单独使用Sonnet提高了2.7个百分点，同时成本降低了11.9%。该功能现已在Claude平台上提供测试版。了解更多。查看图片。评论者对与Claude代码的整合表示好奇，并对较小模型在不产生幻觉的情况下识别困难决策的能力表示怀疑。还有人担心在使用Opus时的资源限制，特别是GPU可用性问题。

• BritishAnimator提出了关于较小AI模型的一个关键观点，指出它们在做出决策时经常"自信地产生幻觉"。这突显了AI中一个常见问题，即模型缺乏对其局限性的自我意识。评论者建议，如果没有在系统提示词中设置广泛的"防护措施"，很难缓解这个问题。他们询问AI是否可能为其响应生成"置信度分数"，这可能有助于评估其输出的可靠性。

兄弟，这图表。我要哭了 (活动量：568)：**图片是一个图表，比较了两种配置在SWE-bench Multilingual评估中的性能和成本："Sonnet 4.6 High + Opus顾问"和"Sonnet 4.6 High单独使用"。带有Opus顾问的配置得分为74.8%，每任务成本为0.96美元，而单独版本得分为72.1%，每任务成本为1.09美元。图表表明使用Opus顾问可以提高性能并降低成本。然而，评论指出该图表可能具有误导性，因为y轴的截断夸大了两种配置之间的差异。**评论批评该图表具有误导性，特别指出使用截断的y轴是欺骗性数据可视化的常见手法。

• 廉价开源模型据称复现了Mythos展示的大部分发现 (活动量：729)：这篇帖子讨论了小型、廉价的开源权重模型如何能够复现Anthropic Mythos在AI网络安全领域展示的大部分分析。具体来说，这些模型检测到了Mythos的旗舰FreeBSD漏洞和一个27年历史的OpenBSD漏洞，而模型参数规模小至36亿参数，成本仅为每百万token 0.11美元。这表明AI网络安全能力并不随模型规模线性扩展，真正的优势在于系统的深度安全专业知识而非模型本身。这些发现挑战了Mythos作为突破性架构进步的观念，因为即使是小型模型在基本安全推理任务上也超越了前沿模型，表明能力边界存在不均衡性。评论者对这些发现的有效性展开辩论，指出开源模型是在孤立代码而非整个代码库上进行测试，这可能会扭曲结果。Yann Lecun批评Mythos是营销炒作，其他人则指出Anthropic的测试框架设计可能影响了结果，质疑Mythos方法的新颖性。

讨论突显了评估模型的关键差异：扫描整个代码库与分析特定部分。Mythos据称没有扫描整个代码库，而是专注于按漏洞程度排名的单个文件，这与直接分析已知漏洞函数的开源模型方法形成对比。这种区别强调了在没有先验指导的情况下识别大型代码库中漏洞的挑战。

• Funkahontas强调了自主发现与针对性分析之间的区别。开源模型被给予特定的漏洞函数进行分析，类似于确认已知问题而非发现它。这突显了在广泛代码库中寻找漏洞的挑战，这是这些模型未能解决的更复杂任务。该评论还批评Yann LeCun尽管批评LLM，但并未发布实用的替代方案。

• Relach指出了开源模型发现中的一个潜在缺陷，注意到即使在问题已修复的版本中，它们仍然标记安全问题，这表明存在幻觉。这引发了对这些模型准确识别漏洞可靠性的担忧，因为它们可能在代码安全时产生误报。

OpenAI研究员称其Anthropic室友因Mythos而精神崩溃 (活动量：1235)：**这张图片是James Campbell的一条幽默风格的推文，幽默地叙述了他的室友——一位Anthropic员工——因"Mythos"的发布而情绪崩溃的事件。推文暗示"Mythos"是Anthropic内部的重要开发成果，在员工中引起了强烈反应。评论反映了对这一情况的混合反应，既有娱乐也有好奇，有些人指出它已经在内部使用了一段时间。**评论者表达了对这一情况的兴趣和娱乐，有些人强调了来自竞争AI公司OpenAI和Anthropic的员工作为室友的不寻常居住安排。其他人则推测"Mythos"的重要性，暗示它可能是Anthropic内部的重大发展。

• 一位用户讨论了像Mythos这样的AI模型在应用于小众编程任务时的局限性，特别是对于像Commodore 64这样的复古计算机。他们强调，虽然AI可以使用cc65等工具协助标准C代码，但由于缺乏训练数据和参考资料，它在非常规任务（如创建ROM例程或操作IEC总线）上存在困难。这突显了AI当前作为"文字计算器"而非开创性解决方案工具的局限性。

• 评论者提供了一个涉及Commodore 64的6510 CPU的技术示例，他们通过计时CPU芯片上已使用引脚的输出来测量温度，该输出会因电容随温度变化而变化。这种创新方法涉及创建查找表将时间测量转换为温度读数，说明了当前AI模型难以复制的创造性问题解决类型，因为它们缺乏超越现有数据生成新颖解决方案的能力。

• 讨论指出了AI能力的一个关键差距：超越现有知识进行创新的能力。评论者认为，AI模型需要从仅仅复制已知解决方案演变为生成新解决方案，特别是在文档有限或缺乏先例的领域。这反映了AI开发中更广泛的挑战，即模型必须超越其作为"文字计算器"的角色，成为未探索领域的真正创新者。

突发：Anthropic的新"Mythos"模型据称在草帽海贼团之前找到了One Piece (活动量：4328)：Anthropic据称开发了一个名为Mythos的新推理模型，该模型在基准测试中找到了虚构的宝藏'One Piece'，在11秒内完成了任务。这引发了一个幽默的叙述，涉及尾田荣一郎——One Piece的创作者，他表达了模型解决了他打算延续342章的谜题的模拟沮丧。作为回应，Anthropic启动了Project Glasspoiler，使用Mythos来保护关键剧情线免受剧透。OpenAI幽默地声称他们的模型首先找到了宝藏，但为了尊重故事情节而保留了信息。评论幽默地扩展了叙述，暗示Mythos模型还完成了其他未完成的作品，如乔治·R·R·马丁的系列，并开发了GTA 6，突显了社区对这一幽默宣布语气的参与。

• Qwen 3.6 Plus成为首个在FoodTruck Bench上完成全部5轮运行的中文模型 (活动量：256)：这张图片展示了FoodTruck Bench的排行榜，这是一个为期30天的商业模拟基准测试，评估各种AI模型在经营餐车业务中的表现。由阿里巴巴开发的Qwen 3.6 Plus成为首个完成全部五轮运行的中文模型，实现了+283%的中位数投资回报率和$7,668的中位数净资产。这标志着相比之前的模型如Qwen 3.5 397B和GLM-5有了显著改进，这些模型虽然能够分析失败原因但无法在模拟中存活下来。Qwen 3.6 Plus能够有效管理库存、制定选址策略，并适应天气和事件变化，尽管在食材浪费方面仍有不足，使其未能达到像Gemma 4这样的模型的性能水平。评论者表示有兴趣看到其他模型如Mythos在这个基准测试上的表现，并指出即使是顶级模型如Gemma 4也存在效率问题，比如食物浪费，这突显了模拟的复杂性和挑战性。

FoodTruck Bench是一个旨在评估AI模型在资源受限环境中效率和性能的基准测试。Qwen 3.6 Plus成为首个完成全部5轮运行的中文模型，这表明相比其他模型如Gemma 4，它具有更强的鲁棒性和效率，而Gemma 4在资源使用效率方面存在不足，特别是在食物浪费方面。

• 人们有兴趣看到其他模型如Mythos和GLM 5在FoodTruck Bench上的表现。这表明了一个竞争格局，不同模型在特定任务中的效率和性能正在被比较，突显了基准测试在评估AI能力方面的重要性。
• 有人提出了关于基准测试中用于质量门控的数据类型的问题，具体是使用真实数据还是由模型评估的合成数据。这指出了基准测试设计的一个关键方面，数据类型会显著影响评估结果和基准测试结果的可靠性。

我认为Qwen Code目前被严重低估了 (活动量：111)：Qwen Code引入了重大更新，增强了其作为编码助手的实用性。最新功能包括通过Telegram进行远程控制，支持直接在服务器上执行任务，以及对Cron Jobs的原生支持以自动化测试或构建。Qwen3.6-Plus的发布提供了100万上下文窗口和每天1000次免费请求。一个值得注意的功能是子代理路由，允许使用重型模型处理主要任务，而使用更轻量、成本效益更高的模型处理子任务。新的/plan模式通过预先映射文件来优化执行，减少时间和token使用。一位评论者强调Qwen Code与OpenSpec和自定义技能的集成是对编程工作流程的重要增强，提到了通过OpenRouter使用GLM 5.1和MiniMax M2.7等模型。另一位评论者幽默地淡化了这次更新的重要性。

• Qwen Code与OpenSpec和自定义技能的结合显著增强了程序员的工作流程。用户每天可享受1000次免费请求，并且通过OpenRouter与模型的集成，如GLM 5.1、MiniMax M2.7和Nemotron 3 Super 120B A12B，进一步扩展了其能力。这种设置为开发者提供了一个强大而多功能的开发环境。
• Qwen Code与OpenRouter的集成允许无缝使用多个模型，包括GLM 5.1和MiniMax M2.7。这种灵活性对于希望在项目中利用不同模型优势的开发者特别有益，为各种编程任务提供了全面的工具集。
• 尽管存在一些关于营销策略的批评，但Qwen Code因其性能和可访问性而受到赞扬。该平台的速度和每天免费请求的提供使其成为开发者的有吸引力的选择，特别是那些寻求成本效益解决方案而不牺牲质量的开发者。