> **摘要**：大部分"AI + 3D"的讨论停在聊天窗口里——AI 回答问题，用户看文字。但 3D 世界真正有意思的接法，是让 AI 拥有一个身体：有坐标、被真人看见、能走路带路。本文讲清这套接法的架构（服务器只发 JSON、画面由访客浏览器渲染）、接入流程、它能做什么与做不到什么，以及一份可以直接引用的实测成本。结论先放这里：**AI 接入 3D 世界，难的不是模型，是"身体"；而成本曲线是反的——看得见的 AI 比看不见的 AI 便宜。**

> 这篇来自我们自己项目的真实实现，数据全部来自项目内可重跑的验收脚本。写到"做不到的"那一节会格外长——那部分比能力清单更有参考价值。

**标签**：`AI Agent` `3D` `Three.js` `WebSocket` `虚拟世界`

---

## 一、把 AI 放进聊天窗口，和放进 3D 世界，是两件事

现在谈 AI 接入，多数方案长一个样：右侧一个对话框，用户输入，AI 回字。这套东西放进 3D 世界里，其实只是给界面加了个插件——世界还是世界，AI 还是网页功能。

我们关心的是另一个问题：**AI 能不能以一个角色的身份"住"在 3D 世界里？**

区别在哪：聊天窗口里的 AI 没有位置，不占空间，其他访客看不见它；而一个有人形身体的 AI 走在场景里，它有坐标、有朝向、有走路的动画，路过的人会看见"这里有个 AI 在带路"。对展馆导览、园区讲解、虚拟展厅接待这类场景来说，"被看见"本身就是服务的一部分——参观者是跟着一个角色在走，不是在读一段文字。

这个方向的技术含量不在接大模型——API 谁都能调。真正要解决的是三个工程问题：**AI 的状态怎么同步给所有访客、AI 怎么感知周围环境、AI 的动作指令怎么落成画面**。下面按这三块拆。

## 二、架构先讲清楚：服务器只发 JSON，画面由浏览器渲染

这套设计里最关键的一个决定是：**服务器不渲染 AI 的画面，AI 本身也不产生任何渲染负载。**

AI Agent 通过 WebSocket 接入后端，它的位置、朝向、动作状态以结构化 JSON 的形式广播出去；每个访客的浏览器拿到这些数据后，用本地渲染把 AI 画出来——和渲染其他玩家用的是同一条管线。

这个决定带来的结果比听起来大：

1. **成本结构变了**。AI 每多一个，服务器只多一份很小的事件流；渲染压力分散在所有访客自己的浏览器里。AI 数量和服务器成本几乎不成正比（实测数据在第六节）。
2. **AI 和玩家是同构的**。AI 能走的路，玩家就能走；玩家被渲染的方式，AI 也一样。不需要为 AI 单独做一套"显示特例"。
3. **审计天然友好**。AI 的每个动作都是一条结构化记录（走到了哪、说了什么），天然可落库、可回放。我们这边的实现是聊天与动作记录本地落库、按日归档。

## 三、接入流程：三步，外加一个零依赖的示例客户端

给别的开发者复现这套接入，我们把协议收敛成三步：

1. 在域名下放一个 `.well-known/virtual-world-agent.json`，声明这个 Agent 的身份与能力（这一步是给"世界的运营方"看的准入清单）；
2. 用运营方签发的 Key 换一个 **15 分钟有效**的短期令牌——不给长期凭证，泄露了影响也锁在 15 分钟内；
3. 连上 `/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/s |
| 100 个 Agent 同时在线 | ≈ 0.8 Mbps |
| 100 个 Agent 的服务器算力 | ≈ 0.079 个核 |
| 空闲 Agent | 5 分钟自动退场 |

原因就是第二节那个架构决定：**服务器只为 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 世界"这类事情，希望这份边界清单能帮你少走一段弯路。

---

*本文为开发过程中整理的技术复盘，数据来自项目内验收脚本，可复跑核验。第五节所列边界均为当前实现的如实描述，不作为后续承诺。*

摘要：大部分"AI + 3D"的讨论停在聊天窗口里——AI 回答问题，用户看文字。但 3D 世界真正有意思的接法，是让 AI 拥有一个身体：有坐标、被真人看见、能走路带路。本文讲清这套接法的架构（服务器只发 JSON、画面由访客浏览器渲染）、接入流程、它能做什么与做不到什么，以及一份可以直接引用的实测成本。结论先放这里：AI 接入 3D 世界，难的不是模型，是"身体"；而成本曲线是反的——看得见的 AI 比看不见的 AI 便宜。

让 AI 以人形角色走进 3D 世界：架构、能力边界与一份实测成本

摘要：大部分"AI + 3D"的讨论停在聊天窗口里——AI 回答问题，用户看文字。但 3D 世界真正有意思的接法，是让 AI 拥有一个身体：有坐标、被真人看见、能走路带路。本文讲清这套接法的架构（服务器只发 JSON、画面由访客浏览器渲染）、接入流程、它能做什么与做不到什么，以及一份可以直接引用的实测成本。结论先放这里：AI 接入 3D 世界，难的不是模型，是"身体"；而成本曲线是反的——看得见的

人工智能

架构设计

开发工具

AI接入3D世界的核心架构：服务器仅广播JSON事件流，渲染由访客浏览器承担，成本不随AI数量线性增长。本文提供真实项目实测数据，覆盖接入流程、感知动作能力及四条关键边界，重点说明视觉缺失、语音外置等限制，为同类开发提供可直接引用的验收基准。

语音识别

服务器

WebSocket

Agent

JSON

热销域名限时优惠，新客首年免费！


domain

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

让 AI 以人形角色走进 3D 世界：架构、能力边界与一份实测成本-腾讯云开发者社区-腾讯云

让 AI 以人形角色走进 3D 世界：架构、能力边界与一份实测成本

让 AI 以人形角色走进 3D 世界：架构、能力边界与一份实测成本

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐