Unity × Agent:一次关于现实边界的系统搭建实验¶
这个系统的目标很简单:让 Unity 里的角色不再是空壳,而是具备基础的理解、记忆与回应能力——不只是回应,更是“情感化”的回应。
一、初始分歧:Unity 工具 vs Python 后端,API vs 本地模型¶
起点的问题本质是两个维度的权衡:
- 第一,智能模块是在 Unity 内部构建(C#)还是外部构建(Python 后端)?
- 第二,是调用在线 API,还是本地部署模型?
选择是清晰的:Python 后端 + API 模型。这不是因为其它方式不可行,而是在当时,时间和工具还没到位。
Unity 的智能生态远不成熟,支持有限,很多功能只是“能跑”。而本地模型那边,主流选择是 LLaMA2,一方面性能不行,另一方面小模型输出中英文不分——常常输出夹杂着的英文、逻辑跳脱的中文。真正可用的只有 Qwen 2.5 3B,但商业许可不开放,依然限制太多。
现实是,不缺技术路径,缺的是可落地的组合。
二、逐项击破:从“能用”到“像人”¶
这个系统的目标,从来不只是对话,而是“有记忆”“带情绪”“像个活人”。
整个迭代过程,是一场持续削减延迟、压缩上下文、模拟心理模型的过程。主要问题分为四个:
1. RAG 准确率过低¶
传统的文本分段 + 向量化检索(即 RAG)在本地环境中效果极差:切片难以控制语义边界,匹配召回也经常错漏。虽然这种方案的复杂度低,但准确性不足。
最终放弃了这条路,转向结构化数据:直接使用 CSV 文件作为信息载体。Unity 将信息记录写入 CSV,Python 后端通过精确的指令式函数(如 CSVTools.query(...)
)进行搜索,检索结果直接拼接进 prompt。
这样,Agent 不再“模糊猜测”,而是“明确调用”。
2. 响应速度太慢¶
等待是一种用户焦虑。
最初版本的延迟显著,体验非常差。大部分本地模型尝试下来响应时间普遍在 7 秒以上,尤其在需要工具调用或复杂上下文拼接时。
解决方案是“流式输出 + 动态函数调用”:先说话,后做事。即优先返回前几句“我明白了,我来查一下”,随后在后台执行函数,拉取检索数据,再继续完整回答。
结果是延迟压缩到 最快 2 秒,常态 3 秒内,几乎消除了用户端的空等感。
3. 情感缺失¶
角色说话太像机器,不像人。
尝试路径包括:提示词固定化、角色情绪预设、人格 Prompt 微调。
结果惊人:角色不但能在合理上下文中表现出“担忧”“讽刺”“温柔”等情绪,还能针对玩家的历史行为做出八卦式的调侃,比如:“上次你不是也说过要戒糖?”
这部分效果异常自然。情感化不再是“多用感叹号”,而是具体而生动的语言选择。
4. 事件记忆不足¶
简单记忆系统无法追踪上下文事件链,角色始终是“失忆的 NPC”。
这部分的解决方案依旧是基于结构化 CSV 文件。所有事件通过 Unity 的行为触发后写入 CSV,Python 后端则在需要时通过搜索读取内容,再补充到 prompt 中。
这种机制避免了上下文无节制地膨胀,也让 Agent 在需要“回忆”的时候才去“想起”玩家的历史行为,实现了低成本的记忆系统。
三、结语:不是因为做得到才做,而是因为做了才知道可行¶
这个系统不是为了炫技,也不是为了追热点。
只是为了看看,现实中的边界在哪里,Unity + AI Agent,到底可以做到什么程度。
答案是:可以做到“像人”。
不完美,但已经足够惊人。情感、记忆、理解、调侃、迟疑——这些都可以构建。而最终呈现在玩家面前的,是一个真正意义上“会活的角色”。
这不是未来,而是现在。