Claude Code Game Studios 中的 Godot GDExtension 专家 Agent绑定模式、ABI 与内存管理的可验证行为规范【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios本篇技术指南基于仓库中的 Agent 测试规范 godot-gdextension-specialist.md 展开。它定义了 CCGSClaude Code Game Studios框架中专职负责 Godot 原生扩展GDExtension的 AI 专家 Agent 的职责边界、五大行为测试用例与协议合规要求。读完本文你将理解如何用结构化的测试规范约束一个 AI Agent 正确产出 godot-cpp 绑定代码、规避跨小版本升级的 ABI 风险、遵循 Godot 专属的 RAII 内存管理约定并通过/skill-test体系对其行为做可重复的质量验证。一、背景GDExtension 专家在 CCGS Agent 体系中的定位Claude Code Game Studios 将完整的游戏开发工作室层级映射为 49 个 AI Agent 与 72 个工作流技能。其中引擎层按技术栈拆分为 godot、unity、unreal 三个家族每个家族内又细分为多个专职 Agent。以 agents/engine/godot 目录为例Godot 家族包含godot-specialist负责 Godot 架构决策、节点/场景模式、信号与语言选型GDScript vs C# vs GDExtensiongodot-gdscript-specialist负责 GDScript 静态类型、信号架构、协程与性能godot-csharp-specialist负责 C# 侧实现godot-shader-specialist负责着色语言、材质与后处理godot-gdextension-specialist即本文主角负责 GDExtension API、godot-cpp C 绑定、godot-rust 绑定、原生库集成与原生性能优化。这些 Agent 在 catalog.yaml约第 967-968 行中登记spec字段指向各自的测试规范文件用于测试覆盖率追踪。职责边界声明来自规范开头的 Agent SummaryDomain负责GDExtension API、godot-cpp C 绑定、godot-rust 绑定、native library integration原生库集成、native performance optimization原生性能优化Does NOT own不负责GDScript 代码归godot-gdscript-specialist、Shader 代码归godot-shader-specialistModel tierSonnet专家 Agent 的默认层级Gate IDs无该 Agent 不触发任何阶段门。清晰的双向边界是这套体系能并行工作的前提GDExtension 专家只管把 C 的能力暴露给引擎至于 GDScript 侧如何调用、Shader 如何编写分别由专职 Agent 负责。这也与 godot-specialist 中语言专属实现委托给子专家的分工设计保持一致。静态断言Static Assertions规范在结构层面对 Agent 定义文件提出了 4 项硬性检查description:字段存在且为领域专属必须提到 GDExtension / godot-cpp / native bindingsallowed-tools:列表包含 Read、Write、Edit、Bash、Glob、Grep模型层级为 Sonnet专家默认Agent 定义不得宣称对 GDScript 或 Shader 编写拥有权限。这些断言保证了 Agent 定义文件的身份一致性——一个描述含糊、工具缺失或越权宣称的 Agent 定义会在结构检查阶段直接被拦截。二、Case 1域内请求 — godot-cpp 绑定模式的正确产出测试输入Expose a C rigid-body physics simulation library to GDScript via GDExtension.预期行为要求 Agent 产出完整的 GDExtension 绑定模式包含四个组成部分继承基类类继承自godot::Object或合适的 Godot 基类如godot::Node、godot::PhysicsBody3D等视被封装对象类型而定GDCLASS宏注册GDCLASS(MyPhysicsLib, godot::Object)将 C 类注册到 Godot 的类系统使其可被引擎识别与实例化_bind_methods()实现在静态成员函数_bind_methods()中通过ClassDB::bind_method()将物理 API 暴露给 GDScript这是 GDScript 能调用 C 方法的桥梁gdextension_init入口extern C GDExtensionBool gdextension_init(...)作为扩展的初始化入口在内部完成类注册。此外Agent 必须指出.gdextension清单文件格式是必需的——Godot 编辑器/运行时通过该清单定位动态库.so/.dll/.dylib及其入口符号清单中通常包含entry_symbol、libraries按平台列出二进制路径以及compatibility_minimum字段。关键约束规范明确要求 Agent不得顺带产出 GDScript 调用代码——那属于godot-gdscript-specialist的领域。这正是职责边界在具体输出层面的落点Agent 交付API 面方法名、参数类型、返回值而 GDScript 消费方代码由另一个专家接手。Coverage Notes 补充该 Case 的产出应配套一个smoke test验证扩展能够成功加载、且暴露的方法可从 GDScript 侧实际调用。这意味着测试不仅要检查绑定代码是否写对了还要检查绑定是否跑得通——加载失败或符号找不到都属于本 Case 的失败表现。三、Case 2域外重定向 — 跨 Agent 协作协议测试输入Write the GDScript that calls the physics simulation from Case 1.预期行为不得产出任何 GDScript 代码明确声明 GDScript 编写属于godot-gdscript-specialist将请求重定向给godot-gdscript-specialist允许且鼓励以handoff spec交接规格的形式描述 GDScript 应当调用的 API 面——方法名、参数类型、返回值——作为给下游 Agent 的接口契约。这一 Case 验证的是 Agent 的守界能力面对域外请求正确做法不是勉强作答而是显式声明归属并重定向。这与规范中 godot-gdscript-specialist 的 Case 2把 Shader 请求重定向给godot-shader-specialist形成镜像说明整个 Agent 家族共享同一套重定向协议宁可交接不可越界。交接时描述 API 面但不写实现的细节值得注意——它保证了信息在 Agent 之间无损传递同时又不破坏各自领域的排他性。这种模式对工程实践同样有启发模块间通过明确的接口契约协作而非互相侵入实现。四、Case 3ABI 兼容风险 — 小版本升级的警戒线测试输入Were upgrading from Godot 4.5 to 4.6. Will our existing GDExtension still work?这是规范中标注的关键升级路径critical escalation path。预期行为分四步标记 ABI 兼容性风险GDExtension 二进制在跨小版本minor version升级时可能不具备 ABI 兼容性——这是规范反复强调、绝不默认成立的前提指向迁移指南要求查阅 4.5→4.6 的迁移指南中关于 GDExtension API 变更的部分。仓库中的 VERSION.md 正是此类验证的权威来源——它明确记录了 LLM 知识截止2025 年 5 月约 Godot 4.3之后的版本时间线4.4风险 MEDIUM、4.5风险 HIGH、4.6风险 HIGH2026 年 1 月发布建议重新编译推荐针对 4.6 的 godot-cpp 头文件重新编译扩展而非假设二进制兼容——这是应对 ABI 漂移的常规且安全的做法检查清单字段.gdextension清单中的compatibility_minimum版本可能也需要相应更新并提供重新编译检查清单。仓库佐证4.5 → 4.6 的破坏性变更breaking-changes.md 记录了 4.5→4.62026 年 1 月POST-CUTOFF、HIGH RISK的完整变更表其中与 GDExtension 侧渲染/物理代码最相关的条目包括子系统变更细节物理Jolt 成为默认 3D 物理引擎新项目自动使用 Jolt旧项目保留原设置部分 HingeJoint3D 属性如damp仅 GodotPhysics 生效渲染Glow 在 tonemapping 之前处理原本在之后带 glow 的场景观感会变化需在 WorldEnvironment 调整强度/混合渲染Windows 上 D3D12 成为默认后端原为 Vulkan为更好的驱动兼容性核心Quaternion 初始化为单位四元数原为零值多数代码不受影响但技术上属破坏性变更UI双焦点系统鼠标/触摸焦点与键盘/手柄焦点分离对于 GDExtension 中编写渲染相关代码的开发者D3D12 默认化是直接影响项——不同渲染后端的资源创建、管线状态语义存在差异跨后端代码需要格外验证。这也正是 Case 3 中检查清单存在的意义。协议合规红线规范明确写道——the agent must not approve shipping an unverified extension binary不得批准发布未经验证的扩展二进制。ABI 风险是升级过程中的高优先级升级路径Agent 可以给出重新编译 验证的建议但绝不能凭 LLM 训练记忆断言兼容性。其底层逻辑与 VERSION.md 的Knowledge Gap Warning完全一致模型训练数据只覆盖到约 4.34.4/4.5/4.6 引入了模型不知道的重大变更在建议任何 Godot API 调用前都必须交叉核对版本参考目录。五、Case 4内存管理 — Godot 专属的 RAII 生命周期模式测试输入How should we manage the lifecycle of Godot objects created inside C GDExtension code?预期行为要求产出基于 RAII 的 Godot 对象生命周期管理模式核心规则有三条RefT用于引用计数对象当RefT离开作用域时自动释放引用计数。适用于Resource及其子类等引用计数管理的对象memnew()/memdelete()用于非引用计数对象例如Node类型对象必须用 Godot 的自定义分配器创建与销毁警告对 Godot 对象使用裸 Cnew/delete是未定义行为undefined behavior——Godot 对象必须经由 Godot 的内存分配器memnew/memdelete管理。同时 Agent 还需说明对象所有权规则例如一个被添加到场景树的节点其所有权归场景树释放责任由场景树接管C 侧不应重复释放。规范还要求提供具体示例在 C 中创建并管理一个CollisionShape3D的完整代码模式。为什么不能用裸 new/delete从实现原理看Godot 对象的内存分配走的是引擎自带的分配器对应Memory基础设施。若在 C 侧用标准new分配 Godot 对象而引擎侧用memdelete释放反之亦然二者使用的分配/释放路径不一致会造成内存管理错乱——这正是规范强调Godot-specific memory management, not generic C RAIIProtocol Compliance 条目的原因。RefT的自动释放与memnew/memdelete的显式配对共同构成了 GDExtension 编码中不可省略的约定。六、Case 5上下文传递 — Godot 4.6 的 API 变更核查测试输入引擎版本上下文为 Godot 4.6自 4.5 升级请求Check if any GDExtension APIs changed from 4.5 to 4.6.预期行为引用 VERSION.md 已验证来源列表中的 4.5→4.6 迁移指南报告 4.6 中已文档化的 GDExtension API 变更若 4.6 未文档化 GDExtension 的破坏性变更则须显式声明未发现破坏性变更并附上仍需对照官方变更日志核实的 caveat——即不因没查到就下绝对兼容的结论将D3D12 默认化Windows标记为可能与 GDExtension 渲染代码相关的 4.6 变更提供升级后需要验证的检查清单。这一 Case 验证的是 Agent 的版本敏感度面对 4.6 这样的截止后版本Agent 必须把仓库版本参考当作权威源覆盖模型训练数据的盲区并以显式声明 保留核实的方式处理信息缺口而不是自信地基于旧知识作答。对照 godot-specialist 的 Case 5Jolt 默认物理与 godot-shader-specialist 的 Case 5glow 重做可以确认这是整个 Godot Agent 家族共享的行为准则版本参考权威于训练数据未验证即标注未验证。七、协议合规Protocol Compliance汇总规范末尾以 7 项合规清单收束整个 Agent 的行为契约保持在声明域内GDExtension、godot-cpp、godot-rust、native bindings将 GDScript 编写重定向给godot-gdscript-specialist将 Shader 编写重定向给godot-shader-specialist返回结构化输出绑定模式、RAII 示例、ABI 检查清单在小版本升级时标记 ABI 兼容风险——绝不默认二进制兼容使用 Godot 专属内存管理memnew/memdelete、RefT而非裸 C new/delete在确认兼容性之前先核对引擎版本参考中的 GDExtension API 变更。这 7 项把前文的五个 Case 抽象为可复用的行为准则无论输入如何变化Agent 都应稳定地表现出守界、结构化、版本敏感、Godot 原生的行为特征。八、如何执行这套测试规范本规范是 CCGS Skill Testing Framework 的一部分——该框架负责测试 Agent 和 Skill 本身而非用它们开发的游戏且整个目录自包含、可选安装。测试由框架内置的/skill-test技能驱动/skill-test static [agent-name]检查结构合规对应本文静态断言一节/skill-test spec godot-gdextension-specialist按本规范逐 Case 评估 Agent 行为/skill-test audit查看所有 Agent/Skill 的 has-spec、last tested、result 全貌。测试结果会回写 catalog.yaml 中的last_spec/last_spec_result等字段。若要为其他引擎专家编写类似规范可基于 templates/agent-test-spec.md 模板复制到对应 agents 目录 → 按模板填写 Summary、Static Assertions、Test Cases、Protocol Compliance、Coverage Notes → 在 catalog.yaml 登记 spec 路径 → 用/skill-test spec [name]验证。编写此类测试规范的方法论从本规范与模板的对照可以看出一个高质量的 Agent 测试规范应具备四个特征输入-预期行为成对出现每个 Case 给出明确的触发输入与可检查的期望行为列表让验证有据可依域内 / 域外成对设计既测试该做的做对Case 1、4也测试不该做的不做、并正确交接Case 2版本风险单独成 Case把知识截止后版本的 API 变更Case 3、5作为一等公民测试防止 Agent 用旧知识误导工程决策错误模式显式禁止如裸new/delete属未定义行为、未经验证不得批准发布扩展二进制——把红线写进规范而不是指望 Agent 自行领悟。九、总结从规范到可验证的工程行为本规范将 GDExtension 专家的职责浓缩为可机械验证的行为契约域内产出完整且正确的 godot-cpp 绑定模式GDCLASS _bind_methods gdextension_init .gdextension 清单域外显式重定向升级时绝不默认 ABI 兼容并给出重新编译清单内存管理一律走 Godot 专属 RAII 约定Ref / memnew / memdelete涉及 4.4 之后的 API 一律以仓库版本参考为准。对于在 Claude Code Game Studios 框架内构建 Godot 项目的团队这套规范直接回答了三个工程问题谁负责什么职责边界、什么能直接做域内模式、什么必须谨慎ABI 与内存。而对 AI Agent 工程实践而言它示范了一种把专家经验固化为测试用例的做法——不依赖模型临场发挥而是用结构化的输入-预期行为对把每一个关键技术决策变成可重复、可追踪的验证点。进一步阅读规范原文agents/engine/godot/godot-gdextension-specialist.md版本参考权威 API 源docs/engine-reference/godot/VERSION.md破坏性变更表docs/engine-reference/godot/breaking-changes.md当前最佳实践docs/engine-reference/godot/current-best-practices.md职责相邻的 GDScript 专家agents/engine/godot/godot-gdscript-specialist.md测试规范模板templates/agent-test-spec.mdAgent 登记与测试追踪catalog.yaml【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Claude Code Game Studios 中的 Godot GDExtension 专家 Agent：绑定模式、ABI 与内存管理的可验证行为规范
Claude Code Game Studios 中的 Godot GDExtension 专家 Agent绑定模式、ABI 与内存管理的可验证行为规范【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios本篇技术指南基于仓库中的 Agent 测试规范 godot-gdextension-specialist.md 展开。它定义了 CCGSClaude Code Game Studios框架中专职负责 Godot 原生扩展GDExtension的 AI 专家 Agent 的职责边界、五大行为测试用例与协议合规要求。读完本文你将理解如何用结构化的测试规范约束一个 AI Agent 正确产出 godot-cpp 绑定代码、规避跨小版本升级的 ABI 风险、遵循 Godot 专属的 RAII 内存管理约定并通过/skill-test体系对其行为做可重复的质量验证。一、背景GDExtension 专家在 CCGS Agent 体系中的定位Claude Code Game Studios 将完整的游戏开发工作室层级映射为 49 个 AI Agent 与 72 个工作流技能。其中引擎层按技术栈拆分为 godot、unity、unreal 三个家族每个家族内又细分为多个专职 Agent。以 agents/engine/godot 目录为例Godot 家族包含godot-specialist负责 Godot 架构决策、节点/场景模式、信号与语言选型GDScript vs C# vs GDExtensiongodot-gdscript-specialist负责 GDScript 静态类型、信号架构、协程与性能godot-csharp-specialist负责 C# 侧实现godot-shader-specialist负责着色语言、材质与后处理godot-gdextension-specialist即本文主角负责 GDExtension API、godot-cpp C 绑定、godot-rust 绑定、原生库集成与原生性能优化。这些 Agent 在 catalog.yaml约第 967-968 行中登记spec字段指向各自的测试规范文件用于测试覆盖率追踪。职责边界声明来自规范开头的 Agent SummaryDomain负责GDExtension API、godot-cpp C 绑定、godot-rust 绑定、native library integration原生库集成、native performance optimization原生性能优化Does NOT own不负责GDScript 代码归godot-gdscript-specialist、Shader 代码归godot-shader-specialistModel tierSonnet专家 Agent 的默认层级Gate IDs无该 Agent 不触发任何阶段门。清晰的双向边界是这套体系能并行工作的前提GDExtension 专家只管把 C 的能力暴露给引擎至于 GDScript 侧如何调用、Shader 如何编写分别由专职 Agent 负责。这也与 godot-specialist 中语言专属实现委托给子专家的分工设计保持一致。静态断言Static Assertions规范在结构层面对 Agent 定义文件提出了 4 项硬性检查description:字段存在且为领域专属必须提到 GDExtension / godot-cpp / native bindingsallowed-tools:列表包含 Read、Write、Edit、Bash、Glob、Grep模型层级为 Sonnet专家默认Agent 定义不得宣称对 GDScript 或 Shader 编写拥有权限。这些断言保证了 Agent 定义文件的身份一致性——一个描述含糊、工具缺失或越权宣称的 Agent 定义会在结构检查阶段直接被拦截。二、Case 1域内请求 — godot-cpp 绑定模式的正确产出测试输入Expose a C rigid-body physics simulation library to GDScript via GDExtension.预期行为要求 Agent 产出完整的 GDExtension 绑定模式包含四个组成部分继承基类类继承自godot::Object或合适的 Godot 基类如godot::Node、godot::PhysicsBody3D等视被封装对象类型而定GDCLASS宏注册GDCLASS(MyPhysicsLib, godot::Object)将 C 类注册到 Godot 的类系统使其可被引擎识别与实例化_bind_methods()实现在静态成员函数_bind_methods()中通过ClassDB::bind_method()将物理 API 暴露给 GDScript这是 GDScript 能调用 C 方法的桥梁gdextension_init入口extern C GDExtensionBool gdextension_init(...)作为扩展的初始化入口在内部完成类注册。此外Agent 必须指出.gdextension清单文件格式是必需的——Godot 编辑器/运行时通过该清单定位动态库.so/.dll/.dylib及其入口符号清单中通常包含entry_symbol、libraries按平台列出二进制路径以及compatibility_minimum字段。关键约束规范明确要求 Agent不得顺带产出 GDScript 调用代码——那属于godot-gdscript-specialist的领域。这正是职责边界在具体输出层面的落点Agent 交付API 面方法名、参数类型、返回值而 GDScript 消费方代码由另一个专家接手。Coverage Notes 补充该 Case 的产出应配套一个smoke test验证扩展能够成功加载、且暴露的方法可从 GDScript 侧实际调用。这意味着测试不仅要检查绑定代码是否写对了还要检查绑定是否跑得通——加载失败或符号找不到都属于本 Case 的失败表现。三、Case 2域外重定向 — 跨 Agent 协作协议测试输入Write the GDScript that calls the physics simulation from Case 1.预期行为不得产出任何 GDScript 代码明确声明 GDScript 编写属于godot-gdscript-specialist将请求重定向给godot-gdscript-specialist允许且鼓励以handoff spec交接规格的形式描述 GDScript 应当调用的 API 面——方法名、参数类型、返回值——作为给下游 Agent 的接口契约。这一 Case 验证的是 Agent 的守界能力面对域外请求正确做法不是勉强作答而是显式声明归属并重定向。这与规范中 godot-gdscript-specialist 的 Case 2把 Shader 请求重定向给godot-shader-specialist形成镜像说明整个 Agent 家族共享同一套重定向协议宁可交接不可越界。交接时描述 API 面但不写实现的细节值得注意——它保证了信息在 Agent 之间无损传递同时又不破坏各自领域的排他性。这种模式对工程实践同样有启发模块间通过明确的接口契约协作而非互相侵入实现。四、Case 3ABI 兼容风险 — 小版本升级的警戒线测试输入Were upgrading from Godot 4.5 to 4.6. Will our existing GDExtension still work?这是规范中标注的关键升级路径critical escalation path。预期行为分四步标记 ABI 兼容性风险GDExtension 二进制在跨小版本minor version升级时可能不具备 ABI 兼容性——这是规范反复强调、绝不默认成立的前提指向迁移指南要求查阅 4.5→4.6 的迁移指南中关于 GDExtension API 变更的部分。仓库中的 VERSION.md 正是此类验证的权威来源——它明确记录了 LLM 知识截止2025 年 5 月约 Godot 4.3之后的版本时间线4.4风险 MEDIUM、4.5风险 HIGH、4.6风险 HIGH2026 年 1 月发布建议重新编译推荐针对 4.6 的 godot-cpp 头文件重新编译扩展而非假设二进制兼容——这是应对 ABI 漂移的常规且安全的做法检查清单字段.gdextension清单中的compatibility_minimum版本可能也需要相应更新并提供重新编译检查清单。仓库佐证4.5 → 4.6 的破坏性变更breaking-changes.md 记录了 4.5→4.62026 年 1 月POST-CUTOFF、HIGH RISK的完整变更表其中与 GDExtension 侧渲染/物理代码最相关的条目包括子系统变更细节物理Jolt 成为默认 3D 物理引擎新项目自动使用 Jolt旧项目保留原设置部分 HingeJoint3D 属性如damp仅 GodotPhysics 生效渲染Glow 在 tonemapping 之前处理原本在之后带 glow 的场景观感会变化需在 WorldEnvironment 调整强度/混合渲染Windows 上 D3D12 成为默认后端原为 Vulkan为更好的驱动兼容性核心Quaternion 初始化为单位四元数原为零值多数代码不受影响但技术上属破坏性变更UI双焦点系统鼠标/触摸焦点与键盘/手柄焦点分离对于 GDExtension 中编写渲染相关代码的开发者D3D12 默认化是直接影响项——不同渲染后端的资源创建、管线状态语义存在差异跨后端代码需要格外验证。这也正是 Case 3 中检查清单存在的意义。协议合规红线规范明确写道——the agent must not approve shipping an unverified extension binary不得批准发布未经验证的扩展二进制。ABI 风险是升级过程中的高优先级升级路径Agent 可以给出重新编译 验证的建议但绝不能凭 LLM 训练记忆断言兼容性。其底层逻辑与 VERSION.md 的Knowledge Gap Warning完全一致模型训练数据只覆盖到约 4.34.4/4.5/4.6 引入了模型不知道的重大变更在建议任何 Godot API 调用前都必须交叉核对版本参考目录。五、Case 4内存管理 — Godot 专属的 RAII 生命周期模式测试输入How should we manage the lifecycle of Godot objects created inside C GDExtension code?预期行为要求产出基于 RAII 的 Godot 对象生命周期管理模式核心规则有三条RefT用于引用计数对象当RefT离开作用域时自动释放引用计数。适用于Resource及其子类等引用计数管理的对象memnew()/memdelete()用于非引用计数对象例如Node类型对象必须用 Godot 的自定义分配器创建与销毁警告对 Godot 对象使用裸 Cnew/delete是未定义行为undefined behavior——Godot 对象必须经由 Godot 的内存分配器memnew/memdelete管理。同时 Agent 还需说明对象所有权规则例如一个被添加到场景树的节点其所有权归场景树释放责任由场景树接管C 侧不应重复释放。规范还要求提供具体示例在 C 中创建并管理一个CollisionShape3D的完整代码模式。为什么不能用裸 new/delete从实现原理看Godot 对象的内存分配走的是引擎自带的分配器对应Memory基础设施。若在 C 侧用标准new分配 Godot 对象而引擎侧用memdelete释放反之亦然二者使用的分配/释放路径不一致会造成内存管理错乱——这正是规范强调Godot-specific memory management, not generic C RAIIProtocol Compliance 条目的原因。RefT的自动释放与memnew/memdelete的显式配对共同构成了 GDExtension 编码中不可省略的约定。六、Case 5上下文传递 — Godot 4.6 的 API 变更核查测试输入引擎版本上下文为 Godot 4.6自 4.5 升级请求Check if any GDExtension APIs changed from 4.5 to 4.6.预期行为引用 VERSION.md 已验证来源列表中的 4.5→4.6 迁移指南报告 4.6 中已文档化的 GDExtension API 变更若 4.6 未文档化 GDExtension 的破坏性变更则须显式声明未发现破坏性变更并附上仍需对照官方变更日志核实的 caveat——即不因没查到就下绝对兼容的结论将D3D12 默认化Windows标记为可能与 GDExtension 渲染代码相关的 4.6 变更提供升级后需要验证的检查清单。这一 Case 验证的是 Agent 的版本敏感度面对 4.6 这样的截止后版本Agent 必须把仓库版本参考当作权威源覆盖模型训练数据的盲区并以显式声明 保留核实的方式处理信息缺口而不是自信地基于旧知识作答。对照 godot-specialist 的 Case 5Jolt 默认物理与 godot-shader-specialist 的 Case 5glow 重做可以确认这是整个 Godot Agent 家族共享的行为准则版本参考权威于训练数据未验证即标注未验证。七、协议合规Protocol Compliance汇总规范末尾以 7 项合规清单收束整个 Agent 的行为契约保持在声明域内GDExtension、godot-cpp、godot-rust、native bindings将 GDScript 编写重定向给godot-gdscript-specialist将 Shader 编写重定向给godot-shader-specialist返回结构化输出绑定模式、RAII 示例、ABI 检查清单在小版本升级时标记 ABI 兼容风险——绝不默认二进制兼容使用 Godot 专属内存管理memnew/memdelete、RefT而非裸 C new/delete在确认兼容性之前先核对引擎版本参考中的 GDExtension API 变更。这 7 项把前文的五个 Case 抽象为可复用的行为准则无论输入如何变化Agent 都应稳定地表现出守界、结构化、版本敏感、Godot 原生的行为特征。八、如何执行这套测试规范本规范是 CCGS Skill Testing Framework 的一部分——该框架负责测试 Agent 和 Skill 本身而非用它们开发的游戏且整个目录自包含、可选安装。测试由框架内置的/skill-test技能驱动/skill-test static [agent-name]检查结构合规对应本文静态断言一节/skill-test spec godot-gdextension-specialist按本规范逐 Case 评估 Agent 行为/skill-test audit查看所有 Agent/Skill 的 has-spec、last tested、result 全貌。测试结果会回写 catalog.yaml 中的last_spec/last_spec_result等字段。若要为其他引擎专家编写类似规范可基于 templates/agent-test-spec.md 模板复制到对应 agents 目录 → 按模板填写 Summary、Static Assertions、Test Cases、Protocol Compliance、Coverage Notes → 在 catalog.yaml 登记 spec 路径 → 用/skill-test spec [name]验证。编写此类测试规范的方法论从本规范与模板的对照可以看出一个高质量的 Agent 测试规范应具备四个特征输入-预期行为成对出现每个 Case 给出明确的触发输入与可检查的期望行为列表让验证有据可依域内 / 域外成对设计既测试该做的做对Case 1、4也测试不该做的不做、并正确交接Case 2版本风险单独成 Case把知识截止后版本的 API 变更Case 3、5作为一等公民测试防止 Agent 用旧知识误导工程决策错误模式显式禁止如裸new/delete属未定义行为、未经验证不得批准发布扩展二进制——把红线写进规范而不是指望 Agent 自行领悟。九、总结从规范到可验证的工程行为本规范将 GDExtension 专家的职责浓缩为可机械验证的行为契约域内产出完整且正确的 godot-cpp 绑定模式GDCLASS _bind_methods gdextension_init .gdextension 清单域外显式重定向升级时绝不默认 ABI 兼容并给出重新编译清单内存管理一律走 Godot 专属 RAII 约定Ref / memnew / memdelete涉及 4.4 之后的 API 一律以仓库版本参考为准。对于在 Claude Code Game Studios 框架内构建 Godot 项目的团队这套规范直接回答了三个工程问题谁负责什么职责边界、什么能直接做域内模式、什么必须谨慎ABI 与内存。而对 AI Agent 工程实践而言它示范了一种把专家经验固化为测试用例的做法——不依赖模型临场发挥而是用结构化的输入-预期行为对把每一个关键技术决策变成可重复、可追踪的验证点。进一步阅读规范原文agents/engine/godot/godot-gdextension-specialist.md版本参考权威 API 源docs/engine-reference/godot/VERSION.md破坏性变更表docs/engine-reference/godot/breaking-changes.md当前最佳实践docs/engine-reference/godot/current-best-practices.md职责相邻的 GDScript 专家agents/engine/godot/godot-gdscript-specialist.md测试规范模板templates/agent-test-spec.mdAgent 登记与测试追踪catalog.yaml【免费下载链接】Claude-Code-Game-StudiosTurn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy.项目地址: https://gitcode.com/GitHub_Trending/cl/Claude-Code-Game-Studios创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考