MCP

如果只把 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。 ...

如果你最近觉得 Claude Code 的用量表涨得比预期快，先别急着怀疑模型涨价。 更可能的原因是：你付费的不只是“那一句 prompt”，而是一整套 Agent harness 的启动成本。 这两天 HN 上有一篇很值得看但也很容易被误读的文章。Systima 把 Claude Code 和 OpenCode 放在同一台机器、同一个模型、同类任务下，在 API 边界抓取请求与返回的 usage block，结论很刺眼：在一个只要求回答 OK 的最小任务里，Claude Code 在真正读取用户提示词之前，已经带上大约 33,000 tokens 的系统提示、工具 schema 和注入脚手架；OpenCode 大约是 7,000 tokens。换成 Claude Fable 5 后差距会收窄到约 3.3 倍，但方向没变。 我不想把这篇写成“Claude Code 不行、OpenCode 真香”的二元对立。坦白说，这样读反而会错过真正有工程价值的部分。 真正的问题是：编码 Agent 的成本，正在从模型单价问题，变成上下文装配问题。 Systima 的原文把 Claude Code 和 OpenCode 称为两个 harness。这个词很关键。模型只是发动机，harness 才是把仓库、终端、文件系统、MCP、权限、子 Agent、记忆、hooks、通知、后台任务塞进一次请求里的“车架”。你看到的聊天框是一句话，模型看到的可能是一辆满载卡车。 用人话说就是：你以为自己在问“帮我改个 bug”，但系统实际先递给模型一份厚厚的公司制度、工具手册、权限说明、项目记忆、外部系统目录，然后才轮到你的 bug 描述。 33k tokens 从哪里来？ Systima 的测法并不复杂：清空配置目录，不开 MCP，不加载用户设置和 memory，用空 workspace 跑三类任务。第一类任务最极端，只要求返回固定字符串。这样做的好处是把“任务本身的复杂度”剥掉，专门看工具启动时的固定负担。 ...

如果你让一个 Agent 帮你分析 CSV，最容易翻车的地方往往不是 SQL，也不是统计口径，而是最后那张图。 模型可以很自信地吐出一大段 Vega-Lite、ECharts 或 Chart.js 配置；第一次看像那么回事，真正渲染出来却经常出现标签重叠、坐标轴选择离谱、颜色语义混乱，或者更糟：配置本身就不合法。坦白说，我以前一直把这类问题归因于“模型还不够聪明”。但 Microsoft Flint Chart 给出的判断更有意思：问题可能不只在模型，而在我们让模型直接操纵的可视化语言太底层了。 Flint 的做法是把图表生成拆成两层。Agent 不再直接写几百行低层配置，而是写一个更紧凑的语义化规格：数据是什么、字段是什么语义类型、想要哪类图、哪些字段放到 x/y/color。然后 Flint 编译器再把这些高层意图转成 Vega-Lite、ECharts 或 Chart.js 的原生配置。HN 上这个项目的作者也把问题说得很直白：简单规格可靠但图不好看，复杂规格好看但 Agent 难以稳定生成，所以需要一个更适合 Agent 的中间语言。对应的 Show HN 讨论 在两天内拿到 300 多分，说明这不是一个小众痛点。 人话翻译一下：Flint 想把“画图审美和布局细节”从 LLM 的自由发挥里拿出来，交给一个可测试、可维护的编译器。 这件事为什么重要？因为数据可视化是 Agent 产品里非常典型的“最后一公里”。前面检索、清洗、聚合都做对了，最后输出一张难看的图，用户仍然会觉得系统不专业。更麻烦的是，图表错误不像代码报错那么直接。一个错位的柱状图、错误的时间轴、被截断的图例，可能不会触发任何异常，却会默默误导用户。 低层图表配置，本来就不适合让模型裸写 以 ECharts 或 Vega-Lite 为例，成熟库的能力很强，但配置面也很大。你要处理 mark 类型、scale、axis、legend、tooltip、label、layout、颜色、响应式尺寸、空值、字段类型、数据基数……这些东西对人类前端工程师都不轻松，更别说让一个通用 LLM 每次都稳定地一次写对。 Flint README 里的核心设计是“semantic chart specs”：它支持 70 多种语义类型，例如 Rank、Temperature、Price、Country，并根据数据基数、语义类型、图表类型和画布约束自动推导尺寸、间距、标签、图例等细节。这个方向我比较认可，因为它把 Agent 的任务缩小了：模型负责表达意图，系统负责补完形式。 这和编程语言里的编译器很像。你不会要求业务开发者每次手写汇编，也不希望 Agent 每次都从零手搓图表布局。一个好的中间层，价值不在“更酷”，而在减少自由度。 自由度少，系统才容易稳定。 Flint 当前仓库也不是只有一份概念文档。它包含 flint-chart TypeScript 库和 flint-chart-mcp MCP Server，可以把同一份输入编译到多个后端；仓库在 GitHub 上有接近千星、MIT License，最近提交就在 2026 年 7 月。按我的判断，这已经超过“白皮书项目”的阶段，属于可以实验接入的真实工程工具。不过它仍然很新，生产环境大规模使用前还需要自己压测和做视觉回归。 ...

我对“给 Agent 做代码搜索”这类工具一直有点警惕。 原因很简单：很多产品把问题讲成“grep 太笨，向量检索更聪明”，最后落地却变成另一个黑盒。Agent 找不到符号定义时，开发者至少还能看见它 grep 了什么；如果换成一个语义搜索服务，结果看起来更像魔法，但错的时候也更难排查。 所以看到 HN 上的 Semble 时，我第一反应不是“又一个代码 RAG”，而是问一个更工程化的问题：编程 Agent 到底需要什么样的代码搜索？ Semble 的答案挺明确：它不是给人做 IDE 搜索，也不是给企业做大规模代码知识库，而是给 Claude Code、Codex、Cursor、OpenCode 这类编程 Agent 提供一个本地、低延迟、少 token 的代码检索层。HN 原帖标题也很直接：Show HN: Semble – Code search for agents that uses 98% fewer tokens than grep。截至我写这篇时，项目在 GitHub 上已经超过 1000 stars，最近提交也在 2026 年 5 月，至少不是一个空 README 项目。 为什么 grep 对 Agent 不够友好 人用 grep，其实会做很多隐性判断。 你搜 auth，看到 30 个文件，会快速扫目录名、测试文件、legacy 文件，再决定先打开哪个。你会知道 auth_test.py 不是主实现，compat/ 里可能只是兼容层，AuthProvider 的定义比调用点更重要。 Agent 就没这么省。 它通常会先 grep，一个关键词命中几十个文件，然后 read 一堆文件。每多读一个文件，就多消耗上下文窗口、多花钱、多增加模型注意力噪声。更麻烦的是，Agent 经常会被“看起来相关”的调用代码带偏，最后改了外围逻辑，真正的核心函数反而没碰。 ...

如果你用过 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 也把这些字段明确写成结构化配置，而不是自然语言建议。 ...

你有没有这种感觉：每天早上醒来，前一天学的东西大部分都忘了？ 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 并行成为默认 2023 到 2025 年间，AI 编程工具完成了从自动补全引擎到自主 Agent 的进化。Claude Code 能阅读整个代码库、推理架构约束并实现多文件功能。Codex CLI 可以执行 Shell 命令、运行测试并根据失败信息迭代。Gemini CLI 能分析大型代码库并生成全面的重构计划。 每个工具单独使用都足够强大。但当两个或更多工具并发运行时——这在工程团队尝试跨特性分支并行化 AI 辅助开发时越来越常见——问题出现了：瓶颈从「AI 能否写代码」转移到了「多个 AI 能否在同一代码库上协同工作而不互相摧毁」。 答案在大多数团队中是「不能」。 本文以 NXTG.AI 开源的 Forge 项目1为锚点，用熵增理论框架分析多 AI 协作的系统性困境：为什么三个 Agent 并发编辑同一个仓库会产生 merge 冲突、知识蒸发和架构漂移这三种必然的熵增现象，以及 Forge 的文件锁、知识飞轮和漂移检测三个核心机制如何构成一个逆向熵增的工程系统。 1. 多 AI 协作的三种熵增现象 热力学第二定律告诉我们：孤立系统的熵永不自发减少。多 AI 协作系统在并发运行时就是一个典型的孤立系统——多个自主 Agent 在没有协调层的情况下操作同一个共享资源（代码库），信息熵自发增大，表现为三种具体的系统故障。 1.1 Merge 冲突：信息位叠加的不可逆损耗 两个 Agent 同时编辑同一个文件，各自产出了一系列修改。当这些修改最终汇聚到 Git 时，产生了不可调和的冲突节点。这不是 Git 的缺陷，而是两个独立信息流在同一个时空中叠加后产生的熵——两个 Agent 在各自的上下文中做出了局部最优决策，这些决策在更高层次上却是互斥的。 从信息论角度，每个 Agent 的编辑可以看作一次信息压缩操作。在单 Agent 场景下，上下文窗口提供了足够的历史信息来保证压缩的一致性。在并发场景下，上下文窗口相互独立，信息压缩失去了共享参考系，熵增体现在合并时的信息损耗——必须丢弃一个 Agent 的部分或全部工作。 1.2 知识蒸发：跨会话信息的热力学逃逸 Agent A 在一次会话中发现了数据库迁移必须在 API 服务器启动前运行的约束条件。Agent B 运行在完全独立的上下文窗口中，对 Agent A 的发现毫无感知，按错误顺序部署了 API 服务器并花费 20 分钟调试由此产生的问题。 ...