📝

Parlant（18.2K⭐）是客户交互控制层：把业务约束写成可组合的 Guideline，用 Relationship 解冲突、Journey 管多轮 SOP、Tool 按场景开放、Strict 模板锁死合规话术——控制来自「匹配—关系解析—工具—合成」流水线，而非某句神奇提示词。

Parlant 3.3：不靠巨型提示词，把客服 AI 的规则、工具与合规真正管住

原文：微信公众号「如此才是」《Parlant 3.3：不靠巨型提示词，把客服 AI 的规则、工具与合规真正管住》· 项目：emcie-co/parlant（18,221⭐）

做一个会聊天的 Demo 不难，难的是上线后仍能稳定做到：退款前先核验、VIP 走不同政策、工具失败不胡编、人工接管不断档，而且每次回答都能解释「为什么这样说」。

把规则全塞进 System Prompt 会越改越长，流程图分支一多也会变脆。Parlant 把业务约束写成可组合规则，每轮只选择当前需要的上下文，再让 LLM 生成自然回答——它不是聊天模型，而是客户交互控制层。

功能不是清单，而是一套控制系统

Guideline（准则）

由「何时适用」和「应该怎么做」组成，可附详细说明、优先级、关键程度、标签和处理器。条件会读取完整对话，而非关键词命中。只需感知状态、不需要直接回答时，用 Observation（观察）；它也能触发工具、检索器或 Journey。

准则会推断一次性、持续到问题解决或条件成立期间生效
track=False 可要求重做
LOW/MEDIUM/HIGH criticality 决定匹配投入
动作宜短，细节放 description，可减少 token 和延迟

Relationship（关系）

解决规则冲突：依赖、互斥、prioritize_over、蕴含和歧义消解；目标既可是一条准则，也可用 Tag 组织成 AnyOf/AllOf。3.3 又加入数值 priority 与工具执行后的重新评估。源码中的解析器以最多三轮固定点计算，顺序处理依赖、关系优先级/互斥、数值优先级和蕴含，并保留淘汰原因。

Journey

适合开户、理赔、退订等多轮 SOP。可适应的有向图：Chat State 负责沟通、Tool State 执行业务、Fork State 分流；支持条件跳转、汇合、回退、跳步、链接另一段 Journey 和明确结束。

激活条件只决定何时进入，进入后由状态与转移控制
关键操作前应安排确认节点
避免连续 Tool State，把真正的业务事务留在工具层

Tool

挂在准则或观察上，先匹配场景再开放，而非全局暴露给模型。必须是 async，首参为 ToolContext，返回 ToolResult；consequential 标记会促使引擎谨慎核参。

结果可携带数据、隐藏 metadata、临时准则、罐头回复或模板字段
也能更新会话/客户和切换人工模式
参数支持来源优先级、隐藏值、动态选项及 Pydantic 约束

Retriever

用于一次性被动知识注入，与准则匹配并行；可按 Agent、Guideline、Journey 或具体状态限定作用域。Deferred Retriever 先启动昂贵查询，匹配完成后再按命中规则过滤，兼顾延迟和准确率。

Glossary

保存术语、定义和同义词，按语义取回，帮助引擎理解公司黑话；动态事实仍应交给工具。

Canned Response

三种模式：Fluid 优先参考候选模板、必要时自由生成；Composited 用候选回复约束风格；Strict 只允许模板，无匹配则兜底。

Jinja2 模板可读取客户、Agent、变量、工具和生成字段；缺少必填字段会被确定性淘汰
模式可按准则、Journey、状态覆盖，冲突时最严格者胜出
流式输出只适用于 Fluid

运行实体与外围

Agent：管人格、输出模式和稳定 ID
Customer：支持访客、标签和中途绑定身份
Session：保存消息、工具、自定义事件、标签、状态与 trace ID，AI 和真人客服共用一条时间线
Context Variable：可按客户或标签赋值，并按每轮或 cron 新鲜度刷新
外围：Python/TypeScript 客户端、REST/OpenAPI、React 组件、SSE/长轮询、主动消息、人工接管、输入审核、限流、授权、CORS、OpenTelemetry，以及自定义 API、容器组件和引擎 Hook
Capabilities API 会按语义选能力，但源码明确标为 experimental

五分钟跑起来

Python 需 3.10—3.14。默认使用 Emcie，也内置 OpenAI，并提供 Anthropic、Gemini、Vertex、Bedrock、Azure、Ollama、LiteLLM 等适配器。

1 2	pip install parlant export EMCIIE_API_KEY="***"

创建 main.py：

import parlant.sdk as p

async def run():
    async with p.Server() as server:
        agent = await server.create_agent(
            name="售后助手",
            description="负责订单、退款与人工转接"
        )

        @p.tool
        async def order_status(ctx: p.ToolContext, order_id: str) -> p.ToolResult:
            return p.ToolResult({
                "order_id": order_id,
                "status": "已发货"
            })

        await agent.create_guideline(
            condition="用户查询订单状态",
            action="先取得订单号，再查询并准确说明状态",
            tools=[order_status],
        )

1 2	python main.py # 打开 http://localhost:8800 即可调试

换供应商时安装对应 extra，如 pip install "parlant[anthropic]"；前端可用 npm install parlant-chat-react，Python/JS 客户端包均名为 parlant-client。

一条高效落地路线

第一步，先写 10—20 条最常见、风险最高的 Guideline，不要复刻整本制度。条件写「已经可观察到的事实」，不要写「用户可能会……」。把例外拆开，用 Relationship 表达依赖和互斥，用 priority 处理同一时刻只能选一条的规则。

第二步，多轮目标做成 Journey：每个状态只承担一个任务，分支互斥且尽量完备；扣款、删除、提交前先确认，工具后回到 Chat State 解释结果。

第三步，区分三类上下文：固定定义进 Glossary；每轮个性化信息进 Variable；实时或大体量数据进 Tool/Retriever。检索器尽量按规则或 Journey 缩小范围，只有普适资料才放 Agent 级；耗时查询使用 deferred。

第四步，按风险选择回复模式。营销问答用 Fluid；品牌措辞严格但仍需组合时用 Composited；法律披露、价格承诺、验证码等用 Strict。把必要字段显式列入模板，让「数据不足」变成不可选，而不是交给模型猜。

第五步，用内置解释能力查看：哪些准则被匹配、哪些因依赖或优先级被剔除、工具为何调用、最终用了哪种生成模式。把线上失败样本转成新增准则、关系或回归测试，而不是继续扩写总提示词。

第六步，再调性能。匹配策略会并行分批：基础策略下，普通准则 10 条以内一批，11—20 条两批，21—30 条三批，更多则五批；批次越大调用更少，延迟和判断负担可能上升。LOW criticality、合理作用域、缓存后的规则预评估，都能降成本。每轮引擎默认最多准备三次，通常 2—3 次能覆盖「工具返回新事实→新规则生效」；压到 1 次更快，但会错过动态联动。

为什么比「提示词堆料」可控

采用六边形架构：core 放领域模型、端口和 AlphaEngine；adapters 实现 LLM、向量库、持久化和观测；api 是 FastAPI 入口；sdk.py 提供异步 DSL。外部实现可替换而不必改业务规则。

一轮消息先加载变量，并行准备术语与实验能力；随后匹配 Journey 和 Guideline，解析关系；把普通规则与带工具规则分开，推断参数、调用工具，再根据工具结果重新匹配。状态稳定或达到 max_engine_iterations 后，才进入处理器、Journey 逻辑与回复合成，最后写入 ready 事件、Agent 状态和追踪数据。主动 utter() 则把指定意图转成一次受控准则匹配。

匹配不是向量相似度硬猜。官方工程文章说明，Embedding 难以处理时间、逻辑和状态条件，Cross-Encoder 与专用分类头也不够稳定；当前实现按规则类型分组，用 LLM 执行结构化的 Attentive Reasoning Queries（ARQ），多个批次并发，并把配置预评估结果缓存。ARQ 通过字段顺序和临近决策处重申关键条件利用注意力近因效应，不要求暴露思维链。官网公布的项目测试集结果为 ARQ 90.2%、CoT 86.1%、直接询问 81.5%（项目自测数据，不应当作通用基准）。

回复阶段同样分层：Fluid 先起草，再语义召回模板，渲染字段并选择最佳候选；Strict 则把生成空间锁在已批准模板内。控制因此来自「匹配—关系解析—工具—合成」流水线，而不是某一句神奇提示词。

源码安装与生产清单

pip install git+https://github.com/emcie-co/parlant@develop
git clone https://github.com/emcie-co/parlant.git
cd parlant
python -m pip install uv
python scripts/initialize_repo.py
uv run python examples/healthcare.py

初始化脚本会执行 uv sync --all-extras 并安装 Git hooks，依赖较重；日常开发可运行 uv run pytest，项目的 API、核心、适配器、SDK、端到端和随机性场景均有测试目录。

持久化：默认本地存储只适合开发。源码提供 JSON、MongoDB、Snowflake 持久化，向量层有 Chroma、Qdrant、Mongo 和内存实现。多副本必须使用外部存储，并补齐 TLS、密钥、备份和容量规划
安全：至少替换默认放行的 DevelopmentAuthorizationPolicy，启用生产授权策略、按 IP/操作限流和收紧 CORS；敏感输入可用 provider moderation，paranoid 模式需 Lakera
观测：OpenTelemetry 可分别上报 trace、metric、log；重点观察准则匹配、工具调用、首条消息时间和生成耗时

最后要明确边界：Parlant 控制「如何与客户交互」，不是 CRM、支付或工作流引擎；LangGraph 等外部流程应通过工具或检索器接入。依赖 LLM 判断，HIGH criticality 代表增加推理投入而非数学保证；真正不能变形的输出要用 Strict 模板，真正不可逆的业务操作要在工具端做鉴权、幂等和审计。

如果你的痛点是「Agent 会说，但不能稳定按业务规则说」，Parlant 的价值不在多一个编排框架，而在把规则、状态、工具、话术、解释和运行治理放进同一条可测试的控制链。先从高风险准则和一个 Journey 切入，往往比重写整套提示词更快看到收益。

💬 本文评论区已开启，但暂无读者留言。