让 AI 自动配置 Unity 特效资产：基于 HTTP API 与 Skill 的一次实践
让 AI 自动配置 Unity 特效资产：基于 HTTP API 与 Skill 的一次实践
一、背景与目的
这两年，AI 工具变得越来越聪明。最直观的变化是，它已经不只是回答问题，而是可以直接参与生产：写代码、改代码、生成图片，甚至根据一个比较完整的目标，自行拆解步骤并调用工具完成任务。
我平时负责维护项目里的特效框架。工作中经常能看到美术同学重复处理大量资产配置，例如创建节点、绑定组件、填写参数，以及一段一段地调整动画曲线。这些工作当然需要经验，但其中也有不少步骤规则明确、重复度高。看得多了，我就产生了一个想法：既然 AI 已经能自动写代码和生成图片，能不能也让它直接管理 Unity 中的特效资产，替我们完成这些配置工作？
我想做的并不是让 AI 凭空生成一个不可控的结果，而是把现有的生产能力整理成一组明确的工具，再交给 AI 使用。人只需要描述目标，AI 负责理解需求、规划步骤、调用工具并检查结果。这样既能减少机械操作，也能让已有的特效框架继续作为最终的规则执行者。
二、建立大模型与 Unity 对象之间的桥梁
大模型可以理解“创建一个沿莫比乌斯环运动的特效”这句话，但它默认并不知道当前打开了哪个 Unity 工程、场景里有哪些对象，也不知道某个特效组件有哪些可编辑参数。换句话说，模型有理解和规划能力，却没有观察 Unity、操作 Unity 的手脚。
因此，第一步不是继续优化提示词，而是给模型提供一座桥梁。这座桥梁至少要解决两件事：
- 让模型能够读取生产环境中的信息，例如当前场景层级、对象路径、组件类型和现有参数。
- 让模型能够调用受控的生产接口，例如创建特效节点、添加表现层、设置网格、修改生命周期、写入动画曲线和颜色渐变。
Unity 提供了丰富的 C# 编辑器 API，但没有直接提供一套可供外部 AI-Agent 调用的通用操作接口，所以还需要我们在项目里做一层封装。目前比较常见的接入方式是 MCP 工具或 Skill。MCP 的标准化程度更高，不过实际接入时还要处理客户端与服务端的连接、进程和会话生命周期。对于我这个只在本机 Unity 编辑器内使用的场景，我更倾向于简单的无状态方案：
在 Unity 内启动一个只监听本机的 HTTP API 服务，把生产能力封装为 JSON 接口；再导出一份
SKILL.md，向 AI-Agent 说明每个接口的用途、参数和返回值。
这样，AI-Agent 读取 Skill 后，就知道自己有哪些工具可用。收到需求时，它可以先查询场景信息，再根据目标规划调用顺序，最后通过 HTTP 请求逐步完成编辑。每次请求都是独立的，不需要维持一条长连接，也便于直接查看请求参数和返回结果。
整个过程可以简单理解为：
自然语言需求 -> AI-Agent 读取 Skill -> 规划操作步骤 -> 调用 Unity HTTP API -> 修改并返回资产状态
这里需要强调一点：AI 负责理解需求和组织步骤，真正修改资产的仍然是我们提供的工具函数。工具边界越清楚，参数校验越完整，AI 的执行结果就越稳定。
三、现有工具：Aether
这个方案不必从 HTTP 监听、参数解析和工具描述生成开始全部重写。Unity Asset Store 中已经有一套可以直接利用的工具：Aether - AI-Skill-Tools For Unity。
Aether 是一个运行在 Unity 中的无状态 HTTP API 框架。它可以扫描注册的工具方法，生成对应的路由和 JSON Schema，并把全部工具导出成 AI-Agent 能够阅读的 SKILL.md。它还支持常见的 Unity 数据类型和自定义参数类型，省去了不少协议层的工作。
最简单的编辑器扩展方式，是继承 AIHttpServerEditorWindow，然后通过 ToolClassType 指定自己的工具类：
using System;
using Aether.Editor;
public sealed class MyAIToolWindow : AIHttpServerEditorWindow
{
protected override Type ToolClassType => typeof(MyAITools);
}
工具函数本身不需要继承额外的基类。把工具放进静态类，使用 [HttpServe] 标记方法，再使用 [ApiArgument] 描述参数即可：
using System.Collections.Generic;
using Aether.HttpApi;
using Aether.Protocol;
public static class MyAITools
{
[HttpServe(
"set_effect_lifetime",
Description = "设置指定特效的生命周期",
Route = "/effect/set-lifetime",
Method = HttpMethod.POST)]
public static CallToolResult SetEffectLifetime(
[ApiArgument(Description = "场景对象路径", Required = true)] string path,
[ApiArgument(Description = "生命周期，单位为秒", Required = true)] float duration)
{
// 在这里调用项目原有的特效框架接口。
return new CallToolResult
{
Content = new List<ContentBlock>
{
new TextContentBlock { Text = $"已将 {path} 的生命周期设置为 {duration} 秒" }
}
};
}
}
服务启动后，Aether 会把这些标记过的方法注册为 HTTP 工具。点击导出按钮，就能得到包含工具名称、接口地址、参数结构和调用示例的 SKILL.md。把这个 Skill 提供给支持工具调用的 AI-Agent，它就可以按照文档自行选择并组合接口。
实际项目中，我没有只使用通用的 Unity 操作，而是围绕自己的 Omnipresent 特效框架补充了更贴近业务的工具，例如场景层级查询、特效根节点创建、Particle/Renderer/Light Presentor 配置、路径曲线设置和材质颜色渐变等。这样 AI 操作的是“特效生命周期”“循环路径”“颜色渐变”这些业务概念，而不必猜测底层序列化字段。
图 1 是我基于这套工具扩展的窗口。左侧列出了已经注册的接口，右侧可以查看选中工具的说明、请求地址和输入 JSON Schema；上方还能查看当前场景层级、启动或停止服务，以及导出 AI Skill。这样既方便 AI 调用，也方便开发者检查工具是否注册正确。
四、实际使用案例
完成工具封装后，我先做了一个路径动画测试。给 AI-Agent 的任务大意是：场景中的 EffectRing 是一个 Omnipresent 对象，请为它添加一个 RendererPresentor，把网格设置为 Sphere，生命周期设置为 5 秒，再生成一条循环的莫比乌斯环路径，同时把 EffectRing 和 Sphere 都设置为循环播放。
这段需求包含了多个连续步骤。AI 需要先找到目标对象，再创建对应的表现组件，设置网格和生命周期，计算莫比乌斯环上的采样点，最后把路径与循环参数写入特效资产。因为 Skill 中已经说明了每个接口的能力和参数，AI 可以自行安排这些调用，而不需要我逐条告诉它该点哪个按钮。
图 3 是执行后的路径结果。可以看到，AI 已经写入了一组闭合的三维路径控制点，整体形成了预期的莫比乌斯环形状。第一次尝试的结果谈不上已经达到最终美术品质，但作为自动配置的验证，看起来还不错，也说明这条工作流确实能够跑通。
接着，我又追加了一段更接近美术配置的要求：在 5 秒周期内制作颜色渐变，让颜色从暖色调开始，中间过渡到冷色调，最后再回到原来的暖色调。
从图 5 可以看到，AI 创建了对应的颜色动画层，开启了循环，并配置出“暖色—冷色—暖色”的渐变。这个案例看起来很简单，但它验证了一个重要点：只要接口能够准确描述项目里的资产结构，AI 不仅可以创建对象，也可以处理曲线、渐变和循环模式这类较细的编辑工作。
五、总结
这次尝试让我比较确定，AI 自动生产和配置资产是可行的。关键并不是让模型直接理解 Unity 内部所有细节，而是把现有生产流程拆成稳定、可验证的工具，并为这些工具提供清楚的说明。模型负责理解目标和组合步骤，项目代码负责执行规则，两者各做自己擅长的部分。
后续如果要把这套方式真正用于日常生产，还需要继续补充工具的参数校验、错误返回、操作日志、结果检查和批量处理能力。对于会修改场景和 Prefab 的接口，也应该只监听本机地址，配合版本控制和 Unity Undo 使用，避免错误调用造成难以恢复的修改。
从手动配置一个参数，到让 AI 完成一串资产操作，中间缺少的并不是更长的提示词，而是一套可靠的生产工具。当这座桥搭好之后，AI-Agent 才真正有机会进入 Unity 的资产生产流程。