柳溪动物诊所只有一位兽医，一天大部分时间都在做手术，前台则忙于接待。他们的 AI 智能体 前台 负责接答网页聊天和电话。当普莉娅写下 「能请埃利斯医生就贝拉的用药问题给我回个电话吗？」 时，诊所想马上 就知道这件事 —— 趁普莉娅还留在网站上、还没转去打给另一家诊所的时候，而 不是等聊天结束半个小时之后。
这正是 Live 的用武之地。它一次只能开在一个 对话洞察 的是 / 否字段上。此后，智能体会在对话进行中就把请求标记出来，挂在那个字段 标签上的提醒工作流会在几秒之内运行。你没有打开的字段一切照旧，完全不受 影响。
它背后的是 / 否字段
对话洞察是一份简短的问题清单，AI 会就每一段对话回答这些问题。每个问题是 一个字段，每个字段有一个类型：是 / 否、枚举（从你自己写的 一组取值里选一个）、文本 或 数字。
一个是 / 否字段只问一个问题，答案只有两种。柳溪动物诊所的对话洞察 前台跟进 里有一个叫 要求回电 的字段，它的提取说明写明了什么时候 答案是「是」：客户请兽医或诊所给他们回电。
开启输出为标签后，答案就会变成对话上的一个标签：
| 字段类型 | 开启「输出为标签」后，对话会得到 |
|---|---|
| 是 / 否 | 答案为「是」时，得到字段名 要求回电；答案为「否」时，什么都没有 |
| 枚举 | AI 选中的那个取值，比如 紧急 |
| 文本、数字 | 永远不会产生标签 |
工作流监听的正是标签。一封邮件提醒就是一个工作流：某个标签被加到一段对话 上时它被触发，所以说，真正把邮件发出去的是标签。
一个标签，多个请求
标签在一段对话上要么有、要么没有。对「这次是不是关于疫苗接种？」这样的 问题，这没有问题：一旦成立就一直成立。对请求来说这样行不通，因为客户可能 开口不止一次：
- 不开 Live 时，分析第一次答「是」，标签就挂上去了。一小时后普莉娅 再问一次，标签已经在了，什么都不会新增，提醒也不会再跑。
- 开了 Live 时，智能体每标记这个请求一次，标签下就会多出一个带编号的 请求：「Request 1」、「Request 2」。只要还有请求没处理，标签 就留在对话上；最后一个被标记为已处理后，标签才取下来。每个新请求都可以 再触发一次提醒。
这就是为什么只有是 / 否字段能设为 Live：「是」代表客户做了一件事，下一个 「是」就是一个新请求。枚举取值描述的是对话本身，没有东西可数。 「During the conversation」 区块只列会产生标签的是 / 否字段。当一份 对话洞察一个这样的字段都没有时，它会显示 「前台跟进 has no yes/no fields that produce a label, so nothing can be Live yet.」
字段设为 Live 之后，什么会变
当 要求回电 在输出标签、那个标签上又挂着一个邮件提醒时：
| 未开 Live | 开了 Live | |
|---|---|---|
| 提醒什么时候到 | 对话洞察运行时，也就是对话结束之后 | 客户开口后几秒之内，趁人还在的时候 |
| 同一段对话里，客户稍后又问了一次 | 没有动静：标签已经挂上了 | 一个新请求，一封新提醒 |
| 谁来发现它 | 对话结束后的那次检查 | 智能体，在客户开口的那一刻。如果它漏了，对话结束后的检查仍然会发现，提醒那时照发 |
Live 字段的底下，对话结束后的分析照常运行。它是兜底的安全网：智能体没 标记出来的请求，照样会在对话结束时被记录并发出提醒，和没开 Live 时 一模一样。
Live 生效的地方
你的智能体对外说话的每一个地方：网站聊天组件、智能体的测试页面、WhatsApp 和其他消息渠道、邮件往来，以及打入和打出的电话。
在电话里，智能体只快速尝试一次标记请求，最多两秒钟，打电话的人完全不必等 它。如果没成功，智能体会用自己的话继续讲下去，通话结束时的检查会把请求 找出来。没有被记录为对话的通话，永远不会被实时标记。
让 Octo 帮你设置
最快的办法，是对 Octo 说一句话：
每次有人要求回电，都立刻给我发一封邮件。Octo 会找到产生那个标签的字段（或者提议在智能体的对话洞察里加一个），搭好 提醒工作流，并在把字段设为 Live 之前，把这次改动会波及的每一处都展示给 你看。在你点头之前，什么都不会变。
措辞很重要。「马上」「立刻」「一有人问就」「趁客户还在聊的时候」和「每次 有人问都要」，这些说法要求的是实时。平平的一句「有回电请求就通知我」， 得到的会是一封对话结束后才送达的普通提醒，Octo 会告诉你一次：它可以做成 实时的。
或者到「配置」里手动打开
-
在 /agents 上打开这个智能体，进入配置。
-
在会话结束后 —— 对话洞察就挂在那里 —— 的下方，有一个独立的区块： 「During the conversation」：
Turn a yes/no field Live and this agent flags it as soon as the customer asks, so its workflows run within seconds. Fields that aren’t Live are still found after the conversation ends.
没有挂对话洞察时，这里会显示 「Attach a Dialog Insight above to choose what this agent flags while the conversation is still going.」
-
每个会打标签的是 / 否字段都有一张卡片，上面有 Live 开关和挂在这个 标签上的工作流。枚举、文本和数字字段不在列：只有是 / 否字段能设为 Live。
每个会产生标签的是 / 否字段一张卡片。 -
把 要求回电 的 Live 开关打开。确认对话框 「Turn on Live detection for “要求回电”?」 会弹出。读完之后，按 「Turn on Live」。
只有工作区所有者和管理员能改动这个开关。其他人看到的是只读状态，旁边写着 一句 「Only workspace owners and admins can change Live detection.」
确认对话框会告诉你什么
确认对话框把开关波及的一切都列在 「This changes it for」 下面：
- 使用这份对话洞察的每一个智能体和每一个营销活动。 开关装在对话洞察 上，不是装在智能体上。如果前台把它共享给了夜间热线，两边都会开始标记。 共享的对话洞察会在卡片上方说明这一点：「Shared with 1 other agent. A Live switch here changes it for all of them.」
- 标签上的每一个工作流，以及它会在什么时候运行。标着 「Built for after the conversation. It reads the AI summary, which doesn’t exist yet while a conversation is live.」 的工作流，在你打开 Live 之前值得看一眼。
- 模型不能使用工具的智能体。 它们无法在对话进行中标记任何东西，它们的 请求仍会在对话结束后被发现。
如果你打开这个对话框期间，有智能体、营销活动或工作流开始使用这个字段，它 会显示 「Something changed since you opened this」，并请你 「Review again」。
客户会听到什么
智能体用它自己组织的话回答，依据写在它的指令里。它不会念一句写死的台词， 也绝不会告诉客户提醒发给了谁。
这就留下一个风险：智能体许下团队做不到的承诺（「埃利斯医生五分钟内就给 您回电话」）。所以确认对话框里有一个以智能体名字命名的复选框 「Tell 前台 what we can promise」，勾上它会往智能体的指令里加一句话。 默认内容是：
When a customer asks about “要求回电”, tell them the team will follow up. Don’t promise a specific time.
把它改成你团队的真实做法，比如「当天下午我们就回电」。这句话只会进到这 一个智能体的指令里，不会进到共享这个字段的其他智能体。
重复请求与提醒工作流
每张卡片都会在 「Workflows on the label “要求回电”」 下面写明每个 工作流什么时候运行：
| 卡片上写着 | 它的意思 |
|---|---|
| 「Runs for each new request (requests within 30 minutes are merged)」 | 工作流的触发器在每一次重复请求上都会运行。Octo 搭建实时提醒时就是照这样设置的 |
| 「Runs when the label is added: the first request, and again after every request is handled」 | 在 Live 出现之前搭的提醒，或者搭的时候没选重复。它保持原样不动；让 Octo 把它改成每个请求都触发 |
| 「Runs once per conversation until this field is Live」 | 一个还没设为 Live 的字段上，配了一个重复提醒 |
两条限制，防止一个话多或心怀恶意的客户把你的收件箱灌满：
- 30 分钟内的请求会合并。 在一个未处理请求的 30 分钟之内再说一遍 「请给我回电话」，仍是同一个请求：一个请求，一封提醒。这个请求会显示 「Asked again at 4:12 PM, merged into this request」。
- 每段对话在 24 小时内最多 5 个请求会启动工作流。 第 6 个及以后的请求 仍会被记录和显示，标着 「Alert limit reached」，但整个工作流对它们都 会跳过，不只是邮件。如果这个工作流还会更新 CRM 或给某人发消息，那些 步骤也同样跳过。
提醒邮件里写了什么
Octo 搭的提醒会把请求本身传下去，所以邮件会写明这是第几个请求。从第二个 请求起，邮件主题会以「(第 2 次请求)」「(第 3 次请求)」结尾，以此类推。 客户名字上方的那一行类似 要求回电 · 第 2 次请求 · 第 1 次请求仍未处理 （第一个请求只显示标签本身）。名字下方是：
- 致电 和 发邮件 按钮，在客户留了电话号码或邮箱时出现。
- AI 备注，可能引用客户原话：智能体标记请求时就这个请求写下的话。 「由 AI 助手在对话中撰写。AI 摘要会在对话结束后生成。」 备注以纯文本 显示，客户打过的任何字都不会在你的收件箱里变成链接。
- 对话的最近消息。
- 打开对话 和 标记为已处理。「标记为已处理」只会打开这段对话并 定位到那个请求，它绝不会自作主张改动任何东西，因为邮件扫描器会打开邮件 里的每一个链接。到了那里再点一下，请求才算处理完：参见 跟踪未处理的客户请求并标记为已处理。
先测一次：测试也会发出真的提醒
智能体测试页面和试用语音里的对话，和其他任何对话一样会被实时标记， 提醒工作流也是真跑：邮件发到真实地址。这是看到 Live 真正跑起来最快的 办法，值得先试这么一次。
之后想让测试不再进到你的提醒里，就对 Octo 说：
只对真实对话发提醒。它会加一个关于对话来源的过滤条件，来自测试页面、试用语音和测试批次的 对话从此不再触发提醒。这些测试对话的请求仍会照常显示在收件箱里。
不是应急手段
每张 Live 卡片都带着一行字：「Alerts can be delayed or missed. Not for emergencies.」 这话是当真的。提醒只是一封由工作流发出的邮件，而邮件可能迟到、被过滤， 或者根本没人打开看。
如果字段与紧急情况有关，确认对话框会把这句话再说一遍 （「Email alerts can be missed or delayed; they are not an emergency service.」）， 并为智能体准备了一句不同的话：
If the customer describes an emergency, tell them to call 911 or their local emergency number now. Don’t say that the team has been told.
在动物诊所，把这句话改成你们实际合作的急诊动物医院的名字，并保留它。Live 能让请求更快到达你的团队，但它不会把你的团队变成应急服务机构，也绝不能 让客户以为它做到了这一点。
关掉 Live
把开关拨回去，并确认 「Turn off Live」。智能体不再在对话进行中标记 这个字段，改回对话结束后才发现它：提醒会到得更晚，同一段对话里的重复请求 也不会再触发提醒。已经处于打开状态的请求会一直开着，直到有人把它们标记为 已处理。
接下来
- 跟踪未处理的客户请求并标记为已处理 —— 收件箱这一侧：哪些对话还等着人处理，以及怎么把每个请求关掉。
- 配置一个对话洞察 —— Live 开关所在的那些字段。