企业官网建设流程全解析

从零构建 LangGraph Coding Agent：多智能体协作、Unity 编译、自动修复与人工审批完整实战

最近一直在研究 AI Coding Agent。

一开始我的想法比较简单：让大模型根据需求生成几份 Unity C# 代码，然后再让另一个 Agent 检查一下就行了。

但真正做起来之后就会发现，只会“生成代码”远远不够。模型说代码没问题，不代表 Unity 编译器也认为它没问题；代码能编译，也不代表测试能通过；Agent 自动修改文件虽然方便，但如果没有审批、版本校验和 Git 兜底，也很容易把原项目改坏。

所以这个项目从一个简单的 Tool Agent 开始，逐步加入了 LangGraph 工作流、RAG、项目理解、依赖图、可信 Unity API 检索、真实 Unity 编译、EditMode/PlayMode 测试、自动修复、人工审批与审计、团队只读观察、本地 Git、多模型路由和评估体系，最后整理成了现在的LangGraph Coding Agent v1.2.0。

简单说，它现在可以完成下面这条链路：

读取需求 → 准备 Git 基线并验证 Unity 基线 → 理解现有 Unity 项目 → 检索可信 Unity API 证据 → 设计架构 → 规划文件 → 生成代码提案 → 人工审批 Diff → 静态检查 → 构建不可变 Unity 快照 → 隔离 Worker 执行 Unity 编译 → EditMode 测试 → PlayMode 测试 → Reviewer 审查 → 自动修复并再次审批 → 全部通过后创建本地 Git 提交

项目地址：

LangGraph Coding Agent GitHub

本文会从项目功能、环境配置、启动、实际使用、自动修复和评估结果几个部分，完整介绍一下这个项目。

一、项目介绍

1. LangGraph Coding Agent 是什么

LangGraph Coding Agent 是一个面向 Unity C# 项目的多智能体编程工作流。

它不是把所有事情都交给一个大模型，而是把软件开发流程拆分给多个职责不同的 Agent：

不同 Agent 通过 LangGraph 的状态和条件路由串联起来。某一步失败时，工作流不会直接把任务标记为成功，而是根据失败类型进入 Repair、重新设计架构或者安全停止。

2. 项目工作流

整个流程可以分成四个阶段：

1. Planning：需求分析、项目理解、架构设计、文件规划 2. Generation：代码生成、测试生成、变更提案 3. Validation：静态检查、不可变快照、Unity 编译、EditMode、PlayMode 和代码审查 4. Repair Loop：分析根因、生成修复 Diff、人工复审、再次验证

这里有一个比较重要的设计：Coder 和 Repair 都不能直接修改生产代码。

它们只能生成待审批的补丁提案。只有用户查看 Diff 并明确批准后，系统才会真正写入文件。这样既保留了 Agent 自动生成和修复代码的效率，也避免它在后台偷偷改坏项目。

3. 从 Day01 到 Day19 做了什么

这个项目保留了完整的学习过程，每一天都有对应的 Notebook 或设计文档。

如果你正在学习 LangGraph，也可以按照 Day01 到 Day19 的顺序查看，而不是一开始就直接读最终版本。Day01～Day15 主要建立 Coding Agent 的闭环，Day16～Day19 则进一步补齐可信知识、权限审计、团队观察和隔离执行能力。

二、项目环境准备

1. 基础环境

Windows 10 / Windows 11 Python 3.10 及以上，推荐 Python 3.11 Git Unity 2022.3 LTS Unity Test Framework 能够覆盖默认角色路由的 Provider 组合

完整工作流需要真实 Unity Editor。如果只是查看 Day01～Day19 的离线 Notebook，或者运行不依赖 Unity 的测试，则可以暂时不配置 Unity 和大模型 API。

2. 下载项目

gitclone https://github.com/MaddieMo1/LangGraph-Coding-Agent.gitcdLangGraph-Coding-Agent

也可以在 GitHub 页面点击Code → Download ZIP，下载完成之后解压。

小提示：Windows 下建议把项目放在路径较短的目录中，尽量避免特殊字符。

3. 创建 Python 环境

使用 Anaconda：

conda create-nlanggraph-coding-agentpython=3.11-yconda activate langgraph-coding-agent

不使用 Anaconda，也可以使用 venv：

python-mvenv .venv .venv\Scripts\activate

4. 安装依赖

python-mpipinstall--upgradepip pipinstall-rrequirements-lock.txt

requirements-lock.txt固定的是已经验证过的 Windows/Python 3.11 完整依赖树，适合普通使用者和交付复现。requirements.txt保留直接依赖范围，主要用于参与开发和升级依赖。安装完成后可以执行python -m pip check，正常情况下应输出No broken requirements found.。

主要依赖如下：

LangGraph：有状态 Agent 工作流 LangChain：模型和消息调用 Gradio：本地人工审批界面 Pydantic：结构化状态和输出校验 FAISS + Sentence Transformers：本地 RAG OpenAI SDK：调用兼容 OpenAI 协议的服务 SQLite Checkpoint：保存和恢复工作流

安装完成后先检查：

python--version

三、配置模型和 Unity 环境

1. 创建.env

复制项目根目录中的.env.example：

Copy-Item.env.example.env

打开.env，根据自己的环境修改。

2. 配置模型 API

默认路由会按 Agent 角色选择不同模型，不是只配置一个 Provider 就能覆盖完整工作流。当前最小组合可以选择：

DeepSeek + Kimi 或者 DeepSeek + Qwen

下面先以 DeepSeek 为例填写第一组配置：

DEEPSEEK_API_KEY=替换成你自己的_API_Key DEEPSEEK_MODEL=deepseek-chat DEEPSEEK_BASE_URL=https://api.deepseek.com

然后至少再配置 Kimi 或 Qwen；如果四家服务都可用，也可以全部填写：

KIMI_API_KEY=替换成你自己的_API_Key KIMI_BASE_URL=https://api.moonshot.cn/v1 QWEN_API_KEY=替换成你自己的_API_Key QWEN_BASE_URL=https://dashscope.aliyuncs.com/compatible-mode/v1 GLM_API_KEY=替换成你自己的_API_Key GLM_BASE_URL=https://open.bigmodel.cn/api/paas/v4

多模型路由不是随机选模型，而是按照 Agent 角色和任务复杂度进行确定性选择。简单任务优先使用速度更快、成本更低的模型，复杂架构、长上下文、Reviewer 和 Repair 可以路由到更适合的模型。主模型出现可恢复错误时最多切换一次备用 Provider；执行python -m tools.environment_check可以确认当前 Key 是否覆盖全部默认路由。

小提示：.env中保存的是密钥，不要提交到 GitHub，也不要在截图中暴露。

3. 配置 Unity Editor

找到本机 Unity Editor 的完整路径：

UNITY_EDITOR_PATH=D:\Unity\Hub\Unity_Editor\2022.3.62f2c1\Editor\Unity.exe

Unity Hub 的常见安装路径类似于：

C:\Program Files\Unity\Hub\Editor\2022.3.xx\Editor\Unity.exe

注意需要填写Unity.exe，不是 Unity Hub 的路径。

4. 准备 Unity 测试工程

创建一个单独的 Unity 测试项目，并配置：

UNITY_TEST_PROJECT_PATH=D:\Unity\Unity_Project\CodingAgentTest

工程至少要包含：

CodingAgentTest/ ├── Assets/ ├── Packages/ └── ProjectSettings/

控制器会把经过批准的脚本、测试和 Unity 工程必要目录打包成不可变快照。隔离 Worker 在快照中同步Assets/Generated，再通过 Unity BatchMode 依次执行真实编译、EditMode 和 PlayMode 测试。三个作业使用同一快照，但拥有独立的作业 ID、尝试号和结果，陈旧或错配结果不能进入 Reviewer。

使用隔离测试工程的好处是：即使真实业务项目正在 Unity Editor 中打开，Agent 也不需要强制关闭它。

5. 准备生成代码仓库

GENERATED_SOURCE_PATH需要指向一个独立 Git 仓库，并且必须存在基线提交。

New-Item-ItemType Directory-Path D:\Unity\AgentGeneratedCodeSet-LocationD:\Unity\AgentGeneratedCode git init-b main git config user.name"你的名字"git config user.email"你的邮箱"Set-ContentREADME.md"# Agent Generated Code"git add README.md git commit-m"chore: initialize generated code repository"

然后在.env中填写：

GENERATED_SOURCE_PATH=D:\Unity\AgentGeneratedCode

必须先有基线提交，因为每个任务都要基于它创建独立分支、校验文件漂移并记录最终 commit。

6. 配置运行时状态

下面两个配置可选，但建议放在项目外部：

GENERATED_TEST_SOURCE_PATH=D:\Unity\AgentRuntime\generated-tests WORKFLOW_CHECKPOINT_PATH=D:\Unity\AgentRuntime\workflow.sqlite

一个用于保存生成测试，一个用于保存 LangGraph SQLite 检查点。这样即使重启程序，待审批任务仍然可以恢复。

7. 配置本地 Unity Worker

v1.2.0 默认使用本机子进程 Worker，也可以显式连接受 HMAC 保护的 HTTPS Worker。首次在 Windows 上准备本地 Worker 时，先确保已经通过防火墙、虚拟机或容器真实阻断 Worker 的公网访问，然后运行：

.\scripts\setup_local_worker.ps1 `-UnityEditorPath"C:\Program Files\Unity\Hub\Editor\2022.3.62f2c1\Editor\Unity.exe"`-UnityProjectPath"D:\Unity\Unity_Project\CodingAgentTest"`-GeneratedSourcePath"D:\Unity\AgentGeneratedCode"`-WorkerStatePath"D:\Unity\AgentRuntime\unity-worker"`-NetworkIsolationEnforced

脚本会创建独立 Worker 状态目录、生成不含凭据的启动器并运行环境预检。它是幂等的，不会修改防火墙，也不会自动建立网络隔离；-NetworkIsolationEnforced只是操作者对已有隔离证据的明确确认。Worker 状态目录不能位于控制器仓库、Unity 工程或生成代码仓库内部。

8. 配置审批身份、审计和团队观察

Day17 默认使用服务启动时绑定的本地身份，角色可以是viewer、reviewer、approver或operator。审批记录以追加式 JSONL 审计链保存：

APPROVAL_ACTOR_ID=local-maintainer APPROVAL_ACTOR_ROLE=approver APPROVAL_AUDIT_PATH=D:\Unity\AgentRuntime\approval_audit.jsonl

Day18 的团队观察默认关闭。需要局域网只读观察时，应设置唯一的 32～256 字符令牌，并优先配置 HTTPS 证书：

OBSERVATION_ENABLED=true OBSERVATION_READ_TOKEN=替换成独立的只读访问令牌 OBSERVATION_SERVER_NAME=0.0.0.0 OBSERVATION_SERVER_PORT=7860 OBSERVATION_TLS_CERTFILE=D:\Unity\AgentRuntime\certs\observer.crt OBSERVATION_TLS_KEYFILE=D:\Unity\AgentRuntime\certs\observer.key

访问令牌、证书私钥和 Worker 凭据都不能提交到仓库。观察面只提供状态投影；本机控制面仍会拒绝非回环来源访问。

四、启动前环境检查

所有配置完成后，先执行：

python-mtools.environment_check

环境预检会检查：

1. Python 版本 2. 本地审批身份 3. 追加式审计日志路径 4. 团队只读观察配置 5. Provider 路由覆盖 6. Unity Editor 路径 7. Unity 测试工程结构 8. Unity Worker 状态、超时和网络隔离声明 9. 生成代码目录是否为独立 Git 仓库 10. Git 用户名和邮箱

这个命令是只读的，不调用模型、不启动 Unity、不修改仓库，也不会输出 API Key。

常见问题：

UNITY_EDITOR_PATH_INVALID 原因：Unity Editor 路径错误，或者填成了 Unity Hub。 UNITY_PROJECT_INVALID 原因：缺少 Assets、Packages 或 ProjectSettings。 GENERATED_REPOSITORY_INVALID 原因：生成代码目录不是独立 Git 仓库。 GIT_BASELINE_MISSING 原因：Git 仓库还没有第一次提交。 MODEL_ROUTE_UNCONFIGURED 原因：某个 Agent 路由不到可用模型。 UNITY_WORKER_UNAVAILABLE 原因：Worker 状态目录、超时、网络模式或真实隔离声明不满足要求。

按照输出逐项处理，再重新执行即可。

五、启动和创建任务

1. 启动 Web 界面

python app.py

默认情况下程序只监听本机127.0.0.1，不会自动创建公共分享链接。启用团队观察后可以监听配置的局域网地址，但根路径仍受回环访问限制，团队成员只应访问/observe/ui。根据终端输出打开对应地址。

界面顶部有三个入口：

工作台：创建任务、审批 Diff、查看执行阶段和最终结果 任务中心：查看历史任务、筛选、恢复任务和打开详情 团队观察：向局域网团队成员提供严格只读的任务状态

团队观察默认关闭。启用后，根路径仍然是只允许本机访问的控制面，远程成员只能访问/observe/ui，不会获得批准、拒绝、重试、取消或 Git 操作能力。

2. 使用命令行入口

如果希望从脚本创建任务，也可以使用正式 CLI：

python main.py"设计 Unity 背包系统并生成代码"python main.py"设计 Unity 背包系统并生成代码"--thread-id inventory-demo --database-path memory/demo.sqlite--jsonpython main.py--help

需求是必填参数。--json的标准输出只包含有限、脱敏的任务摘要，执行日志会写入标准错误；任务停在人工审批点后，可以打开网页控制台并使用同一任务 ID 继续处理。

3. 输入任务需求

例如：

为 Unity 项目设计并生成一个射线点击系统。 要求返回命中的 GameObject、Collider、世界坐标和法线， 使用事件解耦输入层与业务层，并生成对应 EditMode 测试。

需求尽量写清楚：

要实现什么功能 允许新增或修改哪些文件 希望使用什么架构 哪些现有接口不能破坏 需要覆盖哪些测试场景

然后点击“开始并生成提案”。

Coordinator 会先生成结构化需求契约，接着扫描 Unity 项目、建立上下文和依赖图，再依次运行 Architecture、File Planner 和 Coder。

六、人工审批代码 Diff

当 Coder 完成后，LangGraph 会通过原生interrupt()暂停工作流。

左侧可以切换文件，中间查看统一 Diff，右侧显示提案来源、任务 ID 和变更统计。

底部有三种操作：

批准全部并继续：应用提案中的全部文件 仅应用所选文件：只批准勾选文件，仍然原子应用 拒绝本次提案：不写生产代码并结束本次流程

建议重点检查：

文件路径是否正确 是否修改了需求范围外的文件 公开类名和文件名是否一致 是否重复定义现有类型 是否误删已有逻辑 测试是否覆盖核心行为

提案生成时会记录源文件哈希。批准时系统还会再次检查磁盘文件，如果审批期间手动改过同一个文件，系统会拒绝用旧补丁覆盖新修改。

出现哈希冲突时，重新基于最新文件生成提案即可，不建议绕过校验。

七、Unity 编译、测试和自动修复

1. 批准之后的质量门

1. Test Generator 生成结构化 EditMode 和 PlayMode 测试 2. Code Checker 执行静态检查 3. 控制器构建并校验不可变 Unity 快照 4. Unity Worker 执行真实 BatchMode 编译 5. Unity Worker 依次运行 EditMode 和 PlayMode 测试 6. Reviewer 综合代码、编译器和测试证据评分

任务只有同时满足下面条件才可以完成：

Code Checker 通过 Unity 编译通过 EditMode 测试通过 PlayMode 测试通过 Reviewer 返回 pass=true Reviewer 分数不低于 90 remaining_issues 为空

不能只看某一个 Agent 输出“通过”，真实编译器和测试结果的优先级更高。

2. 编译失败时自动 Repair

如果 Unity 返回CS1061、CS0246、CS1525等错误，Reviewer 会先整理结构化根因，再交给 Repair Agent。

Repair 不直接改文件，而是生成新的修复提案，再次停在人工审批界面：

Repair 审批页会显示：

当前修复轮次 触发失败的质量门 Unity 错误代码 结构化根因 相关文件 修复策略 本轮统一 Diff

确认合理后再次批准。工作流会重新执行静态检查、Unity 编译、测试和 Reviewer，不会直接跳到成功。

3. 修复循环不是无限的

Repair Loop 有明确的最大次数。达到上限仍未通过时，系统会以失败状态结束并保留历史，不会把失败误报成成功。

系统错误和代码错误也会分开。例如 Unity 路径失效、许可证错误、测试运行器无法启动属于环境问题，不应该让 Repair 去乱改业务代码。

八、任务中心和断点恢复

点击顶部“任务中心”，可以查看统计、搜索、状态筛选和分页任务卡：

任务状态包括运行中、等待审批、已完成和已失败。活动任务会置顶并受安全锁保护，非活动任务可以多选删除。

点击任务卡片可以打开详情：

详情中可以查看任务 ID、更新时间、当前节点、错误、Git 分支、基准提交和最终提交。

工作流状态保存在 SQLite Checkpoint 中，所以刷新页面、重启 Gradio 或电脑短暂重启后，待审批任务仍然可以恢复。

恢复时会重新检查：

当前 Git 分支 基准提交 批准文件集合 文件内容哈希 工作区额外修改

发现漂移时会拒绝继续。这个限制看起来严格，但可以避免旧任务覆盖用户后续修改。

团队只读观察

Day18 增加了可选的团队观察页面。观察者使用服务端配置的只读令牌换取短期会话，可以查看任务、当前门禁、耗时、测试计数和稳定错误码，但看不到 API Key、Worker 凭据、绝对路径、源码、完整日志或 HMAC 材料。

真实第二设备验收确认：观察页面可以断线续传和恢复任务状态，同时不存在任何审批、重试、取消或 Git 控件。它适合团队了解进度，但不会把控制权从本机审批者手中移走。

九、本地 Git 安全边界

每个任务会创建类似下面的本地分支：

agent/<task-id>

只有全部质量门通过后，Git Agent 才暂存批准范围内的文件并创建本地提交。

当前 Git Tool 不提供任意 Shell，也不支持：

git push 创建 Pull Request merge rebase reset 历史改写 自动暂存范围外文件

Agent 最多只会创建一个可检查的本地提交，远程推送和合并仍然由用户决定。

如果失败任务留下了已批准文件，界面会进入DIRTY_BASELINE。用户可以明确选择“归档失败现场并清理工作区”，系统使用包含未跟踪文件的 Git stash 保存现场，再确认工作区干净。

这个操作不会在后台自动执行，避免 Agent 擅自移动用户代码。

十、多模型路由和长期记忆

不同 Agent 对模型要求不同。Architecture 更看重复杂推理和长上下文，Coder 更看重代码生成，Reviewer 需要独立审查视角，Repair 则需要依据真实错误做精确修改。

系统会记录每次调用的：

Provider 模型名称 任务复杂度 选择原因 调用次数 执行耗时 可用 Token Usage

主模型遇到可恢复错误时最多切换一次其他 Provider；如果只是结构化输出格式错误，会先让当前模型纠正一次，再决定是否回退。

长期记忆按 Unity 项目隔离，包含：

project_memory：项目结构和稳定事实 coding_style：代码风格和命名习惯 bug_history：出现过的错误 solution_history：经过验证的修复方案

只有通过后续 Unity 编译或测试验证的 Repair 才能进入可复用方案。模型自己说“修好了”不算，必须有编译器或测试证据。环境错误也不会污染缺陷记忆。

十一、任务完成和结果检查

当静态检查、Unity 编译、EditMode、PlayMode 和 Reviewer 全部通过后，系统会创建本地 Git 提交：

完成页会显示：

Unity 基线 静态检查 Unity 快照 Unity 编译 EditMode 测试 PlayMode 测试 Reviewer Repair 轮次 Git 分支 基准提交 最终 commit hash 开始时间和任务总历时

任务结束后建议进入生成代码仓库再检查一次：

gitstatusgitbranch --show-currentgitlog-1--onelinegitshow--stat--onelineHEAD

需要合并到真实业务项目时，先人工 Review 最终提交，再由开发者执行后续合并。

十二、项目评估结果

Day14 加入了固定离线基准，覆盖：

首次生成成功 Repair 后成功 Repair 次数耗尽 模型调用失败 Unity 环境阻塞

固定 Fixture 的指标如下：

这些分母来自固定基准契约，不代表线上流量，也不会把环境阻塞强行算成代码质量问题。

真实 Provider + Unity 验收中，项目已经跑通过完整 Repair 链路：

第一次 Unity 编译失败 → Reviewer 定位根因 → Repair 生成修复提案 → 第二次人工审批 → Code Checker 通过 → Unity 编译通过 → 14 / 14 EditMode 测试通过 → Reviewer 100 分 → 创建本地 Git 提交

v1.0.0 教程与发布材料阶段曾完成346 项 Python 回归。随着 Day16～Day19 和交付加固功能加入，2026-08-24 在 Python 3.11.4 上以 UTF-8 模式执行当前完整回归，结果为596 项全部通过，耗时 27.024 秒；把ResourceWarning、DeprecationWarning和UserWarning提升为错误后仍然全绿，同时通过compileall、pip check和git diff --check。

Day19 还完成了独立真实环境验收：同一份 34 文件不可变快照分别通过本机客户端和局域网 HTTPS Worker 执行，Unity2022.3.62f2c1的 compile、EditMode 1/1、PlayMode 1/1 全部通过。远程链路同时验证了证书、HMAC 签名、陈旧请求拒绝、幂等取消、沙箱清理和证据产物哈希。

运行离线评估：

python-mevaluation.runner

生成：

evaluation/results/day14_evaluation.json evaluation_report.md

Day01～Day19 的离线 Notebook 和 Python 回归可以在没有大模型、没有 Unity、没有密钥的环境中运行。真实 Provider、Unity、证书链和 Worker 网络隔离仍然需要单独的真实环境验收，不能用 fixture 或 GitHub Actions 代替。

十三、常见问题

1. 启动后找不到模型

检查.env是否位于项目根目录，再确认变量名、Base URL 和 API Key。然后执行：

python-mtools.environment_check

2. Unity 一直编译失败

先区分代码错误和环境错误：

CSxxxx 编译错误：通常属于代码问题，可以进入 Repair。 Unity 无法启动、许可证失败、工程损坏：属于环境问题，先修环境。

3. 提示生成代码仓库不干净

进入GENERATED_SOURCE_PATH检查：

gitstatus--short

自己的修改先提交或保存；失败任务留下的文件可以用界面的失败现场归档。不要直接使用git reset --hard，否则可能删除仍然需要的代码。

4. 审批后提示文件哈希冲突

说明提案生成后源文件又被修改了。这是正常安全拦截，重新基于最新文件生成提案即可。

5. 页面刷新后任务不见了

检查WORKFLOW_CHECKPOINT_PATH是否可写。默认检查点位于：

memory/workflow_checkpoints.sqlite

经常更换项目目录时，建议配置固定的外部运行时路径。

6. 测试生成 JSON 解析失败

Test Generator 会自动重试最多两次。仍然失败时会保留原 thread、已批准代码和任务分支，修正模型配置后可以从失败页“重试生成测试”，不必重新审批生产代码。

十四、目前的限制

当前真实执行主要面向 Windows 和 Unity 2022.3 LTS 远程模式是显式启用的单 Worker 服务，不是集群调度系统 远程身份使用单 Worker 专用预共享凭据，不是账号或多租户权限系统 Git 只创建本地分支和提交 不会自动 push、创建 PR 或合并 GitHub Actions 只覆盖离线 Python 验证 新机器仍需人工验证 Provider、Unity、证书链和 Worker 网络隔离

我认为这些限制不一定都是缺点。

Coding Agent 真正进入工程之后，重要的不是让它拥有无限权限，而是让每一步都有明确输入、真实证据、安全边界和可恢复状态。当前版本已经具备本机与 HTTPS Worker、团队只读观察和双模式测试，但仍然坚持“默认权限最小、远程能力显式启用”的原则。后续如果继续扩展，会优先考虑更正式的身份系统、Worker 集群调度和 PR 协作，而不是直接给 Agent 无限权限。

总结

这个项目最初只是想验证 LangGraph 能不能组织多个 Agent 生成 Unity 代码，最后逐渐变成了一套相对完整的工程工作流。

对我来说，最重要的并不是 Agent 数量变多，而是补上了几个真正影响可靠性的环节：

让真实 Unity 编译器决定代码是否能编译 让 EditMode 和 PlayMode 测试共同决定功能是否满足要求 让不可变快照和隔离 Worker 约束真实执行环境 让所有生产代码变更都经过人工审批 让审批身份、审计链和团队只读观察各自保持清晰边界 让修复结果通过再次验证后才能记忆 让 Git 只在全部质量门通过后提交 让失败任务可以恢复、追踪和安全结束

AI 可以负责分析、规划、生成和修复，但最终写入什么、是否接受、是否推送，仍然应该掌握在开发者手中。

暂时先这样吧，如果在安装、Unity 配置或者运行过程中遇到问题，可以在评论区留言，看到我会回复的。

希望这个项目和教程对你有帮助！

如果准备把项目交给其他人使用，可以继续阅读：

• v1.2.0 发布说明
• Day19 Unity Worker 验收记录
• 交接与用户操作指南

路漫漫其修远，与君共勉。