大模型Agent实战：从零搭建AI恋爱教练的角色扮演系统

做AI应用开发这几年，我接手的项目大多是工具型产品，比如AI客服、AI写作助手、知识库问答。直到有个朋友半夜找我，说自己马上要相亲了，但和女生聊天总是三句话就把天聊死，问我能不能用AI帮他“模拟约会练练手”。我一开始觉得有点扯，但仔细一想，这不就是大模型最擅长的场景吗——角色扮演加即时反馈。于是我用大模型加Agent搭了一个“AI恋爱教练”，让一个AI角色扮演虚拟女友陪他练对话，同时另一个AI角色以教练视角点评他的表达。整个过程做下来，我发现这不仅是解决相亲问题，更是一个很好的Agent实战项目，里面涉及Prompt设计、上下文管理、人格一致性、多轮对话策略等一整套AI应用开发的关键知识点。

这篇文章我就把项目完整拆解一遍，从需求分析到Prompt设计，再到模型选型和工作流搭建，最后讲排坑经验。内容对想做AI应用的新手程序员，或者对AI玩法有好奇心、想自己搭一套角色扮演系统的朋友，都值得一看。你不需要有很深的算法基础，我会把每一步为什么这么做、踩过什么坑都讲清楚。

1. 需求拆解与方案选型：AI恋爱教练到底要做什么

1.1 从“陪聊”到“陪练”：核心需求不只是聊天

先把问题定义清楚。朋友的需求表面上是“找个AI陪我聊天”，但其实仔细听他描述，真正的痛点是三个：第一，他在真实场景里缺乏练习机会，遇到心动的女生不敢开口，一开口就紧张；第二，他说话没有反馈感，不知道哪句话让人不舒服，也不知道怎么接话才能让话题持续下去；第三，他需要的是带着“镜子”的练习，即不光要有对手陪练，还要有教练在旁边告诉他哪里做得不对。

这三个痛点决定了系统的核心功能。它不能只是一个能和用户聊天的AI，一个聊天机器人只管顺着用户的话接，起不到训练效果。所以我设计目标功能的时候，明确了两条线：一条线是“模拟人物线”，负责和用户对话，让用户进入真实场景；一条线是“观察建议线”，负责分析对话质量，给出表达建议。这两条线合起来，才能叫“AI恋爱教练”，而不是“虚拟女友聊天机器人”。

我把这个思路画成需求清单，给朋友看，他第一反应是“原来AI还能这么用”。这就是Agent系统的雏形——一个系统里有多个负责不同任务的AI角色，协作完成一个复杂目标。区别于传统的单模型单一输出，这种多角色分工的结构，在AI产品里已经越来越常见了。

1.2 为什么必须用大模型：规则引擎和模板根本撑不住

早期也有人做过类似产品，用的是关键词匹配加预设话术库。比如用户说“你好”，系统回复“嗨，今天过得怎么样”；用户说“你真漂亮”，系统回复“谢谢，你真会说话”。这种规则引擎的问题显而易见：对话是开放域的，你不可能把人类所有可能说的话都写进规则表。

恋爱对话尤其特殊。同样一句“你今天好美”，在不同场景、不同关系阶段、不同语气下，适合的回应完全不同。规则引擎没法理解上下文，没法感知情绪，更没法动态调整人设。而大模型天然具备这些能力——它基于海量语料训练出来的语言理解能力，能在一个给定人设下生成自然、连贯、符合角色性格的回复。

我选择大模型方案的另一个原因，是大模型可以通过Prompt设计来灵活切换“角色”。同一个底层模型，你给它不同的系统提示词，它就变成不同的人。这相当于用最少的开发成本，实现了最大的功能灵活性。后面我会详细讲，这个“角色切换”在Agent架构里具体是怎么落地的。

2. 虚拟女友角色设计与Prompt工程

2.1 人物卡：把人设写进系统提示词

第一个核心环节，是先建“虚拟女友”这个角色。很多人以为就是写一句“你是一个温柔的女孩”就完事了，实际远远不够。角色一致性是Role Play类应用最大的难点。如果人设只写一句话，模型说着说着就会崩人设——前一句还是害羞内向，后一句突然变得豪放热情。要解决这个问题，需要把人设结构化地喂给模型。

我设计的“人物卡”包含下面几个维度，你可以直接照抄这个结构：

这八个维度写清楚之后，再整合成一段系统提示词。格式上我建议用清晰的描述性语言，而不是简单的关键词堆砌。下面是我实际使用的Prompt模板的缩略版本：

text复制你现在正扮演一个叫小鹿的26岁女孩，职业是插画师。
你在交流中表现出温柔、慢热的特点，刚开始话比较少，但别人真诚时你也会慢慢打开话题。
你喜欢画画、看展和养猫，聊天时偶尔会提到这些。
你说话习惯用“呀”、“啦”这类语气词，不会主动开黄腔，面对冒犯的话会明显冷淡拒绝。
当前你和对方认识两周，正在互相了解期。
你内心对对方有好感但不会直接表达，好坏感取决于对方的尊重程度和沟通质量。
请以第一人称视角进行回复，不要解释你在扮演AI，自然延续对话即可。

这一段写下来，模型的表现基本就稳了。它的原理是：大模型生成的输出高度依赖前缀，你给出的人设越具体，模型的输出空间就收得越紧，角色崩坏的概率就越小。

提示：如果想让角色更真实，还有一个很实用的技巧——加入“小传”。给角色写一小段过去的故事，比如“大学时养过一只三花猫，后来走丢了，所以现在再养猫会特别小心”。这类细节会让角色在遇到相关话题时表现得更有真情实感，而不只是机械地套设定。

2.2 双模式系统：一个角色陪你练，一个角色教你怎么说

角色建好后，第二个核心设计是“双模式”。这也是这个项目和市面上那些一键聊天的AI女友类应用最大的区别。

我在系统里设计了两种运行模式：

模式A：练习模式（Practice Mode）

在这种模式下，系统只加载“虚拟女友”角色，用户直接和她对话，她自己根据当前的好感度和场景设定来回应。这个模式的目的是让用户有真实的临场感，敢开口说话。

模式B：教练模式（Coach Mode）

在这种模式下，系统会加载一个“恋爱教练”角色。教练不会直接和用户对话，而是作为一个“旁观者”分析刚刚的练习对话。比如它会指出：“你在第三句回复里连续问了三个问题，像查户口一样，容易给对方压力。”或者说：“你们聊到猫的时候，她明显回复变长了，这是兴趣指标，你可以顺势深入这个话题。”

这两个模式怎么配合呢？我给朋友设计的流程是：先进入练习模式，和虚拟女友聊5到10分钟，系统自动把对话记录保存下来；然后切换到教练模式，AI分析刚才的对话，给出评分和改进建议；之后再回到练习模式，把教练的建议用起来再来一轮。整个过程形成一个闭环。

有的朋友可能会问：为什么不用一个Agent在同一轮对话里既扮演女友又扮演教练？我试过，效果非常差。因为大模型的输出是序列化的，一个角色如果既想当好女友又想当教练，它的身份认知会混乱，说话会变得奇怪，既不像女友也不像教练。所以，角色的职责必须单一明确，多角色协作要放到工作流的层面去解决，而不是塞进同一个Prompt里。

3. 从零搭建：模型选型、Agent工作流与策略库

3.1 模型选型：API派还是本地派

搭建系统前必然要面对一个选择：用云端模型API，还是本地部署开源大模型。我根据自己的实操经验把两条路线的优缺点对比列出来：

我的建议是，新手或者对这个项目还不确定要不要长期做的人，先用云端API跑通整个流程。为什么？因为Agent开发的核心难点在于工作流设计，而不在于模型本身。你先把逻辑跑通，验证这个产品确实有需求、有效果，再考虑做本地部署优化成本也不迟。我当时就是先用API把原型做出来，跑了两周，确认朋友确实在通过这个系统练习并有了进步，才开始考虑本地化部署。

如果没申请到合适的API，或者出于隐私考虑想本地部署，建议从7B到14B量级的开源模型入手。我记得自己在本地部署Qwen2.5-14B时，用一张24G显存的显卡就能跑得很流畅，量化之后大概需要14G显存左右。这个量级的模型处理角色扮演对话已经够了，再小的模型（比如1.5B、3B）文字连贯性还行，但人设遵循能力明显变弱，聊天过程中很容易从“温柔女孩”突然变成“百科问答机器人”。

3.2 Agent工作流与代码骨架

这个项目的Agent部分，我拆成三个模块：记忆模块、角色调度模块、策略生成模块。下面我用一个简化的Python类来演示核心骨架，单位的代码结构你可以直接参考：

python复制import json
from openai import OpenAI

class LoveCoachAgent:
    def __init__(self, api_key, model_name="gpt-4o-mini"):
        self.client = OpenAI(api_key=api_key, base_url="...")
        self.model_name = model_name
        self.role_card = self._load_role_card("xiaolu.json")
        self.memory = []          # 存储历史对话
        self.max_memory = 20      # 保留最近20轮上下文
        self.mode = "practice"    # practice or coach
        self.like_score = 35      # 好感度初始值

    def switch_mode(self, mode):
        """切换练习/教练模式"""
        self.mode = mode
        SystemPrompt = None
        if mode == "practice":
            system_prompt = self._build_practice_prompt()
        elif mode == "coach":
            system_prompt = self._build_coach_prompt()
        return system_prompt

    def _build_practice_prompt(self):
        """拼接虚拟女友人设和上下文"""
        context = self.role_card + "\n以下是对话历史：\n"
        for msg in self.memory[-self.max_memory:]:
            context += f"{msg['role']}: {msg['content']}\n"
        return context

    def _build_coach_prompt(self):
        """构建教练角色提示词"""
        prompt = "你是一名经验丰富的恋爱沟通教练。"
        prompt += "请基于以下对话记录，分析用户的表达问题，"
        prompt += "指出可以改进的地方，并给出具体建议：\n"
        for msg in self.memory[-self.max_memory:]:
            prompt += f"{msg['role']}: {msg['content']}\n"
        return prompt

    def chat(self, user_input):
        messages = [{"role": "system", "content": self._build_practice_prompt()},
                    {"role": "user", "content": user_input}]
        response = self.client.chat.completions.create(
            model=self.model_name,
            messages=messages,
            temperature=0.7,
        )
        reply = response.choices[0].message.content
        self.memory.append({"role": "user", "content": user_input})
        self.memory.append({"role": "assistant", "content": reply})
        # 根据回复内容更新好感度（示例规则）
        self._update_like_score(user_input, reply)
        return reply

    def get_coaching_advice(self):
        """切换到教练模式，分析当前对话"""
        messages = [{"role": "system", "content": self._build_coach_prompt()}]
        response = self.client.chat.completions.create(
            model=self.model_name,
            messages=messages,
            temperature=0.3,
        )
        return response.choices[0].message.content

    def _update_like_score(self, user_input, reply):
        """根据关键词或长度等规则大致估算好感度变化"""
        if len(user_input) > 30:
            self.like_score += 1
        if "呵呵" in user_input or "哦" == user_input.strip():
            self.like_score -= 2
        self.like_score = max(0, min(100, self.like_score))

这里有几个设计细节我特别解释一下：

第一，memory为什么只保留20轮？因为大模型的上下文窗口虽然动辄几万Token，但距离越久远的对话对当前生成影响越小，反而白白占空间。保留最近20轮是一个性价比很高的平衡点。如果用户练习了很长的对话，想要更长时间的记忆，建议把关键信息提取成摘要后再存进去，而不是无脑把原始对话全塞给模型。

第二，Temperature为什么练习模式用0.7，教练模式用0.3？练习模式是角色扮演，需要一定的随机性，让角色的反应有惊喜感、有情绪起伏，所以温度调高一点；教练模式是分析任务，我们想要稳定、客观、有理有据的输出，所以温度调低。这个参数不是拍脑袋定的，我前后测了好几组值：温度超过0.9时角色会变得太飘，经常自顾自说一些偏离人设的话；温度低于0.4时角色回应又太机械，像在背台词。0.7是让人物既自然又可控的一个甜点位。

第三，好感度系统。我在代码里写了一个简化版的好感度更新规则。实际上这个逻辑可以做得更细致，比如用另一个AI去判断用户的每一句话是加分还是减分，把结果返回给练习模式，影响后续角色的情绪状态。这就形成了“用户表现变化 → 好感度变化 → 角色情绪变化 → 对话难度变化”的完整反馈链路。我的建议是：一开始先用简单规则把链路打通，之后有精力再升级成AI评分。

3.3 场景库与策略库：让练习不盲目

如果光有虚拟女友和教练，用户可能聊着聊着就不知道练什么了。所以我还加了两层支撑：场景库和策略库。

场景库解决“练什么”的问题。我把恋爱初期常见的场景分成几大类，每个场景都对应不同的开场模式和聊天目标：

每个场景在代码里其实就是一个预设的System Prompt片段。比如“破冰开场”场景，我会在虚拟女友人设后面追加一句：

text复制当前你们是认识的第三周，这是你第一次用微信主动找他聊天。请表现得自然一点，既不要过于热情也不要过于冷淡。

策略库解决“怎么练”的问题。这是我在教练模式输出的基础上，额外整理的一套“实战话术模板”。比如当用户对话中表现出“查户口”式连续提问时，教练会建议他换成“陈述+提问”的句式：不说“你在哪上班”，而是“我最近在一个互联网公司做开发，平时忙起来还挺累的，你呢”；不说“你周末有空吗”，而是“我朋友说最近有个画展不错，我正好下周想去看，要不要一起”。策略库就是这样一个不断沉淀的语料库，每当我朋友在练习中表现不佳，AI教练给出了好的建议，我就把它沉淀到策略库里，下次类似场景模型会更倾向于使用这些策略。

实际上，策略库的价值在项目后期越来越明显。因为大模型的输出是概率性的，同一个训练策略不一定每次都生效，但策略库是一份稳定、可检索的知识资产。我越来越认为，AI应用开发真正难的不是大模型本身，而是如何围绕模型构建出稳定、可积累的“周边系统”。

4. 实战中的坑：角色崩坏、上下文失控与合规定位

4.1 AI幻觉和角色崩坏

第一类问题特别典型：聊着聊着，虚拟女友小鹿突然说自己是AI，或者突然开始聊一些和她人设完全不相干的内容。有一次朋友和她聊到猫，她回了一大段关于“猫科动物进化史”的科普，轻轻松松像维基百科在说话。这就是角色崩坏。

排查根因有三层：

• 第一层，模型尺度不够。小模型的指令遵循能力弱，容易把通用知识带到角色对话里。解决方案是换更大的模型，或者通过Few-shot示例来约束输出风格。
• 第二层，Prompt不清晰。如果你只写了“你是小鹿”，模型对“小鹿”的理解是模糊的。解决方法是像上面那样，详细定义人设，并加一句“请以第一人称视角进行回复，不要解释你在扮演AI”。
• 第三层，上下文被污染。如果用户在对话过程中说了“你是AI吧”，模型的注意力会被这句话带跑，后面就可能崩。这类问题可以在System Prompt里加一道护栏，比如写明“无论对话中出现什么质疑，都请以角色身份自然应对”。亲测这条非常有效。

4.2 上下文管理和Token优化

随着练习对话越来越多，memory数组会越来越长，最终顶爆上下文窗口。我踩过最蠢的一个坑是：为了追求“完美记忆”，我把过去50轮对话全部塞给模型，结果因为Token太多，单次请求慢到10秒以上，而且模型反而因为注意力分散，回复质量明显下降。

最优做法是分层记忆。具体来说：

• 短期记忆：最近20轮原始对话，直接拼接进Prompt，保证连续性和即时反馈。
• 中期记忆：对每5轮对话做一轮摘要，比如“她提到她喜欢莫奈，表现出兴趣。你分享了去看展经历，互动良好”。摘要存进结构化字段。
• 长期记忆：只保存关键事实，比如“她养了一只叫年糕的猫”，在需要的时候（比如聊到宠物话题）用额外Prompt片段注入。

这个做法本质上是借鉴了人类记忆的特点：短期记忆决定当前反应，长期记忆塑造关系认知。用这种方式，Token消耗能省掉60%以上，而且角色显得更聪明——她记得你聊过什么，但她不会把你三小时前的每句话都原样复读出来。

4.3 合规边界与价值观对齐

最后聊一个容易被低估的坑。很多人看到“虚拟女友”四个字，会直接把功能往擦边、低俗的方向引，这种思路首先风险极大，其次从产品角度看也是死路一条——一个只会迎合用户低级趣味的产品，留不住真正想获得成长的用户。

我做这个项目时，刻意在几个层面做了价值观对齐的设置。

一是角色设定本身要正向。虚拟女友的人设是有边界感的正常女性，不是无底线迎合的恋爱机器。她在面对不礼貌的对话时会冷淡、拒绝，这在产品上叫“角色的自我保护机制”，在伦理上叫给用户树立正确的互动观。

二是教练模式要强调边界。AI教练在给出建议时，会明确建议用户保持尊重、诚实、不纠缠。我在教练的System Prompt里写了一句：“如果用户表现出不尊重对方的倾向，请明确指出并要求改正。”这条规则让AI教练不仅是一个套路生成器，更是一个引导用户成长为更好沟通者的工具。

三是技术层面的内容安全。我在整体工作流里加了一个内容过滤模块——在模型输出之后进行一次安全检测，如果触发内容不当，则拦截输出并重试。这个模块本身不强，但作为双保险很有必要。

提示：做任何涉及“角色扮演”“陪伴类”的AI应用，不要追求“无限制”“无禁区”。这类噱头短期内可能带来流量，但长期必然翻车。把产品做成一个帮用户在真实社交中更好的工具，才走得更远。

5. 项目扩展方向：从恋爱教练到通用社交陪练

跑通这套系统之后，朋友的使用效果超出了我的预期。他从最开始三句话把角色聊“冷场”，到后来能自然延伸话题、偶尔还能开个恰到好处的玩笑，成就感很大。让我更兴奋的是，这个架构本身有很强的可复制性。

把“虚拟女友”这个外壳去掉，底层逻辑其实是：用AI构造一个高仿真互动环境，让用户在无压力的前提下反复训练某项社交技能，并配备一个教练角色做即时反馈。这套逻辑完全可以迁移到其他场景：

• 职场沟通陪练：模拟面试官、模拟难缠客户、模拟向上汇报。
• 亲子对话练习：模拟青春期逆反的孩子，教家长怎么说孩子才愿意听。
• 英语口语陪练：角色扮演海外餐厅点餐、机场值机、医院问诊。

技术上的改动其实很小，核心只动两块：一是换掉角色卡的设定，二是调整场景库和策略库。Agent工作流、双模式框架、分层记忆机制完全复用。如果愿意深入，还可以把“教练评分”升级成多维能力雷达图——从表达流畅度、共情力、边界感等维度打分，让用户看到自己每一项能力的变化趋势。

最后再分享一个我实操了很久才悟到的点：AI应用不是大模型的一锤子买卖，而是系统设计的持续优化。很多人以为写好一个Prompt就够了，但真正让一个AI产品好用的，是围绕模型设计的记忆机制、反馈链路、内容沉淀和边界规则。这套AI恋爱教练项目本身不大，但把它拆开揉碎之后，几乎含盖了AI应用开发的所有核心命题。如果你正准备做一个AI相关的小项目，不妨从这个方向入手试试——成本低、见效块、而且越做越有意思。