人格叠加（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 点还在查提交记录，试图搞清楚哪些分支已经改了，哪些还在回答没有出处的答案。

加载中…