面试模式与任务模式：你的智能体不断打破的无形契约

打开任何智能体 (Agent) 的用户反馈渠道，你都会发现两类抱怨，它们声音宏大、普遍存在，且都被归咎于模型。第一种听起来像是：“它在干活前问的问题太多了。”第二种听起来像是：“它不跟我确认就自顾自地跑去乱做一气。”产品团队将这两者视为截然相反的问题，并发布了相反的修复方案——收紧系统提示词以减少提问，然后在下一季度因另一种抱怨声变大而再次放开。这两种改变都无法长久奏效，因为这两类抱怨的核心并不在于提问或行动本身，而在于用户默默选定了一份契约，而智能体未能履行。

与智能体的每一次对话都运行在两种隐性模式之一中。访谈模式 (Interview mode) 是一种契约，用户期望智能体在采取任何实质性行动之前先提取需求——澄清性提问是受欢迎的，过早执行则是失败。任务模式 (Task mode) 则是另一种契约，用户已经完成了思考，心中已有具体计划，并期望智能体根据现有上下文直接执行，仅在真正受阻时才提问——提问是阻力，半生不熟的执行则是失败。

用户不会宣布他们处于哪种模式。他们期望智能体能从消息、对话历史和情境中读懂模式，并在智能体搞错时给予严厉的抨击。针对“问题太多”和“问得不够”的修复方案是同一个：将“模式”作为一个一等公民的概念引入你的智能体，从你可以实际观察到的信号中检测它，并在不确定时向用户明示。

用户脑中已有的两种模式

观察一些真实用户开启编程智能体或研究助手的会话。访谈模式的用户会输入类似“帮我做一个追踪阅读清单的东西”的内容，然后靠在椅背上。他们有一个模糊的目标，没有架构设计，并期望智能体像体贴的协作伙伴一样引导他们：询问数据、交互界面、约束条件，然后提出方案。如果智能体立即搭建了 Postgres 模式和 React 应用，用户会感到被冒犯，而不是惊艳。

在同一个产品中，任务模式的用户会输入“在阅读清单模型中添加 priority 字段，并将现有行迁移为 medium”。他们已经做好了决定。他们想要的是执行。如果智能体回复说：“你想要哪些优先级级别？Low/medium/high 还是数字？迁移过程中是否允许 null 值？你想添加索引吗？”，用户会认为智能体在磨蹭。他们写下了具体的指令；智能体的工作是行动，而不是主持需求研讨会。

行业研究在大规模范围内证实了这一点。一项常被引用的客户服务研究发现，55% 的用户反感聊天机器人询问重复性问题，“机器人不停地问同样的问题”几乎出现在每个聊天机器人失败清单的首位。与之相对的抱怨——“它没问就自顾自猜了，结果还猜错了”——在智能体编程的事后分析中同样频繁出现，团队发现他们的智能体根据对模糊提示词的第一种合理解释就发布了功能。这两者都是真实的失败模式。它们只是发生在不同的用户身上。

开发者的陷阱在于这两种模式看起来像是性格特征。“我们的智能体太爱管闲事了。”“我们的智能体太自负了。”因此，团队倾向于调整性格旋钮——在系统提示词中加入一句话，引导模型多问或少问。这能缓解一类人群的问题，却毁了另一类人群的体验。实际的变量不是性格，而是用户进来时期望的是哪种契约。

驱动模式选择的信号

如果模式是一种契约，那么模式检测就是一个分类器——就像任何分类器一样，当你刻意选择特征而不是寄希望于大语言模型 (LLM) 自己领悟时，它的效果最好。有几种信号可以很好地区分访谈契约和任务契约，而且这些信号是你已经拥有的：

• 名词的具体性。 “一个追踪我阅读的东西”是访谈模式的语言。“ReadingList 模型”是任务模式的语言。具体的标识符——文件路径、函数名、工单 ID、表名——与已有计划的用户强相关。
• 意图动词。 “帮我搞清楚”、“我正在考虑”、“我该如何”是商讨性动词。“添加”、“重命名”、“部署”、“修复”是执行性动词。单条消息中动词的组合是最清晰的信号之一。
• 提示词中的约束。 包含验收标准、目标系统或“不得”条款的消息几乎总是任务模式。没有任何约束的消息通常是访谈模式。
• 对话位置。 会话的第一条消息偏向访谈模式（用户正在引入目标）。紧跟在计划或澄清回答之后的回复则极度倾向任务模式（用户此时已经选定了路径）。
• 消息长度和结构。 带有代码块且分三行排列的需求是任务模式。单句的开放式问题是访谈模式。用户已经完成了排版工作，这本身就是一种立场信号。
• 粘贴的 Artifacts。 粘贴的错误、日志、回溯轨迹 (traceback) 或差异对比 (diff) 是近乎确定的任务模式信号。用户不是在问“是否”要做某事；他们希望在处理这些 Artifacts 时获得执行层面的帮助。

这些信号没有一个是完美的，你也不需要它们完美。重点是智能体的模式分类器应该基于真实信号运行——其中许多信号是廉价且确定性的——而不是隐式地委派给模型在本轮对话中的随兴发挥。关于意图模糊性的文献（包括最近关于置信度阈值澄清的研究）观点一致：将低置信度的输入路由到澄清路径，将高置信度的输入路由到行动。大多数智能体的 Bug 在于它们根本没有设定阈值。

一个合理的初始策略：如果分类器的任务模式置信度高于高阈值（例如 0.8），则执行。如果低于低阈值（例如 0.4），则以一个针对性强的澄清问题开头。如果落在灰色地带，则向用户明确指出模糊之处，而不是胡乱猜测。

模式切换的 UX

识别只是工作的一半。另一半是向用户展示你认为自己处于哪种契约中，这样当你有误时，他们可以以极低的成本纠正你。

最成功的模式是编程智能体已经趋于一致的做法：一个可见的计划模式 (plan mode)，它与执行界面不同。当 Cursor 或 Claude Code 进入计划模式时，智能体可以询问、提议和修改——但不能触碰文件。用户可以在 UI 中看到契约的体现：一份可以编辑的 Markdown 计划、执行任何操作前的确认步骤、以及明确移交给“开始执行”的过程。计划本身成为了访谈的产物，而进入任务模式的转变是一个离散的、经用户确认的事件。这就是将“模式即契约”可视化。

你不需要一个专门的模式切换开关也能获得这种好处。同样的想法在行内也适用：

• 以模式开头。 智能体的第一句话应该让契约显而易见。“在起草任何内容之前，我会先问三个简短的问题” 或者 “我会直接添加带有合理默认值的字段——如果你想覆盖，请告诉我” 都能告诉用户你选择了哪种契约。如果你选错了，他们在这一轮就能推翻，而不是等到十轮之后。
• 提供一行的逃生口。 每当你做出猜测时，给用户一个低成本的退出路径：“……或者如果你更愿意直接指定优先级，粘贴它们，我会跳过这些问题。” 这就是聊天界面中模式协商 UX 的样子：让在对话中途更换契约变得毫无成本。
• 明确告知模式转变。 当用户发起转换（“好，就用低/中/高，发布吧”）时，智能体应该标记这一转变——“正在切换到执行模式；我现在就添加该字段。” 沉默的转换会让智能体停留在模式之间的尴尬地带，在用户已经批准操作后还在问问题。
• 将计划作为契约产物。 在执行之前展示一份简短的要点计划，让用户能在几秒钟内审核智能体的理解。如果错了，他们修改的是计划，而不是智能体的个性。计划模式之所以奏效，是因为计划是外部化的契约——它是可审查、可版本化且可引导的，而不像“氛围感 (vibe)”那样模糊。

注意这些模式的共同点：它们让契约变得可观察。模式不匹配之所以让人感觉糟糕，最大的原因在于用户在出错之前看不到智能体的立场。公开立场比让立场变得完全正确要容易得多。

当模式协商看起来像是个性问题时

一旦你开始留意这一点，你会发现惊人数量的“智能体太 X 了”的抱怨，其实是披着个性外衣的模式协商失败。以下是几种通常会引发误诊的模式：

• “它每次都问同样的事情” 通常意味着智能体无视消息的具体程度，每次会话都以访谈模式开启。修复方法是基于信号的模式检测，而不是在 prompt 中加入“少问问题”的指令——后者会把下一个用户的体验推向另一个极端。
• “它擅自做假设而不是询问” 通常意味着智能体处于任务模式，而用户期望的是访谈模式。修复方法是提高执行的置信度阈值，并提供一个让用户在行动前审核的行内计划。
• “它让人觉得优柔寡断” 通常意味着智能体在摇摆——询问，然后半执行，接着再询问——因为模式在逐轮重新评估且没有承诺。修复方法是在边界处选定一种模式，并保持在该模式中，直到用户明确协商转换。
• “它解释过多” 通常意味着智能体处于访谈模式，并将解释视为需求采集的一部分。在任务模式下，同一个智能体应该减少叙述，多采取行动，并报告它做了什么。

将这些诊断为个性问题会让团队陷入死胡同：调整语气、设定人设 Prompt、或者加入“更简洁一点”的指令。这些都无法解决根本问题，即智能体从未决定它是在哪种契约下运行的。

需要监控的指标

大多数智能体观测面板都会衡量满意度、延迟和工具调用成功率。几乎没有人衡量模式不匹配，这就是为什么模式协商的 bug 会隐蔽地存在好几个季度。以下是一些值得添加的指标：

• 模式纠正轮数。 统计用户明确重定向智能体立场的轮数（如*“直接做”、“等等，先问我”、“先别写代码”*）。高频率直接指向了分类错误的模式检测器。
• 首次行动时间 (Time-to-first-action)。 开场消息与第一个具体行动之间的长时间延迟通常与访谈模式相关。如果被分类为任务模式的会话出现长时间延迟，说明你检测失误，正在审讯那些想要直接执行的用户。
• 计划编辑率。 当用户在批准前频繁编辑计划时，说明访谈不完整或智能体的理解有偏差。当用户未经编辑就批准计划，随后又对结果表示不满时，说明计划太模糊，无法作为真正的契约。
• 会话内模式翻转率。 在没有明确用户信号的情况下中途翻转模式的智能体正在发生震荡——需要调查分类器不稳定的原因。

追踪这些数字能将“用户抱怨个性”转变为可调试的信号。你可以针对可衡量的模式不匹配率，对阈值、Prompt 表述和 UI 交互进行 A/B 测试，而不是仅凭感觉。

模式是契约，而非性格

能带来回报的思维转变是将模式视为智能体与用户协商的结果，而不是模型所体现的某种特质。一个设计良好的智能体既不爱管闲事，也不自大；它处于访谈模式或任务模式，具有明显的立场和低成本的切换路径。投诉将不再集中于智能体“是什么”，而开始转向契约是否正确——这才是你真正能够解决的问题。

下一个 Sprint 的两个实用建议。首先，写下你智能体的每个交互界面应该默认遵守哪种契约（例如，单次补全端点默认是任务模式；长期的规划会话默认是访谈模式），并审计你的提示词和 UI 是否真正反映了这一点。其次，在本周对模式修正交互进行埋点统计。这个数字几乎总是比团队预想的要高，一旦你看到了它，那些“性格调节按钮”就不再那么有吸引力了——而真正的解决方案，即把模式作为一等公民契约，就会变得显而易见。