有一个数据足以让人们停止“增加一个聊天机器人”的条件反射：在很大一部分 AI 功能中，大多数打开聊天窗口的用户从未发送过一条消息。据报道，大约有 60% 的用户在发送第一条消息前就放弃了，而相比之下，当同样的能力被封装在带有示例和一键启动点的设计好的空白状态（empty state）中时，用户的参与度要高得多。模型并没有失败。答案从未生成，因为问题从未被提出。用户打开一个空白框，看着闪烁的光标，然后离开了。
我们选择聊天界面是因为它是阻力最小的路径，而不是因为它就是正确的界面。当语言模型可以进行对话的那一刻，“与 AI 交流”就变成了“使用 AI”的代名词，每个产品团队都继承了同样的默认设置：一个文本框，一个发送按钮，以及一个模型会搞定剩下一切的承诺。对于大多数智能体（agent）实际承担的工作来说，这种默认设置其实是错误的。
聊天是一个不错的 输入原语 (input primitive)。但它是一个糟糕的 操作环境。这是两个不同的概念，将它们混为一谈会导致你在需要控制面板的地方只交付了一个闪烁的光标。
只要翻开任何足够长的生产环境对话记录，你都会发现有用户会将同一个问题问上三遍。每一轮的措辞都会稍微改变——代词换成了名词，加上了限定词，到第三次尝试时，那些客气的委婉话也消失了——但底层的请求是完全相同的。他们不是在问三个问题。他们是在问同一个问题，而智能体没能给出答案，用户希望这一次表达的方式能产生不同的效果。
这里的对话记录级信号是如此响亮，以至于近乎显而易见。用户已经通过他们的键盘敲击告诉你，之前的回答没有帮助。他们不需要填写调查问卷，不需要点踩。他们通过再次输入问题直接告诉了你。而在大多数生产环境的 AI 技术栈中，这个信号被评估流水线默默丢弃了，因为这些流水线孤立地对每一轮对话评分，而满意度调查仅在会话结束时触发——到那时，那些重复提问三次的用户通常已经流失，永远不会进行任何评分。
行动前先询问的 AI 系统显然更可靠。它们能避免不可逆的错误，在误解扩散前将其暴露出来，并在第一次真正的尝试中生成更高质量的输出。
问题在于，这一原则的大多数实现都是 UX（用户体验）的灾难。它们不是问一个好问题，而是问三个平庸的问题。那些本只需要澄清十个词指令的用户，最终陷入了五轮审讯式的对话，这比直接做错任务然后再修正还要耗时。可靠性带来的优势消失殆尽，取而代之的是用户的放弃。
这是一个设计问题，而不是模型能力问题。模型完全有能力提出精准、高价值的问题。缺失的是一种强制收敛的架构约束：一种将多轮澄清视为需要通过工程手段解决的故障模式（Failure Mode），而不是一种可以依赖的特性的规则。
打开任何智能体 (Agent) 的用户反馈渠道，你都会发现两类抱怨，它们声音宏大、普遍存在，且都被归咎于模型。第一种听起来像是：“它在干活前问的问题太多了。”第二种听起来像是：“它不跟我确认就自顾自地跑去乱做一气。”产品团队将这两者视为截然相反的问题，并发布了相反的修复方案——收紧系统提示词以减少提问，然后在下一季度因另一种抱怨声变大而再次放开。这两种改变都无法长久奏效，因为这两类抱怨的核心并不在于提问或行动本身，而在于用户默默选定了一份契约，而智能体未能履行。
与智能体的每一次对话都运行在两种隐性模式之一中。访谈模式 (Interview mode) 是一种契约，用户期望智能体在采取任何实质性行动之前先提取需求——澄清性提问是受欢迎的，过早执行则是失败。任务模式 (Task mode) 则是另一种契约，用户已经完成了思考，心中已有具体计划，并期望智能体根据现有上下文直接执行，仅在真正受阻时才提问——提问是阻力，半生不熟的执行则是失败。
用户不会宣布他们处于哪种模式。他们期望智能体能从消息、对话历史和情境中读懂模式，并在智能体搞错时给予严厉的抨击。针对“问题太多”和“问得不够”的修复方案是同一个：将“模式”作为一个一等公民的概念引入你的智能体，从你可以实际观察到的信号中检测它，并 在不确定时向用户明示。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
