面试题 · Prompt
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
当一个代码生成Agent（Coding Agent）在实际任务中表现不佳时，可能的原因有哪些？请从模型能力、工具调用、错误反馈机制、上下文管理等方面分析，并提出相应的改进策略。
核心问题
改进策略
按学习路线查看教程、项目和面试题。
核心问题
改进策略
核心问题
改进策略
核心问题
改进策略
建议构建诊断-归因-干预的闭环：先通过日志分析bad case分布，识别主导因素，再针对性优化。避免同时改动多个变量导致效果不可归因。
场景切入
假设我们有个内部的代码生成Agent，用来给客服系统写SQL查询。有时候它生成的SQL语法完全正确，但查出来的数据不对，或者干脆跑不出来。你遇到这种情况，一般会从哪些地方开始排查原因？
层层追问
你觉得代码生成Agent表现不好，通常会是模型本身能力不够吗？……那如果模型能力还可以，还会有什么其他因素？……比如它调用工具去查文档或者跑测试的时候，会不会出问题？
直球架构
从模型能力、工具调用、错误反馈、上下文管理这几个维度，分析一下代码生成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和自校验，反馈不行就结构化解析加次数限制，上下文不行就分层加动态检索。千万别同时改多个变量，不然效果烂了都不知道是谁的锅。