案例分析一：修复一个陌生 Python 项目——固定 Workflow 为什么会迅速膨胀？

场景背景

假设我们想做一个内部工具，用户提交一个 Python 项目，系统自动判断为什么项目启动失败。

第一版很自然：

读取 requirements.txt
  ↓
读取 app.py
  ↓
运行 python3 app.py
  ↓
分析报错
  ↓
输出建议

对于某些标准 Flask 项目，这条链完全能用。

问题矛盾

第一个真实项目来了：

project/
├── src/
│   └── main.py
├── pyproject.toml
└── tests/

没有 app.py。

也没有 requirements.txt。

于是第一版 Workflow 两步都失败。

你补规则：

如果没有 requirements.txt → 查 pyproject.toml
如果没有 app.py → 查 main.py

第二个项目：

project/
├── server.py
├── environment.yml
└── config/

继续补。

第三个项目是 Django。

第四个项目用 Poetry。

第五个项目根本不是依赖问题，而是环境变量缺失。

第六个项目测试代码本身有 Bug。

你会发现，Workflow 不是不能做，而是规则数量会越来越大。

输入与前置条件

假设我们的 Harness 提供：

list_files
read_file
search_files
run_python
run_test

解决过程

Agent 可能走：

Goal：定位启动失败原因
 ↓
Action：list_files
 ↓
Observation：发现 pyproject.toml、src/main.py
 ↓
Action：read_file(pyproject.toml)
 ↓
Observation：requires-python >= 3.9
 ↓
Action：检查当前 Python 版本
 ↓
Observation：3.9
 ↓
Reason：版本不满足
 ↓
Finish

另一个项目可能完全不同：

list_files
 ↓
read README
 ↓
run_test
 ↓
Observation：ImportError
 ↓
search_files
 ↓
read module
 ↓
Finish

同样目标，不同路径。

这就是 Agent 的优势。

将固定规则和两条实际排查路径并排后，Workflow 为什么会膨胀就很容易看出来：

左边试图提前覆盖项目结构、依赖工具和故障类型，规则网会随着新项目不断扩张；右边保留同一个 Goal 和一组受控 Tool，再根据刚拿到的证据选择不同路径。Agent 减少的不是必要检查，而是为了穷举未知情况而堆出来的僵硬分支。

输出结果

最终输出应该更像：

根因：
当前运行环境 Python 版本为 3.9，
但 pyproject.toml 要求 Python >= 3.9。

证据：
- pyproject.toml 中 requires-python = ">=3.9"
- 当前解释器版本为 3.9.x

建议：
切换到 Python 3.9 或更高版本，
重新安装依赖后再运行测试。

复盘与迁移

这个案例最值得迁移的不是“修 Python”。

而是判断方式，如果核心是“执行固定检查项”，Workflow 就够。

如果核心是“根据刚拿到的信息决定接下来查什么”，Agent 才真正有价值。

但即使用 Agent：

• 最大步数；
• Workspace；
• 权限；
• Shell 安全；
• 审批；

依然应该写死。

所以真正落地的是：

Workflow + Agent