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