Open Source

上周，里约热内卢市政府高调发布了名为 Rio-3.5-Open-397B 的大语言模型，官方说法是"由 IplanRIO（里约市政 IT 公司）自主训练的 397B 参数模型"。模型发布后，巴西媒体一片欢腾——这可是全球首个由市政当局发布的前沿级 AI 模型，还号称在多项基准测试中超过了 Qwen 3.7 Plus。 然后，48 小时之内，Nex-AGI（一家来自上海的 AI 实验室）在 GitHub 上发了一条 issue，用两种完全独立的方法证明：这个模型的每一个权重，都是 Nex-N2-Pro 和 Qwen3.5-397B-A17B 按 6:4 比例线性混合的结果。 不是微调，不是蒸馏，是直接把两个模型的权重按比例倒在一起。 身份探针：去掉系统提示词后，模型自己说了实话 Rio-3.5-Open-397B 附带了一个硬编码的系统提示词：“You are Rio, a large language model developed by IplanRIO。“这个提示词在每次推理时都会被注入，强制模型"记住"自己的身份。 Nex-AGI 做了一件很简单的事：把这个系统提示词删掉，然后问模型"你是谁”。 他们在去除了身份强制的情况下，向 Rio 的部署端点发送了 120 次身份提问。结果如下： 模型回答"我是 Nex"的比例：79.2%（95/120 次） 模型回答"我是 Nex-AGI 的"比例：73.3%（88/120 次） 模型回答"我是 Rio"的比例：0.0%（0/120 次） 零。一次都没有。 更离谱的是，模型还能逐字背出 Nex-AGI 的组织背景——“Nex-AGI is a large-model ecosystem alliance, jointly built by the Shanghai Innovation Institute（上海创智学院）…"——这段文字是 Nex-AGI 在训练自己的模型时注入的专属身份数据，出现在数百条训练样本中。 ...

两天之内 4700+ Star，241 条 HN 评论——小米 MiMo Code 的发布在开发者社区引起了不小的波澜。但让我真正感兴趣的不是这个数字本身，而是它背后的策略：fork 一个已经有 17 万 Star 的开源项目 OpenCode，然后在上面叠加自己的东西。 坦白说，“大厂 fork 开源项目"这件事本身就自带争议。HN 评论区有人直接开喷：“fork 一个已有的开源项目，不给上游贡献代码，附加可能跟 MIT 许可证冲突的使用限制，然后还要 PR。“但也有另一种声音：如果 fork 出来的东西确实有实质性的技术创新，那这件事本身就有讨论的价值。 所以这篇文章想回答的核心问题是：MiMo Code 到底加了什么？这些加的东西值不值得一个独立项目的存在？ 从 OpenCode 到 MiMo Code：不是换层皮那么简单 先说上游项目。OpenCode（现在叫 opencode）是一个终端原生的 AI 编程助手，17 万+ Star，TypeScript 写的，支持多 Provider、TUI 界面、LSP、MCP 协议和插件系统。它在 2025 年 4 月创建，到现在已经迭代了一年多，是终端编程 agent 领域里用户量最大的开源项目之一。 MiMo Code 保留了 OpenCode 的所有核心能力——多 Provider 切换、TUI 交互、LSP 集成、MCP 工具协议和插件系统——在此基础上叠加了五个关键模块。从源码结构看，它在 packages/opencode 目录下保留了 OpenCode 的核心代码，同时新增了 packages/app、packages/desktop、packages/enterprise、packages/sdk 等模块，看起来不只是一个 CLI 工具，而是一个完整的平台化产品。 持久化记忆系统 —— 这可能是最有意思的部分。它用 SQLite FTS5（全文搜索）做底层存储，维护一个 MEMORY.md 文件作为跨会话的项目知识库。每次你开新会话，记忆自动注入上下文，agent 不需要重新理解项目结构。 ...

最近 HN 上有篇帖子引起了我的注意：一个叫 Lathe 的开源项目，247 points，标题是"Use LLMs to learn a new domain, not skip past it"。 说实话，看到这个标题的第一反应是：又一个 LLM 教学工具？市面上这类东西已经太多了——NotebookLM、各种 AI tutor、ChatGPT 自己就能教你任何东西。但仔细看完 README 和 HN 评论区之后，我觉得这个项目抓住了一个很多人没说出口的痛点。 问题出在哪？ 过去一年，“Vibe Coding"这个概念从 Andrej Karpathy 的一条推文变成了整个行业的主流工作方式。打开 Claude Code、Cursor 或者 Copilot，描述你想要什么，AI 帮你生成代码，你负责 Review 和微调。效率确实高，但这里有一个很少被正面讨论的问题：你到底学到了什么？ HN 上另一篇今天 807 points 的帖子——“LLMs are eroding my software engineering career”——把这个焦虑写得很直白。一位资深工程师说，LLM 正在侵蚀他的软件工程职业，他不知道该怎么办。评论区里各种声音都有，但核心矛盾其实就一个：当 AI 代劳了思考过程，工程师的价值在哪里？ 这不是杞人忧天。看看现在的 AI 编程成本追踪工具（比如 Budi）就知道，很多团队每个月在 AI 编程上的开销已经不小了。但如果你问这些开发者"你从 AI 生成的代码里学到了什么”，大部分人会沉默。 Lathe 的反直觉设计 Lathe 的作者 Deven Jarvis 在 README 里写了一段很长的个人经历，我读完觉得挺真诚的。他在 2000 年代通过 PSP 自制游戏社区学会了编程，后来通过各种 hands-on 教程（build-your-own-x、Crafting Interpreters 这类）不断精进。他说这些教程给他的不只是知识，更是"从零到一"的信心和继续深入的底气。 ...

如果你用过 Claude Code、Codex CLI 或 Cursor 这类编程 Agent，大概率见过一种很烦人的失败模式：它明明已经读完文件，却又回头读一遍；明明应该先写测试，却开始大面积重构；明明只是修一个 20 行 bug，却顺手动了 6 个模块。最后 token 花了，diff 也出来了，但你不敢合并。 我越来越觉得，这不是“模型不够聪明”一个问题。 更准确地说，是我们把 Agent 放进了一个没有交通规则的城市：Read、Grep、Edit、Bash、Web、MCP 工具全都摊在它面前，然后指望一段系统提示词告诉它“请谨慎驾驶”。提示词当然有用，但它不是刹车，也不是红绿灯。 这也是 Statewright 最近在 HN 上引起我注意的原因。它的口号很硬：Agents are suggestions, states are laws. 用人话翻译：不要只靠模型“自觉”，把工作流拆成确定状态，在每个状态里只开放它该用的工具。 状态机不是新概念，但放在 Agent 上刚好戳中痛点 Statewright 做的事情并不神秘。它让你定义一个工作流，例如 planning → implementing → testing → completed。在 planning 状态里，Agent 只能读文件、搜索代码；进入 implementing 以后才允许 Edit/Write；到 testing 状态，Bash 可以用，但只能跑 pytest、cargo test、npm test 这类白名单命令。 项目 README 里的示例很直观：planning 只给 Read/Grep/Glob，implementing 允许 Read/Edit/Write 且限制 max_edit_lines、max_files_per_state，testing 才给 Bash，并且通过 guard 判断测试是否通过。官方的 workflow schema 也把这些字段明确写成结构化配置，而不是自然语言建议。 ...

如果你正在做 AI Agent，有一个问题很容易被忽略：Agent 到底需不需要一个很大的模型来“选择工具”？ 我以前默认答案是“需要”。毕竟工具调用看起来像推理：用户说“明天早上 8 点提醒我带伞”，模型要理解意图、找到日历或提醒工具、抽取时间、地点和参数，最后输出一段合法 JSON。让 7B、14B 甚至更大的模型来做，似乎很自然。 但这两天 HN 上的 Needle 把这个直觉反过来了。Cactus 团队开源了一个只有 26M 参数的 function calling 模型，README 里说它是把 Gemini 3.1 的工具调用能力蒸馏到一个 “Simple Attention Network” 上，目标是跑在手机、手表、眼镜这类消费设备上。项目目前 MIT 开源，代码在 cactus-compute/needle，权重放在 Hugging Face。 26M 是什么概念？比很多 embedding 模型还小，比常见的 0.5B/1.5B 小模型又小一个数量级。它不打算写诗、聊天、做数学题，只做一件事：给定用户 query 和工具 schema，吐出应该调用的工具及参数。 坦白说，我觉得这个方向比“又一个端侧聊天机器人”更值得写。因为生产里的 Agent 系统，最先遇到瓶颈的往往不是“模型不够聪明”，而是“每一步都太贵、太慢、太不稳定”。 把工具调用从“推理”降级成“路由” Needle 的核心判断很激进：单轮工具调用本质上不是开放式推理，而是 retrieval-and-assembly。 用人话说，就是三步：先从工具列表里匹配哪个工具最像用户意图；再从用户句子里抽参数；最后按 schema 拼成 JSON。这个过程当然需要语言理解，但它未必需要一个装满世界知识的大模型。工具说明和参数 schema 已经作为输入给了模型，事实知识在上下文里，不必塞进 FFN 权重里。 这也是它的架构为什么反常。Needle 的 Simple Attention Networks 文档 里明确写到：实验发现，如果任务依赖外部结构化知识，Transformer 里的 MLP/FFN 可以被完全拿掉，模型主要靠 attention 和 gating 工作。Needle 的结构是 12 层 encoder 加 8 层 decoder，隐藏维度 512，8 个 attention head，BPE 词表 8192；README 还强调 “no MLPs anywhere”。 ...

你有没有这种感觉：每天早上醒来，前一天学的东西大部分都忘了？ LLM 就是这样工作的。 每个对话 session，模型都是从零开始。它不记得你是谁，不记得你上次做了什么决定，更不记得那个方案三个月前就试过并且失败了。你花 20 分钟解释背景，下一个 session 又得重来一遍。 这不是 AI 的 bug——这是架构限制。大多数 Agent 的"记忆"，就是把整段对话历史塞进 prompt，靠上下文窗口撑着。贵、慢，而且换一个新 session 照样失忆。 Stash 想要解决这个问题。它的 slogan 很直接：Your AI has amnesia. We fixed it. 这个项目是做什么的 Stash 是一个开源的持久化记忆层，专门给 AI Agent 用。它不是一个聊天机器人，而是一个基础设施——在 Agent 和外部世界之间加了一层认知处理管道。 核心思路：Episodes become facts. Facts become patterns. Patterns become wisdom. AI 的每一次对话、每一个决定、每一次成功和失败，都被记录下来，经过一个 8 阶段的管道，转化成结构化的知识。事实与事实之间建立关联，关联形成模式，模式沉淀为真正的理解。 原始对话 ↓ Episode 记录（原始事件） ↓ Fact 提取（去掉了时间戳和情绪的事实） ↓ Relationship 建立（事实之间的连接） ↓ Pattern 检测（反复出现的模式） ↓ Goal Tracking（目标状态） ↓ Failure Pattern（失败教训） ↓ Hypothesis & Confidence（假设与置信度衰减） ↓ Wisdom（长期知识） 这个管道是增量的——每次运行只处理新数据，不会重复劳动。 ...

如果你在生产环境跑过 AI Agent，大概率遇到过一个头疼的问题：Agent 怎么安全地访问那些需要 API Key 的服务？ 传统方案很简单：把密钥配置在环境变量里，Agent 启动时读取。但这套逻辑是给"确定性程序"设计的——程序行为可预测，不会被外部指令诱导去做你没想过的事。 AI Agent 不一样。它们是非确定性的，能被 prompt injection 诱导，能被恶意网页操纵，能在 RAG 流程里接收有害指令。密钥一旦进了 Agent 的上下文，就等于随时可能被抽走。 这是一个真实存在的威胁，不是理论推演。Infisical 最近的博客详细描述了攻击路径：攻击者通过文档注入、恶意网页或工具调用让 Agent “主动"把环境里的密钥发到攻击者控制的端点。哪怕你上了多层 guardrails，也没有办法保证 Agent 绝对不泄露。 传统解法为什么不够用 业界的应对思路大概分三类： ① 短命凭证（Short-lived Tokens） OAuth2 的 access/refresh token 模式，API 返回临时凭证，过期自动失效。配合自动化密钥轮换，攻击者拿到的那串字符很快变成废纸。 听起来合理，但本质上只是降低窗口期，没有解决根本问题——凭证依然会泄露，攻击者只要在失效前用完就赚了。 ② 防火墙和网络隔离 只允许 Agent 访问特定 IP 段，不允许出站直连。攻击者通过 Agent 发起请求，同样会经过那些被允许的端点，该泄露还是泄露。 ③ 自行实现凭证代理 Anthropic 的 Managed Agents 架构、Vercel 的 credential brokering、Cloudflare 的 outbound workers，都走了同一条路：Agent 的请求经过一个代理层，由代理负责在请求发出前把凭证注入，Agent 自己从不直接接触密钥。 这条路是对的，但每家公司都得自己造轮子。 Agent Vault 的思路 Infisical 新开源的 Agent Vault 把这条路做成了通用产品。它的核心设计原则只有一条：Agent 永远拿不到金库里的密钥，只能通过代理间接使用。 ...

如果你在生产环境里接入了两个以上的 LLM 提供商（OpenAI、Anthropic、Gemini、Groq……），大概率已经踩过这些坑：供应商的 API 格式不统一、重试逻辑要写 N 份、想把 Claude 和 GPT 的调用日志合并看也做不到、换个供应商代码要改一大坨。 这就是 AI Gateway 存在的意义——在你和所有模型供应商之间加一层抽象，对外暴露统一的 OpenAI 兼容 API，你改供应商只需要改配置，不用动业务代码。 这个赛道最知名的是 LiteLLM（Python），今天要聊的是一个用 Go 写的竞争方案——GoModel，4 个月时间，511 Stars，GitHub 最后一次提交就在昨天。 背景：多供应商困境 先说个真实的场景。 你做 AI 产品，接入了 GPT-4o 做主力、Claude Sonnet 做复杂推理、Gemini 2.5 Flash 做快速摘要。三个供应商，三套 SDK，三套错误处理，三套重试策略，三套计费逻辑。然后产品经理说：「能不能把这个月各模型 token 消耗做个报表？」 你翻了三天日志，发现各家日志格式完全不一样，计量单位都不统一。这就是为什么需要一个 AI Gateway——它把所有调用收敛到一个统一的接口，同时帮你把日志、计费、缓存这些事情做好。 LiteLLM 是这个方向最成熟的开源方案，但它是 Python 写的，GIL 限制了并发能力，而且配置相对复杂。 GoModel 是什么 GoModel 是来自波兰华沙的独立开发者 Jakub（GitHub @santiago-pl）的作品，2024 年 12 月开始开发，定位是高性能 AI Gateway，用 Go 编写，对外暴露完整的 OpenAI 兼容 API。 核心特性： 11 家供应商支持：OpenAI、Anthropic、Google Gemini、xAI Grok、OpenRouter、Z.ai、Azure OpenAI、Oracle Cloud AI、Ollama、vLLM OpenAI 兼容端点全覆盖：/v1/chat/completions、/v1/embeddings、/v1/files、/v1/batches 双层响应缓存：精确匹配缓存 + 语义缓存（基于向量相似度），官方案例中语义缓存将命中率从 18% 提升到 60-70% Guardrails：可配置的请求/响应过滤管道 Provider Passthrough：原生端点透传（/p/{provider}/...），绕过网关直接访问供应商特性 Admin API：用量统计、Token 消耗追踪、审计日志 说白了就是：LiteLLM 能做的 GoModel 基本都能做，但用 Go 写的，高并发下性能更好，内存占用地更低。 ...

如果你只有一台 Mac 电脑，想从单张图片生成 3D 模型——直到今天，这基本上是个伪需求。市面上最好的开源图片转 3D 技术，几乎全部围绕 NVIDIA CUDA 构建，买不到合适的硬件就等于玩不了。 这个局面正在被打破。 TRELLIS.2 是微软 2025 年发表在 CVPR 的论文提出的图片转 3D 方法，在 GitHub 上有 1.2 万星，官方仓库清一色 CUDA 代码。近日有个开发者把它完整移植到了 Apple Silicon，M4 Pro 上 3.5 分钟就能生成一个 40 万顶点的网格模型，全程跑在苹果自研芯片上，不需要半块 NVIDIA 显卡。 移植的核心思路：替换掉 CUDA 依赖 TRELLIS.2 依赖好几个 CUDA 专用的库，官方版本开箱即用但根本不支持 Metal。这不是简单的编译选项问题，而是代码里大量硬编码了 .cuda() 调用和 CUDA 核函数。 移植的思路很直接：找到每一个 CUDA 依赖，用 PyTorch 原生功能或纯 Python 实现替换。 主要替换关系如下： 原始（CUDA） 移植版本 用途 flex_gemm backends/conv_none.py 子流形稀疏 3D 卷积，通过 gather-scatter 实现 o_voxel._C hashmap backends/mesh_extract.py 从双体素网格提取网格面 flash_attn PyTorch SDPA 稀疏变换器的注意力机制 cumesh Stub（跳过） 网格孔填充与简化 nvdiffrast Stub（跳过） 可微分光栅化（仅影响纹理导出） 稀疏 3D 卷积的替换是个技术亮点。原始 flex_gemm 做的是子流形稀疏卷积——3D 生成任务中只有物体表面有数据，不需要对整个空间做卷积。移植版本用 Python 构建空间哈希表，对每个活跃体素收集邻域特征，通过矩阵乘法应用权重，再把结果 scatter 回去。neighbor maps 做了缓存避免重复计算。 ...

真实案例引入：一次生产事故揭开的盖子 2025 年中，某团队的 AI 编码助手在凌晨两点突然崩溃——他们在 Ollama 上跑的好好的 GPT-OSS 20B 模型突然报 GGML tensor type 不支持的错误。同一模型，在 llama.cpp 上运行完全正常。 这不是孤例。2025 年 GitHub 上关于 Ollama 的 issue 爆发式增长：#3185（许可证问题，400 天无回应）、结构化输出失效、视觉模型崩溃、多版本 GGML assertion crash。社区反复报告同一个事实：Ollama 自 2025 年中从 llama.cpp 后端切换到自研 ggml 分支后，引入了 llama.cpp 早已解决的 bug。 这场崩溃的根源，要从 Ollama 的诞生说起。 背景：Ollama 的起源与商业模式 Ollama 由 Jeffrey Morgan 和 Michael Chiang（曾主导 Docker GUI 工具 Kitematic）于 2021 年创办，入选 Y Combinator Winter 2021，2023 年正式公开。核心卖点是"Docker for LLMs"——一条命令下载运行模型。 然而，Ollama 的全部推理能力来自 llama.cpp：Georgi Gerganov 于 2023 年 3 月用一晚上 hack 出来的 C++ 推理引擎，让 LLaMA 模型首次能在消费级笔记本上运行。llama.cpp 如今 GitHub 104,280 stars，450+ 贡献者，是几乎所有 GGUF 工具的底层依赖。 ...