智能体项目的“立项评审”清单：在资源投入前，必须回答的 7 个残酷问题

这不是一篇教你“如何做 Agent”的文章。

这是在你决定要不要做之前，必须先通过的一次工程拷问。

如果一个智能体项目在立项阶段就回答不了下面的问题，那么它后续出现的：

• Agent 行为不稳定

• Prompt 越写越长

• 错误无法复现

• 系统无法演进

都不是“模型不行”，而是立项失败的延迟后果。

使用说明：如何阅读这 7 个问题？

• 每一个问题，不是“愿景问题”，而是工程问题

• 每一个问题，都只有三种状态：

  • ✅ 已明确

  • ⚠️ 模糊但有路径

  • ❌ 无法回答

• 出现 ≥2 个 ❌，建议直接否决立项

问题一：这个项目的“智能”到底负责什么？

如果 Agent 行为出错，你准备让它为哪一类决策负责？

这是最残酷、也最常被跳过的问题。

错误回答示例

• “负责帮用户更高效完成任务”

• “负责自动化流程”

• “负责理解用户意图”

这些都是功能描述，不是责任边界。

工程化回答应该是

• 它负责任务拆解顺序

• 它负责工具选择

• 它负责是否请求澄清

• 它负责何时停止

✅ 如果你能清晰说出Agent 的决策责任面

❌ 如果你只能描述“它会做什么”

问题二：失败发生时，你预期谁来“反思”？

失败后，是人来总结，还是系统自己生成改进信号？

这是区分Demo 项目和工程项目的分水岭。

两种完全不同的系统走向

立项阶段必须明确

• 是否设计行动后反思（Post-Action Review）

• 是否有结构化失败记录

• 是否有失败进入系统的通道

✅ 如果你已经设计了 Reflection / Case 结构

❌ 如果你回答：“先跑起来再说”。

问题三：Agent 的行为空间是否真的不可枚举？

这个问题，用规则+Tool 能不能解决？

这是一个防止过度 Agent 化的关键问题。

你应该警惕这些信号

• 行为路径其实固定

• 决策条件可枚举

• 错误类型是实现错误，而非决策错误

如果是这样：你需要的是Tool，不是Agent

✅ Agent 的必要条件：

• 行为组合指数级

• 顺序 / 时机 / 上下文高度相关

• 错误需要“复盘”，而不是“修 bug”

问题四：错误是否具有“跨任务复现价值”？

这个 Agent 犯的错，值不值得被长期记住？

这是一个是否值得投入工程成本的问题。两类完全不同的错误

✅ 如果错误模式可以跨任务复现

❌ 如果错误大多是环境噪声。

问题五：这个 Agent 的改进，会不会牵一发动全身？

你能否在不破坏系统其他部分的前提下，让它变好？

这是一个系统耦合度问题。高风险信号

• 改 Prompt 会影响所有场景

• Router 和 Prompt 强耦合

• 一个改动需要“全量回归”

✅ 成熟设计应当允许：

• 局部 Prompt 演进

• 用例级回归

• 可回滚策略

❌ 如果你现在就知道：“改它一定会影响别的 Agent”，那不是智能，是系统性脆弱。

问题六：你准备用什么指标判断“它变好了”？

不是离线评测，而是线上行为指标。

如果你的回答是：

• BLEU / Rouge

• 人工感觉

• “好像更聪明了”

那这不是工程项目。工程上至少要明确一类指标

• 决策错误率

• 重试次数

• 人工兜底频率

• 用户澄清触发率

✅ 如果指标和 Agent 决策责任强相关

❌ 如果指标只是模型输出质量

问题七：当它表现不好时，你是“修它”，还是“下线它”？

Agent 是否允许被降级、冻结或替换？

这是最后一个，但极其关键的问题。成熟系统的现实

• Agent 不是永远正确

• 某些阶段它可能比规则更差

• 某些版本必须回滚

✅ 如果你设计了：

• fallback 路径

• Tool-only 模式

• 策略切换开关

❌ 如果你默认：“Agent 是系统核心，不能关”。那你不是在做工程，而是在下注。

结语：不是所有问题都值得用 Agent 解决

以上7个问题，覆盖了Agent的定义，概念，核心功能，错误处理，性能优化等方方面面。最后给一句立项级别的工程结论：Agent 是系统中最昂贵、最脆弱、也最难维护的单元。如果你在立项时就无法回答它的失败如何被吸收，那你不是在建系统，而是在制造未来的事故。