Coding Agent 表现差怎么排查?

30 秒回答

1. 模型能力局限（代码理解、长程依赖、特定语言/框架掌握不足）
2. 工具调用失效（参数格式错误、工具选择不当、执行环境隔离）
3. 错误反馈循环断裂（无法正确解析执行错误、缺乏自我修正迭代）
4. 上下文窗口瓶颈（代码库规模超限、历史对话淹没关键信息）

回答与解析

答案要点

• 模型能力局限（代码理解、长程依赖、特定语言/框架掌握不足）
• 工具调用失效（参数格式错误、工具选择不当、执行环境隔离）
• 错误反馈循环断裂（无法正确解析执行错误、缺乏自我修正迭代）
• 上下文窗口瓶颈（代码库规模超限、历史对话淹没关键信息）
• 改进策略需针对具体根因设计，而非简单堆叠prompt

一、模型能力层面

核心问题

• 代码理解深度不足：对复杂业务逻辑、跨文件依赖、设计模式识别能力弱
• 长程依赖建模差：修改A文件时忽略B文件的调用关系，导致回归错误
• 语言/框架知识陈旧：训练数据截止导致的API变更、新特性不了解

改进策略

• 引入RAG检索相关代码片段和官方文档作为上下文增强
• 针对特定技术栈做SFT或LoRA微调
• 采用"plan-then-code"模式：先输出设计文档/修改方案，再生成代码

二、工具调用层面

核心问题

• 参数格式错误：JSON schema理解偏差，特别是嵌套结构、可选字段
• 工具选择失误：面对模糊需求时选错工具（如用文件读取替代代码搜索）
• 执行环境隔离：Agent无法感知实际运行环境状态（依赖缺失、权限问题）

改进策略

• 强化Function Calling的few-shot示例，明确边界情况
• 增加工具描述的自我验证步骤："我将使用X工具，因为..."
• 构建沙箱环境的状态探针，执行前做前置检查

三、错误反馈机制

核心问题

• 错误解析失效：面对堆栈跟踪时定位根因困难，陷入表面修复
• 自我修正循环断裂：多次尝试后偏离原始需求，或产生过度修改
• 无反馈沉默失败：工具返回空结果或状态码时无法判断成功/失败

改进策略

• 设计结构化错误解析prompt：要求提取错误类型→定位文件→分析原因→制定方案
• 设置修正次数上限（如3次），超限触发降级策略（人工介入或简化需求）
• 强制工具返回标准化状态，Agent必须显式确认执行结果

四、上下文管理

核心问题

• 代码库规模超限：大型项目远超上下文窗口，关键信息被截断
• 历史对话淹没：多轮迭代后原始需求被稀释，出现需求漂移
• 无关信息干扰：检索返回的噪声代码片段误导生成

改进策略

• 分层上下文：需求描述 + 相关文件摘要（由代码图谱生成）+ 具体修改点代码
• 关键信息锚定：将原始需求、约束条件固定在prompt首尾，每轮重申
• 动态检索：根据当前修改目标实时检索相关代码，而非一次性加载

系统性改进思路

建议构建诊断-归因-干预的闭环：先通过日志分析bad case分布，识别主导因素，再针对性优化。避免同时改动多个变量导致效果不可归因。

口语版讲法(约4分钟)

• 一句话定位：代码生成Agent表现不好，本质是模型、工具、反馈、上下文四块短板，得先诊断再下药
• 模型能力上，复杂逻辑和长程依赖是软肋，RAG加plan-then-code比堆prompt管用
• 工具调用和错误反馈是执行层的老大难，得靠few-shot加结构化解析来堵漏
• 上下文管理最坑，分层加动态检索才能让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和自校验，反馈不行就结构化解析加次数限制，上下文不行就分层加动态检索。千万别同时改多个变量，不然效果烂了都不知道是谁的锅。

关键一句:错误修正次数上限的动态调整策略，结合任务复杂度和变更量监控

面试官还可能这样问

1. 问法 1 · 场景切入

   假设我们有个内部的代码生成Agent，用来给客服系统写SQL查询。有时候它生成的SQL语法完全正确，但查出来的数据不对，或者干脆跑不出来。你遇到这种情况，一般会从哪些地方开始排查原因？

2. 问法 2 · 层层追问

   你觉得代码生成Agent表现不好，通常会是模型本身能力不够吗？……那如果模型能力还可以，还会有什么其他因素？……比如它调用工具去查文档或者跑测试的时候，会不会出问题？

3. 问法 3 · 直球架构

   从模型能力、工具调用、错误反馈、上下文管理这几个维度，分析一下代码生成Agent为什么有时效果差，并给出对应的改进策略。先说你认为最关键的瓶颈在哪里。