用 Agent 做工程：四个让自动化真正可靠的支柱

把 AI Agent 引入工程流程，最容易犯的错是把它当「更快的搜索引擎」——扔进去一个需求，等着它吐代码，然后把结果直接合并。这种用法能跑，但会把「不可靠」编码进你的工作流里，问题只会越来越多，不会越来越少。

我用 Agent 做工程的核心认知转变是：Agent 是执行者，人是质量与风险的守门人。真正可靠的 Agentic 工程有四根支柱，缺了哪根都会摇晃。

eval-first：先定义「完成」，再开始执行

最常见的反模式是：任务扔给 Agent，它生成了一堆输出，你凭感觉看看觉得差不多，合并。

这等于把质量控制环节完全交给直觉。

Eval-first 的做法是反过来：在执行之前，先写好能客观判断完成与否的评估。两类 eval 缺一不可：

• 能力 eval：这个任务的目标是什么？用什么标准验收？（通过率、回归测试、边界 case）
• 回归 eval：改这里不能破坏哪些已有行为？baseline 是什么？

先跑一次 baseline，记录失败签名（哪些 case 本来就过不了、哪些是新引入的）。执行完之后，对比 delta，而不是对比最终结果本身——delta 才是 Agent 这次到底干了什么。

这个顺序很重要。eval 写在执行前，是对任务边界的强制澄清；eval 写在执行后，往往会无意识地迁就已有输出，失去客观性。

任务分解：15 分钟单元规则

Agent 在明确边界的短任务上表现最好，在模糊的长任务上最容易偏移。

一个健康的任务分解单元有三个特征：

1. 独立可验证——可以单独跑 eval，不依赖其他未完成单元
2. 单一主风险——只有一个需要人工确认的高风险决策点
3. 清晰的完成条件——Agent 和人都能判断「这个单元做完了」

「15 分钟」不是精确的时间约束，而是一个量级感：如果你觉得一个单元需要 Agent 工作超过一个小时才能完成，它大概率需要再拆。拆不动的原因往往不是粒度问题，而是前置的设计或 spec 不够清晰——这时候的正确动作是先补设计，不是让 Agent 硬撑。

模型路由：用对了省钱，用错了返工

不是所有任务都需要最强的模型，但用错了会产生两种损耗：用低档模型做超出能力的任务会导致返工；用高档模型做简单任务会浪费成本和时间。

一个粗粒度的路由原则：

• 分类、模板变换、窄范围修改：用小模型，速度快，成本低，足够
• 功能实现、重构、有一定上下文推理量的任务：用中档模型
• 架构决策、跨文件不变量分析、根因诊断：用旗舰模型

关键原则是只在下一档明确失败时才升级，不要「以防万一」地一律用最强模型。升级的触发条件是「低档模型给出了有推理缺口的输出」，而不是「感觉这个任务看起来很难」。

成本纪律：把每次调用当作可测量的投资

在 Agentic 工作流里，成本容易失控的原因不是单次调用贵，而是重试链和长 session 累积。一个没有成本观测的工作流，等账单来了才发现问题。

每个任务单元应该跟踪：使用了哪个模型、大概的 token 量、重试了几次、用了多少时间、最终是成功还是失败。这四个维度放在一起，能快速看出哪类任务的 ROI 最差——是任务分解不对，还是 eval 太松导致反复返工，还是模型路由选错了。

Session 策略同样重要：耦合紧密的连续子任务可以共享 session；大阶段跨越之后应该开新 session；里程碑完成后做压缩，不要在调试过程中压缩（会丢失关键上下文）。

一句话心法

用 Agent 做工程的本质，是把「不确定性」转移到可测量的边界里——eval 定义边界，分解控制范围，路由平衡成本，纪律保证可观测性。