不是把所有规则塞进 Prompt：客服 Agent 如何按需装配业务能力

返回 ResolveAI 项目总览

“我的退款怎么还没到账？”

客户说这句话时，并不知道系统里有什么“退款跟进场景”，更不会主动选择策略版本。他只期待客服理解自己的问题，找到对应记录，给出下一步处理。

而对系统来说，同样带着“退款”两个字，可能是查询个人进度，也可能是咨询退货条件。前者需要身份与业务对象，可能涉及异常工单；后者需要政策资料，不应该顺手查询个人记录。两种诉求看起来相近，背后的权限、信息与处理流程却不相同。

在 AgentOne 的客户模拟入口中，我把这件事拆成了两个问题：这一轮需要哪项业务能力？确定能力之后，应该为它准备哪些信息和执行规则？ 本文沿用博客项目名 ResolveAI，讨论 AgentOne 个人复现版的实现。退款用于解释机制，不概括企业项目的全部业务或个人参与范围。

这样，客户可以从自然对话进入业务；系统则不必把所有场景的详细配置一次性交给模型。

先区分三种“加载”

讨论动态加载时，最容易混在一起的，是配置存在哪里、一次运行用了什么，以及模型最终看到了什么。

因此，服务端内存里可以同时保存很多配置，而某次业务运行只绑定其中一份。即使已经选中这份配置，也不代表配置中的全部内容都会进入模型请求。

动态的，是每轮选择与装配的组合；业务规则本身仍然是提前定义、带版本的资产。 系统不会在听到客户说“退款超时”后，临时让模型编出一套退款政策。

这个区分也决定了方案的重点。把 Prompt 缩短只是可能的附带效果，更重要的是把“理解客户”“确认业务事实”“决定允许做什么”分给合适的环节。

第一步：让模型认识能力，而不是背下所有流程

当前客户入口暴露两项业务能力：

能力描述不是一句泛泛的“处理退款问题”。它还要说明适用范围和排除范围：个人进度与一般政策怎么分，哪些业务尚未接入，哪些请求需要追问。

入口模型收到的是这份小目录里的能力标识和描述，以及角色化对话、服务端保留的会话状态。目前两项能力的摘要会一起提供，但各自的完整场景、知识正文和工具规则不会跟着一起塞进去。 这仍然是一个明确的小目录路由器，并不是先从海量能力库中进行检索。

模型输出也被限制为候选。以客户明确提到某笔退款为例，一个候选可以这样表达：

{
  "capability": "refund.followup",
  "operation": "new",
  "refundId": "RF310",
  "evidence": "RF310 的退款怎么还没到账"
}

这是字段形态示意。它表达“客户可能想做什么”，不表示已经查过退款，更不表示有权创建工单。

模型不会返回任意场景地址，也不能指定配置版本。服务端检查输出结构和候选范围；给出了引用依据时，检查它是否来自本轮原文；同时检查对象是否来自本轮明确输入或可沿用的已确认会话状态。随后还要核实当前身份与对象归属。

问候、情绪表达、目标不明确和暂不支持的业务，也有各自的出口。让客户澄清不是另一个退款策略；普通回应也不需要装配一套退款执行流程。

第二步：由服务端把能力绑定到明确版本

选出能力之后，系统还不能直接执行。能力是一项对客服务，场景配置则定义这项服务如何运行，两者之间需要一层受控映射。

当前目录中的映射是显式定义的：

入口模型只看到前一节的标识与描述，这张表里的场景和版本由服务端持有。后端根据映射，从配置历史中精确取出对应版本，再进入原生运行函数。

这种设计解决了一个很实际的问题：运营人员修改了场景，不代表正在进行的客户会话就应该立刻换规则。连续处理同一能力时，系统保留原有绑定；明确开始新业务时，才重新读取能力目录中的映射。它也不会在指定版本不可用时，悄悄改用“最新的一份”。

当前客户模拟入口的装配主线。节点按职责归纳，服务端检查分布在实际处理代码中；不是独立服务的部署拓扑。

这里的关键分工是：模型帮助选择业务方向，服务端决定具体使用哪份配置。版本不会随着一句自然语言指令变化，客户也不需要理解内部的场景编号。

第三步：按消费者装配，规则不必都经过模型

有了配置，还需要回答一个经常被忽略的问题：这些资料究竟是给谁用的？

在退款跟进链路里，业务模型承担的是事实提取。它从客户消息中提取诉求、约束和缺失信息。退款实际等了多久、属于哪个客户、有无既有工单，则来自服务端业务记录，而不是让模型根据聊天记录补全。

配置里的 Policy 和 Guard 使用这些事实，判断当前状态允许采取什么动作；工作流推进处理状态；工具执行层负责参数契约与业务动作。这条事实提取链路不给模型选择业务工具的权限，工具契约也不作为该次模型调用的可用工具列表。

政策咨询走另一条链路：先根据所选场景限定知识范围，再围绕本轮问题检索。生成回答时使用命中内容，而不是把整个场景库的知识都塞进上下文。当前本地检索还按生效时间筛选资料版本，并记录候选、排序与命中内容，便于追溯答案依据。

按当前两类业务链路区分信息消费者。按需装配既包含模型上下文，也包含模型之外的执行配置。

所以，同一个平台中会有不同的模型调用契约：入口模型理解业务方向，退款模型提取事实，政策回答模型组织有资料依据的答复。它们不是三个可以随意相互授权的角色，而是运行链路中职责受限的环节。

装配时，系统还会记录组件来源、版本、内容摘要与实际消费位置。例如，策略标记为在模型外使用；当前无需知识检索时，知识组件标记为不纳入；业务模型的对话输入按运行配置保留最近若干轮，并限制单轮长度。这些记录使“本次用了什么”可以检查，而不只存在于一段难以拆解的 Prompt 中。

用一次退款跟进把它连起来

假设当前模拟客户已经有一笔退款，状态是处理中，等待十天，正常业务时限为七天。客户问：“我的退款怎么还没到账？”

入口先判断这是个人退款跟进，而不是询问一般退款政策。服务端随后在当前客户名下确认退款对象：只有一笔时可以明确选择；有多笔时需要客户指出具体对象；其他客户的单号不能直接用来运行。

确认对象后，refund.followup 绑定到退款处理场景的明确版本。本轮对话进入事实提取环节，而十天、七天、是否已有异常工单等业务事实留在运行时使用。

接下来才轮到策略判断：

• 尚在正常时限内，按已核实的状态解释进度。
• 已经超时且没有异常工单，满足执行条件后进入异常建单路径。
• 已有异常工单，沿用已有处理信息，不再重复创建。

客户看到的是处理结果的说明，运营侧同时保留这次运行的配置、判断与工具回执。创建异常工单意味着问题进入跟进流程，不等于退款已经到账。

如果客户改问“生鲜拆封以后还能退吗”，入口转向政策咨询，使用该能力的知识范围，不读取个人退款记录，也不创建异常工单。表面上仍是一个聊天窗口，内部实际采用的信息和权限已经不同。

这正是按需装配的作用：让不同诉求进入不同的业务处理方式，同时保留一致的客户交互入口。

退款跟进的多轮对话：延续对象，也保留停止状态

“现在有人跟进了吗？”可能没有单号，也没有“退款”两个字，但在已经确认退款对象的会话里，它仍然是一条业务追问。

系统会保存当前能力、已确认退款对象和停止状态。正常追加的后续消息可以沿用这些状态；本轮明确指出新对象时，则重新确认对象来源与归属。客户端历史回复中的一个单号，不能仅因为出现在聊天里就获得执行资格。

会话版本也需要区分。工作台允许编辑消息，用来构造另一种客户表达；编辑后的历史被视为新分支，不继承原会话选择。但是，之前已经发生的业务动作仍然存在，编辑对话不会撤销工单。

同样，客户说“先别处理了”，系统需要保留停止状态。普通问候不会自动恢复业务处理；再次发起处理需要明确请求。停止新的处理与撤回已经存在的工单，是两个不同的业务动作。

这些约束让装配具有连续性，也有明确的重新选择条件。保留上下文不是永久锁定旧话题，切换话题也不是清空所有已经发生的业务事实。

为什么选择这种组合

这套方案可以概括为：小型能力目录负责选择，服务端负责绑定，业务运行时负责执行。

我考虑的重点不是把每项能力都做成独立 Agent，而是让知识咨询与业务办理拥有清楚的边界。当前能力范围较小，显式目录便于审阅，也方便说明新增能力需要准备哪些资产。

几种常见设计方向各有用途：

Anthropic 在《Building effective agents》中将 Routing 描述为先分类输入，再交给专门的后续任务，并以不同客服请求进入不同流程为例。这个模式与本文的入口划分相近；我们进一步把配置绑定和执行权限放在服务端，而不让分类结果本身承担授权职责。原文：Workflow: Routing

这里也存在明确取舍：增加入口路由会多一个模型处理环节；能力摘要写得含糊，会影响后续选择；目录显式维护也意味着新能力不会自动从配置库里冒出来。新增能力时，需要同时定义适用范围、配置绑定、身份与对象要求、可用资源和结果表达。

如果以后能力多到小目录难以直接区分，再考虑分层目录或先检索候选能力。那是目录规模变化后的扩展方向，不影响当前“模型提候选、服务端定配置”的职责划分。

它给质量运营工作台带来的价值

AgentOne 的核心仍是客服质量运营：把业务要求、运行过程和处理结果联系起来。客户模拟入口的作用，是让这些配置能从一段自然对话进入，而不是要求使用者事先知道该选择哪个场景。

入口并没有复制一套退款逻辑。选定能力之后，它调用平台已有的原生业务运行，因此场景页与客户对话可以共用策略、执行保护和运行证据。同一份配置既描述预期处理，也能成为实际运行的依据。

质量治理也因此向执行之前延伸：除了检查最后做了什么，还能检查为什么进入这项能力、采用了哪个版本。

例如，客户咨询一般政策，却进入个人退款查询，偏差已经发生在能力选择阶段；能力选对但业务对象绑定错误，需要检查身份和对象来源；工具执行失败则继续看执行回执。不同位置对应不同调整对象，不必一律从修改回答 Prompt 开始。

当前实现覆盖客户模拟入口与平台内部运行，身份和下游退款数据使用模拟记录，绑定的 revision 也是模拟入口的显式选择。正式接入需要将身份验证、发布准入、业务查询和动作提交接到实际系统；本文讨论的能力与运行契约可以保留。

对我来说，动态装配最有价值的地方，是让自然语言入口与业务规则之间有一层清楚、可维护的连接：客户不需要理解场景，模型不需要掌握全部规则，而系统仍然知道这一轮用了什么、为什么能做、最后做到了哪里。