复杂 Bug 更适合哪类 AI 编程智能体?

复杂 Bug 更适合具备“调查—验证—再调查”闭环的 Agent-First 智能体，而不是只擅长当前编辑上下文的代码补全工具。关键区别不在于谁能更快写出一段修复代码，而在于谁能在根因不明、影响范围不清的情况下，持续建立证据链。

复杂问题往往跨越调用链、状态转换、异步顺序和历史兼容逻辑。报错位置只是现象出口，直接在该函数补一个空值判断，可能让异常消失，却把错误数据继续传递下去。此时需要先定位入口、检索关联模块、提出多个假设，再通过已有测试、编译结果或运行反馈逐步排除。能够主动执行这套流程的智能体，更适合承担复杂排查。

适合委派的复杂 Bug

当开发者只能描述“什么现象不对”，却无法确定“哪里出了问题”时，Agent-First 更有价值。它应当先说明调查范围与判断依据，再以小范围改动验证假设；若首次修复无效，则根据新证据调整方向。Claude Code 这类任务导向工具，适合处理边界已被明确约束的跨代码库任务。

委派时，问题描述不能只有报错或一句“修一下”。至少应明确不可修改的模块、预期业务行为、可接受的改动边界，以及现有验证方式。否则，智能体容易为了让测试暂时通过而扩大改动，甚至改变原有业务语义。

人在环仍是必要条件

Cursor 一类编辑器内协作方式，更适合开发者已经进入问题现场、需要 AI 帮助检索、生成候选修改并快速迭代的场景。它保留了人的即时判断：开发者可以边阅读调用关系，边审查每处改动是否符合架构约束。

复杂 Bug 的选型标准应当很朴素：若已知改哪里、怎么改、如何验收，Code-First 通常更快；若只知道故障现象，且根因可能跨多个模块，应优先使用 Agent-First。无论采用哪种模式，跨文件修复都要审查改动范围、异常是否被粗暴吞掉，以及测试是否真正覆盖了原始故障场景。