1.1 愿景价值与范式对比

1.1 愿景价值与范式对比

本节摘要：Parlant 的愿景不是「让大模型更好用」，而是把代理从提示词堆砌的幻觉表演者，改成行为可预期、责任可追溯的数字员工。对照纯 prompt、通用 Agent 和传统规则引擎，它的核心动作是把「做什么」交给指南、把「怎么做」交给工具，让模型只管理解和措辞。

学习目标

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

1. 说出提示工程在长流程里为什么会碎
2. 对照三条替代路径，指出 Parlant 把控制权放在哪里
3. 用金融客服例子讲清开发写工具、业务写指南
4. 列出可控、可维护、可组合三条价值及其代价

提示工程先碎，不是模型先笨

过去几年，很多团队把业务逻辑写进提示词：退款口径、身份校验顺序、能不能透露余额，全塞进一段自然语言。短问答还能撑。流程一长——先验身份、再查资产、再算收益、再按监管口径说话——提示词就变成一份没人敢改的「口头宪法」。改一条合规要求，等于重写整段咒语，还没法单测。

更糟的是职责糊在一起。程序员被迫当语言炼金术士，领域专家改不了行为，只能提工单。通用 Agent 框架看起来进步了：模型自己规划、自己调工具。灵活是真的，越权也是真的——模型「觉得」该转账，就构造了转账参数。传统规则引擎相反：行为确定，但用户说「我那笔单子怎么还没影」，规则写的是订单号字段，两边对不上。

Parlant 问的是更硬的一句：能不能把 What 和 How 拆开？ 开发实现可测试的工具；业务用自然语言指南决定何时调用、如何组合、如何对用户说话。模型还在，但它不再是决策主体。

纯 prompt:   [业务口径] ──全塞进──► [一段提示词] ──碰运气──► 输出
通用 Agent:  [目标描述] ──交给──► [模型规划循环] ──可能越权──► 工具
规则引擎:   [if-else] ──听不懂人话──► 确定动作
Parlant:    [指南 What] + [工具 How] ──引擎匹配──► 受权动作 + 受控措辞
​

对照表：四条路到底谁说了算

⚠️ 常见坑：把 Parlant 当成「更好的提示词框架」。它不是。提示词仍可能出现在生成环节，但行动许可来自指南与工具契约，不来自模型心情。
💡 关键直觉：航空飞控不取消飞行员，但飞行员不能凭直觉关掉液压。Parlant 对 LLM 也是这层关系。

图 工具与指南的职责分离

金融客服是原文反复用的例子。用户问「我的投资组合表现如何？」背后有身份验证、资产查询、风险评估、收益计算。全塞进提示词，监管一改 GDPR 披露口径，整段提示作废。Parlant 里开发实现 get_financial_insights 一类工具，保证输入输出和错误处理；业务写指南：「当用户请求个性化财务洞察时，调用该工具，并以简洁图表形式呈现。」各写各的，互不污染。

三条价值，以及你要付的账

可控性。 外部操作必须走预定义工具，工具是确定性函数。原文还强调 ToolContext：可用客户标识对齐身份，可用进度反馈避免用户以为卡死，可用状态标记「处理中」或「需人工介入」。对照通用 Agent：模型直接 function calling，权限模型往往是「描述里写了别乱用」——那不是权限，是祈祷。

可维护性。 口径变了改指南；工具字段变了改工具。碳足迹要进财务报告？扩展工具返回字段，指南加一句「同时展示碳排放」。不必重训模型，也不必重构提示模板。对照纯 prompt：每次改都是全文回归。对照规则引擎：每次改都是开发迭代。

可组合性。 真实对话会中途改主意：「先别看收益，帮我赎回。」指南支持条件、分支、等待确认。原文例子：转账超过五千先做风险检查，风险高则询问是否继续，明确确认后再调转账工具。这不是把 LLM 当工作流引擎，而是用可读规则编排确定性动作。

局限也要对照着说，原文写得很直：初始要建工具库和指南体系，不适合一次性小任务；工具没覆盖的场景会「无能为力」，需要回退；特别复杂的动态规划，自然语言指南会不够用，得靠脚本扩展。别用「集成化」掩盖这些账。

指南如何被机器执行？原文给的是混合路径：先把指南结构化成意图-动作-条件，运行时按对话匹配相关指南，再把匹配结果交给主模型生成合规调用——而不是把整本指南当超长提示灌进去。工具则有契约：参数类型、权限、副作用。运行时当沙箱，违约调用拦截，调用写进结构化日志。

和「模型微调」也要对照一次

有人会问：微调一个听话的客服模型，是不是比上框架更省事？微调能改善口吻和领域词，不能单独解决越权行动和口径审计。权重里的「大概会遵守退款政策」过不了合规抽检。Parlant 把政策留在指南文本里，抽检时可以对着指南 ID 说话。微调可以做领域自适应的补充，原文第 3 章会讲：它更倾向外部知识注入，而不是频繁改基座权重。

另一条常见岔路是「先用通用 Agent 跑通，再补护栏」。护栏如果只是输出过滤，拦得住脏话，拦不住错误承诺——承诺已经生成了。Parlant 把拦截提前到「是否允许调用这个工具」。这是控制点位置的差别，不是文案差别。

# 概念对照：工具是确定性动作，不是模型即兴
# 业务指南只描述何时调用，不把查询逻辑写进提示词
@p.tool
async def get_financial_insights(context: p.ToolContext, customer_id: str) -> p.ToolResult:
    # 真实查询发生在工具内部，输出结构受契约约束
    return p.ToolResult("已按客户标识汇总收益与风险摘要")
​

原文提到的方向包括：从历史对话辅助生成指南草案、从接口说明辅助生成工具契约、多代理在共享规则下协作。这些是路线，不是保证已全部产品化。选型时把它们当「可能减轻初始成本的方向」，不要当今天就能买到的开关。

评审会上怎么把这套愿景讲完

产品会常出现一种假共识：大家都说要可控，各自指的却不是同一个开关。有人说的可控是温度调到零，有人说的是加一句系统提示，有人说的是上线后人工抽检。Parlant 的愿景要把可控定义成：未授权的行动在系统层发生不了。评审时请把这句话写成验收，而不是写成形容词。温度与提示仍然有用，但它们不承担「转账有没有打出去」的证明责任。

和业务专家沟通时，不要从框架名开始。从他们正在用的 SOP 开始：哪一步必须人工、哪一步禁止承诺金额、哪一步依赖订单状态。这些句子几乎已经是指南草稿。开发要做的是把句子里的动词变成工具，把名词变成术语或槽位。若 SOP 本身互相打架，框架会诚实地把架打在激活图上——这是优点，不是缺陷。先治 SOP，再治代理。

和只信通用 Agent 的同事对照时，承认他们的灵活。探索性内部助手、写代码、搜资料，模型规划往往更合适。分歧在生产对话：用户是顾客或监管对象，说错话有工单和法律。灵活在这里是负债。可以并存两套：探索用通用 Agent 沙箱，生产对话用 Parlant。不要用同一套提示词服务两种风险。

和只信规则引擎的同事对照时，承认他们的确定。若入口已经是表单字段，不必强行加对话。Parlant 的增量是口语入口。用户不说订单号、说「我那单还没影」，规则引擎要补无数关键词，指南加模型理解更便宜。代价是你要维护术语和指南资产。没有人维护，确定优势会退回提示词时代。

落地第一周不要追求覆盖所有意图。选一条高风险路径，例如退货或余额查询，把工具契约、指南、失败转人工跑通，再抽检解释链。愿景是白盒协作，第一周的产物就应该能指着指南说话。若第一周只有一个聊天窗口和一段超长提示，那叫用新名词做了旧事。

愿景验收口（写进立项）
1. 未授权工具：零调用
2. 政策变更：改指南不发版（结构变更才动 Journey）
3. 抽检：对话能指到指南 ID
4. 角色：业务能改口径，开发能改工具，互不挡路
​

把「数字员工」当成岗位说明书

愿景里的数字员工要有岗位说明书：职责是执行已授权动作并用合规措辞沟通；权限止于工具契约；考核是未授权零调用与口径抽检通过。不要写「聪明、主动、有同理心」当主职责。同理心属于风格字段，主动属于预写规则触发，聪明属于模型能力。岗位说明书写混，招聘（选型）就会混。对照真人坐席：我们也不会把「口才好」写成可以擅自退款的授权。框架愿景其实很土，土在把 AI 拉回岗位制，而不是拉进天才制。土，才可上线。

要点速记

• 提示工程先碎：长流程把口径塞进提示词，改一次赌一次，职责也糊掉
• 四条路对照：prompt 快而不审、通用 Agent 活而越权、规则引擎硬而不懂人话、Parlant 用指南+工具握住方向盘
• What/How 分离：开发写工具，业务写指南，模型管措辞
• 三条价值：可控、可维护、可组合；代价是初始资产库和覆盖盲区
• 拦截点靠前：不授权则不能行动，比事后过滤承诺更接近合规
• 别神化：复杂规划仍可能要脚本；开放闲聊请换路

下一节把「愿景」拆成可对照的特性清单：状态机、客户实体、工具链、可解释性、多租户。