观察一名开发者使用 Agentic 编程工具一小时，你会看到同一个动作重复四十次：弹窗出现，“允许 Agent 运行 git status 吗？”，手在眼睛读完之前就移到了批准按钮上。到第四十次提示时，提示内容根本没被阅读。它变成了一个用户学会全速通过的减速带。
这是“人机回环”（human-in-the-loop）的一种无声失败。架构图上仍然显示人类在把控每一个危险动作。审计日志仍然记录着对每个命令的明确批准。但人类已经停止了评估。他们变成了一个接入控制流的生物版 “yes” 函数 —— 虽然身在回路中，却不贡献任何判断。权限提示本应是一项安全控制，它却退化成了附带确认对话框的系统延迟。
一个故障率高达 70% 的功能是无害的。用户在一周内就会发现他们必须验证每一条输出，将系统视为一个不可靠的助手，并做出相应调整。而一个成功率达到 70% 的功能则更糟糕。它正确的频率足以让用户停止验证，而错误的频率又足以让失败变得集中、显眼且具有针对性。用户的心理模型会崩塌为“我不知道什么时候该信任它” —— 这种产品体验从根本上比“我知道不要信任它”更糟糕。
这就是 70% 的恐怖谷，也是过去两年中构建的大多数 AI 功能所处的位置。团队衡量综合准确率，看着数值超过某个“足够好”的阈值，然后发布。实际的用户体验并不随着这个数字单调提升。在大约 60% 到 85% 的准确率之间，产品随着准确率的提高反而变得更差，因为用户因疏于检查而导致的错误成本，超过了他们无需验证正确答案所带来的价值。
那些在不考虑可预测性问题的情况下发布 70% 准确率产品的团队，发布的并不是一个 95% 产品的拙劣版本。他们发布的是一个完全不同的产品：一个主要的失效模式是隐形的产品。
大多数团队构建的环境 AI，用户上线就关。
这个模式高度一致：团队内部演示功能，所有人都认为理论上有用，但上线两周内禁用率就超过 60%。这不是模型质量问题，而是架构问题——更具体地说，是打扰阈值问题。团队在设计环境智能体时，考虑的是 AI 能做什么，而不是用户在没有主动求助时能忍受什么。
从显式调用（"问 AI"）到环境监控（"AI 观察并行动"）之间的鸿沟，不只是 UX 问题。它需要从根本上不同的系统架构、不同的事件模型，以及关于 AI 智能体何时才算赢得发言权的不同心智模型。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
