案例分析一：一个“会修 Bug”的 Coding Agent，最终到底会经历哪些步骤？

场景背景

我们先提前看看课程最终项目之一。

用户上传一个 Flask 项目，然后提交任务，“这个项目启动时报错，帮我定位原因。如果能安全修复，就修改后重新测试。”

传统聊天模型需要你自己复制代码、复制报错，再让模型分析。

我们最终的 Coding Agent 希望直接在受限 workspace 里工作。

问题矛盾

真正难的不是“模型会不会看报错”。

难的是：

• 项目入口文件叫什么？
• 应该先跑测试还是先读 README？
• 可以读取哪些文件？
• Shell 命令是否安全？
• 修改前要不要备份？
• 修改以后怎么验证？
• 如果第一次修复失败怎么办？
• 一共允许尝试多少次？

这些都需要 Harness。

前置条件

假设最终系统提供：

list_files
read_file
search_files
edit_file
run_python
run_shell
run_test

同时 Harness 限制：

只能访问 workspace/
最大 30 Step
Shell 命令必须经过安全检查
删除操作需要人工审批
所有 Tool Call 写入 Trace

解决过程

一次可能的执行轨迹是：

Step 1
Agent：先查看项目结构
Tool：list_files
Observation：发现 app.py、requirements.txt、tests/

Step 2
Agent：读取 app.py
Tool：read_file
Observation：发现 import requests

Step 3
Agent：读取 requirements.txt
Tool：read_file
Observation：没有 requests

Step 4
Agent：运行测试确认
Tool：run_test
Observation：ModuleNotFoundError: requests

Step 5
Agent：形成修复建议
Tool：edit_file
Observation：requirements.txt 已加入 requests

Step 6
Agent：再次运行测试
Tool：run_test
Observation：测试通过

Step 7
Agent：结束任务

注意，这条路径不是写死的。

如果把刚才的修复轨迹和执行边界叠在一起，Coding Agent 的工程重点会非常直观：

主流程可以根据测试结果回到“定位根因”继续迭代，但无论 Agent 选择哪条路径，都不能越过 workspace、Shell 安全检查、最大步数和人工审批这些硬约束。动态的是排查策略，不变的是执行底线。

另一个项目可能第一步就去读 pyproject.toml，另一个项目可能先跑测试，另一个项目可能根本不需要修改代码。

输出结果

最终用户得到的不应该只有一句，“修好了。”

而应该包含：

根因：
项目代码依赖 requests，但依赖文件中未声明。

修改：
requirements.txt 新增 requests。

验证：
测试重新执行后通过。

执行步数：
7

风险操作：
无

Trace：
可查看完整 Tool Call 与结果。

复盘与迁移
这个案例让我们提前看到为什么 Harness 才是重点。

模型只负责，“下一步应该做什么？”

真正让整个过程可控的，是：

Tool Registry；
Workspace；
Safety；
Max Steps；
Test；
Trace；
Run。
后面 Coding Agent 项目只是把这些我们一路搭起来的模块组合到一起，并不是突然变出一个“神奇 Agent”。

同样的思路可以迁移到代码审查、测试生成、依赖排查、配置诊断等场景。只要任务具有“看结果再决定下一步”的特点，就可以把动态判断交给 Agent；而文件权限、命令安全、最大步数等稳定规则仍由 Harness 控制。