《Persona vs Specialist 分离》读书笔记

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

一句话主线：在 Agent 层把”思考的角色”（Persona）和”执行的角色”（Specialist）显式拆开——两者的成功标准、契约格式、调度方式完全不同；混在一起，agent 既不会思考也不会执行。

反对什么观点：

• 反对”加几个 role 就有多视角了”——CrewAI 的失败证明这不够
• 反对”Agent 是同一种基本单位”——这忽略了”产出立场” vs “产出物件”的根本差异
• 反对”反正都是 LLM 调用”——物理一致不重要，契约不一致才重要

如果只能记一句话：

Persona 产出立场，Specialist 产出物件——同一个 LLM 戴两顶帽子，不是同一个角色。

2. 关键概念词典

立场 vs 物件（核心区分）

Persona 的三种 vs Specialist 的三种

我自己用的：

Persona（视角型）：

• 架构师 / PM / 务实工程师 / 未来学家 / 增长 / Steve Jobs / UX 设计师

Specialist（执行型）：

• dev / qa / design / devops / product / marketing / research

三个相关概念的层级（容易混的）

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

为什么”思考”和”执行”需要相反的设计压力

思考的好坏取决于：

• 视角是否独特
• 是否敢于反对（反谄媚）
• 是否承认自己的盲点
• 是否能给出可证伪的承诺

执行的好坏取决于：

• 是否完成验收标准
• 是否符合质量门
• 是否能在指定预算内
• 是否文档可移交

这两组指标互相打架：

• 鼓励”敢反对”会让执行者犹豫不前
• 鼓励”通过质量门”会让思考者跳过批判

所以同一个 agent 同时承担两者 = 用一个工具拧两种相反方向的螺丝。

为什么 CrewAI 的”role-based agents”是混淆

CrewAI 的 mental model：每个 agent 有一个 role（researcher / writer / reviewer），任务在 agent 之间流转。

问题：role 不区分”思考还是执行”。

• “researcher” 是思考还是执行？
• “writer” 是思考（构思）还是执行（写下来）？
• “reviewer” 是思考（提意见）还是执行（出 reject 报告）？

全部既是思考又是执行——CrewAI 的 demo 里每个 agent 都既给意见又写代码。结果：意见浅、代码乱。

正确做法：

• “researcher” 拆成 “research persona（视角）” + “research specialist（综述生成）”
• “writer” 是 Specialist（产出物件）
• “reviewer” 拆成 “review persona（多视角批评）” + “qa specialist（质量门检查）“

为什么 Persona 用 markdown，Specialist 用 YAML

不是任意选择。这两种格式对应不同的本质：

Persona 是 markdown，因为：

• 视角是叙事性的（背景、思维模式、盲点）
• 反谄媚规则是自然语言指令
• 可以用诗化语言描述（“先画全景，再看细节”）
• LLM 读得最自然

Specialist 是 YAML，因为：

• 契约是结构化的（input.required, output, quality）
• 质量门是枚举的（enumerable rules）
• 调度器需要机器可读
• 验证脚本可以读

为什么 Persona 必须独立调用，Specialist 可以并行

Persona 在圆桌里发言，前一个 persona 的发言会污染后一个的视角——所以理想上 persona 应该独立调用（每个 persona 不看到其他的发言，最后由 moderator 综合）。

但这成本高。妥协：让 persona 看到其他 persona 的发言，但加强反谄媚规则强制独立判断。

Specialist 没这个问题——每个 specialist 接到的是独立任务，并行做不冲突。所以 Specialist 可以真正并行（多个 dev 任务、多个 qa 检查）。

我的 sprint 流水线：phase 3（dev 实现）是顺序，phase 4（qa 4 个并行 reviewer）是并行——因为 reviewer 是 specialist，独立检查不冲突。

4. 真实代码 / 数据

一个 Persona 的实际样子（简化版）

# 架构师 (Architect)

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

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

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

## 反谄媚规则
- 禁止说："这个设计很好"
- 必须做：每次发言至少指出一个权衡
- 如果真的没问题：说明检查了哪些维度

## 什么证据会让我改变立场
- 实际运行数据表明架构在目标规模下表现良好 → 放弃重构
- 团队规模数据证明简单方案维护成本更低 → 接受不优雅

一个 Specialist 的实际契约

name: dev
description: 全栈开发 + AI 工程化团队

skills:
  - frontend
  - backend
  - ai
  - database
  - build

input:
  required:
    - task-description
    - acceptance-criteria
    - project-dir
  optional:
    - design-guide
    - tech-stack

output:
  - code-files          # 新增/修改的文件
  - progress-log        # 进度条目
  - case-record         # episodic memory 条目

quality:                # 质量门，违反任一 = 拒收
  - 不允许硬编码色值
  - 不允许占位符内容
  - 不允许假数据
  - 三层（HTML/JS/CSS）必须对齐
  - 必须有空状态兜底

调度的实际差异（伪代码）

# 圆桌：召集 personas
def roundtable(topic):
    personas = load_personas()  # 7 个
    statements = []
    for p in personas:
        # 每个 persona 独立给立场（不看前面的发言效果更好，
        # 但成本高；妥协：看前面的但加强反谄媚）
        statement = call_llm(persona=p, topic=topic)
        statements.append(statement)
    # moderator 综合分歧/共识
    summary = synthesize(statements)
    return summary  # 立场，不是物件

# Sprint：派遣 specialists
def sprint(goal):
    tasks = decompose(goal)
    artifacts = []
    for task in tasks:
        specialist = match_specialist(task)
        artifact = call_specialist(specialist, task)
        # 严格质量门
        if not specialist.quality_check(artifact):
            artifact = retry_with_feedback(task, artifact)
        artifacts.append(artifact)
    return artifacts  # 物件，不是立场

数据点（茶会六周后）

• Personas 总数：7 个（架构师 / PM / 务实工程师 / 未来学家 / 增长 / Steve Jobs / UX 设计师）
• Specialists 总数：7 个团队（dev / qa / design / devops / product / marketing / research）
• 圆桌（用 Personas）：158 场
• Sprint（用 Specialists）：约 12 个（每个产生若干代码 commits）

5. 架构图

图 1：相反的设计压力

      Persona 的指标                Specialist 的指标
  
    "视角是否独特？"                  "是否过质量门？"
    "敢反对吗？"                      "完成验收标准了吗？"
    "承认盲点吗？"                    "在预算内吗？"
    "可证伪吗？"                      "文档可移交吗？"
  
        ↓                                  ↓
    要求开放、不确定                  要求严格、确定
        ↓                                  ↓
        ←──────  互相打架  ──────→
  
    一个 agent 同时承担 = 分裂人格

图 2：Persona 调度 vs Specialist 调度

    Persona 圆桌（顺序，受污染担忧）

    议题
       │
       ↓
    Persona 1 → 立场 1
       │
       ↓ （理想：不让 P2 看到 P1 发言）
       ↓ （妥协：看到 + 加反谄媚）
    Persona 2 → 立场 2
       │
       ↓
    Persona 3 → 立场 3
       │
       ↓
    Moderator 综合（共识 / 分歧 / 待验证）

    Specialist Sprint（并行，独立）

    任务
       │
    ┌──┼──┬──────┬──────┐
    ↓  ↓  ↓      ↓      ↓
   dev qa design devops research  ← 独立任务，并行执行
    │  │  │      │      │
    └──┴──┴──────┴──────┘
       │
       ↓
    汇总（artifacts 集合）

图 3：契约格式对应本质

    Persona                         Specialist
  (markdown)                        (yaml)

    # 架构师                          name: dev
    > 系统设计者...                   skills: [...]
                                      input:
    ## 思维模式                        required: [...]
    - 先问边界                        output: [...]
    - 关注耦合                        quality:
                                       - 不允许 X
    ## 反谄媚                          - 必须 Y
    - 禁止说 X
    - 必须 Y
    
    ## 改变立场的证据
    - 数据 X → 改变 Y
                                      
    诗化、叙事、开放                  结构化、可枚举、严格

6. 我的批注

我和我以前的想法的冲突

以前：我以为 multi-agent 框架（CrewAI、AutoGen）已经解决了”多角色”问题。 现在：它们解决了”多 agent 实例”，没有解决”角色类型”——所有 agent 是同一种类型，只是 prompt 不同。这是个质的差距。

以前：我以为给 agent 加 schema = 上 production 标准。 现在：Schema 必须只加在 Specialist 上。给 Persona 加 schema 反而压抑视角的开放性（schema 强迫结构化输出，结构化输出不擅长论辩）。

以前：我把”agent 之间协作”当成”agent 互相调用”。 现在：Persona 和 Specialist 之间不直接互相调用——Persona 输出的是立场（决策输入），决策由人类（或 skill）做出，决策结果输入给 Specialist 执行。中间的人类/skill 是关键。

反复想过的部分

为什么 designer 的角色难分——一个好的设计师确实是边设计边思考的（“画 = 想”）。这种角色我倾向做成一个 Persona + 一个 Specialist 紧耦合：先 designer persona 给视角（“该走哪个方向”），再 design specialist 出物件（具体设计稿）。两次调用，不混在一次。

为什么 reviewer 不是 persona——表面上 reviewer 是”批判视角”。但生产质量的 reviewer 是 specialist——它的工作是出 reject 报告，不是给视角。视角是为了改变决策，reject 报告是为了改进物件。两者不同。真要做 review persona，让它在决策阶段批 plan 而不是批 artifact。

为什么不能让 persona 调用 tool——技术上可以，但会让 persona 滑向 specialist。一个能调 read_file 的 persona 会开始”基于具体代码反对”——但这就不再是”视角”，而是”具体审查”。视角应该停留在抽象。

下次会改的

• Persona 之间的依赖——目前 persona 互不依赖（独立加载）。但有时一个 persona 应该”基于另一个 persona 的反对”调整自己的立场。应该有 follow-up persona 机制：第二轮发言时给每个 persona 看其他人的立场，强制响应。
• Specialist 之间的 handoff——目前 specialist 之间是 sprint phase 之间的顺序调度，没有 dynamic handoff。OpenAI Agents SDK 的 handoff 模式可以借鉴——dev 完成时主动 handoff 给 qa，不通过 sprint 调度器中转。
• Persona vs Specialist 的边界——有些角色（如 product manager）有时是 persona（产品判断），有时是 specialist（写需求文档）。需要明确”这次召唤的是哪一个”——目前我是隐式判断，应该显式标注。

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

30 秒电梯版

2 分钟白板版

10 分钟深入版

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

问题 1：物理上 Persona 和 Specialist 都是 LLM 调用，本质不一样吗？

回应：

物理实现上是。但接口和契约不同：

Persona 接口是”输入议题、输出立场”，契约是 markdown + 反谄媚规则。 Specialist 接口是”输入任务 + 验收标准、输出 artifact”，契约是 YAML + 质量门。

评估方式、失败处理、调度方式全部不同。物理一致不重要，契约不一致才重要。把它们当成同一种东西管，就是 CrewAI 那种产品形态——demo 好看，生产空。

问题 2：你的 Persona 听起来像花哨的 prompt，有什么特别？

回应：

表面是 prompt，关键差异在于”反谄媚规则 + 可证伪承诺”两段。

普通 prompt 的角色描述会被 RLHF 训练梯度压过去——agent 几轮内塌缩成同一个声音。反谄媚规则是反训练梯度的工程方案。可证伪承诺让立场是论辩而不是抬杠。

没这两段，“persona” 就只是花哨的 prompt。这两段是把 prompt 升级成 persona 的关键。

详见我那篇 反谄媚规则。

问题 3：CrewAI 的 role 不就是你的 Persona 吗？

回应：

不是。CrewAI 的 role 是单一类型——每个 role 既负责思考又负责执行（researcher 既研究又写综述）。这正是混淆。

我的 Persona 只产出立场，不产出 artifact。CrewAI 的 role 必须产出可交付——这迫使它跨越思考/执行边界。

你可以用 CrewAI 实现我的拆分——但需要自己加纪律。CrewAI 框架本身没强制这个分离。

问题 4：Designer / PM 这种角色明明思考和执行不分？

回应：

部分对。但仔细看，仍然是两步：

Designer：先有”设计判断”（视角），再有”设计稿”（物件）。我的拆法是 design persona（决定走哪个方向）+ design specialist（出具体设计）。两次调用，不混在一次。

PM：先有”产品判断”（视角，“应该做什么 / 不做什么”），再有”PRD”（物件）。同样两步。

关键洞察：感觉”分不开”是因为人类做这两步太快——同一个会议同一个人。但这不意味着对 AI 也分不开。AI 拆开做反而更清晰，因为 AI 不像人类有那种隐式跨越能力。

问题 5：拆开会让 multi-agent 系统更复杂吗？

回应：

短期是，长期相反。

短期：你需要维护两种描述格式（markdown + YAML）、两种调度方式（顺序 + 并行）、两种评估机制（论证质量 + 质量门）。学习曲线增加。

长期：你不需要为”agent 既给意见又写代码”这种混乱 debug；你不需要在 model 升级时重写所有 agent；你不需要担心 persona 谄媚或 specialist 越界。总维护成本下降。

阈值：当你两种类型都至少有 2 个 agent 时，拆分的收益超过开销。低于这个阈值，简单的统一框架更划算。

9. 相关链接

内部（其他主文章）

• Five Layers of an Agent System — Persona/Specialist 在第 2 层（Agents）
• 反谄媚规则 — 让 Persona 真正有视角的关键
• Memory as Foundation — Persona 和 Specialist 都消费的底座
• Agent Framework Landscape — 业界框架为什么没拆这一刀

外部参考

• CrewAI 官方文档 — 反面教材：role-based 但没拆思考/执行
• OpenAI Agents SDK — Handoff 模式的实现，比 CrewAI 更清晰
• Anthropic: Building Effective Agents — Generator-Evaluator 是相关思路（生成器/评估器分离）

相关概念

• Generator-Evaluator（Anthropic）≈ 我的 Specialist + QA reviewer，但没我细分的多 persona
• Reviewer / Devil’s Advocate（传统组织）≈ Persona 思路在人类组织里的对应
• Producer-Consumer（CS 经典）≈ 物理上的相似模式