大多数编码代理的失败并非因为不会写代码，而是因为一开始就用了错误的地图。

我一直在构建 SigMap，一个专为 AI 编码代理设计的开源基础层，但有一个假设我搞错了。我曾以为更大的上下文窗口能解决大部分 AI 编码问题。然而，在测试了 Claude Code、Cursor、Codex 风格的工作流以及本地代理后，我不断看到同一个瓶颈：代理在真正开始做有用工作之前，花了太多时间试图理解代码仓库。它会： - 搜索代码库 - 打开随机文件 - 追踪导入关系 - 猜测逻辑所在 - 有时甚至会从错误文件里给出答案 因此，我开始换个角度思考问题。与其给代理更多上下文，SigMap 提供的是一个确定性地图： - 真实文件 - 真实的函数/类 - 真实的行锚点 - 针对任务的排名文件 - 覆盖验证 - 回答后的 groundedness 检查 - 用于按需查找的 MCP 工具 当前 v8.9 基准测试快照： - 21 个仓库平均 token 减少 97.0% - hit@5 检索率 88%，而随机基线仅为 13.6% - 每个任务提示从 2.84 降至 1.44 - 90 个任务的任务成功代理约 67.8% - 使用 SigMap 后，0/21 个 GPT-4o 溢出仓库，而未使用时为 16/21 我现在最感兴趣的不是“更多自主性”，而是“更少的上下文浪费”。当前 SigMap 还可以通过 MCP 暴露这一点，这样代理就可以按需拉取所需内容，而无需预先加载整个仓库。还有一个 squeeze_output 工具，用于在上下文进入前压缩杂乱的堆栈跟踪、CI 日志和 JSON 载荷。核心思想：仓库 → 确定性签名映射 → 排序上下文 → 验证 → 基于实际结果的答案。