1.3 用户场景与适用边界

1.3 用户场景与适用边界

本节摘要：Parlant 不是通用聊天机器人框架。它面向逻辑严、要可解释、和业务强耦合的场景。用户是双轨的——开发者造工具，业务专家写指南。适合客服 SOP、合规风控对话、内部员工赋能；不适合心理陪伴和开放创意。边界说不清，后面所有特性都会被用错。

你能学到什么

阅读完本节，你应当能够：

1. 画出开发者与业务专家如何同时参与却不互相改代码
2. 用指南关系类型解释冲突时系统怎么选路
3. 对照三类典型场景：电商客服、金融合规、内部 HR/IT
4. 列出不该用 Parlant 的场景，避免为闲聊上重型框架

双轨用户，不是「全栈一人包办」

通用 Agent 教程常常默认读者是会写 Python 的全栈：提示、工具、业务规则全在一个笔记本里。规则引擎教程默认读者是开发：业务只能提需求。Parlant 原文把用户劈成两半，这是它和另外两条路最不一样的产品假设。

开发者维护工具：查询订单、更新库存、生成合规报告。语言可以是团队熟悉的后端技术，不必关心这句话最终怎么被自然语言触发。业务定义者——产品、客服主管、合规官——用指南描述：何时调哪个工具、冲突时谁优先、需要澄清时问什么。例如：「用户问订单到哪了且已提供订单号，则调用查询物流。」

这不是组织鸡汤，是关注点分离。少了「必须同时精通 NLP、后端和业务规则」的全栈瓶颈。代价是：两边都要有人真写东西。只有开发、没有指南维护者，系统会退化成工具目录；只有业务、没有合格工具，指南会变成空转口号。

指南不是关键词 FAQ，关系类型才是冲突解法

传统意图+槽位：分类模型打标签，覆盖一变就要重训。纯 prompt：把 SOP 贴进系统提示，冲突时模型自行「权衡」。规则引擎：优先级写在代码常量里。

原文把指南看成条件到动作的规则，条件作用在用户输入的语义表示上。多条同时激活时，靠关系类型：

这些关系是业务写指南时的元数据，不是模型即兴。运行时建激活图，再决定执行路径。确定性来自关系，灵活性来自 LLM 对口语的理解——混合，而不是二选一。

⚠️ 常见坑：把所有口语变体写成几十条几乎重复的指南。匹配变慢，还互相打架。应正交化语义空间，变体交给模型理解，冲突交给关系。
💡 关键直觉：交通灯不是让司机「自己看情况」，而是预先规定冲突怎么解。指南关系就是对话里的信号灯。

三类场景：值在哪，对照什么替代方案

电商客服。 每天大量订单、退货、券。关键词准确率低；专用分类模型维护贵；通用 LLM 容易口头放宽退货。Parlant 把 SOP 变成指南：已签收且非生鲜则发起退货并附地址。新增「奢侈品要视频验货」加高优先级指南，原逻辑不动。对照规则引擎：同样能写死，但「我想把这东西退了呗」这类口语要持续补关键词。

合规与风控对话。 银行助手被问「我能贷多少」时，不得直接报金额，必须走预审工具，并强调预估非审批结论。Dependency 保证信息披露前置。审计时对着指南 ID，而不是对着一次采样。对照通用 Agent：即使加了安全提示，抽检仍可能发现它「好心」给了具体数字。

内部赋能。 HR 假期、IT 排障。工具接内部系统，指南由 HRBP 或 IT 主管改。员工问「我去年休了多少天」，调用假期记录接口。IT 只提供工具，口径由业务改。对照纯 prompt 连内部知识库：知识会过期，操作类请求（开权限、提工单）仍要人。

值不值得上 Parlant，用三问压：
1. 说错话或调错接口，有没有合规/资金/医疗代价？
2. 流程是否多步、会不会中途改主意？
3. 改口径的人是不是经常不是写代码的人？
三个「是」，值得。三个「否」，杀鸡用牛刀。
​

开放域心理咨询、创意写作、天马行空闲聊，原文明确不是主场。表达力受指南覆盖限制；初始要把业务知识收成指南，小团队会嫌重；工具粒度过粗或过细，指南会扭曲。LLM 仍做语义和生成，Parlant 做行为控制器——互补，不是取代端到端模型。

原文提到的演进：指南版本与 A/B、可视化编辑、与检索增强类框架集成、从日志建议新指南。把它们当减负方向。自动生成指南若当唯一来源，会把错误 SOP 规模化，这是治理问题，不是功能彩蛋。

问题 我们能不能先用通用 Agent 做内部试用，再迁到 Parlant？

可以当探索，但要承认迁移成本：工具要按契约重包，口径要从提示词抽成指南，状态要从消息列表变成会话实体。试用期若已经让模型自由调生产接口，迁移前先把权限收掉。内部试用也建议走沙箱工具。

问题 业务专家完全不会技术，真能写指南吗？

原文假设他们懂业务流程，用自然语言写条件-动作，并用关系声明冲突。可视化编辑被写成降低门槛的方向。若业务连 SOP 都写不清，任何框架都救不了，那是流程资产问题。

边界案例：看起来像，其实不该上

第一种假适配：公司要做「有趣的品牌精灵」，希望每句都有梗。指南会把梗管死，模型会在约束里憋出尴尬。这是开放创意，请换路。第二种假适配：内部知识问答，只检索文档不操作。用检索增强加引用即可，上 Parlant 会为指南体系付额外税。除非问答里夹带「帮我提单、改权限」这类行动，才值得把行动部分接过来。

第三种假适配：已经有一套成熟的工单状态机，入口是按钮不是聊天。不必为了 AI 而 AI。第四种真适配却常被低估：夜间值守。人手少、SOP 清、风险高，指南能把「什么情况必须叫醒人」写死。通用 Agent 在夜里更敢行动，这不是优点。

双轨落地会失败在考核。若只考核开发的故事点，指南没人写；若只考核业务的对话量，工具契约会烂。建议把「指南变更次数与事故率」放进业务指标，把「未授权调用次数」放进工程指标。关系类型的培训要给业务：蕴含、优先级、依赖、消歧各举他们自己 SOP 里的例子，不要讲图论。

小团队只有两个人时，双轨仍成立，只是两顶帽子戴在同一批人头上。关键是资产分离：工具仓库和指南仓库不要混成一个提示文件。人可以身兼，文件不能身兼。否则休假一周回来，分不清哪句是代码哪句是口径。

三问打分（每问是记 1）
说错或调错有没有合规资金医疗代价？
流程是否多步、会不会中途改主意？
改口径的人是不是经常不是写代码的人？
0-1 分：先别上。2 分：局部试点。3 分：主路径值得。
​

试点范围建议选「高风险但闭环短」的路径，例如查单加标准安抚，不要一开始就做完整退款赔付。短闭环才能在两周内完成抽检。边界清楚，后面的特性才不会被用去支撑一个本不该存在的闲聊机器人。

组织摩擦比技术边界更先出现

双轨失败很少因为装饰器不会写，多因为业务认为「写指南是额外负担」。要算清楚：现在改口径要等两周排期，指南化之后改口径是文本变更加抽检。把这两周换成他们自己的工时，他们才愿意写。开发侧摩擦是害怕失去控制——指南一变行为就变。应用版本化与灰度：指南变更走评审，关键路径自动回归。边界不只是场景边界，也是组织边界。场景适合但组织不接受双轨，落地会伪装成提示词工程，只是文件名改叫指南。伪装是本章最想让你提前看见的坑。

对照作业：场景三问与组织双轨

围绕「场景三问与组织双轨」，把四条路径再过一遍。表里每格都是可执行判断，不是形容词。读完请把你的项目钉进一格，不要钉在两格之间假装都占了。

伪装成指南的提示词，是本章最阴的坑。文件名改了，真源没改。用「运营改文本能否改行为」识破伪装。

夜间值守是被低估的真适配：人手少、SOP 清、风险高。通用 Agent 夜里更敢行动，那不是优点。

钉列纪律：场景边界与双轨组织

在「场景边界与双轨组织」上，纯 prompt 把判断写进一段话，改的人必须会改提示，复盘只能翻聊天，口语进得来但口径会漂。通用 Agent 把判断交给循环，灵活的代价是越权与路径不可复现。规则引擎把判断写进分支，确定的代价是口语进不来、改口径要排期。Parlant 把判断写成指南与契约：业务改口径，未授权则无行动，复盘指轨迹。把这四句贴到工位上，比再记一组术语有用。

针对场景边界与双轨组织，本周只做一件可验收的事：找出一条真实对话或工单，标注它今天落在哪一列；若要迁到第四列，缺的是指南、工具还是关系边。缺指南就写草稿，缺工具就列契约，缺关系就补消歧或依赖。不要同时开十条战线。最常见的伪装是文件名叫指南、真源仍是提示词，或者架构图上有网关、运行时模型仍直接调函数。用「改文本能否改行为」和「低权限点名是否被拒」两张试纸识破。识破了再谈优化与案例。优化在伪装上加速，只会让错误承诺更多；案例在伪装上复制，只会把新闻变成事故。

场景边界与双轨组织的纪律是先钉列，再谈快。钉列需要抽检，抽检需要轨迹，轨迹需要审计真的在记抑制原因，而不只记最终回复。若没有抑制原因，排错会以为没写规则，其实是优先级压了。看得见「为什么没走另一条路」，才叫对照，才叫可控。把这句话写进值班手册，场景边界与双轨组织才从概念变成岗位。对照驱动不是文风，是岗位制：模型是引擎和笔杆子，方向盘在指南与工具契约上。谁把方向盘又塞回提示词，谁就在场景边界与双轨组织上退回第一列。

核心回顾

• 双轨：开发造工具，业务写指南；缺一边都会退化
• 关系类型：蕴含、优先级、依赖、消歧，用来解冲突，而不是让模型「权衡一下」
• 三类主场：电商 SOP、合规对话、内部赋能
• 三问筛选：代价、步长、改口径的人是谁
• 明确不主场：开放创意与情感陪伴
• 混合架构：LLM 负责懂人话，Parlant 负责不许越界

下一节看这套双轨假设从哪来：内部痛点、开源策略、存储演进，以及许可证原文为什么说法不一。