从零构建 LangGraph Coding Agent多智能体协作、Unity 编译、自动修复与人工审批完整实战从零构建 LangGraph Coding Agent多智能体协作、Unity 编译、自动修复与人工审批完整实战一、项目介绍1. LangGraph Coding Agent 是什么2. 项目工作流3. 从 Day01 到 Day19 做了什么二、项目环境准备1. 基础环境2. 下载项目3. 创建 Python 环境4. 安装依赖三、配置模型和 Unity 环境1. 创建 .env2. 配置模型 API3. 配置 Unity Editor4. 准备 Unity 测试工程5. 准备生成代码仓库6. 配置运行时状态7. 配置本地 Unity Worker8. 配置审批身份、审计和团队观察四、启动前环境检查五、启动和创建任务1. 启动 Web 界面2. 使用命令行入口3. 输入任务需求六、人工审批代码 Diff七、Unity 编译、测试和自动修复1. 批准之后的质量门2. 编译失败时自动 Repair3. 修复循环不是无限的八、任务中心和断点恢复团队只读观察九、本地 Git 安全边界十、多模型路由和长期记忆十一、任务完成和结果检查十二、项目评估结果十三、常见问题1. 启动后找不到模型2. Unity 一直编译失败3. 提示生成代码仓库不干净4. 审批后提示文件哈希冲突5. 页面刷新后任务不见了6. 测试生成 JSON 解析失败十四、目前的限制总结从零构建 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# 项目的多智能体编程工作流。它不是把所有事情都交给一个大模型而是把软件开发流程拆分给多个职责不同的 AgentAgent主要职责Coordinator理解需求并生成结构化需求契约Architecture根据需求和现有项目设计架构Architecture Validator检查架构方案是否合理File Planner规划需要新增或修改的文件Coder生成多文件代码提案Test Generator生成结构化 EditMode 和 PlayMode 测试Code Checker静态检查和跨文件重复类型检查Unity Compiler通过隔离 Worker 调用真实 Unity Editor 编译 C#Unity Test在同一不可变快照中依次运行 EditMode 和 PlayMode 测试Reviewer综合代码、编译器和测试结果审查Repair根据真实错误生成修复提案Git 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 或设计文档。阶段实现内容Day01Tool Agent 和多工具调用Day02LangGraph 状态、节点、条件路由和 CheckpointDay03Unity 知识库、Embedding、FAISS 和 RAGDay04读取真实项目并生成代码Day05多 Agent、Reviewer 和基础 Repair LoopDay06Unity 编译、结构化错误、Diff Patch 和撤销Day07Unity Project UnderstandingDay08类型依赖图和影响范围分析Day09EditMode 测试生成和隔离执行Day10项目级长期记忆Day11interrupt 人工审批和 SQLite 恢复Day12安全本地 Git 分支和提交Day13DeepSeek、Kimi、Qwen、GLM 多模型路由Day14离线基准和真实 Agent 评估Day15需求契约、环境预检、CI 和 v1.0 发布Day16Unity API 可信知识检索、版本匹配和缓存Day17审批身份、权限矩阵和追加式审计链Day18团队只读观察、SSE 和断线续传Day19不可变 Unity 快照、隔离 Worker 和 EditMode/PlayMode 双门禁如果你正在学习 LangGraph也可以按照 Day01 到 Day19 的顺序查看而不是一开始就直接读最终版本。Day01Day15 主要建立 Coding Agent 的闭环Day16Day19 则进一步补齐可信知识、权限审计、团队观察和隔离执行能力。二、项目环境准备1. 基础环境Windows 10 / Windows 11 Python 3.10 及以上推荐 Python 3.11 Git Unity 2022.3 LTS Unity Test Framework 能够覆盖默认角色路由的 Provider 组合完整工作流需要真实 Unity Editor。如果只是查看 Day01Day19 的离线 Notebook或者运行不依赖 Unity 的测试则可以暂时不配置 Unity 和大模型 API。2. 下载项目gitclone https://github.com/MaddieMo1/LangGraph-Coding-Agent.gitcdLangGraph-Coding-Agent也可以在 GitHub 页面点击Code → Download ZIP下载完成之后解压。小提示Windows 下建议把项目放在路径较短的目录中尽量避免特殊字符。3. 创建 Python 环境使用 Anacondaconda create-nlanggraph-coding-agentpython3.11-yconda activate langgraph-coding-agent不使用 Anaconda也可以使用 venvpython-mvenv .venv .venv\Scripts\activate4. 安装依赖python-mpipinstall--upgradepip pipinstall-rrequirements-lock.txtrequirements-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.exampleCopy-Item.env.example.env打开.env根据自己的环境修改。2. 配置模型 API默认路由会按 Agent 角色选择不同模型不是只配置一个 Provider 就能覆盖完整工作流。当前最小组合可以选择DeepSeek Kimi 或者 DeepSeek Qwen下面先以 DeepSeek 为例填写第一组配置DEEPSEEK_API_KEY替换成你自己的_API_Key DEEPSEEK_MODELdeepseek-chat DEEPSEEK_BASE_URLhttps://api.deepseek.com然后至少再配置 Kimi 或 Qwen如果四家服务都可用也可以全部填写KIMI_API_KEY替换成你自己的_API_Key KIMI_BASE_URLhttps://api.moonshot.cn/v1 QWEN_API_KEY替换成你自己的_API_Key QWEN_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 GLM_API_KEY替换成你自己的_API_Key GLM_BASE_URLhttps://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_PATHD:\Unity\Hub\Unity_Editor\2022.3.62f2c1\Editor\Unity.exeUnity Hub 的常见安装路径类似于C:\Program Files\Unity\Hub\Editor\2022.3.xx\Editor\Unity.exe注意需要填写Unity.exe不是 Unity Hub 的路径。4. 准备 Unity 测试工程创建一个单独的 Unity 测试项目并配置UNITY_TEST_PROJECT_PATHD:\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 Codegit add README.md git commit-mchore: initialize generated code repository然后在.env中填写GENERATED_SOURCE_PATHD:\Unity\AgentGeneratedCode必须先有基线提交因为每个任务都要基于它创建独立分支、校验文件漂移并记录最终 commit。6. 配置运行时状态下面两个配置可选但建议放在项目外部GENERATED_TEST_SOURCE_PATHD:\Unity\AgentRuntime\generated-tests WORKFLOW_CHECKPOINT_PATHD:\Unity\AgentRuntime\workflow.sqlite一个用于保存生成测试一个用于保存 LangGraph SQLite 检查点。这样即使重启程序待审批任务仍然可以恢复。7. 配置本地 Unity Workerv1.2.0 默认使用本机子进程 Worker也可以显式连接受 HMAC 保护的 HTTPS Worker。首次在 Windows 上准备本地 Worker 时先确保已经通过防火墙、虚拟机或容器真实阻断 Worker 的公网访问然后运行.\scripts\setup_local_worker.ps1 -UnityEditorPathC:\Program Files\Unity\Hub\Editor\2022.3.62f2c1\Editor\Unity.exe-UnityProjectPathD:\Unity\Unity_Project\CodingAgentTest-GeneratedSourcePathD:\Unity\AgentGeneratedCode-WorkerStatePathD:\Unity\AgentRuntime\unity-worker-NetworkIsolationEnforced脚本会创建独立 Worker 状态目录、生成不含凭据的启动器并运行环境预检。它是幂等的不会修改防火墙也不会自动建立网络隔离-NetworkIsolationEnforced只是操作者对已有隔离证据的明确确认。Worker 状态目录不能位于控制器仓库、Unity 工程或生成代码仓库内部。8. 配置审批身份、审计和团队观察Day17 默认使用服务启动时绑定的本地身份角色可以是viewer、reviewer、approver或operator。审批记录以追加式 JSONL 审计链保存APPROVAL_ACTOR_IDlocal-maintainer APPROVAL_ACTOR_ROLEapprover APPROVAL_AUDIT_PATHD:\Unity\AgentRuntime\approval_audit.jsonlDay18 的团队观察默认关闭。需要局域网只读观察时应设置唯一的 32256 字符令牌并优先配置 HTTPS 证书OBSERVATION_ENABLEDtrue OBSERVATION_READ_TOKEN替换成独立的只读访问令牌 OBSERVATION_SERVER_NAME0.0.0.0 OBSERVATION_SERVER_PORT7860 OBSERVATION_TLS_CERTFILED:\Unity\AgentRuntime\certs\observer.crt OBSERVATION_TLS_KEYFILED:\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. 使用命令行入口如果希望从脚本创建任务也可以使用正式 CLIpython 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 返回 passtrue 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 的指标如下指标结果端到端成功率2 / 4编译成功率2 / 3Repair 成功率1 / 2功能稳定性5 / 5这些分母来自固定基准契约不代表线上流量也不会把环境阻塞强行算成代码质量问题。真实 Provider Unity 验收中项目已经跑通过完整 Repair 链路第一次 Unity 编译失败 → Reviewer 定位根因 → Repair 生成修复提案 → 第二次人工审批 → Code Checker 通过 → Unity 编译通过 → 14 / 14 EditMode 测试通过 → Reviewer 100 分 → 创建本地 Git 提交v1.0.0 教程与发布材料阶段曾完成346 项 Python 回归。随着 Day16Day19 和交付加固功能加入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.mdDay01Day19 的离线 Notebook 和 Python 回归可以在没有大模型、没有 Unity、没有密钥的环境中运行。真实 Provider、Unity、证书链和 Worker 网络隔离仍然需要单独的真实环境验收不能用 fixture 或 GitHub Actions 代替。十三、常见问题1. 启动后找不到模型检查.env是否位于项目根目录再确认变量名、Base URL 和 API Key。然后执行python-mtools.environment_check2. 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 验收记录交接与用户操作指南路漫漫其修远与君共勉。 从零构建 LangGraph Coding Agent：多智能体协作、Unity 编译、自动修复与人工审批完整实战
从零构建 LangGraph Coding Agent多智能体协作、Unity 编译、自动修复与人工审批完整实战从零构建 LangGraph Coding Agent多智能体协作、Unity 编译、自动修复与人工审批完整实战一、项目介绍1. LangGraph Coding Agent 是什么2. 项目工作流3. 从 Day01 到 Day19 做了什么二、项目环境准备1. 基础环境2. 下载项目3. 创建 Python 环境4. 安装依赖三、配置模型和 Unity 环境1. 创建 .env2. 配置模型 API3. 配置 Unity Editor4. 准备 Unity 测试工程5. 准备生成代码仓库6. 配置运行时状态7. 配置本地 Unity Worker8. 配置审批身份、审计和团队观察四、启动前环境检查五、启动和创建任务1. 启动 Web 界面2. 使用命令行入口3. 输入任务需求六、人工审批代码 Diff七、Unity 编译、测试和自动修复1. 批准之后的质量门2. 编译失败时自动 Repair3. 修复循环不是无限的八、任务中心和断点恢复团队只读观察九、本地 Git 安全边界十、多模型路由和长期记忆十一、任务完成和结果检查十二、项目评估结果十三、常见问题1. 启动后找不到模型2. Unity 一直编译失败3. 提示生成代码仓库不干净4. 审批后提示文件哈希冲突5. 页面刷新后任务不见了6. 测试生成 JSON 解析失败十四、目前的限制总结从零构建 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# 项目的多智能体编程工作流。它不是把所有事情都交给一个大模型而是把软件开发流程拆分给多个职责不同的 AgentAgent主要职责Coordinator理解需求并生成结构化需求契约Architecture根据需求和现有项目设计架构Architecture Validator检查架构方案是否合理File Planner规划需要新增或修改的文件Coder生成多文件代码提案Test Generator生成结构化 EditMode 和 PlayMode 测试Code Checker静态检查和跨文件重复类型检查Unity Compiler通过隔离 Worker 调用真实 Unity Editor 编译 C#Unity Test在同一不可变快照中依次运行 EditMode 和 PlayMode 测试Reviewer综合代码、编译器和测试结果审查Repair根据真实错误生成修复提案Git 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 或设计文档。阶段实现内容Day01Tool Agent 和多工具调用Day02LangGraph 状态、节点、条件路由和 CheckpointDay03Unity 知识库、Embedding、FAISS 和 RAGDay04读取真实项目并生成代码Day05多 Agent、Reviewer 和基础 Repair LoopDay06Unity 编译、结构化错误、Diff Patch 和撤销Day07Unity Project UnderstandingDay08类型依赖图和影响范围分析Day09EditMode 测试生成和隔离执行Day10项目级长期记忆Day11interrupt 人工审批和 SQLite 恢复Day12安全本地 Git 分支和提交Day13DeepSeek、Kimi、Qwen、GLM 多模型路由Day14离线基准和真实 Agent 评估Day15需求契约、环境预检、CI 和 v1.0 发布Day16Unity API 可信知识检索、版本匹配和缓存Day17审批身份、权限矩阵和追加式审计链Day18团队只读观察、SSE 和断线续传Day19不可变 Unity 快照、隔离 Worker 和 EditMode/PlayMode 双门禁如果你正在学习 LangGraph也可以按照 Day01 到 Day19 的顺序查看而不是一开始就直接读最终版本。Day01Day15 主要建立 Coding Agent 的闭环Day16Day19 则进一步补齐可信知识、权限审计、团队观察和隔离执行能力。二、项目环境准备1. 基础环境Windows 10 / Windows 11 Python 3.10 及以上推荐 Python 3.11 Git Unity 2022.3 LTS Unity Test Framework 能够覆盖默认角色路由的 Provider 组合完整工作流需要真实 Unity Editor。如果只是查看 Day01Day19 的离线 Notebook或者运行不依赖 Unity 的测试则可以暂时不配置 Unity 和大模型 API。2. 下载项目gitclone https://github.com/MaddieMo1/LangGraph-Coding-Agent.gitcdLangGraph-Coding-Agent也可以在 GitHub 页面点击Code → Download ZIP下载完成之后解压。小提示Windows 下建议把项目放在路径较短的目录中尽量避免特殊字符。3. 创建 Python 环境使用 Anacondaconda create-nlanggraph-coding-agentpython3.11-yconda activate langgraph-coding-agent不使用 Anaconda也可以使用 venvpython-mvenv .venv .venv\Scripts\activate4. 安装依赖python-mpipinstall--upgradepip pipinstall-rrequirements-lock.txtrequirements-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.exampleCopy-Item.env.example.env打开.env根据自己的环境修改。2. 配置模型 API默认路由会按 Agent 角色选择不同模型不是只配置一个 Provider 就能覆盖完整工作流。当前最小组合可以选择DeepSeek Kimi 或者 DeepSeek Qwen下面先以 DeepSeek 为例填写第一组配置DEEPSEEK_API_KEY替换成你自己的_API_Key DEEPSEEK_MODELdeepseek-chat DEEPSEEK_BASE_URLhttps://api.deepseek.com然后至少再配置 Kimi 或 Qwen如果四家服务都可用也可以全部填写KIMI_API_KEY替换成你自己的_API_Key KIMI_BASE_URLhttps://api.moonshot.cn/v1 QWEN_API_KEY替换成你自己的_API_Key QWEN_BASE_URLhttps://dashscope.aliyuncs.com/compatible-mode/v1 GLM_API_KEY替换成你自己的_API_Key GLM_BASE_URLhttps://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_PATHD:\Unity\Hub\Unity_Editor\2022.3.62f2c1\Editor\Unity.exeUnity Hub 的常见安装路径类似于C:\Program Files\Unity\Hub\Editor\2022.3.xx\Editor\Unity.exe注意需要填写Unity.exe不是 Unity Hub 的路径。4. 准备 Unity 测试工程创建一个单独的 Unity 测试项目并配置UNITY_TEST_PROJECT_PATHD:\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 Codegit add README.md git commit-mchore: initialize generated code repository然后在.env中填写GENERATED_SOURCE_PATHD:\Unity\AgentGeneratedCode必须先有基线提交因为每个任务都要基于它创建独立分支、校验文件漂移并记录最终 commit。6. 配置运行时状态下面两个配置可选但建议放在项目外部GENERATED_TEST_SOURCE_PATHD:\Unity\AgentRuntime\generated-tests WORKFLOW_CHECKPOINT_PATHD:\Unity\AgentRuntime\workflow.sqlite一个用于保存生成测试一个用于保存 LangGraph SQLite 检查点。这样即使重启程序待审批任务仍然可以恢复。7. 配置本地 Unity Workerv1.2.0 默认使用本机子进程 Worker也可以显式连接受 HMAC 保护的 HTTPS Worker。首次在 Windows 上准备本地 Worker 时先确保已经通过防火墙、虚拟机或容器真实阻断 Worker 的公网访问然后运行.\scripts\setup_local_worker.ps1 -UnityEditorPathC:\Program Files\Unity\Hub\Editor\2022.3.62f2c1\Editor\Unity.exe-UnityProjectPathD:\Unity\Unity_Project\CodingAgentTest-GeneratedSourcePathD:\Unity\AgentGeneratedCode-WorkerStatePathD:\Unity\AgentRuntime\unity-worker-NetworkIsolationEnforced脚本会创建独立 Worker 状态目录、生成不含凭据的启动器并运行环境预检。它是幂等的不会修改防火墙也不会自动建立网络隔离-NetworkIsolationEnforced只是操作者对已有隔离证据的明确确认。Worker 状态目录不能位于控制器仓库、Unity 工程或生成代码仓库内部。8. 配置审批身份、审计和团队观察Day17 默认使用服务启动时绑定的本地身份角色可以是viewer、reviewer、approver或operator。审批记录以追加式 JSONL 审计链保存APPROVAL_ACTOR_IDlocal-maintainer APPROVAL_ACTOR_ROLEapprover APPROVAL_AUDIT_PATHD:\Unity\AgentRuntime\approval_audit.jsonlDay18 的团队观察默认关闭。需要局域网只读观察时应设置唯一的 32256 字符令牌并优先配置 HTTPS 证书OBSERVATION_ENABLEDtrue OBSERVATION_READ_TOKEN替换成独立的只读访问令牌 OBSERVATION_SERVER_NAME0.0.0.0 OBSERVATION_SERVER_PORT7860 OBSERVATION_TLS_CERTFILED:\Unity\AgentRuntime\certs\observer.crt OBSERVATION_TLS_KEYFILED:\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. 使用命令行入口如果希望从脚本创建任务也可以使用正式 CLIpython 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 返回 passtrue 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 的指标如下指标结果端到端成功率2 / 4编译成功率2 / 3Repair 成功率1 / 2功能稳定性5 / 5这些分母来自固定基准契约不代表线上流量也不会把环境阻塞强行算成代码质量问题。真实 Provider Unity 验收中项目已经跑通过完整 Repair 链路第一次 Unity 编译失败 → Reviewer 定位根因 → Repair 生成修复提案 → 第二次人工审批 → Code Checker 通过 → Unity 编译通过 → 14 / 14 EditMode 测试通过 → Reviewer 100 分 → 创建本地 Git 提交v1.0.0 教程与发布材料阶段曾完成346 项 Python 回归。随着 Day16Day19 和交付加固功能加入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.mdDay01Day19 的离线 Notebook 和 Python 回归可以在没有大模型、没有 Unity、没有密钥的环境中运行。真实 Provider、Unity、证书链和 Worker 网络隔离仍然需要单独的真实环境验收不能用 fixture 或 GitHub Actions 代替。十三、常见问题1. 启动后找不到模型检查.env是否位于项目根目录再确认变量名、Base URL 和 API Key。然后执行python-mtools.environment_check2. 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 验收记录交接与用户操作指南路漫漫其修远与君共勉。