小米 AI Agent 一面(暑期)

1. 自我介绍

2. 为什么要通过微调模型来做代码生成？为什么不用纯 prompt 或 spec coding？

答案：纯 prompt 和 spec coding 确实可以提升模型在单次任务上的表现，但它们更多是推理时约束，解决的是“让模型按要求做事”的问题。微调解决的是模型行为分布的问题，比如固定代码风格、内部框架 API 使用习惯、异常处理模式、日志规范、单测模板、目录结构约定，这些如果全部靠 prompt 塞进去，成本很高，也容易在长任务里被稀释。

在缺陷修复 Agent 里，我选择微调不是为了让模型记住业务代码，而是让它学习稳定的工程动作：先读测试，再定位调用链，再改最小范围，再补回归测试。prompt 可以告诉模型这套流程，但微调能让模型更自然地遵循这种模式，减少乱改文件、漏写测试和使用不存在 API 的概率。

train_sample = {
    "instruction": "根据缺陷描述修复代码，并补充回归测试",
    "input": {
        "bug": "当用户未配置 timeout 时接口抛出 NoneType 异常",
        "files": ["client.py", "test_client.py"],
        "style": "保持最小修改，不改变公开接口"
    },
    "output": {
        "plan": ["定位 timeout 默认值", "补充空值分支", "新增单测"],
        "patch": "diff --git ...",
        "tests": ["test_default_timeout"]
    }
}

3. 这个项目是什么时候开始、什么时候完成的？怎么证明不是临时包装的？

答案：这个项目可以按阶段讲。前期大概两周做原型，目标是验证模型能否基于 Issue 自动定位相关代码；中间一个月做工具链，包括仓库检索、AST 分析、测试执行、patch 生成和 CI 接入；后面两到三周做评测集、失败 case 复盘和链路优化。

证明项目真实性不能只说时间线，要能说清楚每个阶段遇到的问题和指标变化。比如一开始模型经常只改业务代码不补测试，后来把任务拆成“定位-计划-修改-测试-总结”，并把测试失败日志作为 observation 回灌给 Agent，修复成功率才明显提升。

阶段一：代码检索原型，验证 Issue -> 文件定位
阶段二：接入 AST、git diff、pytest、CI 日志
阶段三：构建缺陷样本集，评估修复成功率和测试通过率
阶段四：优化上下文压缩、失败重试、工具调用参数校验

4. spec coding / SDD 也能拆 task，为什么达不到你项目里的效果？

答案：spec coding 或 SDD 更像是把需求写清楚，让模型按规格逐步实现。它适合需求边界明确、上下文稳定、任务可以人工拆解的场景。但真实缺陷修复里，需求往往不完整，错误日志和代码实现之间存在间接关系，模型需要自己定位上下文、发现隐藏依赖、执行测试并根据失败结果继续修正。

我的项目里不是简单“把任务拆小”，而是让 Agent 在每一步都能读环境反馈。比如第一次 patch 后测试失败，Agent 需要理解失败栈、回到相关代码继续修改。SDD 的静态任务列表很难覆盖这种动态反馈，而 Agent 的重点是“状态驱动的下一步决策”。

state = {
    "issue": "接口偶发返回 500",
    "current_step": "run_tests",
    "last_observation": "test_user_api failed: KeyError('profile')",
    "changed_files": ["user_service.py"],
    "next_action": "inspect_profile_default_branch"
}

5. 你当时用 Qwen2.5，为什么没有用更新的模型？

答案：模型选型不是只看发布时间和榜单分数，还要看部署成本、推理延迟、私有化要求、工具调用稳定性和代码任务上的性价比。当时选择 Qwen2.5，主要是因为它在中文、代码理解、指令跟随和本地部署生态上比较均衡，vLLM、量化、LoRA 微调都比较成熟，方便做闭环实验。

更新模型可能参数更大、能力更强，但如果部署成本翻倍、响应延迟明显变高，Agent 多轮调用时整体成本会被放大。代码修复 Agent 不是只调用一次模型，一次任务可能涉及规划、检索、生成 patch、解释测试失败、再次修复等多次推理，所以稳定性和成本很关键。

model_choice = {
    "base_model": "Qwen2.5-Coder-14B",
    "reason": [
        "代码能力稳定",
        "支持本地部署",
        "LoRA 微调链路成熟",
        "vLLM 推理吞吐可接受",
        "多轮 Agent 成本可控"
    ]
}

6. 你用的是自己部署的模型吗？为什么不用外部大模型 API？

答案：是自己部署为主，外部 API 可以作为对照评测或兜底，但不能作为核心链路。原因有几个：第一，代码仓库、Issue、CI 日志都可能包含内部业务逻辑和敏感信息，直接传给外部 API 有合规风险；第二，Agent 任务调用频率高，用外部 API 成本不稳定；第三，内部模型可以做 LoRA 微调和推理优化，外部 API 很难控制模型版本和行为漂移。

另外，代码生成场景需要稳定复现。今天同一个 prompt 输出一种 patch，明天模型版本变了输出另一种 patch，会影响评测和上线。自己部署虽然运维成本更高，但能控制模型版本、采样参数、日志、审计和灰度策略。

inference_config = {
    "deployment": "self_hosted",
    "engine": "vllm",
    "max_model_len": 32768,
    "temperature": 0.2,
    "top_p": 0.9,
    "version": "coder-agent-lora-v3"
}

7. 外部模型参数更大，14B 在 Agent 层面会不会不够？

答案：14B 的确不如更大模型在复杂推理上稳，但 Agent 系统不能只依赖模型裸能力。工程上可以通过工具、检索、结构化状态、约束解码、测试反馈和评审器补足模型能力。很多代码修复任务失败不是因为模型不知道语法，而是因为上下文没给对、任务边界不清、测试反馈没利用好。

如果出现指令遵循问题，我会先区分原因。如果是模型理解能力不足，可以换更大模型或蒸馏更强模型的数据；如果是上下文污染，就要做上下文裁剪；如果是任务太长，就拆成状态机；如果是工具结果不可靠，就先修工具链。模型参数大小只是一个因素，不是唯一瓶颈。

def route_model(task):
    if task["risk"] == "high" or task["files_changed"] > 5:
        return "larger_model_review"
    if task["type"] in ["simple_bugfix", "unit_test"]:
        return "local_14b_agent"
    return "local_14b_with_rerank"