---
title: 开发 AI 团队模板
description: 用固定成员、资源关系和协调员工组织可复用团队。
lastVerified: 2026-10-23
---

# 6.3 开发 AI 团队模板

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

## 在平台用自然语言创建 {#create-in-chat}

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

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

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

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

<figure class="guide-screenshot">

[![自然语言创建的团队接收结果](https://docs.teloa.ai/assets/screenshots/nl-create-team.jpg)](https://docs.teloa.ai/assets/screenshots/nl-create-team.jpg)

</figure>

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

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

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

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

2. 初稿返回后，在**同一话题引用初稿并 @反馈复核员**：“核对分类、计数和引用。CSV 编码报错应为 2 条（F1、F3），深色模式为 1 条（F2）；说明通过或具体错误，不推断客户身份。”
3. 看到真实复核意见后，**@反馈分析员**：“根据本话题的复核意见修改并交付最终简报；未解决的问题保留为待确认。”

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

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

## 完整示例

[下载团队开发示例](https://docs.teloa.ai/examples/resource-authoring-024/team.zip)。解压 `team.json`，在 **员工 > 导入模板** 中预览。示例包含撰写与复核两位员工，共用 `evidence-brief` 技能，没有账号连接或定时执行。

## 定义成员与协调者

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

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

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

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

## 依赖与准备

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

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

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

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

```json
{
  "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` 等完整字段。共享方法可以复用；岗位目标和交接标准应分别明确。

### 把分工落实到包内引用

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

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

```json
{
  "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 清单中支持，见[资源包](https://docs.teloa.ai/markdown/develop/packages.md)。

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

## 验证完整路径

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

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

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

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

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

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

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

更新任一成员定义或方法，使用新固定版本并核对全部引用。通过[离线或在线分享](https://docs.teloa.ai/markdown/guides/sharing.md)分发固定副本；发布到官方市场另走审核投稿。