我构建了一个通过 WebSocket 控制 Unity 编辑器的智能体，而不仅仅是生成代码架构文档

大多数“面向游戏开发的 AI”工具要么生成 C# 代码交付给你，要么作为聊天插件嵌入在编辑器中。它们都有一个共同的缺陷：无法查看运行时状态，因此无法告诉你预期效果是否真正达成。你粘贴进一段脚本，结果不对劲，却不知道是智能体的问题、项目本身的问题，还是某个未更新的序列化引用导致的。 我一直在构建一种不同的方案：一款保持与编辑器实时 WebSocket 连接的桌面应用程序。该智能体读取控制台输出，检查实际的组件值，并验证其执行的操作是否产生了预期的状态。即：静态项目上下文，辅以实时运行时状态。 技术栈： * 客户端采用 Electron + React，主进程中运行 LangGraph.js 智能体 * Unity 内部的 C# 桥接包，监听 WebSocket 并通过编辑器 API 执行操作 * Next.js 控制平面，代理 LLM 调用（直接对接 Anthropic + OpenRouter） * 使用 Qdrant 进行 RAG（检索增强生成），通过工具调用检索而非系统提示词注入（系统提示词注入会破坏缓存命中率） 行之有效的方法： * 将 18 个细粒度工具封装精简至 5-7 个工作流工具。工具选择准确率大幅提升，跨步骤的累积错误显著减少。 * 采用双层模型配置，并端到端集成提示词缓存。简单任务使用 Haiku，复杂的多步任务使用 Sonnet。启用缓存后的会话成本远低于无缓存运行。 * 通过回读状态来验证每一步操作。这能捕捉大量静默失败（如组件添加到错误对象、引用未传播等）。 无效的方法： * 空间推理是一个模型问题，而非工具问题。完美的运行时可见性并不能帮助智能体理解为什么摄像机会穿墙。 * 早期尝试给模型提供大量细粒度工具——选项越多，模型的选择能力反而越差。 * 试图将 RAG 塞入系统提示词以实现“常开上下文”。这杀死了缓存，导致冷启动成本占据主导。 下一步计划集成播放模式，使智能体能够实际运行游戏、观察发生的情况并进行迭代。目前运行时可见性仅限于只读。 我很想了解其他构建编辑器风格智能体（不限于 Unity，任何工具均可）的人遇到了哪些问题。运行时状态与静态上下文之间的权衡似乎是一个普遍存在的难题。