一项复杂任务可以拆给不同角色，但多一个角色也多一次交接。对第一次 JD 整理，一个 Agent 通常就足够；当公司研究与独立核查可以分开时，再考虑多角色协作。
本书给一个设计例子：研究者整理公司公开证据；核查者逐条回看来源；主负责人把差异合并成可用研究表。研究者不能替核查者宣布“全部正确”，核查者也不改变客户确认过的岗位要求。
| 角色 | 收到什么 | 必须交什么 |
|---|---|---|
| 研究者 | 基线与来源范围 | 事实、链接、日期、未知 |
| 核查者 | 研究表与原始来源 | 支持/不支持/无法核实及依据 |
| 主负责人 | 两份报告 | 冲突处理、保留限制、最终草稿 |
宽表格可左右滑动查看
把“请你们合作研究一下”改成这样的交接约定，输出才容易合并。拆分收益应来自独立信息处理，而不是让三个人重复读同一份短 JD。
WorkBuddy 的专家与专家团提供角色入口，具体召唤与创建流程见官方专家说明。界面上的一个专家角色不等于一个拥有独立权限和独立上下文的子 Agent，不同宿主的执行方式需分别确认。
首次可以由你人工开启两个任务、传递同一份脱敏资料，再合并结果。这个演练验证的是分工是否清楚，不是证明已经部署多 Agent 系统。只有当合并成本低于获得的价值，并且你能定位错误来自哪一步，才值得进一步自动化。