6.3 开发 AI 团队模板

团队模板把多位员工与共同方法组织起来，接收后仍需配置和授权。协作群、模板定义与某次任务的临时执行小组是不同对象。

在平台用自然语言创建

本节示例已用真实 MiniMax 验证；相关修复已包含在 0.2.10 中。截图使用虚构反馈，生成内容以实际模型输出为准。

打开 市场 > 创建 > 创建 AI 团队。输入以下说明，点 继续，到会话中核对并发送：

制作一个“反馈改进团队”模板，包含两位员工：
1. 反馈分析员：归类我给出的编号反馈，统计数量，提交带来源的初稿。
2. 反馈复核员：核对分类、计数和引用，列出错误与遗漏，交回分析员。
由反馈分析员协调，复核通过后交付最终简报，未通过继续修改。
两位员工共用“反馈简报方法”，技能标识用 feedback-brief-method；
只处理我提供的文字。不带账号、密钥、自动化或外部工具授权。
这是原创示例，采用 MIT 许可。先生成完整团队模板供我预览。

核对两位员工的分工、协调者、共享方法和关联关系，点 预览并分享。导出文件或生成在线链接，再从 员工 > 导入模板 接收。确认添加成员及安装随包方法后，点 组建 AI 团队；核对实际群成员、默认模型和技能绑定，恢复需要工作的员工。

本地 MiniMax 实测：两位员工和共享方法已接收。组建协作群、配置及启用员工后，才开始工作。 点击图片查看原图。

在群里完成三步试做。使用输入框的 @ 选择真实员工，不能只在正文写它的名字：

1. @反馈分析员，请它按共享方法整理下面三条反馈：

   按原编号计数，不自动去重；分类并统计数量，保留来源。
   [F1] 导入 CSV 时提示编码错误。
   [F2] 希望支持深色模式。
   [F3] 导入 CSV 时提示编码错误。
   先提交初稿，待复核后再定稿；只在群内处理文字。

2. 初稿返回后，在同一话题引用初稿并 @反馈复核员：“核对分类、计数和引用。CSV 编码报错应为 2 条（F1、F3），深色模式为 1 条（F2）；说明通过或具体错误，不推断客户身份。”

3. 看到真实复核意见后，@反馈分析员：“根据本话题的复核意见修改并交付最终简报；未解决的问题保留为待确认。”

核对两位员工的实际响应与最终稿。模板里的交接说明不会自动生成顺序任务依赖；仅看到一位员工回复，还没有完成复核。

如果两位员工已经存在，可在普通会话要求“查看员工目录，用现有的反馈分析员和反馈复核员创建‘反馈改进’协作群；先核对成员，不新建同名员工”。核对后确认建群。具体操作见在群里带领员工。

完整示例

下载团队开发示例。解压 team.json，在 员工 > 导入模板 中预览。示例包含撰写与复核两位员工，共用 evidence-brief 技能，没有账号连接或定时执行。

定义成员与协调者

外层使用 teloa.template-share/v2、subject: "team"，内部至少两项 kind: "role" 资源。每位员工都是完整 teloa.role/v1，含五组结构化职责，写明各自输入、输出与交接条件。示例协调者声明为：

{"team":{"coordinatorResourceId":"employee-0"}}

协调者必须指向包内已有员工资源 ID，不是本人账号或员工实例 ID。这只是模板协调约定，不给该员工扩权。

在 teloa.json.resources 声明每个员工和技能的固定版本及本地路径。示例用两条 role-skill 关系，将两位员工分别关联同一方法。单一资源路径只对应一项资源；不要靠同名或文件排列顺序推断关联。入口只可指向技能或工作模板，不是员工。

依赖与准备

先设计工作分工，再写成员 JSON

以“资料简报团队”为例，先约定以下交接。下表是作者的工作设计，不是额外的 JSON 协议字段：

成员	接收输入	交付输出	不负责的动作
Evidence writer	用户的编号笔记与验收要求	带来源的初稿和未知项	不宣布自己的初稿已复核
Evidence reviewer	同一份笔记与撰写员的初稿	逐项通过／需改／无法核实和原因	不增加没有来源的新事实
协调者，由 writer 承担	本轮目标与两人的结果	整理最终稿、保留复核意见	不把成员已回复等同于用户已验收

下载示例已分别写好撰写员和复核员的岗位文件。修改自己的团队时，分别调整两人的职责、接手条件与交付检查。下面是复核员需要表达的内容，放入员工模板所示的完整定义：

{
  "duty": "Review a draft against the supplied source notes. Return specific corrections and unresolved issues.",
  "responsibility": {
    "triggers": ["When assigned source notes and a draft to review."],
    "autonomousActions": ["Check each claim, number and citation against the supplied notes."],
    "confirmationPoints": ["Ask before accessing additional material or distributing the draft."],
    "escalationRules": ["Identify unsupported claims and conflicting evidence without inventing a resolution."],
    "deliveryChecks": ["For each issue, identify the claim, source, correction and any remaining uncertainty."]
  }
}

这是需要替换的字段片段，不能单独作为员工文件导入。保留 format、name、kind、dataScope 和 executionScope 等完整字段。共享方法可以复用；岗位目标和交接标准应分别明确。

把分工落实到包内引用

sources/
  teloa.json
  roles/employee-0.json               # 撰写与协调
  roles/employee-1.json               # 独立复核
  skills/evidence-brief/SKILL.md       # 共同方法

清单内的关键引用如下；完整清单请使用下载示例，不能只导入这个片段：

{
  "relations": [
    {"kind":"role-skill","from":"employee-0","to":"evidence-brief"},
    {"kind":"role-skill","from":"employee-1","to":"evidence-brief"}
  ],
  "entrypoints": ["evidence-brief"]
}

外层 team.coordinatorResourceId 仍填 employee-0。team 放在分享包外层，relations 放在内部清单中；不能把协调者的运行实例 ID 填进包里。包内每位员工单独声明为资源，共用技能只声明一次，再通过两条关系关联。

先交办撰写，再把初稿交给复核员。在协作群里明确 @ 对应员工，并核对实际接手者。模板中的文件顺序不会自动安排执行。

优先做不依赖外部系统的小团队。增加连接时声明 connections 能力，并提供无凭据的连接声明；账号与工具权限由接收方另行配置。加入计划时声明 automation，写明触发条件与消耗，接收后按实际页面由本人启用。完整业务配置仅在内部 v4 清单中支持，见资源包。

修改后运行 node pack.mjs team.json，再预览更新后的团队。

验证完整路径

按校验方法检查格式，再确认预览有两位员工、正确协调者与方法。接收时核对目标业务及资源选择；添加完成后按页面提示组建协作群，核对成员和默认暂停状态，再启用需要的员工。用虚构资料验证撰写、复核和最终交付的来源，不把模板已添加当成协作已执行。

添加成员后点 组建 AI 团队：核对群名称，点 下一步，核对撰写员、复核员和协调员工，再点 创建协作群。示例群共有三位成员（包含本人）；员工保持暂停，配置并启用后再交办。

可以用员工教程的 N1–N3 笔记完成一次闭环：

1. 先让撰写员交付简报，检查实际回复来源和成员身份。
2. 交给复核员时，故意把初稿中的总反馈数改成 21，要求逐条核对；应指出 N1 与 N2 相加为 20，不能照抄错误。
3. 将修正意见交回撰写员，要求形成最终候选稿，并保留仍无法确定的新老用户分布。
4. 中途暂停或停止一项测试工作，核对它没有被其他成员的回复误标完成；刷新后查看结果和任务来源。
5. 以未配置外部连接的接收环境再次预览，确认仍能看到要求和依赖，不能继承作者的账号、密钥、群历史或审批。

验收至少留下输入、两位成员的任务与结果、纠错记录、停止结果和安装版本。只检查“群里有两个人”无法证明团队能完成协作；成员未接手、来源不清或结果缺失都应保留为未通过。

问题	检查方法
被识别为单个员工	subject 应是 team，包内至少两位员工
协调者不存在	指向清单中 kind: role 的资源 ID
只有一人有方法	每位需要该方法的员工都有自己的 role-skill 关系
成员重复回答、互相接错工作	缩小职责和触发条件，明确交接输入与输出，核对实际接手者
添加后没有自动开工	接收只安装定义；配置、启用、组群和明确交办分别完成
更新后旧群没变化	固定副本不自动继承新版本；先预览差异，再按产品入口接收与调整

对外集成当前按单名员工创建凭据。若由协调员工对接业务系统，仍应分别验证其实际协作权限；不能假定团队分享包就是一个已支持的“团队 API”。

更新任一成员定义或方法，使用新固定版本并核对全部引用。通过离线或在线分享分发固定副本；发布到官方市场另走审核投稿。