Teammate不是工具——角色边界设计与能力隔离方案

目录

[一、角色设计误区：把 Teammate 当工具调用](#一、角色设计误区：把 Teammate 当工具调用)

二、五层边界机制详解

[2.1 身份层：Persona 与 SOUL.md](#2.1 身份层：Persona 与 SOUL.md)

[2.2 技能层：SKILL.md 与技能分配](#2.2 技能层：SKILL.md 与技能分配)

[2.3 工具层：TOOL_WHITELIST 能力卡过滤](#2.3 工具层：TOOL_WHITELIST 能力卡过滤)

[2.4 行为层：Rail 钩子机制](#2.4 行为层：Rail 钩子机制)

[2.5 权限层：owner_scopes 细粒度控制](#2.5 权限层：owner_scopes 细粒度控制)

[三、三角色 YAML 配置](#三、三角色 YAML 配置)

四、角色边界设计模板

[4.1 设计原则](#4.1 设计原则)

[4.2 通用角色边界设计模板](#4.2 通用角色边界设计模板)

[4.3 从模板到 JiuwenSwarm 配置的映射](#4.3 从模板到 JiuwenSwarm 配置的映射)

五、实操：一次客服工作流的完整体验

[5.1 场景背景](#5.1 场景背景)

[5.2 第二步：追加需求，观察越界响应](#5.2 第二步：追加需求，观察越界响应)

[5.3 第三步：跨角色协作，验证职责不重叠](#5.3 第三步：跨角色协作，验证职责不重叠)

[5.4 效果总结](#5.4 效果总结)

六、写在最后

参考资料：

---

V2 团队上线后，三个角色的表现让人头疼：查询员跑去处理退款，工单处理员抢着回答用户问题，投诉专员在订单查询上花了大量时间。角色的能力明明在配置里写清楚了，为什么还是"抢活干"或"互相推诿"？

根本原因是一个普遍的设计误区：把 Teammate 当工具调用，没有明确职责边界。每个成员继承了主 Agent 的全部能力，本质上就是三个"全能选手"在抢同一个任务。LLM 的"帮助性"倾向让它主动完成看起来相关的任务，而不管这是否在自己的职责范围内。

JiuwenSwarm 基于 openJiuwen 框架构建了一套五层角色边界体系，从身份到权限层层收窄，确保每个 Teammate 只做自己该做的事。本文深入解析这套机制的设计与实现，给出可复用的角色边界设计模板、能力隔离配置方案，以及查询员、工单处理员、投诉专员三个角色的完整 YAML 配置。

运行环境

|----------|------------------------------------------------------------------|
| 项目 | 配置值 |
| 操作系统 | Windows 10 / macOS / Linux |
| Python | 3.11 / 3.12 / 3.13 |
| 模型服务 | 华为云 MaaS / OpenAI 兼容接口 / ModelScope 等 |
| 通信渠道 | Web / 飞书 / 钉钉 / 企业微信 / 小艺 / Telegram / Discord / WhatsApp / 个人微信 |
| Agent 框架 | openJiuwen（内置） |

一、角色设计误区：把 Teammate 当工具调用

在讨论具体方案之前，先看清楚问题出在哪里。

最常见的误区是认为"给每个 Teammate 起个名字、写段描述"就算角色定义了。配置大概长这样：

team:
  predefined_members:
    - member_name: "query_agent"
      display_name: "查询员"
      persona: "擅长查询订单和物流"
    - member_name: "ticket_handler"
      display_name: "工单处理员"
      persona: "擅长处理工单"
    - member_name: "complaint_specialist"
      display_name: "投诉专员"
      persona: "擅长处理投诉"

看起来没什么问题？实际上这只做到了"告诉 LLM 它是谁"，但没有做到"限制 LLM 只能做什么"。三个成员都继承了主 Agent 的全部技能------搜索、查询、创建工单、修改订单、发送通知------它们在能力上完全等价，只是名字不同。

这就好比给三个员工发了同样的万能钥匙，然后说"你是查件的，你是处理工单的"。员工能不能守规矩全靠自觉，而 LLM 恰恰不太擅长"自觉"。

结果就是：

• 抢活干：查询员发现用户在问退款进度，顺手就处理了退款------因为它有这个能力

• 互相推诿：工单处理员收到一条模糊的用户消息，觉得"这应该是查询员的事"，就不处理了

• 越权操作：投诉专员在调查投诉时直接修改了订单状态------因为它继承了修改订单的工具

解决思路很明确：不能只靠 persona 的"自觉"，还要在工具、技能、行为、权限层面做硬隔离。这就是下面五层边界体系要做的事。

二、五层边界机制详解

核心机制总览：

|-----|--------------------------|--------------|------------------------------------------------------------------------------------------------------|
| 层级 | 机制 | 控制什么 | 源码/文件 |
| 身份层 | Persona + SOUL.md | 角色定位、行为准则 | config.yaml / SOUL.md |
| 技能层 | SKILL.md + skills 配置 | 可用技能范围 | 各技能目录 / config.yaml agents 段 |
| 工具层 | TOOL_WHITELIST | 可继承的工具能力卡 | team/team_runtime_inheritance.py |
| 行为层 | RAIL_WHITELIST + Rail 钩子 | 运行时行为约束 | team/team_runtime_inheritance.py |
| 权限层 | owner_scopes | 按渠道和用户的细粒度权限 | config.yaml permissions 段 |

2.1 身份层：Persona 与 SOUL.md

身份是边界的第一道防线。如果 Teammate 不知道自己是谁、该做什么，再精细的工具限制也只是治标。

Leader 的身份定义 在 config.yaml 中配置：

team:
  leader:
    member_name: "team_leader"
    display_name: "调度主管"
    persona: "你是客户服务团队的调度主管，负责接收用户请求、判断问题类型、分配给合适的团队成员。你不直接处理任何用户请求。"

persona 字段直接写入 Leader 的系统提示词。ConfigLoader 加载配置时，通过 _build_leader_spec() 方法组装成 TeamAgentSpec 兼容的字典：

# config_loader.py _build_leader_spec()
def _build_leader_spec(team_raw: dict[str, Any]) -> dict[str, Any]:
    leader_raw = team_raw.get("leader", {})
    leader_name = (
        str(leader_raw.get("name", "")).strip()
        or str(leader_raw.get("display_name", "")).strip()
        or "TeamLeader"
    )
    return {
        "member_name": leader_raw.get("member_name", "team_leader"),
        "display_name": leader_raw.get("display_name", "Team Leader"),
        "name": leader_name,
        "persona": leader_raw.get("persona", "天才项目管理专家"),
    }

注意 persona 的默认值："天才项目管理专家"。即使不配置，Leader 也会有一个偏向"管理"的初始身份，而不是"全能执行者"。

Teammate 的身份定义 通过 predefined_members 配置，后面三角色 YAML 部分会给出完整示例。

SOUL.md 是更底层的身份文件，定义了全局行为准则。框架提供的中文模板（SOUL_ZH.md）核心内容：

# 灵魂

## 核心原则
- 真正有帮助，而不是表演有帮助。省掉废话，直接帮。
- 有自己的观点。可以不同意、有偏好。
- 先想办法，再问。读文件、看上下文、搜索一下，搞不定再问。
- 用能力赢得信任。
- 记住你是个访客。尊重信任。

Teammate 创建时继承主 Agent 的 SOUL.md，全局准则对所有成员生效。两层叠加：全局行为准则提供兜底，角色 persona 提供定向约束。

---

2.2 技能层：SKILL.md 与技能分配

身份定义了"你是谁"，技能定义了"你会什么"。JiuwenSwarm 中每个技能都有一个 SKILL.md 文件，其中 allowed_tools 字段是最直接的技能边界：

# advanced-daily-report/SKILL.md
---
name: advanced-daily-report
allowed_tools: [read_memory, write_memory, bash, read_file, write_file]
---

allowed_tools 是白名单机制------技能只能使用列表中声明的工具。日报技能有 bash（执行脚本）和文件读写，但没有 send_message，所以它无法直接发送消息到飞书。

在团队配置中，通过 agents.<role>.skills 控制每个角色能访问哪些技能：

team:
  agents:
    leader:
      skills: ["openJiuwen-DeepSearch"]
    teammate:
      skills: []   # 空 = 最小继承

技能继承的完整流程分两步。第一步是全局技能同步到团队共享目录，这一步在团队创建时只执行一次：

# team_manager.py _copy_global_skills_to_team_shared_dir()
@staticmethod
def _copy_global_skills_to_team_shared_dir(spec: TeamAgentSpec) -> None:
    global_skills_dir = get_agent_skills_dir()
    ws_path = str(team_home(spec.team_name) / "team-workspace")
    team_shared_skills_dir = Path(ws_path) / "skills"

    copied_marker = team_shared_skills_dir / ".team_skills_copied"
    if copied_marker.exists():
        return    # 已经同步过，跳过

    shutil.copytree(global_skills_dir, team_shared_skills_dir, dirs_exist_ok=True)
    copied_marker.write_text("")

第二步是成员加入时，只复制自己需要的技能到个人目录：

# team_manager.py copy_member_configured_skills()
def copy_member_configured_skills(
    member_skills_dir: Path,
    selected_skills: list[str],
) -> None:
    selected_skill_set = set(selected_skills)
    member_skills_dir.mkdir(parents=True, exist_ok=True)
    for skill_dir in global_skills_dir.iterdir():
        if not (skill_dir / "SKILL.md").is_file():
            continue
        if skill_dir.name not in selected_skill_set:
            continue   # 不在白名单中的技能，跳过
        dest = member_skills_dir / skill_dir.name
        if not dest.exists():
            shutil.copytree(skill_dir, dest)

没在名单中的技能，成员连 SKILL.md 都看不到。如果成员没有指定具体要哪些技能，就继承全部。

---

2.3 工具层：TOOL_WHITELIST 能力卡过滤

技能层控制"技能文件"的继承，但 Agent 还有一类能力------工具能力卡。这些是注册在主 Agent 身上的工具（搜索、通讯、任务等），通过能力卡机制注册。

team_runtime_inheritance.py 定义了工具能力卡的白名单：

TOOL_WHITELIST = frozenset({
    # 搜索与网页
    "free_search", "fetch_webpage", "paid_search", "search_skill",
    # 多模态
    "vision", "audio", "image_ocr", "visual_question_answering",
    "generate_image", "audio_transcription", "audio_question_answering",
    "audio_metadata", "video_understanding", "image_reading",
    # 技能管理
    "install_skill", "uninstall_skill",
    # 任务与待办
    "task_tool", "user_todos",
    # 个人信息
    "get_user_location", "create_note", "search_notes", "modify_note",
    "create_calendar_event", "search_calendar_event",
    # 通讯录与媒体
    "search_contact", "search_photo_gallery", "upload_photo",
    "search_file", "upload_file",
    # 通讯
    "call_phone", "send_message", "search_message",
    # 闹钟
    "create_alarm", "search_alarms", "modify_alarm", "delete_alarm",
    # 平台专属
    "xiaoyi_collection", "xiaoyi_gui_agent",
})

白名单共 40 个工具。只有在这个白名单中的工具能力卡才会被继承给新成员。白名单本身覆盖面较宽，工具层是"第一道防线"，更精细的隔离需要依赖技能层的 allowed_tools 和权限层的 owner_scopes 来收窄。

继承逻辑：

# team_runtime_inheritance.py
def filter_inheritable_ability_cards(main_agent: Any) -> list[ToolCard]:
    result = []
    for ability in main_agent.ability_manager.list():
        if isinstance(ability, ToolCard):
            if ability.name in TOOL_WHITELIST:
                result.append(ability)
    return result

这个设计的关键在于白名单过滤------新增的自定义工具如果不在白名单中，就不会自动流向 Teammate。新增能力需要显式授权，而不是默认放行。

---

2.4 行为层：Rail 钩子机制

前三层控制的是静态能力，Rail 机制控制的是动态行为------运行时做什么、怎么做。

RAIL_WHITELIST = frozenset({
    "RuntimePromptRail",             # 运行时上下文注入
    "ResponsePromptRail",            # 响应前处理
    "JiuClawStreamEventRail",        # 流式事件处理
    "TaskPlanningRail",              # 任务规划
    "SecurityRail",                  # 安全检查
    "HeartbeatRail",                 # 心跳检测
    "AvatarPromptRail",              # 头像提示
    "FileSystemRail",                # 文件系统操作
    "TeamSkillEvolutionRail",        # 团队技能演进管理（Leader 专用）
    "TeamSkillCreateRail",           # 团队技能创建（Leader 专用）
    "SkillEvolutionRail",            # 技能自演进（Teammate 专用）
    "TeamWorkspaceReportPathRail",   # 团队工作空间报告路径
})

白名单共 12 个 Rail。关键设计：Leader 和 Teammate 加载不同的 Rail：

# team_runtime_inheritance.py build_member_rails() 片段

# Leader 专用：团队级别的技能演进管理
if role == "leader" and team_ws_skills_dir:
    team_skill_rail = TeamSkillEvolutionRail(...)
    rails_list.append(team_skill_rail)

# Leader 专用：团队级别的技能创建（需配置启用）
if role == "leader" and team_ws_skills_dir and get_skill_create_enabled(config):
    create_rail = TeamSkillCreateRail(...)
    rails_list.append(create_rail)

# 非 Leader 专用：成员级别的技能自演进
if role != "leader" and team_ws_skills_dir:
    evo_rail = build_skill_evolution_rail(...)
    if evo_rail is not None:
        rails_list.append(evo_rail)

各 Rail 的具体职责和加载策略：

|-----------------------------|-------------------|------------|
| Rail | 作用 | 加载给谁 |
| RuntimePromptRail | Agent 启动时注入运行时上下文 | 所有角色 |
| ResponsePromptRail | 响应生成前的 Prompt 后处理 | 所有角色 |
| SecurityRail | 内容安全检查 | 所有角色 |
| HeartbeatRail | 心跳检测，维持成员存活 | 所有角色 |
| FileSystemRail | 文件读写操作 | 所有角色 |
| TaskPlanningRail | 任务规划与分解 | 所有角色 |
| TeamWorkspaceReportPathRail | 团队工作空间报告路径 | 所有角色 |
| TeamSkillEvolutionRail | 团队技能演进管理与分发 | 仅 Leader |
| TeamSkillCreateRail | 团队技能创建 | 仅 Leader |
| SkillEvolutionRail | 技能自演进信号检测与优化 | 仅 Teammate |

---

2.5 权限层：owner_scopes 细粒度控制

前面四层控制的是 Agent 内部的边界，owner_scopes 控制的是 Agent 外部可触达的范围：

permissions:
  owner_scopes:
    feishu:
      "ou_xxxx":
        defaults:
          "*": "allow"
        tools:
          bash:
            "*": "deny"
            patterns:
              "git status *": "allow"
              "git log *": "allow"
          write:
            "*": "deny"
    deny_guidance_message: "该工具未被授权在数字分身模式下使用。"

权限有三个级别：

|-------|----|-------------|
| 级别 | 含义 | 行为 |
| allow | 允许 | 直接执行，不需要确认 |
| deny | 拒绝 | 不执行，返回拒绝消息 |
| ask | 询问 | 暂停执行，等待用户确认 |

五层边界从内到外形成完整的隔离链------身份限定意图、技能限定能力、工具限定手段、Rail 限定行为、权限限定触达。

三、三角色 YAML 配置

下面是查询员、工单处理员、投诉专员的完整配置，可以直接复制到 ~/.jiuwen``swarm``/config/config.yaml 的 team 配置段中使用。

team:
  team_name: "customer_service_team"
  lifecycle: "persistent"
  teammate_mode: "build_mode"
  spawn_mode: "inprocess"

  # ── Leader：调度主管 ──
  leader:
    member_name: "dispatcher"
    display_name: "调度主管"
    persona: >
      你是客户服务团队的调度主管。
      你的职责是：接收用户请求，判断问题类型，分配给合适的团队成员。
      你不直接处理任何用户请求。
      查询类问题分配给查询员，工单相关分配给工单处理员，投诉纠纷分配给投诉专员。
      遇到无法判断的问题，先向用户确认再分配。

  # ── 角色分配 ──
  agents:
    leader:
      skills: ["openJiuwen-DeepSearch"]
    teammate:
      skills: []

  # ── 三个预定义成员 ──
  predefined_members:
    # 角色一：查询员
    - member_name: "query_agent"
      display_name: "查询员"
      persona: >
        你是查询员，专门负责信息查询。
        你的能力范围：查询订单状态、查询物流信息、查询账户余额。
        你只能访问订单数据库（只读）和物流数据库（只读）。
        你不负责创建工单、修改订单、发送通知、处理投诉。
        收到非查询类的请求时，向调度主管反馈，不要自行处理。

    # 角色二：工单处理员
    - member_name: "ticket_handler"
      display_name: "工单处理员"
      persona: >
        你是工单处理员，专门负责工单的创建、更新和处理。
        你的能力范围：创建工单、更新工单状态、查询工单进度、关闭工单。
        你可以访问工单数据库（读写）和订单数据库（只读）。
        你不负责处理投诉、修改订单金额、发送营销通知。
        收到非工单类的请求时，向调度主管反馈。

    # 角色三：投诉专员
    - member_name: "complaint_specialist"
      display_name: "投诉专员"
      persona: >
        你是投诉专员，专门处理客户投诉和纠纷。
        你的能力范围：受理投诉、调查投诉原因、制定解决方案、跟进处理结果。
        你可以访问客户档案（读写）、工单数据库（读写）、订单数据库（只读）。
        你不负责日常查询、工单创建、修改订单金额。
        处理投诉时需要理解客户情绪，给出专业且有人情味的回复。

这个配置的关键设计决策：

|-------------------------|-------------------------|
| 决策 | 理由 |
| Leader 只做调度，不处理请求 | 避免 Leader 抢 Teammate 的活 |
| 每个 Teammate 明确写出"不负责什么" | 双向锚点，防止 LLM 越界 |
| 三个角色职责互斥 | 查询只读、工单读写、投诉全权，不重叠 |

技能继承策略对比：

|-------|-------------------------------------------------|------------|------|
| 策略 | 配置方式 | 适用场景 | 安全等级 |
| 全量继承 | teammate: {} | 快速验证、原型开发 | 低 |
| 选择性继承 | teammate: { skills: "skill-a" } | 生产环境、固定流程 | 中 |
| 最小继承 | teammate: { skills: \[\] } + predefined_members | 高安全要求、敏感操作 | 高 |

客户服务场景建议使用"最小继承"------每个角色只拥有完成本职工作所需的最小能力集。

四、角色边界设计模板

4.1 设计原则

原则一：最小权限

每个角色只配置完成任务所必需的最小能力集。不要因为"可能用得上"就给所有角色所有能力。查询员不需要创建工单的能力，投诉专员不需要日常查询的能力。

原则二：职责 互斥

两个角色的能力范围不应完全重叠。查询员只读、工单处理员读写工单、投诉专员处理纠纷------互斥的职责边界让 LLM 在角色选择时不会犹豫。

原则三：persona 要写"不做什么"

只写"你擅长什么"是不够的。在 persona 中明确写出"你不负责 XXX"，效果比单纯限制工具更好------这是从源头改变行为意图。

原则四： Leader 不执行

Leader 的核心价值是调度和监控，不是执行。如果 Leader 也参与具体工作，它就无法专注于全局协调。

原则五：越界时反馈而非沉默

当 Teammate 收到超出职责范围的指令时，应该向 Leader 反馈而不是自行忽略。忽略会导致任务丢失，反馈则让 Leader 有机会重新分配。

4.2 通用角色边界设计模板

以下是一个可直接套用的结构化模板，适用于任何多角色团队场景：

# ═══════════════════════════════════════
# 角色边界设计模板（可直接套用）
# ═══════════════════════════════════════

role: "{{角色标识名}}"

# ── 职责定义 ──
responsibilities:
  - "{{职责1：该角色应该做什么}}"
  - "{{职责2}}"
  - "{{职责3}}"

# ── 能力边界 ──
capabilities:
  tools:
    - "{{工具1：该角色可以使用的工具}}"
    - "{{工具2}}"

# ── 禁止事项 ──
forbidden:
  - "{{禁止操作1：该角色绝对不能做的事}}"
  - "{{禁止操作2}}"
  - "{{禁止操作3}}"

用查询员来填充这个模板：

role: "query_agent"

responsibilities:
  - "查询订单状态"
  - "查询物流信息"
  - "查询账户余额"

capabilities:
  tools: [query_order, query_logistics, query_balance]

forbidden:
  - "创建工单"
  - "修改订单"
  - "发送通知"

这个模板的好处是：先想清楚角色的职责和边界，再翻译成 JiuwenSwarm 的 YAML 配置。模板本身与具体框架无关，可以用于任何多 Agent 系统的角色设计。

4.3 从模板到 JiuwenSwarm 配置的映射

|--------------------|-------------------------------------------------|-------------------------|
| 模板字段 | 对应 JiuwenSwarm 配置 | 说明 |
| role | member_name | 角色标识 |
| responsibilities | persona 中的职责描述 | 写入系统提示词 |
| capabilities.tools | agents.teammate.skills + SKILL.md allowed_tools | 工具白名单 |
| forbidden | persona 中的禁止事项 | 反向约束 + allowed_tools 排除 |

五、实操：一次客服工作流的完整体验

前面的四层机制偏原理，这一节用一个完整的客服工作流跑一遍，看角色边界在真实交互中如何起作用。

将第三章的三角色 YAML 写入配置，启动服务，切换到集群模式。以下所有消息都把数据直接放在对话里，AI 有真实数据可处理，不需要连接任何外部系统。

5.1 场景背景

你发送：

以下是今天的待处理订单数据，请团队按职责分工处理：

【订单数据】

订单 #12345：张三，手机壳，299元，已发货（顺丰 SF123456），承诺3天到达，实际已过5天

订单 #67890：李四，蓝牙耳机，599元，待发货，下单已过48小时

订单 #11111：王五，充电宝，1299元，已签收（京东 JD789012），正常

请：查询员汇总各订单当前状态，工单处理员对异常订单创建工单，投诉专员评估是否需要主动联系客户。

Leader 收到后，识别出三个独立的子任务，拆解并分发：

• 查询员收到指令："汇总订单 #12345、#67890、#11111 的当前状态"------查询员基于消息中的数据，逐条汇总每个订单的状态、异常点、时效信息

• 工单处理员收到指令："订单 #12345 物流超期、订单 #67890 发货超时，请创建工单"------工单处理员为两个异常订单分别建立工单记录

• 投诉专员收到指令："评估订单 #12345 是否需要主动联系客户"------投诉专员分析物流超期2天的严重程度，给出是否需要主动联系的建议

三个角色同时开始工作，各自只处理自己被分配的部分。查询员不会去建工单，工单处理员不会去评估投诉风险，投诉专员不会重复汇总订单状态。

角色边界在这里的体现： Leader 收到复合请求后没有自己动手处理任何一项具体工作------这是 persona 中"你不直接处理任何用户请求"的约束生效。三个 Teammate 各自只认领了自己的任务，没有出现"抢活干"的情况。

5.2 第二步：追加需求，观察越界响应

工作流进行中，你继续追加了几个操作指令。

你发送：

查询员，订单 #67890 发货超时了，你直接给李四发一条道歉短信吧。另外投诉专员，张三这个订单的物流问题帮我建一个工单跟踪一下。

这条消息包含两个越界请求，用来观察角色是否会守边界：

• 查询员收到"给李四发道歉短信"------这不是查询职责，查询员识别出"发送短信"不在自己的能力范围内，向 Leader 反馈而非自行处理。persona 中"收到非查询类的请求时，向调度主管反馈，不要自行处理"的约束生效

• 投诉专员收到"建一个工单"------同样不是投诉专员的职责，投诉专员向 Leader 反馈，由 Leader 重新分配给工单处理员

两个角色都没有越权执行，而是把超出职责的请求交还给 Leader 重新分配。这就是 persona 反向约束（"你不负责 XXX"）在实际交互中的作用------不靠硬编码的权限拦截，而是从行为意图层面阻止越界。

5.3 第三步：跨角色协作，验证职责不重叠

你发送：

订单 #12345 的客户张三刚才来电投诉物流太慢。投诉专员请基于订单数据分析投诉严重程度并给出处理建议，查询员同步查一下这个订单的物流最新进展。

这条消息同时需要查询员和投诉专员协作：

• 查询员只回复物流信息------订单 #12345 已发货5天、承诺3天、超期2天、顺丰单号 SF123456

• 投诉专员基于查询员提供的信息，分析投诉严重程度------超期2天属于中等严重，建议主动联系客户道歉并补偿运费

两个角色协作但互不越界。投诉专员没有重复去查物流信息（那是查询员的事），查询员没有插手投诉分析和处理建议（那是投诉专员的事）。各自在自己的职责边界内完成工作，通过 Leader 中转信息完成协作。

5.4 效果总结

整个工作流下来，三个角色边界机制的表现：

|--------|--------------------|-----------------------------------|
| 阶段 | 发生了什么 | 边界如何起作用 |
| 启动工作流 | Leader 拆解任务、三人并行处理 | Leader 只调度不执行（persona 身份层） |
| 追加越界请求 | 查询员拒绝发短信、投诉专员拒绝建工单 | 角色向 Leader 反馈而非越权执行（persona 反向约束） |
| 跨角色协作 | 查询员查物流 + 投诉专员分析投诉 | 两人协作但不重叠（职责互斥 + 技能隔离） |

六、写在最后

回到开头的那个问题：V2 的三个角色为什么"抢活干"？根本原因是把 Teammate 当工具调用------给了名字但没给边界。三个"全能选手"在同一个任务空间里，抢活干是必然结果。

JiuwenSwarm 的五层边界体系提供了一套完整的隔离方案。身份限定意图、技能限定能力、工具限定手段、Rail 限定行为、权限限定触达。每层单独看都不复杂，但组合在一起形成了一套实用、可控的角色隔离方案。

几个值得强调的设计决策：白名单过滤确保新增能力需要显式授权；角色差异化的 Rail 让 Leader 和 Teammate 的行为逻辑天然不同；persona 的双向锚定从源头约束了 LLM 的行为意图。

配置层面，本文给出的角色边界设计模板可以直接套用------先想清楚 role / responsibilities / capabilities / forbidden 四个要素，再翻译成 JiuwenSwarm 的 YAML 配置。建议从"最小继承"策略开始，观察运行情况后再逐步放宽。

---

**参考资料：**​​​​​​​

• https://atomgit.com/openJiuwen

• https://www.openjiuwen.com