考察点
这是场景设计题，面试官通常会给具体情境：「我们有个客服 bot，售前要像销售一样热情推品，售后要冷静安抚走流程，怎么设计？」想考察的是候选人在「一个 Prompt 写多个角色」「路由分流到多个 Prompt」「多 Agent 协作」三种方案间的取舍能力，以及对角色混乱、风格串味这些实际坑的认知。
参考答案
三种方案，按复杂度选
方案一：单 Prompt 内分角色。 在一个 System Prompt 里描述多个角色及触发条件：「当用户咨询价格时，以售前顾问身份回复……当用户投诉时，以售后专员身份回复……」。优点是简单，一次调用搞定，上下文天然共享；缺点是角色多了之后指令互相干扰，风格容易串——售后安抚的语气混进售前话术里。经验上限是三四个界限分明的角色，再多必乱。
方案二：意图路由 + 多 System Prompt。 前置一个轻量分类器（小模型或 LLM 分类调用），判断当前会话属于售前还是售后，路由到对应角色专属的 System Prompt。每个角色的 Prompt 独立维护、独立评测，风格边界干净。这是生产上最常用的形态。工程细节：路由判断要基于整段对话历史而不是单句，否则用户一句「刚才说的那个价格太贵了我要退」会被切错；切换角色时把对话历史带过去，但要在 System Prompt 里声明「你现在是售后角色，之前的售前承诺仅供参考」，避免新角色被旧角色的语气带跑。
方案三：多 Agent。 每个角色是独立 Agent，有各自的工具集和记忆，由编排层调度。售前 Agent 能查库存和优惠，售后 Agent 能查订单和建工单。当角色之间能力边界清晰、工具权限不同、甚至需要不同的安全策略时，才值得上这套。为「语气不同」上多 Agent 是过度设计——Anthropic 自己都提醒不要过早引入多智能体，复杂度和 token 成本都翻倍。
以客服+运营双角色为例的设计要点
假设场景：一个社群 bot，平时是客服（答用户问题），运营还要让它定时发活动推送。
- 人设卡分开写：每个角色一张人设卡——身份、目标、语气、禁区。客服角色禁区写「不主动推销」；运营角色禁区写「推送每天不超过 2 次」。人设卡就是 System Prompt 的核心段落，版本化管理。
- 工具按角色授权：客服角色只挂知识库查询；运营角色挂推送接口，且推送接口在代码层做频率限制和审批。角色的能力边界靠工具授权实现，不靠 Prompt 里写「你不要用」。
- 切换要有用户感知：角色切换时在回复里自然体现（「这个问题我帮您转售后专员处理」之类），用户能感受到连贯性，后台日志也能记录切换轨迹便于排查。
- 评测按角色分开：客服角色测问题解决率和话术合规，运营角色测推送打开率和退订率，两套指标两套评测集，混在一起测不出问题。
常见坑
最常见的翻车是人格混叠：多角色共用一个 Prompt 时，模型在长对话后期逐渐忘掉角色设定，语气向通用助手回归。对策是角色特征在 System Prompt 里用强标记（开头结尾都强调），对话轮次多了周期性重申角色（把角色摘要作为最新一条 system 消息注入）。
可能的追问
- 路由分错了怎么办？ 允许模型侧二次判断——被路由到的角色 Prompt 里写「如果用户意图不属于你的职责，输出 TRANSFER:目标角色」，编排层捕获后重新路由。
- 角色之间要共享记忆吗？ 事实类信息（用户订单、历史问题）共享；过程类信息（售前话术尝试）不必。共享通过外部存储（用户画像表、会话摘要）实现，别指望上下文窗口。
- 什么时候角色该合并？ 两个角色的工具集、知识库、话术风格重合度超过七八成，就合并成一个角色用 Prompt 内的语气开关区分，减少维护面。