AI编程助手能自动找Bug、修代码，这件事听起来很美好。但一位工程师把Claude塞进Kubernetes代码库实测后发现：它们确实能定位孤立问题，却经常搞不清改动会在系统哪里引发连锁反应。这项发表在CNCF博客的研究，直接挑战了"提升代码检索能力就能让自动修Bug变强"的流行假设。
作者Brandon Foley把AI Agent接入了日常工作流，用Kubernetes仓库的真实PR当基准测试。这些不是人造的玩具问题，而是活跃贡献者正在修复的真实Bug。测试规则很苛刻：Agent只能看到Issue描述，看不到PR说明，更看不到最终补丁。相当于闭卷考试，而且考的是生产环境里的难题。
九份Bug报告覆盖了kubelet、调度器、网络、存储和应用子系统。三种配置同台竞技：纯RAG检索（用KAITO RAG引擎+Qdrant，BM25关键词匹配混嵌入语义搜索）、混合模式（必须先RAG发现再访问本地文件）、纯本地（完整代码库克隆，无检索索引）。所有变量锁死：同一模型Claude Opus 4.6、同一5分钟超时、同一输出格式，唯一区别是Agent怎么看代码。
速度和成本的数据很干净。纯RAG平均76秒，最快——它跳过文件系统导航，直接基于检索片段生成代码。混合模式最慢，平均约两分半，强制的RAG前置阶段增加了开销。token经济层面，混合模式也最贵，不是因为它读更多代码，而是模型调用次数最多；由于API无状态，每次调用都要重放完整对话历史。调用次数成了成本和延迟的最大推手。
但正确性的图景就复杂多了。主导失败模式不是修错，而是修不全。Agent处理了"主Bug"，却漏掉相邻改动；修好了一种实现，忽略了第二种；补丁打在了核心问题，却忘了依赖集成逻辑的必要调整。或者在遇到代码库里已有的部分修复时就停手了。共同模式是：Agent不会问"还有什么需要改？"一旦眼前问题看似解决，就停止了。
另一个模式关于架构选择。当有选择时，Agent倾向于引入新抽象而非复用现有方案。一个测试用例中，正确修复使用了已有的RestartCount字段；所有Agent却都引入了新的Attempt字段——功能正确，但架构负担更重。
研究表明，检索策略影响发现能力，但不影响推理质量。强制使用RAG在某些情况下改善了结果，因为