Day 19 - Coding Agent Basics

今日目标

能设计「修复测试脚本失败」的 Coding Agent 完整流程，说清代码库上下文与测试闭环。

学习安排

核心概念

阅读重点

• 对应章节：第 5 章「Coding Agent 与代码生成」。
• 关注点：
• 代码是能创造新工具的工具：Coding Agent 可以写工具来扩展自己的能力。
• 代码库上下文：不理解项目结构的 Agent 只会盲改，改错地方的概率极高。
• 生产级 Coding Agent 工作流：测试闭环、patch、review、合入策略。
• 为什么必须运行测试：模型生成的代码不能只靠「看起来对」。
• 补充材料：
• Anthropic 官方 coding agent 资料（Claude Code 与 agentic coding 工作流）。
• 开源 coding agent（如 OpenHands）的设计文档与评测方式。

理解检查

• Coding Agent 和普通代码生成（一次生成一段代码）有什么区别？
• 为什么代码库上下文很重要？没有它，Agent 最可能在哪个环节出错？
• 为什么必须运行测试？「看起来正确」和「验证过」差在哪里？
• Agent 生成的 patch 是否可以直接自动合并？什么条件下可以？

实践任务

背景：你们的回归测试脚本在 CI 上失败，你想设计一个 Coding Agent 流程来自动修复，但必须保证「改得对、改得少、可回退」。

步骤：

• 按 7 步设计流程：读取失败日志、定位测试文件、理解项目结构、修改代码、运行测试、输出变更说明、等待人工 review。
• 每一步写清：输入、输出、检查点（做对没有）。
• 为「运行测试」设计范围：先跑失败用例，再跑同文件相关用例，最后跑冒烟集。
• 标注每一步失败时的处理方式。

产出：一份 coding_agent_flow.md，含 7 步流程骨架与每步的失败处理。

输出模板

Coding Agent 流程: 修复测试脚本失败
1. 读取失败日志
   输入: [CI 日志地址或文件]
   输出: [失败用例、错误信息、堆栈]
   检查: [错误类型是否明确；失败时 -> 报告人工，不猜测]
2. 定位测试文件
   输入: [失败用例名]
   输出: [测试文件路径 + 相关行号]
   检查: [文件存在、可读；失败时 -> 用 repo map 重试一次]
3. 理解项目结构
   输入: [测试文件]
   输出: [被测模块、依赖、代码约定]
   检查: [改动边界是否清楚；不清楚 -> 只读不改]
4. 修改代码
   输入: [定位结果 + 修复假设]
   输出: [patch / diff]
   检查: [改动最小化、不碰无关文件]
5. 运行测试
   输入: [patch]
   输出: [失败用例 + 相关用例结果]
   检查: [原失败用例通过且无新失败；否则回到第 4 步]
6. 输出变更说明
   输入: [修复过程记录]
   输出: [根因、改动内容、验证结果]
7. 等待人工 review
   输入: [变更说明 + diff]
   输出: [review 结论: 合入 / 打回]

示范输出

Coding Agent 流程: 修复 test_force_logout 失败
1. 读取失败日志
   输入: ci_logs/job_4521.txt
   输出: test_login.py::test_force_logout FAILED，AssertionError: assert '登录成功' not in response.text
2. 定位测试文件
   输出: tests/api/test_login.py 第 42 行断言
3. 理解项目结构
   输出: 被测模块 app/services/auth.py；依赖 fixtures/login_fixture.py；约定: 接口返回 JSON，code=0 表示成功
4. 修改代码
   修复假设: 后端新增 force_logout 状态码，成功响应里不再有「登录成功」文案
   输出 patch:
   - 断言改为兼容 code=0 与文案两种成功形态
   - 不触碰其他断言与文件
5. 运行测试
   pytest tests/api/test_login.py -k force_logout -> 1 passed
   pytest tests/api/ -> 42 passed，无回归
6. 输出变更说明
   根因: 接口返回结构调整；改动: 断言兼容新旧结构；验证: 42 个用例全部通过
7. 等待人工 review
   提交 PR，等待测试负责人 review 后合入

追问练习

• 如何降低 Coding Agent 引入回归的风险？除了跑测试还有哪些手段？
• Agent 改了 5 个文件才修好 1 个用例，你会打回吗？依据什么判断？
• 测试断言本身写错了，Agent 怎么识别「该改代码」而不是「该改测试」？
• auto-merge policy 该怎么定？哪些类型的改动允许免 review？

常见误区

• 把代码生成当 Coding Agent：不读上下文、不跑测试的生成只是一次性补全。
• 只跑失败的那一条用例：相关用例不跑，回归风险完全没被覆盖。
• 让 Agent 改测试来「通过」：测试被改坏比代码改坏更难发现。
• patch 直接合入：没有 review 与回滚路径，出问题无法收场。

进阶扩展

• 生产级 Coding Agent：沙箱执行、并行测试、快照与回滚。
• 评估 Coding Agent：用真实失败 issue 做 eval，比较修复成功率与改动规模。
• 合入策略与保护：code review 规则、auto-merge 白名单、危险文件只读。

今日作业

• 完成 coding_agent_flow.md 流程设计（7 步 + 每步检查点）。
• 用你手头一个真实失败用例走一遍流程，写出伪步骤。
• 为 auto-merge policy 定 3 条规则。
• 明天开始前，解释为什么「运行测试」是闭环的关键。

自检清单

• 我能设计「修复测试脚本失败」的完整流程。
• 我能说清代码库上下文为什么重要。
• 我能解释为什么必须运行测试。
• 我能为 patch 制定 review 与合入策略。
• 我能列出降低回归风险的手段。