《反谄媚：五行规则》读书笔记

1. 主文章在讲什么（30 秒）

一句话主线：在多智能体系统里，LLM 的 RLHF 训练让所有 agent 都倾向于附和；五行规则（禁用谄媚短语 + 强制反对 + “什么会改变我的立场”）反转这个倾向，把”和稀泥的合唱”变成”有真分歧的审议”。

反对什么观点：

• 反对”多 agent 自然会有不同视角”——他们会塌缩到同一个声音
• 反对”加 persona 描述就够了”——RLHF 会压过 persona 设定
• 反对”调 temperature 能解决”——这是训练问题不是采样问题

如果只能记一句话：

谄媚不是 prompt 的问题，是模型训练的副作用；五行 prompt 纪律是绕过训练的工程方案。

2. 关键概念词典

谄媚的三种表现（容易混的）

RLHF vs Constitutional AI vs 反谄媚规则（容易混的）

关键区分：前两个是模型层方案，用户控制不了。反谄媚规则是运行时方案，用户每次会话都能调。这两层是互补的，不是替代关系。

Persona / Specialist / 反谄媚规则的关系

3. 完整脉络（主文章每节展开）

为什么是 RLHF 的”训练副作用”

RLHF 的目标函数大致是：“让人类标注者觉得这个回答好”。人类标注者统计上更喜欢：

• 礼貌的语气
• 不冲突的措辞
• 同意而不是反对
• 给替代方案而不是判定错误

模型在训练中学到：这些行为得分高。

副作用是：当你在 prompt 里给一个 persona 定义”你是个挑剔的架构师”，模型仍然倾向回到”礼貌不冲突”的中位数行为。persona 描述被 RLHF 训练梯度压过去了。

这不是 prompt engineering 不够强，是训练梯度和你的指令在拉锯。

为什么禁用短语会有效

LLM 的生成是自回归 + softmax 选下一个 token。禁用短语相当于在生成时把这些 token 路径的概率拉低。

模型不能说”看起来很好”——这条路径被堵了。它必须找另一条路径。另一条路径要求模型实际有内容——因为如果没内容，“看起来很好”是最便宜的填充。

为什么”必须有反对”反转梯度

默认情况：附和的成本最低（短、礼貌、生成概率高）。 加规则后：附和违反规则——成本是”被拒收”。

模型选择路径时：附和路径 = 一定违反 → 必然失败 → 选反对路径。

这不是说服，是经济学。模型走最低成本路径，规则把”附和”那条路径的成本拉成无限大。

为什么”什么会改变立场”是关键

没有这一段，反谄媚规则可能让 agent 僵化反对——为了反对而反对。

加上”什么证据会让我改变立场”：

• agent 必须给出可证伪的承诺
• 用户提供这个证据时，agent 必须改变（否则违反自己的规则）
• 整个交互变成真正的论辩——双方有立场、有可改变的条件

4. 真实代码 / 数据

完整的反谄媚规则（架构师 persona）

# 架构师

> 系统设计者。先画全景，再看细节。

## 思维模式
- 先问边界
- 关注耦合
- 可逆性优先
- 画图说话
- 质疑规模假设

## 反谄媚规则
- 禁止说："这个设计很好"、"架构很合理"、"没什么问题"、
  "我同意"、"那是个公平的观点"
- 必须做：每次发言至少指出一个架构风险或设计取舍
- 如果真的没问题：说明自己检查了哪些维度，而不是笼统说"没问题"

## 什么证据会让我改变立场
- 实际运行数据表明当前架构在目标规模下表现良好 → 放弃重构建议
- 团队规模和交付压力证明简单方案的维护成本更低 → 接受不优雅方案
- 用户反馈表明架构层面的改进对体验没有可感知的影响 → 重新排列优先级

## 盲点
- 容易过度设计
- 对用户需求的理解偏技术化

真实的 before / after 笔录片段

Before（没规则）：

PM: 我建议我们用 LangGraph 做编排。
架构师: 这是个不错的选择，LangGraph 在生产中很成熟。
未来学家: 同意，而且 LangSmith 给我们 trace。
PM: 那我们就这么定了。
（4 轮内 3 个 agent 全部同意，没有真正的讨论）

After（加了规则）：

PM: 我建议我们用 LangGraph 做编排。
架构师: 我有一个关切——LangGraph 是 LangChain 系，引入它意味着接受
       LangChain 的整套抽象，未来想换会很贵。我们对 LangChain 抽象
       的需求有多刚？
未来学家: 我也想推回去——LangGraph 解决我们的第 3 层问题，但留下
         第 1、2、4、5 层。引入它会不会让我们对"我已经解决了"
         有错觉？
PM: ...好，那我们再想想。
（4 轮内有真分歧，决策被推迟，但后来证明这个推迟是对的）

数据点：反谄媚规则部署前后

我观察到的（茶会自己的圆桌系统，约 6 周）：

• 没规则时：典型圆桌 5-7 轮内 100% 共识。讨论笔录有 80% 是附和填充。
• 有规则时：典型圆桌每场至少有 1 个明确分歧，最后归档为”待验证”或”分歧”，不强求共识。讨论笔录有 80% 是实质内容。

这些不是严格 benchmark，是主观观察——我没做对照实验。但差异是肉眼可见的，不是模糊的。

5. 架构图

图 1：RLHF 训练梯度 vs persona 设定的拉锯

   Persona 设定                   RLHF 训练梯度
   "你是挑剔的架构师"              "礼貌、不冲突、同意"
        │                                │
        ↓                                ↓
   ┌────────────────────────────────────────┐
   │     模型生成下一个 token 时的拉锯        │
   │                                          │
   │  persona 推力：表态、批评                  │
   │  RLHF 推力：礼貌、附和                    │
   │                                          │
   │  RLHF 推力 ≫ persona 推力                │
   └────────────────────────────────────────┘
        │
        ↓
    输出：附和（persona 描述被压过）

图 2：加了反谄媚规则后的反转

   Persona 设定                   RLHF 倾向
   + 反谄媚规则                    "礼貌、附和"
                                          │
   "禁用：'看起来很好'..."                  ↓
   "必须：指出风险"              ┌──────────────┐
        │                          │  附和路径     │
        │                          │  → 违反规则   │
        ↓                          │  → 拒收      │
   ┌──────────────────────┐     └──────────────┘
   │   生成时，附和路径被堵 │
   │   模型必须找另一条路径  │
   └──────────────────────┘
        │
        ↓
    输出：实质内容 + 表态

图 3：反谄媚 + 可证伪 = 论辩

            纯反谄媚                    反谄媚 + 可证伪
   "禁止同意"                      "禁止同意 + 列出改变立场的证据"
        │                                  │
        ↓                                  ↓
    Agent 抬杠                         Agent 立场
    (反对一切)                         (清晰条件)
        │                                  │
   用户：你为什么反对？              用户：那这个数据呢？
        │                                  │
   Agent: 就是要反对                  Agent: 这正是改变我立场的
                                            条件 → 改变立场
        │                                  │
        ↓                                  ↓
    无效讨论                           论辩闭环

6. 我的批注

我和我以前的想法的冲突

以前：我以为 multi-agent 系统的多视角是默认就有的——给每个 agent 不同的 persona 描述就行。 现在：persona 描述会被 RLHF 训练梯度压过去；没有反谄媚规则的 multi-agent 是单声合唱。

以前：我觉得”反谄媚”听起来像让 agent 变”坏脾气”。 现在：禁用谄媚填充后，模型默认值不是”无礼”，而是”实质”。一个不能说”看起来很好”的 agent 默认会说”我注意到 X”——这才是资深工程师默认的语气。

以前：我以为 prompt engineering 已经探索完了所有套路。 现在：反谄媚规则是 prompt 层一个未被广泛使用的杠杆——五行字改变多 agent 系统质量。

反复想过的部分

为什么 5 行而不是 50 行——一个 persona 的整体描述长度是有上下文预算的。规则越长，挤占视角描述的空间越多。5 行是经验上的甜蜜点：足够强制行为，又不淹没 persona 本身。

为什么不能让 LLM 自己写反谄媚规则——我试过让 GPT/Claude “为这个 persona 写反谄媚规则”，它写出来的规则自己就是谄媚的（“友好地指出…”）。规则必须人类硬写，因为它是反训练梯度的，模型自己写不对。

为什么对 Specialist 不加——Specialist 的工作是交付物件。“必须给反对意见”在 Specialist 上下文里没意义——它的”反对”应该是质量门拒收，不是口头反对。

下次会改的

• 测量更严——目前我说的 “before 100% 共识、after 至少 1 分歧”是主观观察。下一步应该跑对照实验：同一议题、同一阵容，A/B 跑加规则和不加规则。
• 规则的可调档——不是所有圆桌都需要最强反谄媚。技术决策需要尖锐对峙，产品讨论可能需要温和。应该有 tone parameter：strict / balanced / soft。
• 跨语言——目前规则是英文写的（我系统是中英混的）。中文里”附和填充”的具体短语和英文不同（“挺好的”、“可以”、“不错”），需要单独列。

7. 面试话术（按时长背三档）

30 秒电梯版

2 分钟白板版

10 分钟深入版

8. 可能被问到的 5 个问题 + 回应

问题 1：为什么不直接用 Constitutional AI 这种训练层方案？

回应：

Constitutional AI 是模型实验室在训练阶段加约束——用户（开发者）控制不了。我做应用，需要的是运行时可调的方案。两个层是互补的：模型层是”开箱即用的善良”，运行时层是”按场景调整的纪律”。

而且 Constitutional AI 解决的是”模型说危险话”，不是”模型在多 agent 讨论里附和”——后者需要框架/prompt 层的工作。

问题 2：禁用一些短语真的能改变模型行为吗？听起来像迷信。

回应：

实际上有理论基础。LLM 是自回归 + softmax 在词表上选下一个 token。如果在 prompt 里说”禁止用 X 短语”，模型在生成时会主动避开产生该短语的潜在方向——这是 RLHF 训练的”指令遵循”能力的一部分。

反过来想：最让人意外的是这一招居然没被广泛使用。整个 prompt engineering 社区花了三年讨论 “few-shot examples”、“chain of thought”、“role-playing”，但禁令式的反向 prompt 是个被低估的杠杆。

验证方法很简单：在你的 multi-agent 系统里加上这五行，跑 5 场圆桌，对比。如果差异不肉眼可见，我错了。

问题 3：加了规则不会让 agent 变得不可用地粗鲁吗？

回应：

这正是我以前的担心，也是为什么我提出来时被反驳过几次。结果是没有——禁用谄媚填充后的默认值不是”这是个糟糕的设计”（粗鲁），而是”这个设计假设 X，需求里有 Y 的反例”（精确）。

原因：粗鲁需要主动模型选择”批评”的方向，但 RLHF 训练里”批评”和”附和”一样都被推到中位数。模型默认走的不是”批评”，是”指出 + 给条件”——这是更资深的语气。

规则不是教模型粗鲁，是关掉模型的”初级礼貌路径”——剩下的就是资深路径。

问题 4：你怎么验证规则确实改变了行为？有 benchmark 吗？

回应：

诚实说：我没有严格 benchmark。我观察到的是主观对比：

• 没规则时，圆桌 5-7 轮内 100% 共识，笔录 80% 是附和填充
• 有规则时，每场圆桌至少有 1 个明确分歧，笔录 80% 是实质内容

这是肉眼可见的差异，但我没做对照实验。这是我自己的下一步——同一议题、同一阵容、A/B 跑加规则和不加规则，让第三方 reviewer 盲评讨论质量。

在那之前，这是经验性方法，不是科学验证的方法。我不会装它经过严格证明。

问题 5：这能用在生产 AI 产品上吗？还是只对你自己的研究系统有用？

回应：

任何有多 agent 讨论的产品都能用。具体场景：

• AI 教练 / 咨询：教练 persona + 反谄媚 = 不取悦用户的真教练
• 产品决策 AI：多 persona 圆桌 + 反谄媚 = 真正的多视角而不是合唱
• 代码 review AI：reviewer persona + 反谄媚 = 不放水的 code review

不适合的场景：用户是孤独需要陪伴的（比如老人 AI 陪伴），那种场景里”附和”恰恰是产品价值。

五行字的工程成本几乎为零。唯一阻碍是产品经理担心用户不喜欢”被反对”——这通常是错的产品判断，但需要数据说服。

9. 相关链接

内部（其他主文章）

• Persona–Specialist 的分离 — 反谄媚规则只加在 Persona 上的原因
• Five Layers of an Agent System — 这套规则在第 2 层（Agents）
• The 2026 Agent Framework Landscape — 业界框架为什么没有内置这个
• Coach Who Doesn’t Flatter — 在产品层面把”不取悦”作为承诺

外部参考

• Constitutional AI (Anthropic, 2022) — 训练层的相关方法
• Sycophancy in RLHF Models (Anthropic, 2023) — 谄媚问题的实证研究

相关概念

• Constitutional AI ≈ 训练层的反谄媚（不是用户可调）
• Adversarial Persona Prompting ≈ 学术界的相关探索
• Debate / Devil’s Advocate ≈ 传统组织管理里的反谄媚机制