简介：摘要：本文面向需要把通用对话助手升级为“多角色智能体团队”的开发者与技术负责人，以“同事化”分工为设计原则，系统讲解角色设计、交付标准定义、任务交接协议、共享工作台、并行调度与安全治理的完整搭建过程，并提供示意配置、通用伪代码、验证清单与排查思路，帮助读者构建可并行协作、可控成本、可观测可运维的智能体团队。
近两年，个人智能体（Personal Agent）市场的竞争焦点正在从“谁的模型更强”转向“谁能把智能体稳定、持续地嵌入个人与团队的真实工作流程”。同类产品的实测观察显示，增长较快的一类形态并没有发明新的模型能力，而是把“同事化”的交互思路与已有的模型、云电脑、工具调用等技术结合，做好产品化设计，从而带来可观的付费用户增长与留存。
所谓“同事化”，核心是改变用户给 AI 分配工作的方式。面对一个“什么都能做”的通用对话框，用户每次都要想清楚：这次让 AI 扮演谁、要补充哪些背景、该调用什么工具、按什么标准交付。而“同事化”的产品把 AI 呈现为一个个有名字、有职责、有工作背景的“同事”。例如研究员负责找资料，作者负责出稿，助理负责安排时间，还能被拉进同一个“群”里互相发消息、交接任务。用户面对熟悉的角色分工，自然就知道该怎么派活、该向谁要什么结果。
本教程的目标是：从零搭建一套最小可用的多智能体团队协作系统。它至少具备以下能力：
完成本教程后，读者将得到一套“声明角色 → 注册技能 → 编排交接 → 校验交付”的可扩展框架，并可根据自身业务在此基础上增加角色和能力。
适用读者：
适用场景：
前置知识：
| 类别 | 准备内容 | 作用 |
|---|---|---|
| 模型服务 | 开通大语言模型服务，申请访问凭证；如涉及多模态，同时确认图像/文档理解能力可用 | 提供智能体的推理与生成能力 |
| 任务调度 | 一个异步任务框架或消息队列 | 支撑角色并行执行与任务交接 |
| 状态存储 | 关系型数据库、对象存储、缓存各一 | 分别保存任务状态、产出文件、高频上下文 |
| 观测体系 | 集中式日志、指标监控与告警 | 定位交接失败、评估成本与延迟 |
| 运行时 | 容器平台或函数计算类服务 | 隔离部署，按角色独立扩缩容 |
| 权限体系 | 身份认证与访问控制 | 区分用户、角色与工具调用权限 |
如果在百度智能云上落地，可组合使用容器平台、对象存储、消息队列、数据库、日志服务与监控告警等通用能力，构成上述基础设施。
在动手编码前，建议先准备三份材料：
缺少这三份材料就开始写提示词，是“角色串味”和“交付不可控”的最常见根源。
在展开步骤之前，先明确“同事化”在多智能体系统中的技术含义。它可以拆解为四个转变，后续每一步都围绕它们展开。
转变一：从“单次提问”到“持续岗位”。 单轮对话中，用户每次都要重新描述上下文。角色化之后，智能体的身份、方法与背景沉淀在角色档案中，用户只需描述目标和约束条件。这样，提示词从“一次性输入”变成了“可版本化的配置资产”。
转变二：从“角色描述”到“分工边界”。 角色描述是“你是负责研究的人员”这类一句话设定，分工边界则明确该角色的输入是什么、输出是什么、依赖谁、被谁依赖。只有边界清晰，并行执行才不会出现多个智能体重复劳动、产出互相覆盖的情况。
转变三：从“人工搬运上下文”到“协议化交接”。 用户把研究员的结果复制给作者，是典型的隐性成本。协议化交接要求每次传递都携带任务标识、版本号、产出引用和验收标准，使交接可追踪、可重放、可校验。
转变四：从“尽力而为”到“可验收交付”。 对同事的要求从来不是“说点什么”，而是“按标准交付”。因此每个角色都必须有结构化的交付契约和自动校验逻辑，把质量判定前移到运行时。
做什么： 先画一张角色关系图，明确每个角色的输入、输出和上下游关系。以研究写作场景为例：
| 角色 | 核心职责 | 输入 | 交付物 | 上下游 |
|---|---|---|---|---|
| 研究员 | 拆解问题、检索资料、交叉核验 | 用户诉求、检索范围 | 带来源的结论清单 | 上游：用户；下游：作者 |
| 作者 | 按结论与风格规范成稿 | 结论清单、风格手册 | 结构化初稿 | 上游：研究员；下游：审校 |
| 审校 | 事实一致性、合规、文风检查 | 初稿、结论清单 | 修改意见或终稿 | 上游：作者；下游：用户/排期 |
| 助理 | 日程、提醒、信息归集 | 用户日程与待办 | 日程变更、提醒 | 与其他角色并行 |
为什么做： 角色数量与边界直接决定系统的复杂度和成本。角色过少会导致单角色承担过多职责、上下文膨胀；角色过多会带来频繁交接，延迟与费用同时上升。实践中 3～6 个角色通常够用，且必须满足“单一职责”原则：一个角色只解决一类问题，不设计成“什么都能干”的通用体。
注意： 不要为了“看起来丰富”而设置研究、写作、翻译、法务、财务等一堆角色。若某一类任务的出现频率低于总任务的 5%，更适合作为现有角色的一个“技能”存在，而不是独立角色。
做什么： 为每个角色编写一份结构化的角色档案，建议包含五个字段：
# 角色档案示例（示意，非任何产品专有格式）role: researchername: "资料研究员"avatar: "assets/researcher.png"scope: # 职责边界：明确“做什么、不做什么”do: ["拆解检索问题", "多来源交叉验证", "输出带引用来源的结论清单"]dont: ["撰写完整文稿", "对结论做价值判断", "编造未检索到的来源"]method: # 工作方法：决定输出质量的稳定度- "先将问题拆为可独立检索的子问题"- "每个子问题至少检索两个独立来源"- "来源冲突时并列呈现，并说明分歧点"background: # 背景设定：让语气与视角符合角色- "长期从事行业调研，习惯以数据和出处说话"- "汇报风格：结论先行，证据在后"skills: ["web_search", "document_reader", "citation_formatter"]
为什么做： “scope”解决的是串味问题，“method”解决的是稳定性问题，“background”解决的是体验一致性问题。三者分工明确，才能在更换底层模型时保持行为一致，这也是角色档案与模型解耦的关键。
注意：
做什么： 为每个角色定义结构化输出契约，并配套自动校验规则。
// 研究员交付契约（示意）{"task_id": "T-20260812-001","role": "researcher","version": 3,"findings": [{"claim": "多智能体分工在长流程任务中的完成率优于单智能体","sources": ["src://a", "src://b"],"confidence": "medium","conflict": "来源B的样本量较小"}],"open_questions": ["缺少中文场景的数据支撑"]}
为什么做： 结构化契约带来三个直接收益：一是交接时接收方可直接解析，不需要二次理解自然语言；二是可用代码自动校验，把不合格产出拦在交接之前；三是可统计质量指标，例如“单任务平均返工轮次”。
注意： 校验规则应当是“可执行”的，例如必填字段完整性、来源数量下限、置信度枚举值合法性、版本号单调递增。避免使用“内容要专业”这类无法自动判定的标准。
这是整个系统的核心，也是最容易出错的地方。一个健壮的交接消息至少应包含：
// 交接消息（示意）{"message_id": "M-0007","task_id": "T-20260812-001","from": "researcher","to": "author","type": "deliverable_ready","artifact_ref": "oss://bucket/tasks/T-20260812-001/findings.v3.json","summary": "已核验 7 条结论，2 条存在来源冲突","constraints": { "deadline": "2026-08-13T18:00+08:00", "max_retries": 2 },"idempotency_key": "T-20260812-001:researcher:v3:author"}
四个字段缺一不可：
为什么做： 没有幂等键的交接，在异步重试场景下会出现“同一份资料被写入两次”；没有产出引用的交接，会把大段文本塞进提示词，直接推高上下文长度和费用。
注意： 交接应设定最大轮次上限。两个角色互相退回任务（俗称“踢皮球”）是多智能体系统的经典故障模式，必须在协议层用轮次计数熔断，超过上限后升级人工介入。
做什么： 搭建三类共享资源：
task_id/role/version 分目录；为什么做： 共享工作台替代了“用户复制粘贴”的协作方式。研究员把结论写入共享空间，作者直接从约定路径读取，用户只需在看板上确认进展。这是“同事协作”与“多次独立对话”的本质区别。
注意：
做什么： 实现调度器的三条基本规则：
# 调度逻辑示意（伪代码）def schedule(tasks, agents):ready = [t for t in tasks if not t.blocked_by]running = []while ready or running:# 1) 空闲角色认领无依赖任务，实现并行for t in list(ready):agent = find_idle_agent(t.required_skill)if agent:running.append(agent.execute(t))ready.remove(t)# 2) 等待最先完成的任务done, running = wait_any(running)# 3) 依据交接协议解锁下游任务for r in done:if r.status == "delivered":unlock_downstream(r, tasks)else:requeue_or_escalate(r, tasks)ready = [t for t in tasks if not t.blocked_by]return collect_results(tasks)
为什么做： 只有并行调度才能让“一支团队”真正快于“一个人”。同时，冲突控制必须显式设计：同一文件或同一数据记录被两个角色并发写入时，应使用版本号加乐观锁，或使用任务级互斥锁，避免出现“后写覆盖先写”导致产出丢失。
注意： 要为每个角色设置并发上限。角色并行度过高会同时放大模型调用配额压力与速率限制风险，通常每个角色 1～2 个并发实例即可满足大多数场景，再按监控数据调整。
做什么：
为什么做： 多智能体系统的成本通常呈“倍数放大”特征：一个任务被三个角色依次处理，模型调用次数就是单智能体的三倍以上，加上返工轮次，很容易失控。权限不清则可能导致智能体执行用户并未授权的操作。
做什么： 至少采集四类指标：
| 指标 | 含义 | 用途 |
|---|---|---|
| 任务完成率 | 成功交付任务 / 总任务 | 评估整体可用性 |
| 平均返工轮次 | 每任务被退回次数 | 判断角色档案与交付契约是否需要调整 |
| 单任务成本 | token 消耗与工具调用费用 | 成本治理与配额决策 |
| 交接延迟 | 上游交付到下游开始执行的耗时 | 定位调度瓶颈 |
为什么做： “同事化”系统的问题往往不是模型不行，而是流程卡点。例如返工轮次偏高，通常说明角色档案中的方法约束不足；交接延迟偏高，通常是并发上限或队列配置问题。有了指标，优化才有方向。
| 配置项 | 含义 | 常见取值逻辑 | 风险 |
|---|---|---|---|
role.scope.do/dont |
角色职责边界 | 每角色 3～7 条，动词开头 | 过宽导致串味，过窄导致无法完成任务 |
max_handoff_rounds |
最大交接轮次 | 3～5 轮 | 过小导致复杂任务被熔断，过大导致循环消耗 |
max_concurrency_per_role |
单角色并发实例数 | 初始 1～2，按监控调整 | 过高触发速率限制 |
context_budget_tokens |
单次调用上下文预算 | 依模型窗口设定，预留 30% 余量 | 溢出导致截断或报错 |
task_timeout_seconds |
单任务超时 | 依历史 P95 耗时 × 1.5 | 过短造成误杀，过长占用资源 |
retry_policy |
重试策略 | 指数退避，最多 2～3 次 | 无上限重试会放大成本与故障 |
artifact_retention_days |
产出保留天数 | 依合规要求，常见 30～180 天 | 过短无法追溯，过长增加存储成本 |
其中 max_handoff_rounds 与 retry_policy 需要区分：前者治理“业务层反复退回”，后者治理“技术层调用失败”。两者混用会导致技术故障被当作业务返工处理，掩盖真实问题。
做什么： 用准备好的 20 条以上真实任务样例执行回归验证，逐条检查：
判定标准建议： 以“返工轮次 ≤ 1”作为质量达标线，以“任务零丢失”作为可靠性底线。两项均不达标时，优先修正角色档案与交接协议，而不是更换模型。
问题一：角色串味，研究员开始写长文。
原因：角色档案中的禁止事项不可判定，或团队级指令与角色指令冲突。
排查：抽取该角色的历史输入，检查系统指令中是否存在职责重叠描述；将禁止事项改为可校验约束，并在校验层拦截越界产出。
问题二：两个角色互相退回任务，消耗居高不下。
原因：缺少轮次熔断，或验收标准主观化导致接收方总能找到“不满意”的理由。
排查：检查 max_handoff_rounds 是否生效；将验收标准从主观描述改为结构化规则校验，把判定权交给代码而非模型。
问题三：交接后下游角色“不知道要做什么”。
原因：只传递了产出引用而未提供任务上下文与约束条件。
排查：确认交接消息中的 summary 与 constraints 完整；检查共享空间的访问权限是否对下游角色开放。
问题四：上下文溢出或响应变慢。
原因：历史消息全量累积，产出全文被塞进提示词。
排查：统计单次调用的上下文构成，将超过预算的部分改为引用加摘要模式；对长期记忆做检索式注入而非全量注入。
问题五：成本突然上升数倍。
原因：无预算熔断、并发过高、或重试策略缺失导致失败请求反复调用。
排查：按角色与任务维度拆分账单，定位异常来源；补充 token 预算与超时上限，为重试增加退避与上限。
问题六：并行时产出互相覆盖。
原因：多个角色写入同一路径或同一条记录，缺少版本与锁机制。
排查：检查共享空间目录规范是否按角色与版本隔离；对数据库记录写入使用乐观锁或任务级互斥。
“同事化”之所以有效，并不是因为带来了更强的模型，而是因为它把用户的心智负担从“构造一次完美提示词”转移到“给合适的同事派活、按合理标准验收”。落到工程实现上，这套思路可以归纳为五件事：角色档案定义身份与边界，交付契约定义质量，交接协议定义协作，共享工作台定义上下文，调度与治理定义效率与安全。
按本教程的八个步骤依次落地，读者可以搭建出一套可并行、可交接、可观测、可治理的迷你智能体团队。后续可以继续深入的方向包括：基于历史任务的角色自动优化、跨角色的冲突消解策略、面向团队场景的多人共享记忆机制，以及在百度智能云等云平台上的弹性伸缩与高可用部署方案。建议以真实业务任务为驱动，先让 3 个角色跑通一条完整链路，再逐步扩展角色与场景。