Coding Agent 表现差怎么排查?

这道题问的是代码生成[[Agent]]表现不好的原因，其实本质就一句话：Agent的能力天花板是由模型、工具、反馈、上下文四块板拼起来的，哪块短了都拉胯，而且不能头痛医头，得先诊断出主要矛盾再下手。

先说模型能力。很多Agent写简单脚本挺溜，一碰到复杂业务逻辑、跨文件依赖就懵了。比如改一个订单状态机的代码，它可能只改了当前文件，完全没意识到另一个文件里有个回调函数依赖这个状态，一跑就崩。这个问题的根因是模型对长程依赖建模差，训练数据里也没覆盖你用的那个冷门框架的新API。改进的话，我倾向两条路：一是用[[RAG]]把相关代码片段和官方文档塞进上下文，相当于给它开卷考试；二是走plan-then-code模式，先让它输出修改方案和影响分析，确认逻辑再写代码。这比单纯堆prompt靠谱多了。

再一个就是工具调用和错误反馈，这两个其实是执行层的一体两面。工具调用最常见的问题，像参数格式搞错、工具选偏了。比如用户说'查一下这个bug'，Agent可能调了文件读取而不是代码搜索，结果返回一堆无关日志。我一般会给[[Function Calling]]加几个边界情况的few-shot示例，并且让Agent在调用前显式说一句'我为什么选这个工具'，相当于自我校验。错误反馈更坑，Agent经常拿着堆栈跟踪瞎修，修到第三轮可能连原始需求都忘了。这里有个关键点：必须给错误修正设上限，比如最多三次，超了就降级成人工介入或者简化需求。同时我会让Agent做结构化解析，先定位错误类型，再找文件，再分析根因，最后出方案，每一步都拆开，而不是让它自由发挥。

上下文管理这个坑，做大了项目的人都懂。大型代码库动不动几十万行，Agent的上下文窗口根本塞不下。更麻烦的是多轮对话后，原始需求被稀释，Agent可能自己加需求、改需求。比如你让它'修复订单金额计算错误'，它修着修着开始重构整个支付模块，需求漂移了。我的做法是分层管理上下文：最顶层放原始需求和约束条件，中间层放相关文件摘要（用代码图谱自动生成），最底层才放具体要改的那几行代码。而且关键信息要锚定在prompt首尾，每轮都重申一遍原始目标，避免遗忘。动态检索也很重要，别一次性把所有代码喂进去，而是根据当前修改目标实时拉取相关片段。

这里有个细节值得聊一下：错误修正次数上限设多少合适？设少了容易误杀，设多了Agent可能在一个死循环里浪费token。我一般会根据任务复杂度动态调整，简单任务两次，复杂任务三次，同时监控每次修正的代码变更量，如果越改越大就提前终止。这块其实可以跟强化学习里的early stopping结合起来做。

所以整体上，我会把Agent调优看成诊断加归因加干预的闭环，先跑一批bad case看主要短板在哪，再针对性地补。模型不行就上RAG或微调，工具调用不行就加few-shot和自校验，反馈不行就结构化解析加次数限制，上下文不行就分层加动态检索。，不然效果烂了都不知道是谁的锅。