客服 Agent 出事故，多半不是“不会答”，而是“太会答”。产品文档没写的退款政策，它能自己编一套；语气稍微放松，就开始跟客户称兄道弟。常规解法是把 system prompt 写到几千字，结果越写模型越记不住。Parlant 换了个路子：别写大 prompt，写规则库，每一轮只把命中的几条塞进上下文。GitHub 18,311 星，Apache-2.0，值得单独聊一篇。
它到底管什么
Parlant 是 Emcie 团队 2024 年 2 月开源的项目，官方给自己的定位是 “interaction control harness”——直译是“交互控制缰绳”，不是工作流引擎，也不是模型。当前版本 v3.3.2，Apache-2.0，商用不用掏授权费。它盯的是客服、售前这类面向客户的对话：话术要一致、政策不能越线、出了问题能查。官方也直接把它摆成 Ada、Decagon、Sierra 的开源替代。
跟 LangGraph、DSPy 的分工，官方说得很直白：LangGraph 擅长工作流编排，DSPy 擅长底层 prompt 优化，Parlant 管“这一轮该看什么、该说什么”。
核心原语有五个：
- Observation：监听对话，条件成立就触发。
- Guideline：带动作的 observation，也就是“当……时，做……”。
- Tool：外部 API 只在关联 observation 命中时才进入上下文，减少误调用。
- Journey：多轮 SOP，不是死脚本，能跟着用户的回答走。
- Canned Response：高风险场景直接套预审过的模板，绕过模型生成。
再往外还有 glossary（业务术语表）和 OpenTelemetry 全链路 trace——每一轮哪条规则被命中、为什么命中，都能翻出来。对客服团队来说，这个比“回答得像人”更值钱。
它内部的做法不玄：先把对话拆成观察点，再逐条判断条件，命中的 guideline、tool、journey 才进入本轮上下文。规则总量可以堆到几百条，单轮真正看到的可能只有三五条。这就是它敢说自己能管住复杂客服的原因。
上手：一个文件就能跑
要求 Python 3.10 到 3.14，直接 pip：
pip install parlant
最小示例，起一个车行客服：
import asyncio
import parlant.sdk as p
async def main():
async with p.Server() as server:
agent = await server.create_agent(
name="Otto Carmen",
description="You work at a car dealership",
)
await agent.create_guideline(
condition="the customer greets you",
action="offer a refreshing drink",
)
asyncio.run(main())
模型侧，官方推荐自家的 Emcie 推理服务，设 EMCIE_API_KEY；也支持 OpenAI、Anthropic、Gemini，或者用 LiteLLM 转接。跑 python main.py，浏览器开 localhost:8800 就能对话调试。生产环境换 parlant-server，默认 8080，数据落在 ~/.parlant，首次启动记得加 --migrate。
要改行为，不用回去改那一大段 prompt，加一条 guideline 就行。这是它跟“提示词工程”最大的区别：行为是数据，不是咒语。
实话：代价和边界
先说代价。每轮多一次观察匹配，token 和延迟都会涨；官方没给统一数字，量级取决于你挂了多少条规则、用什么模型。规则写得含糊，匹配就会飘，垃圾进垃圾出。条件写太宽，不该触发的话术会被放进来；写太窄，该拦的又没拦住。上线前拿真实对话回放跑一遍，比看 demo 有用。
再说边界。Parlant 不是拖拽式工作流平台，复杂业务流程还得配 Dify 或 n8n。它官方推荐的推理服务是 Emcie 自家的，换通用模型要自己调匹配质量；社区规模也比 LangChain 系小。
那它适合谁？客服、售前、合规敏感、话术必须一字不差的 B2C/B2B 场景。不适合谁？一次性脚本、批量数据处理、需要大量人工审批节点的内部系统。
一句话总结：如果你被“Agent 乱说话”折磨过，Parlant 是目前少见的、把行为控制当一等公民的开源项目；如果你要的是把二十个系统串起来，先去看 n8n 或 Dify 那两篇。
