冷门观点：Cursor 和 Claude Code 并没有变笨，而是它们的代理循环在结构上存在盲点，正在窒息你的上下文窗口

我真的受够了那些“兄弟你只需要提示得更好”的说法——当人们谈论编码代理在 20 轮对话后产出垃圾代码时。这周我终于坐下来审计了我的 API 日志和提示负载，因为我的 token 使用量高得离谱，然后我发现了一件让我真正抓狂的事。模型（即使是那些大模型）并没有退化或被「脑叶切除」。它们只是在自己膨胀的上下文窗口中窒息而死，甚至还没开始进行任何实际的推理。如果你看看 Cursor 或 Claude 在中等规模仓库（比如 1 万行以上代码）下实际做了什么，那简直是一场噩梦： * **盲目探索**……它们只是递归地执行 grep 并将大约 40 个不同的文件塞入上下文，只是为了找到一个愚蠢的实用函数。多半时候它甚至找不到我现有的组件，所以就凭空幻觉出一个重复的组件，哈哈。 * **原始摄入**：将一个 2000 行的大文件直接灌入提示中，只是为了更新一个 5 行的接口。到底是为什么？ * **工具泛滥**：冗长的测试日志和巨大的 MCP 工具定义消耗了大约 3 万 token，而模型连一个代码 token 都还没生成。 * **金鱼记忆**：每一次会话都是「重复昨天的事」。完全没有实际的项目意识，所以一旦上下文达到约 80% 的容量，全是这种纯粹的噪音，模型的注意力机制就彻底崩溃了。智商明显降到室温，然后就开始破坏你的架构。 标准的块状 RAG 也根本不能解决这个问题，因为标准 RAG 对于逻辑推理来说很垃圾。代理从根本上对代码库的实际结构是盲目的，直到它耗尽你所有的 token 来读取原始文本。有没有其他人在本地解决这个问题？我们真的在接受这种奇怪的效率悖论吗——省下 1 小时打字，却要花 5 小时修复它制造的架构乱麻？感觉我们迫切需要一种开源的代理，它实际上能将代码解析成 AST 或图数据库，以便在浪费上下文窗口处理原始文本之前理解结构。还是只有我一个人对此发疯？