构建 AI Agent 时容易犯的 15 个错误

Replit 的 AI 编程 Agent 在代码冻结期间删除了生产数据库——尽管有明确指令不要碰它——这成为了 2025 年最受关注的警示案例之一。这是一个真正有用的案例研究，因为underlying的错误并不罕见：Agent 拥有的权限超过了任务所需，而且没有任何硬性 guardrail 来阻止破坏性操作，不管模型最终决定做什么。大多数 AI Agent 故障都可以追溯到少数几个重复出现的错误。以下是你在交付之前值得了解的 15 个。

1. 为了"加快速度"授予广泛的系统访问权限。Replit 事件是这一模式最清晰的例子——一个拥有生产环境写/删权限的 Agent，而它的实际任务从未需要那种级别的权限。权限范围应该精确到任务所需，而不是原型阶段图方便。

2. 对不可逆操作没有硬性 guardrail。即使权限合理，Agent 执行破坏性操作（删除数据、发送通信、修改财务记录）时，应该触发硬编码的确认步骤或 human-in-the-loop 检查点，而不是依赖模型"决定"不做。

3. 只在精选的 happy-path 示例上测试。演示在干净输入上能工作。生产环境不会发送干净的输入。在将 Agent 交给真实流量之前，用真实的历史请求构建你的测试集，包括那些混乱、不完整甚至是对抗性的请求。

4. 对不确定行为没有明确定义。一个不确定的 Agent 应该提出澄清问题、升级或拒绝——而不是猜测并自信地给出错误答案。Chevrolet 被广泛报道的经销商聊天机器人事件——客户操纵它同意以一美元出售车辆——就是一个 public 例子，说明当 Agent 对超出范围的请求没有拒绝或升级的边界时会发生什么。

5. 忽视 prompt injection 作为攻击面。如果你的 Agent 读取外部或用户提供的文本，并且拥有工具访问权限，那么该文本就是一个攻击向量。OWASP 的 LLM 应用 Top 10 正是基于这个原因将 prompt injection 列为最高风险类别——拥有工具访问权限的任何 Agent 都需要与 public API 端点相同 threat modeling。

6. 在出问题之前跳过可观测性建设。可追溯的决策日志——Agent 看到了什么、决定了什么、为什么——是分钟级调试事故和几周后从记忆中重建之间的区别。从第一个 pilot 开始就建立日志，而不是在事故迫使你面对之后才亡羊补牢。

7. 把演示当作工程工作的主要内容。一个可工作的演示通常只占生产实际所需的 20%。集成、权限范围、失败处理和监控是另外的 80%，它们不会在演示中出现。

8. 没有升级到人类的路径。每个执行真实操作的 Agent 都需要一条明确的"转交给人"的路径，用于处理超出其能力范围的情况——而不是死胡同，Agent 要么成功，要么无声地失败而没有任何恢复路线。

9. 第一个项目范围过大。全流程客户支持自动化或完全自主的工作流管理器是这个问题最难的形式。从狭窄的场景开始——工单分类、报告摘要——先证明它可行，然后再扩展。

10. 假设 Agent 行为是确定性的。与传统自动化不同，相同的输入并不总是产生相同的输出。围绕 Agent 构建的系统和流程需要考虑这种可变性，包括重试、验证步骤，以及在输出被执行之前对其进行合理性检查。

11. 没有对行为漂移的监控。一个在发布时可靠运行的 Agent 会随着底层数据变化、模型提供商更新模型或使用模式变化而退化。持续的漂移监控是运营需求，而不是一次性的验收测试。

12. 低估集成复杂性。将 Agent 连接到真实的记录系统——CRM、ERP、工单系统——通常是构建过程中最慢、最不吸引人的部分，而那些为推理逻辑做预算却不为集成工作做预算的团队，在时间和成本上总是会超支。

13. 没有应对模型或提供商变化的计划。提供商会废弃模型并改变行为。与某个特定模型紧密耦合、没有抽象层的 Agent 架构是脆弱的——这种脆弱性在收到废弃通知、迫使紧急迁移之前很容易被忽视。

14. 忽视规模下的成本曲线。一个每个任务调用几次模型的 Agent 在只有十个测试运行的演示中看起来很便宜，但在生产规模下就一点也不便宜了。模型路由——简单子任务用更便宜的模型， frontier 模型留给真正困难的推理——比大多数团队预先计划的要重要得多。

15. 部署时没有回滚计划。如果一个 Agent 在生产环境中开始表现异常，需要有一种快速、干净的方式禁用它或回滚到之前的流程，而不需要为期数天的紧急抢救。把这当作你对待任何其他生产部署回滚计划的方式来对待。

贯穿这 15 个问题的共同主线：几乎没有一个是模型问题。它们都是工程和治理问题——这些围绕模型的不起眼的工作不会在演示中出现，但决定了 Agent 能否在真实生产流量中存活。从一开始就把权限范围和架构当作一等设计决策来处理，而不是当作收尾工作——这就是让一个 Agent 能够交付而不是成为下一个 Replit 式事故报告的区别所在。