WorkBuddy 实战手册
WorkBuddy 实战手册

Appearance

Expert / 专家团 / Agent 拆分与验收 ​

本章目标 ​

面对一项复杂工作，最容易出现的误区是先增加角色，再想任务怎么做。更稳妥的顺序是先定义交付物、输入、判断标准和风险，再判断普通任务、Skill、Expert、专家团、Agent 或多 Agent 哪一层足够。本章关注任务拆分、协作责任和验收，不把角色数量当成能力证明。

产品事实与实施方法：官方资料和现有公开页支持普通任务、Skill、专家、专家团以及企业智能体等概念的区分；具体创建入口、可见范围、工具权限、运行方式和企业租户能力必须以当前产品页面和实际账号为准。下文的分工表、交接模板、评分表和人工闸门属于实施方法，不代表平台内置同名流程。

一、先选择最小够用的层级 ​

层级主要解决什么适合的信号不能替代的责任
普通任务直接回答或完成一次边界清楚的工作输入和输出短，过程不需要复用人对事实、权限和最终结果负责
Skill固化重复任务的方法、资料和输出约定同类任务多次发生，规则稳定不会自动解决目标不清或数据缺失
Expert用固定领域或岗位视角分析和处理问题需要稳定的方法框架或专业关注点不等于专家资质或自动正确
专家团让多个视角围绕一个目标分工协作研究、数据、写作、审核等工作包可拆不会自动消除冲突和交接成本
Agent在明确目标下持续执行多步任务或工具动作需要状态、工具、规则和停止条件不替代权限审批和人工接管
多 Agent让多个 Agent 处理可并行或有依赖的工作包任务可以明确交接、汇总和复核不能因为“都完成”就跳过总验收

一个简单判断顺序是：一次性问题先用普通任务；规则稳定再考虑 Skill；需要岗位视角再考虑 Expert；可以拆成独立工作包才考虑专家团或多 Agent；需要持续运行、工具动作和状态管理时，再评估 Agent。若拆分后每个角色只是在重复同一段 Prompt，应退回更小的方案。

二、用工作包而不是角色名称来拆 ​

先写最终交付物，再把它拆成工作包。每个工作包都要有唯一的输入边界、责任人、输出和验收点。

字段要回答的问题例子
输入这个角色实际读取哪些资料？是否完整？脱敏销售明细、指标定义和上期报告
责任它负责产生什么判断或产物？不负责什么？只负责异常分类，不负责改写原表
输出下游拿到什么可检查的交接物？异常表、证据位置、未决问题
上下游前置产物是谁提供，谁消费？数据清洗 → 指标解释 → 汇报草稿
判断权哪些决定可以自动做，哪些必须由人批准？规则分类可自动，发布结论由业务负责人批准
工具是否需要文件、连接器、API 或其他能力？只读表格处理，不开放外发
权限能读、写、发送或删除什么？读测试目录，只写自己的输出目录
验收用什么证据判定完成？数字可回溯、格式通过、异常未被吞掉

建议给每个工作包使用结构化交接物，而不是依赖长对话记忆：

text
工作包：
负责人：
输入与版本：
已完成：
关键结论与证据：
未决问题：
输出位置：
禁止动作：
验收状态：通过 / 待确认 / 失败

三、什么时候按岗位拆角色 ​

复杂任务常见的候选角色包括研究、数据、写作、审核、设计、执行和项目管理，但角色名称不是拆分依据。拆分前问四个问题：它是否有独立输入？是否有不同的判断标准？是否需要不同的权限？它的输出是否可以被下游单独检查？如果四个问题都答不上来，就不应单独增加一个角色。

以“把多份业务资料整理成季度汇报”为例：

  • 研究工作包只登记来源、事实、时间范围和证据，不替业务下结论；
  • 数据工作包负责字段、口径、异常和计算结果，不修改原始明细；
  • 写作工作包根据已确认事实组织叙事，不把缺失资料补成确定结论；
  • 审核工作包检查完整性、数字一致性、来源和敏感信息；
  • 发布工作包只在人工批准后生成外发副本或通知。

项目负责人可以统筹依赖和停止条件，但不应让“总负责人”变成没有具体输出的空角色。每个角色都需要唯一价值和唯一责任边界。

四、串行、并行与汇总 ​

使用依赖关系决定协作方式，而不是为了速度默认并行：

  1. 串行。 下游必须等待上游事实、字段或版本确认时，按顺序执行。例如先完成数据清洗，再做指标解释。
  2. 并行。 工作包输入独立、不会写同一份关键文件时，可以同时进行。例如多个研究员分别核对不同来源。
  3. 汇总。 并行结果必须回到一个统一格式，由总负责人检查缺口、冲突和重复，不直接拼接所有输出。
  4. 复核。 事实、权限、敏感信息和外发动作需要独立检查，不能由产出者自证全部正确。
  5. 人工介入。 输入不完整、结论冲突、工具失败、权限不足或任务跨出原范围时，暂停并交给人处理。

冲突处理要留下原始意见、证据位置和决定人。不要把冲突简单投票，也不要让后运行的角色静默覆盖先前已经确认的结果。

五、验收：完成不是通过 ​

Agent 或专家团显示“已完成”，只表示某个运行分支结束，不等于最终任务合格。至少按下表验收：

维度检查问题失败时怎么处理
Completeness 完整性任务卡要求的字段、文件、步骤和限制是否都覆盖？列出缺口，退回指定工作包
Correctness 正确性结论能否回到输入和规则，是否有事实错误？标记错误主张，重新核对来源
Evidence 证据关键数字、判断和引用是否有位置和版本？不能补猜，转人工或补证据
Consistency 一致性多个产物中的名称、数字、版本和结论是否一致？以批准的主版本为准重新汇总
Output format 格式文件、表格、字段、命名和目录是否符合约定？只修格式，不掩盖内容缺口
Business requirement 业务要求结果是否解决真正的问题，而非只完成形式？由业务负责人判断是否返工
Human approval 人工批准是否有人确认写入、发布、外发或高风险动作？保持草稿或停用动作

可把结果分为“通过”“待确认”“失败”三态。只有业务负责人和安全责任人完成必要批准后，才允许进入发布或真实写入阶段。

六、常见失败与纠偏 ​

角色过多。 每个角色只产生一句相似摘要，交接成本已经超过收益。合并角色，先跑通一个 Agent 或普通任务。

职责重叠。 两个角色都能修改同一份文件，最后无法解释谁的结果生效。为关键文件指定唯一写入负责人，并让其他角色只提交差异或建议。

没有最终 owner。 多个角色都完成了自己的步骤，却没人对最终结果负责。开始前指定总负责人和人工批准人。

Agent 相互复制。 下游没有读取上游交接物，而是重新处理同一批输入。固定交接格式和证据位置，禁止无依据重算。

输入不完整。 任务缺少版本、权限或关键字段时仍继续执行。把缺口列为阻断条件，不要让模型猜测。

输出没人验收。 只看运行状态、字数或文件生成成功。回到完整性、正确性、证据、一致性、业务要求和人工批准七项检查。

相关内容 ​

来源引用 ​

内容版本与核对日期 ​

  • 内容版本：0.1.0
  • 最后核对日期：2026-09-26
  • 适用版本状态：专家、专家团、Agent、工具和企业权限以当前产品版本、租户策略和实际权限为准。
  • 来源提交版本：6b5e2403f0f2ad5d3f7ab7a67e9c4d4113583ff3

章节导航 ​