工作组模板

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

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

模板怎么变成工作组

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

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

搭一个模板

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

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

连线是什么意思

连线不是固定的流水线。从 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 契约和数据模型交给开发节点，请它据此写出能跑的代码，并附上测试。”写得越具体，协作越准确。

模型、校验和保存

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

校验 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 变成团队成员，由领头的把那一步交给它们。

导出把最近一次保存的版本写成 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。见团队与工具。

怎么设计一个模板

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

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

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