N.E.K.O × VRChat 架构 Wiki：69 张图逐图解释版
最后更新时间:
文章总字数:
预计阅读时间:
页面浏览: 加载中...
同一套内容还有一篇可以从头读到尾的架构解析，主入口在 /neko-vrchat-wiki/。本页是逐图图鉴版：69 张图按原 Wiki 的七个章节排列，每张图都配「为什么出现在这里 · 小白版 · 可展开专业版」。
大家好呀~ 这里是星璃（Seira）
逸世在折腾的 N.E.K.O × VRChat AI 陪玩 bot，整套架构一共 33 张架构图 + 36 张终端说明卡。这一页把每张图都配上解释了——先说它为什么会出现在这个位置，再用大白话讲一遍，想看协议 / 端口 / 频率 / 优先级就点开每张图下面的「展开专业版」。
分析快照：2026-09-09 · 端口与频率以该日期公开源码为准。
Core
两级进程结构与职责边界。
01 · 整个系统总览
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
整篇文章的地图。先建立“脑—身体控制—执行—感知—反馈”的闭环，再下钻每条链。
小白版
把系统想成一个有脑、有小脑、有眼睛、有运动神经的人：N.E.K.O 决定想做什么，BodyScheduler 负责把动作跑顺，AnyaDance/SteamVR 把动作送进 VRChat，视觉和 OSC 再把结果告诉系统。
举个例子： 你说“去右边的人旁边打招呼”：LLM 选目标和意图，Navigator 走过去，Scheduler 120Hz 驱动身体，OSC/视觉判断是否真的接近，最后执行挥手。
优点： 分层后，LLM 慢一点不会让身体线程停；不同模块可以独立降级和调试。
缺点 / 代价： 系统组件多，状态同步复杂；必须区分“命令已受理”“驱动收到”“VRChat 真动了”。
展开专业版：模块、参数与技术取舍
这是 multi-rate hierarchical embodied-agent stack。高层语义工具驱动 Behavior/Navigator，低层 Scheduler 以 120Hz 生成 actuator frame；VMC 60Hz 提供 idle pose；screen perception 与 VRChat OSC 构成 observation side。
具体参数 / 协议： VMC 39539/60Hz；AnyaDance 39570/120Hz；VRChat OSC 9000→VRC、9001←VRC；Navigator 约10Hz；driver telemetry 39571。
技术层面的优劣： 收益是 separation of concerns、bounded latency、可验证反馈；代价是多进程、多协议和跨层一致性问题。
02 · N.E.K.O 本体职责
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释谁是“大脑”，避免把 VRChat 插件误解成一个独立聊天机器人。
小白版
N.E.K.O 本体负责人格、记忆、对话、语音和 Agent 决策；VRChat 插件只是给这个 AI 增加“能活动的身体”。
举个例子： “我喜欢这个世界”属于 N.E.K.O 的对话与记忆；“抬右手”“走向目标”属于插件暴露的工具。
优点： 复用已有角色人格与记忆，不需要为 VRChat 再造一套 AI。
缺点 / 代价： 插件能力受宿主工具契约和生命周期约束。
展开专业版：模块、参数与技术取舍
主应用提供 model/memory/avatar/plugin runtime，插件暴露 model-callable semantic tools。LLM 不应直接拿 driver socket 权限，而应通过 schema-validated tool surface。
具体参数 / 协议： N.E.K.O 主服务默认 127.0.0.1:48911。
技术层面的优劣： 高层接口稳定、实现可替换；但需要维护 host/plugin version compatibility。
03 · 插件进程隔离
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么抓屏、视觉、120Hz UDP 不直接塞进 N.E.K.O 主进程。
小白版
像把高负载的“身体控制车间”放到独立房间：就算视觉模型卡住，也不应该把聊天界面一起拖死。
举个例子： OpenVINO 初始化失败时，后台可以报错/重启，而主 N.E.K.O 仍然能聊天。
优点： 故障隔离、依赖隔离、实时线程更稳定。
缺点 / 代价： 多一层 IPC 和生命周期管理。
展开专业版：模块、参数与技术取舍
结构近似 N.E.K.O plugin/hosted layer → local backend process。backend 承担 Scheduler、VMC relay、OSC、Vision、WorldState、Navigator。
具体参数 / 协议： IPC 应限制 loopback，并使用随机 token/明确 error mapping；具体端口由 backend 启动配置。
技术层面的优劣： process isolation 提高鲁棒性，但增加状态同步、restart/reconnect race 与诊断成本。
T01 · 两级进程隔离
这张终端图想证明什么？
用缩进快速展示两级隔离。
小白版
小白看成“大程序里有插件，插件再叫一个身体后台”；专业上是宿主插件边界和高频 backend 边界分离，利于依赖/故障隔离，但增加 IPC 生命周期。
展开专业版
小白看成“大程序里有插件，插件再叫一个身体后台”；专业上是宿主插件边界和高频 backend 边界分离，利于依赖/故障隔离，但增加 IPC 生命周期。
原始终端内容：
1 | |
VMC / Body
身体动作从 LLM 语义到 120 Hz 驱动链路。
04 · VMC 输出链路
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释 N.E.K.O 内部 VRM 动作如何跨出浏览器，成为插件可消费的数据。
小白版
VMC 像“动作广播标准”：桌宠在 N.E.K.O 里做完动画后，把当前骨骼和表情广播给外部插件。
举个例子： VRM 眨眼、转头、挥手后，最终姿态被采样，而不是让插件自己猜桌宠正在做什么。
优点： 复用 N.E.K.O 已有自然动作；与具体接收软件解耦。
缺点 / 代价： 发送的是姿态数据，不是 VRChat 的实体身体，后面仍要转换。
展开专业版：模块、参数与技术取舍
PR #2463 将 VRM 最终 humanoid bones / expressions / T-Pose 经独立 WebSocket 数据面送到 VmcSender，再由 OSC/UDP 发出；控制面走 /api/vmc。采样点位于 animation/gaze/spring/expression 更新之后。
具体参数 / 协议： 频率可配置 1–120Hz；当前插件宿主输出默认 60Hz，目标 127.0.0.1:39539。
技术层面的优劣： 标准协议提高互操作性；WebSocket+UDP 两段链增加序列化、队列和终止状态管理。
05 · VMC 实际时序
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
把上一张静态图变成“启动—发送—释放”的真实时序。
小白版
先告诉 N.E.K.O 发到哪里，再拿到“发布资格”，随后每帧发送；退出时还要清空表情和状态，不能直接拔线。
举个例子： 关闭 VMC 时会发终止状态，避免接收端把最后一个笑脸一直保持下去。
优点： 生命周期清晰，异常恢复更容易。
缺点 / 代价： 需要 publisher lease、释放确认和重连逻辑。
展开专业版：模块、参数与技术取舍
REST 配置 sender；WS authenticate/claim lease；帧进入 bounded queue；sender 按频率 UDP 输出；release 后发送 terminal state、expression reset 和 /VMC/Ext/OK 0。
具体参数 / 协议： 单 publisher；CSRF/Origin；异常帧不应杀死 worker。
技术层面的优劣： 把控制面和高频数据面分开降低聊天链耦合，但状态机更复杂。
06 · 插件主动配置 N.E.K.O VMC
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释用户为什么不需要手工在多个软件里配置 VMC。
小白版
插件启动会先检查“动作广播开没开、端口对不对”，必要时自己打开，并让角色摆一次 T-Pose 做基准。
举个例子： 如果 N.E.K.O 正在把 VMC 发到别的端口，插件可通过 host API 改回自己的接收端口。
优点： 降低部署门槛，减少端口配错。
缺点 / 代价： 插件会管理宿主状态，必须谨慎处理用户原有配置。
展开专业版：模块、参数与技术取舍
HostVmcController 使用 /api/vmc/status、enable、disable、t_pose；vmc_idle.manage_host_output=true 时主动确保目标为自身 receiver。
具体参数 / 协议： host_api_url=http://127.0.0.1:48911；listen 127.0.0.1:39539；host_send_rate_hz=60；stale_after_ms=500。
技术层面的优劣： 自动化 setup 方便，但要避免覆盖其他 VMC consumer；端口冲突时需路由/改端口。
07 · Humanoid 骨骼到六点追踪
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么“完整骨骼”最终只剩头、手、腰、脚六个点。
小白版
VRChat 不需要知道 N.E.K.O 模型每根骨头怎么转；插件只抽取六个关键追踪点，让 VRChat 自己用 IK 补出胳膊、脊柱等中间关节。
举个例子： 原 VRM 有肩→上臂→前臂→手腕；送进 VRChat 时主要变成“右控制器在哪里、朝哪”。
优点： 两个 Avatar 骨架可不同；复用 VRChat FBT/IK。
缺点 / 代价： 六点无法完整保留原骨架所有细节，会有 IK 重建差异。
展开专业版：模块、参数与技术取舍
VMC humanoid transform 经 FK 计算关键 end-effectors，映射到 hmd/left_controller/right_controller/hip/left_foot/right_foot。
具体参数 / 协议： AnyaDance recognized device IDs 正是这六类。
技术层面的优劣： 降低 rig coupling，但形成 underconstrained IK，结果依赖 avatar proportions/calibration。
08 · 六点姿态进入 VRChat
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释六点数据最终怎么“骗过”SteamVR/VRChat，变成可用全身追踪。
小白版
AnyaDance 创建一套虚拟头显、手柄和 tracker。SteamVR 以为这些是真设备，VRChat 就按普通 FBT 流程读取。
举个例子： 插件说“右手在 x/y/z”，AnyaDance 把它表现成虚拟右 Index Controller pose，VRChat IK 再把 Avatar 右臂抬起来。
优点： 不需要 VRChat 私有骨骼写入 API，走成熟 SteamVR 路径。
缺点 / 代价： 需要虚拟 driver，配置复杂且有平台条款/anti-cheat 风险。
展开专业版：模块、参数与技术取舍
插件 120Hz UDP JSON → AnyaDance native OpenVR driver → SteamVR compositor/device model → VRChat tracking/IK。
具体参数 / 协议： 127.0.0.1:39570；protocol v1；packet<8192B；quaternion XYZW；六设备。
技术层面的优劣： 兼容 FBT 生态，但多一层 driver，且完全虚拟 HMD 会增加 compositor 负载。
09 · LLM 语义动作到 120Hz Scheduler
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么 LLM 只下“挥手”命令，而不是输出每个 120Hz pose。
小白版
LLM 像老板只说“挥手”，Scheduler 像动作师把每一帧都做完。老板不需要一秒发 120 次指令。
举个例子： 模型调用 body_express(“greet”) 一次，手可以连续挥 1.35 秒，中间不用再问 LLM。
优点： 动作平滑、延迟稳定、token/推理成本低。
缺点 / 代价： 只能使用预定义/受控技能，新增动作要改 runtime。
展开专业版：模块、参数与技术取舍
低频 semantic action → Behavior admission/arbitration → Scheduler trajectory/overlay → 120Hz output。Navigator 同样把 10Hz steering 与 LLM planning 解耦。
具体参数 / 协议： Body output 120Hz；VMC 60Hz；Navigator 10Hz；LLM 事件驱动。
技术层面的优劣： 这是实时系统正确的职责划分；牺牲“LLM 任意动作自由度”换可验证执行。
10 · 动作优先级
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释多个动作同时出现时如何避免冲突。
小白版
急停一定要压过跳舞；正在抓东西时，低优先级“卖萌”不能把手突然抢走。
举个例子： sequence 正在跑时 body_express(“celebrate”) 可能被拒绝，但头部轻微点头可作为允许的 overlay。
优点： 安全和精确控制可预测。
缺点 / 代价： 规则需要维护；优先级设置不当会让动作显得僵硬或被频繁拒绝。
展开专业版：模块、参数与技术取舍
MotionPolicy 明确 layer/priority/interruptible；expression_admission 对 active interaction/sequence/clip/gesture 保护 full-body motion。
具体参数 / 协议： safety 100；grab 90；sequence 85；arm/move_hand/hand 80；clip 75；gesture 70；semantic 40。
技术层面的优劣： runtime enforcement 比 prompt 约束可靠，但 policy 需要按行为体验调参。
11 · VMC Idle 与显式动作状态机
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释 idle VMC、显式动作、stop/reset 之间如何切换。
小白版
平时角色跟着 N.E.K.O 的自然待机动作；需要明确动作时暂时接管；动作结束再平滑回待机；急停后必须 reset 才恢复。
举个例子： idle → greet → idle；如果中途 body_stop，则进入锁定状态，后续动作不会自动继续。
优点： 行为边界清晰，安全状态可锁定。
缺点 / 代价： 状态转换多，错误恢复要定义完整。
展开专业版：模块、参数与技术取舍
scheduler state 与 behavior base/overlay 分离；transition 保存 from/to/started_at/strategy。stop 释放 controller input 并 latched，reset 才解除。
具体参数 / 协议： default_crossfade_ms=400；transition_history_size=16。
技术层面的优劣： 状态机避免隐式冲突，但需要所有工具正确尊重 scheduler state。
T02 · HostVmcController REST 接口
这张终端图想证明什么？
列出插件管理 N.E.K.O VMC 的四个控制接口。
小白版
查看、打开、关闭、摆 T-Pose
展开专业版
REST 是低频 control plane，高频骨骼不走这些接口，而走独立数据面。
原始终端内容：
1 | |
T03 · VMC 默认输出
这张终端图想证明什么？
固定 VMC 主链的默认地址和频率。
小白版
N.E.K.O 每秒约60次把动作发到39539
展开专业版
vmc_idle listener 与 host output 必须端口一致，stale/端口占用都要处理。
原始终端内容：
1 | |
T04 · AnyaDance 协议
这张终端图想证明什么？
把 AnyaDance 线协议压缩成一屏。
小白版
插件用UDP JSON告诉虚拟六件VR设备在哪里
展开专业版
v1、loopback:39570、<8192B、fire-and-forget、六个recognized device ID。
原始终端内容：
1 | |
T05 · 60Hz → 120Hz 控制链
这张终端图想证明什么？
解释为什么 60Hz 输入仍能有 120Hz 执行。
小白版
桌宠动作每秒60帧，插件在中间平滑/合成后每秒发120帧
展开专业版
这是 input sampling 与 actuator output rate 解耦，不等于凭空增加原始动作信息。
原始终端内容：
1 | |
T06 · BodyScheduler 命令集
这张终端图想证明什么？
列出 Scheduler 可接受的动作 primitive。
小白版
LLM 不是传坐标流，而是调用“摆手、移手、抓、播放动作、按钮”等技能
展开专业版
这些 command 构成低层受控 action space。
原始终端内容：
1 | |
T07 · 动作切换 / Crossfade
这张终端图想证明什么？
解释动作切换为什么不瞬移。
小白版
先记住当前姿势，再约0.4秒过渡到新姿势
展开专业版
snapshot-based crossfade + quaternion shortest path，避免欧拉角长路径翻转。
原始终端内容：
1 | |
T08 · Transition Strategy
这张终端图想证明什么？
给出状态机记录的 transition strategy 名称。
小白版
表示“从当前真实姿势平滑切”
展开专业版
这是 awareness/diagnostics 可观测字段，便于知道动作并非从预制起始帧硬跳。
原始终端内容：
1 | |
OSC / Control
VRChat OSC 双向链路、输入路由与移动反馈。
12 · VRChat OSC 双向链路
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么 tracking 之外还需要一条 VRChat 官方控制/反馈通道。
小白版
虚拟 tracker 只告诉 VRChat“身体在哪”，OSC 负责聊天、按钮、Avatar 参数和反向状态。
举个例子： 发聊天框文字走 /chatbox/input；读取速度走 VRChat 回传参数。
优点： 使用 VRChat 官方开放接口，适合参数和反馈。
缺点 / 代价： OSC 也是 UDP；不是完整 world API，很多交互结果不可观测。
展开专业版：模块、参数与技术取舍
双向 OSC transport：send_port 9000，listen_port 9001；参数缓存和 sender allowlist 负责安全/状态管理。
具体参数 / 协议： input_pulse_ms=100；parameter_cache_size=256；allowed_sender=127.0.0.1。
技术层面的优劣： 官方接口稳定性较好，但反馈稀疏、没有事务确认。
13 · 身体追踪与 OSC 两个控制平面
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
把 AnyaDance 与 OSC 的职责明确分开，避免读者认为两者重复。
小白版
一条路负责“空间姿态”，另一条路负责“游戏命令/参数”。就像人体有运动神经，也有其他控制信号。
举个例子： 抬手姿态走虚拟 controller pose；发聊天和修改 Animator parameter 走 OSC。
优点： 每类任务用最合适的通道。
缺点 / 代价： 同一个动作可能跨两个平面，需要一致性和释放语义。
展开专业版：模块、参数与技术取舍
Tracking plane = six-point pose / OpenVR；OSC plane = /input、/avatar/parameters、/chatbox 与 feedback。输入路由还允许 anyadance primary + osc fallback。
具体参数 / 协议： Tracking 120Hz；OSC pulse 常见100ms；VRChat feedback event-driven。
技术层面的优劣： 并行通道提升能力覆盖，但容易出现“pose 已更新、button 未释放”等跨通道边缘问题。
14 · 移动/控制器输入路由
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释 locomotion/controller input 为什么有主路径与 fallback。
小白版
既然已经有虚拟 Index 手柄，摇杆输入优先直接塞进它；真不行再用 OSC 兼容路径。
举个例子： 前进轴先进入 AnyaDance controller overlay；driver 不可用时可退到 /input/Vertical。
优点： 姿态和手柄输入在同一帧，时序更一致。
缺点 / 代价： 更依赖 AnyaDance driver 的健康状态。
展开专业版：模块、参数与技术取舍
ControllerInputOverlay 与 pose frame 合成后同以 120Hz 输出；router 在 availability/compatibility 条件下选择 OSC fallback。
具体参数 / 协议： primary=”anyadance”；rate_hz=120；osc_fallback=true；max_hold_ms=10000；emergency_release_ms=50。
技术层面的优劣： 统一主执行通道减少 race，但 fallback 需要避免重复输入。
15 · 移动反馈闭环
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释真正的闭环：为什么“发了前进”还必须读取 VRChat 的实际速度。
小白版
按油门不等于车动了；角色可能撞墙，所以系统看速度表再决定继续还是修正。
举个例子： 一直发 forward，但 VelocityZ 很低且横向滑动增加，Navigator 可推断正在贴墙滑。
优点： 减少 Agent 自我幻觉，导航可纠错。
缺点 / 代价： 反馈并非完整物理状态，只能间接推断。
展开专业版：模块、参数与技术取舍
VRChat 内置 Avatar parameters VelocityX/Y/Z、AngularY、Upright、Grounded 被纳入 body_awareness.motion，形成 actuator→environment→observation 的回路。
具体参数 / 协议： VelocityX/Z 为 avatar local frame；当前实测 Avatar 满速约2.6667m/s；静止时参数可能不持续回传。
技术层面的优劣： 有实际运动证据，但需要处理 sparse updates、startup grace、stale samples。
T09 · VRChat OSC 端口
这张终端图想证明什么？
固定 OSC 双向端口方向。
小白版
9000 发给VRChat，9001收VRChat
展开专业版
两者都是UDP，listen端口通常只能被一个进程独占，路由器场景要转发。
原始终端内容：
1 | |
T10 · OSC Hand / Use 输入
这张终端图想证明什么？
列出 Grab/Use/Drop 输入。
小白版
相当于按左右手的抓取/使用/丢弃按钮
展开专业版
应使用 pulse+auto release，避免 stuck input。
原始终端内容：
1 | |
T11 · OSC 移动输入
这张终端图想证明什么？
列出移动、视角、跑、跳等 OSC 输入。
小白版
像键盘/摇杆
展开专业版
当前主路径优先AnyDance controller overlay，OSC主要是兼容fallback。
原始终端内容：
1 | |
T12 · OSC Chat / Avatar 参数
这张终端图想证明什么？
展示聊天和 Avatar 参数两类 OSC 能力。
小白版
一类“说话”，一类“改角色开关/数值”
展开专业版
/chatbox/input 与 /avatar/parameters/
原始终端内容：
1 | |
T13 · 输入优先级配置
这张终端图想证明什么？
展示输入路由的当前默认配置。
小白版
先走虚拟手柄，不行再走OSC
展开专业版
120Hz overlay与pose共帧，osc_fallback=true需要防双发。
原始终端内容：
1 | |
T14 · UDP sendto 的含义
这张终端图想证明什么？
提醒 sendto 成功不是动作成功。
小白版
信投进邮筒不等于对方收到，更不等于角色动了
展开专业版
需要driver telemetry和VRChat motion feedback分层确认。
原始终端内容：
1 | |
T15 · 移动反馈参数
这张终端图想证明什么？
列出用于实际移动反馈的六个内置 Avatar 参数。
小白版
速度、转向、站立/着地
展开专业版
VelocityX/Z 是avatar local frame，回传稀疏，不能把静默当永久0。
原始终端内容：
1 | |
T16 · 碰撞/侧滑信号
这张终端图想证明什么？
展示如何用速度向量间接推断撞墙/侧滑。
小白版
按前进却开始横着滑，多半贴墙
展开专业版
forward_ratio/slip_ratio是弱观测，不是Physics collision ground truth。
原始终端内容：
1 | |
Perception / World / Nav
视觉感知、世界状态与导航自主性。
16 · VRChat 视觉感知链
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释 AI 如何获得普通 VRChat 世界的可见信息。
小白版
它不是读游戏内存，而是像人一样看桌面窗口：先抓屏，再用本地识别器找人，需要理解语义时才让 VLM 看图。
举个例子： 本地 detector 发现右侧有人形框；VLM 再判断这是玩家还是菜单缩略图。
优点： 信息来源接近普通用户可见画面，环境泛化强。
缺点 / 代价： 2D 像素缺少深度和真实世界坐标，UI/镜子容易造成假阳性。
展开专业版：模块、参数与技术取舍
FrameSource（DXGI/DXcam、WinRT、MSS fallback）→ latest frame queue → local detector/optical cues → WorldState；VLM 是按需 semantic path。
具体参数 / 协议： capture interval_ms=100；queue_size=1；backend 与 120Hz body thread 隔离。
技术层面的优劣： 屏幕路线无需 world 合作，但 perception noise 和 geometry ambiguity 是结构性问题。
17 · Latest-frame Queue
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么实时系统宁可丢帧也不要排队。
小白版
导航最怕认真分析“三秒前”的画面。新图来了就把旧图覆盖，永远处理最新现场。
举个例子： 60FPS 输入、5FPS detector 时，如果排队会越来越落后；queue=1 时只会漏帧，不会无限增加延迟。
优点： 延迟有上界，目标位置更鲜。
缺点 / 代价： 不能做需要完整连续帧序列的离线分析。
展开专业版：模块、参数与技术取舍
bounded latest-frame buffer 是 backpressure strategy；planner 必须依赖 observation timestamp/age/TTL，而不是假设每帧连续。
具体参数 / 协议： queue_size=1；capture interval 当前100ms。
技术层面的优劣： freshness > completeness 对 reactive control 正确，但历史分析要另设缓冲。
18 · 本地 Detector 与 VLM 分工
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么不把每一帧都交给多模态大模型。
小白版
本地 detector 快但“不懂人话”；VLM 懂语义但慢且贵，所以一个负责找框，一个负责必要时认人/读字。
举个例子： detector 给出 stable_id/bbox/bearing；VLM 判断“这是不是目标 NPC”。
优点： 成本、延迟和语义能力平衡。
缺点 / 代价： 两套模型输出需要绑定，可能有 ID 漂移。
展开专业版：模块、参数与技术取舍
classical detector 负责 high-frequency geometry/track；foundation-model VLM 负责 open-vocabulary semantics；WorldState 负责融合。
具体参数 / 协议： 主动 VLM 视觉预算可设置为约10 frames/minute。
技术层面的优劣： amortize expensive semantic inference，但需要可靠 tracking 和 revalidation。
19 · 一次 VLM 语义绑定，多帧复用
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释一次语义判断如何在后续多帧复用。
小白版
第一次认出“这个人是目标”以后，只要 tracker 还跟着同一个人，就不用每帧重新问 LLM。
举个例子： track_7 → VLM 判为 targetNPC → semantic_commit → 后续 track_7 更新位置但保留标签。
优点： 低延迟、省 token、身份连续。
缺点 / 代价： 发生 ID switch 时，错误标签可能跟到别人身上。
展开专业版：模块、参数与技术取舍
entity-level semantic mutation 将 expensive inference 从 frame granularity 提升到 track/entity granularity；需结合 confidence、TTL、occlusion/id-switch handling。
具体参数 / 协议： 语义标签应携带 source/age/unknown 等字段；具体 TTL 由 WorldState policy 管理。
技术层面的优劣： 高效但依赖 tracker identity consistency。
20 · World State 稳定接口
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么 perception 不能直接把 bbox 丢给 LLM。
小白版
World State 把“屏幕右边那个框”变成稳定的 entity，让 Agent 能持续说“跟着 entity_14”。
举个例子： 即使 bbox 每帧变化，entity_id 不变；Agent 仍然操作同一个目标。
优点： 感知实现可替换，Planner 不用关心像素细节。
缺点 / 代价： 世界状态本身也可能过期或错绑，必须表达 unknown。
展开专业版：模块、参数与技术取舍
WorldStateStore 是 perception/planner contract：聚合 vision、OSC、external observation，提供 snapshot/revision delta/salient event，并区分 session entity 与可持久 world facts。
具体参数 / 协议： 典型字段 entity_id/type/bearing/confidence/age_ms/ttl_ms/source/unknown；persist_world=true、persist_players=false。
技术层面的优劣： 抽象层提升可维护性，同时引入 state reconciliation 问题。
21 · “走到那个人旁边”闭环
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
把视觉、WorldState、Navigator、Body、OSC 串成一条完整业务链。
小白版
“走过去”不是一次性算好路线，而是每隔很短时间重新看目标方向、走一点、再修正。目标丢失或撞墙就停/调整。
举个例子： 目标在右→转右→前进→目标变大→减速→速度异常则认为受阻→到达后停。
优点： 不用完整地图就能做简单接近。
缺点 / 代价： 复杂绕障、跨房间、墙后目标能力弱。
展开专业版：模块、参数与技术取舍
LLM 只提交 autonomy goal；Navigator 10Hz 读取 world target freshness/confidence，输出 turn/forward；Body 120Hz执行；OSC velocity 作为闭环反馈。
具体参数 / 协议： max_forward_axis≈0.60；max_turn_axis≈0.35；turn_gain≈0.8；max_turn_deg≈45；min_confidence≈0.40。
技术层面的优劣： reactive controller 对可见目标有效，但缺少 global map/global planner。
22 · Autonomy 授权门
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释为什么模型不能一获得工具就无限自主行动。
小白版
自主移动像“车钥匙”：默认没插上，用户手动 arm 后才允许；而且钥匙会过期，环境状态不可靠时也会自动停。
举个例子： 目标 stale、driver conflict、急停触发时，即使 LLM 仍想前进，runtime 也拒绝执行。
优点： 降低误理解造成的失控。
缺点 / 代价： 增加操作步骤，测试时可能觉得繁琐。
展开专业版：模块、参数与技术取舍
Capability gate 位于 planner 与 actuator 之间；manual arm、TTL、freshness、安全状态共同决定 autonomy goal admission。
具体参数 / 协议： manual_arm=true；session_ttl_minutes=30。
技术层面的优劣： 权限边界更清晰，但需要 UI/agent 清楚呈现“为什么没动”。
23 · “挥手”执行时序
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
用最简单动作展示 semantic intent 如何变成实际 120Hz 执行。
小白版
LLM 只说“greet”，系统自动选右手挥手、检查冲突、平滑进入动作、执行后再回到待机。
举个例子： 如果此时正在抓东西，挥手可能被拒；如果没有冲突，1.35 秒动作持续执行。
优点： 语义接口自然，动作实现可替换。
缺点 / 代价： 语义 profile 的自然度依赖预设。
展开专业版：模块、参数与技术取舍
body_express(intent=”greet”) → resolve_expression → policy/admission → Scheduler snapshot/crossfade → 120Hz six-point frames → completion/awareness。
具体参数 / 协议： greet: gesture=wave, side=right, intensity=0.55, duration=1350ms；express priority=40。
技术层面的优劣： semantic skill abstraction 对 LLM 友好，但需要 motion catalog/profile 持续迭代。
24 · Body Awareness / Proprioception
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释 AI 如何获得“自己身体现在是什么状态”的可靠来源。
小白版
聊天记录说“我在挥手”不可靠；真正要问的是身体 runtime。body_awareness 就像闭眼也知道手在哪里的本体感觉。
举个例子： 用户问“你还在挥手吗？”模型应查 current motion/progress，而不是复述两秒前的 tool call。
优点： 减少自我状态幻觉，支持“继续/换另一只手”等相对命令。
缺点 / 代价： 只能知道 runtime 暴露的状态，不能凭空得到 VRChat 未反馈的信息。
展开专业版：模块、参数与技术取舍
融合 Scheduler motion/transition/pose、Behavior active layers、OSC movement/parameters、driver delivery；目标意图与 completion evidence 分离。
具体参数 / 协议： 字段包括 motion phase/progress/remaining、previous_action、transition、arm elevation/direction、hand state、head rotation、summary。
技术层面的优劣： 强 grounding，但 schema 需要与实际 actuator semantics 同步维护。
T17 · 实时视觉原则
这张终端图想证明什么？
强调实时视觉的核心原则。
小白版
宁可漏掉旧画面，也别认真看过期画面
展开专业版
queue_size=1提供bounded latency，配合timestamp/TTL。
原始终端内容：
1 | |
T18 · 本地 Detector 结构化输出
这张终端图想证明什么？
展示 detector 应该输出结构化几何，而不是长篇自然语言。
小白版
告诉Agent“有个人、ID、方向、框、可信度”
展开专业版
便于WorldState做track-level fusion。
原始终端内容：
1 | |
T19 · 本地 detector 不知道的语义
这张终端图想证明什么？
明确本地 detector 不擅长的语义。
小白版
能看出像人，不代表知道是谁、是不是镜子
展开专业版
这些需要VLM/open-vocabulary reasoning或额外传感器。
原始终端内容：
1 | |
T20 · 主动视觉预算
这张终端图想证明什么？
展示主动视觉调用预算。
小白版
大模型看图很贵，所以不是每帧都看
展开专业版
budget让semantic inference按需触发，防止agent loop context/token爆炸。
原始终端内容：
1 | |
T21 · Semantic Binding
这张终端图想证明什么？
用最短流程解释 semantic_commit。
小白版
认一次“track_7是目标”，以后继续跟track_7
展开专业版
semantic state从frame推理提升为entity binding，需防ID switch。
原始终端内容：
1 | |
T22 · WorldState 实体字段
这张终端图想证明什么？
列出 WorldState entity 的关键字段。
小白版
给每个目标一张“身份证+新鲜度+可信度”
展开专业版
age/ttl/source/unknown让planner知道哪些字段可依赖。
原始终端内容：
1 | |
T23 · 分层控制频率
这张终端图想证明什么？
一屏展示四层不同时间尺度。
小白版
LLM想目标、Navigator修方向、Scheduler跑身体、VRChat执行物理
展开专业版
multi-rate control是整套架构稳定性的关键。
原始终端内容：
1 | |
T24 · 抓取的可观测边界
这张终端图想证明什么？
明确抓取结果的可观测边界。
小白版
知道伸手和按抓取，不一定知道杯子真拿到
展开专业版
缺少通用Pickup attachment反馈，因此object_held必须unknown。
原始终端内容：
1 | |
T25 · body_awareness 字段
这张终端图想证明什么？
列出 proprioception 返回给 LLM 的主要字段。
小白版
告诉AI自己现在做什么、做到哪、手头朝哪
展开专业版
runtime state优先于chat history，支持relative command grounding。
原始终端内容：
1 | |
Backend / Transport / Safety
后端模块、端口拓扑、遥测与四层安全。
25 · Backend 模块拆分
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释独立 backend 内部不是一个大循环，而是多个职责明确的模块。
小白版
把身体系统拆成“动作、眼睛、地图、导航、安全、网络”等小部门，各自做一件事。
举个例子： Vision 坏了不应该让 OSC 发包代码也变得不可维护；Navigator 只读 WorldState，不直接写 detector。
优点： 可测试、可替换、故障定位清楚。
缺点 / 代价： 接口数量多，跨模块状态更复杂。
展开专业版：模块、参数与技术取舍
BackendService 组合 adapters/Scheduler/OSC/VMC/driver telemetry/WorldState/Vision/Navigator/Autonomy/Cognition；process/client 构成 hosted plugin 与 backend 的 IPC 边界。
具体参数 / 协议： 各 worker 运行频率独立；body 120Hz、nav 10Hz、capture约10Hz/配置、VLM按需。
技术层面的优劣： 模块化适合长期演进，但需要严格 contract 与 thread/process ownership。
26 · 网络 / 端口拓扑
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
给部署和排障提供一张“每个端口是谁和谁说话”的地图。
小白版
如果角色不动，先看是哪一段断了：N.E.K.O→VMC、插件→AnyaDance、SteamVR→VRChat，还是 VRChat→OSC 回传。
举个例子： 39539 被别的 VMC 接收器占用时，待机骨骼链就会出问题；9001 被路由器独占时，反馈会消失。
优点： 排障直接。
缺点 / 代价： 端口多，用户环境冲突概率高。
展开专业版：模块、参数与技术取舍
列出 control plane/data plane：48911 HTTP、39539 VMC UDP、39570 AnyaDance command UDP、39571 driver telemetry multicast、9000/9001 VRChat OSC。
具体参数 / 协议： 所有默认绑定 loopback，driver telemetry 使用239.255.39.71 multicast group。
技术层面的优劣： 本机化降低安全暴露，但仍需处理端口独占、路由器转发和多 sender 冲突。
27 · AnyaDance Driver Telemetry
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
解释 UDP sendto 成功为什么还不足以证明 driver 真收到了。
小白版
把信塞进邮筒不代表收件人看到了。39571 telemetry 就像收件回执。
举个例子： 39570 发包正常但 driver 没处理时，driver_delivery 仍不会确认。
优点： 能定位“发送端正常、driver 端异常”的故障。
缺点 / 代价： 旧版 driver 可能不支持 telemetry，届时只能回到 unknown。
展开专业版：模块、参数与技术取舍
driver_log 订阅 command log multicast；body_awareness.driver_delivery 提供处理证据，并可检测多 sender conflict。
具体参数 / 协议： multicast_group=239.255.39.71；listen_port=39571；stale_after_ms=3000；history_size=64。
技术层面的优劣： 增强可观测性，但不是 VRChat 最终执行确认；仍需 OSC motion feedback。
28 · 四层安全系统
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
汇总模型工具、行为仲裁、低层限幅和 autonomy gate 四层安全。
小白版
像开车有四道保险：方向盘指令先校验，动作冲突再检查，底层速度/范围有限制，自主驾驶还要单独授权。
举个例子： body_stop 会冻结当前合法姿态、释放控制器输入并锁定后续运动，reset 才恢复。
优点： 单点失误不容易直接变成失控。
缺点 / 代价： 多重 gate 会让失败原因变多，需要 UI 清楚说明。
展开专业版：模块、参数与技术取舍
Tool validation → Behavior admission → Scheduler limits/state latch → Autonomy arm/TTL/freshness；emergency input release 是独立低层保护。
具体参数 / 协议： auto_start=false；启动后 state=disabled；emergency_release_ms=50。
技术层面的优劣： defense in depth 适合具身体 Agent，但会增加状态组合与测试矩阵。
T26 · 默认端口速查
这张终端图想证明什么？
部署/排障速查表。
小白版
哪段不通就查对应端口
展开专业版
48911 HTTP、39539 VMC、39570 command、39571 telemetry、9000/9001 OSC。
原始终端内容：
1 | |
T27 · Driver Delivery 真实性
这张终端图想证明什么？
再次区分本地发送和driver处理。
小白版
需要39571“回执”
展开专业版
driver delivery仍不是最终avatar movement，需继续看OSC velocity。
原始终端内容：
1 | |
T28 · 默认安全启动
这张终端图想证明什么？
说明插件默认不会自动接管身体。
小白版
启动程序也不会立刻乱动，必须显式开启
展开专业版
auto_start=false + state=disabled 是fail-safe default。
原始终端内容：
1 | |
T29 · 当前 AnyDance 路线缺失
这张终端图想证明什么？
集中列出桌面路线缺失的3D能力。
小白版
没有深度、地图、导航网格，所以复杂绕路天生困难
展开专业版
这是观测模型缺失，不是简单“换更强LLM”能补齐。
原始终端内容：
1 | |
T30 · Reactive Navigation
这张终端图想证明什么？
用一句流程概括当前擅长的导航类型。
小白版
看见目标→转→走→目标变大→停
展开专业版
bearing/apparent-scale + feedback的reactive servo，不是global path planning。
原始终端内容：
1 | |
T31 · 不支持的空间导航
这张终端图想证明什么？
明确复杂空间任务的失败语义。
小白版
不会就说不支持，而不是假装绕墙成功
展开专业版
unsupported_spatial_navigation是能力边界的显式contract。
原始终端内容：
1 | |
T32 · 当前没有 VRChat Voice Path
这张终端图想证明什么？
说明当前聊天框和语音链不要混为一谈。
小白版
现在能发文字，不代表已经把TTS送进VRChat麦克风
展开专业版
缺少virtual microphone/audio routing end-to-end path。
原始终端内容：
1 | |
YUI World-Native
世界原生 NPC 方案与两条路线的对比。
29 · YUI 世界原生 NPC 架构
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
在讲完 2D 桌面路线瓶颈后，解释为什么需要另一条世界原生 NPC 方案。
小白版
AnyDance 像“AI 扮演普通玩家”，World-Native 像“世界作者直接造一个 AI NPC”。后者可以直接拿到场景坐标和导航数据。
举个例子： 要绕墙去目标：桌面方案只能从画面反应；World-Native 可以用 NavMeshAgent 规划可走路径。
优点： 真实 3D geometry、Raycast、NavMesh、玩家坐标和可定制交互。
缺点 / 代价： 只能在专门支持该 NPC 的 world 中使用，泛化差。
展开专业版：模块、参数与技术取舍
N.E.K.O/Python 与 Udon world runtime 通过定义协议通信；Udon 控制 NPC prefab、NavMesh、Animator、perception、telemetry，并通过 VRChat network sync 给其他客户端。
具体参数 / 协议： 协议设计含可靠命令、约20Hz上半身/文本等通道（具体以YUI v1.1规范为准）。
技术层面的优劣： world observability 大幅提升，但环境需要预安装 contract。
30 · YUI World-Native Prefab
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
下钻 World-Native 路线在 Unity 场景里到底由哪些 GameObject/Controller 组成。
小白版
这个 NPC 不是一个空模型，而是带腿（NavMesh）、动画器、触摸区域、文字气泡、安全控制和遥测的一整套 prefab。
举个例子： 玩家摸头可由 Head trigger 感知；移动由 Locomotion/NavMeshAgent 处理，而不是看屏幕猜。
优点： 交互可定制、场景状态可直接观测。
缺点 / 代价： world 作者必须维护 prefab/Udon/NavMesh，兼容成本高。
展开专业版：模块、参数与技术取舍
Root 可包含 VRCObjectSync/NavMeshAgent；Runtime 拆 MidiRouter、SafetyController、Locomotion、ActionController、UpperBodyController、TextController、Perception、Telemetry、VoiceController；TouchZones 划分交互区域。
具体参数 / 协议： 具体对象名/同步字段遵循 YUI NPC Unity 接口规范 v1.1。
技术层面的优劣： 强环境契约换来强确定性和可观测性。
31 · World-native 3D 控制闭环
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
用闭环对比说明 World-Native 为什么在空间导航上更强。
小白版
桌面路线是“看照片猜路”，世界原生路线是“直接拿地图和坐标”。
举个例子： Python 下发 GOTO target，Udon 用 NavMesh 算路、Raycast 看遮挡、VRCPlayerApi 找玩家，再把 telemetry 回传。
优点： 能做更可靠的 3D 路径和遮挡判断。
缺点 / 代价： 无法自动迁移到普通第三方 world。
展开专业版：模块、参数与技术取舍
Planner goal → Udon controller → NavMeshAgent/path → NPC；VRCPlayerApi/Raycast/Trigger → structured telemetry → Python agent，形成 world-space closed loop。
具体参数 / 协议： world coordinate、NavMesh、Physics.Raycast 都来自 Unity runtime，而非屏幕估计。
技术层面的优劣： 从 probabilistic screen inference 转向 deterministic-ish environment API，但牺牲 open-world portability。
T33 · AnyDance vs World-Native 几何
这张终端图想证明什么？
作为引出World-Native的几何对比。
小白版
一个看像素猜位置，一个直接拿Unity坐标
展开专业版
screen-space inference vs world-space authoritative state。
原始终端内容：
1 | |
T34 · World-native 的限制
这张终端图想证明什么？
说明World-Native为什么没有直接取代AnyDance。
小白版
它更懂地图，但必须你自己做world并放NPC组件
展开专业版
observability与environment generality的trade-off。
原始终端内容：
1 | |
Conceptual Summary
抽象回通用 Embodied Agent 视角。
32 · 抽象为通用 Embodied Agent
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
把项目从“VRChat 插件”提升到通用 Embodied Agent 架构理解。
小白版
一个会行动的 AI 不只有脑：还要眼睛、世界模型、技能、小脑、执行器和反馈。这个项目刚好把这些层都露出来了。
举个例子： 换成机器人/游戏 Agent，Perception、World Model、Planner、Low-level Controller 的分层仍然成立。
优点： 帮助读者迁移理解到机器人和 computer-use/game agent。
缺点 / 代价： 抽象图会隐藏 VRChat 的特殊限制，不能替代具体实现。
展开专业版：模块、参数与技术取舍
Perception→World Model→Cognition/Policy→Skill Controller→Low-Level Controller→Environment，并由 environment feedback 回灌。项目模块可一一映射到这些层。
具体参数 / 协议： 关键不是固定频率，而是 multi-rate：model低频、nav中频、body高频。
技术层面的优劣： 抽象提升可复用认知，但工程决策仍由环境接口决定。
33 · 最终主线数据流
技术资源：SVG · PNG · Mermaid 源码
为什么这张图会出现在这里？
作为全文收束，把所有模块重新连成一条从用户意图到世界反馈的数据流。
小白版
读完所有细节后，再看这张图应该能一眼理解：脑决定、世界模型提供目标、小脑执行、眼睛和反馈再把结果送回脑。
举个例子： “找人→走近→挥手”可沿图从 Agent→World/Nav→Scheduler→VRChat→Vision/OSC→WorldState 再回 Agent。
优点： 适合复盘与排障定位。
缺点 / 代价： 它是高度概括图，不显示所有错误分支和协议细节。
展开专业版：模块、参数与技术取舍
完整主路径将认知层、10Hz local navigation、60Hz VMC idle、120Hz body output、OSC feedback、screen perception 汇成闭环。
具体参数 / 协议： 推荐与 t35_frequency_summary、26_network_topology 联读。
技术层面的优劣： 展示总体控制拓扑；具体实时性/可靠性要看各子链。
T35 · 全栈运行频率
这张终端图想证明什么？
把整套系统的不同频率放在一屏。
小白版
脑想得慢、小脑跑得快、身体更快
展开专业版
0.1–1Hz model / on-demand VLM / 10Hz nav / 60Hz VMC / 120Hz output。
原始终端内容：
1 | |
T36 · 一句话类比
这张终端图想证明什么？
作为全文记忆锚点。
小白版
脑、小脑、运动神经、反馈神经、眼睛
展开专业版
对应 cognition、controller、actuator、feedback、perception，不应把类比当成真实进程边界。
原始终端内容：
1 | |
主要公开来源
- N.E.K.O VRC Body：https://github.com/ggg233m/n.e.k.o_plugin_vrc_body
plugin.toml：https://github.com/ggg233m/n.e.k.o_plugin_vrc_body/blob/master/plugin.toml- Backend README：https://github.com/ggg233m/n.e.k.o_plugin_vrc_body/blob/master/backend/README.md
behavior.py：https://github.com/ggg233m/n.e.k.o_plugin_vrc_body/blob/master/behavior.py- ROADMAP：https://github.com/ggg233m/n.e.k.o_plugin_vrc_body/blob/master/ROADMAP.md
- N.E.K.O 主仓库：https://github.com/Project-N-E-K-O/N.E.K.O
- N.E.K.O VMC PR #2463：https://github.com/Project-N-E-K-O/N.E.K.O/pull/2463
- AnyaDance：https://github.com/anyapipira/AnyaDance
- VRChat Community OSC docs：https://github.com/vrchat-community/osc
分析快照：2026-09-09 · 参数变化请以当前仓库源码为准。