同一个客户收到两封像两家公司写的邮件：Agent 的提示词副本在漂移

一家公司的销售和客户成功团队，给各自搭的 Agent 都接了同一份客户历史。历史数据由 Computer by DevRev 维护，和 HubSpot、Gmail、Slack 同步，通过 MCP 读取。MCP 可以简单理解成一种让模型按协议读取外部数据的接口。这个设计运行正常：两个 Agent 写同一个客户时，看到的邮件和交易记录一致。

问题出在写作提示词。每个 Agent 的系统提示里都贴了同一段规则，不到 120 个词，要求用名字称呼客户，提到对方最近在用什么，客户不问就不报价，后面还附了两条旧的续约邮件当示例。到 9 月，这段东西已经有三个版本。

客户成功经理把自己发过的、语气更暖的邮件换进了其中一个副本。规则没改，草稿却变得更爱聊天。发帖人的判断是，示例对语气的牵引比规则更强。另一个销售给临近续约的客户做了回访 Agent，从旧版本里复制了那段规则，里面还留着“写上当前套餐和价格”。这句话之前因为客户抱怨回访读起来像账单，已经被删过，但只删在一个副本里。发帖人给自己的 Agent 加“建议下一条消息”时，干脆重写了一遍，因为他分不清哪份是当前版本。

上个月，一个客户在同一周收到了续约邮件和回访邮件。事实对得上，因为两个 Agent 读的是同一份历史。语气对不上：续约邮件是三段温暖的话，回访邮件很正式，还引用了价格。看起来像两家公司写的。没人能说哪版才对，因为每份副本都没记录某条规则为什么存在。

他们后来把这段规则挪进一个共享文档。能缓解，但只要有人改了提示词又忘了贴回去，副本还是会分叉。客户历史那层稳，是因为只有一份，Agent 实时读取。文档没人实时读。每个 Agent 跑的还是最后一次被粘贴进去的内容。

有网友的做法是用一个共享的提示词注册表，简单 JSON 文件，放 Git 里版本化，再通过中心 API 同步给 Agent。对方说这套东西管着 12 个 Agent，没有漂移，也没有复制粘贴。

另一个跟帖把重点放在示例上。示例换掉之后，语气跟着变，说明示例本身就是规格。共享规则之外，示例也该版本化，还要写清楚每个示例为什么放在那里，比如“展示一条不报价的简短续约回访”。这位网友还给了三个小办法：在规则块顶部写版本行，比如 style v4, 2026-11-02，让 Agent 在隐藏字段或日志里回显；把删掉的规则放进一个简短的“我们不再这样做，因为……”清单；保留一个固定的测试输入，比如一个假的续约客户，每次改完都让所有副本跑一遍，草稿读起来不一样就说明有副本漂了。

还有人问得更直接：既然已经在运行时通过协议拉上下文，为什么不用同一条管道下发写作规范。销售可以改自己的任务指令，品牌语气由中心注入，避免被顺手 fork。

这件事和模型能力关系不大，更像配置管理。数据层共享，不代表指令层也共享；事实一致，不代表输出一致。多个 Agent 面向同一批客户写东西时，运行时注入最省事。做不到，至少让副本可追溯：版本号、变更原因、固定测试输入。还有一个问题得提前定，谁有权改这些规则。

原帖：Our agents share one account history but each runs its own copy of the writing prompt, and the copies drifted