ludeo-unity-integration

Unity 中集成 Ludeo SDK

技能版本： 2.0.0 · 固定使用 Ludeo Unity 插件 v4.3.0 API（com.ludeosdk.unity 4.3.0）。请与最新版本对比，确认已安装的副本为最新版本。如果版本较旧，请运行 npx skills update ludeo-labs/integration-skills/skills/ludeo-unity（然后启动新的 Agent 会话——SKILL.md 会在每个会话中缓存）。

⚠️ v4.3.0 是一次破坏性 SDK 重写。 如果你使用的是旧版插件（InitLudeoSession、LudeoStateObject/SetAttribute、AddNotify*、LudeoGameplaySession），请参阅 references/ludeo-integration-docs/12-SDK-API-REFERENCE.md 中的“v4.3.0 中的变更”表——现在初始化使用 Initialize()+SessionManager.CreateSession，通知使用 C# 事件，捕获通过 LudeoRoom.Writer + 作用域限定的 WriteData 完成，游戏会话则为 LudeoPlayer。

本技能将引导 Agent 在 Unity 游戏中集成 Ludeo SDK，使用的是 Ludeo Unity 插件（托管的 LudeoSDK C# API），涵盖从安装程序包到动作映射、对象跟踪、状态恢复和运行时验证的全过程。

这是 Unity 专用技能。 对于 C++/专有引擎，请改用 ludeo-unreal-integration。两者采用相同的工作流方法；本文内容均以 Unity/C# 习惯用法表达（MonoBehaviour 生命周期、场景、预制件、托管的 LudeoSDK API）。

开始前建议使用前沿模型。 集成质量很大程度上取决于模型能力，而用户通常使用较弱的模型（例如 Sonnet）。在开始集成时，建议用户切换到 Opus 4.8（或同等的前沿模型）再继续。

适用情况

当用户提出以下任何要求时，启用此技能：

• “将 Ludeo 集成到我的 Unity 游戏中”
• “在 Unity 中设置 Ludeo SDK”
• “添加 Ludeo 动作跟踪”（Unity 项目）
• “使用 Ludeo SDK 构建我的 Unity 游戏”
• “在 Unity 中接入 Ludeo 生命周期”

如果项目不是 Unity 项目（没有 Assets/、ProjectSettings/、Packages/manifest.json 或 .asmdef/.unity 文件），请停止并引导用户使用适用于其引擎的技能。

请先阅读

不要把 C++/主循环的假设套用到 Unity 项目上——这会让你去寻找不存在的东西（main、由游戏编写的循环、构建脚本），并错过实际存在的内容（场景、MonoBehaviour 回调、预制件、已安装的程序包）。完整的 Unity 结构模型和代码库扫描搜索模式位于阶段 2（references/2-map-game-code.md）；后续各阶段也都结合了所需的 Unity 实际情况。

在阶段 1 之前，请先阅读 references/ludeo-integration-docs/00-CRITICAL-REQUIREMENTS.md——其中的强制规则已针对 C# 包装器重新校准。

此技能在 learnings/ 中有一套经验记录——整理自过往集成的修正内容。每个阶段开始时都要加载相关经验，并在发现新经验时立即记录。 加载和记录规范见下文的 经验记录；这不是可选项。

工作流

此集成是一套顺序工作流，现在按8 阶段指南顺序（表格中的 Phase 列）执行，而非沿用旧文件编号（编号调整暂缓）。 执行顺序为：1 安装 + KYG → 2 映射代码 → 3 SDK 生命周期 → 4 映射对象 → 5 追踪与恢复（一个迭代式波次循环，将一次捕获转化为可游玩的 Ludeo——波次 1 = 可恢复主干，然后逐步扩展） → 6 操作 → 7 验证 + 上传 → 8 打磨与完成。请注意，根据指南，操作（阶段 6）在追踪与恢复（阶段 5）之后执行——先验证玩家流程（波次 1 能够恢复），再丰富操作。阶段 8 是一个循环，而非终点：它会检查 Ludeo 仍可捕获哪些状态，提出建议，并在用户希望扩展时，重新进入阶段 4 和 5，将其作为新波次添加（然后由阶段 7 重新上传扩展后的构建），再完成收尾。除非用户表示已完成较早阶段，否则始终从阶段 1 开始。每次只完成一个阶段，并在进入下一阶段前与用户确认。从顶层报告每个阶段的开始和结束情况，遵循 references/ludeo-studio-mcp.md 中的报告进度要求，并告知你调度的每个子 Agent 不要调用 ludeo-mcp 工具。

阶段 3、5 和 6 由编排器协调。每个阶段都是一个由单任务简报组成的逻辑指南阶段，由轻量编排器负责调度，每个任务对应一个子 Agent（Agent 工具），并通过文件传递产物——因此用户体验到的是一个完整阶段。

• 阶段 3（“规划并实现 SDK 生命周期”）遵循 references/3-lifecycle-orchestrator.md： 任务 1–4 自动运行，编译 + 运行关卡则交由人工处理。
• 阶段 5（“追踪与恢复”）遵循 references/5-tracking-restore-orchestrator.md，并按迭代式波次循环运行：阶段 4 生成一份清查结果 + 波次计划，阶段 5 则一次实现一个波次——每个波次依次执行：深度范围界定（任务 0）→ 捕获（任务 1）→ 恢复计划（任务 2）→ 重建（任务 4）；恢复流程（任务 3）则仅在波次 1 中构建一次。波次 1 验证完整的捕获→重放往返流程，覆盖可恢复主干 + 必需项；后续每个波次都会扩大追踪范围。每个子任务都以一个由编排器执行的关卡结束。将每个关卡拆分为两部分：Agent 自行验证编译部分（使用无头 -batchmode，然后读取日志——它没有交互式 Console，但 Console 的输出会记录在日志中）；人工部分仅限于需要真人参与的环节——捕获/重放关卡需要人工捕获并游玩一个 Ludeo，然后评估保真度。如果关卡未通过，则携带日志重新调度修复子 Agent；若故障根源在较早波次的状态，则重新打开该较早波次。
• 阶段 6（“操作”）遵循 references/6-actions-orchestrator.md：映射 → 实现，然后进行一次人工编译 + 日志关卡（每个操作都必须在 Creator 和 Player 流程中同时触发）。 | 阶段 | 文件 | 用途 | | --- | --- | --- | | 1 | references/1-build-game-with-sdk.md | 下载最新的插件版本（github.com/ludeo-labs/unity-plugin-releases）+ 安装 UPM 包，设置脚本定义 + LudeoSettings，进行基线编译和启用 SDK 后的编译，运行 KYG（了解你的游戏）（包括游戏级别的存档系统分类） | | 2 | references/2-map-game-code.md | 生成 Unity 项目的 CODE_MAP（场景、MonoBehaviours、预制件、管理器） | | 3 | references/3-lifecycle-orchestrator.md | SDK 生命周期（编排）——将下方五份任务说明作为子 Agent 分派；规划恢复入口 + 非游戏玩法处理 | | 3 · 任务 1 | references/3a-find-sdk-integration-points.md | 将每个游戏事件映射到 [SDK]/[Layer] 调用点 | | 3 · 任务 2 | references/3b-create-tdd.md | 编写技术设计文档（架构、策略、风险） | | 3 · 任务 3 | references/3c-plan-sdk-lifecycle.md | 规划 LudeoController 层 + 通知注册 + 非游戏玩法事件发送 | | 3 · 任务 4 | references/3d-implement-sdk-lifecycle.md | 实现 LudeoController/Flow/SessionManager 层 + 接入钩子 | | 3 · 任务 5 | references/3e-compile-and-fix.md | 在编辑器中编译（定义启用和关闭），修复问题，确认捕获叠加层 — 需人工把关 | | 3f | references/3f-classify-save-system.md | 已被取代： 游戏级存档分类已移至阶段 1 的 KYG；实体级矩阵移至阶段 4。待退役。 | | 4 | references/4-map-game-objects.md | 阶段 4 指南 — 清点 + 波次计划（A 部分）：列出每种可追踪对象类型，标记承重对象，分配波次（波次 1 = 可恢复主干 + 必备集合）。包含阶段 5 按波次执行的B 部分深度范围确定流程。此处不涉及深度细节或代码 | | 5 | references/5-tracking-restore-orchestrator.md | 追踪与恢复（编排、迭代式波次循环）——逐个波次实施波次计划；将下方任务说明作为子 Agent 分派；每个子任务、每个波次均设有人为把关环节 | | 5 · 任务 0 | references/5a-deep-scope-wave.md | **每个波次：**确定本波次类型的深度范围（执行阶段 4 的 B 部分）→ 向 OBJECT_TRACKING.md 追加 ## Entity 行 | | 5 · 任务 1 | references/5b-implement-object-tracking.md | **每个波次（增量）：**为本波次类型接入 ILudeoStateHandler 注册和每帧属性捕获 | | 5 · 任务 2 | references/5c-plan-state-restoration.md | **每个波次（追加）：**为本波次规划恢复方案（objectType 分桶、两遍处理）→ RESTORATION_PLAN.md | | 5 · 任务 3 | references/5d-implement-restoration-flow.md | 仅一次（仅波次 1）：实现恢复流程：LudeoSelected→GetLudeo→播放流程、冻结/叠加层、RoomReady→Begin、ApplyRestoredState() 存根 | | 5 · 任务 4 | references/5e-implement-state-reconstruction.md | **每个波次（增量分桶）：**为本波次填充 ApplyRestoredState()——两遍处理：从分桶生成并应用状态、引用、延迟属性、环境 | | 6 | references/6-actions-orchestrator.md | 操作（编排）——将下方两份任务说明作为子 Agent 分派；在阶段 5 之后运行（玩家流程已验证）；设置一个人工编译 + 日志把关环节 | | 6 · 任务 1 | references/6a-map-game-actions.md | 查找游戏代码中的操作点（从玩家视角；包括阶段 3 规划的非游戏玩法标准操作） | | 6 · 任务 2 | references/6b-implement-game-actions.md | 插入 SendAction 调用（游戏玩法 + 非游戏玩法）+ 记录一次性的平台全局触发器映射 | | 7 | references/7-upload-build.md | 阶段 7 指南 — 验证发布版本（validate-build）+ 准备构建并使用 ludeo CLI 上传至 Ludeo 平台，然后轮询状态直至变为 ready | | 8 | references/8-polish.md | 阶段 8 指南 — 润色与完成（循环）。检查是否存在 Ludeo 仍可捕获的状态缺漏，提出建议；用户同意后重新进入阶段 4 和 5，将其作为新波次加入（通过阶段 7 重新上传）；此外进行外观/时序润色 + 修复先前的错误；最后在 TDD 中记录完成情况。自身不分派任务——而是返回波次循环 |

重要规则

• 一次只进行一个阶段。 进入下一阶段前，先征得用户确认。

• 面向集成人员写作，而不是面向技能写作——但要介绍产品。 三类词汇，承担三种不同的作用：

  1. 产品术语——Ludeo、Studio Lab。要教会他们这些术语，绝不要避开。 集成人员正在交付 Ludeo 集成，他们的玩家也会看到这个词。首次使用时，只需清楚地定义一次（“一个 Ludeo——一段可直接插入的短小可玩片段”），之后正常使用。为了让内容显得易懂而绕开产品名称，会让他们看不懂文档、控制面板或自己的待办事项。
  2. SDK API 名称——LudeoRoom、WriteData、SendAction。 当主题就是他们将阅读或编写的代码时，这些名称既准确又必要。不要用 API 名称代替对行为的说明：“OpenRoom 开始捕获本次运行的状态，CloseRoom 结束捕获”，而不是只写一个 OpenRoom——并且注意这种解释刻意避开了什么：“录制”。参见下文的转述陷阱。
  3. 技能内部的简写——CR-006、Wave 1、“two-pass”、“non-ludeoable”、“readiness gate”、每次合作各自的问题标签（SHIP-2）、用作名词的阶段编号。 这些是我们内部使用的，对他们毫无帮助。在 Agent 之间交流以及 ludeo-integration-plan/ 文件中可以使用；任何人类会阅读的内容都应将其转换为易懂的说法——例如“根据种子重建关卡，然后放回物体”，而不是“CR-006 two-pass”。如果 ID 确实有用（例如文件按 ID 编号），应将其放在通俗表述后面的括号中，绝不能用 ID 取代表述。

  通俗表述必须保留区别，而不是将其抹平。 转述会丢失信息。替换术语前，先问问它承载了什么区别，并检查替换后的说法是否仍保留了这个区别——尤其是那些专门用于区分容易混淆概念的词汇。已发现的问题： 有个 Agent 在遵循这条规则时，将 Room 解释成了“录制”。这会让人误以为捕获的是视频（实际捕获的是状态，不是视频片段），也会把 Room 和 Ludeo 混为一谈——这会导致对第 3 阶段的范围界定错误，而且同一场会话中已经两次提醒过该 Agent。正确说法（依据实时 SDK 文档 GameplaySessions）：一个 Room 界定一个被捕获的游戏片段；平台会从该片段中派生 Ludeo——某个片段能生成多少个 Ludeo，并非由游戏决定。 如果某种简化让已提醒过的混淆更容易发生，那就不算简化。 **测试标准：**一名熟练但从未听说过此 SDK 的 Unity 开发者，能否读懂每句话，并且能对内容提出异议？他们提出异议，是协作过程中最重要的纠错方式；如果他们看不懂术语，就无法进行你最需要的审查。如果有人质疑某个术语，就调整整体用语风格，而不只是修改那个术语。

• **每个编写代码的阶段结束时，都必须设置重新编译 + 运行关卡（硬性要求）。**会编辑 .cs 文件的阶段（4、7、9、11、12）都必须要求集成人员在阶段结束时：(1) 将焦点切回 Editor，确保重新编译成功；(2) 运行游戏，确认仍可正常运行。Unity 会在焦点切回时重新编译，因此“编译”是每个阶段都要面对的实际工作，并非一次性里程碑。对于编排式阶段（3、5 和 6），由编排器执行这些关卡——它会派发代码生成子 Agent（不会编译），然后向人工操作者提出重新编译 / 运行关卡；若失败，则附上日志重新派发修复子 Agent。Agent 会尽可能读取 Editor.log / Player.log，但无法真正验证这两步；除了日志之外，它只能依赖集成人员的确认。在对方确认两项都已完成（或明确选择跳过）之前，不要继续。编译与修复循环以及 error CS 表位于 phase 3 · task 5；关卡会引用该处，不再重复。

• **先建立 Unity 心智模型。**在进入阶段 1 之前，先理解上述“先读此处”模型（以及阶段 2 的“Unity 游戏的结构”），并以此指导每次搜索和操作。

• **默认将对象作为属性跟踪，而非数据块。**SDK 同时支持这两种方式；Ludeo 强烈倾向于基于属性的集成。在映射和跟踪对象时（阶段 4–5），默认捕获离散的类型化属性（WriteData(name, int/float/double/bool/string/Vector3/Quaternion)，放在 using (obj.EnterObjectScope()) 内），不要询问用户该用哪种方式。仅当用户明确提出，或实体确实不透明时，才使用数据块 / byte[] 存储——参见 06-TRACKING-PATTERNS.md。不透明值（枚举、类型代码、内容 ID）还应附带一个配套的 <Attr>Name string 标签，这样下游就能将 EnemyType: 3 显示为 EnemyTypeName: "HeavyGunner"——数值仍是真实数据源，恢复时绝不读取该标签（06 §1.5）。

• **写入和读取都必须限定作用域（CR-002，v4.3.0）。**每次 WriteData / ReadData 都必须在 using EnterObjectScope() 内执行（组件作用域嵌套其中）。规定的 ILudeoStateHandler 按每个 tick 管理写入作用域，因此游戏逻辑代码只需调用 WriteData；但恢复应用代码必须自行开启读取作用域。参见 12-SDK-API-REFERENCE.md 和 00-CRITICAL-REQUIREMENTS.md。

• **SDK 会自行执行 tick。**插件会实例化一个 LudeoUnityManager 来驱动 SDK Tick。不要将 SDK Tick 接入 Update 循环。游戏只负责驱动自身的 UpdateStateObjects() 属性采样节奏。

• 优先使用 Ludeo 层；条件允许时尽量少改游戏文件（这是偏好，不是硬性规定）。 集成正确性优先——绝不要为了避免修改游戏代码而扭曲集成方式、跳过必要的钩子，或与游戏架构对着干。话虽如此，如果有干净的实现方案，就将逻辑放在游戏的 Ludeo 集成文件夹（[Layer] 类——unity/REFERENCE-ARCHITECTURE.md）中，并尽量让对游戏自身源代码的修改保持精简、机械化（最好只添加一次门面调用或事件订阅）。游戏文件改动越少、越小，集成就越容易审查、隔离和移除——应尽量如此，但两者有冲突时，始终以正确性为先。

• 禁用 Ludeo 主要是运行时问题，而非条件编译问题。安装软件包后，它会自动引用（无需配置 asmdef）。通过接口调用所有 SDK 功能，这样在用户未同意 / 尚未初始化的状态下，就能回退到 Dummy* / Disabled* 实现，让游戏正常运行。脚本定义（例如 LUDEO_SDK）是可选的——只有在必须发布完全不包含 SDK 软件包的构建版本时才需要。

• **未经查阅文档，绝不要声称 SDK 具有某项行为。**搜索 sdk-docs MCP 服务（见下文 MCP 配置），或阅读随附的 references/ludeo-integration-docs/。如果两者都没有相关说明，就明确指出不确定之处，不要猜测。

• **工作流文件中的路径均相对于工作流文件本身。**例如，位于 references/N-*.md 的工作流文件中写着 ludeo-integration-docs/<file>.md，表示从该位置访问文档文件夹。

• Agent 将输出写入游戏的 Unity 项目，而非此技能。例如，ludeo-integration-plan/CODE_MAP.json 会创建在 Unity 项目根目录下。

• **建议开启新会话。**每个阶段都会产生大量上下文。如果某个阶段运行了很久，建议用户在下一阶段开始时新建 Agent 会话。

经验总结

learnings/ 是此技能的经验库：收录了以往集成中经过脱敏处理的修正内容，按 architecture/、common-mistakes/、engine-quirks/（Unity/C# 特有问题）和 save-systems/ 分类。每个文件记录一条经验，并包含 frontmatter（category、tier、sourceGame、phase、question、sanitized）。

加载 — 每个阶段开始时

经验库会随着每次集成不断扩充；每个阶段都阅读所有文件，会占用该阶段实际工作所需的上下文。请先读索引：

1. 完整阅读 learnings/INDEX.md。 每条经验占一行：path | tier | phase | hook。hook 是这条经验的前置条件问题（若没有，则是其标题）。索引中的条目只是指针，不是经验内容——绝不能只根据索引行引用或应用某条经验。
2. 完整阅读所有 phase 与当前阶段匹配的条目正文，不论其 tier。阶段标签采用保守标注，因此这只是最低要求，不是全部工作。
3. 根据你对该项目的了解，逐一核对其他 hook（是否需要通过菜单启动，还是直接进入游戏？是否使用对象池？没有存档系统？追踪方式是 blob 还是 attribute？），并阅读所有可能相关条目的正文。宁可多读——阅读正文成本很低；错误地跳过经验则可能导致集成出问题。
4. 在阶段中途重新查询索引。 遇到新主题（同意/覆盖层、恢复顺序、对象池生成、动作发送等）时，搜索索引并在自行摸索前阅读匹配条目。
5. 交叉检查完整性： 将索引中的 Total: 数量与 Glob(pattern: "**/*.md", path: "<skill-base-dir>/learnings") 进行比较（直接从 learnings 目录执行 glob——learnings/** 前缀在 Windows 上会失败；计数时减去 INDEX.md 本身）。如果有文件未列入索引，也要阅读——这说明索引已过期；请重新生成（node scripts/generate-learnings-index.mjs），或手动补上缺失行。

Tier 含义（严格）： universal = 适用于每一个 Unity Ludeo 集成，且没有任何前置条件。generalizable = 仅在满足指定前置条件时适用（question 字段就是该前置条件——应用前，先确认它在当前项目中成立）。game-specific = 与某一款游戏绑定；不要跨游戏复用。

在决策中引用任何经验之前： 阅读完整正文，确定其前置条件，并以具体证据核实这些条件在当前项目中成立（已阅读的文件、已回答的问题、已运行的测试）。若无法核实前置条件，则该经验不适用——不要引用。绝对化结论（例如“唯一方法”“绝不做 X”）若标记为 universal，就是警示信号——先检查它是否应标记为 generalizable。

捕获——发现时记录，而不是等到阶段结束

经验教训只追加，不覆盖。 在 learnings/{category}/ 下添加新文件；未经人工明确批准，绝不删除或覆盖现有文件。每当出现以下情况时，继续之前先写下经验教训：修复尝试了不止一次，或根本原因与你的假设不同；SDK、引擎或环境的表现与文档描述不一致；人工纠正了你；或你发现了不明显的前置条件、顺序要求或精确 API 签名。推迟记录会丢失可复用的具体细节。

1. 归类（architecture / common-mistakes / engine-quirks / save-systems），并划分层级（参见上文语义）。
2. 使用以下 frontmatter 编写 learnings/{category}/<slug>.md：

   ---
   category: common-mistakes
   tier: generalizable
   sourceGame: FPSSample      # abstract codename only — see config/learning-policy.json
   phase: 4
   question: "..."            # the precondition to re-check on future integrations (null if universal)
   sanitized: true            # attest you ran the sanitization checklist
   ---
   

3. **将其登记到索引中：**运行 node scripts/generate-learnings-index.mjs（如果无法运行 node，也可以按照相同格式手动将条目追加到 learnings/INDEX.md）。加载步骤会先读取索引——未列入索引的经验教训对后续阶段不可见。
4. 保存前进行脱敏——强制要求。 这些经验教训会在未来为其他客户端进行集成时读取；任何残留的客户端特定信息都会泄露某个客户端的代码给所有其他客户端。只记录可迁移的模式，绝不记录客户端的内容：sourceGame 必须是允许列表中的抽象代号；客户端命名空间、.asmdef 和类名必须替换为中性的、基于角色的名称；Ludeo SDK 和 Unity 原生标识符则保持原样。检查标准：读者能否识别出客户端，或复制粘贴属于该客户端的内容？如果可以，就说明尚未脱敏。此要求适用于每个已提交的文件，不只是 learnings/ 中的文件。完整规则和检查清单：references/learning-sanitization.md——编写任何经验教训前请先阅读。 scripts/validate-skill.mjs 会检查结构性要求（代号允许列表、索引是否为最新、客户端标识符防护）。

参考资料

• references/learning-sanitization.md — 如何编写经验教训，同时避免泄露客户端 IP（记录模式，而非内容）；保存前检查清单。config/learning-policy.json 包含代号允许列表。
• references/ludeo-integration-docs/ — 主要集成指南（构建、生命周期、追踪、恢复、API 参考、研究模板、游戏模式手册），均适用于 Unity/C#。
• references/ludeo-integration-docs/unity/ — Unity 专用资料：
  • REFERENCE-ARCHITECTURE.md — 规定的集成层（LudeoController / LudeoFlowSwitch / LudeoGameplaySessionManager / ILudeoStateHandler / LudeoKeys）。
  • UPM-INSTALL-AND-DEFINES.md — 安装路径、脚本定义、虚设实现模式。
  • LAUNCH-AND-READINESS.md — 启动模式（菜单控制启动与直接启动游戏）以及 SDK 就绪检查门控，用于替代菜单中隐式的 Activate／同意等待。
  • CONSENT-AND-OVERLAY.md — 双向的同意门控和暂停／恢复（CR-011）；连接任一方向前请阅读 §3。
  • READING-UNITY-LOGS.md — 在编译／运行门控中定位并读取 Editor.log / Player.log。
• references/ludeo-studio-mcp.md — ludeo-mcp 的接入点（环境查询、Beta 版本、邀请）、已部署的工具，以及读取无需确认、写入需确认的策略。

MCP 配置

本技能中最新且始终有效的 SDK 详情主要来源是 sdk-docs MCP 服务——它会 搜索 Ludeo SDK 文档（API 参考、方法签名、回调链；包括 Unity/C#）。它随技能一同提供 （config/mcp_config.template.json），并在集成者的机器上运行。在开始任何 SDK 工作之前，设置一次即可。

如果尚未连接 sdk-docs，请根据随附模板配置，然后继续。它托管于（HTTP） https://ludeo-mcps-sdk-docs.ludeo.com/mcp，需要设置 X-User-Name 标头为你的 Ludeo 用户名 （Ludeo 邮箱的本地部分，例如 jane.doe）——用于识别调用者。

• Claude Code： 将 <skill-base-dir>/config/mcp_config.template.json 中的 sdk-docs 条目复制到项目的 .mcp.json（或运行 claude mcp add），将 X-User-Name 设置为你的 Ludeo 用户名，然后启动新会话以连接服务。
• 其他 Agent： 将相同条目添加到运行时的 MCP 配置中。
• 如果无法连接，请告知用户，并退而使用随附的 references/ludeo-integration-docs/——但请明确说明这一点，因为随附副本可能与实时 SDK 不一致。

服务	托管端点	用途	后备方案
sdk-docs	https://ludeo-mcps-sdk-docs.ludeo.com/mcp（HTTP，X-User-Name 标头）	搜索 Ludeo SDK 文档	随附的 references/ludeo-integration-docs/
ludeo-context	https://mcp-ludeo-context-internal.ludeo.com/mcp（HTTP，Bearer 令牌）	公司知识、QA 工作流、代码库上下文	不使用；分析质量可能会降低
ludeo-mcp	https://mcp.ludeo.com/mcp（HTTP，OAuth 登录）	Studio Lab 平台操作，否则 Agent 会将其交由用户处理——环境、用于将本地运行路由到环境的 Beta Version Name，以及邀请。接触点与读写策略：references/ludeo-studio-mcp.md	请用户在 Studio Lab 中完成该步骤

从这里开始

阅读 references/1-build-game-with-sdk.md 并按其说明操作。（进入代码库映射阶段后，Phase 2 会建立完整的 Unity 结构模型和搜索模式。）