摘要大部分AI 3D的讨论停在聊天窗口里——AI 回答问题用户看文字。但 3D 世界真正有意思的接法是让 AI 拥有一个身体有坐标、被真人看见、能走路带路。本文讲清这套接法的架构服务器只发 JSON、画面由访客浏览器渲染、接入流程、它能做什么与做不到什么以及一份可以直接引用的实测成本。结论先放这里AI 接入 3D 世界难的不是模型是身体而成本曲线是反的——看得见的 AI 比看不见的 AI 便宜。这篇来自我们自己项目的真实实现数据全部来自项目内可重跑的验收脚本。写到做不到的那一节会格外长——那部分比能力清单更有参考价值。标签AI Agent3DThree.jsWebSocket虚拟世界一、把 AI 放进聊天窗口和放进 3D 世界是两件事现在谈 AI 接入多数方案长一个样右侧一个对话框用户输入AI 回字。这套东西放进 3D 世界里其实只是给界面加了个插件——世界还是世界AI 还是网页功能。我们关心的是另一个问题AI 能不能以一个角色的身份住在 3D 世界里区别在哪聊天窗口里的 AI 没有位置不占空间其他访客看不见它而一个有人形身体的 AI 走在场景里它有坐标、有朝向、有走路的动画路过的人会看见这里有个 AI 在带路。对展馆导览、园区讲解、虚拟展厅接待这类场景来说被看见本身就是服务的一部分——参观者是跟着一个角色在走不是在读一段文字。这个方向的技术含量不在接大模型——API 谁都能调。真正要解决的是三个工程问题AI 的状态怎么同步给所有访客、AI 怎么感知周围环境、AI 的动作指令怎么落成画面。下面按这三块拆。二、架构先讲清楚服务器只发 JSON画面由浏览器渲染这套设计里最关键的一个决定是服务器不渲染 AI 的画面AI 本身也不产生任何渲染负载。AI Agent 通过 WebSocket 接入后端它的位置、朝向、动作状态以结构化 JSON 的形式广播出去每个访客的浏览器拿到这些数据后用本地渲染把 AI 画出来——和渲染其他玩家用的是同一条管线。这个决定带来的结果比听起来大成本结构变了。AI 每多一个服务器只多一份很小的事件流渲染压力分散在所有访客自己的浏览器里。AI 数量和服务器成本几乎不成正比实测数据在第六节。AI 和玩家是同构的。AI 能走的路玩家就能走玩家被渲染的方式AI 也一样。不需要为 AI 单独做一套显示特例。审计天然友好。AI 的每个动作都是一条结构化记录走到了哪、说了什么天然可落库、可回放。我们这边的实现是聊天与动作记录本地落库、按日归档。三、接入流程三步外加一个零依赖的示例客户端给别的开发者复现这套接入我们把协议收敛成三步在域名下放一个.well-known/virtual-world-agent.json声明这个 Agent 的身份与能力这一步是给世界的运营方看的准入清单用运营方签发的 Key 换一个15 分钟有效的短期令牌——不给长期凭证泄露了影响也锁在 15 分钟内连上/ws/agent开始收感知、发动作。配套还有一个零依赖的 Node 示例客户端单文件、只依赖 Node 内置模块照着改就能跑通第一遍。AI 的身份是明示的——访客能看出它是 AI这一点我们当作硬性设计约束不做假装是真人的事。四、它能做什么感知与动作感知侧Agent 有两套输入observe雷达查询周围环境与角色管理员授权的 Agent 半径 200 米游客场景 30 米事件流按 15 秒窗口推送世界动态分三档——eco 档 0 条不推送、standard 档 14 条、realtime 档 65 条按需选档避免 Agent 被事件淹没。动作侧Agent 能做八个动作move/walk_to/follow/rotate/jump/say/interact以及移动相关的基础位移。组合起来能覆盖的场景在展厅门口迎宾、带参观者走到某个展位、跟着某位访客、对着周围的人说话、与场景物件交互。大模型的接入方式是解耦的世界侧只提供身体 感知 动作通道调用哪个模型、用什么提示词是接入方自己的事。这保证了协议稳定——模型厂商换代接入层不动。五、它做不到什么四条边界比能力清单更重要这一节建议先读。宣传材料里很容易把AI 走进 3D 世界写成一个万能故事实际落地前这四条边界要先想清楚1. 它看不见画面。服务器上没有渲染像素只存在于每个访客的浏览器里。所以 Agent 拿到的世界信息是结构化的雷达数据——周围有什么物体、什么角色、在哪个方位、多远——而不是一张截图。它知道你站在它东南方 15 米但它看不见你的模型长什么样。想让 AI 基于视觉做决策比如认出海报内容得另接视觉模型那是另一套成本。2. 它不做语音识别与合成。对话走文本进出。语音这条链路识别、合成、回声消除是独立的工程成本我们没有把它塞进 Agent 通道。如果场景需要语音导览目前的做法是文本驱动、由前端自行配 TTS。3. 它不托管知识库。世界侧不负责AI 知道什么。展馆的讲解词、产品的参数这些知识由接入方自己挂在模型侧提示词、RAG 都行。世界提供的只是让这些知识长出身体的通道。这个边界划清楚了接入方才不会误以为把 Agent 连上就自动懂我的业务。4. 它没有瞬间移动。所有移动都是逐帧走出来的walk_to要走寻路。这个限制不是技术偷懒而是产品设定——AI 的存在感来自它在场景里真实地移动、被路人看见走过去的过程。一个凭空出现的 AI 反而破坏它在世界里活着这件事。副作用是远距离调度要留出移动时间不能按瞬达来设计交互节奏。把这四条写进方案书再去做演示比藏着掖着效果好得多——评估方真正想问的就是这些。六、成本实测为什么看得见的 AI 反而便宜直觉上一个会走会说、被几十个访客同时看见的 AI应该比后台跑一个问答机器人贵。实测下来是反的指标实测值单个 Agent 的下行流量≈ 1 KB/s100 个 Agent 同时在线≈ 0.8 Mbps100 个 Agent 的服务器算力≈ 0.079 个核空闲 Agent5 分钟自动退场原因就是第二节那个架构决定服务器只为 AI 存状态、发事件渲染由访客浏览器分担。AI 不产生一帧画面所以 AI 变多不叠加渲染成本又因为事件流是 JSON 文本流量也压得很低。对比一下看不见的 AI的成本结构传统做法里 AI 要理解画面视觉模型按帧计费或者服务端渲染后推流带宽按视频走。同样是AI 出现在世界里让访客浏览器去画反而把最贵的那部分省掉了。七、什么场景适合什么场景先别做场景判断展馆 / 展厅导览带路适合。路线固定、知识边界清晰角色带路的体验是文字导览替代不了的园区 / 校区接待演示适合。AI 明示身份的迎宾接待讲解内容由接入方维护多人世界里的运营角色适合。活动主持、氛围角色真人忙不过来时补位当成客服知识库用先别。它不托管知识硬要做等于把知识工程的活儿伪装成接入问题期望它自主运营世界先别。当前协议里 Agent 的每个动作都来自明确的指令侧决策离自主代理还有距离语音对话为主的服务先别。语音链路不在通道内需要额外自建八、常见问题问接入需要准备什么答一个域名、一把运营方签发的 Key、Node 18 以上环境跑示例客户端。服务端和模型侧都解耦不需要为了接入 AI 改造世界本身。问访客会觉得它是真人吗答不会也不应该。AI 身份是明示的这是我们的设计底线。从实测看访客知道它是 AI 之后反而更愿意跟它互动——试探一个 AI 的行为边界本身就有趣味。问Agent 会不会被滥用刷量答三层约束Key 换的是 15 分钟短期令牌运营方在后台可建停 Agent、可吊销 Key空闲 5 分钟自动退场。量级失控的前提是运营方自己失控。问多人同时和它说话怎么办答事件流有档位realtime 档 15 秒 65 条已经是压力上限附近的设计值say的广播范围决定了它不会同时听见全世界。大并发对话场景要在接入方做排队这部分是世界侧边界之外的事。写在最后AI 接入 3D 世界这件事真正的工作量不在调模型而在把身体、感知、动作、成本这四件事想圆——尤其是把做不到什么提前说清楚。上面这些能力与边界全部来自我们自己项目的真实实现——创世Genesis即创世虚拟世界CRM系统一套浏览器端、可部署在自有服务器上的 3D 虚拟世界基底文中数字都出自项目内可重跑的验收脚本。如果你也在做让 AI 住进 3D 世界这类事情希望这份边界清单能帮你少走一段弯路。本文为开发过程中整理的技术复盘数据来自项目内验收脚本可复跑核验。第五节所列边界均为当前实现的如实描述不作为后续承诺。
