Heart Heart Heart

1. Prelude

今天的大语言模型已经很擅长聊天。给模型一段角色设定和一些历史消息，我们很容易得到一个能够自然交流、模仿语气，甚至表现出特定性格的聊天机器人。

但一个真正长期存在的“角色”，不应该只存在于一次模型调用里。

它应该记得过去发生过什么，保持相对稳定的人格，并让过去的经历影响未来的行为。它也不应该只会生成文字：当它答应提醒用户、查询信息或执行任务时，背后应该有真实的系统行为。

随着能力增加，另一个问题也会出现：当 Agent 做出一个决定时，我们能否知道它当时看到了什么、记起了什么、调用了什么工具，以及状态如何发生变化？

本题希望你围绕这些问题，设计并实现一个具有持续状态、人格、记忆和行动能力的智能角色 Agent。

你不需要完成一个完整产品，也不需要把所有模块做到 Production Ready。请根据时间选择最值得验证的设计，并完成足以证明核心思路可行的实现。

2. 基本假设

技术选型没有限制。

你可以使用云端或本地模型，也可以自由选择编程语言、Agent Framework、数据库、游戏引擎和第三方服务。

与题目重点关系不大的模块，可以直接使用成熟方案，也可以 Mock。语音识别、语音合成、Live2D、3D Avatar、搜索服务等能力都不要求自行实现。

评价重点不是“从零实现了多少组件”，而是各个组件是否形成了合理的系统。

3. Lv1：成为一个持续存在的角色

Lv1 关注三个基本问题：对话连续性、人格和情绪状态。

Agent 应该能够进行正常的多轮交流。过去的对话需要以某种方式影响之后的回答。随着历史不断增长，你需要考虑上下文如何被保留、压缩、筛选或重新组织，但具体方法不限。

角色也应该具有相对稳定的身份和行为方式。这里的“稳定”并不意味着角色永远不能改变。关系、经历和长期互动都可能让角色发生变化。我们希望看到的是一种可以解释的连续性，而不是每次调用都重新生成一个人格。

除此之外，Agent 还应该拥有某种可观察的情绪或内部状态。它不应该只依赖一句“请表现得开心一点”的 Prompt，而应该存在能够被更新、读取，并实际影响之后回复或行为的状态。

Lv1 的核心目标很简单：证明这个角色不是一个完全无状态的文本生成器。

4. Lv2：拥有过去，也能够行动

Lv2 是本题的主体。

如果 Lv1 解决的是“这个角色是谁”，那么 Lv2 需要进一步解决两个问题：“它经历过什么？”以及“它能够做什么？”

4.1 Memory

大语言模型本身并不会天然拥有跨会话的长期记忆。因此，你需要设计一个独立于当前上下文的记忆系统。

这里的重点不是简单保存聊天记录，而是思考什么应该成为记忆，以及什么时候应该重新想起它。

长期事实、用户偏好、过去的事件、关系变化和 Agent 自己的经历，可能具有不同的性质。不同记忆也可能过期、冲突、被修正，或者随着新信息而发生变化。

你不需要建立复杂的分类体系，但应该意识到：Memory 是一个信息生命周期系统，而不仅仅是一个 Vector Database。

除了“记住”，还需要考虑“忘记”和“更新”。当新信息与旧信息矛盾时，系统应该有某种处理方式；当用户明确要求忘记某件事情时，也应该能够产生实际效果。

同样重要的是回忆。随着记忆越来越多，Agent 不可能在每次交互中读取全部历史。系统需要根据当前上下文选择值得重新进入思考的记忆。

具体可以使用关键词、Embedding、数据库查询、图结构、模型判断，或者其他任何方式。

我们真正关注的是：角色的过去是否能够以合理的方式影响未来。

4.2 Action

Agent 不应该永远停留在“生成一段文字”。

它至少需要具备一种对话之外的行动能力，例如调用外部服务、查询信息、运行程序、操作文件、创建任务，或者与其他系统交互。

具体工具并不重要。重要的是 Agent 能够判断什么时候仅仅需要回答，什么时候应该采取行动，并根据行动结果继续完成任务。

系统还应该能够区分“说自己做了某件事”和“真正执行了某个行为”。

换句话说：语言输出和系统行为应该是两个可以区分的概念。

你可以采用 Tool Calling、Action Model、状态机，或者任何你认为合适的设计。

5. 可观测性与审计

当 Agent 开始拥有长期记忆和外部行动以后，调试会迅速变得困难。

如果它引用了一条错误的记忆，调用了不合适的工具，或者出现了异常行为，仅仅保存聊天记录通常不足以定位问题。

因此，系统应该提供某种行为记录机制。

你应该能够在一次交互之后，大致回答这些问题：

• Agent 使用了哪些上下文和记忆；
• 内部状态是否发生变化；
• 是否调用了工具，以及输入和结果是什么；
• 最终产生了什么语言或行为。

具体的数据模型没有限制。日志、事件流、SQLite、JSONL、Tracing 系统都可以。

重点不是做一个完整的 Observability Platform，而是让系统能够回答：刚才究竟发生了什么？

如果还能进一步解释某个决策为什么发生，会更有价值。

Lv2 最终应该形成一个完整的数据流：历史信息能够形成记忆，记忆能够在未来被重新使用，Agent 能够执行真实行动，而这些过程又能够被观察和分析。

这些能力不应该只是几个互不相关的 Demo。

6. Lv3：如果 Agent 有了身体

Lv3 是可选方向。

你可以使用 Live2D、3D Avatar，或者其他能够持续展示角色形象的形式。

重点不在模型精度、动画数量或者画面效果，而在于：Agent 的内部状态能否通过身体表现出来。

例如，情绪、思考、说话、等待、执行工具等状态，都可以影响角色的表情或动作。

这些表现不需要实时生成。预先制作少量动画或表情完全可以接受。

我们关注的是 Avatar 是否真正成为 Agent 状态的一种输出，而不是一个独立播放动画的前端组件。

7. Lv4：实时交流

Lv4 同样是可选方向。

你可以尝试让 Agent 通过语音、Avatar 或其他媒介进行更加实时的互动。

最基本的语音能力包括语音输入和语音输出。可以直接使用现有的语音识别和语音合成服务。

如果系统已经拥有情绪状态，可以进一步思考这些状态是否应该影响声音。例如语速、停顿、音高、风格或者其他语音特征。

Lv4 还需要实现至少一种实时互动形式。

这里我们只保留一个明确要求：从用户提交输入，到 Agent 出现第一个用户可感知的反馈，不应超过 10 秒。

这里的“反馈”不一定是完整回答。角色进入思考状态、开始播放语音、显示任务进度，都可以算作反馈。

我们鼓励 Streaming 和渐进式响应，因为真实交互系统中的延迟，不仅取决于任务什么时候完成，也取决于用户什么时候能够意识到系统已经开始处理。

8. 开放问题

本题没有唯一正确的架构。

在设计过程中，你可能需要自己回答很多问题。

人格应该主要存在于 Prompt 中，还是应该成为显式状态？Agent 是否应该拥有关于自己的记忆？用户与 Agent 的关系是否需要建模？

事实、推断和经历是否应该使用不同的记忆策略？错误记忆如何修正？旧记忆什么时候失效？

工具产生的结果是否值得进入长期记忆？具有副作用的操作是否应该要求确认？行动失败是否应该影响角色状态？

如果工具需要长时间执行，角色应该如何表现？如果用户打断 Agent，系统应该如何处理？

这些问题没有标准答案。

我们更关心你如何定义问题、做出取舍，并解释自己的设计。

Appendix A. Glossary

本表面向没有 Agent、人工智能或相关工程经验的读者。

解释有意进行了简化。如果某个概念与你的方案有关，可以通过对应的 Learn more 继续了解。

AI 与 Agent

API、工具与行为

记忆与数据

调试、日志与审计

工程与项目范围

虚拟形象与 3D

语音与实时交互

如果只想先看最重要的词

第一次阅读题目时，不需要先学完上面的全部内容。

建议先理解下面这些词：

Agent → LLM → Prompt → Context → State → Memory → Tool → Action → API → Audit → Streaming

理解这几个概念以后，已经足够开始思考 Lv1 和 Lv2 的方案。Live2D、WebGL、ASR、TTS 等词汇，可以在决定挑战 Lv3 或 Lv4 后再学习。