目录为什么传统 Coding Agent 开始失效向量化代码理解的瓶颈在哪里Claude Code 为什么选择“终端调试范式”CodeGraph节省 Token但解决不了核心问题真正的转变从“看懂代码”到“跑通代码”这套范式对工程实践意味着什么一、为什么传统 Coding Agent 开始失效过去两年大多数 Coding Agent 的核心思路其实是一致的先理解代码再生成修改方案。典型做法是对本地代码库做向量化 embedding结合 IDE 上下文构建“高质量上下文”再交给大模型做推理与生成为了优化性能很多方案甚至在本地部署小模型专门用于补全、路径选择、上下文筛选这一整套体系本质上是在做一件事尽可能在“动手之前”把代码理解清楚。但问题也正出在这里。二、向量化代码理解的瓶颈在哪里这套范式在 Demo 场景下效果不错但一旦进入真实工程环境就开始暴露问题1、代码是“活”的向量是“死”的代码频繁变更embedding 很容易过期维护成本极高2、理解 ≠ 能修改很多时候问题并不是“找不到代码”而是“改了之后对不对”这个问题无法通过向量检索解决3、上下文越多风险越大大量图谱信息输入 LLM模型未必能正确消化幻觉概率反而上升一句话总结你以为是在增强理解实际上是在增加噪音。三、Claude Code 为什么选择“终端调试范式”Claude Code 出来之后整个思路开始发生明显变化。它不再强调“先理解全局”而是更接近真实工程师的行为看代码 → grep → 修改 → 执行 → 报错 → 修复 → 再执行这是一个典型的终端驱动调试流程Terminal-first loop。核心特点不依赖完整上下文不追求一次性正确强依赖执行反馈这种方式有一个关键优势可以在不理解全局的情况下逐步逼近正确答案。四、CodeGraph节省 Token但解决不了核心问题CodeGraph 是最近讨论比较多的一个方案。它的思路是将代码库构建成图结构提供 MCP 接口给 Agent 调用替代 grep 等搜索行为从数据上看它确实有价值可节省约 20% 的 token提升部分检索效率但它解决的本质上还是“更快找到代码”而不是“如何正确修改代码”在真实工程问题中真正难的往往是后者。五、真正的转变从“看懂代码”到“跑通代码”Claude Code 背后的核心理念其实可以总结为一句话不要过度依赖“看得很准”而是通过执行不断逼近正确。这带来了一个非常关键的范式变化旧范式新范式先理解再修改边修改边理解强依赖上下文强依赖执行反馈一次性推理多轮试错静态分析驱动动态调试驱动这和真实工程实践是高度一致的当一个复杂系统报错时工程师很少会先完整理解系统而是优先解决当前报错。六、这套范式对工程实践意味着什么这个变化不只是工具层面的升级更是工程思维的变化。1、Agent 从“助手”变成“执行者”不再只是给建议而是直接动手修改、运行、验证2、测试的重要性被进一步放大每一次修改都需要验证自动化测试成为闭环关键3、RAG / 向量检索不再是核心能力依然有用但不再是主角只是辅助信息获取4、终端能力成为 Agent 的核心接口未来的 Coding Agent核心能力不再是“我知道多少代码”而是“我能不能把代码跑通”结尾过去两年大家一直在优化如何让模型“更懂代码”但现在一个更现实的方向正在浮现代码不需要完全理解只需要能被正确修改并跑通。从“理解驱动”走向“执行驱动” 这可能才是 Coding Agent 真正的分水岭。如果你正在做AI 编程助手自动化测试Agent 工作流这套范式的变化基本绕不开。