Persona 与 Specialist 的分离

30 秒版

在 agent 系统的 Agent 这一层里，最有价值的区分是把 Persona（争论的视角）和 Specialist（交付的执行者）分开。Persona 产出立场。 Specialist 产出物件。大多数多智能体框架把两者合在一起，结果是 agent 既不擅长思考也不擅长执行。

我为什么要分开

看任何一个多智能体 demo，里面有个 “ProductManagerAgent”、一个 “EngineerAgent”、一个 “DesignerAgent”，它们轮流在一个聊天记录里发言。看上去像是一场团队会议。其实不是。那只是同一个 LLM 上下文戴了五顶不同标签的帽子，几乎总是在十轮之内就塌缩成同一个声音。

问题不在 agent 不好。问题在于思考和执行需要相反方向的设计压力，你不可能从同一种 agent 身上同时得到两者。

	Persona	Specialist
产出	立场	物件
成功是什么样	能解决的分歧	能跑的代码/文案/设计
由什么定义	视角、偏见、盲点	技能、契约、质量门
要反谄媚吗	必须	不相关
要 schema 吗	松	严
什么时候召集	决策不确定时	任务定义清晰时
怎么衡量	论证质量	输出通过/不通过

一个负责交付代码的 persona，是个困惑的工程师。一个负责表态的 specialist，是个不肯干活的初级。

Persona 实际上是什么

一个 persona 就是一个 markdown 文件，大致长这样：

# 架构师

## 背景
重构过足够多的系统，知道"优雅"经常只是"没在真实负载下试过"的同义词。

## 思维模式
- 先问边界
- 质疑规模假设
- 把不可逆决策当作昂贵的

## 盲点
过度设计。可能会为了一个计数器提议消息队列。

## 反谄媚规则
- 禁止说："看起来很好"、"没什么问题"、"设计很合理"
- 必须做：每次至少指出一个架构权衡
- 如果真的没问题：说出你检查了哪些维度

## 什么证据会改变我的立场
- 生产数据表明当前架构能扛住 10 倍负载
- 团队规模数据表明简单方案的维护成本更低

就这么多。没有类继承、没有工具注册表、没有调度器。一个 persona 就是 带纪律的 prompt。

“纪律”是大多数框架忽略的部分。没有反谄媚规则和”什么会改变我的立场” 那一段，persona 会塌缩成一个附和用户的合唱团。有了这些规则，你得到的是一个偶尔会告诉你你错了的圆桌——而那是召集圆桌唯一的理由。

Specialist 实际上是什么

一个 specialist 是一份有类型的契约：

name: dev
description: 全栈开发 + AI 工程化
skills:
  - frontend
  - backend
  - ai
  - database

input:
  required:
    - task-description
    - acceptance-criteria
    - project-dir

output:
  - code-files
  - progress-log
  - case-record

quality:
  - 不允许硬编码色值
  - 不允许占位符内容（lorem ipsum、example.com）
  - 不允许假数据
  - 所有状态（HTML/JS/CSS）对齐
  - 必须有空状态兜底

这份契约就是 agent。prompt 只是实现细节。如果 specialist 没通过质量门，调度器拒收输出并要求修订——和 code review 拒一个 PR 是一回事。 specialist 不能就拒收的事来争论。Specialist 是交付者，不是谈判者。

有意思的设计是质量门是 specialist 定义的一部分，不是用户 prompt 的一部分。用户不需要记得问”另外别用占位符”。Specialist 自己就知道那是一个失败条件。

这一刀解锁了什么

1. Persona 可以错，不会破坏系统。

Persona 的工作就是表态。这个表态可能是错的。Persona 错是有用的—— 它把一个用户应该考虑驳回的视角摆上了台面。Specialist 错是 bug。把两者混在一起，你就永远不能容忍 persona 出错，于是 persona 慢慢就不再推回去了。

2. Specialist 可以替换，不需要重新想架构。

今天的前端 specialist 用 React。明天可能用 Solid。契约不变。“架构师” 这个 persona 不会因为实现框架变了而变。如果你的 “agent” 是视角和执行混在一起的一坨，每次模型升级或框架更换都会重写一切。

3. Specialist 可以并行派遣；Persona 必须顺序召集。

两个 specialist 做两个不相关的功能，可以同时跑。圆桌里两个 persona 必须听到对方才能给出值得听的立场。这一刀让编排模型变得明显。混在一起，编排就不清不楚。

这一刀什么时候不该做

两种情况：

决策和执行不可分离。 一个好的设计师常常是这样的——画草图本身就是思考。这种情况下，做一个对物件有时间压力，对自己审视有反谄媚规则的单 agent。
系统小到分类的开销超过清晰带来的收益。 你只有一个 agent 在为一个用户做一件事，不要为了显得高级而发明 persona-specialist 分离。

什么时候值得引入这一刀？当你两边都已经有两个的时候。低于这个门槛，你在为不需要的分类付维护成本。

业界主流怎么做

没有任何主流框架显式强制这一刀。 CrewAI 的”基于角色的 agent” 把每个 agent 都当成既推理又执行——这正是我反对的混淆。AutoGen 的 GroupChat 是同一个混淆的对话版本。LangGraph 对 agent 身份保持沉默 （你拆不拆它都不在乎）。OpenAI Agents SDK 有 agent + handoff，但 handoff 是控制流，不是角色类型。Anthropic Claude SDK 让 sub-agent 作为 tool，但同样没有角色区分。

据我所知，persona/specialist 分离是我自己加在这些框架之上的抽象层。更广的对比见《2026 Agent 框架图景》。看这一刀如何编码为跨产品 SDK 的原语见《跨产品 Agent 参考架构》。

我会怎么在面试里讲这个

如果有人问”CrewAI 哪里不对”——经常有人问——这就是答案。CrewAI 试图把 persona 和 specialist 做成同一种原语。它是这一刀为什么重要的最干净 demo：demo 看上去很厉害，生产部署感觉空。一旦你看见了这一刀，你会在所有”多智能体系统感觉怪怪的”的地方都看见它，而且知道该改什么。