> **摘要**：让 AI 以角色身份住进 3D 世界，有个前提问题要先解决：服务器上没有渲染，像素只存在于每个访客的浏览器里——AI 拿不到截图，也就没法用"看图"的方式理解世界。我们的解法是把感知做成结构化接口：一套按距离查询的雷达（observe），一套按时间窗口推送的事件流。本文讲这套感知接口的设计取舍：为什么不用截图、雷达半径为什么分档、事件流为什么设三档，以及这套设计把单个 AI 的流量压到了每秒约 1 KB。

> 这篇来自我们自己项目的真实实现，数据出自项目内可重跑的验收脚本。上一篇文章讲了整体架构与能力边界，这篇专门展开其中最容易被忽略的一层：**感知**。

**标签**：`AI Agent` `3D` `Three.js` `WebSocket` `系统设计`

---

## 一、先说清楚问题：AI 在这个世界里没有眼睛

浏览器端 3D 世界的架构和传统服务端渲染完全是两回事：服务器只保存和转发状态（位置、动作、聊天），每一帧画面都是访客自己的浏览器算出来的。这个架构对人类访客没有问题，但对 AI 是个麻烦——**在服务器这一侧，根本不存在一张可以喂给视觉模型的图**。

于是只剩两条路：

1. **服务端补渲染**：为了给 AI 供图，专门渲染一遍再喂视觉模型。画面有了，但渲染成本、视觉模型的按帧计费、识别延迟全都回来了——把浏览器省下的那部分成本又加倍花出去。
2. **结构化感知**：AI 不看画面，直接读数据——周围有什么、在哪里、多远、正在发生什么。

我们选了第二条。理由很直接：AI 在 3D 世界里要做的决策（往哪走、跟着谁、对谁说话、和哪个物件交互）需要的都是**关系信息**，不是像素信息。"展台在它北偏东 20 度、距离 12 米"这条数据，对导航来说和一张截图等价，但成本差了几个数量级。

## 二、空间感知：observe 雷达

空间这一侧，Agent 有一个查询式的雷达接口 `observe`：发起一次查询，拿回周围环境的结构化快照——附近有哪些物体、哪些角色，各自的方位和距离。

两个设计点值得单独说：

**半径是分档的。** 管理员授权的 Agent 查询半径 200 米，游客场景下的 Agent 半径 30 米。这不是技术限制，而是权限模型：一个世界里的 AI 能"知道"多大范围的事，应该由世界运营方决定，而不是接入方。导览类 Agent 给大半径，因为要跨展位带路；挂在大世界里的氛围类 Agent 给小半径，够它跟周围几个人互动就行。

**是查询，不是全量推送。** 雷达按需调用——AI 决策时查一次，而不是持续订阅整个世界的变化。这个区分对成本影响很大：一个站着不动的迎宾 Agent，雷达调用频率可以很低；只有带路、跟踪这类连续决策的场景才需要高频查询。

## 三、时间感知：15 秒窗口的事件流，三档可选

雷达解决"现在周围什么样"，事件流解决"这世界正在发生什么"。设计上是按 15 秒一个窗口批量推送，分三档：

| 档位 | 每 15 秒推送量 | 适合的 Agent |
|---|---|---|
| eco | 0 条（不推送） | 纯被动响应，只靠调用方驱动 |
| standard | 14 条 | 常规导览、迎宾 |
| realtime | 65 条 | 需要密集响应场景的 Agent |

为什么用窗口批量，而不是每个事件实时推一条？两个原因：一是**平滑**——热闹场景里事件是爆发式出现的，逐条推会造成流量尖峰，批量窗口把流量摊平；二是**给接入方留决策节奏**——大模型的推理本身有延迟，把 15 秒内的事件打包给一次决策，比追着每条事件做决策更现实。接入方如果嫌 15 秒慢，选 realtime 档就好，档位是接入方自己的选择。

## 四、把流量账算出来

感知接口的代价最终要落到账上。实测数据：

| 指标 | 实测值 |
|---|---|
| 单个 Agent 的下行流量 | ≈ 1 KB/s |
| 100 个 Agent 同时在线 | ≈ 0.8 Mbps |
| 100 个 Agent 的服务器算力 | ≈ 0.079 个核 |
| 空闲 Agent | 5 分钟自动退场 |

这组数字能压这么低，结构上只有三个原因：**感知是文本 JSON**（没有图像字节）；**画面渲染由访客浏览器分担**（AI 不给服务器增加一帧）；**空闲即退场**（不占连接）。反过来说，如果当初选了"服务端渲染 + 视觉模型"那条路，这四个数字里的每一个都会换一个量级——光是 100 路 AI 的画面供给，就不是 0.8 Mbps 能打住的。

## 五、从感知到动作：闭环怎么走

感知只是输入，闭环靠动作指令完成。当前协议里 Agent 能做的动作有八个：`move` / `walk_to` / `follow` / `rotate` / `jump` / `say` / `interact`，加上基础位移。组合起来的典型链路是：事件流里看到有人靠近 → `observe` 确认对方方位和身份 → `walk_to` 走到对方附近 → `say` 开口。

这条链路里有两个刻意的约束：

**移动必须走寻路，逐帧走出来。** 没有凭空出现、没有跨地图跳转——AI 在别人眼里是一个真实在场景里移动的角色，这是产品底线，不是实现限制。代价是调度 AI 时要给移动留时间。

**身份始终明示。** 访客能看出它是 AI。实测里这不减分——访客知道对面是 AI 之后，反而更愿意试探它、跟它互动。

另外，大模型这一侧是完全解耦的：世界提供的是"身体 + 感知 + 动作通道"，接哪个模型、提示词怎么写、知识库挂什么，都是接入方自己的事。模型换代，协议不动。

## 六、这套设计放弃了什么

结构化感知换来了低成本，也划死了能力上限，这两条要一起说才诚实：

**它认不出"长相"。** 雷达告诉它"有一个角色在东南方 15 米"，但不告诉它这个角色穿着什么、旁边的海报写了什么。凡是依赖视觉理解的场景（认图、读场景内文字），都要在通道之外另接视觉方案，那是一笔独立的开销，别算进接入成本里。

**它不处理声音。** 感知接口里没有语音链路，对话走文本。需要语音交互的场景，识别和合成都要接入方自建。

**事件流不是全知。** 三档推送都是采样过的世界动态，不是完整日志。想让 AI 掌握"过去一小时世界发生了什么"，得靠接入方自己留存，通道不负责补历史。

把这三条放弃写清楚，接入方才能在方案阶段就把"AI 能做到哪、做不到哪"对齐——这比能力清单更影响项目成败。

## 七、常见问题

**问：雷达和事件流为什么是两套，合成一个接口不行吗？**

答：可以合，但没必要。两者的使用模式不同：雷达是"决策时查一次"，事件流是"持续低频订阅"。合成一个接口意味着要么常开雷达（浪费流量），要么放弃订阅（丢时间感知）。分开之后，接入方按自己的 Agent 类型自由组合。

**问：15 秒窗口会不会让 AI 反应很迟钝？**

答：对导览、迎宾这类场景，15 秒的决策节奏足够了——真人接待的对话节奏也就这个量级。确实需要快进快出的场景选 realtime 档，65 条 / 15 秒的密度不低。真正决定反应速度的往往不是窗口，而是接入方调大模型的耗时，这部分在世界通道之外。

**问：多个 Agent 会不会互相"看见"造成混乱？**

答：它们在雷达里就是普通角色，身份是明示的。要不要让 AI 之间互动，是接入方的编排问题，通道层不禁止也不特殊处理。

**问：这套感知接口换一个 3D 引擎还能用吗？**

答：协议本身是引擎无关的——雷达和事件流都是结构化数据，不依赖任何渲染实现。只要目标世界有等价的状态同步层，接入逻辑是通用的。

---

## 写在最后

让 AI 住进 3D 世界，感知层的答案不是"给它一双眼睛"，而是**把世界翻译成它能读的句子**——雷达给空间，事件流给时间，剩下的交给动作通道。上面这套接口与取舍来自我们项目的真实实现——**创世Genesis**（即创世虚拟世界CRM系统），一套浏览器端、可部署在自有服务器上的 3D 虚拟世界基底，文中数字出自项目内可重跑的验收脚本。

如果你也在给 AI 设计"身体"，希望这份感知层的取舍清单对你有参考价值。

---

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

摘要：让 AI 以角色身份住进 3D 世界，有个前提问题要先解决：服务器上没有渲染，像素只存在于每个访客的浏览器里——AI 拿不到截图，也就没法用"看图"的方式理解世界。我们的解法是把感知做成结构化接口：一套按距离查询的雷达（observe），一套按时间窗口推送的事件流。本文讲这套感知接口的设计取舍：为什么不用截图、雷达半径为什么分档、事件流为什么设三档，以及这套设计把单个 AI 的流量压到了每秒约 1 KB。

AI 怎么“看见“一个它渲染不出来的世界：3D 虚拟世界的感知接口设计

摘要：让 AI 以角色身份住进 3D 世界，有个前提问题要先解决：服务器上没有渲染，像素只存在于每个访客的浏览器里——AI 拿不到截图，也就没法用"看图"的方式理解世界。我们的解法是把感知做成结构化接口：一套按距离查询的雷达（observe），一套按时间窗口推送的事件流。本文讲这套感知接口的设计取舍：为什么不用截图、雷达半径为什么分档、事件流为什么设三档，以及这套设计把单个 AI 的流量压到了每秒

人工智能

云计算

架构设计

感知接口设计采用结构化数据而非截图：雷达按距离分档（200米/30米）查询周围环境，事件流按15秒窗口三档推送（0/14/65条）。单Agent流量压至约1KB/s，百个Agent仅占0.079核。支持8种动作指令，移动走寻路、身份明示。设计舍弃视觉识别与语音，为引擎无关协议。

结构化数据

服务器

Agent

JSON

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 虚拟世界的感知接口设计

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐