Dynamic Planner（动态规划）：把一个复杂请求变成一步步的计划

大多数对话不需要计划。有人问你的智能体一个价格、一个营业时间，或者一个单一的操作问题，该得到的是一个直接答案，而不是一个项目。但有些对话不一样：用户想把一整件事办成——注册一家公司、申请一个签证、处理一起家具损坏的理赔——而且他明显不知道该从哪儿下手。Dynamic Planner 正是为这一刻而存在的：它把这一场对话变成一条临时 storyline（一份嵌套的、由清单驱动的计划），再由智能体一步一步走完。

这是一项 Pro 能力，按租户开启。负责规划的模型由平台运营方按租户指派，而不是在对话里临时挑选——正因如此，有数据驻留要求的租户可以被指到本地或本地区的模型上，其余租户继续用托管模型。

什么时候会触发一份计划？

绝不会是模型「自己决定」，也不会有一个让用户随意点单的开放输入框。一共三条入口，按确定性从高到低排：

1. 一个可展开的 storyline 步骤。 租户把一条已编写好的 storyline 中的某一步标记为可展开。用户走到这一步时，智能体会提出把这一步展开成一份子计划。这个判断作者在设计时就已经做过了，没有留给运气。
2. 用户接受了邀请。 每一份计划都从一张确认卡片开始（就是别处一直在用的那套提问表单 UI）。用户随时可以拒绝，而且这次会话里智能体不会再问第二遍。
3. 升级判定。 在 storyline 之外，一次专门的小模型调用会盯着每一轮对话，从三个维度给它打分——下面就讲。只有三项全部通过，用户才会看到这个邀请。主对话模型从来不被指望「记得」去触发什么；这个判定是引擎发起的一次强制的、结构化的调用。

租户自己编写的 storyline 永远优先：只要有一条 storyline 正在驱动对话，规划器就保持沉默。手工搭的流程胜过生成的流程。

三个维度的升级判定

判定评估的是任务复杂度、用户困惑和领域契合——三项必须同时成立。这是这项功能的核心，所以下面把真实的判断逻辑和例子摆出来。

1. 复杂度——这真的是多步骤的事吗？ 这件事应当需要好几步、好几份材料或者好几轮对话才能完成。一个问题不构成一份计划。

• ✅「我想开一家做电商的美国公司，完全不知道这里面都涉及什么」
• ❌「特拉华州注册要多少钱？」——查个价，直接回答就行
• ❌「SS-4 表第 7b 行怎么填？」——用户本来就在走这个流程，这只是其中一个具体步骤

2. 困惑——用户是想被人带着走一遍吗？ 信号包括：「我到底该从哪儿开始」「我需要准备什么」「把整个流程给我讲一遍」「这么多东西我根本记不住」。一个清楚流程、只问其中某一环的用户并不困惑——把那一环告诉他，别给他一份计划。

• ✅「老板让我把美国子公司设起来，我从来没干过这种事」
• ✅「注册办完了——接下来还有什么？年报？税？我实在理不清，不如你帮我记着」
• ❌「材料我都齐了，你就告诉我去哪儿交」——是清楚，不是困惑

3. 领域契合——这是这个智能体的活儿吗？ 用户嘴里冒出「计划」两个字，并不能打开这道门。租户是按对话付费的；一个做公司注册的智能体会拒绝变成一个通用的私人助理，无论这个请求措辞多客气。

• ❌「给我做一份三个月的健身计划，细到每周」——不在领域内，拒绝
• ❌「一步一步给我规划一趟十天的欧洲行程」——不在领域内，拒绝

生成出来的计划本身同样受领域约束：规划器会拿到这个智能体的职责范围，并且必须让每一步都待在里面。

用户点了「好」之后

规划是整个过程中唯一带概率的环节，而且它只发生一次：一个规划模型把计划起草成结构化数据——若干步骤、每一步的指令、一份「要收集什么」的清单、一个完成标准。这份草稿会像任何一张 storyline 图一样被校验（格式不合法的计划会重试，再不行就交给备用模型；始终校验不过的计划干脆不会运行）。一份固定的边界模板会被确定性地盖进每一步——遇到矛盾必须指出、不得推荐该步清单之外的东西、不得作出批准或价格上的承诺——所以这些护栏从不依赖规划模型是否记得把它们写进去。

从这里往后，执行就是 storyline 引擎在做它一贯做的事：每一轮只走一个专注的步骤，清单项只有在有证据时才被勾上，进度显示在横幅里，一条细进度条，以及一份由引擎渲染的步骤列表——所以你看到的是真实状态，而不是模型对状态的回忆。计划以嵌套方式运行：如果它是某个 storyline 步骤展开来的，那么计划完成后，父 storyline 会从它离开的确切位置继续。