“会回答”与“能执行”之间，隔着身份、权限、状态和结果。会员说“帮我处理一下”，这句话本身不能成为改业务数据的授权；模型说“处理好了”，也不能成为业务成功的依据。

SRICH CHAT 把模型判断与任务执行分开。模型可以在配置允许的位置理解意图、选择候选；Runtime 按已发布流程管理状态，能力层只执行注册并通过契约校验的动作，最终业务规则由运营商自己的系统检查。

一条消息先经过谁

  1. 先看会话与任务状态。 是否允许 AI 参与、是否已有进行中的任务，会影响后续处理。已有任务的输入按当前步骤处理，不随一句闲聊改成另一项工作。
  2. 再看知识与办事需求。 已采纳问法可以直答，知识检索提供候选。按配置，候选可由阈值规则处理，也可把知识候选与员工岗位交给同一次模型判断。模型不是每条消息必经的一站。
  3. 交给实际处理者。 问规则可以答 FAQ；有明确岗位可启动员工；需要人继续的会话通过举手与等待回复标记被客服看见。客服一直能看到共享会话，不需要把整段对话搬去另一个系统。
  4. 按真实结果回复。 系统区分任务结束、接口受理与业务最终结果，不把三者混成一个“成功”。

当前决策配置支持先做影子对比再切换。不同部署采用的判断方式可能不同，不能把“可以启用”写成“默认所有消息都由模型判断”。

查单员怎样办一件事

以“已付款但某笔订单未到账”为例：读取该会员订单 → 让会员确认订单并提供水单 → 按站点与网关找到配置的上游群 → 提交核查 → 等待有效回执 → 符合条件时调用完成订单接口 → 再读业务最终结果 → 如实说明结果。

这需要买方提供两个看板和一个操作接口，并配置、发布员工流程、Telegram Bot、群映射与图片存储等前置。系统不会凭聊天里的一句“确认了”直接改账本，也不负责计算应加的金额。

上游说收到、业务接口返回受理、会员实际看到处理结果，是三个不同事实。例如 processed 表示业务侧已收到并提交处理，不能无条件改写成“钱已到账”。

为什么流程不会任意漂移

一位员工有明确岗位、步骤和出口。无关输入按当前步骤提示处理，不交给模型自由续写；同一步连续三次无关输入会结束本次工作。读接口可按规定有界重试，写操作不会因为超时自动补发。任务技术失败与最终结果暂时未知，也有不同的出口。

这能约束执行行为，不等于模型永远不会误判。我们把“判断是否选对任务”和“进入任务后是否遵守流程”分开验证。

既有隔离测试记录包含 30 个无关输入场景、360 个断言，验证的是指定场景的流程约束，外部接口使用替身；它不能证明所有真实输入零错误，也不是节省人力比例的证明。

新岗位如何扩展

为新任务确定输入、权限、步骤、接口、成功和失败出口，注册需要的能力，校验并测试，再发布。已有能力可复用，新业务动作仍需要开发接入。我们希望持续增加可负责的专岗，而不是让一个无边界模型拥有整个业务系统的写权限。

产品与对接入口

本文为 2026-09-22 整理的公开说明；功能使用取决于已部署版本、配置和对接情况。接口实现以对应版本的帮助中心契约为准。