1. 为什么是英语情景教学Agent从需求到产品定位1.1 看似热闹的AI口语产品其实缺一块拼图先聊一个我自己的真实经历。前年冬天我试着用市面上的AI口语陪练产品练了两个月英语每天跟读十分钟。效果确实有但总觉得哪里不对——练的是点菜问路这种标准对话一到真实场景比如同事临时拉我去参加一个英文会议、或者房东打电话来谈维修脑子还是转不过来。后来我复盘了一下发现这些产品普遍存在三个问题一是对话脚本太固定翻来覆去就那几句二是AI不会根据我的水平动态调整难度三是没有真正解决开口前要想很久这个核心痛点。这三件事恰好是我决定自己做一个英语情景教学Agent的直接动机。市面上不是没有好产品但它们大多把精力花在语音识别和发音打分上对情景的理解其实很浅。所谓情景教学关键在于让用户沉浸在一个具体、连续、有目标感的场景里完成一次真实的沟通任务而不是机械地念完一段对话。1.2 这个Agent到底是什么以及它解决什么问题我定义的英语情景教学Agent是一个基于大语言模型、具备多轮对话能力、能动态生成剧情分支、并提供针对性反馈的在线学习系统。它跟传统口语App的区别在于传统App是人跟着脚本走Agent是脚本跟着人走。具体来说它要做三件事模拟一个真实的互动场景比如机场值机、餐厅投诉、项目汇报、租房谈判由用户扮演场景中的一个角色自主决定说什么、怎么接话会话结束后Agent针对语法、表达准确性、流畅度和情景契合度给出评价和改进建议。这个东西最核心的价值不是替代真人外教而是解决练得少和不敢说的问题。它把练口语的门槛从找个语伴、凑个时间降到了打开App就能演一场戏而且用户不用担心说错丢面子。1.3 目标用户与功能边界我在技术预研阶段先划定了边界不然这个东西会做成一个没有尽头的怪物。核心目标用户有两类一是有一定英语基础、想提升口语流利度的职场人二是备考雅思口语、需要大量情景演练的学生。所以功能重点放在四块场景引导、角色扮演、实时纠错、学习报告。不做什么也很重要。我不做语音识别本身直接调用成熟ASR我不做复杂的发音音素级打分只做可懂度层面的判断我不做真人社交匹配那是另一个产品形态。把边界划清楚以后开发路径就清晰多了核心工作在于剧情引擎和反馈引擎其余环节尽量复用成熟组件。2. 技术选型大模型、框架与整体架构2.1 模型选择的几个考量维度Agent的大脑选择我前后对比了四五款主流大模型。评估维度不是简单的谁聪明而是指令遵循能力、中文理解能力、多轮稳定性、延迟、成本。因为英语教学Agent的输入可能是中英混杂的——用户可能用中文说这个场景我应该怎么回答——所以模型必须兼容中英双语上下文。选型结论是这样的主线教学对话用GPT-4o这个级别的大模型最稳尤其是角色一致性和复杂情景推理但考虑到成本我设计了一个双模型路由方案——日常简单轮次走轻量模型遇到情节转折、深度纠错这种复杂任务再切换到大模型。这个策略实测能把成本压到纯大模型方案的40%左右。2.2 Agent框架为什么我最终自己搭了编排层2024到2025年市面上出现了大量Agent框架早期的LangChain、AutoGen、以及更轻量的Dify甚至字节的Coze。我前期花了整整一周测试这些框架。结论很真实框架解决的是通用Agent问题而我要做的是特定教学闭环硬套框架反而被它的抽象层绊住。比如LangChain的记忆管理对一句话剧情推进这种高频状态切换来说太笨重了。我自己搭了一个极简的事件驱动编排层用户输入 - 意图理解 - 状态更新 - 剧情生成 - 反馈判断。整个过程用异步事件流串起来没有复杂的Chain调用图调试起来非常清晰。2.3 Agent的技术栈全景我最终的技术栈长这样模块选型选型理由主模型GPT-4o / Claude 3.5角色扮演稳定、多轮推理强轻量模型DeepSeek或GLM-4成本低处理简单轮次语音识别WhisperV3 / 字节火山ASR中英混杂场景识别率高语音合成ElevenLabs / Azure TTS声音自然度支持多角色音色Agent编排自研轻量框架贴合教学链路便于定制状态存储Redis PostgreSQL对话状态用Redis长期记录入PG前端Vue3 WebSocket实时流式交互这里有一个关键点值得展开语音链路延迟。用户说一句话到听见AI回应全链路超过3秒教学体验就会明显变差。所以ASR必须用流式接口TTS也选择流式合成模型推理则通过流式输出配合打字机效果三路并行把总延迟压到2秒左右。2.4 为什么用双对话引擎而不是单一Prompt这是我开发到中期踩坑之后做的重构。最开始我把角色扮演、剧情推进、纠错、学习报告全都塞进一个系统Prompt让大模型自己决定什么时候做什么事。结果就是角色扮演好好的突然跳出一段评价或者用户犯了个语法错误AI只顾着推进剧情完全没纠错。拆开之后变成两个引擎剧情引擎只负责沉浸式推进故事以角色身份回应永远不说教反馈引擎一个人智囊团独立分析用户说错的部分、应该怎么改、为什么改。剧情引擎在对话过程中运行反馈引擎在每轮结尾触发一次轻量判断并在整场会话结束后输出完整报告。这个拆法让两个任务的Prompt互不干扰质量直线上升。3. 情景剧本设计从静态Prompt到动态剧情引擎3.1 情景场景库的搭建逻辑情景剧本是这个Agent的灵魂。我一开始犯的错误是试图让模型凭空生成场景——结果生成出来的场景千篇一律全是餐厅点餐。后来我换了一种做法人工建立场景骨架模型在骨架内动态填充血肉。什么是场景骨架它包含几个要素场景名称、用户角色、AI角色、初始目标、核心冲突、可能的发展分支。比如机场转机延误这个场景用户角色是赶转机航班的乘客AI角色是机场地勤。核心冲突是原定航班取消用户必须找到替代方案。我按照生活类、职场类、学术类、旅行类四个大类人工策划了40个骨架每个骨架配3-5个可选的事件触发器——比如机场场景里可能触发突然广播登机口变更护照信息有误行李没跟上等子事件。模型在对话过程中根据用户的反应随机或智能地触发这些事件这样即使同一个骨架用户练十次也不会觉得重复。3.2 Prompt工程的迭代过程情景Prompt的编写我经历了三个阶段。第一阶段是一段话描述完所有要求效果是场景有了但对话很干瘪第二阶段是结构化角色卡规则列表效果好了很多但模型还是会偶尔跳出角色第三阶段是角色卡世界观对话风格样例硬性禁令。目前沉淀下来的角色卡结构大致是这样的你是【角色名】身份是【职业/关系】。 你正处于【场景描述】中当前核心诉求是【角色目标】。 你对用户的态度【友好/紧张/不耐烦/公事公办】。 你的说话风格【简短/话痨/使用俚语/正式】。 你需要遵守 1. 永远不跳出角色不承认你是AI。 2. 每轮回复不超过3句话除非用户明确要求你解释。 3. 当空用户提出关键信息时记住它并在后续对话中引用。 4. 如果用户偏离场景太远温和地把对话拉回主线。 禁区绝不替用户完成他的表达任务。第四条和禁区是踩了无数次坑之后加上的。没有这两个规则模型会变成话痨用户说半句它就帮你说完了那就完全失去了练习意义。3.3 动态分支状态机与概率选择剧情动态化技术上我用了一个轻量的剧情状态机。每个场景的会话过程被分成几个阶段比如开局 - 冲突升级 - 转折 - 收尾。每个阶段挂载若干可能的剧情事件模型根据用户表现选择触发哪个。触发方式我是这么设计的不把全部事件一次性告诉模型而是按状态分组。比如开局阶段只给顺利办理/证件不全/柜台暂停服务三个事件选择当用户用较好的口语应对了开局就触发证件不全这种更高难度的事件。这其实是一个基于用户表现的难度自适应系统。状态切换的判断依据是什么我会让模型在回复中附带一个不可见的JSON状态标记类似{state:conflict_intensified, event: lost_boarding_pass}前端解析标记来更新UI上的当前进度条而后端将这个状态写入Redis用于后续生成反馈报告。3.4 难度自适应的底层逻辑自适应不是玄学本质就是一套评分调参逻辑。我在每轮对话结束后让反馈引擎给用户打四个维度的分语法准确度(0-1)、词汇丰富度(0-1)、流利度(基于ASR的停顿/重复检测)、情景应对度(模型主观评分)。之后这套分数会进入一个简单的规则引擎四维平均分低于0.4下轮降低事件难度比如地勤说话放慢、用简单词平均分高于0.8触发隐藏挑战事件比如突然插入一个电话干扰平均分在0.4-0.8之间保持当前难度但随机微调事件选项。这套机制花了大概两周时间打磨但效果远比让模型自己判断用户水平要可控。模型自己的判断波动太大规则引擎至少保证逻辑可解释、可调参。4. 核心模块实现对话管理、角色扮演与反馈评价4.1 对话管理长短期记忆分离实现过程中对话管理是最容易翻车的地方。市面上很多RAG方案把整个历史记录一股脑塞给模型轮次短还好到第20轮Prompt会爆炸而且模型会忘记前面细节。我采用了一个三级记忆架构短期记忆最近5轮对话原文直接放入上下文剧情记忆一个结构化的JSON记录当前状态、已触发事件、用户角色的关键属性比如用户选的出发地、目的地、时间等长期档案用户的历史学习记录包括常犯的错误类型、最近练习节奏这部分不进入每轮上下文只在生成反馈报告时使用。剧情记忆JSON是一个很关键的工程决策。比如机场场景里用户在第一轮说我的航班号是CA981飞洛杉矶。这个信息如果不单独存到了第8轮模型很可能就忘了。我把它抽取出来存成{flight:CA981, destination:LAX, issue:none}在每一轮构造Prompt时拼接到上下文里。这一个改动让角色一致性的用户评分从6.2分涨到了8.5分。4.2 角色一致性内容过滤与人格锚定角色精分是LLM扮演类应用的通病。我用了两层机制来解决。第一层在系统指令中写了人格锚定语句每轮模型输出前面都会由框架自动注入一句角色内心独白比如地勤角色在用户语气很不耐烦时内心独白是旅客情绪比较激动需要更耐心地解释这帮助模型稳定在当前角色视角。第二层是输出内容的硬约束模型返回值必须是JSON包住的{dialogue: 角色说的话, inner_thought: ..., state_update: {...}}。通过结构化约束防止模型在角色话术里插入作为AI之类的破墙台词。一旦检测到dialogue中包含作为一个语言模型或我无法之类的教学口吻后端会重试生成一次。4.3 练习意图识别与动态干预用户的意图不只是扮演角色他还会问这里我不太会能不能给我提示或者直接说用中文告诉我应该怎么回答。我在编排层加了意图分类器用一个小模型或者正则关键词兜底识别用户输入属于哪一类继续角色扮演、请求帮助、请求翻译、脱离场景闲聊、要求更换话题。这个分类器的结果决定请求交给哪个引擎处理。这个模块的引入背景是一次真实翻车用户说等等我不知道该说什么结果剧情引擎一本正经地用角色语气回应您可以在值机柜台办理登机手续完全无视用户的求助信号。后来一旦识别到请求帮助就会切换到教学模式由反馈引擎生成一段思路提示示例句型关键词汇然后再回到剧情引擎继续扮演。这个体验细节非常影响留存率用户卡壳时能不能得到温柔接管直接决定他会不会继续用下去。4.4 反馈生成从挑错到教练式反馈最开始的反馈设计走偏了以为用户需要的就是一堆红叉和语法批改。测试发现用户看到满屏错误会挫败有的人直接卸载。后来参考语言学习理论里的情感过滤假说把反馈改成了三层结构第一层肯定亮点。先是具体夸奖比如你在表达航班变更时用了result in搭配很地道第二层分级纠错。按严重程度分三类影响理解的硬伤必须改、明显但不影响理解的错误建议改、优化空间随意第三层替代表达。提供两种以上更自然的说法并说明使用情境。还有一个细节反馈不能只看单句语法还要看情景契合度。我让反馈引擎结合当前剧情状态判断比如用户在机场角色扮演里说了一句很地道的商务英语语法没错但在这个情景里显得突兀——反馈会指出这个表达更适合会议室在机场你可以更直接一些。这个维度是情景教学Agent相对传统口语App的差异点。5. 评估体系不靠感觉靠数据驱动迭代5.1 评测集构建做Agent最怕的就是自己觉得好用。我花了很大精力建了一套评测集包含三个层次。第一层是情景完整性测试每个场景跑一遍完整会话检查开始、转折、收尾三个阶段是否都有正常推进有没有卡死在某个状态。自动化测试通过35个场景骨架各跑3遍产出105条会话记录。第二层是行为规范测试检查每轮AI回复是否遵守了不跳出角色不超过三句话不替用户说话等硬指标用规则人工抽检完成。第三层是用户表现评估招募8名不同英语水平的内测用户每人跑完5个场景后填深度问卷从压迫感有趣度帮助价值自然度四个维度打分。这一层最花时间但最有价值。5.2 失败模式与修复记录以下几类失败是我在整个开发中高频出现的直接列出来供参考失败现象根因修复方案AI帮用户把话说完剧情引擎接到用户卡壳输入出于助人本能补全增加意图分类器卡壳时切换教学模式剧情引擎强制等待角色前后矛盾称呼都变了上下文过长导致模型遗忘引入剧情记忆JSON每轮更新关键属性反馈报告千篇一律反馈引擎依赖单轮local判断缺少全局信息反馈引擎整合长期档案完整会话记录用摘要树压缩中英混杂识别率低用户说中文ASR识别成英文再丢给模型ASR中英双语模式Prompt内明示可用中文求助用户故意调戏场景模型认真接梗剧情崩坏增加离题兜底规则两次离题后由地勤有礼貌地结束对话5.3 技术债与成本的平衡大模型项目的成本控制是个绕不开的话题。我的实测数据一个完整10轮左右的场景练习如果全部用GPT-4o成本大约0.35美元做了双模型路由后降到0.12-0.15美元。成本优化还有两个小技巧。第一个是Prompt精简把不必要的装饰性文字去掉上下文能少100个token累计下来省5%-8%成本。第二个是缓存策略同一场景骨架的静态部分场景描述、角色卡、初始Prompt按版本缓存不重复计入输入token。对于可能被反复练习的高频场景这个优化收益很可观。我个人不太建议为了省成本去硬套一个明显能力不足的小模型。教学场景里一次生硬的回复流失用户的成本远高于省下的几分钱。关键是精准路由让每一分钱花在刀刃上。6. 上线后的迭代方向Agent发展的下一站6.1 语音交互的延迟优化目前整个链路在4G网络下平均延迟2.3秒5G或Wi-Fi环境下可以压到1.8秒。下一步的计划是引入端侧轻量模型做首轮意图预判在用户还没说完时就预生成部分回复候选等ASR结果确认后直接无缝衔接。这个方案参考了语音助手的early decision思路预计能把感知延迟降到1秒以内。6.2 多模态教学信号还有一个更长远的方向是把视觉信号加进来。比如用户扮演在餐厅向服务员描述一道菜的口感时Agent如果能看到用户的表情和手势就能给出更丰富的反馈。这个对硬件和带宽要求都不低但教学价值很高——毕竟真实交流中非语言信息占比很大。目前我还在评估方案优先考虑的是简化版——从WebRTC视频流截帧做表情识别。6.3 数据飞轮与个性化内容的生产不能一直靠人工。我计划引入一个社区场景创作机制用户提交自己遇到的真实交流场景Agent自动加工成结构化骨架由其他用户测试投票高的进入正式场景库。这就是数据飞轮的雏形——使用的人越多场景越真实场景越真实使用的人越多。个性化方面下一步要做的是错题驱动的内容推荐用户在反馈报告里暴露的弱点会有针对性地推荐下一个练习场景。比如数值型语法错误频繁推荐购物砍价房租谈判这类数字表达密集的场景。踩过这么多坑之后我最大的体会是做一个英语情景教学Agent60%的精力不在AI技术上而在内容设计和用户体验细节上。模型能力已经足够强了关键是怎么把它驯化成可靠的教学角色。如果你的目标也是做一个自己的Agent建议想清楚一句话的答案你做的Agent让用户的哪种体验发生了本质变化想不清楚这个技术再花哨也立不住。