SCOPE本章边界
本章专门讲 coding agent。通用的 ToolPipeline、ContextProjection、Permission 和 Reliability 已在前面章节讲过；这里把它们落到软件工程任务：repo map、search、edit、test、CI、review、merge 和 large repo context。
30 SEC面试开口版
Coding Agent 的核心不是会写代码，而是有一个稳定的 Agent-Computer Interface：它能在大型 repo 里定位相关文件，生成小而可审查的 patch，选择合适测试验证，并把证据交给用户或 CI。我会先建 repo map：目录、符号、imports、call graph、recent changes、test ownership；定位时结合 ripgrep、symbol search、历史错误和少量 embeddings，不把全仓库塞进 prompt。修改时走 atomic diff、format/lint/test gate；测试按风险分层，从相关单测到模块测试再到全量/CI。flaky test 要有重跑和历史 flake rate，不能把一次 flaky pass 当强证明。最终输出要包含 changed files、why、test evidence、risk 和 rollback。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Repo Map：仓库结构、符号、依赖、测试和最近变更的索引。 Patch Strategy：如何生成、应用、审查和回滚代码 diff。 Test Selection：根据变更范围和风险选择要跑的测试。 Flaky Test Policy：不稳定测试的识别、重跑和证据权重策略。 Review Evidence：给审查者看的变更原因、测试结果、风险和证据引用。 |
| 为什么这样回答 | 先把 coding agent 从“代码生成器”提升为“软件工程运行系统”。面试官会追 large repo、测试慢、patch 冲突、flaky、CI 和 review 风险，回答要让每个环节都有 runtime 对象。 |
| 小白解析 | 写代码只是其中一步。真正难的是知道该改哪里、别改错依赖、改完怎么证明没坏、测试失败是不是自己的锅、给审查者怎么解释。 |
| 关联知识点 | 前面章节的 Context、Tool、Reliability、Eval 都会在 Coding Agent 里被放大：文件上下文会过期，shell 有风险，测试是 verification gate，CI artifact 是证据。 |
1 MIN一分钟口语版
我会把 Coding Agent 的闭环拆成六步。第一步理解任务：从用户问题、错误日志、issue、PR 反馈中抽出目标和验收标准。第二步定位：用 repo map、ripgrep、符号搜索、测试 ownership 和最近变更找候选文件，而不是把 repo 全塞给模型。第三步建上下文：只读相关文件片段、接口、调用链、测试和配置，所有片段带 hash，写后要 read-after-write。第四步 patch：生成最小 diff，避免无关重构，应用前后记录变更和冲突。第五步验证：先跑相关单测和格式化，再按风险升级到模块测试、端到端或 CI；flaky 要重跑并标不确定。第六步交付：输出变更摘要、测试证据、残余风险、回滚路径和后续建议。这样 Agent 才像一个可审查工程师，而不是一次性补全工具。
理解与记忆 · 术语、解析、关联知识点
| 专业术语 | Read-after-write：写文件后重新读取当前内容，避免基于旧上下文继续推理。 Atomic Patch：一次可审查、可回滚的最小变更。 Test Ownership：文件、模块或功能对应的测试集合。 Risk Scoring：按公共 API、迁移、安全、并发、生成代码等给变更评风险。 CI Artifact：远端构建、测试日志、覆盖率和截图等证据。 |
| 为什么这样回答 | 一分钟版按真实修 bug 流程讲，能自然引出 ACI、context、patch、verification、review。它不是炫工具，而是说明 Agent 如何降低软件工程风险。 |
| 小白解析 | 像资深工程师修 bug：先复现或读日志，再找相关代码，小改一处，跑测试，最后写清楚改了什么和还有什么风险。 |
| 关联知识点 | SWE-agent 强调 ACI 会影响软件工程任务表现；Guga 的工具管线和 artifact store 可以承载 diff、测试日志、CI 证据和 replay。 |
FLOW从 bug 到可审查 patch
Coding Agent 的工程闭环
DESIGN关键策略表
| 环节 | 设计要点 | 常见错误 |
|---|---|---|
| 定位 | rg + symbol search + repo map + recent changes + test ownership。 | 只靠 embedding，召回相似但无关文件。 |
| 上下文 | 文件片段带 hash/version，写后重读，冲突显式标记。 | 基于旧文件片段继续改，覆盖用户变更。 |
| Patch | 最小 diff、保留风格、避免无关重构、可回滚。 | 顺手重构大片代码，让 review 难以接受。 |
| Test | 先相关单测，再模块/集成/CI，失败分类 deterministic vs flaky。 | 测试太慢就不跑，或 flaky pass 当强验证。 |
| Review | changed files、why、evidence、risk、rollback、open questions。 | 只说“修好了”，不给证据。 |
INTERVIEW高强度追问
面试官：大型 repo 里第一步怎么定位？
我会先用低成本信号缩小范围：错误栈、文件名、符号、接口名、日志关键字、最近变更、目录约定、测试 ownership。然后用 rg 和 symbol search 找候选，再读少量关键文件。embedding 可以辅助，但不能替代结构化搜索和代码索引。
面试官：repo map 里应该有什么？
至少有目录模块、symbols、exports/imports、call graph、dependency graph、test mapping、generated files 标记、ownership、recent changed files、CI commands、lint/format commands。它不是一次塞给模型，而是帮助 runtime 选择上下文。
面试官：上下文太大怎么办？
不把全仓库塞进去。先给任务目标、相关符号、文件摘要、关键片段、调用链、测试和最近 diff。每段带 source path、line、hash 和为什么包含。需要更多细节再按需读取，避免旧片段和无关代码污染模型。
面试官：Agent 修改文件后还用原来的上下文继续推理，会有什么问题？
会基于旧世界推理。写后要 read-after-write，更新 file hash、diff 和 context source；如果用户或另一个 Agent 同时改了文件，要检测冲突。否则模型可能覆盖用户变更，或继续引用已经不存在的代码。
面试官：Patch 应该多大？什么时候允许重构？
默认最小可验证 patch。除非 bug 根因在抽象层或重复导致风险，否则不做无关重构。重构要单独 plan item、单独风险说明和更宽验证。面试里我会强调可审查性：小 patch 更容易验证和回滚。
面试官：测试太慢，Agent 怎么选测试？
按风险分层。先跑改动文件对应单测和失败复现测试，再跑模块测试；公共 API、迁移、安全敏感、并发或跨模块变更再升级到集成测试或 CI。Test selection 要记录为什么选这些、为什么没跑全量。
面试官：测试失败了，怎么判断是 bug 还是 flaky？
看失败是否稳定复现、是否和改动相关、历史 flake rate、失败日志类型和重跑结果。确定性失败要修；疑似 flaky 要标 uncertain，重跑有限次数，不能把一次 pass 当强证据。最终报告要说明验证可信度。
面试官：CI 集成怎么做？
本地先跑快速验证，远端 CI 负责更完整环境。Agent 要能读取 CI status、日志 artifact、失败分类和截图；如果 CI 失败，回到定位/patch 循环。PR 说明里引用本地和 CI 证据，不只贴最终状态。
面试官：怎么处理 patch 冲突？
冲突不是让模型盲目覆盖。runtime 要保留 base hash、current hash、agent patch 和 user changes，做 three-way merge；无法自动合并时给模型和用户看冲突 hunk。高风险文件进入人工 review。
面试官：哪些文件不应该让 Agent 随便改？
密钥、生产配置、迁移、权限策略、支付、安全敏感代码、生成文件、lockfile、大规模公共 API、法律文本都要更高风险等级。可以允许提案，但执行要审批、diff preview、额外验证和 rollback plan。
面试官：代码审查输出应该包含什么？
包含变更摘要、根因、changed files、关键 diff、测试命令和结果、未跑测试原因、风险、回滚方式、开放问题。给审查者的是证据链，不是“我觉得可以”。
面试官：Coding Agent eval 怎么做？
看 task success、patch correctness、regression rate、test pass rate、review acceptance rate、unrelated diff rate、time to fix、cost per accepted patch、flaky misclassification、security-sensitive false edits。SWE-bench 类任务有价值，但内部真实失败集更重要。
面试官：Agent 要不要自动提交或开 PR？
可以，但要分层。低风险小 patch 可以生成 PR draft；合并、发布、迁移和生产配置改动需要人工确认。提交信息要引用 trace 和 test evidence；自动提交不是绕过 review，而是把可审查材料准备好。
面试官：MVP 先做哪些工具？
先做 read/search/edit、git diff/status、shell with sandbox、test runner、artifact store、patch preview、context projection 和 verification gate。先不做全自动 merge、跨 repo 大规模重构、无监督生产发布和复杂多 Agent 写同一 repo。先把定位、最小 patch、验证和审查跑稳。
PRINCIPLE我总结的核心范式
Coding Agent 的原则是“少读但读对，小改但可证，验证先于完成”。真正的价值不在生成代码，而在把定位、补丁、测试和审查证据放进可恢复的工程闭环。