# Unity Agent Team v2：自适应多智能体Unity DOTS开发框架

> Unity Agent Team v2是一个为Unity DOTS设计的自适应多智能体AI框架，通过任务分类、动态团队组建和严格的阶段门控，解决了v1版本中固定团队结构、过早并行执行和弱约束机制等问题。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-05-26T03:45:24.000Z
- 最近活动: 2026-05-26T03:53:52.658Z
- 热度: 152.9
- 关键词: Unity DOTS, 多智能体, AI开发框架, ECS, 自适应流水线, 智能体编排, 游戏开发, MCP, 软件开发自动化
- 页面链接: https://www.zingnex.cn/forum/thread/unity-agent-team-v2-unity-dots
- Canonical: https://www.zingnex.cn/forum/thread/unity-agent-team-v2-unity-dots
- Markdown 来源: ingested_event

---

## 原作者与来源

- **原作者/维护者**: dyCuong03
- **来源平台**: GitHub
- **原始标题**: unity-agent-team
- **原始链接**: https://github.com/dyCuong03/unity-agent-team
- **发布时间**: 2026年5月26日

---

## 项目概述与核心理念

Unity Agent Team是一个专为Unity DOTS（Data-Oriented Technology Stack，包含ECS、Jobs、Burst）设计的多智能体AI开发框架。它模拟真实的游戏开发团队结构，包含架构师（Architect）、Unity开发者（Unity Dev）、数据工具专家（Data Tool）和测试人员（QA）等角色，通过结构化的工作流程来完成设计、构建、调试和优化任务。

v2版本是对v1的重大重构，核心理念从"固定团队结构"转变为"自适应流水线"。v1版本的问题在于：无论任务大小始终启动4个智能体、规则只是文档承诺缺乏强制执行、过早并行执行导致冲突编辑、tmux作为硬依赖侵入架构设计。v2通过设计而非文档来解决这些问题，引入了任务分类（Triage）、动态规划（Plan）和阶段门控（Gate）机制。

---

## v1的核心问题与v2的解决方案

v1版本采用固定的4智能体结构（architect、unity-dev、data-tool、tester），这导致大多数任务根本不需要这么多参与者，造成资源浪费和协调开销。v2引入了任务分类器（Triage），根据任务复杂度、领域和置信度输出`triage.json`，然后由编排器（orchestrate.py plan）推导出1-4个智能体的最小可行组合。

v1的规则只是Markdown文档中的承诺，如"不要继续直到X完成"，但编排器可以无视这些规则。v2将每个阶段门控实现为`orchestrate.py gate <phase-id>`命令，返回非零退出码（exit 2）时强制停止流水线。这种机制确保了规则的可执行性。

v1的测试人员始终在线，即使是微小任务也会启动。v2根据任务复杂度动态选择验证者：tiny复杂度使用确定性bundle（无智能体），small/medium使用轻量级verifier，只有large/critical复杂度或置信度低于0.7时才启用tester。

v1使用嵌套子智能体（如burst-validator、code-generator），导致架构复杂。v2将这些功能打包为技能包（skill packs），作为文本加载到相关智能体中，而非作为独立智能体生成。

v1过早允许并行执行，常在设计不确定时就开始并行工作。v2只有在置信度≥0.8、复杂度≥medium、且所有权跨≥2个智能体分区时，才允许并行执行。

v1将tmux作为硬依赖。v2使tmux成为可选的UI组件，编排逻辑在没有tmux的情况下也能完全相同地运行。

---

## 自适应流水线架构

Unity Agent Team v2的流水线包含5个核心步骤：

**步骤0：引导（Bootstrap）** - 运行`orchestrate.py preflight`进行环境检查和状态重置。

**步骤1：任务分类（Triage）** - Triage智能体通过CRG（Context-Rich Generation）和指纹分析生成`workspace/triage.json`，包含任务复杂度、领域、置信度和推荐深度。

**步骤2：规划（Plan）** - `orchestrate.py plan`读取triage.json，输出`workspace/pipeline.json`，定义阶段、并行策略和产物清单。

**步骤3：阶段执行（Execute Phases）** - 对每个阶段：调用`orchestrate.py gate <id>`进行门控检查；生成阶段指定的智能体；每个智能体写入产物并验证；在verifier失败时循环重试（最多2次）。

**步骤4：收尾（Finalize）** - `orchestrate.py finalize`生成完成报告或返回exit 4表示验证失败。

---

## 复杂度驱动的流水线配置

v2根据任务复杂度自动选择流水线配置：

| 复杂度 | 流水线 | 验证方式 |
|--------|--------|----------|
| tiny | [unity-dev] | 确定性bundle（无智能体） |
| small | [unity-dev, verifier] | verifier |
| medium | [architect, unity-dev, verifier] | verifier |
| large | [architect, unity-dev, tester] | tester |
| critical | [architect, unity-dev, data-tool, tester] | tester |

意图（Intent）可以覆盖默认配置：bug意图会在流水线前添加bug-investigation；refactor意图会添加refactor-agent并强制architect审批和分步门控；explore意图产生空流水线，仅triage智能体运行并更新repo-knowledge.md。

深度（Depth）修饰符提供额外控制：quick降低一级复杂度（multi-system影响范围时拒绝）；normal使用triage的分类结果；deep提升一级复杂度，总是使用tester，并要求/codex:review。

---

## 运行时强制执行机制

v2的核心创新在于将承诺转化为可执行契约。每个产物都有JSON Schema定义，存储在`.claude/schemas/`目录下。每个阶段边界调用`.claude/scripts/orchestrate.py`，退出码定义了契约状态：

| 退出码 | 含义 |
|--------|------|
| 0 | 成功 |
| 2 | 门控违规 - 阶段不得继续 |
| 3 | 所有权违规 - 写入者触碰了分区外的文件 |
| 4 | 验证失败 - 完成被阻止 |
| 10 | 重试限制达到（3次实现周期失败） |

开发者可以随时手动运行门控检查：`python .claude/scripts/orchestrate.py gate phase-2`。这种设计确保了规则的可验证性和不可绕过性。

---

## 技能包系统

v2用技能包（skill packs）替代了v1的嵌套子智能体。技能包作为文本加载到智能体中，永远不会作为独立智能体生成：

| 技能包 | 加载目标 | 替代v1子智能体 |
|--------|----------|----------------|
| burst-safety | unity-dev（DOTS/Hybrid领域） | burst-validator |
| ecs-job-patterns | unity-dev（DOTS/Hybrid领域） | job-optimizer |
| memory-safety | unity-dev（DOTS/Hybrid领域） | memory-checker |
| ownership-partitioning | 并行时的每个写入者 | （新增） |
| triage | triage智能体 | （新增） |
| verifier | verifier智能体 | （新增） |

完整的Unity DOTS技能（unity-dots-best-practices/SKILL.md）始终加载到architect和unity-dev中。

---

## 产物与Schema

每个产物都是JSON格式，根据Schema验证，并在下一阶段运行前由编排器门控：

| 产物 | 所有者 | 被谁需要 |
|------|--------|----------|
| triage.json | triage（始终） | 每个阶段 |
| pipeline.json | orchestrate.py plan | 每个阶段 |
| root_cause.json | bug-investigation / refactor-agent | architect / unity-dev |
| approved_plan.json | architect（medium+） | unity-dev / data-tool |
| impl_result.json | unity-dev, data-tool | verifier / tester |
| verification_result.json | verifier, tester | orchestrate.py finalize |
| ownership.lock.json | architect（并行时）/ triage（2个写入者时） | 每个写入者的ownership-check |

---

## 实践意义与应用场景

Unity Agent Team v2代表了AI辅助软件开发框架的重要演进。它解决了多智能体系统中的一个核心难题：如何在灵活性和可控性之间取得平衡。通过自适应流水线，框架能够根据任务特性动态调整资源配置，避免过度工程化；通过严格的门控机制，它又确保了开发过程的可靠性和可预测性。

对于Unity DOTS开发者而言，这个框架提供了专门针对ECS、Jobs和Burst优化的智能体配置。DOTS是Unity的高性能数据导向技术栈，对内存布局、并行模式和性能特性有特殊要求。通用AI助手往往难以处理这些细节，而Unity Agent Team通过内置的DOTS技能包和领域特定知识填补了这一空白。

对于AI系统研究者而言，v2的设计提供了多智能体协作架构的参考实现。任务分类、动态规划、阶段门控、所有权分区等机制，都是构建可扩展多智能体系统的关键组件。