无法说出"等一下"的智能体

随便挑一个过去两年里搭建的生产级智能体,清点它在某一轮里实际能做的事。清单很短:发起一次工具调用、给出最终答案,或向用户提一个澄清问题。这就是整个动作词汇表。注意一下缺了什么。没有动词表达"我想在决定之前多花点时间";没有动词表达"我足够不确定,所以希望暂停并重新考虑,而不立刻承诺";没有动词表达"我想在采取任何行动之前先在这件事上多停留一会儿"。智能体在字面意义上无法说出"等一下"。语法里压根没有这个词。

这并不是表面打磨的问题,而是结构性的问题。一旦智能体的全部输出都是动作,任何内部状态都必须经由一个动作来表达。犹豫变成多余的工具调用,怀疑变成自信的承诺。只设计了动作动词的团队,实际上发布了一个唯一的语言就是"做事"的智能体——然后又奇怪它怎么从来不像在思考。

言语行为的缺口

言语行为理论里有个有用的区分。一句话拥有施事力(illocutionary force)——说话者用它想做什么——以及话语形式(locutionary form)——这些词在表面上的模样。人类有一套丰富的、用于非动作状态的施事词汇:对冲、推迟、请求时间、表达不适、登记反对意见而不立刻据此行动。绝大多数人类审议都发生在这些言语行为之中,远在任何外部可观察的行动之前。

再看智能体协议。它能表达的施事力被框架提供的话语形式所限制。有 call_tool(name, args),有 return(final_answer),运气好的话还有 ask_user(question)。粗略地说,这就是三种施事力:承诺去做、承诺给出答案、请求信息。人类风格里"我想把判断再悬置一轮"这一空间没有任何可表达的形式。智能体拥有那个认知状态,却没有那个动词。

后果是,内部的犹豫被挤压进最接近的可用动词。如果模型不确定是否要行动,它没法说"让我等一轮",于是只能退而求其次,走协议允许的下一步:调用一个其实并不需要的工具,借这个工具的延迟为思考腾出一点时间;或者以高出实际把握的语气返回一个最终答案,因为相比"调一个多余的工具"来说,"承诺"反而显得更体面。是动作词汇塑造了认知,而非反过来。

为什么 "ask_user" 不够

团队意识到这个缺口时,标准做法是再加一个澄清类的工具。ask_user、request_more_context、defer_decision。这些有帮助,但属于在错误的层上做的半截修补。它们和 read_file、send_email 一同住在动作词汇表里。智能体必须下决心去调用它们——而当犹豫一旦被表达成工具调用,它就已经从内部状态被提升为外部动作,连带承担了所有后果。

当"我不确定"必须以工具调用的形式表达时,有三件事会出问题。

第一,智能体不愿意使用它的原因和不愿意做任何工具调用一样:工具有 token 与延迟的成本,被良好指令训练过的模型被鼓励选择通向目标的最短路径。请求澄清很少是最短路径,尤其当提示词把任务框定为"要被完成的事情"时。本应暂停的模型反而做出承诺,因为承诺更便宜。

第二,当智能体真的去调 ask_user 时,交互界面会把它当成一个有后果的动作——用户必须回应、必须消耗一个回合、必须触发一次通知。这种分量对真正的阻塞器是合适的,但对低强度的不确定性来说就过重了。把握 70% 的智能体,没有任何协议级的方式去表达"我有 70% 的把握",它只能要么 100% 地行动,要么 0% 地升级。中间那段空间是不可达的。

第三,ask_user 只允许智能体问用户,不允许智能体问自己。没有一个第一人称的原语——例如 let_me_think_about_this——能被框架识别为有别于"什么都不做"和"行动"的合法状态。想要停留下来的智能体要么调用工具,要么返回一个对冲过的答案;它无法仅仅"存在"。

这种偏置在生产中如何显现

观察一个本来胜任的智能体如何在需要耐心的任务上失败。失败模式并不随机。

智能体常常会去调用一个其实根本不需要的只读工具。它会列出已经列过一次的目录、重新抓取已经读过的 URL、再 dump 一次早已缓存的 schema。这不是错误。这是模型在用唯一可用的渠道表达"我想再多一轮思考"——一次良性的工具调用,为它换来又一段对话步骤,而无须做出承诺。你能从轨迹中看到这种模式:一片不产生任何新信息的工具调用平地,接着才是一个决定。那些多余的调用就是审议,只是因为没处安放,只好以动作的形式被外化出来。

加载中…