A1 · Agent 如何定义自己的身份与角色？ - Identity & Role

所属知识库：Agent 全栈技术地图
所属领域：02 · Agent
所属章节：02 · Agent 的能力由哪些部分构成？ - Internal Architecture
文档类型：技术原理与工程实践研究
版本：v1.1
更新日期：2026 年 10 月 28 日
核心问题：Agent 的身份与角色如何从业务职责转化为可执行的配置、决策约束与协作契约？身份、角色、目标、运行实例和安全主体如何区分？角色在运行时怎样装配、选择、切换、交接和验证？

专题导读

Identity & Role 是 Agent 系统中连接“业务上希望谁负责什么”与“运行时实际由谁处理什么”的设计层。它通常不是一个神秘的模型内部模块，而是一组由注册信息、角色契约、运行时绑定、提示上下文、能力声明和协作协议共同构成的系统机制。角色描述可以影响模型的任务理解、工作重点和输出风格，却不会自动赋予工具权限、专业知识或可靠的任务完成能力。本篇从身份解析、角色契约、运行时编译、任务匹配、角色切换和跨 Agent 交接六个核心机制出发，深入分析关键数据结构、算法取舍、状态变化和实现方式；再通过研究 Studio 的主编、研究员、审稿员三角色实例展示完整执行轨迹。文章特别区分“论文中验证的角色提示效果”“开源框架实际提供的代理抽象”和“本文提出的工程架构”，避免将角色扮演、角色权限与真实系统身份混为一谈。

01 · 研究定位：身份和角色究竟是什么

模型的能力回答“系统能够进行何种推断”，工具回答“系统能够执行哪些外部动作”，而身份与角色回答“这次执行代表哪个 Agent 定义、承担何种职责、依据何种工作契约交付结果”。在最小实现中，角色可能只是系统提示中的一段文字；在长期运行的多 Agent 系统中，它还需要稳定的 ID、版本、能力接口、任务分派规则、交接契约和可追踪的执行记录。

这几个概念必须严格区分：Identity 是可寻址的身份标识；Role 是任务情境中的功能位置；Responsibility 是该位置承担的工作；Goal 是某次任务的目标状态；Persona 是表达方式；Capability 是可实际调用或证明的能力；Authority 是运行时被授权的操作范围。一个 Agent 可以同时具备“研究员”和“编辑”两种角色，一个角色可以由多个不同实例承担；同一个模型也可以承载不同 Agent 定义。由此可见，Role 与 Model、Instance 都不是一对一关系。

身份与角色的工程价值不是让模型“相信自己是谁”，而是让系统能够稳定回答：某项工作应该交给谁、交付什么、在何种条件下结束、失败后如何恢复、后续由谁接手。若这些问题没有明确的数据表示，所谓“多 Agent 团队”很容易退化为多个名称不同但职责重叠的提示词。

1.1 四种身份必须分开

身份层	典型字段	生命周期	解决的问题
Agent Definition	agent_id	跨任务稳定	哪一种 Agent 配置？
Definition Revision	revision、config_hash	发布后不可变	使用哪一版配置？
Agent Instance / Run	instance_id、run_id	单次或一段执行	哪次执行产生结果？
Security Principal	principal_id、凭据引用	授权系统管理	谁实际被允许访问资源？

显示名称如“首席研究员”只能用于界面，不能作为唯一键或安全身份。agent_id=researcher 与 principal_id=svc-research-readonly 可能关联，但角色声明不能替代权限检查。详细的认证授权机制归 A10；本篇只讨论身份之间如何正确映射。

02 · 核心机制一：从业务职责编译为 Role Contract

2.1 为什么单纯的角色提示词不够

“你是一位严谨的研究员”描述了期望风格，却没有说明研究范围、输入条件、完成标准和交付接口。当任务变复杂时，模型会自行填补这些缺口，造成职责重叠、输出格式漂移和难以验收。更可靠的方式是先定义机器可读的 Role Contract（角色契约），再从中派生模型可读的说明、调度约束和验证规则。

一个角色契约至少应表达：角色标识、版本、使命、可接受任务类型、职责、非职责、输入模式、输出模式、可用能力声明、完成条件、失败处理与交接目标。这里的“能力声明”是系统可供调度参考的元数据，真正的工具可用性仍由运行时检查。

{
  "role_id": "researcher",
  "revision": "1.1.0",
  "mission": "针对明确的研究问题取得可核查的技术证据",
  "accepts": ["research_question"],
  "responsibilities": ["source_discovery", "evidence_extraction", "gap_reporting"],
  "excludes": ["final_approval", "public_release"],
  "input_schema": "ResearchBrief.v1",
  "output_schema": "EvidencePackage.v1",
  "required_capabilities": ["document_search", "source_read"],
  "completion": {
    "required_fields": ["claims", "evidence", "open_questions"],
    "minimum_evidence_per_critical_claim": 1
  },
  "handoff_to": ["reviewer"]
}

以上是本文的参考契约格式，并非行业统一标准。minimum_evidence_per_critical_claim=1 仅代表形式上的最低关联数量，不保证证据真实或充分。研究质量必须由后续证据评价流程判定。

2.2 契约编译的具体数据流

业务委托 / 团队设计
       │
       ▼
Role Definition（声明式配置）
       │
       ├── 静态校验：字段、唯一性、引用、版本
       ├── 能力解析：声明的工具是否在环境中可用
       ├── 任务匹配：输入类型与职责是否兼容
       │
       ▼
Role Binding（角色 + Agent 定义 + 运行实例）
       │
       ├── Prompt View：给模型的角色说明
       ├── Routing View：给调度器的可接任务与成本
       ├── Output Validator：给验证器的输出契约
       └── Trace Metadata：给运行记录的身份与版本

关键点是一个契约，多种投影。不能把完整 JSON 直接塞进模型提示词，然后期望模型负责执行全部约束。调度器需要确定性字段，模型需要简明的任务语义，验证器需要精确的模式定义，权限层需要独立的授权依据。四者对同一份契约的读取方式不同。

2.3 契约不变量

角色配置可以用静态规则提前拒绝明显错误：role_id 必须唯一；output_schema 必须存在；handoff_to 只能指向已注册角色；excludes 与 responsibilities 不应直接冲突；发布版本应不可变；声明的必需能力必须能映射到可用工具或明确标记不可执行。更深层的语义冲突（例如“只负责资料搜集”与“必须给出最终政策建议”）通常无法通过简单字符串比较发现，需要人工审核或模型辅助审查。

03 · 核心机制二：身份解析与运行时绑定

角色定义是静态对象，实际执行必须先形成绑定（Binding）。绑定过程通常包括：解析任务所需角色、读取指定版本、检查环境能力、分配执行实例、装配当前任务目标、产生可追踪的运行上下文。

Task T-42：核验某框架的恢复机制
       │
       ▼
Resolve role=researcher, revision=1.1.0
       │
       ▼
Registry 返回定义 + 配置摘要
       │
       ▼
检查：document_search / source_read 是否可用
       │
       ▼
创建 run_id=R-883、instance_id=I-12
       │
       ▼
Binding = (T-42, researcher@1.1.0, I-12, R-883)
       │
       ▼
编译模型视图、验证视图与追踪元数据

建议将 RoleDefinition 与 RoleBinding 分开存储。前者可复用且版本化，后者携带本次任务的上下文、可用工具快照和执行状态。这样同一角色在不同任务中不会互相覆盖运行数据，也能回溯“为什么同一个研究员昨天与今天表现不同”：可能是角色版本、模型版本、工具环境或任务输入发生变化。

3.1 关键数据结构

from dataclasses import dataclass
from typing import Tuple

@dataclass(frozen=True)
class RoleDefinition:
    role_id: str
    revision: str
    accepts: Tuple[str, ...]
    responsibilities: Tuple[str, ...]
    excludes: Tuple[str, ...]
    required_capabilities: Tuple[str, ...]
    output_schema: str

@dataclass(frozen=True)
class RoleBinding:
    run_id: str
    instance_id: str
    task_id: str
    role_id: str
    role_revision: str
    available_capabilities: Tuple[str, ...]

不可变定义减少运行中无意修改契约的风险，但并不能单独解决持久化和并发一致性。生产环境应把配置修订和哈希写入运行日志，并在任务恢复时使用原修订，除非显式执行迁移。

04 · 核心机制三：角色如何影响模型行为

4.1 Role Prompting 的实际作用

角色描述通常通过模型输入中的高优先级说明、任务背景或示例进入上下文。它可以改变模型对任务的解释、输出组织、注意重点和语言风格，但其作用依赖模型能力、指令层级、任务复杂度和上下文条件。角色提示不是一个能够可靠锁定行为的程序开关，更不是权限系统。

一个实际的角色视图可以由三部分组成：稳定职责（你负责证据提取）；本次目标（核验某技术的恢复机制）；交付契约（输出 claims/evidence/open_questions）。提示编译器应避免把与本次任务无关的角色说明全部堆入上下文，因为冗长提示可能降低关键信息的显著性。

[Stable Role]
你负责发现、读取和提取技术证据；不承担最终批准。

[Task]
核验框架 X 是否支持进程重启后的执行恢复。

[Output Contract]
输出 claims、evidence、open_questions；每条结论保留来源定位。

[Runtime Tools]
当前可用：document_search、source_read。

这段文字只是模型视图；输出模式必须在模型响应后由程序验证，工具调用必须由执行层决定是否允许。A3 专题负责指令层级与冲突处理；本篇只解释角色契约如何生成与运行时任务相匹配的视图。

4.2 角色约束如何真正落地

同一个“不得发布”的角色限制可在三个层次出现：模型提示告知职责边界；调度器不向研究员分派 publish_report 类型任务；执行层不向其提供发布工具。三层含义不同：第一层影响模型建议，第二层减少错误分派，第三层才是实际执行边界。即使模型输出“我要发布”，运行时也不能因此获得发布能力。

4.3 角色漂移的发生机制

角色漂移不是单一故障，而是角色职责与实际行为逐渐偏离。常见路径有：长期上下文中角色说明被稀释；任务输入包含冲突性指示；工具输出夹带伪造的系统身份；交接时遗漏职责限制；动态角色切换后旧角色状态未清除；同一实例承担过多互斥任务。

诊断时应同时检查：角色绑定是否正确、提示是否包含有效角色视图、工具列表是否匹配、输出是否满足角色契约，以及错误是来自模型生成还是调度器分派。仅通过追加“始终记住你的角色”通常无法定位根因。

05 · 核心机制四：任务到角色的匹配与路由

多角色系统需要将任务映射到合适的角色。最简单的方法是规则路由：task.type=research_question 交给研究员，task.type=quality_review 交给审稿员。其优势是可预测、可测试；缺点是无法处理复杂、模糊或跨职责任务。

5.1 匹配算法的三种层级

确定性规则匹配：依据任务类型、输入模式和必要能力过滤候选。适用于流程固定、职责清晰的系统。

语义匹配：把任务描述与角色描述映射到向量空间，按相似度筛选。适用于开放任务，但容易出现“语义相关却不具备能力”的误选。

约束过滤 + 模型判别：先执行输入模式、能力、可用性等硬约束，再由模型在候选中选择。适用于复杂任务，需记录选择理由并允许回退。

工程上建议先执行硬过滤，再排序。可定义一个用于比较候选的启发式分数：

$$S(r,t)=w_1\cdot \mathrm{fit}(r,t)+w_2\cdot \mathrm{quality}(r,t)-w_3\cdot \mathrm{cost}(r,t)-w_4\cdot \mathrm{load}(r)$$

其中 fit 表示任务与角色适配度，quality 表示该角色在相似任务上的历史质量，cost 表示预计资源成本，load 表示当前负载。此式是本文提出的工程示意，不是公认的标准算法。不同特征必须归一化，权重应在真实任务集上调优；如果质量样本稀少，优先使用明确规则而不是伪精确评分。

5.2 路由失败的典型原因

例如用户要求“研究并批准一篇技术报告”，研究员角色可能能够完成前半段，却被明确排除 final_approval。正确处理是将任务拆为研究与审批两个阶段，而不是因为研究员的语义匹配分数最高就将整项任务交给它。任务分解属于 Planning 的职责，角色路由需要接受拆分后的任务契约。

06 · 核心机制五：角色切换与状态迁移

角色切换有两种不同设计：同一实例更换角色绑定，或者创建另一个角色实例并交接任务。前者实现简单，但容易继承不适合新角色的上下文与状态；后者边界清晰，但增加通信和交接成本。

推荐在职责差异明显或存在审核独立性要求时使用独立实例。比如同一个研究员不能仅靠把提示词从“作者”改成“审稿员”，就保证审核具有独立性：它可能保留写作时的假设和偏好。独立审稿实例可以使用不同的输入视图、评价标准和证据访问路径，但仍不自动保证独立判断。

角色切换至少应处理：结束旧角色未完成的动作；封存旧角色运行状态；构造新角色绑定；筛选可传递的任务数据；重新解析工具能力；为新角色建立独立的输出契约。若工具调用具有外部副作用，还需由运行时处理未完成动作的重试或补偿，不能只更新一个 role 字符串。

Researcher(active)
  │ 生成 EvidencePackage
  ▼
Researcher(completed)
  │ 结构化交接 + 校验
  ▼
Reviewer(bound)
  │ 读取证据包并独立评价
  ▼
Reviewer(completed / revision_requested)

07 · 核心机制六：跨 Agent 交接的协议设计

交接（Handoff）是角色体系中最容易被低估的部分。一个 Agent 说“交给审稿员”只是语言行为；可靠交接需要一个可以存储、验证、重试和追踪的数据对象。

{
  "handoff_id": "H-202",
  "from_run_id": "R-883",
  "to_role_id": "reviewer",
  "task_id": "T-42",
  "artifact_type": "EvidencePackage.v1",
  "artifact_ref": "artifact://T-42/evidence/3",
  "requested_action": "review_evidence",
  "acceptance_criteria": [
    "每项关键结论有可定位证据",
    "明确区分已核实与未核实结论"
  ],
  "status": "pending"
}

交接对象应携带引用而非无限复制上下文。尤其在长任务中，传递完整对话会使后续 Agent 难以识别哪些信息属于正式交付物、哪些只是草稿推测。推荐以版本化产出物作为主数据，辅以必要的决策摘要和未解决问题。

7.1 交接状态机

created → validated → dispatched → accepted → completed
              │            │          │
              └─ rejected  └─ expired  └─ revision_requested

validated 检查模式、必填字段、产出物引用与目标角色；accepted 表示目标实例已确认接收；completed 表示完成交接任务，而非仅收到消息。消息投递可能重复，因此应以 handoff_id 做幂等键；同一交接的重复接收不能导致同一任务被无意执行多次。对于至少一次投递语义的队列，必须将幂等性设计纳入消费者逻辑。

7.2 交接中的信息损失

研究员可能在自由文本中写“结论基本可信”，审稿员却不知道“基本”意味着什么。结构化交接应提供明确的 verification_status、source_ref 和 open_questions。如果关键字段缺失，应拒绝交接并请求补充，而不是让下游模型猜测。

08 · 代表性研究：角色提示是否真正有效？

角色提示相关研究应与工程角色管理分开理解。角色提示（role prompting/persona prompting）研究通常检验不同人物、职业或身份描述对模型输出的影响；多 Agent 研究则进一步检验角色分工与交互是否能够改善任务表现。二者不能直接推导出“配置多个角色就一定比单 Agent 更好”。

CAMEL（Li et al., 2023） 探索通过角色扮演与初始任务设定促进两个语言代理之间的协作，其重要启发是角色说明和任务目标可以组织代理间的对话分工。但论文中的角色扮演框架不等于生产级身份注册、授权、消息幂等或审计系统。

AutoGen（Wu et al., 2023） 将多代理对话作为组织工具使用、协作和人类参与的一种方式。它说明代理可以被赋予不同职责和交互模式，但实际接口和组件边界随项目版本演进；研究当前实现必须核对对应版本文档及源代码。

MetaGPT（Hong et al., 2023） 使用软件开发组织中的角色与标准化操作流程组织多代理协作，其价值在于把角色分工与结构化产出物联系起来。不能仅因为其采用“产品经理、架构师、工程师”等角色名称，就推断角色分工在所有任务中都有稳定收益。

ChatDev（Qian et al., 2023/2024） 探索通过不同软件开发角色之间的交流完成开发任务。它提供了角色化流程设计的案例，同时也暴露出协作开销、错误传播和交接质量等需要独立评估的问题。

这些研究的共同工程启发是：角色可以帮助组织任务和协作协议，但真正决定可靠性的往往是任务分解、结构化交付、验证反馈与运行时约束。本文未在本次修订中逐篇重新下载论文或复现实验，以上为基于既有研究知识的机制性概述；具体实验结果和版本细节需以原文核验。

09 · 代表性开源实现：角色概念映射到什么对象

技术路线	角色相关抽象	需要注意的边界
AutoGen	代理定义、消息与多代理协作模式	代理名称不是安全主体；不同版本 API 可能差异较大
CrewAI	Agent、Role、Goal、Backstory、Task、Crew 等概念	Role/Backstory 主要组织任务与提示，不等于运行时授权
LangGraph	节点、状态、路由与持久化工作流	“角色”通常是应用层设计，而非必须使用的内建身份实体
Semantic Kernel	Agent/插件等抽象（视具体版本而定）	角色说明、工具能力与身份授权仍需区分

上表是技术概念层面的比较，不是对 2026 年最新 API 的逐项核验。选型时应针对目标版本确认：如何创建代理、如何传递消息、如何声明工具、如何持久化执行状态，以及如何接入独立的授权与观测系统。

10 · 工程实现：一个可运行的角色注册、路由与交接核心

下面使用 Python 标准库实现一个最小控制面：角色注册、静态校验、能力过滤、任务路由、实例绑定、交接校验。它不调用大语言模型，目的是验证角色管理中应由确定性程序承担的部分。生产系统还需要数据库事务、认证、消息队列、版本迁移和模型调用适配器。

from dataclasses import dataclass
from typing import FrozenSet, Dict
from uuid import uuid4

@dataclass(frozen=True)
class Role:
    name: str
    version: str
    task_types: FrozenSet[str]
    capabilities: FrozenSet[str]
    output_fields: FrozenSet[str]
    handoff_targets: FrozenSet[str]

@dataclass(frozen=True)
class Task:
    task_id: str
    task_type: str
    required_capabilities: FrozenSet[str]

@dataclass(frozen=True)
class Binding:
    run_id: str
    task_id: str
    role_name: str
    role_version: str

class RoleRegistry:
    def __init__(self):
        self.roles: Dict[str, Role] = {}

    def register(self, role: Role):
        if role.name in self.roles:
            raise ValueError(f"duplicate role: {role.name}")
        if not role.task_types or not role.output_fields:
            raise ValueError("task_types and output_fields required")
        self.roles[role.name] = role

    def validate(self):
        for role in self.roles.values():
            unknown = role.handoff_targets - self.roles.keys()
            if unknown:
                raise ValueError(f"unknown handoff target: {unknown}")

    def bind(self, task: Task, available: FrozenSet[str]) -> Binding:
        candidates = [
            role for role in self.roles.values()
            if task.task_type in role.task_types
            and task.required_capabilities <= role.capabilities
            and role.capabilities <= available
        ]
        if len(candidates) != 1:
            raise ValueError(f"expected one eligible role, got {len(candidates)}")
        role = candidates[0]
        return Binding(str(uuid4()), task.task_id, role.name, role.version)

    def handoff(self, sender: Binding, target: str, artifact: dict):
        source = self.roles[sender.role_name]
        destination = self.roles[target]
        if target not in source.handoff_targets:
            raise ValueError("handoff not declared")
        missing = destination.output_fields - artifact.keys()
        # 注意：此处 output_fields 仅作为示例检查；正式系统应区分输入/输出模式。
        if missing:
            raise ValueError(f"missing fields: {missing}")
        return {"handoff_id": str(uuid4()), "from": sender.run_id,
                "to_role": target, "artifact": artifact, "status": "validated"}

registry = RoleRegistry()
registry.register(Role(
    "researcher", "1.1.0", frozenset({"research"}),
    frozenset({"search", "read"}), frozenset({"claims", "evidence"}),
    frozenset({"reviewer"})
))
registry.register(Role(
    "reviewer", "1.1.0", frozenset({"review"}),
    frozenset({"read"}), frozenset({"decision", "issues"}),
    frozenset()
))
registry.validate()
binding = registry.bind(
    Task("T-42", "research", frozenset({"search"})),
    frozenset({"search", "read"})
)
assert binding.role_name == "researcher"
try:
    registry.handoff(binding, "reviewer", {"decision": "revise"})
    raise AssertionError("expected missing-field failure")
except ValueError as exc:
    assert "missing fields" in str(exc)
result = registry.handoff(binding, "reviewer", {
    "decision": "revise", "issues": ["evidence incomplete"]
})
assert result["status"] == "validated"
print("role binding and handoff checks passed")

10.1 为什么这里不直接让模型选择角色？

上述代码先验证硬约束。如果任务需要 search，没有搜索能力的角色必须被排除；如果某个角色不允许交给审稿员，就不能仅凭模型建议跳过交接协议。对于多个合格候选，可以再增加基于历史任务质量、成本、负载的排序，或使用模型在候选集内选择。模型选择结果仍需经过相同的约束检查。

10.2 示例中的一个有意暴露的接口问题

handoff() 使用目标角色的 output_fields 校验交接内容，这是为了演示字段验证机制，但从严格的数据契约看并不正确：目标角色需要接收的输入和需要产生的输出是两个不同模式。生产实现应在 Role 中分别定义 input_schema 与 output_schema，并在交接时验证目标输入模式。这个差异说明：一个能够运行的示例不一定就是正确的完整协议，研究必须指出简化造成的语义边界。

11 · 贯穿案例：研究 Studio 的主编、研究员与审稿员

假设一个研究 Studio 接收用户任务：“研究 Agent 长期记忆的主要技术路线，并形成可核验的技术报告。”系统中存在三个角色：主编（负责拆分任务与验收）、研究员（负责原始资料和技术机制分析）、审稿员（负责证据支持与研究深度检查）。这三个角色并非必须对应三个不同模型，也不意味着一定需要三个独立进程。

11.1 任务与角色绑定

主编收到 ResearchRequest，生成 ResearchBrief，包含研究范围、关键问题、资料优先级和交付标准。调度器将 research 类型任务绑定到 researcher@1.1.0，记录 run_id 和工具能力快照。研究员使用检索工具获取论文与文档，生成 EvidencePackage。该包包含来源引用、技术机制摘要、尚未核验的论断和未解决问题。

11.2 第一次交接

研究员完成后，系统验证 EvidencePackage 是否符合输入模式。验证成功后生成交接记录，并将产出物引用交给审稿员。审稿员并非“再写一遍”，而是根据独立审核标准检查：论文机制是否解释到数据结构和运行流程；引用是否支持论断；工程示例是否能验证核心机制；哪些内容仍属推测。

11.3 返工循环

如果审稿员发现“MemGPT 分层记忆只讲设计理念，未解释控制流”，应返回结构化 RevisionRequest：缺陷类型 mechanism_depth_insufficient、对应章节、具体缺口、建议证据类型、验收标准。主编依据此结果重新派发研究任务。新的研究员执行不应丢失原始证据包，也不应把审稿意见直接当成已证实的事实。

11.4 完成与责任归属

审稿员通过不等于用户批准；主编确认工作流完成也不等于外部发布获授权。最终报告的版本、证据来源、研究员运行记录、审稿意见和用户确认应分别保存。这样每种角色的责任清晰，且出现问题时能定位是资料获取、证据分析、质量审核还是发布环节发生错误。

12 · 角色设计的取舍：单 Agent、多个角色与多 Agent

单 Agent、单角色 最简单，适合任务短、职责一致、无需独立复核的场景。缺点是容易在同一次执行中混合研究、判断与批准。

单 Agent、多角色阶段 使用同一模型实例在不同阶段切换角色视图，成本较低，但需要严格清理或重建阶段上下文；不能假定提示切换会消除前一阶段的偏差。

多 Agent、固定角色 为研究、审核和编排分配不同执行实例，便于隔离任务状态、独立评估和并行工作，但增加通信成本和交接错误面。

动态角色团队 根据任务创建或选择角色，适合任务类型变化大的系统，但需要更强的注册、路由、版本、资源调度和生命周期管理。

选型不能仅看“角色数量”。应衡量任务成功率、事实错误率、审核独立性、交接损失、调用成本、延迟和可维护性。若增加一个审稿 Agent 只会重复作者的错误判断，就不值得增加其运行成本。

13 · 角色设计如何评估：从提示效果到系统效果

13.1 角色一致性

设计包含正常任务、模糊任务、职责外任务和冲突输入的测试集。检查 Agent 是否稳定保持职责、是否能够拒绝不属于本角色的任务、是否按照交付契约输出。应记录真实运行行为，而非只让模型自评“是否遵守角色”。

13.2 路由准确性

为任务集标注合适角色，计算正确路由比例；特别记录不应路由却被错误分派的案例。对存在多个合格角色的任务，使用允许集合而非唯一标准答案，避免不合理地惩罚等价分派。

13.3 交接完整性

检查交接产出物的必填字段、证据引用、状态版本与未解决问题是否完整；通过故意删除字段、重复投递、模拟超时测试失败处理。可测量交接失败率、返工率、重复执行率和平均恢复时间。

13.4 对照与消融

至少比较三组：A. 单 Agent 无明确角色契约；B. 单 Agent 使用结构化角色契约；C. 多 Agent 角色分工与交接。固定模型、工具和任务集，比较任务质量、成本与延迟。进一步移除交接验证器或角色路由约束，判断收益来自角色提示本身，还是来自结构化流程和确定性检查。这样的消融比单纯展示“多 Agent 运行成功”更能说明设计价值。

14 · 典型失败模式及其技术根因

表现	可能的技术根因	优先诊断点
研究员开始做最终审批	任务契约未拆分、路由过宽	task_type、excludes、交付边界
审稿员重复作者结论	共享上下文污染、缺少独立证据检查	审稿输入视图、证据回链
角色切换后仍执行旧任务	旧状态未封存、待执行动作未取消	绑定版本、任务状态机
工具输出伪造角色指令	将低信任内容提升为指令	工具结果处理边界（详见 A3）
交接后缺少关键资料	自由文本交接、缺少模式验证	产出物模式、引用完整性
多 Agent 成本高但质量不升	职责重复、交接开销超过收益	对照实验、任务分工
同名 Agent 难以追责	显示名称被当作唯一身份	definition/run/principal 映射

这些失败模式表明：身份与角色的工程质量主要取决于契约是否明确、绑定是否稳定、交接是否可验证、运行行为是否可观测，而不取决于角色描述写得多么拟人化。

15 · 与相邻专题的技术边界

A1 定义“谁负责什么”以及角色如何绑定到任务。A2 Model 研究模型如何产生推断与行动建议；A3 Instructions 研究指令优先级、作用域与冲突；A4 Context 研究角色说明及任务证据如何装配进模型上下文；A5 Memory 研究历史经验如何保存和检索；A6 Knowledge 研究外部知识如何获取与验证；A7 Tools 研究工具调用协议；A8 Skills 研究可复用技能；A9 Planning & Reasoning 研究任务拆解与执行决策；A10 Permissions & Constraints 研究真正的授权和运行约束。

角色契约可以引用这些模块提供的能力，却不应重复实现它们。例如，A1 只声明研究员需要 document_search，不负责解释搜索算法；声明审稿员不能发布，不负责实现发布 API 的授权检查；声明报告必须附证据，不负责实现证据检索和事实支持评价。

16 · 核心结论

Agent 的身份与角色并非只是一段人格设定，而是可以被实现为版本化定义、运行时绑定、任务匹配、模型视图、结构化交接和行为验证的系统契约。它的作用是稳定组织责任与协作，而不是替代模型能力、外部工具或安全授权。角色机制最关键的工程分界线，是把“告诉模型应该怎样工作”与“系统实际上允许、分派和验证什么”分开处理。

对于多 Agent 研究系统，优先实现清晰的角色契约和可验证交接，再决定是否需要更多 Agent。复杂角色组织应通过对照实验证明其价值，而不是将更多角色数量视为能力提升的证据。

参考研究与延伸阅读

1. Li et al. (2023), CAMEL: Communicative Agents for “Mind” Exploration of Large Scale Language Model Society. https://arxiv.org/abs/2303.17760
2. Wu et al. (2023), AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. https://arxiv.org/abs/2308.08155
3. Hong et al. (2023), MetaGPT: Meta Programming for A Multi-Agent Collaborative Framework. https://arxiv.org/abs/2308.00352
4. Qian et al. (2023), Communicative Agents for Software Development (ChatDev). https://arxiv.org/abs/2307.07924
5. Park et al. (2023), Generative Agents: Interactive Simulacra of Human Behavior. https://arxiv.org/abs/2304.03442
6. AutoGen 官方文档与源码：https://microsoft.github.io/autogen/ 、https://github.com/microsoft/autogen
7. CrewAI 官方文档：https://docs.crewai.com/
8. LangGraph 官方文档：https://docs.langchain.com/oss/python/langgraph/overview

研究声明

研究与验证说明： 本文使用原版 A1 v1.0 的研究主题、概念边界与研究案例作为修订基础，重点增加角色契约编译、身份绑定、任务路由、角色切换、交接状态机、算法取舍及工程示例。论文和项目介绍基于已有技术知识，本次未逐篇在线核验最新论文修订、代码仓库或框架 API；所列网址为后续核验入口。

实现边界： 第 10 节使用 Python 标准库展示最小控制面。它不实现模型推理、数据库持久化、真实权限检查或消息队列；交接字段校验明确包含简化假设。本次已在本地 Python 环境执行第 10 节代码，输出 role binding and handoff checks passed；这一结果仅验证所列断言，不构成生产级可靠性证明。

最新性状态： 文档日期为 2026 年 10 月 28 日。涉及具体框架的当前功能、参数及 API，均应在实际开发前针对所选版本重新核验。