世界模型就是你所需要的一切 (World Models are all you need)。

2026年3月11日至3月12日的 AI 新闻。我们检查了 12 个 subreddits，544 个 Twitter 账号，未查看更多 Discord。AINews 网站 允许您搜索所有往期内容。提醒一下，AINews 现在是 Latent Space 的一个板块。您可以 选择订阅或退订 邮件发送频率！

AI Twitter 回顾

Agent 基础设施、Harness 以及 MCP 辩论

• Harness 正成为真正的产品表面：多篇帖子趋向于一个观点：仅仅模型质量已不再是瓶颈；环绕模型的 Harness、工具、记忆和运行时环境更为重要。@mattturck 对 Harrison Chase 的采访 明确围绕 Harness、沙箱 (sandboxes)、文件系统访问、技能、记忆和可观测性 (observability) 展开，而 @hwchase17 则强调 Agent UI/UX 仍然困难且开发不足。同样的架构视角也出现在 LangChain JS 新的跨框架 useStream hook、Redis 的上下文工程实验室 以及 Artificial Analysis 的 Stirrup Slack 集成 中，后者添加了具有文档处理、子 Agent、MCP、浏览器使用和代码执行功能的 Slack 原生 Agent。

• MCP 并没有消亡；它正被规范化为生产环境的管道 (plumbing)：尽管出现了一波“MCP 已死”的笑话（示例），但更具技术性的观点则截然相反。@omarsar0 认为 MCP 的问题主要是 Harness 问题，而不是协议问题，随后指出 Anthropic 的新图表功能似乎是由 MCP 支持的（推文）。最具体的证据是 @GergelyOrosz 指出 Uber 在内部使用 MCP，证明 MCP 是大型公司内部 Agent 服务集成的“命脉”。在实践中，市场信号很明确：Agent 平台现在将 MCP 视为基础的互操作性标准，而非新鲜事物。

Coding Agent、评估以及开发工作流的转变

• Coding Agent 技术栈正从 Demo 成熟为可衡量的系统：Cursor 新的 CursorBench 方法论 是这一系列中较强的评估发布之一，它结合了 离线基准测试与在线请求派生指标，从 智能和效率 两个维度为模型打分；团队认为公开的代码基准测试正日益饱和。OpenAI 迅速强调 GPT-5.4 在正确性和 Token 使用效率方面领跑 CursorBench。另外，Code Arena 报告称 GPT-5.4-high 在真实世界的 Web 开发任务中位列前 6，而来自 @htihle 的 WeirdML 结果 显示出强劲但不够稳定的性能，以及异常长的生成解决方案。共同的模式是：代码模型的比较正转向 多维度测量 —— 正确性、Token 效率、交互行为以及对真实任务的契合度。

• Agent 辅助开发正分化为重自动化的流和“人在回路”的工具：一些从业者对冲向完全自主编码的趋势表示反对。@ThePrimeagen 认为 快速的行内自动补全 (inline autocomplete) 在保持理解和减少认知负债方面通常仍然优于 Agent 工作流。相比之下，来自 @sydneyrunkle 和 @corbtt 的帖子展示了 Agent 目前的长处：根据屏幕截图复现 Bug、跨工具的组织级检索 以及自动化繁琐的协调工作。OpenAI 也围绕这种模式发布了更多操作性功能：Codex Automations 现已正式发布 (GA)，支持 Worktree 与分支的选择、模型/推理控制以及可复用模板，并在应用中加入了 UI 自定义功能（主题更新）。

• Hermes Agent 正在崛起为一个严肃的开放 Agent 平台：Nous 的 Hermes Agent v0.2.0 在为期两周的冲刺中发布了一个内容异常密集的版本，正如 @witcheer 所总结的，更新包括：全面的 MCP 客户端支持、面向编辑器的 ACP 服务器、提供商扩展（包括 GLM、Kimi、MiniMax、OpenAI OAuth）、支持回滚的文件系统检查点、git worktree 隔离、本地浏览器支持以及子 Agent 透明度。后续更新还增加了 官方 Claude 提供商支持和更轻量级的安装方案。社区反应表明该平台已被真实采用，包括从 OpenClaw 迁移过来的用户（示例）。

多模态检索、Embedding 以及新的交互界面

• 多模态检索的大年：Google 的 Gemini Embedding 2 是其首个原生多模态 Embedding 模型，它将文本、图像、音频、视频和 PDF 映射到同一个向量空间。来自 Weaviate 和 @victorialslocum 的推文强调了其实际应用案例，如多模态 PDF RAG、通过 Matryoshka Representation Learning 实现的灵活输出维度，以及在检索流水线中的原生支持。最具竞争力的回应来自 Mixedbread 的 Wholembed v3，该模型声称在跨模态和 100 多种语言中达到了 SOTA 检索水平，其团队和外部观察者都强调 late-interaction / 多向量（multi-vector） 设计是其核心差异化优势（@bclavie, @lateinteraction）。

• 检索之争正聚焦于单向量与多向量之别：最具技术深度的评论来自 @lateinteraction，他认为像 Gemini Embedding 2 这样的新型多模态单向量基准模型几乎立即就被扩展后的 ColBERT/ColPali 风格方法超越，并随后表示继续押注单向量 Embedding 几乎是“不理智的”（推文）。即便考虑到炒作成分，更广泛的启示依然重要：检索团队正日益优先考虑交互丰富的索引/评分机制，而非单向量的简洁性，只要基础设施能让其在大规模应用中变得切实可行（TopK 基础设施笔记）。

• 界面正变得更丰富，而不只是更聪明：Anthropic 的 Claude 现在可以直接在对话中生成交互式图表和图解，这是向生成式 UI (Generative UI) 迈出的重要产品化一步，而非仅仅停留在纯文本输出。这引起了已经通过 MCP 构建类似系统的开发者们的共鸣（@omarsar0）。与此同时，Perplexity Computer 已向 Pro 用户开放，配备了 20 多个模型、技能和连接器，@alexalbert__ 将这一更广泛的产品趋势总结为“生成式 UI 时代已开启”。

模型发布、基准测试与效率趋势

• NVIDIA 的 Nemotron 3 Super 脱颖而出，成为技术讨论热度最高的模型发布：@rasbt 强调该模型是一个权重开放的 120B 模型，具有强大的吞吐量，且基准测试表现大致处于 Qwen3.5/GPT-OSS 级别。其架构因 LatentMoE 设计而备受关注；@cwolferesearch 提供了一份有用的拆解，展示了在低维潜空间（latent space）中进行路由如何同时降低 all-to-all 通信成本和专家权重加载成本，并随后将这些节省的开销重新投入到更多的专家以及每个 token 激活更多专家的设计中。这是架构演进的一个清晰范例，旨在追求更好的推理经济性，而不仅仅是刷榜基准测试。

• Grok 4.20 Beta 看起来更像是一次成本/速度/行为方面的更新，而非前沿性能的飞跃：Artificial Analysis 的评估将 Grok 4.20 (reasoning) 的 Intelligence Index 定位在 48，低于目前的顶尖模型，但拥有更大的 2M context window、更低的价格（每 1M in/out tokens 为 $2/$6）、极快的速度，以及目前在该机构 non-hallucination metric（非幻觉指标）上测得的最高分。来自 @scaling01 和 Vals 的后续评论广泛证实了这一观点：虽然不是顶尖的前沿水平，但更便宜、更快速，并且在某些生产环境中可能更具实用性。

• 效率和架构依然是核心主题：当天还发布了 FLUX.2 klein 9B-KV，据报道其图像编辑速度快了 2x–2.5x 且质量没有下降；以及 Reka Edge，这是一个 7B VLM，主打约 98ms 的 time-to-first-token 和低延迟的 agentic/端侧使用。在研究方面，推特上出现了关于 looped transformers with gated memory banks、LM head gradient bottlenecks、reasoning probes for early CoT exit 以及 Flash-KMeans 的研究工作，所有这些都与该领域目前在训练信号质量、推理效率和 adaptive compute（自适应计算）方面寻求突破的方向一致。

Applied AI: 地图、健康、视频和预测

• Google Maps 正在围绕 Gemini 进行重构，将其作为交互层而非仅仅是地图层：Google 的 Maps 升级推文描述了十多年来最大的产品更新，其中包含两个值得注意的部分：一个基于 Google 地点/社区图谱的对话式 “Ask Maps” 模式，以及具有更丰富 3D 路线引导的 Immersive Navigation（沉浸式导航）（详情）。来自 @dbreunig 等观察者的工程启示更有趣：未来的 UX 可能根本“看起来不像地图”，LLM 将作为地理空间知识的主要接口。

• 医疗 Copilot 正在向纵向个人上下文演进：Microsoft 推出了 Copilot Health，这一在美国发布的产品可以将 EHR 记录、可穿戴设备、个人历史和实验室数据聚合到一个专门的健康档案中。该公司强调，用户数据不会用于训练模型，且输出结果基于具有引用的可信健康来源。另外，Glass Health 为 athenaOne 和 eClinicalWorks 添加了自助式 EHR 集成，显示出 AI 系统只有在与真实的临床数据系统深度连接后才真正发挥作用的趋势。

• 视频生成 API 变得更具产品化：OpenAI 的 Sora 2 驱动的 Video API 更新增加了自定义角色/物体、16:9 和 9:16 导出、20 秒剪辑、续写以及批量任务，这一系列务实的功能适用于营销活动、故事板和 UGC 工作流，而不仅仅是纯粹的研究演示。

• Groundsource 是“AI 助力公益数据”领域最强有力的发布之一：Google Research 的 Groundsource 利用 Gemini 将 5M+ 份公共报告转化为包含 150+ 个国家、2.6M+ 次洪水事件的数据集，能够提前 24 小时预测城市突发洪水。其方法论意义超出了洪水预测本身：利用 multimodal/LLM 流水线从嘈杂的公共语料库中合成结构化的开放基准测试，可能成为那些缺乏数据监测手段的领域的重要模式。

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

• Claude 交互式图表与图形：Anthropic 在对话中推出了交互式图表/图形，这是本周 LLM 向更丰富的前端界面而非仅仅是更优质的文本演进的最清晰案例之一。
• Google Maps + Gemini：Google 对 Maps 的重大升级是本组中目前为止规模最大的主流产品发布，包含对话式地点搜索和沉浸式导航。
• CursorBench / 编程评估：Cursor 针对编程 Agent 的新评估方法论引起了格外的关注，因为它解决了真正的空白：如何结合线上和线下信号，从能力和效率两个维度评估编程系统。
• Perplexity Computer 推出：面向 Pro 用户的 Perplexity Computer 标志着市场对具有更广连接器/技能的“计算机操作（computer-use）”产品而非单一模型对话产品的持续热情。
• OpenJarvis 设备端个人 AI：斯坦福大学推出的 OpenJarvis 作为一个严肃的本地优先（local-first）设备端个人 AI 框架脱颖而出，具有模块化基础设施、本地检索、MCP 工具以及关注效率的评估。

AI Reddit 简报

/r/LocalLlama + /r/localLLM 简报

1. Qwen3.5 模型性能与基准测试

• Qwen3.5-9B 在 Agent 编程方面表现相当出色 (热度: 428)：该帖子讨论了 Qwen 3.5-9B 在带有 12 GB VRAM 的 Nvidia Geforce RTX 3060 上的性能，强调了它在 Agent 编程任务中的有效性。用户对比了多种模型，包括 Qwen 2.5 Coder 和 Qwen 3 Coder 的 Unsloth 量化版本，指出 1-bit 量化速度快但在 Tool calls（工具调用）方面不可靠，而 2-bit 量化速度较慢且不稳定。然而，Qwen3.5-9B 模型表现良好，维持了一个多小时的功能正常且无故障，这表明它非常适合 VRAM 有限的消费级硬件。用户还提到 Unsloth-Qwen3 Coder 30B UD-TQ1_0 在代码补全方面非常有效。一位评论者指出 Qwen3.5-9B 的性能可以与 GPT-120B 等大型模型相媲美，而另一位用户则分享了负面经历，该模型破坏了他们的构建系统，表明性能存在差异。此外，还分享了另一个模型 OmniCoder-9B-GGUF 的链接作为潜在替代方案。

  • Qwen3.5-9B 以其出色的性能著称，基准测试接近 GPT-3 的 120B 模型水平，考虑到其较小的尺寸，这一点令人惊讶。这表明 Qwen3.5-9B 在性能与尺寸比方面效率极高，使其成为 Agent 编程领域的有力竞争者。
  • 尽管有其优势，据报道 Qwen3.5-9B 在某些情况下会导致严重问题，例如彻底破坏构建系统和删除项目。这表明虽然该模型表现良好，但也可能存在稳定性问题或 Bug 需要解决，特别是在 RTX 4060 上使用 LM Studio 和 Claude Code 等复杂环境时。
  • 围绕 Qwen3.5-9B 等低量化模型的效用存在争议，一些用户认为尽管这些模型尺寸较小，但确实可以执行有用的任务。这挑战了只有大型模型才能产出高质量结果的观念，突显了优化后的小型模型在实际应用中的潜力。

• 我花了 8 个多小时在 4x RTX PRO 6000 (SM120) 上对 Qwen3.5-397B NVFP4 的每个 MoE backend 进行了基准测试。这是我的发现。 (热度: 349): 该帖子详细介绍了在 4x RTX PRO 6000 GPU 上对 nvidia/Qwen3.5-397B-A17B-NVFP4 模型进行的广泛基准测试工作。尽管有人声称速度可达 130+ tok/s，但实际最高仅达到 50.5 tok/s。瓶颈被归因于 NVIDIA 的 CUTLASS kernels，由于 TMA Warp Specialized grouped GEMM 策略初始化中的一个错误，该 kernel 在 SM120 硬件上失效，正如 CUTLASS issue #3096 所记录的那样。作者认为，由于数据中心级别的假设导致了 Shared Memory (SMEM) 溢出，SM120 的严格限制为 101 KiB，而数据中心变体则不同。帖子还强调，由于反量化（dequantization）差异，Multi-Token Prediction (MTP) 会导致 -22% 的性能衰减。作者已向 FlashInfer 和 vLLM 提交了补丁以解决其中一些问题，但核心问题仍未被 NVIDIA 解决。 一位评论者认为，作者在 GitHub 上的 bug 报告过于冗长且缺乏清晰的复现步骤，这可能是 NVIDIA 尚未处理的原因。另一位评论者指出 SM120 问题的根本原因是物理 SMEM 溢出，并建议更小的 tile shapes 可能会解决问题。第三位评论者指出，在原生 Linux 上运行该配置比在 WSL2 上性能可提升约 10%。

  • lawdawgattorney 提供了对比影响 RTX PRO 6000 GPU 上 Qwen3.5-397B NVFP4 模型 bug 的详细分析。问题追溯到由于数据中心假设导致的 Shared Memory (SMEM) 溢出，SM120 核心具有严格的 101 KiB 限制，而数据中心核心约为 227 KiB。流水线阶段（pipeline stages）的自动计算公式未能考虑到 alignas(1024) 填充，导致 kErrorInternal 崩溃。临时修复方法包括硬编码 StageCount<2>，但由于内存延迟问题，这会将性能降低至 4.8 tok/s。提出的解决方案是支持更小的 tile shapes，以便在 SM120 的 SMEM 限制内容纳更多流水线阶段。
  • JockY 批评原始 bug 报告过于冗长且缺乏关键细节，如复现指令和错误日志。报告过长且包含无关的基准测试，使开发者难以解决问题。JockY 建议采用更简洁的方法，专注于清晰的复现步骤和错误日志，以便开发者进行调试和解决。

  • AndreVallestero 建议在原生 Linux 而非 WSL2 上运行基准测试，指出性能可能有约 10% 的提升。这意味着 WSL2 中的虚拟化层可能会引入开销，影响运行 Qwen3.5-397B NVFP4 模型等 GPU 密集型任务的性能。

  • Qwen3.5-9B 量化对比 (热度: 398): 该帖子展示了使用各种 GGUF 量化方法对 Qwen3.5-9B 模型进行的详细量化对比，重点关注 Kullback-Leibler Divergence (KLD) 和 Perplexity (PPL) 作为关键指标。分析强调，对于显存（VRAM）受限且不希望低于 Q4 质量的场景，来自 bartowski 的 IQ4_XS (4.93 GiB, KLD 0.0127) 是最优选；而来自 bartowski 的 Q4_K_S (5.18 GiB, KLD 0.0108) 在多个领域表现良好。值得注意的是，bartowski 的 Q4_K_M 优于 unsloth 的 Q4_K_M (0.0087 vs 0.0222 KLD)，而 lmstudio 的 Q4_K_M 得分最差 (0.0353 KLD)。帖子还在 HuggingFace 上提供了一个 token 级偏移可视化，展示了四个领域的偏移情况。评估是在配备 i3-12100F CPU、64GB RAM 和 RTX 3060 GPU 的系统上使用 llama.cpp 完成的。 评论者一致认同这些发现，指出 Bartowski 的量化版本 被认为比 unsloth 等其他版本更稳定。用户对这种有助于在量化选择时做出明智决策的详细分析表示赞赏。
• General_Arrival_9176 强调了 Bartowski 和 Unsloth 在相同级别的量化（Quantization）之间存在显著的性能差异，Bartowski 的 Q4_K_M 实现了 0.0087 的 KL Divergence，而 Unsloth 则为 0.0222。这表明量化过程以及 Unsloth 可能使用的训练方法论具有实质性影响，同时也说明了选择正确量化方法的重要性，以避免不必要的重复下载多个版本。
• Shingikai 强调了在评估量化性能时，使用 KL Divergence (KLD) 优于 Perplexity (PPL) 的价值。虽然 PPL 提供了一个平均性能指标，但 KLD 可以揭示模型虽然保持流畅但会做出错误决策的“灾难性失效（catastrophic failure）”案例。讨论还指出 Bartowski 的 Q4_K_M 优于 Unsloth，这表明在 4-bit 级别，校准数据（calibration data）的选择比量化引擎本身更为关键。

• dark-light92 和 General_Arrival_9176 都注意到 Bartowski 的量化方案相较于 Unsloth 等方案具有更好的稳定性和性能。这表明量化方法正趋向于更可靠，Bartowski 的方法因其稳定性和更低的 KL Divergence 而受到青睐，这对于在实际应用中保持模型准确性和性能至关重要。

• M5 Max just arrived - benchmarks incoming (Activity: 2679): 该帖子讨论了 M5 Max 128GB 14 英寸笔记本电脑的到货和基准测试，重点是使用 mlx_lm 工具测试各种 AI 模型。作者最初在 BatchGenerator 上遇到了问题，导致他们在切换到全新的 Python 环境并使用 stream_generate 以获得准确结果时出现了延迟。基准测试涵盖了 Qwen3.5-122B-A10B-4bit 和 gpt-oss-120b-MXFP4-Q8 等模型，并提供了详细的性能指标，如 tokens-per-second 和峰值内存占用。结果突显了 M5 Max 高效处理大型模型的能力，某些测试中的峰值内存占用达到了 92.605 GB。 评论者们急于看到基准测试结果，一些人对 Qwen 3.5 27b MLX 4bit 和 6bit 等特定模型表示了兴趣。讨论反映了人们对 M5 Max 在这些 AI 模型上表现的期待和好奇。

  • 使用 mlx_lm.generate 对 M5 Max 128GB 14 英寸进行的基准测试结果显示，在不同模型和配置下都有显著表现。例如，Qwen3.5-122B-A10B-4bit 模型在 16K Context 下实现了 1,239.7 t/s 的 Prompt 速度和 60.6 t/s 的生成速度，峰值内存占用为 73.8 GB。相比之下，Qwen3.5-27B-Claude-4.6-Opus-Distilled-MLX-6bit 模型在 32K Context 下的生成速度较低，为 14.9 t/s，但峰值内存占用也较低，为 30.0 GB。
  • Qwen3-Coder-Next-8bit 模型表现出令人印象深刻的性能，特别是在更高的 Context 下，在 32K Context 下实现了 1,887.2 t/s 的 Prompt 速度和 68.6 t/s 的生成速度，峰值内存占用达到 89.7 GB。这表明该模型经过优化，可以高效处理更大的 Context，尽管它需要大量的内存资源。
  • gpt-oss-120b-MXFP4-Q8 模型凭借其极高的 Prompt 和生成速度脱颖而出，特别是在 16K Context 下，Prompt 速度达到 2,710.5 t/s，生成速度达到 76.0 t/s，而峰值内存占用相对较低，为 64.9 GB。这表明它在速度和内存效率之间取得了极佳的平衡，使其成为高性能任务的极具竞争力的选择。

• Llama.cpp now with a true reasoning budget! (Activity: 444): Llama.cpp 引入了真正的推理预算（reasoning budget）功能，增强了之前的存根实现（stub implementation）。新功能使用采样器机制在推理期间计算 Token 数量，并在达到预算时终止。在 Qwen3 9B 上的初步测试显示，在强制执行推理预算时，HumanEval 性能从 94% 下降到 78%，但添加 --reasoning-budget-message 后分数提高到 89%。此更新允许实验不同的模型和设置，可能会提高推理效率。更多技术细节请参见 commit。 评论者指出，HTTP 中的 thinking_budget_tokens 与 CLI 中的 --reasoning-budget 之间可能存在混淆，并建议通过动态调整 logit_bias 来获得更好的性能。另一个建议是通过将 logit_bias 设置为负无穷大来强制执行最小推理预算，这可能会提高分数。一位用户报告了在 Qwen3.5 35B 上的成功测试，推理预算提高了决策效率，而没有出现过度的 “Overthinking”。

• coder543 指出了 Llama.cpp API 设计中可能存在的混淆：HTTP 字段名为 thinking_budget_tokens，但 CLI 参数却是 --reasoning-budget。这种不一致可能导致用户因误向 API 发送 reasoning_budget 或 reasoning_budget_tokens 而出错。此外，coder543 建议在推理预算即将结束时，动态提高 end-of-think token 的 logit bias，以帮助模型更自然地结束推理，尽管他们指出这可能会降低智能评分。
• chris_0611 分享了 Qwen3.5 35B 模型在 Q5 量化下的实际测试结果，使用“洗车测试 (car-wash test)”来评估推理预算。在推理预算为 0 时，模型无法为 100 米的距离选择步行。在预算无限时，它思考了 83 秒但通过了测试。而推理预算设为 1000 tokens 时，测试成功且仅思考了 18 秒，展示了速度与准确性之间的平衡。

• audioen 提出了一种逐渐增加生成 </think> token 概率的方法，建议每个 token 线性增加 0.1% 的偏置。这种方法旨在让模型的推理过程在设定的 token 限制结束前自然收敛，从而在不产生突然中断的情况下提高效率。

• llama.cpp 在 $500 MacBook Neo 上的表现：Qwen3.5 9B Q3_K_M 的 Prompt: 7.8 t/s / Generation: 3.9 t/s (热度: 636): 一位用户在搭载 **Apple A18 Pro 芯片的 MacBook Neo 上成功编译了 llama.cpp，使用 Qwen3.5 9B Q3_K_M 模型实现了 7.8 tokens/second 的 Prompt 处理速度和 3.9 tokens/second 的生成速度。该配置使用了 8 GB 统一内存 和支持 Metal 的 5 核 GPU。模型源自 Hugging Face 仓库，占用磁盘空间 4.4 GB。用户提供了一个可能实现更快性能的配置，9B 模型达到 5 tokens/second，4B 模型达到 10 tokens/second，详见帖子中的链接。** 评论者指出，性能可能受到了 8GB RAM 和潜在 磁盘交换 (disk swapping) 的限制，建议使用更小的模型以提升速度。配置参数 -b, -ub, -ctk 和 -ctv 也被强调为不寻常。

  • coder543 认为性能指标表明系统可能正在向磁盘进行交换或使用压缩内存，这严重影响了速度。他们建议使用较小的 4B 模型进行测试，以观察潜在的非线性速度提升，暗示当前的设置对 9B 模型来说并非最优。
  • Technical-Earth-3254 指出，MacBook 上有限的 8GB RAM（尤其是运行完整操作系统时）是影响性能的主要瓶颈。这表明内存限制是观察到的吞吐率的关键因素。
  • thisguynextdoor 询问了是否使用了 Apple 的 Metal API 进行 GPU 加速，这可以显著增强性能。他们将其与自己在 M1 Pro 上运行 Gemma 3 27B 模型（达到 15 t/s）的经验进行了比较，表明硬件加速可能是提高吞吐量的关键因素。

2. OmniCoder-9B 与 Agentic 编码

• **[OmniCoder-9B

  基于 425K Agent 轨迹微调的 9B 编程 Agent](https://www.reddit.com/r/LocalLLaMA/comments/1rs6td4/omnicoder9b_9b_coding_agent_finetuned_on_425k/)** (热度: 330): OmniCoder-9B 是由 Tesslate 开发的一个拥有 90 亿参数的编程 Agent，它在 Qwen3.5-9B 模型基础上使用 Gated Delta Networks 和标准 Attention 的混合架构进行了微调。该模型在超过 425,000 条精心挑选的 Agent 编码轨迹上进行训练，其中包括来自 Claude Opus 4.6 和 GPT-5.4 等模型的数据，重点关注真实世界的软件工程任务和多步推理。该模型具有 262,144 token 的上下文窗口，可扩展至 1M+，并展示了强大的错误恢复和推理能力，例如响应 LSP 诊断和使用最小编辑 diffs。它采用 Apache 2.0 许可证发布，并完全开放权重。评论者强调了 Qwen3.5-9B 模型令人印象深刻的能力，认为尽管其体积较小，但足以与大得多的模型竞争。用户对测试 OmniCoder-9B 表现出极大的热情，一些用户注意到它能够高效处理复杂任务。

  • Uncle___Marty 强调了 Qwen 3.5 9B 模型令人印象深刻的性能，认为在编程能力方面，它可以与 100B+ 参数的大型模型相媲美。评论者强调了像 Qwen 3.5 9B 这样小而强大的模型的潜力，并因其效率和能力而倡导其在本地应用中的未来。
  • pilibitti 分享了一个该模型能力的实际案例，指出它在一个空白系统提示词下成功完成了一个需要 20 多次工具调用的 Agent 任务，而 Qwen 3.5 9B 即使在详细提示下也未能完成该任务。这突显了该模型在最小指导下处理复杂任务的高效性和有效性。
  • PaceZealousideal6091 询问了 OmniCoder-9B 与 Qwen 3.5 35B 之间的对比基准测试，表示有兴趣了解性能差异。他们还询问了推出更大版本（如 35B 模型）的可能性，表明了在保持效率的同时扩大模型能力的的需求。

• 我曾是 Manus 的后端负责人。在构建 Agent 两年后，我完全停止了使用函数调用。这是我现在的做法。 (热度: 2145): 这篇文章讨论了从使用多个类型化函数调用到使用带有 Unix 风格命令的单一 run(command="...") 工具的转变，认为这种方法符合 Unix 和 LLM 的文本特性。作者曾是 Manus 的后端负责人，在开发 Pinix 和 agent-clip 等开源项目时开发了这种方法。Unix 的文本流和 CLI 命令哲学被视为 LLM 的天作之合，因为 LLM 是在海量的 CLI 模式上训练出来的。文章概述了一种处理 LLM 限制的两层架构，使用了诸如渐进式 --help 探测、用于导航的错误消息以及一致的输出格式等技术，来引导 Agent 使用 CLI 工具。这种方法与传统的函数调用方法形成对比，突显了 CLI 对 LLM 的效率和熟悉度。 一位评论者提到了一项类似的实验，即使用 Python 代码 eval 作为 LLM 的唯一工具，据报道效果很好。另一条评论幽默地暗示这篇文章可能是为了给 LLM Agent 提供完整的终端访问权限，而第三条评论则强调了自然语言到命令行工具转换的威力。

  • spaceman_ 提到了一项实验，该实验限制 LLM 仅使用 Python 代码评测（eval）作为工具，据报道表现良好。这表明 LLM 可以有效地利用编程语言作为执行复杂任务的工具，从而可能简化 LLM 在以 Python 为主要语言的环境中的集成。
  • raucousbasilisk 强调了在自然语言处理任务中使用 JIT（即时编译）的潜力，特别是将自然语言转换为 sed、awk 和 regex 等命令行实用程序。这种方法可以利用现有的命令行工具进行文本处理，为处理各种数据操作任务提供灵活高效的方法。
  • johnbbab 推测，终极的 Agent 框架可能类似于 Shell 环境，暗示 Shell 脚本的简单性和强大功能可以作为开发稳健 Agent 框架的模型。这一观点突显了在新的 AI 驱动应用中利用现有的、已被充分理解的技术的潜力。

3. 模型发布与新基准测试

• Nemotron 3 Super 发布 (热度: 755): NVIDIA 发布了 Nemotron 3 Super，这是一个拥有 1200 亿参数的 Mixture of Experts (MoE) 模型，其中包含 120 亿激活参数，专为 Agent 推理设计。该模型完全开源，包括权重、数据集和训练方案 (recipes)，允许开发者在其基础设施上进行定制和部署。它拥有一个全面的数据流水线，包含用于预训练的 10 万亿精选 tokens 和用于后期训练的 4000 万个样本，支持推理、编程和多步骤 Agent 任务。该模型已在 Hugging Face 上提供，并支持具有 NVFP4 精度的量化感知训练 (QAT)。一些用户已经为该模型创建了 GGUFs，这至少需要 64GB 内存，并建议在官方更新发布前使用 llama.cpp 的特定分支以确保兼容性。

  • Nemotron 3 Super 因其开源特性而备受关注，提供了对权重、数据集和训练方案的完全访问权限，允许开发者在自己的基础设施上定制和部署模型。该模型的数据流水线包括 10 万亿用于预训练的精选 tokens 和 4000 万个后期训练样本，强调了可复现性和 Agent AI 的开发。RL 任务涵盖 21 个环境，生成了 120 万次 rollouts，展示了其超越静态文本的动态能力。
  • Nemotron 3 Super 模型提供多种格式，包括 BF16 和 NVFP4，并具有量化感知训练 (QAT) 选项。该模型的 GGUFs 需要至少 64GB 内存，且目前与 llama.cpp 存在兼容性问题，建议使用 Unsloth 的特定分支以获得正常功能。这突显了该模型对硬件的高要求以及持续的集成努力。
  • 对 Nemotron 3 Super 的初始性能评估表明，在 LM Arena Text 基准测试中（特别是在过滤开源和关闭风格控制的情况下），其得分低于像 Qwen3.5 这样更轻量的模型。这表明尽管它拥有全面的数据集和开源优势，但在某些基准测试中的表现可能尚未达到预期。

• 新的基准测试刚刚发布 (热度: 1359): 该帖子幽默地请求一段完整的 Three.js 代码，用于创建一个包含 **Michael Jackson、Pepe the Frog、Donald Trump 和 Elon Musk 表演 “Thriller” 舞蹈的场景，强调高质量渲染和电影效果。评论中提到了各种 AI 模型，如 Sonnet 4.6 和 Gemini，分别指出了它们在光影和动画方面的优势。讨论凸显了这一请求的趣味性，像 Deepseek 3.2 以及 Minimax & GLM 等模型在尝试这项任务时的表现也被调侃式地提及。** 评论幽默地争论了不同 AI 模型的能力，Sonnet 4.6 因光影效果受到称赞，Gemini 因编舞受到好评，而 Deepseek 3.2 等模型虽未表现卓越，但其努力得到了认可。

  • Recoil42 强调了各种模型在这一新基准测试中的表现，指出 Sonnet 在光影和模型方面表现出色，而 Gemini 在编舞方面令人印象深刻。他们还提到了 Deepseek 3.2 稳定的表现，并幽默地指出 Minimax 和 GLM 失去了兴趣，而 Qwen 似乎在尝试一项完全不同的任务。
  • cmdr-William-Riker 质疑了 OpenAI 的表现，对其感知的退步表示惊讶。他们专门询问了基准测试中使用的 Qwen 3.5 变体，表现出对理解可能影响结果的特定配置或版本的兴趣。

• Nvidia 将投入 260 亿美元构建 Open-Weight AI 模型，财报文件显示 (热度: 1146): 根据最新的财务文件，Nvidia 计划在未来五年内投资 260 亿美元 开发 Open-Weight AI 模型。该计划旨在加强 Nvidia 在 AI 基础设施市场的地位，与 OpenAI 和 Anthropic 等主要实体竞争。这项投资可能会集中于利用 Nvidia 的硬件能力（如 H100 集群），以维持 CUDA 作为默认推理目标的地位，并针对 NVFP4 精度进行优化。欲了解更多详情，请参阅 原文。评论者强调，Nvidia 的这一战略举措是通过将 AI 模型商品化来维持其在 AI 硬件市场的统治地位，从而巩固“Nvidia 税”。这种做法被视为确保 CUDA 保持默认推理目标的一种方式，充分利用了其硬件的能力。

  • Nvidia 对 Open-Weight AI 模型的 260 亿美元投资被视为维持其在 AI 硬件市场主导地位的战略举措。通过开发这些模型，Nvidia 旨在确保 CUDA 仍然是默认的推理目标，从而有效地锁定其生态系统，使竞争对手更难证明设计替代芯片的合理性。这种方法符合“将你产品的互补品商品化”的策略，即 Nvidia 不仅销售硬件，还提供在其上运行的软件和模型，从而巩固其市场地位。
  • 对 Open-Weight AI 模型的投资也是 Nvidia 优化其自身硬件（如 H100 集群）使用的一种方式。通过内部利用这些资源，Nvidia 可能会加速高级 AI 模型的开发，进而推动对其硬件的进一步需求。此举被视为证明维持 CUDA 作为 AI 开发首选平台的高昂成本合理性的一种方式，确保 Nvidia 的生态系统仍然是 AI 研究人员和开发者的首选。
  • Nvidia 对优化 NVFP4（Nvidia 的浮点格式）的关注凸显了其致力于最大化硬件性能的承诺。通过定制其 AI 模型以利用 NVFP4，Nvidia 可以实现更高的效率和性能，这对于大规模 AI 训练和推理任务至关重要。这种技术优化不仅增强了其模型的能力，还增强了其硬件解决方案的价值主张，使其对需要高性能 AI 解决方案的客户更具吸引力。

较低技术性的 AI Subreddit 综述

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

1. Claude Code 与 Anthropic 的进展

• Anthropic：递归自我改进已经到来。世界上最具颠覆性的公司。 (热度: 1803): Anthropic 正在利用其模型 Claude 加速 AI 开发，该模型目前为未来的模型编写了 70% 到 90% 的代码，这标志着向 递归自我改进 迈出了重要一步。来自 Anthropic 的 Evan Hubinger 表示，全自动 AI 研究可能即将到来，甚至可能在一年内实现。由于安全方面的考虑，Claude 3.7 Sonnet 的发布推迟了 10 天，这突显了 AI 快速进步与安全协议之间持续存在的紧张关系。Dario Amodei 警告说，AI 可能会在五年内取代一半的入门级白领工作，并呼吁对这些影响保持透明。Anthropic 在军事背景下的 AI 部署立场及其对 AI 政策受政治影响的批评也值得关注。一些评论者对安全延误的批评表示质疑，认为既然有 90% 的代码由 AI 生成，彻底的测试对于确保安全至关重要。其他人则回顾了 AI 安全问题的历史背景，提到了 Sutskever 对 GPT-2 的谨慎态度。

• Substantial-Elk4531 提出了一个关于 AI 开发中安全问题的关键观点，质疑了由于这些担忧而导致的模型发布延迟。他们强调了测试 AI 生成代码的重要性，特别是当很大比例（高达 90%）的代码不是由人类编写时，以确保安全性和可靠性。这反映了 AI 社区中关于在创新与伦理考量之间取得平衡的持续辩论。
• BiasHyperion784 讨论了 Anthropic 基础设施升级的时间表，指出到 2027 年第三季度，将部署新的硬件（’rubin ultra’），从而增强计算能力。他们强调训练时间的改进至关重要，因为定制硬件将呈指数级增加处理能力，暗示一旦这些升级完成，AI 能力将实现重大飞跃。

• Pitiful-Impression70 对 AI 自我改进的快速发展表示担忧，像 Claude 这样的模型越来越多地负责编写自己的代码。他们认为这种从人类创作到 AI 驱动开发的转变带来了挑战，因为人类变成了审查者而非创造者，由于缺乏对 AI 生成决策的直观理解，使得监督过程变得复杂。

• Claude 现在可以创建交互式图表、图示和可视化 (Activity: 1174): **Claude 推出了一项新功能，允许用户直接在对话中创建交互式图表、图示和可视化。这些视觉效果是动态生成的，并可以通过后续交互进行修改，增强了对话体验。该功能目前处于 beta 阶段，适用于所有方案，包括免费层级。更多细节可以在其 官方博客 上找到。** 评论者对该功能在教育用途和逻辑流设置方面的潜力充满热情，认为它可能会在某些用户中取代 ChatGPT 等其他工具。人们对其与 Claude 编码能力的集成以及是否能生成这些视觉效果的链接感到好奇。

  • Unlikely_Ad_8060 强调了 Claude 交互式可视化带来的解决问题方式的重大转变。如果这些视觉效果是在推理循环中生成的，它允许用户通过调整参数、测试假设和探索边界情况来迭代地探索问题。这种方法更贴合工程师和分析师的思维方式，从静态输出转向动态的探索过程。
  • trashcanhat 提出了一个关于在 Claude 代码环境中集成这些交互式可视化的技术问题。Claude 发布这些可视化链接的潜力可以增强可用性，暗示了代码执行与视觉反馈之间的无缝集成。
  • Much-Inevitable5083 提供了一个关于使用 Claude 构建交互式图表工具的资源链接，表明已有现成的用例，并且可能为有兴趣利用此功能的用户提供教程或文档。这对于希望实现或了解 Claude 可视化工具技术能力的开发者来说非常有价值。

• 我因为付不起演示视频的费用而将产品发布推迟了几个月。用一个周末的时间使用了 Claude Code 和 Remotion。现在我的 Reels 视频获得了数千次观看。 (Activity: 1152): 该帖子描述了作者如何使用 **Remotion（一个基于 React 的视频生成工具）和 Claude Code 来为他们的产品创建演示视频，从而省去了聘请昂贵的动态图形设计师的需求。通过利用 remotion-transitions 和 frontend-design 等 Claude Skills，作者能够快速生成基于 SVG 的视觉效果和动画 UI 部分，将创建每个 Reels 视频的时间从 3 小时缩短到不到 1 小时。这种方法带来了数千次观看并增加了产品关注度，除 Claude Code 订阅费用外，制作成本为 $0。** 评论指出，虽然生成的视频对于产品演示非常有效，但缺乏专业编辑的精致感。Remotion 因其在制作讲解类视频方面的实用性而受到称赞，尽管它可能不足以应对更复杂的动态设计或角色动画。

• Remotion 被强调为创建产品 demos 和解说短片 (explainer reels) 的强大工具，尽管它可能不适用于更复杂的动态设计 (motion design) 或角色动画。Remotion 和 Claude Code 的结合实现了营销视频的高效制作，无需深厚的设计技能或高昂预算，使其成为初创公司和小型企业的理想选择。
• 讨论中的一个核心见解是，发布产品的真正瓶颈往往在于认为高质量制作需要巨额预算的假设。Remotion 和 Claude Code 等工具的使用证明，创始人可以用极少的资源制作出有效的营销资产。这种方法允许快速迭代和部署，因为视频可以像代码一样进行版本控制 (version controlled)，从而消除了与设计师反复沟通的需要。

• Remotion 和 Claude Code 技术栈因其能将视频视为 React components 处理而受到赞誉，从而实现了版本控制和轻松更新。这种工作流是革命性的，因为它允许对营销视频进行快速更改和重新渲染 (re-rendering)，类似于软件开发过程，这对于行业内的许多人来说是一个新颖的概念。

• 使用了 4 个月的 Claude Code，坦白说最难的部分不是编码 (热度: 1448): 该帖子讨论了使用 **Claude Code 构建完整 iOS app 的挑战，强调虽然 AI 可以有效处理编码任务，但设计决策和针对真实用户的调试更具挑战性。该应用包含 220k lines 代码，尽管进行了广泛的内部测试，但在外部用户测试时仍遇到了诸如交易丢失之类的问题。作者强调了安全性的重要性，使用 Plaid 进行银行连接，并进行 Snyk security audit 以解决漏洞，确保使用 Firestore rules 和 Cloud Functions 安全地管理敏感数据。** 评论者强调了在处理银行详细信息等敏感信息时安全性的重要性，建议过度依赖 AI 进行编码可能会导致意想不到的用户行为和安全风险。此外，还提到了使用 Claude Code 处理 CSS 任务的困难，AI 在应对精确的设计需求时表现不佳。

  • ReddLemon 强调了在使用 AI 生成的代码处理银行详细信息等敏感信息时的关键安全问题。他们警告说，一个“氛围编码产品 (vibe coded product)”可能会导致安全漏洞和潜在的法律问题，并强调了用户与软件交互的不可预测性。
  • CyberMage256 指出了 Claude Code 处理 CSS 的一个具体问题：AI 无法准确理解并执行使按钮高度一致的指令。这表明 Claude 在理解和实现精确设计需求方面存在局限性。
  • KILLJEFFREY 提到了“220k monolith”，可能指大型代码库或项目规模，这在管理和维护上具有挑战性，尤其是使用 AI 生成的代码时。这突显了扩展 AI 辅助开发的复杂性和潜在困难。

• 我曾忽视的两个 Claude Code 功能完全改变了我的使用方式：Stop Hooks + Memory files (热度: 690): 这篇 Reddit 帖子讨论了 **Claude Code 中两个未被充分利用的功能：Stop Hooks 和 Memory Files。Stop Hooks 允许用户在 Claude 完成任务后自动执行后续操作，例如在代码生成后运行 linter，或针对边缘情况审计计划。此功能通过减少人工干预简化了工作流程。Memory Files 解决了长会话或复杂会话中的上下文丢失问题，在每个会话开始时为 Claude 提供一个持久的参考文件，包含项目结构、规范和决策。这使 Claude 从一个简单的自动补全工具转变为一个更可靠的协作伙伴。帖子建议这些功能对于复杂的、多步骤的任务特别有益。** 评论者强调了这些功能的实用性，其中一人建议使用 /btw 命令处理旁支问题，另一人建议对 memory files 采用结构化方法，使用每日日志和精选摘要来防止文件臃肿。人们对为复杂工作流链接 stop hooks 也表现出兴趣，例如在编辑文件后自动执行一系列任务。

• Claude Code 中记忆文件的使用被强调为一项显著的增强功能，像 ‘asklee-klawde’ 这样的用户实现了一个双文件系统：用于原始笔记的每日日志和用于长期上下文的精选 MEMORY.md。这种方法在防止记忆膨胀的同时，保持了对重要信息的获取，优化了 AI 召回和应用项目特定模式及决策的能力。
• Stop hooks 因其在自动化重复任务（如编辑后的自动格式化和运行完整性检查）中的实用性而受到赞誉。用户正在通过链式调用 Stop hooks 来探索更复杂的工作流，例如在编辑文件后自动执行一系列动作，这可能包括运行测试并在成功后提交更改。这减少了人工干预并简化了开发过程。

• “Fork + Rewind” 的概念被讨论为一种高效管理多次更改的方法。这种方法允许用户在分别处理无关更改的同时保持主上下文，从而优化上下文窗口的使用并改进工作流管理。这对于在执行计划后实施多次更改而又不扰乱主上下文特别有用。

• Anthropic 刚刚发布了关于 MCP、Claude Code 及其 API 的免费官方课程 (Anthropic Academy)。 (活动热度: 296): Anthropic 推出了 “Anthropic Academy”，为使用 Claude 的开发者提供免费、全面的课程。该学院包括 13小时 的 Claude API 课程、10小时 的 Model Context Protocol (MCP) 课程、3小时 的 Claude Code 集成课程以及 4小时 的 Agent 技能课程。这些课程旨在帮助用户从基础的 Prompting 转向高级 AI 集成，并提供官方结业证书。可以从这里访问该学院，详细的课程细分可见于 Mindwired AI。评论者强调了课程在从基础 Prompting 转向工程开发方面的价值，强调了 MCP 和 Agent 技能对于现实世界 AI 集成的重要性。他们建议将课程知识与 Runable 或 Replit Agent 等平台结合进行实践应用，并推荐使用 Hasura 和 Kong 等基础设施工具进行有效的后端集成。

• 在 Anthropic Academy 上发布的结构化课程（如 Claude 101 和开发者深度探讨）对于那些从随意 Prompting 转向工程开发的人来说意义重大。这些课程强调 Model Context Protocol (MCP) 和 Agent 技能，表明了向将 AI 集成到真实开发工作流的转变。这些知识可以与 Runable、Replit Agent 或 V0 等执行平台结合，以构建功能原型，增强课程材料的实际应用。
• 高级的 MCP 内容对于设计可长期维护的工具层非常有价值。课程鼓励将工具建模为小型、可组合的动词（verbs），将状态和策略保持在 Agent 外部。一种实用的方法是在学习过程中将真实的后端（如 Postgres）集成为 MCP 服务器，并加入日志记录、速率限制和人工审批流，以便尽早了解潜在挑战。这种方法与使用 Hasura 实现类型化 GraphQL、使用 Kong 或 Tyk 实现网关策略以及使用 DreamFactory 将传统 SQL 暴露为 REST 端点等基础设施模式高度契合。

2. DeepSeek V4 及其相关猜测

• 也许是 DeepSeek 4？ (Activity: 325): 图像描绘了 OpenRouter 应用的移动界面，展示了 AI 模型列表，包括 “Hunter Alpha” 和 “Healer Alpha”。”Hunter Alpha” 被描述为用于 Agent 用途的前沿智能模型，而 “Healer Alpha” 则以全模态能力（包括视觉和推理）著称。这暗示了对先进 AI 功能的关注，可能预示着 AI 模型能力的新开发或发布。音量控制叠加层的出现暗示该应用可能具有音频功能或集成。 一位评论者提到在 opencode 中测试了这些模型并对其性能表示赞赏，指出它们明显优于之前的模型。另一位评论者猜测了这些模型的来源，认为由于它们能够处理未经审查的查询，可能并非来自中国，并猜测它们可能是 Grok、Mistral 或其他模型，但不是 Gemini 或 GPT。

  • Shoddy-Department630 推测所讨论的模型不太可能是 DeepSeek，因为它能够处理通常会被中国 AI 模型审查的查询。他们认为这可能是 Grok 模型或 Mistral，并指出它也不像 Gemini 或 GPT 模型，表明其具有独特的运行行为或架构。
  • Traveler3141 提出了该模型是 Qwen 4 的可能性，认为它可能是现有模型的新迭代或版本。这意味考虑到近期 AI 模型的进展或发布，可能与观察到的性能和特性相符。
  • peva3 分享了在开源代码环境中使用该模型的积极体验，称其明显优于他们使用过的其他模型。这表明在性能或能力上有显著提升，尽管没有提供具体的指标或对比。

• DeepSeek V4 确认了？ (Activity: 316): 该图片似乎是来自一个即时通讯应用的截图，其中用户询问了台湾作为一个国家的地位，而回答符合中国的“一个中国原则”。标题“DeepSeek V4 确认了？”暗示了对软件或 AI 模型新版本的猜测，可能与回答风格或内容有关。然而，评论显示出对这是否确实与 DeepSeek V4 有关持怀疑态度，一位用户建议这可能是一个中国模型，但不一定是 DeepSeek。 一条评论指出，该回复可能来自某个中国模型而非 DeepSeek，这引发了关于提供回复的 AI 的来源或性质的争论。

• 终于近了 (Activity: 249): 图像看起来是一个与名为 “DeepSeek-V4-INT8” 的机器学习模型相关的非技术性梗图（meme）或预告。图中列出的文件路径表明关注点在该模型的特定版本或迭代上，可能预示着即将到来的发布或重大开发里程碑。标题“终于近了”暗示了对项目的期待或最终成果，但由于缺乏进一步的背景或技术细节，这仍然属于推测。 评论反映了怀疑和期待，一位用户幽默地称其为“预测市场诱饵（betting market bait）”，另一位用户则在询问来源，表明关于该模型的发布或开发状态缺乏具体信息或确认。

3. OpenClaw 在中国的安装

• 人们在中国免费安装 OpenClaw。数千人排队安装 OpenClaw。 (Activity: 134): **Tencent 正在中国深圳推动 OpenClaw 的免费安装，利用其 Tencent Cloud’s Lighthouse 平台，该平台仍能从云端资源使用中产生收入。此活动针对的是在激烈的职场竞争和被 AI 取代的恐惧中渴望采用 AI 技术的白领专业人士。这次被冠以慈善名义的安装活动凸显了中国拥抱新技术的文化热忱，这种热忱更多是由焦虑和地位压力而非特定应用驱动的。** 评论者对 OpenClaw 的安全风险表示担忧，指出用户在不了解软件的情况下就授予了其重要的访问权限。还有人提到了移除 OpenClaw 的相关费用，大约为 500 RMB。

• 讨论强调了一个重要的文化和经济视角，即为什么 OpenClaw 在中国比 Manus 更受欢迎。OpenClaw 被比作“买房”，因为它是开源的，允许用户通过将其安装在自己的硬件上来拥有基础设施，且仅产生 API 调用费用。相比之下，Manus 被描述为“豪华租房”，因为它采用封闭箱式的 SaaS 模式，用户按月付费并按积分扣费，这对于那些更看重所有权而非租赁的人来说吸引力较低。
• 讨论中提到了对 OpenClaw 安全性的担忧，用户对安装此类软件的信任度表示怀疑，尤其是当由第三方完成安装时。虽然承认了 OpenClaw 的开源性质，但人们担心用户如果不亲自验证安装过程，可能会导致安全漏洞。

• 提到了从机器上卸载 OpenClaw 的成本，具体金额约为 500 元人民币。这表明虽然初始安装可能是免费的，但其移除过程存在隐藏成本，这可能成为以后决定不再使用该软件的用户的一个潜在障碍。

• People are getting OpenClaw installed for free in China. As Chinese tech giants like Alibaba push AI adoption, thousands are queuing. (Activity: 125): Tencent 正在中国深圳通过一项公益活动促进 OpenClaw 的免费安装，尽管这些安装仍在使用 Tencent Cloud 的 Lighthouse，从而确保 Tencent 能从云端使用中获益。该倡议是 Alibaba 等中国科技巨头推动 AI 普及的更广泛行动的一部分。该活动针对的是因工作压力和担心被 AI 取代而渴望采用 AI 技术的白领专业人士。OpenClaw 是一款开源的 AI Agent，用户可以安装在自己的硬件上，这与 Manus 等封闭箱式 SaaS 模式形成对比，后者需要持续付费且所有权较低。这反映了中国文化中对拥有数字资产（类似于拥有房地产）而非租赁的偏好。评论者强调了中国对拥有数字资产的文化偏好，将 OpenClaw 比作拥有房地产，而 Manus 则被视为租赁模式。这种偏好源于对数字基础设施控制权和权益的渴望，与 SaaS 模式的持续成本和缺乏所有权形成对比。

• Manus 和 OpenClaw 之间的对比突显了中国在 AI 采用方面的重大文化和技术转变。Manus 以封闭箱式 SaaS 模式运行，要求用户支付月费并使用积分，这可能具有限制性。相比之下，OpenClaw 是开源的，允许用户安装在自己的硬件上，实际上赋予了他们 AI 基础设施的所有权。这符合中国人更倾向于拥有数字资产（类似于拥有房地产）而非租赁的偏好，这被认为是一种更具可持续性和成本效益的方法，尤其是在 DeepSeek 和 Qwen 等国内模型降低了运营成本的情况下。
• 在中国社区中，将 OpenClaw 比作“养小龙虾”的类比，强调了对拥有和定制技术的文化价值。这个隐喻暗示了与技术的一种培养关系，用户随着时间的推移投资并增强其 AI 能力，这与 Manus 等 SaaS 模式的短暂性质形成对比。国内 AI 模型极具竞争力的定价进一步支持了这种所有权模式，使得本地运行 OpenClaw 在经济上极具吸引力。
• 讨论触及了 AI 采用的更广泛影响，OpenClaw 的模式允许用户通过在本地基础设施上构建自定义工作流来成为“数字房东”。这种方法不仅减少了对外部 SaaS 提供商的依赖，还使用户能够创造持久的数字资产权益。国内 AI 模型之间持续的价格战进一步激励了这种转变，因为本地运行 OpenClaw 变得越来越具有成本效益，挑战了传统 SaaS 模式的主导地位。

AI Discords

遗憾的是，Discord 今天关闭了我们的访问权限。我们不会以这种形式恢复它，但我们很快就会发布全新的 AINews。感谢阅读到这里，这是一段美好的历程。