Coding Agent

如果只把 Grok Build 看成“又一个终端 AI 编码工具”，我觉得有点可惜。 真正值得研究的不是它能不能替代 Claude Code，也不是 TUI 做得够不够酷，而是这次开源把一个大型商业 coding agent 的 harness 直接摊在了桌面上：它怎么读仓库、怎么跑命令、怎么接 MCP、怎么做 headless、怎么设权限、怎么用 sandbox 限制自己。 这些东西比模型名字更接近生产环境里的真实风险。 HN 上这条 Grok Build is open source 讨论很热，链接指向 xai-org/grok-build。我查了一下仓库：截至本次写作，它有约 12.5k stars，最近 push 在 2026-07-16，主语言是 Rust，根目录里能看到 crates/、bin/、prod/、third_party/，不是一个只放 README 的“开源姿态”。README 说得也很直白：Grok Build 是 SpaceXAI 的 terminal-based AI coding agent，支持全屏 TUI、理解代码库、编辑文件、执行 shell、搜索 Web、管理长任务，也能以 headless 方式用于脚本/CI，或通过 Agent Client Protocol 嵌入编辑器。 用人话说：这不是聊天壳子，它是一个能动你文件系统和终端的自动化运行时。 这也是我为什么会更关心安全边界。一个 coding agent 一旦进入真实仓库，它拿到的不是“代码补全上下文”，而是 .env、SSH 配置、私有依赖、内部接口、部署脚本、测试数据库连接串，以及开发者本机上各种历史包袱。模型回答错一句话只是质量问题；Agent 在错误权限下读错、传错、改错东西，就是安全事故。 开源价值：不是“免费”，而是可审计 Grok Build 的 README 提到，这个仓库包含 grok CLI/TUI 与 agent runtime 的 Rust 源码，并且是从 SpaceXAI monorepo 周期性同步出来的版本。仓库布局里，xai-grok-pager 负责 TUI，xai-grok-shell 负责 agent runtime 和 stdio/headless 入口，xai-grok-tools 放工具实现，xai-grok-workspace 处理文件系统、VCS、执行和 checkpoints。 ...

两天之内 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 不需要重新理解项目结构。 ...