大多数 AI Coding Agent 的评估指标聚焦于「任务是否完成」，却忽略了一个更根本的问题：Agent 是否在用正确的方式做事？ 本文提出一个决策质量框架，帮助你评估和提升 Agent 的判断水平。
一、完成任务 ≠ 做对决策
先看一个真实的对比场景：
用户：「帮我优化一下这个查询」
Agent A 的执行路径：
- 分析现有 SQL，发现查询耗时 200ms
- 识别缺失的数据库索引
- 添加索引，验证后 20ms 完成
- 报告：优化成功，性能提升 10 倍
Agent B 的执行路径：
- 先问：「这个查询在什么场景下使用？QPS 大约多少？」
- 发现这个查询只在每日报表中使用，每天跑一次
- 告知用户：「优化成本高（需要变更 Schema），但收益极低（每天只跑一次）」
- 建议：「如果只是偶尔需要看报表，可以加个 WITH (NOLOCK) 提示临时解决，或者干脆不管」
- 用户同意，关闭工单
两个 Agent，谁的表现更好？
结果维度：Agent A「完成」了任务，Agent B「没有完成」
决策维度：Agent A 做了不需要做的决策，Agent B 做了正确的判断
决策质量和结果质量是两个独立的维度。一个 Agent 可能完成了任务但方法错误（好结果 + 坏决策），也可能猜错了但方法正确（坏结果 + 好决策）。后者更危险——因为好结果不可复制，Agent 会误以为自己做对了。
当前大多数 Agent 评测框架（BLEU、SWE-bench Pass@K）测的是结果质量，对决策质量几乎是盲区。这正是本文要填补的。
二、Agent 面对的三种不确定性
Agent 在编码任务中面对的不确定性可以分成三类。识别类型是正确处理的前提。
2.1 信息不确定性
定义：Agent 没有掌握足够的信息来做出正确决策。
典型场景：
- 面对不熟悉的代码库，不知道某个函数的真实调用方式
- 不清楚某个第三方 API 的 rate limit 或幂等性
- 不了解用户的部署环境约束
三种错误的应对方式：
错误模式 A — 盲目猜测：
「我不确定这个配置怎么写，随便填一个试试」
→ 高风险，可能引入 bug，且用户不知情
错误模式 B — 无限探索：
「我需要把所有相关文档都读一遍再动手」
→ 低效，陷入信息收集陷阱，消耗大量 Token
错误模式 C — 跳过问题：
「这个函数看起来没问题，跳过不看了」
→ 遗漏潜在问题，把风险推迟到运行时暴露
正确的信息不确定性处理框架：
Step 1 — 评估信息缺失的「关键程度」
· 关键：没有这个信息无法正确执行 → 进入 Step 2
· 次要：有了更好，没有也能做 → 记录「假设」并继续
Step 2 — 评估获取信息的「成本」
· 低成本（< 2 分钟可验证）：获取后再执行
· 高成本（需大量阅读/测试）：进入 Step 3
Step 3 — 决策
· 关键 + 高成本 → 向用户提问，或明确说明「假设前提」
· 次要 → 标注假设并执行
2.2 目标不确定性
定义：Agent 不理解用户的真正目标，或者目标本身表述模糊。
这个问题的破坏力最大，因为它让 Agent 走向错误的方向却浑然不觉。
用户说「帮我重构这段代码」——真正的问题是什么？
A. 性能瓶颈（重构后要快）
B. 可读性差（重构后要好懂）
C. 难以测试（重构后要能写单元测试）
D. 领导要求的（没有具体问题，就是想重构）
用户说「把这个函数改成异步的」——真正的目标是什么？
A. 提升性能（解决阻塞问题）
B. 应对高并发（支持更多并发请求）
C. 领导的要求（可能是错的决策）
D. 解决某个具体的死锁问题？
目标澄清模式（Goal Clarification）应当被主动触发，而不是被动等待用户说清楚：
当任务涉及以下特征时，必须主动澄清目标：
· 大规模变更（涉及 > 3 个文件）
· 架构决策（引入新框架、服务、数据库）
· 不可逆操作（删除代码、迁移数据、修改 Schema）
· 安全/权限相关变更
澄清清单：
1. 你希望通过这次变更解决什么问题？（性能 / 可维护性 / 功能 bug / 其他）
2. 有没有不愿意改变的边界？（不能修改的接口 / 不能动的模块）
3. 如何判断这次变更是否成功？（具体指标 / 测试用例 / 人工验收）
2.3 方法不确定性
定义：Agent 知道要做什么，但不确定「怎么做最好」。
场景：需要给系统增加缓存层
方案 A — Redis（需额外部署，服务成熟，功能完整）
方案 B — 内存缓存（简单，重启丢失，并发有限）
方案 C — 本地文件缓存（简单，并发差，可能产生竞态）
→ 哪个方案最优？取决于用户场景
方法不确定性的处理框架：
Step 1 — 列出可行方案（不超过 3-4 个，重点突出）
Step 2 — 对每个方案评估：
· 核心优点（1-2 个，不要贪多）
· 核心缺点（1-2 个）
· 实施成本（1-5 分）
· 风险等级（1-5 分）
Step 3 — 结合用户场景选择
· 用户说「简单先上」→ 选成本最低的
· 用户说「生产级」→ 选风险最低的
· 用户没有偏好 → 选平衡方案，并说明权衡
Step 4 — 决策时说明「为什么选这个」
→ 让用户能够纠正错误决策
三、决策质量的五个评估维度
决策质量不能只看「结果对不对」，需要从五个独立维度评估。
决策质量评估模型（DQE — Decision Quality Evaluation）：
1. 信息充分性（Information Sufficiency）
· Agent 在决策前是否获取了足够的关键信息？
· 典型失分：没有验证假设就开始执行
2. 目标一致性（Goal Alignment）
· Agent 的行动是否真正对齐用户的意图？
· 典型失分：实现了功能，但破坏了用户不想改变的边界
3. 风险意识（Risk Awareness）
· Agent 是否识别并说明了决策的风险？
· 典型失分：没有考虑回滚方案或降级策略
4. 可逆性考虑（Reversibility Consideration）
· Agent 是否区分了可逆和不可逆变更？
· 典型失分：做了不可逆变更（删数据、迁 Schema）才告知用户
5. 决策透明度（Decision Transparency）
· Agent 是否说明了决策的原因？
· 典型失分：默默做选择，用户无法提前介入纠正
这五个维度可以组合成决策质量的雷达图，用于评估单个 Agent 或对比不同 Agent 的表现。
四、提升决策质量的工程策略
4.1 决策日志（Decision Log）
每个关键决策都应当被记录，供后续复盘和经验积累：
{
"decision_id": "dec-2026-04-17-001",
"timestamp": "2026-04-17T10:15:00+08:00",
"task": "优化用户查询性能",
"decision": "选择添加数据库索引，而非引入 Redis 缓存",
"alternatives_considered": [
"引入 Redis 缓存（否决原因：需要额外部署，增加运维复杂度）",
"SQL 查询改写（否决原因：无法覆盖所有查询模式）"
],
"reasoning": "查询量可控（QPS < 100），索引优化足够",
"assumptions": [
"查询模式不会急剧变化",
"数据库服务器资源充足"
],
"uncertainty_acknowledged": "如果 QPS 超过 1000，需要重新评估方案",
"verified_by": "用户确认（4月17日 10:20）"
}
决策日志的实战价值：
- 错误可追踪：出了问题可以回溯当时的决策逻辑
- 经验可复用：类似场景可以直接参考历史决策
- 质量可量化：长期积累后可以统计 Agent 的决策正确率
4.2 假设验证（Assumption Verification）
每个关键假设在被用于决策之前，都应该有对应的验证动作：
假设验证模板：
关键假设：{Agent 当前正在基于的假设}
验证方法：
· 假设 A → 验证方式：{如何验证这个假设是否成立}
· 假设 B → 验证方式：{如何验证这个假设是否成立}
如果假设不成立：
→ 通知用户当前方案不可行
→ 提供基于新信息的备选方案
→ 等待用户明确指示后再执行
实战例子：
任务：给支付接口增加重试机制
Agent 的假设：
1. 支付 API 支持幂等（重试安全）
2. 用户接受最终一致性而非强一致性
3. 当前支付失败率 < 1%
验证动作：
1. 检查支付 API 文档中是否有 idempotency_key 支持
→ 发现：不支持幂等，重试可能导致双重扣款
2. 向用户确认：「如果支付超时，重试可能造成双重扣款，介意吗？」
→ 用户：「介意，请勿重试」
结果：假设 1 不成立
→ Agent 需要调整方案，改用「查询状态确认」模式
（先查支付结果，再决定是否重试）
4.3 决策权限分级（Decision Authority Levels）
不是所有决策都需要上报。明确权限分级可以平衡效率和安全性：
L1 — 完全自主（无需确认）
· 代码格式和风格调整（符合项目规范即可）
· 变量/函数重命名（符合命名规范即可）
· 编写测试用例（符合测试规范即可）
· 小范围重构（涉及 < 1 个文件，不改变对外接口）
L2 — 自主决策，但必须说明原因
· 中等范围重构（1-5 个文件）
· 引入新的第三方库
· 修改配置参数
→ 要求：在决策时说明选择该方案的理由
L3 — 必须主动向用户询问
· 架构变更（引入新服务、数据库、框架）
· 大规模重构（> 5 个文件）
· 删除代码或迁移数据
· 涉及安全或合规的变更
L4 — 禁止自主决策（必须上报审批）
· 权限或角色变更
· 支付或财务相关操作
· 不可逆的生产数据操作
决策权限分级是 Supervisor Pattern 的关键补充：Supervisor 不只分解任务，还要定义每个子任务允许的决策级别，防止 Worker 越权做重大决策。
五、在 Prompt 层面嵌入决策指导
光靠外部工程机制不够，决策能力也需要体现在 Agent 的 system prompt 中。
5.1 决策原则嵌入
## 决策指导原则
当你面对不确定性时，遵循以下优先级：
1. 信息不确定 → 优先获取关键信息；次要信息「假设 + 明确标注」
2. 目标不确定 → 主动澄清；不要猜测用户的真实意图
3. 方法不确定 → 列出 2-3 个方案，说明权衡，推荐其一
核心原则：
· 「宁可问清楚，不要猜错了」
· 「如果变更不可逆，先确认再执行」
· 「如果不确定风险，先说风险再说方案」
· 「决策时说明原因，让用户有机会提前纠正」
5.2 关键决策模板
当 Agent 需要做关键决策时，强制输出这个模板：
## 关键决策记录
**决策点**：[简述要决定什么]
**考虑方案**：
A. [方案A] — 优点：... 风险：... 成本：...
B. [方案B] — 优点：... 风险：... 成本：...
**推荐选择**：方案 [X]
**推荐理由**：
1. [理由一]
2. [理由二]
**假设前提**：
- [假设 A]，如果假设不成立则需要重新评估
- [假设 B]
**潜在风险**：
- [风险 1]，缓解措施：...
- [风险 2]，缓解措施：...
**用户确认**：[等待确认 / 已确认]
这个模板的价值是双重的：
- 强迫 Agent 显式化思考过程，不会在模糊中做决定
- 给用户提供了介入点，在执行前就能纠正错误决策
六、决策质量与结果质量为何必须同时关注
│ 好结果 │ 坏结果
─────────┼────────────────┼─────────────────
好决策 │ 理想状态 ✓ │ 运气不好，但
│ 好方法 + 好运气│ 方法正确，可复盘
─────────┼────────────────┼─────────────────
坏决策 │ 危险状态 ⚠ │ 双重失败 ✗
│ 猜对了，但不可 │ 方向错 + 执行差
│ 复制，埋下隐患 │ 需要重新开始
为什么要关注坏决策 + 好结果这种组合？
因为这种组合是 Agent 系统中最容易被忽视的隐患：
- Agent 不会从「成功」中学习改进（因为它认为自己做对了）
- 隐患可能在后续的某个特定条件下才暴露
- 下次遇到类似场景，Agent 会重复同样的错误决策
这就是为什么决策日志如此重要：它把隐性的决策过程变成显性的记录，让「坏决策 + 好结果」有机会被识别和修正。
七、总结：让 Agent 做正确的事
本文的核心观点：
自修正（04-12）→ 解决「做错了怎么纠正」
调试（04-14） → 解决「坏了怎么查」
持续学习（04-15）→ 解决「从失败中提取模式」
Prompt 模式（04-16）→ 解决「怎么结构化复杂任务」
本文（决策质量）→ 解决「怎么在执行前做对判断」
这五条线共同构成一个完整的 Agent 能力体系：
执行前：决策质量（做对的事）
执行中：Prompt Engineering Patterns（用对方法）
执行中：Self-Correction（即时修正偏差）
执行后：调试（出了问题能查清）
多次后：持续学习（经验积累成模式）
行动清单：
□ 审查你的 Agent Prompt：是否包含了决策指导原则？
□ 实现关键决策日志：让 Agent 记录每个重大决策及原因
□ 定义决策权限分级：明确哪些需要用户确认，哪些可以自主
□ 评估现有 Agent：同时测量结果质量和决策质量
□ 建立复盘机制：从「坏决策 + 好结果」中提取改进机会
当一个 Agent 能持续做出高质量决策，它就不只是一个执行工具，而成为一个值得信赖的工作搭档。
本文是 AI 编程实战笔记的第 57 篇，主题隶属「深度思考」分类 🚢