Redis 作者回来了，这次要把 284B 模型塞进你的 MacBook
Redis 作者回来了，这次要把 284B 模型塞进你的 MacBook
antirez/ds4 (DwarfStar)
antirez 回来了。Redis 作者 Salvatore Sanfilippo 时隔七年重新写代码，这次不是数据库，是推理引擎。ds4 只干一件事：让 DeepSeek V4 Flash 在你的 MacBook 上跑起来——不是跑个 demo 那种，是真的能拿来写代码的那种跑。
为什么现在火？两个 timing 叠加：DeepSeek V4 刚出，284B 参数但 MoE 架构让实际激活量小得多；同时 llama.cpp 和 vLLM 都在死磕”GPU 内存是瓶颈”这条路线。antirez 直接说——你们搞反了。KV cache 不该住在内存里，它该住在磁盘上，就像 Redis 的数据天然属于磁盘，只是恰好可以被热加载到内存。这个哲学翻转的直接后果：2-bit 量化 + 磁盘 KV cache = 284B 模型在 96GB MacBook 上跑，还能开 100 万 token 上下文窗口。这在 vLLM 的框架里是不可能的。
真正的亮点不是速度数字（虽然 M5 Max 跑到 34 t/s 也不慢），而是 ds4-agent。这不是外挂的 Agent harness，是推理引擎原生内置的 coding agent。Agent 的 KV session 可以保存、切换、恢复——你的 Agent 真的可以”睡一觉醒来继续思考”，而不是每次从零开始 prefill 25k token 的 system prompt。配合 SHA1-key 的增量 prefill，这意味着长项目的推理成本可以降到原来的几分之一。
有 MacBook Pro 的独立开发者、想在本地跑大模型又不想付 API 费的团队——ds4 值得认真试。但注意这是 beta 代码，antirez 自己说的。
我的判断：ds4 会在 Mac 用户圈子里快速传播，因为它是目前唯一能让 284B 模型在笔记本上真正干活的方案。但 vLLM 阵营不会坐视不管，磁盘 KV cache 会变成标准功能。antirez 真正的贡献不是代码，是那个哲学翻转——“KV cache 是磁盘一等公民”。这个观念一旦被接受，推理引擎的架构都会跟着变。
vercel-labs/zerolang
Vercel Labs 做了一门编程语言，专门给 Agent 写的。叫 zerolang。slogan 就一行：The programming language for agents。
为什么这东西值得看？当前 Agent 写代码用的是 Python/TypeScript/Rust——全是给人设计的语言，Token 效率低、启动慢、依赖重。zerolang 的四个优化目标说得明白：Token 效率、低内存、快启动、零依赖。这不是又一门玩具语言，这是 Vercel 在认真想一个问题——如果编译器从第一天起就要和 Agent 配合，它应该暴露什么样的接口？
亮点在编译器的 CLI 设计。zero check --json 输出的诊断包含稳定的 code/span/repair metadata，不是散文；zero fix --plan --json 给出类型化修复计划但不直接改文件；zero skills get language 随编译器二进制一起发布版本匹配的规则文本。这些接口不是给人读的 man page，是给 Agent 消费的 JSON 契约。这是第一个把”编译器是 Agent 的工具”这件事认真做进语言内核的尝试。
Agent 框架作者、对”Agent 怎么和编译器交互”感兴趣的人——值得 study 它的 CLI 设计，不一定要用这门语言。
我的判断：zerolang 本身大概率不会替代 Python/TypeScript，但它暴露的那套 JSON 契约接口会被其他语言生态抄走。真正有价值的不是 .0 后缀，是 zero check --json 和 zero fix --plan --json 的设计思路——编译器把诊断和修复计划结构化输出，Agent 就不需要 parse 散文报错了。
strukto-ai/mirage
mirage 干了一件很直觉但没人认真做过的事：把 S3、Google Drive、Slack、Gmail、Redis、SSH 这些后端全挂成一棵 Unix 目录树。Agent 只需要 ls/cat/grep/cp，就能操作所有服务。
为什么现在才有人做这个？因为 MCP 刚把”Agent 怎么调工具”标准化了，但每个 MCP server 还是一个独立的 API。Agent 拿到 20 个 MCP tool，得写 20 套调用逻辑。mirage 说：不用，我把 20 个后端统一成一个文件系统，你用 Unix 管道就行。grep alert /slack/general/*.json | wc -l——一条命令跨 Slack + 本地计算。LLM 训练语料里 bash 的占比远超任何 SDK，mirage 让 Agent 直接站在这个优势上。
亮点是跨服务管道。以前你要从 Slack 拉数据写到 S3，得写胶水代码或者用 n8n 拖线。mirage 里一条 cp /s3/report.csv /data/local.csv 就完事了。两层缓存（Index + File）让重复查询不走网络，RAM 或 Redis 后端可选。
DevOps、SRE、需要把多个 SaaS 数据源串起来的自动化开发者——mirage 能直接替换你手写的胶水代码。Python/TypeScript 双 SDK，嵌入 FastAPI/Express 都行。
我的判断：mirage 的”一切皆文件”哲学在 Agent 圈子里会很快被接受，因为 LLM 本来就最擅长写 bash。但它面临的风险是：如果主流 Agent 框架（Claude Code、Codex）开始内置类似能力，mirage 就变成中间层了。短期看，先装先用，比等框架原生支持快得多。
heygen-com/hyperframes
HeyGen 做了个视频渲染框架，叫 Hyperframes。核心主张：写 HTML，输出视频。不需要 React，不需要 build step，不需要 webpack。
为什么突然有人关注？因为 Agent 已经能写 HTML 了，但现有的视频方案（Remotion）要求 Agent 写 React 组件 + 打包配置——这完全是浪费。Agent 写个 <div data-start="0" data-duration="5"> 比写一个 const MyComposition: React.FC = () => 高效得多。Hyperframes 的 HTML-native 路线让 Agent 直接用自己最擅长的格式产出视频内容，确定性渲染，同输入永远同输出。
亮点是 Frame Adapter 模式：GSAP、Lottie、CSS 动画、Three.js 都能接入，而且 seekable——可以跳到任意帧，不用从头播放。50+ ready-to-use blocks，从社交叠加层到 shader 转场都有。Apache 2.0 完全开源，这点比 Remotion 的 source-available 许可强。
做内容自动化的开发者、需要 Agent 批量生产视频的团队——Hyperframes 值得试。npx hyperframes init my-video 五分钟能跑通。
我的判断：Hyperframes 和 Remotion 不是替代关系，是两条路线的选择。HTML vs React，零配置 vs 必须打包，完全开源 vs 商业许可。对 Agent 来说，HTML 路线明显更自然。但 Remotion 在生产级渲染上积累更深，Lambda 支持更成熟。短期内两者共存，长期看 Agent-native 的视频场景里 Hyperframes 会赢。
nexu-io/html-anything
html-anything 是一个”Agentic HTML Editor”——它不自己提供 Agent，而是自动检测你机器上装了哪个 coding-agent CLI（Claude Code、Cursor、Codex、Gemini CLI、Copilot CLI、OpenCode、Qwen Coder、Aider，8 个），然后用你已有的登录 session 生成 HTML。
为什么这东西有意思？Anthropic 的 Claude Code 团队公开说过他们不再用 Markdown 写内部文档了，改写 HTML——因为 HTML 是给读者看的，Markdown 是给写者看的。html-anything 把这个思路产品化了：75 个 skill templates 覆盖 9 种输出格式（杂志文章、Keynote 幻灯片、海报、小红书卡片、推文卡片、Web 原型、数据报告、Hyperframes 视频），一键导出到微信公众号/X/知乎/HTML/PNG。
亮点是零 API key。它不自己调用模型，而是 spawn 你已经登录的 CLI 进程，复用你的订阅。SSE streaming 让你在浏览器里看着 Agent 逐字写 HTML，sandboxed iframe 预览保证安全。Anti-AI-slop 硬约束（CJK 字体、8px 基线、对比度≥4.5）防止生成那种”一眼 AI”的东西。
内容创作者、做公众号/小红书运营的、想把 Markdown 工作流升级到 HTML 的——html-anything 目前是这个方向上最完整的方案。
我的判断：html-anything 的真正价值不在编辑器本身，在 75 个 skill templates。编辑器谁都能做，但那种”CJK-first font stack + 8px baseline grid + contrast≥4.5”的硬约束是积累出来的。短期看，做中国内容市场的 Agent 工具，html-anything 是最实用的。但 75 个 skills 的维护成本会越来越高，社区贡献质量参差不齐，这是隐患。
googleapis/mcp-toolbox
Google 出了个 MCP server，专门连数据库的。前身叫 genai-toolbox，现在改名 mcp-toolbox 对齐 MCP 标准。
为什么值得关注？因为 Google 在 MCP 生态里从旁观者变成了参与者。这个工具双模式运行：prebuilt tools 开箱即用（连 PostgreSQL/BigQuery/Spanner 只要一行配置），custom tools 框架让你写结构化查询和 NL2SQL。20+ 数据库支持，Python/JS/Go/Java 四个 SDK，OpenTelemetry 内置。skills-generate 命令能把 toolset 直接转成 Agent Skill——Google 自己在推 agentskills.io 标准。
亮点是 prebuilt 模式。以前给 Agent 接数据库，你得自己写 MCP server、处理连接池、做鉴权。现在 npx @toolbox-sdk/server --prebuilt=postgres --stdio 一行搞定。对 Gemini CLI、Claude Code、Codex 都直接可用。
数据工程师、需要给 Agent 接数据库的团队——mcp-toolbox 目前是 MCP 数据库接入层里覆盖最广的方案。
我的判断：Google 入场意味着 MCP 不再只是 Anthropic 的小圈子游戏。但 mcp-toolbox 的 prebuilt 模式目前偏 Google Cloud 生态（AlloyDB、Cloud SQL、Spanner、BigQuery），对非 GCP 用户吸引力有限。真正让人兴奋的是 skills-generate 命令——如果每个 MCP server 都能一键转成 Agent Skill，MCP 生态的碎片化问题就有解了。
mksglu/context-mode
context-mode 解决的是 AI coding agent 的”上下文爆炸”问题——tool output 太长，塞进上下文窗口就占掉大半。它的方案是沙盒化 tool output，声称 98% 的上下文降幅，15 个平台支持。
坦白说，这个项目信息不多。README 很长但核心内容不集中。ELv2 许可证不是 OSI 认可的开源协议，这对企业采用是个障碍。
上下文窗口管理确实是 Agent 的真实痛点，但目前解决方案太多了——Serena 的语义检索、ds4 的磁盘 KV cache、各框架自带的 compaction 都在解决同一层问题。context-mode 的沙盒化思路有差异，但还没看到足够的生产验证。
我的判断：值得观察但不急用。98% 降幅这个数字需要更多第三方验证。ELv2 许可证是个扣分项——如果你在选上下文优化工具，Serena（MIT）和 ds4 的磁盘 KV 方案都比这个更开放。
anomalyco/opencode
opencode 是个开源 coding agent，内置两个 agent：build（完整权限）和 plan（只读分析）。Tab 键一键切换。
双 agent 设计不是噱头。plan agent 默认拒绝文件编辑、执行 bash 前先问你——适合探索不熟悉的代码库或者规划改动方案。build agent 就是正常的全权限模式。@general 子 agent 做复杂搜索。桌面应用覆盖 macOS/Windows/Linux，17 种语言 README，brew/scoop/choco/pacman/nix 全平台安装。
为什么有人选 opencode 而不是 Claude Code？因为开源 + 可本地部署 + 不绑死 Anthropic。安装 npm i -g opencode-ai@latest 一行搞定。对 Claude Code 觉得贵或者想用自己的 API key 的独立开发者，opencode 是目前最完整的开源替代。
我的判断：opencode 的双 agent 模式会被其他框架抄走——“先想清楚再动手”比”直接改文件”更安全，这个道理在生产环境里特别重要。但它作为 coding agent 的核心能力（代码理解、编辑精度）还比不上 Claude Code，差距主要在模型层面，不是框架层面。短期内适合当”轻量探索工具”用，不适合当主力开发工具。
oraios/serena
serena 是个 MCP 工具，给 Agent 提供 IDE 级别的代码操作能力。不是按行号搜索替换，是按符号名——跨文件重命名、找引用、改函数体、安全删除，都是一步原子操作。
为什么这比 Agent 自带的文件操作强？因为 Agent 自带的是 Read + Edit + Grep——本质上是”读文件、正则替换、搜关键词”。碰到跨文件重命名，Agent 得自己 grep 所有引用、逐个替换、祈祷没有遗漏。serena 用 LSP language server 做语义分析，一个 rename_symbol 调用搞定。Opus 4.6 的原话：”8-12 error-prone steps collapse into one atomic call。”
40+ 编程语言支持（通过 LSP 后端），JetBrains 插件（付费，但功能更强——包括调试器）。Memory management 系统让长会话 Agent 不丢上下文。多层配置（global/project/execution context）让不同项目能用不同的工具集。
在大型代码库工作、经常需要跨文件重构的开发者——serena 是目前 Agent 辅助编码里”语义层”最强的工具。uv tool install -p 3.13 serena-agent，serena init，然后配进 Claude Code 或 Codex 的 MCP 配置就行。
我的判断：serena 解决的是 Agent 操作代码的”精度问题”——正则替换是钝刀，语义操作是手术刀。但 LSP 后端的启动开销是个问题，大项目首次索引可能要几十秒。JetBrains 插件路线更快但收费，LSP 路线免费但慢。如果你在 JetBrains IDE 里工作，两个后端都试试，选快的那个。
ultraworkers/claw-code
claw-code 是 Claude Code 的 Rust 公开实现，史上最快达到 100K stars 的仓库——虽然这个记录多少有点争议。
它干了什么？把 Claude Code 的 CLI harness 用 Rust 重写了一遍。cargo build --workspace 从源码构建，claw doctor 做健康检查，PowerShell-first 的 Windows 支持。生态有 oh-my-codex 插件体系，ACP/Zed 支持在开发中。
有个坑必须提：cargo install claw-code 会装错东西——crates.io 上那个包是废弃的 stub，会给你一个 claw-code-deprecated.exe。必须从 GitHub 源码构建。README 里用 Important 标注了，但还是会有人踩。
Rust 开发者、想贡献 Claude Code 替代实现的人、Windows 用户需要原生 PowerShell 支持——可以试试。但注意它不是 Anthropic 官方项目，不维护模型后端。
我的判断：100K stars 更多是情绪指标不是技术指标。claw-code 的价值在于给 Claude Code 用户提供了一个开源可审计的替代品，也给 Windows 用户提供了比 WSL 更原生的体验。但它的长期存续取决于能否跟上游保持 parity——如果 Claude Code 加了新功能而 claw-code 没跟上，stars 会贬值。目前看 ROADMAP.md 里欠的债还不少。
