MCP

我对“给 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 分钟调试由此产生的问题。 ...