人格叠加（Persona Overlays）：当一个智能体需要为不同客户群提供多种声音时

一家世界 500 强公司的采购主管打开了你的支持智能体，询问为什么 SOC 2 报告中提到的某个合规控制项在你的产品中已不再执行。你的智能体用对待免费版个人用户的语气回答了她——带着三个感叹号、一个表情符号，以及一个“联系我们团队”的愉快建议，既没有升级路径，也没有引用出处。采购主管把这张截图转发给了她的首席信息安全官（CISO），只写了一行字：“这就是他们派来处理我们合规问题的东西。”你失去了续约机会，不是因为答案错了，而是因为语气在那个场合不对。

大多数团队之所以只发布一种智能体人格面具，是因为组织架构中只有一个支持团队。然而，客户群体很少是单一的。企业买家期望正式感、引用来源和明确的人员升级路径。自助服务用户想要快速回答和零摩擦。开发者想要代码，而不是长篇大论。单一的人格面具在某些群体看来是居高临下的，而在另一些群体看来则是不专业的。而“让用户选择语气”则是将一个本不该由用户承担的产品决策推卸给了用户。

通过创建 N 个分支智能体（每个客群一个）来解决这个问题的本能是可以理解的，但几乎总是错误的。你最终会得到 N 个逐渐偏离的系统提示词，N 套维护不善的评估套件，以及每当关键的安全指令发生变化时，都必须在 N 个地方重新粘贴。正确的架构是将人格面具视为基础智能体之上的一个薄薄的叠加层（Overlay），而不是一个分叉。客群信号随请求一起到达，人格面具在请求时被选中。基础行为——包括工具、检索、拒绝逻辑、升级规则——保持在一处，只有体现语气的表面层发生变化。

人格面具是产品表面，而非系统提示词里的注释

第一个观念转变是：人格面具是一个产品表面。它理应获得与延迟预算、错误状态和定价层级同等的待遇：它应该是可观测、可配置、可进行 A/B 测试的，并由专人负责。如今，大多数团队将人格面具视为系统提示词中的一段注释块，谁上周写了智能体谁就随手写点自己的见解。这就是为什么你最终会得到一个“友好、专业、简洁但又详尽的助手”——这样一句话毫无意义，因为没有人把权衡取舍明确化。

有两种生产模式让情况变得更糟。第一种是团队在整个用户群中对两种语气进行 A/B 测试，根据微小的 CSAT 增量挑选胜者，然后发布一个对两个客群来说都很陌生的智能体——平均而言比两个都好，但对任何一个具体的客群来说都比原本合适的那个差。第二种是团队在设置中提供一个“调整语气”的开关，几乎没人会发现它，而且这种做法将架构上的失败泄露到了用户的 UX 中。这两种模式的根源是一样的：将语气视为一维的偏好，而不是取决于“谁在问”以及“他们在问什么”的函数。

作为产品表面，一个人格面具至少有四个值得显式跟踪的维度：

• 正式程度 (Formality) —— 智能体如何称呼用户，是否使用缩写，是否出现表情符号。
• 密度 (Density) —— 智能体在每个回答中提供多少上下文（引用深度、警示说明、替代方案）。
• 主动性 (Initiative) —— 智能体建议下一步操作、提出升级或推荐人工跟进的频率。
• 对歧义的容忍度 (Tolerance for ambiguity) —— 智能体是询问澄清问题，还是做一个最佳猜测并直接继续。

两个客群可能想要同样的答案，但在这些维度上却有着完全不同的设置。企业安全审计员希望高正式程度、高密度、低主动性（他们会告诉你下一步做什么）以及零歧义容忍（请询问）。第一次调用你 API 的开发者则希望低正式程度、低密度、高主动性（“这是 curl 命令，这是查找密钥的地方”）以及高歧义容忍（猜个答案给我就行）。“平均”的人格面具无法同时服务好这两者。

叠加层架构：一个大脑，多种皮肤

最简洁的实现模式是一个基础智能体，并在请求时应用仅针对人格面具的叠加层差异。基础智能体拥有在不同客群之间绝不应有所不同的所有内容：工具清单、检索策略、拒绝规则、升级逻辑和评估规范。叠加层只拥有应该有所不同的部分：上述四个维度，以及一些特定客群的开场和结尾惯例。

在实践中，这意味着系统提示词是在请求时由基础模板加上一个人格面具片段组成的。人格面具片段是一个小的结构化对象——有时是一个带有四个维度值的 JSON 对象，有时是一段精心编写的风格说明——它会根据入站请求中的客群信号进行解析。客群信号本身来源于你已知的信息：账户等级、合同类型、请求发起的页面（应用内聊天 vs 开发者门户 vs 合作伙伴集成），或者在缺乏这些信息时，根据用户的第一轮对话进行轻量级分类。

这里有几条非常有价值的架构规则。保持人格面具片段短小——建议限制在 150 个 token 以内——因为系统提示词中的每个 token 都是你每轮对话需要支付的成本，也是一个可能导致模型行为产生意外偏差的因素。将人格面具片段与基础提示词分开进行版本管理，这样你就可以在不重新测试工具的情况下滚动语气更改。至关重要的一点是，不要让人格面具片段覆盖基础智能体的安全规则。叠加层设置的是语气，而不是政策。如果一个客群需要不同的政策——不同的数据访问权限、不同的拒绝行为——那就不再是人格面具的差异，而是一个不同的智能体，它理应拥有自己的部署。

这种分离在第一次需要更改通用设置时就会带来回报。例如，一项新的合规要求出台，要求智能体在涉及客户数据的任何主张时必须引用来源。你只需要更改基础模板中的一行代码。如果这行代码之前被复制到了 N 个分支智能体中，你可能半夜 11 点还在查提交记录，试图搞清楚哪些分支已经改了，哪些还在回答没有出处的答案。

分群检测：你已拥有的信号

画像路由中最常见的失败不在于路由本身，而在于分群检测（Cohort Detection）。团队往往过度设计分类器，却低估了请求中自带的信号。

对于已认证用户，分群几乎总是可以从现有数据中推导出来：合同等级、MRR 区间、行业、注册来源、用户在入职引导时选择的角色。将这些信息拉入请求上下文只需要五分钟的改动，就能解决 95% 的问题。有趣的地方在于匿名流量和边缘情况：一个实际上代表企业买家进行评估的免费版用户，或者一个为了个人项目创建账号、现在却在公司内部进行集成的开发者。对于这些情况，在第一轮对话中使用轻量级的意图分类器就能捕捉到大多数误路由——诸如“我们的安全团队”、“为了我们的合规审查”或“采购部门需要”等短语，几乎是完美的信号，预示着如果此时使用随意的画像（casual persona）将会产生糟糕的结果。

一个实用的战术模式：让分群检测在会话内保持粘性，但在会话开始时可重新评估。你不希望 Agent 在对话中途改变语调，仅仅因为用户的第三条消息比第二条更正式。你也不希望六个月前的分群分配左右今天的语气，如果双方的关系已经发生了变化。每个会话计算一次分群，将其存储在对话记录中，并在会话结束时失效。会话内的漂移是突兀的；跨会话的漂移则是正确的。

还有一个值得借鉴的模式：当拿不准时，偏向正式。对随意型用户表现得过于专业，代价只是听起来有点刻板；而对企业买家表现得过于随意，代价可能是丢掉订单。这种失败模式的不对称性应该让你的默认设置产生偏向。

按画像进行评估切片，否则你就是在盲目飞行

在这种架构中，最被低估的纪律就是按画像进行评估切片（Eval Slicing）。原因是统计学上的：如果你的评估报告只显示一个聚合质量得分，那么在大分群上的 4 分提升可能会完全掩盖在小分群上的 6 分退步。切片分析能捕捉到影响一小部分但敏感群体的回归（regressions）——而这些更小、更敏感的群体通常是合同价值更高的群体。聚合评估针对中位数用户进行优化，却会默默地让那些为你买单的离群用户体验倒退。

其机制并不复杂。每个评估案例都会贴上其应所属画像的标签。评估框架在评分前应用相应的覆盖层（overlay）。仪表盘会显示每个画像的质量列以及聚合得分。如果任何画像切片的下降超过配置的阈值，即使聚合得分持平或上升，也会触发回归门控（regression gate）。如果你期望每个切片的通过率约为 80%，并希望在 95% 置信度下有 5% 的误差幅度，请为每个画像准备大约 250 个案例——称之为“切片预算”。少于这个数，你报告的就是噪声。

有两个特定的评估维度对画像工作至关重要。语气稳定性（Tone stability） 衡量 Agent 的声音在会话内是否保持一致——一个有效的测试是在第 5 条消息和第 20 条消息处注入随意或正式的用户话术，检查 Agent 的回复语域（register）偏移是否超过了控制范围。跨画像污染（Cross-persona contamination） 衡量画像覆盖层是否泄露到了本应与画像无关的输出中，例如结构化数据返回或工具调用参数。一个 Agent 仅仅因为随意画像渗入了 JSON 字段，就将 "status": "ok" 返回成 "status": "all good 👍"，这是一个真实且代价高昂的 Bug。

如果团队在没有切片级评估的情况下发布画像覆盖层，最终会发布一个让一部分人群惊喜、却默默地将另一部分人群推向竞争对手的回归。而发布切片级评估的团队，在 CI 阶段就能发现这种漂移，甚至在它触达客户之前。

语气稳定性是一项契约，而非愿望

最后一部分是会话内的语气稳定性契约。一旦用户听到了 Agent 以某种声音说话，在接下来的对话中，他们听到的就应该是那个声音——即使对话转向了另一个分群本该被路由到的主题。对话中途语域的转变是令人不安的：这会破坏用户对“正在对话的对象”建立的心理模型。

漂移通常不是故意的失败，而是结构性的失败。随着对话的增长，系统提示词（system prompt）中的画像指令会因为回合的积累而被推离模型的注意力中心。Agent 会逐渐退回到其基础训练分布——通常是一个略显轻快、略显啰嗦的折中状态——而不管最初应用了哪个覆盖层。解决方法是让画像提醒紧贴模型的最新注意力：在每一轮的上下文窗口前置一个简短的画像提醒，或者在系统提示词中使用结构化区块，在压缩对话历史时对其进行重新总结。

一个实用的“双重保险”模式是在 Agent 的回复返回之前运行一个轻量级的语气分类器。如果回复的语气得分偏离画像目标画像的程度超过了配置的增量，你就使用更强的画像提醒重新生成。在最坏的情况下，这会消耗额外的 Token 和几百毫秒，但它能捕捉到画像提示词本身无法防止的长尾漂移。对于高价值分群——企业、受监管行业、升级后的工单——与一次不匹配的回复所带来的成本相比，这点代价微不足道。

组织层面的感悟

如果一个团队不把性格（personality）作为一个可配置的维度，那么他们就是在向多元化的受众交付一个语调单一的产品，而由此产生的成本正在悄然叠加。续约谈判变得越来越困难。在那些被“平均化优化”所牺牲的受众群体中，NPS 开始下降。销售团队开始在内部 Slack 上发消息说：“这个 agent 对中小企业（SMB）来说还行，但请千万别把它展示给大企业客户。”这一切都不会体现在 agent 自身的指标中，因为 agent 的指标衡量的是它在执行既定任务时的表现，而不是它在满足客户实际需求方面的表现。

人格叠加（Persona overlays）并非一种语调把戏。它代表了一种认知：即同样的答案，如果用错误的口吻传达，就变成了一个完全不同的答案。将人格视为一个产品层面——它是可控的、可观测的、在评估（evals）中被分层的、在会话中保持稳定的，并且与策略（policy）清晰分离——这样，一个 agent 就能比 N 个分支出来的 agent 更好地服务于每一个群体。忽略这项工作，你最终还是会以另一个名字重新构建它，尤其是在第一个大企业客户把截图发给他们的 CISO 之后。