一个 Coding Agent 如何完成任务？读代码、改文件、跑测试、修 Bug 的流程是什么？
Coding Agent 完成任务的核心逻辑是：先理解需求，再读懂代码库，最后才允许动手改文件。这个顺序不能乱。下面我会拆解它的完整工作流程，以及每个环节的关键设计。
1. 先理解再动手 — Coding Agent 的 6 步工作流
Coding Agent 不是上来就写代码，它有一套标准流程：
Step 1：接收 Issue — 把用户的需求转成可执行的任务描述。
Step 2：读取代码库 — 理解现有代码结构和依赖关系。
Step 3：审查方案 — 生成代码修改计划，用户确认后再执行。
Step 4：限制范围 — 只改和任务相关的文件，防止范围蔓延。
Step 5：运行测试 — 通过测试验证修改的正确性。
Step 6：diff 审查 — 输出代码差异，必须经过人工 review 才能 merge。
类比一下，就像新手工程师接任务：不能还没理解需求就开始写代码。Coding Agent 也是一样，只不过这个"新手"可以并行处理大量任务，但每一步都得按规矩来。
2. 读代码 — Agentic Coding 与传统代码补全的本质区别
传统 IDE 的代码补全，只看光标位置附近的内容。Copilot 这类工具能生成一段代码，但它不知道你项目中其他文件是怎么写的。
Coding Agent 不一样，它的上下文是整个代码库，要理解的是跨文件的依赖关系。
代码索引策略
Agent 读代码库分两步：
语义搜索（向量索引） — 找到和任务相关的概念。比如你要修一个"登录超时"的 bug，向量索引能找出所有和"session"、"timeout"、"auth"相关的代码。
关键词搜索（grep） — 找到具体的内容位置。比如你知道错误在
auth.py的第 120 行，直接定位。依赖图构建 — 建立文件之间的调用关系图。你改了
A.py的接口，要能自动知道B.py和C.py可能受影响。
简单说，传统补全是"查手边的字典"，Agentic 是"查整个图书馆的索引系统"。
3. 改文件 — 两种编辑模式的取舍
Coding Agent 编辑代码有两种模式，各有优劣：
全文重写模式
把整个文件内容重新生成一遍，然后替换。
优点：生成连贯，不容易出现上下文错位。
缺点：可能丢失非相关的改动（比如你手动改了一个注释，Agent 不知道，一起覆盖掉了）。
适用场景：新文件、小文件、或者需要重构的场景。
精确编辑模式
只改文件中的特定部分，比如在某个函数里插入几行代码。
优点：范围小，对其他部分无影响。
缺点：容易出现行号偏移问题。假设你在第 50 行插入代码，原来第 60 行的代码就变成第 61 行了，Agent 可能会"对不齐"。
适用场景：大文件、只改局部的 bug 修复。
类比一下：全文重写像"撕掉整页重写"，精确编辑像"局部修改但要小心对不齐"。实际工具通常会混合使用，小文件全文重写，大文件精确编辑。
4. 跑测试 — 测试驱动的迭代循环
Coding Agent 改完代码，必须跑测试验证。流程是这样的：
运行测试 → 分析错误 → 生成修复建议 → 修改代码 → 重复测试失败 → 看错误信息 → 理解哪里出了问题 → 生成修复方案 → 改代码 → 再跑测试
这个循环会持续，直到所有测试通过。
但有个陷阱：死循环
Agent 可能陷入反复修改、反复失败的循环。比如：
- 每次修复都引入新的 bug
- 测试本身写得有问题，怎么改都不通过
- Agent 在两个错误之间来回跳
好的设计会设置最大重试次数，超过就停止，提示人工介入。
另一个关键点：测试通过 ≠ 能 merge
面试时经常被问到这个问题。测试通过只代表改后的代码在现有测试用例下没有报错，但：
- 测试覆盖率够不够？
- 测试本身能不能抓到真正的错误？
- 新增的边界 case 有没有测试？
所以 diff 必须经过人工 review，确认测试质量。
5. 安全与审查 — 不能让 Agent 裸奔
Coding Agent 能读代码、改文件、跑命令，如果不做限制，风险很大。
沙箱执行环境
Agent 的操作必须在隔离环境中执行，常见方案：
- Docker 容器 — 轻量级隔离
- WASM (WASI) — 浏览器级别的沙箱
- gVisor — Google 出的容器安全运行时
- Firecracker — AWS 用的 microVM
沙箱的目的是：即使 Agent 执行了危险命令（比如删库），也不会影响真实系统。
diff 必须过 6 维度审查
代码差异（diff）输出后，人工 review 要检查：
- 任务对齐 — 改的是不是用户要的那个功能？
- 行为正确 — 逻辑对不对，有没有引入新 bug？
- 测试品质 — 测试能不能抓到问题？
- 安全风险 — 有没有注入、越权等安全问题？
- 维护性 — 代码可读吗，以后好维护吗？
- 范围控制 — 改动是否限定在必要范围内？
简单说，这是工厂品控流水线，不合格产品不能出厂。
面试怎么答
基础版（能过的回答）
Coding Agent 完成任务分 6 步：接收 Issue、读取代码库、审查方案、限制范围、运行测试、diff 审查。核心原则是先理解再动手。
读代码和传统补全的区别是上下文范围：传统补全只看光标附近，Agentic 要理解整个代码库的跨文件依赖关系。代码索引用向量搜索找概念、grep 找具体位置，再通过依赖图建立文件间的调用关系。
编辑文件有两种模式：全文重写适合小文件新文件，精确编辑适合大文件局部修改，但要注意行号偏移问题。
测试驱动迭代循环会持续到测试通过，但要防止死循环。另外测试通过不代表能 merge，必须审查测试质量。
安全方面，Agent 操作必须跑在沙箱里（Docker/WASI/gVisor），diff 必须经过人工 6 维度审查。
加分版（让面试官眼前一亮）
结合实际经验说：我用 Coding Agent 补过单元测试、修过小型 bug，效果不错。但也踩过坑——有一次 Agent 把整个文件重写，把我手动加的日志注释覆盖了，后来我改成精确编辑模式就解决了。
高风险操作（删文件、改配置）必须 human-in-the-loop，不能让 Agent 自由发挥。
知道哪些任务适合 Agent：补单元测试、修小型 bug、小型重构。哪些不适合：大型架构改版、生产事故处理。
还有几个常见问题：上下文窗口溢出要分块处理、测试污染要隔离环境、依赖白名单防止 Agent 引入不安全的包。
一句话总结
Coding Agent 的核心是先理解需求和代码库，再动手改文件，通过测试迭代和人工审查保证质量，整个过程必须在沙箱隔离的安全环境下运行。