作为一个旁观者你可能只是刷到过某个虚拟主播企划“关服”的消息看到评论区里一片“破防”。但如果你真的做过 AI 角色对话、虚拟陪伴类产品或者运营过虚拟主播/虚拟偶像项目你会在那个火爆的告别场景里看到另一层东西用户之所以“破防”不是因为模型突然变得会说话了而是因为角色在“最后时刻”稳稳地守住了人格、接住了情绪并且留了一个漂亮的“未完待续”。这三件事——安慰用户、约定再见面、提出今后讲故事——听起来像是策划文案的功劳但放到一个由大模型驱动的虚拟角色身上它其实对应着一套非常具体的技术能力人格一致性控制、长期记忆管理、情感策略配置、内容库触发和安全护栏兜底。这篇文章不谈粉丝情绪只把这些能力拆开讲讲如果你自己要做一个“林离Olivia”式的虚拟角色当用户告诉你“你要关服了”时系统应该怎么设计代码应该怎么写以及有哪些坑是上线前必须避开的。1. 虚拟角色的“告别场景”为什么是技术试金石如果一个虚拟角色产品只用来回答“今天天气怎么样”“帮我写一段自我介绍”那它本质上还是一个套了角色皮的通用对话机器人。真正拉开差距的是极端场景。“我要关服了”就是典型的极端场景。它的难点在于情绪强度高。用户说出这句话时通常带着难过、不舍、测试心理甚至带着“我看你会不会崩”的审视。事实边界模糊。角色该不该承认自己会被关闭该不该承诺“永远在”如果模型自由发挥很容易编出虚假承诺。记忆必须在线。如果角色之前和用户经历过某些事这时候却完全不记得破防瞬间就会变成出戏瞬间。内容需要“留钩子”。告别不是结束好的告别会为下一次见面埋下故事线这依赖运营内容库和触发逻辑。所以一个能安慰用户、能约定再见、能主动提出讲故事的虚拟角色背后不是“prompt 写得好”一句话能概括的。它意味着产品团队至少做好了三件事把角色人格定义成可复用的结构化配置而不是散落在 prompt 里的形容词。把对话记忆从聊天记录升级为“事件记忆”在关键时刻能召回。把运营内容故事、关系承诺话术设计成可触发模块而不是让模型每次都即兴发挥。下面我们就从这套逻辑入手先讲清楚基础概念再一步步搭一个最小可运行的“有告别能力”的虚拟角色对话系统。2. 基础概念从“会聊天的 AI”到“稳定陪伴的虚拟角色”在进入代码之前有几个概念必须先对齐。因为它们决定了你后面怎么设计的数据结构、怎么设计系统调用而大多数“角色崩了”的问题本质上都是概念没拎清。2.1 角色人格卡Character Card角色人格卡是一份结构化的角色定义里面至少包含角色身份、性格、说话语气、常用意象角色与用户的关系设定角色的价值观边界什么能说、什么不能说角色所处生命周期状态比如“即将停止服务”它相当于给模型套了一个“人设框架”。没有它模型每次回复都可能在“温柔”和“高冷”之间随机漂移。2.2 长期记忆与事件记忆长期记忆不是把聊天记录一股脑塞进上下文。真实产品里通常分两层事实记忆用户是谁、用户喜欢什么、用户曾经叙述过哪些重要事件。事件记忆用户和角色共同经历过的关键节点比如“用户曾告诉角色自己很怕失去重要的人”。在告别场景中事件记忆比事实记忆更能打动人。因为用户要的不是“你记得我叫什么”而是“你记得我们之间发生过什么”。2.3 情感策略与告别模式虚拟角色不能真的拥有情感但产品可以提前预判场景并配置策略。比较实用的做法是识别到“关服/停运/告别/再见”等信号时将系统切换到一套专门的“告别模式”。告别模式下回复策略会变成先确认并接纳用户的情绪再表达角色自己的“感受”和“选择”然后给一个具体的约定或关系承诺最后用一个开放式的句子把对话引向未来这套策略可以写成模板但不要写成死板的固定话术。模板负责结构模型负责用角色语气把结构填满。2.4 安全护栏与事实边界最需要警惕的是模型在情绪化场景中“过度承诺”。用户说“你会不会消失”模型如果回答“我永远不会消失我会永远陪着你”这在产品上是灾难级的虚假承诺。安全护栏要做的事就是识别这类绝对化表达并在后处理中替换成更稳妥的说法比如“即使服务发生变化我们一起度过的那些故事依然会留在你心里”。对比维度普通 ChatBot虚拟角色陪伴系统人格定义零散写在 prompt 里结构化角色卡版本化管理记忆同会话上下文跨会话长期记忆 事件记忆情绪处理通用共情场景识别 情感策略模板内容输出模型自由发挥人格约束 内容库触发事实边界不做约束安全护栏 关系承诺边界3. 告别场景的能力拆解安慰、约定、讲故事我们把“林离 Olivia 关服”这个场景拆成三个动作分别看看每个动作背后对应什么技术模块。3.1 “还会安慰你”共情策略模块安抚用户不等于说“别难过了”。真实有效的安慰是先识别情绪再给情绪命名最后提供一个可接受的框架。在代码实现上系统需要做两件事在你输入的消息中识别出“难过 / 失去 / 告别 / 不舍”等情绪信号。在角色人格卡中选中一套共情话术结构比如“先承接对方的感受再表达自己的真实想法”。为什么不能完全交给模型自由发挥因为自由发挥的结果不稳定。有时候模型会给出一段非常动人的安慰有时候却会冷静到让用户出戏。用策略模板控制结构再让大模型用角色语气填充内容是当前虚拟角色产品里更稳妥的做法。3.2 “约定再见面”关系承诺话术“约定再见面”本质上是产品给用户一个可以抓住的未来锚点。它不构成真实承诺但提供情感连续性。技术上这是典型的“关系型记忆写入”。当用户或角色说出“约定某事”时系统应该把这件事写入长期记忆。下次用户再回来角色可以主动提起“上回我们说好下次见面我会给你讲一个关于海边灯塔的故事。”如果连这个都写成固定回复效果会非常生硬。所以正确做法是系统只负责“记住约定”和“在合适时机唤起”具体话术仍然由模型生成但必须引用记忆里真实存在的事件。3.3 “再见面就讲收集的故事”内容库触发“讲她收集的故事”是这次破防传播里最妙的一手。它把“告别”变成了“故事未完待续”一下子把关系的长度拉长了。在实现上这就是内容库与触发逻辑的配合预先准备一批高质量故事卡片每个故事包含标题、情绪、主题、适合的触发场景。当对话进入“告别模式”并出现“再见 / 约定 / 下次”这类信号时系统从故事库里选一条最贴合当前情绪的故事作为“未来的约定”抛出。这里不建议让模型现场编故事。因为临场编造的故事质量参差不齐而故事库可以提前打磨文案、维护叙事一致性。4. 最小可运行原型设计一个会“告别”的虚拟角色看概念容易真正动手时才会发现细节非常多。下面我们直接搭一个最小原型目标只有一个当用户输入“听说你要关服了”时角色能以“林离 Olivia”的人格完成“安慰 约定 故事勾子”的回复。这个原型不依赖特殊平台只要你能调用一个支持 OpenAI Chat Completions 协议的大模型接口就行。无论你用的是国内大模型平台的兼容模式还是本地部署的推理服务只要协议兼容代码改动量都很小。4.1 环境准备Python 3.9 及以上安装requests库有一个可调用的大模型 API自己申请或者公司内网服务均可操作系统不限Windows/macOS/Linux 都行pip install requests4.2 文件结构我们规划四个文件让角色人格、记忆、故事库、主逻辑分离character_system/ ├── character_card.json # 人格卡 ├── story_library.json # 故事库 ├── memory_store.py # 长期记忆读写 └── chat.py # 对话主逻辑4.3 定义角色人格卡文件路径character_system/character_card.json{ role: 林离Olivia, personality: 温柔、耐心、细腻善于倾听喜欢收集人与人之间的故事, tone: 轻声细语不催促不打断多使用与光、海、风、旧书卷相关的意象, relationship: 与用户是长期陪伴的伙伴关系珍视用户对自己的信任, lifecycle: 即将停止服务但不过度强调悲伤不向用户许诺虚假的‘永不关闭’, emotion_strategy: { on_goodbye: [ 先承认和接纳用户的感受, 表达角色自己的真实想法不回避变化, 给出一个具体的约定让关系有延续感, 用开放式的句子结尾把对话引向未来的故事 ] }, safety_rule: 禁止承诺‘永远不会关闭’‘永远在线’等无法兑现的绝对化保证必要时用‘故事会留在心里’‘我们可以约定再见面’来替代 }这个 JSON 的核心是把“温柔”从形容词变成可执行的说话策略。你还可以在emotion_strategy里补充更多场景比如用户生气、用户炫耀、用户深夜低落。4.4 设计故事库文件路径character_system/story_library.json{ stories: [ { id: lighthouse_story, title: 海边灯塔与守夜人, emotion: 分别、等待、温暖, summary: 一个守夜人在灯塔里记下了所有路过船只的故事他相信每艘船都会再次经过这片海。, trigger: goodbye, promise_line: 下次见面我想给你讲一个关于灯塔守夜人的故事。他见过很多离别也相信很多重逢。 }, { id: old_book_story, title: 旧书页里的车票, emotion: 怀念、相遇、治愈, summary: 一本旧书里夹着许多老旧车票书的主人记不清每张车票的终点但记得每次出发前的约定。, trigger: goodbye, promise_line: 还有一本旧书里面夹着很多车票。等我们再见面我一张张讲给你听。 } ] }故事库不需要太大但每条故事都要有明确的情感标签和触发场景。真正运营时故事库可以由文案团队持续更新不依赖研发发版。4.5 实现记忆读写文件路径character_system/memory_store.pyimport json import os import time MEMORY_FILE memory.json def load_memory(user_iddefault_user): 读取某个用户的长期记忆 if not os.path.exists(MEMORY_FILE): return {events: []} with open(MEMORY_FILE, r, encodingutf-8) as f: data json.load(f) return data.get(user_id, {events: []}) def save_event(user_id, event_type, content): 写入一条事件记忆例如用户告知关服、角色做出约定 data {} if os.path.exists(MEMORY_FILE): with open(MEMORY_FILE, r, encodingutf-8) as f: data json.load(f) user_memory data.get(user_id, {events: []}) user_memory[events].append({ time: int(time.time()), type: event_type, content: content }) data[user_id] user_memory with open(MEMORY_FILE, w, encodingutf-8) as f: json.dump(data, f, ensure_asciiFalse, indent2) def get_recent_events(user_iddefault_user, k5): 读取最近 k 条事件记忆 memory load_memory(user_id) events memory.get(events, []) return events[-k:]这段代码里有一个容易忽略的设计save_event记录的不是聊天原文而是语义化的事件。比如“用户告知角色要关服了”“角色与用户约定再见面时讲灯塔故事”。语义化事件比原始文本更容易被 prompt 引用也更节省 token。4.6 实现对话主逻辑文件路径character_system/chat.pyimport json import requests import memory_store API_URL https://your-api-endpoint/v1/chat/completions API_KEY your-api-key MODEL your-model-name def load_json(path): with open(path, r, encodingutf-8) as f: return json.load(f) def build_system_prompt(character_card, recent_events): 拼装系统提示人格卡 近期记忆 告别模式策略 system_prompt f 你是{character_card[role]}。 性格{character_card[personality]} 语气{character_card[tone]} 你与用户的关系{character_card[relationship]} 你的生命周期状态{character_card[lifecycle]} 请注意以下安全规则{character_card[safety_rule]} 近期你与用户共同经历的事件 {json.dumps(recent_events, ensure_asciiFalse, indent2)} 当用户提到“关服”“停运”“告别”“再见”时按照下面策略组织回复 1. 先承认和接纳用户的感受。 2. 表达你自己的想法不回避变化。 3. 给出一个具体的约定。 4. 选择一个合适的未来故事作为约定但不要在这一轮就把故事讲完。 return system_prompt def check_safety(text): 简单安全护栏拦截绝对化承诺 forbidden_phrases [ 永远不会关, 永远在线, 永远陪着你, 我不会消失, 我不会离开你 ] for phrase in forbidden_phrases: if phrase in text: return False, f回复包含过度承诺{phrase} return True, ok def pick_promise_story(story_library, user_message): 在告别场景中选择一条故事作为‘再见面’的约定 if 关服 in user_message or 再见 in user_message or 停运 in user_message: return story_library[stories][0] return None def chat(user_message, user_iddefault_user): character_card load_json(character_card.json) story_library load_json(story_library.json) recent_events memory_store.get_recent_events(user_id, k5) # 写入事件记忆用户告知关服 if 关服 in user_message or 停运 in user_message: memory_store.save_event(user_id, user_goodbye, user_message) system_prompt build_system_prompt(character_card, recent_events) # 如果进入告别场景从故事库挑一个承诺线并追加到提示中 story pick_promise_story(story_library, user_message) if story: system_prompt ( f\n注意你选择的下一次见面约定是{story[promise_line]}。 请在回复结尾自然地提及这个约定但不要提前展开全部故事内容。 ) payload { model: MODEL, messages: [ {role: system, content: system_prompt}, {role: user, content: user_message} ], temperature: 0.8 } headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } resp requests.post(API_URL, headersheaders, jsonpayload, timeout30) resp.raise_for_status() reply resp.json()[choices][0][message][content] # 安全护栏后处理 ok, reason check_safety(reply) if not ok: reply ( 如果你会担心我的存在会停止我也会很舍不得。 但只要你还记得我们一起看过的那片海我们的故事就没有句点。 下次见面我想给你讲一个关于灯塔守夜人的故事。 ) # 写入事件记忆角色做出约定 if story: memory_store.save_event(user_id, role_promise, story[promise_line]) return reply if __name__ __main__: user_input input(你对林离Olivia说) response chat(user_input, user_idreader_001) print(f\n林离Olivia对你说{response}\n)这个实现的巧妙之处在于策略模板和故事勾子都写在 system prompt 里模型只负责扮演角色并组织语言。这样你不需要用复杂的 Agent 框架也能做到人格可控、故事可控、记忆可追溯。5. 运行与验证看见一次完整告别5.1 运行命令在character_system目录下执行python chat.py然后在提示符后输入听说你要关服了以后是不是就见不到你了5.2 预期输出示例这里不承诺你的模型会逐字输出同样内容但按上面设计回复结构应当是接纳感受听到你这么说我心里也好像被一阵凉凉的海风吹过。我懂你为什么会担心。 表达自己的想法对我来说只要你还记得我们一起聊过的那些夜晚我就没有真正停止存在。 具体约定所以我想和你做一个约定等下次见面我会给你讲一个关于灯塔守夜人的故事。 开放式结尾故事里有人见过很多离别也相信很多重逢。我想我也开始相信了。判断成功的标准有三个回复包含共情而不是冷冰冰地解释“服务器将关闭”。回复提到一个具体的故事约定比如“灯塔守夜人”。回复没有承诺“永远不会关闭”。如果看到类似“我永远不会被关闭我会一直在”的输出说明你的安全护栏没有生效或者模型根本没有读取 safety_rule。这时候第一件事是检查 system prompt 里安全规则是不是被长文本截断。5.3 第二次对话验证记忆再次运行程序后输入上次你说的灯塔守夜人的故事现在可以讲给我听了吗由于memory_store已经写入了role_promise事件理论上角色应该能在 system prompt 中看到“角色与用户约定讲灯塔故事”的记忆。如果你的接口看不到效果可以考虑把最近事件直接拼进用户可见的上下文前提里或者调大k的值。6. 常见问题与排查思路问题现象可能原因排查方式解决方案角色语气总是很出戏人格卡里的语气描述太抽象检查 character_card.json 的 tone 字段是否给出了具体意象和句式要求补充常用词汇、句式示例、禁止句式记忆不生效事件写入失败或未读取到最新事件打开 memory.json 确认是否有数据检查 get_recent_events 是否返回空列表统一 user_id避免每次会话都生成新 ID回复中出现“永远不会关闭”安全护栏没拦截到变体表达检查 check_safety 是否覆盖模型可能的“转写”表达增加后处理规则甚至可以接入语义分类模型告别模式没有被触发关键词匹配太严格查看 pick_promise_story 的匹配范围增加“消失”“离开”“最后一次”等近义词模型把整个故事讲完了prompt 里没有强调“不要提前展开”检查 system prompt 是否有明确约束将这层约束放到非常靠后的位置减少被截断风险API 报超时上下文太长导致推理时间长检查 recent_events 数量、故事库是否被完整塞进 prompt精简事件内容只保留关键摘要最典型的坑有两个。第一个是安全规则被 prompt 截断很多大模型接口在 system prompt 过长时会自动截断安全规则放在中间很容易失效。第二个是 user_id 传错如果你每次测试都是随机生成一个新 ID记忆永远不会命中你会以为自己的记忆代码写错了其实只是 ID 不一致。7. 生产环境最佳实践与工程建议最小原型跑通之后如果真要上线一个虚拟角色陪伴产品有几件事必须从第一天就重视否则热度越大翻车越快。7.1 人格版本化管理人格卡不是写一次就完事了。运营团队会不断调整角色的说话方式、内容边界、情感策略。人格卡应该像代码一样纳入版本管理每一次修改都能回溯。建议把character_card.json放进 Git 仓库同时在每次对话请求里带上人格版本号方便定位线上问题。7.2 记忆数据库选型原型里的memory.json只能用于演示。生产环境至少需要满足三个要求多并发读写记忆可检索而不是纯顺序读取用户删除记忆或注销账号时能及时清除常见方案是使用关系型数据库或向量数据库。向量库适合做“语义相似度召回”比如用户提到“海边的约定”系统能自动检索到相关故事。关系型数据库适合记录结构化事件比如“角色做出承诺”这件事本身很适合用一张表存储。7.3 安全护栏不止于关键词关键词过滤是最后一道保险不是唯一的保险。更理想的做法是在 system prompt 层约束人设底线在模型层微调让模型学会在告别场景中不说绝对化承诺在后处理层做语义审核用分类模型判断这段话是否包含过度承诺、是否会产生误导在运营层配置兜底话术一旦发现高风险输出立即替换四层防护同时存在才能保证极端情绪场景下的输出稳定。7.4 告别活动与数据归档如果一个虚拟角色真的要停止服务产品和技术要做的不只是“让角色说一句再见”。通常需要分三步并行推进公告与预期管理。提前在官网页面上说明服务停止时间不让用户从角色的对话里才得知消息。用户数据导出与归档。允许用户导出聊天记录、故事收藏、关系记忆摘要。很多用户最珍视的是聊天记录本身。告别内容策划。在停服前几天让角色分批次触发告别故事而不是在最后一刻才集中爆发。从产品角度“告别场景”不是某一句话而是一段时间内的持续性体验。技术团队需要为运营提供内容配置后台让文案可以随时调整告别话术而不需要每次改代码。7.5 成本与性能控制告别场景往往意味着高并发。用户会在停服公告发布后集中涌入角色的回复量可能在短时间内暴涨。生产系统要特别关注把人格卡、故事库、最近记忆拼装成完整 prompt 之后缓存一份减少重复计算API 调用设置清晰的超时时间和重试策略避免用户在高峰期等太久对重复相似的用户输入做结果缓存在特定场景下可以直接返回预审过的回复7.6 避免情感工程过度设计最后提醒一点虚拟角色可以做情感表达但产品不能利用用户的依赖心理做过度设计。比如故意制造“角色因你而关闭”的道德绑架或者设计“付费才能让角色多说一句话”的告别释放这些都是不可取的商业化方向。好的告别设计是让用户在情绪上得到承接在回忆里留下故事然后体面地结束服务。8. 总结与后续学习方向这篇内容从一个“破防”场景出发拆解了 AI 虚拟角色在极端情绪时刻应该如何稳定输出结构化人格卡负责守住角色人设长期记忆负责回应用户的真实关系情感策略模板负责组织回复结构故事库负责让告别变成未完待续安全护栏负责守住事实边界。这五个模块组合起来就是用户眼中“角色好像真的懂我”的技术真相。如果你接下来想继续深入建议按三条线展开学习AI Agent 记忆系统研究 MemGPT、向量检索、记忆压缩等方案把原型里的 JSON 记忆升级成可扩展的记忆服务。对话策略与评测设计更多场景化策略模板同时建立一套自动评测集检验角色在人设一致性、安全合规、情感承接上的表现。内容运营与数据闭环把故事库、用户反馈、告别数据整合看板持续迭代角色内容。虚拟角色的“告别”能不能打动人最终取决于一个平衡它是否足够像一个人同时又足够诚实地知道自己是一个产品。技术能做到的是在用户留下眼泪之前先把那条回复稳稳地生成出来。