AI Agent 更需要可靠性，而不是单纯更强能力

评估 AI Agent 最有价值的问题不是“它能不能做成一次”，而是“在季度最糟糕的那个周二，它能不能安全失败”。这句话没有演示视频里那么刺激：Agent 打开浏览器、写代码、更新 CRM、再把总结发到 Slack。但对产品运营、创始人和正在引入 Agent 的开发者来说，真正的回报就在这些无聊的可靠性问题里。

过去几年已经有足够多的公开失败案例提醒我们。2025 年，一个 Hacker News 热帖讨论了 Replit Agent 被报告删除生产数据库的事件；Business Insider 后续报道中提到 Replit CEO 公开道歉。还有更多不那么戏剧化、却更常见的问题：Agent 提交低质量 PR、自动化流程写出自信但错误的客服回复、评测体系鼓励“刷榜技巧”而不是生产环境判断力。结论不是 Agent 没用，而是当可靠性系统很原始时，更强的 Agent 反而更危险。

如果 Agent 只能起草一封支持邮件，影响范围很小；如果它能改代码、发邮件、退款或修改客户数据，每增加一项能力，就需要同步增加一层控制面。

为什么能力演示会误导产品团队

Agent 演示会压缩现实。它选择干净环境、已知任务和顺利路径。模型拿到正好需要的工具，网页正常加载，用户提示很清楚。很少有人追问：API 返回过期数据怎么办？浏览器会话过期怎么办？模型选错客户记录怎么办？任务从 6 步变成 23 步怎么办？

生产环境里，错误会叠加。一个模型可能非常擅长单步推理，但在长流程里仍然不可靠。METR 关于长期任务完成能力的研究很有启发，因为它把注意力从孤立 benchmark 题目转向真实任务时长和完成率。Anthropic 的 Building Effective Agents 也强调了类似观点：很多强系统不是巨大的全自动循环，而是有明确工具边界、路由、评估和必要人工审核的工作流。

这会改变采用策略。创始人看完演示后可能会问：“为什么不让 Agent 跑完整续费流程？”运营负责人应该问：“哪一步可以自动验证？哪一步需要审批？如果 Agent 错了，恢复计划是什么？”只有第二组问题能经受客户环境考验。

如果你需要先理解 Agent 的基础能力边界，可以阅读我们的 AI Agent 实用指南。如果你关心运营监控，建议搭配阅读 可观测 Agent 运营漏斗。

公开失败通常是控制系统失败

Replit 数据库事件的价值在于，它很容易被误读。更负责任的理解不是“某个厂商不行”或“编码 Agent 都不安全”，而是：在把 Agent 指向生产资产之前，必须先有权限隔离、环境分离、备份和不可逆操作审批。一个拥有生产数据库权限的初级开发者也可能造成损失。差别在于 Agent 行动更快，可能静默误解，还能在事后给出看似合理的解释。

PR 自动化也是同样结构。Agent 打开一个 Pull Request 本身并不危险；但如果它批量打开噪音 PR、打扰维护者、声称修复了没有验证的问题，或把公开曝光当成目标，就会变成运营问题。围绕“AI 写了这个 PR”的公开讨论很容易演化成团队声誉风险，即使没人有恶意。社交媒体总结经常缺少上下文，所以要谨慎引用；但模式不能忽视：只要 Agent 能代表公司说话或行动，质量控制就是产品的一部分。

Benchmark 也会制造更隐蔽的问题。如果团队只为排行榜优化 Agent，它可能学会通过测试，却没有变得更值得信任。这并不意味着 benchmark 无用，而是 benchmark 胜利只能作为起点，不能作为上线许可。内部评测应包含模糊输入、缺失数据、工具失败、限流、权限边界，以及正确行为是停止的任务。

可靠性是产品界面，不只是工程细节

当 Agent 触达客户运营时，可靠性会被用户直接感知。一个支持 Agent 即使能即时回答 90% 工单，只要把账号取消流程处理错，用户也不会因为平均速度快而原谅它。一个销售运营 Agent 即使补全 1,000 条线索，只要污染 30 条 CRM 记录，清理成本就会吞掉收益。一个编码 Agent 即使节省两小时脚手架时间，但让评审多花一天看臃肿 diff，也不是胜利。

更实用的指标不是“自治程度”，而是“可信吞吐量”：有多少有用任务完成了，并且没有制造隐藏的下游工作。这个指标迫使团队同时衡量四件事：任务是否真正成功；输出被测试、schema、策略规则或人工审核覆盖的比例；失败后定位、回滚和恢复需要多久；一次错误动作的最大影响范围有多大。

对于构建浏览器或 API Agent 的技术团队，我们的 Operator 风格网页自动化指南 里的模式可以直接复用：执行前验证动作、为长流程做检查点、分类错误而不是盲目重试。对于把 Agent 接入内部系统的 SaaS 团队，MCP 集成策略 也很相关，因为工具边界经常比模型选择更重要。

可靠性优先的 Agent 采用清单

在给 Agent 更多工具之前，先缩小它的失败范围。我的清单故意保守。

从可逆工作开始。 草稿、摘要、分类、重复检测和内部研究适合作为早期任务。退款、删除、对外客户消息、权限变更和生产部署需要更严格的闸门。

使用受限凭证。 不要因为方便就让 Agent 继承管理员 token。为不同角色创建专用凭证，默认只读，增加按工具限流，并使用独立的 staging 或 sandbox 环境。

要求结构化输出。 自由文本很难验证。JSON schema、类型字段、确定性状态码和明确置信度，可以让错误结果在用户看到前被拦住。

加入停止条件。 可靠的 Agent 知道何时求助。低置信度、异常工具输出、缺失必填数据、重复重试、不可逆操作，都应触发暂停。

记录决策，而不只是错误。 你需要知道哪个 prompt、模型版本、工具响应和中间步骤导致了最终动作。静默失败和 prompt 回归只能靠这些线索调试。

运行对抗评测。 加入格式错误输入、模糊请求、过期文档、空搜索结果、权限错误，以及“什么都不做才正确”的任务。好的评测集应该让演示显得尴尬。

把人工升级设计成特性。 升级不是失败，而是可靠性机制。告诉人工：发生了什么、Agent 尝试过什么、置信度在哪里下降、现在需要做什么判断。

最好的 Agent 会比演示看起来更不“自治”

下一代 Agent 产品大概率会更强。模型会更会规划，工具调用会更顺手，记忆系统也会改进。但这不会消除可靠性工程，反而会提高风险。

我见过表现最好的团队，并不要求 Agent 英雄主义。他们缩小任务范围，监控每一步，验证输出，并在需要判断或责任归属时引入人。它们在发布视频里可能没那么神奇，却能扛住真实客户、混乱数据和周五下午的事故。

原始能力带来关注，可靠性赢得部署。如果你在 2026 年采用 Agent，请先为后者构建。