LookOut:一个会等、会问的AI助理

论文解读 · 人机分工 · HCI侧

AI 生成的原创概念插画

你打开一封邮件，里面写着“下周见一面”。助理立即弹出来问是否安排会议。你还没看完，第二个窗口已经打开。它确实发现了一个可能有用的动作，只是把你的阅读时间也一起征用了。

这类问题并不是大语言模型出现以后才有。1999年，Eric Horvitz 在 CHI 发表 Principles of Mixed-Initiative User Interfaces，用一个名为 LookOut 的日程助理讨论：系统如何在不确定用户意图的情况下，决定等待、询问或行动。

今天读它，仍能遇到熟悉的产品难题。自动化知道得不够多，却又不能每一步都让人从头操作；一味多问，也会让用户忙着管理助理。论文试着把这些成本放到同一个设计框架里。

论文信息｜约12至16分钟阅读Principles of Mixed-Initiative User InterfacesEric Horvitz。CHI 1999，159至166页，DOI：10.1145/302979.303030。本文解读设计原则、LookOut 原型及其服务时机探索。它是一篇系统与框架论文，不是验证全部原则的大规模对照实验。

人直接操作，机器也可以主动帮忙

当时关于界面代理的一项争论，是研究应该更多投入自动化，还是继续改善人直接操控界面的能力。Horvitz 把问题转向两者如何组合：自动服务可以先做一部分，人仍能查看、修正和完成结果。

这种安排称为 mixed initiative，通常译作混合主动权。它意味着任务推进的发起者可以变化，也要求系统为这种变化留出顺畅的操作方式。

如果机器只能整件事包办，人只能在最初下指令、最后检查，合作空间就很小。相反，当系统能提供一个尚未完成但容易理解的中间结果，用户可以根据自己的知识接着做，双方便不必每次都重新开始。

这也给研究划出了一条实际标准：自动化到底省下了什么？若机器只是把一个本来很清楚的按钮藏起来，再用复杂推理猜测用户是否想点它，智能可能反而增加了负担。

LookOut 处理的是正在读的那封邮件

LookOut 建在 Outlook 的邮件与日程功能之上。它关注新打开或获得焦点的邮件，分析标题、正文等内容，估计用户是否想查看日历或创建约会。

当系统被调用，会进一步解析与会议相关的日期和时间，打开合适的日历位置，并尝试填写约会字段。猜测会留给用户查看、编辑与最终保存。

相对时间需要有参照。昨天写来的邮件说“明天”，今天打开时，指的就可能是今天。论文中的系统会先识别邮件发送日期，将这类表达转换到合适的时间位置。它处理的是特定任务中的时间表达，没有宣称能够理解任意邮件的全部含义。

如果邮件只说“下周”，LookOut 可以展示周视图。确定一个周，却还不知道某天几点，就先做到周这一层。这项选择看起来很小，却让“不够确定”不再只对应完全不做或胡乱补齐两种结果。

把错误的代价，也放进决定里

系统先要估计一个概率：用户现在是否有查看日程或安排会议的目标。论文的实现使用线性 SVM 文本分类，初始训练约有1,000封邮件，相关和不相关各约500封。

这个概率本身还不是行动规则。假设模型认为你有八成可能需要日历，如果打开视图很容易关闭，它可能值得主动帮忙；如果动作会对外发出邀请，猜错的成本就明显不同。后一个情形是今天产品设计的延伸，不能说成 LookOut 当时已经测过的功能。

论文将行动与不行动分别放在“用户确实有这个目标”和“没有这个目标”两种状态下，得到四种结果。每一种都有不同效用，再用目标概率加权比较。

这样，阈值便有了可解释的来源。系统不该因为某个工程团队习惯把0.8设成阈值，就永远在0.8以上行动。打扰成本、帮助收益和漏掉帮助的损失变化后，合理阈值也会变化。

问一句，也会占用人的时间

在行动与不行动之间，论文加入了询问。询问可以减少对目标的猜测，但也会打断用户，要求他阅读、判断和回答。

在一种合理的效用设置下，系统可以形成三个区域：目标可能性低时保持安静，处在中间时询问，较高时提供帮助。但这不是适用于全部产品的固定三档规则，边界来自所假设的成本与收益。

可以用一个示意算例说明。假设做对一次获得10个单位收益，做错损失20个单位，不做的收益暂记为0，那么直接行动的预期收益为10p－20(1－p)，只有 p 大于三分之二才为正。若做错仅损失2个单位，阈值就下降到六分之一。这里的数字是解释性例子，并非论文实验参数。

加入询问以后，还需要考虑询问能解决多少不确定性、答案是否容易给出，以及提问本身的成本。产品里常见的“你确定吗”如果没有提供新信息，可能只增加一次点击，并没有解决系统真正不知道的问题。

用户应该能叫它来，也能让它走

LookOut 保留了手动调用入口。即使系统没有猜到用户需要帮助，人也可以点击图标主动调用，而不必尝试用某种措辞“诱导”系统触发。

在一种提示模式下，系统只在托盘图标上显示标记，表示它认为此时可能值得采取行动。悬停可以查看预期动作，点击后才真正调用。自动判断先变成一个可检查的建议，用户再决定是否采用。

原型也探索了具有动画形象与语音交互的模式。用户拒绝、关闭邮件或没有继续响应时，助理会退出；系统还尝试依据语音中的迟疑调整等待时间。这里体现的是当时的设计探索，不能把拟人化外观本身当成更礼貌或更有效的证据。

值得保留的是调用和终止都很直接。一个助理如果只擅长主动出现，却需要用户连续解释三遍才能退出，交互成本便已经偏向了机器。

帮忙做到什么程度，可以随把握改变

LookOut 的周视图例子展示了“精度降级”：系统知道一些信息，就先提供相应粒度的帮助，把未知部分留出来。

对于用户，这通常比看见一个表面完整、实际上藏着猜测的结果更容易接手。空着的时间字段会提醒人继续决定；一个未经证据支持的具体时刻，却可能在视觉上与确定信息毫无区别。

当然，中间结果也要足够有用。如果系统只是打开另一个空白窗口，并没有省掉寻找日期或整理内容的步骤，仍然未必值得介入。论文强调自动化应带来实质帮助，部分完成不是降低要求的借口。

放到今天的 Agent 工作流，可以据此考虑保留草稿、候选列表或尚未执行的计划，让人修正后继续。这属于从原型出发的设计延伸，仍需要根据具体任务衡量是否减少了工作。

什么时候出现，与出现什么同样重要

论文对服务时机做了探索：记录用户阅读邮件到手动调用日程服务之间的时间，观察它与邮件长度的关系。

作者报告，这种关系可以用 S 形曲线近似，并展示了一名用户的样本数据。原文称数据来自若干用户，但没有提供足以让读者重新评价完整实验设计的详尽人数、样本规模和对照分析。因而适合把它视为原型设计线索，而不是“等待几秒最好”的普遍结论。

系统可以使用预设时机模型，也可以根据用户自己的操作记录学习，或者让人设定固定延迟。这里至少说明，服务是否相关与服务是否来得及时，需要分开处理。

一封长邮件可能要求更久阅读，但文字长度也不是注意力的全部。复杂度、歧义、当前任务及中途打断都可能影响接收帮助的时刻。论文已提到继续研究这些因素，今天重做系统仍需要检查这些条件。

学习人的行为，也可能学到错误解释

LookOut 会观察用户是否在一定时间范围内调用日程功能，把相应邮件记录为与日程相关，再据此改进模型。它也记录用户阅读多久才调用，以调整服务时机。

这种做法让系统可以在使用中学习，却依赖一个解释：发生在附近的动作，与当前邮件有关。现实里，人可能看完这封信后想起另一件事，或者暂时不处理，却并不意味着不相关。这个潜在歧义是从论文机制推出来的部署问题，不是原文已经报告的错误率。

学习因此需要有可观察、可纠正的范围。用户应该能理解系统正在适应什么；开发者也需要区分兴趣变化、分类错误和任务暂缓。记录更多日志，不会自动得到更准确的意图解释。

与此相邻的是隐私问题。阅读邮件内容来推断目标，需要明确数据处理范围和权限。原论文的核心贡献并不是现代隐私治理方案，部署今天的产品时需要补上相应设计。

与“学会互补”的 AI 论文放在一起读

本组另一篇文章解读 IJCAI 2020 的 Learning to Complement Humans。那篇研究让预测模型和请人协助的策略联合训练，以提升团队表现；LookOut 则集中讨论用户实际遇到机器帮助时，控制权怎样流动。

两者共同关心行动的价值，但研究证据不同。互补学习使用带有人类历史判断的数据评估训练方法；LookOut 提出原则并展示原型，有服务时机的初步观察。不能把它们当作同一个系统在两项实验里的前后成绩。

对做产品的人，组合起来更容易形成可检验的问题：模型为什么挑这一步找人，找人的时机是否合适，人接手时有足够线索吗，修正后的工作能否继续。前一个问题常出现在算法日志里，后几个往往要进入实际工作流程才能看见。

微软保存的原论文可公开阅读全文，包含界面示例、效用图和时机模型。本文未确认一个可直接运行的 LookOut 原版公开代码包；重新实现时应报告自己的模型、界面与成本设置，避免把旧原型的描述当成已复现的性能。

LookOut 留下的那份日程可以很具体，也可以只到一张周视图。用户能看见它已经完成什么，尚未确定的时间仍然空着，接下来可以直接动手补上。这样的中间结果，值得在今天的自动化演示里多停留一会儿。

CHI 1999 正式出版记录^[1]

Microsoft Research 保存的 LookOut 论文全文^[2]

配套AI论文：Learning to Complement Humans^[3]

作者：Seminar of HCI。资料核对：2026年10月22日。