# 工作组模板

> 工作组模板是一张由角色和连线组成的 Graph，主助手照它组建工作组。怎么搭建、连线、校验、导入和导出。

**工作组模板**写的是一类活怎么分工：哪些角色参与、谁可以把活交给谁、结果怎么验收。主助手把一个事项的活派出去时，会新开一次某个模板的运行，这次运行就是一个[工作组](../working-groups)。

模板就是 Graph：编辑页、它的标签（**Graph**）以及所有运行里的运行，都还这么叫。在**团队与工具**上，工作组卡片的**看看它会什么**会在这个编辑页里打开它的模板，编辑页的列表（**Graphs**）里列着空间的模板；其他编辑页旁边的 **Graph** 标签也能打开它。

## 模板怎么变成工作组 [#模板怎么变成工作组]

* 主助手看得到空间里的每个模板，以及它描述的前 800 个字符，按描述为每件活挑一个。项目里的软件活交给 `polished_software_dev`，工作室对口的活交给对应的工作室，普通的多步工作交给 `chat`。
* 每派一次活，就新开一次这个模板的运行，在这件活所属的文件夹里干。你的要求按你的原话交给模板的入口 Agent；从那以后，事项看板上的一张**工作组**卡片跟着这个组。
* 一个模板可以同时有几个工作组在干活，各自为不同的事项。团队与工具上它的卡片写着这些事项，比如**在为 2 件事干活：**，后面是事项的标题。
* 主助手可以只为某一个工作组的这次运行换模型，不用改模板，比如你要求某件活用更强的模型时。
* 保存模板之后新组建的工作组用新版本。对角色的修改，连正在干活的 Agent 也会在下一轮用上。

主助手是按描述挑模板的，所以描述要写给它看：这个模板适合什么活，不适合什么活。

## 搭一个模板 [#搭一个模板]

1. 在列表（**Graphs**）里选**新建 Graph**，填上**蓝图 ID**（主助手和模板文件用的名字）和**描述**。
2. 用**新增节点**添加节点。每个节点都是一个活的 Agent，必须绑定一个[角色](./roles)：选中节点，在**节点检查器**里选它的 **Agent 预设**。
3. 同一个检查器里，\*\*自定义系统提示词（追加）\*\*只为这个节点在角色自己的提示词后面再加一段，所以同一个角色可以在不同模板里担任不同的分工。**节点插件**只给这个节点添加整个插件；节点已经从角色或整个模板拿到的插件，会标着它们来自哪里。
4. 从一个节点的输出口拖到另一个节点的输入口，把它们连起来；再选中这条连线，写它的移交说明（见下文）。
5. 在检查器里点**应用修改**，再点**保存**（Cmd/Ctrl+S）。

模板名字旁边的铅笔用来改它的 ID 和描述。**开始任务**在任何事项之外把模板跑一次，和所有运行里的**新建 Graph** 一样，适合试一试模板。

![选中一条连线的 Graph 编辑器](https://the-zeroth.com/docs-assets/images/0.5/zh/working-group-templates-editor.png)

## 连线是什么意思 [#连线是什么意思]

连线不是固定的流水线。从 A 到 B 的一条连线是一种许可：A 可以把活交给 B。A 一交出去就进入休眠，B 醒来，收到的正好是 A 这次移交写的内容和文件，A 上下文里别的东西它都看不到。要不要交、什么时候交，由 Agent 在运行中自己判断，或者听你的。

* 连线是单向的。要让 B 把结果交回来，再加一条从 B 到 A 的连线。
* 没有连线，A 就不能把活交给 B。不过，持有 graph 工具的负责人仍然可以启动任何节点，和自己并行干活；用 TaskBoard 的负责人，会把任务派给完全没有连线的工人节点，`polished_software_dev` 里的 `developer` 就是这样的工人。Agent 在运行中也可以自己加连线。
* 负责移交的那个 Agent，会在自己的指令里看到它能交给哪些节点，以及每个节点角色的描述和那条连线上的文字。

正因为这样，连线上的文字很要紧。**连线检查器**里的**转移说明（handoff 指令）**，就是交出去的那个 Agent 在移交那一刻读到的指令，所以要写完整：什么时候交、把什么交过去、希望对方产出什么。比如：“评审通过后，把完整的方案、API 契约和数据模型交给开发节点，请它据此写出能跑的代码，并附上测试。”写得越具体，协作越准确。

## 模型、校验和保存 [#模型校验和保存]

画布上方的工具栏里是模板的默认模型：一个模型预设，给角色没有单独指定模型的每个节点用。选**跟随默认模型**，这些节点就用全局默认模型。见[模型](./models)。

**校验 Graph** 检查已经保存的模板，显示**校验通过**，或者找到了几个错误。它会查出这些问题：模板里一个节点都没有、连线连到了已经不在的节点、有 Agent 节点没绑角色，以及分不清活先交给哪个节点。先接活的那个节点叫入口：没有任何连线指向的那个唯一节点，除非模板文件里写明了入口。校验读的是保存下来的版本，所以先保存再校验。节点绑的角色已经不存在时，它的检查器里会写明。

## 导入和导出 [#导入和导出]

**新建 Graph** 旁边的**导入 Graph** 按钮，把为别的工具写的团队变成这个空间里的模板。它能读 Oracle 的 **Agent Spec**、**Dify DSL** 文件和 **Microsoft Declarative Workflow**：选一个 .yaml、.yml 或 .json 文件，或者把内容粘贴进来。格式按内容自动判断，也可以在**格式**里自己选。文件里的每个 agent 变成一个角色，它们怎么协作变成连线。

* **预览**在写入之前列出模板、它的 agent 和连线，以及**转换报告**；**导入**才真正写进空间。勾选**覆盖已有**会替换同名的模板或角色。
* 不会悄悄丢东西。转换报告列出每个**没带过来**和**换了样子**带过来的字段，并写明它在文件里的位置。
* 有些东西从来不转过来。导入的角色用你的默认模型，报告里写着文件原本要的是哪个模型。The One 里没有对应的工具，会连同用它的 agent 一起列在报告里。密钥不会进模板，报告里只写它们的名字。
* The One 没有跑固定步骤的引擎，所以一串固定步骤（Agent Spec 的 Flow、Dify 的工作流、带分支的 Declarative Workflow）会变成一个领头的 Agent，它的提示词按顺序写出每一步；这些步骤里调用的 agent 变成团队成员，由领头的把那一步交给它们。

![导入 Dify DSL 文件和它的转换报告](https://the-zeroth.com/docs-assets/images/0.5/zh/working-group-templates-import.png)

**导出**把最近一次保存的版本写成 Agent Spec 26.1.2（YAML 或 JSON）、Dify DSL 文件，或者微软的 Python 包 `agent-framework-declarative` 能直接运行的 Declarative Workflow。技能、插件、模型设置和默认模型预设不会带出去，转换报告里会写明。文件的元数据里存着 The One 自己的连线，所以原样导入回来，还是同一个模板。

在只读的官方空间里，可以导出，不能预览和导入。

## 官方空间里的模板 [#官方空间里的模板]

| 模板                                                    | 应用里叫                          | 做什么                                                                                           |
| ----------------------------------------------------- | ----------------------------- | --------------------------------------------------------------------------------------------- |
| `chat`                                                | **通用工作组**                     | 一个助手，直接用工具做普通的多步工作。内置。                                                                        |
| `polished_software_dev`                               | **软件团队**                      | 方案负责人动手做；和它同时启动的几个检查员，分别把需求、项目里的惯例、报告的症状，以及分开写的几项功能碰到一起的地方变成检查；`developer` 节点接 TaskBoard 的任务。 |
| `deep_research`                                       | **研究组**                       | 调研与综合，需要独立取证时用 TaskBoard 分出几路研究员。                                                             |
| `frontend_design_studio`                              | **前端设计组**                     | 前端设计与实现：设计总监、实现者和独立的设计评审。                                                                     |
| `image_generation_studio`                             | **图片组**                       | 用图像生成插件出图：一个协调者和一个执行者。                                                                        |
| `video_production_studio`                             | **视频组**                       | 视频：制片、创意总监、渲染工程师和独立的质检。                                                                       |
| `cinematic_film_production_studio`                    | **电影制作组**                     | 六个角色的电影工作室，从故事和视觉方向一直到验收过的成片素材。                                                               |
| `strategic_scifi_drama_studio`                        | **科幻剧本组**                     | 六个角色的战略科幻剧工作室。                                                                                |
| `blender_scene_studio`                                | **三维场景组**                     | Blender 场景：导演、搭建者（唯一改场景的人）和评审。                                                                |
| `product_evaluation_lab`                              | **产品体验评估组**                   | 产品体验评测：一个总监、在真实产品上操作的模拟用户，以及审核他们证据的审计员。                                                       |
| `site_deployment_ops`                                 | **建站上线组**                     | 把网站连同域名、支付链接和邮件一起上线：工程师动手改，编排者独立验收。                                                           |
| `storefront_studio`、`store_operator`、`store_reviewer` | **网店门面组**、**网店运营组**、**网店周报组** | 一人公司：搭店铺、日常运营（订单、邮件、退款），以及每周复盘。                                                               |
| `atlas`                                               | **定义编辑组**                     | 编写模板、角色、提示词、技能和插件。内置。                                                                         |
| `self_evolution_lab`                                  | **自我改进组**                     | 进化事项的实验室：总监、改动员和验证员。内置。                                                                       |

内置模板不出现在列表里，但主助手照样能用。另外两个内置模板由应用自己运行：`main_assistant` 和 `nightly_review`。见[团队与工具](../capabilities)。

## 怎么设计一个模板 [#怎么设计一个模板]

出厂的团队是按几条原则搭的，自己设计时也值得照着做：

* 先有一个工具齐全、对结果负责的负责人。只为别人看不到、做不到的事加节点：不同的输入、更窄的上下文、不同的模型，或者有用的并行。同一个角色拿着同样的输入多开几份，只会在同一处出错。
* 检查员在开工时就启动，和动手的人并行，让它们的发现在该做决定之前就到。
* 给检查员的是需求、数据和接口，不是它要检查的成果：读了实现的检查员会继承实现的错。
* 规则放在用到它的地方：放进它管的那次移交里，或者放进一个技能里（见[技能与提示词](./skills-and-prompts)）；不要放进角色常驻的提示词，那里的规则在用不上的时候也在起作用。
* 负责人的路径就是成本：路径上每多一跳都要多几轮。节点数是结果，不是目标。

模板不一定要手动搭。可以交给主助手，或者在[总图](./atlas)画布底部的 **The Director** 指令栏里说。在 [A-Genetic Engineering（Agent 基因工程）](../../multi-agent-architecture/a-genetic-engineering)里，模板连同它的角色就是一个工作组的基因；Agent 在运行中继续把工作组长大（克隆 Agent、开子图），就是 [Prolifera Engineering（增殖式工程）](../../multi-agent-architecture/prolifera-engineering)。

Source: https://the-zeroth.com/zh/docs/the-one-app/capabilities/working-group-templates