> 先说结论：用 CrewAI 多智能体编排 + Unity MCP，让 AI 从一句话需求自动产出可玩的 Unity 游戏——**今天做不到**。这是我花两个月、写了 188 个 commit、约 6 万行代码、跑了 N=5×5 LLM 实验后，才得出来的真话。本文摊开三件事：**emit_output 0/25 翻车实测**、**output_pydantic 反转生产级陷阱**、**7 层防御如何把可用率从 0% 拉到 85%**。如果你也在用 CrewAI 做类似工程，希望省你几周时间。

---

## 1. 立项口号 vs 一个月后的真话

立项口号一句话：**「用户输入一句话需求，AI 编排多 agent 协作，自动产出一个能跑的 Unity 游戏」**。

技术栈最终落到：**Tauri 2.x + React 19 前端 + Python FastAPI 后端 + SQLite 持久化**，188 个 commit、47 个 backend service 文件、约 6 万行代码。CrewAI 跑了 v1 → v2 → v3 三轮架构，光 PM（项目经理）层就重写了 5 次。

---

## 2. 能做到的 vs 做不到的

**能做到**：

- 单个 C# 脚本生成（Qwen + 正确配置基本稳）

- 确定性资源处理（图片 / 音频走脚本化 100% 可靠）

- 半自主多步骤流水线 + 人审 checkpoint

**做不到**：

- 用户按一个按钮、零干预、产出一个可玩 Unity 项目

**最隐的那面墙**：在 N=5×5 个 LLM provider 组合的实测里，CrewAI 的核心交接工具 `emit_output` **0/25 次被 agent 自然触发**。根因在于LLM基于概率推理，而非真正理解工具的含义，在工作流中难以像Claude单词命令一样稳定触发工具。

这不是模型不行，也不是 CrewAI 不行。这是 2026 年这个时间点，用现有大模型 + Agent 框架做这类「严格结构化输出 + 长链路一致性 + 重型外部工具同步」复合任务的真实能力边界。

---

## 3. 核心瓶颈：`output_pydantic` 反转生产级陷阱

CrewAI 1.14 有一个未公开的架构特性，最值得任何打算上 `output_pydantic` 的人警惕。

**假设**：用 `Task(output_pydantic=Spec)` 让框架接管 schema 强制，就能干净取代手写 `emit_output` 工具调用。听起来很对。

**Probe 1（孤立环境）**：Qwen-plus + ExecutorSpec，N=10，10/10 pydantic OK、9/10 一次成功、平均 1.1 LLM call/trial。漂亮。

**Probe 2**：`tool_choice={"type":"function","name":"verify_outputs"}` 在 Qwen 上 5/5 强制成功。架构全绿。

**部署到生产**：7 个代码 task，4 个 `status=done` 但磁盘上文件根本不存在。**真成功 0 个**。如果不是我和Claude没有真正理解其用法，那就是当前架构本身存在隐患。

Phase 4 跑了 5 组受控变量实验：

| 变体 | 真成功率 |

|---|---|

| baseline (`output_pydantic` + 普通 prompt) | 0/5 |

| strong_prompt（强化引导） | 0/5 |

| high_iter（`max_iter=8`） | 0/5 |

| simple_tool（简单工具） | 0/5 |

| **no_pydantic（去掉 `output_pydantic`，用 `verify_outputs` 工具）** | **5/5** |

prompt 强化、提高 iter、换工具——全救不回来。只有去掉 `output_pydantic` 才恢复 agent 的工具调用行为。

**根因**：框架接管 schema 后，agent 把目标从「做事再产 JSON」扭曲成「直接产 JSON」，**工具循环被框架短路**。CrewAI GitHub issue #1338、#2895 都有类似抱怨。

这里有一条超出项目本身的工程教训：**评估架构改动时，必须同时测「理想路径」和「副作用路径」**。10/10 schema 成功 × 0/5 工具调用 = 净负回归。孤立单元测试的盲区。

---

## 4. 7 层防御：把可用率从 0% 拉到 85%

为了给「LLM 不真理解指令」这个无法根治的问题兜底，v3 在执行链路上累积了 7 层防御。每一层都是某次事故后加上去的：

| # | 防御层 | 来源事故 |

|---|---|---|

| 1 | `emit_output` schema 校验 | v2 散文 schema 不可靠 |

| 2 | `emit_output` 路径存在性检查 | 「agent 说写了但其实没写」 |

| 3 | `code_contract` regex 校验 | Sonnet 漏 4-5 个签名 |

| 4 | `code_contract` AST 语义校验（tree-sitter） | regex 对 property body 风格假阴性 |

| 5 | `_rescue_react_emit_output` | agent 把 Action/JSON 写在 text 没真调 tool |

| 6 | `_rescue_by_file_existence` | 写了文件但忘 `emit_output` |

| 7 | `workflow_svc` server-side disk truth check | agent 编 `file_paths` 但磁盘没文件 |

第 4 层那个 AST 升级值得单独说。第一版用 regex 校验代码契约，写 `public int Score { get; set; }` 没问题，模型写 `{ get => _x; set { OnX?.Invoke(); } }`——同一个 API 不同 body，regex 假阴性。21 个 test case 跑下来正样本一片爆。换 tree-sitter 走 `(kind, name)` 语义键匹配，body 风格无关，21 个 case 全过。

**一个月下来，这 7 层把单点任务的可用率从 0% 拉到 85%**。

底层 framework 不给硬保证，所以每个失败模式都要在外面再补一道墙。

---

## 5. LLM 模型实测 + 行业对比

跑下来 4 款模型的工具调用可靠性：

| 模型 | 工具调用可靠性 |

|---|---|

| DeepSeek v4-flash | 不支持 `tool_choice=required`；DSML token 5/5 泄漏（native path）；强制走 LiteLLM 才稳 |

| **Qwen-plus** | **工具调用最稳；支持 `response_format=json_schema`；`tool_choice` specific 模式 5/5 强制成功** |

| GLM-4-plus | 同 Qwen，文档稍弱 |

| MiMo v2.5-pro | 不稳定，2/5 trial 报 None/empty |

**结论**：模型在「单步骤工具调用」这件事上其实有解（Qwen + 正确配置）。问题在「多步骤工具编排 + 严格输出」的复合场景，**所有模型都不可靠**。这是当前 LLM 真实能力边界，不是「哪家不行」。

行业横向数据（2026 年时点）：

- CrewAI 代码生成成功率 **54%** vs LangGraph **62%**

- Devin 自报 SWE-bench **13.86%**（Cognition 没更新 2025/2026 数据）

- 生产环境多 agent 系统失败率 **41-86.7%**

- Context 保留每步丢 2%，**5 步循环后只剩 60% 原始上下文可访问**

- **没有任何公开的"AI 一键搭 Unity 项目"产品**

所以「自动生成可玩 Unity 游戏」今天做不到，**不是个人能力问题，是整个行业的 stretch 目标**。

---

## 6. 走过的 5 个弯路（如果你打算走同样路）

1. **v1 → v2 把 UI 做在不稳定核心之上** —— 用户看见完整 app，但每次跑都失败。先磨稳核心 1-2 个场景的端到端，再做 UI

2. **迷信 agent 会按 prompt 守规矩** —— `emit_output` 0/25 真触发。4 个 rescue 不是 4 个独立 bug，是同一个架构假设「工具会被调」的 4 次破绽

3. **把 schema 严谨等同于框架接管** —— `output_pydantic` 看起来比手写 tool 优雅，Probe 1 漂亮就上，生产 0/7 翻车

4. **`code_contract` 第一版选 regex** —— 写 regex 容易，但 property body 风格假阴性。直接上 AST 是对的

5. **用 git log 做诊断而不用日志/产物** —— 任何时候都要 evidence-first。读 `out.json`、读 LLM raw response、加 instrumentation；不是读 commit 揣测

---

## 7. 下一步怎么走

| 方向 | ROI |

|---|---|

| **降低自主度 + 加人审 checkpoint** | ✅ 短期推荐。半小时 demo 一个游戏，用户当审核者 |

| **脚本化更多确定性步骤** | ✅ 中期推荐。图片生成已 100% 可靠，可扩展到文件创建 / prefab 装配 / asset import |

| **等下一代模型自然变好** | 1-2 年视野推荐。GPT-5 / Claude Opus 5 / Qwen3.7 在路上 |

| **换 stack（Anthropic API / LangGraph / 自研）** | 高投入。没有明显赢家，痛点会以不同形式在别处出现 |

---

## 8. 总结

产品意义上这个项目"失败"了——今天还做不出「一键 Unity 游戏」。工程价值在另一面：

- 188 次 commit / 188 次失败 + 微调 = 一份对 CrewAI 在生产严谨场景真实表现的高保真观察

- 7 层防御机制 + 5 个 PM 重写迭代 = 一份「如何在不可靠 framework 上加 enforcement 层」的工程参考

- N=5×5 provider 实验 = 一份可复用的 LLM 工具调用基准

如果你也在做「LLM 自主代码生成」类项目，希望本文的 7 个防御机制清单、`output_pydantic` 反转数据、5 模型对比表，能省你几周时间。

> 项目已开源（PolyForm Noncommercial）：<https://github.com/Joe-Hank/MyCrew_Desktop>

> 欢迎在评论区交流 CrewAI / LiteLLM / Agent 工程相关问题。

---

## 参考资料

- [CrewAI Issue #1338: Pydantic schema not in system prompt](https://github.com/crewAIInc/crewAI/issues/1338)

- [CrewAI Issue #2895: Gemini Tool Calling Fails with null tools](https://github.com/crewAIInc/crewAI/issues/2895)

- [When Agents Fail to Act: Diagnostic Framework (arxiv 2601.16280)](https://arxiv.org/abs/2601.16280)

- [Beyond pass@1: Reliability Science for Long-Horizon Agents (arxiv 2603.29231)](https://arxiv.org/abs/2603.29231)

- [Unity MCP - AI Game Development Bridge](https://github.com/IvanMurzak/Unity-MCP)

- [CrewAI Hit 47.8K Stars and 2 Billion Agent Runs (2026 Report)](https://digitalbydefault.ai)

---

*环境：Windows 11 + Python 3.13 + CrewAI 1.14.4 + LiteLLM 1.85+，实测数据基于 MyCrew 项目 2026-04-22 ~ 2026-05-21*