Yutori Scouts：把“没有新消息”也做成一次交付

Yutori Scouts 是一类“常驻在网页上”的 AI 产品。用户用自然语言写下要关注的主题、条件和来源，Scout 可以只执行一次，也可以按计划反复运行；结果可以进入邮件摘要、webhook 或实时看板。产品面向的场景很具体：产品经理盯竞品动态，研究人员等新论文，业务团队追踪线索，Scout 接过反复打开同一批网页的动作。1

这类产品面对的是另一个难题：用户把任务交出去几天后，怎样知道 Scout 仍在按原来的条件工作，怎样区分“确实没有新情况”与“任务没有跑完”。Yutori Scouts 的两处设计，正好把这两个判断变成了产品界面的一部分。

聊天式 AI 的默认对象是一轮提问：用户输入问题，系统返回答案，任务随对话结束。Yutori Scouts 把对象换成了一个持续运行的 Scout。用户要描述的内容包括关注什么、哪些变化值得送达、任务跑一次还是周期执行，以及结果进入哪里。官网把自然语言配置、一次性或周期性排程、邮件摘要、webhook 和实时看板并列呈现，说明这些选项共同组成一份长期任务。1

这个顺序改变了用户的注意力。一次性提问要求用户在当下判断“我想知道什么”；持续委托要求用户先定义“未来哪些变化值得打断我”。例如，产品团队可以把任务写成“跟踪指定竞品的定价页与发布页，只在出现新套餐、试用规则变化或明确发布时间时提醒”。这份任务的核心是一条可重复执行的筛选规则，摘要只是某次运行的呈现。

自然语言在这里用来配置任务。用户可以先用日常语言写出条件，再通过运行频率与送达渠道决定任务怎样融入工作流。任务页面随后会持续产出结果，团队成员还可以查看、订阅 Scout 的发现与产物。1

这种设计有一个明确边界：用户必须能说清“什么算值得提醒”。“帮我关注 AI 行业”会让结果标准漂移；“关注三家公司的产品更新，只保留公开定价、功能发布和 API 变更”则能被用户复核。持续型 AI 产品把模糊愿望变成长期任务时，首要工作是帮助用户写出可判断的命中条件。

持续监测最容易出现的体验问题，是安静的收件箱含义太多。网页确实没有变化、筛选条件过窄、Scout 执行遇到问题、通知没有送达，用户看到的表面状态都一样。用户于是只能手动回到原始网页检查，或者干脆失去对自动化的信任。

Yutori 在一个公开 Scout 的更新页面里，除了展示发现到的更新，还连续显示“过去若干次运行没有发现重要内容”的记录。页面同时给出每段时间和生成报告的智能体数量。空结果以可见的交付形式出现：系统告诉用户，任务在这段时间已经按条件执行过，结论是当前没有足够重要的新内容。2

这处细节看起来朴素，解决的却是异步产品最容易被忽略的问题。用户收到一条“本次没有重要发现”的回执后，可以把精力留给下一项工作；用户看到连续的空结果后，也能回头检查筛选条件是不是写得过紧。发现与空结果因此形成一组完整的状态，两种状态都进入用户的视野。

空结果只能说明本次任务已经运行且未命中重要内容。来源覆盖范围、网页访问失败、条件写法和通知链路仍然需要产品分别展示或告警。Yutori 的处理值得借鉴之处在于，它把“本次跑过了，结果为空”从系统内部状态带到用户面前，给后续的判断留出一个明确起点。

Yutori Scouts 的启发来自它对持续型任务的拆分：一类是用户关心的新发现，另一类是任务已经执行且暂未命中的状态。前者帮助用户采取行动，后者帮助用户决定是否继续信任这份委托。

设计一个异步 AI 功能时，可以先检查三个位置：用户是否能写清触发条件，系统是否能让用户选定结果的送达方式，空结果是否会以可理解的形式出现。三个位置都被照顾到，自动化才会从一次性答案变成能长期留在工作流里的助手。