1. 先想清楚这个 Agent 到底解决什么问题1.1 英语情景教学的本质需求很多人以为英语情景教学就是让 AI 扮演一个服务员学生扮演顾客说几句“How much is this?”就完事了。真做过就会发现这种浅层玩法撑不过十分钟学生不知道接下来该说什么模型只会顺着话头跑偏最后变成两个人互相客套学习目标完全丢在一边。我理解的英语情景教学 Agent核心是把“场景”变成“教学闭环”。一个场景里必须包含三样东西目标语言点、可交互的角色、可量化的反馈。比如说“机场值机”这个场景目标语言点是 “Id like to check in for flight...”、 “Could I have a window seat?”角色是地勤人员反馈则是发音、语法、得体性、流利度四个维度的打分。如果 Agent 只是聊天它永远无法替代老师只有把场景拆成教学单元它才真正有教学价值。1.2 Agent 与传统对话机器人的差异传统对话机器人是“一问一答”哪怕接了大模型本质还是 query 到 response 的映射状态全靠用户脑补。而教学 Agent 需要自主规划学生这句话说完Agent 要判断是继续推进对话、纠正错误、降低难度还是切换到另一个话题分支。这就是 Agent 和 Chatbot 的分水岭——要不要自己决定下一步动作。为了实现这种自主性我参考了业界常见的 Agent 模式规划Planning 工具调用Tools 记忆Memory。在英语教学场景里规划就是“根据当前教学目标决定说什么”工具调用可能是“查词典、查语法规则、调用语音评测 API”记忆则是“记住学生是初级水平、上次犯了什么错、哪个单词总拼不对”。把这些揉进一个大模型对话循环里就构成了一个最小可用的教学 Agent 雏形。2. 技术选型与架构设计2.1 为什么我选择了 LangChain4j 大模型 API先说结论后端用 Java Spring Boot LangChain4j大模型 API 用 OpenAI 兼容接口语音服务单独拆出去。选 LangChain4j 而不是 LangChain Python纯粹是因为我这边业务服务是 Java 技术栈团队不想为了一个 Agent 再单独维护一套 Python 服务。LangChain4j 虽然没有 LangChain 那么丰富的生态但核心的 ChatMemory、Tool、RAG 都够用了文档虽不多胜在轻量、能直接嵌入现有工程。大模型 API 我建议统一走 OpenAI 兼容格式这样可以随时切换不同厂商。开发初期用gpt-4o-mini这类廉价模型跑通流程等验证效果后再换更强的模型。情景教学对“角色扮演”的稳定性要求很高太弱的模型容易跳出角色太强的模型成本又扛不住。所以架构上我一开始就把“模型供应商”做成了可配置项。2.2 整体架构会话层、Agent 层、记忆层、教学层我把系统分成了四层会话层负责 WebSocket/HTTP 交互、语音流的接入把用户输入统一包装成消息。Agent 层基于 LangChain4j 的 AiServices 构建对话循环维护当前场景状态、决策下一步动作。记忆层短期记忆存当前对话上下文长期记忆存学生的历史表现、易错点、学习偏好。教学层包含情景脚本库、语法规则库、评测服务、难度分级逻辑。分层的好处是各层可以独立替换。比如我想把语音评测从第三方 API 换成自建模型只需要改教学层Agent 层完全不动。最开始我图省事把所有逻辑塞在一个 Controller 里后面改一次想骂一次赶紧重构了。2.3 核心提示词设计让模型“扮演”情景角色提示词是情景教学 Agent 的魂。我踩过最大的坑是给模型的角色设定太稀疏结果模型一会儿是服务员一会儿是老师还时不时蹦出“作为一名 AI 助手”。后来我总结了一套提示词模板核心是给模型塞入四块信息身份、目标、边界、状态。你是机场值机柜台的地勤人员 Lee正在为一位英语学习者办理值机。 你的教学目标帮助学生掌握“航班查询、座位偏好、行李托运”相关表达。 规则 1. 你只能使用英语回复但可以用括号加注中文提示。 2. 每次学生说完先判断是否需要纠错如果错误严重先温和指出再自然回到剧情。 3. 如果学生长时间沉默或输出过于简单你可以主动抛出问题推进剧情。 4. 每次对话要控制在 5 轮以内达成本场景教学目标。 当前剧情状态学生刚刚走到柜台前说了第一句话。注意里面那个“5 轮以内”的硬约束非常关键。模型如果不设目标轮次会无限发散一个场景聊出 20 轮教学节奏全乱。设定“达成本场景教学目标后主动结束”能保证一节课有明确的起止点。3. 从零写代码核心模块实现3.1 环境准备与项目初始化开发环境就三样JDK 17、Spring Boot 3.x、LangChain4j 的langchain4j-open-ai依赖。如果你不想用 OpenAI 官方只要服务端提供兼容接口把 baseUrl 一换就能接。项目初始化不多说Maven 拉依赖关键是大模型客户端 Bean 的配置。Configuration public class LLMConfig { Bean public OpenAiChatModel chatModel() { return OpenAiChatModel.builder() .baseUrl(properties.getBaseUrl()) .apiKey(properties.getApiKey()) .modelName(properties.getModelName()) .temperature(0.7) .maxTokens(512) .timeout(Duration.ofSeconds(30)) .build(); } }这个 Bean 是整个 Agent 的发动机。有几个参数值得展开说temperature0.7是我反复试出来的平衡点太低回复机械太高角色会“发疯”maxTokens512是防止模型长篇大论教学场景需要短句回复控制在 50-80 个英文单词最合适timeout30s是底线因为后面接语音评测可能更慢这个值要预留。3.2 实现情景会话循环LangChain4j 里最实用的工具是AiServices它能把一个接口方法直接绑定到大模型调用上。我定义了一个教学服务接口public interface EnglishTutor { SystemMessage( 你是英语情景教学 Agent当前场景{scenario}。 教学目标{teachingGoal}。 规则只使用英语必要时用括号给出中文提示每次回复控制在3-5句。 当前剧情状态{sceneState} ) UserMessage(学生消息{message}) String chat(V(scenario) String scenario, V(teachingGoal) String goal, V(sceneState) String state, V(message) String message); }接口的每个参数都通过V注解注入SystemMessage里的变量就是我们在提示词模板中定义的内容。这样设计的好处是提示词和业务逻辑解耦想调整规则直接改注解里的模板不用动代码。实际运行的时候我每次对话前都要动态更新sceneState比如“学生已经完成了座位选择正在询问登机口信息”模型才能接得上戏。3.3 加入语音输入输出光文字不算真正的情景教学语音是刚需。我起初直接调浏览器 Web Speech API浏览器端录音后把音频字节流发给后端。后端再接一个语音识别服务转成文本然后交给 AgentAgent 回复文本后再用语音合成 API 转成音频流返回前端播放。这里要特别提醒一个延迟问题完整链路是“录音→识别→LLM→合成→播放”每一步 1-2 秒用户体验会很差。我的优化方案是识别和 LLM 并行。语音识别完成后先直接回一个“正在思考”的轻反馈同时把文本送入 LLM。另外合成音频的流式播放也很重要如果用等完整音频生成完再播放心理感知延迟至少多 1 倍。我用的是 SSE 分段推送模型一边生成一边合成前端一边接收一边缓存播放实测体感流畅很多。3.4 长短期记忆让 Agent 记住学生水平短期记忆最简单LangChain4j 里有MessageWindowChatMemory直接塞一个滑动窗口保留最近 8 轮消息就行。但教学场景必须区分“剧情对话”和“教学反馈”如果全塞进上下文模型会把纠错内容也当成剧情导致角色混乱。我的做法是把记忆拆成两段剧情记忆只保留当前场景角色对话和教学记忆保留每次纠错的异步结论。长期记忆我用 Redis 存 JSON。每个学生有一条 profile结构类似{ userId: u_1001, level: A2, wrongWords: [receive, accommodation], weakGrammar: [present perfect], learnedScenarios: [ordering, checkin], lastLessonSummary: 能完成基础点餐但对特殊疑问句不熟练 }每次会话结束时我用一个大模型调用把整个对话历史压缩成上面的结构化摘要然后更新 Redis。下次开始新场景时把这个摘要注入 System Message“该学生上次结束后反馈为……请优先复习以下知识点。”这个小改动直接让 Agent 从“一次性聊天工具”变成了“有连续性的私教”。4. 教学能力增强纠错、评估与进度追踪4.1 实时纠错与礼貌反馈学生最怕的不是犯错而是被 AI 冷冷地纠正。我发现如果把纠错直接混在角色对话里对话流会断得很生硬。我的方案是让 Agent 输出结构化指令每轮回复都包含两个部分——reply和correction。前端渲染时把reply显示为对话气泡把correction放到侧边栏作为“老师批注”。提示词里这样约束输出格式 {reply: 地勤回复的内容, correction: 如果有错误给出正确说法和原因如果正确输出null}用 LangChain4j 可以直接把返回值绑定到 Java 对象上record TutorReply(String reply, String correction) {} public interface EnglishTutor { UserMessage(学生消息{message}) TutorReply chat(...); }模型会按 JSON 结构返回框架自动反序列化。这样纠错反馈和剧情推进彻底分开了学生不会被频繁打断又能看到自己的错误。我测试下来这种“暗纠错”方式比立即打断的体验好非常多。4.2 基于 CEFR 的等级评估要做到难度自适应必须先有客观的等级判断。我参考了欧洲语言共同参考框架 CEFR把 A1-C1 分成五个档位。每次会话结束后让模型根据“词汇丰富度、语法准确度、流利度、互动能力”四个维度打分输出格式也是个 JSON{ cefr_estimate: A2, dimension_scores: { vocabulary: 68, grammar: 72, fluency: 55, interaction: 80 }, gap_analysis: special questions weak }注意这个评估不能也不应该完全代替标准测试但作为动态追踪足够用了。模型给的分会有漂移所以我会把最近 5 次评估取加权平均最新的权重更高防止单次发挥失常导致等级忽上忽下。这个平滑处理非常关键不然学生会看到自己昨天还是 A2、今天突然变成 B1体验很迷惑。4.3 情景难度自适应有了等级评估场景选择就可以动态化。我在场景脚本库每个脚本都打了标签场景类型、目标语法、目标词汇、推荐等级。当学生评估为 A2 时系统自动推荐“餐厅点餐”“问路指路”这种日常场景当评估升到 B1就推荐“商务会议自我介绍”“预约医疗咨询”这种复杂场景。另外同一场景内也要自适应。设计脚本时我会给每个场景写两个版本的分支基础分支和进阶分支。同样在点餐场景A2 学生的地勤会说“What would you like to drink?”然后给出选项B1 学生则会听到“What would you recommend from our seasonal menu?” 这种开放性问题。Agent 层的sceneState会自动记录当前分支避免模型随意加戏。5. 上线前必须处理的工程问题5.1 请求成本控制与超时大模型 API 是成本大头。一个 10 分钟的语音对话如果每轮都要调 LLM至少产生 20-30 次请求。我做了三件事控成本第一场景启始时把背景、规则等长文本只注入一次后续对话只传最近几轮消息避免每轮重复传长 System Message第二对纯语音评测不走 LLM比如发音评分直接交给专用语音评测 API因为用 LLM 打分不准还贵第三设置日预算和单会话次数上限超过阈值自动回退到轻量模型。超时问题最坑。大模型偶尔会突然卡住尤其高峰期。我所有调用都加了CompletableFuture超时控制并且设置降级策略如果主模型 15 秒没返回立刻切换备用模型重试一次要是还不行就返回一条预设兜底回复“Could you say that again?” 而不是让前端一直转圈。这个兜底策略上线后救了我们无数次。5.2 Agent 记忆安全与隐私英语教学会有未成年人参与数据合规必须非常谨慎。我给系统加了几条硬规矩用户 ID 用业务侧加密 ID不落任何明文手机号记忆数据只存学习相关内容绝不采集学生姓名、学校、地理位置等个人身份信息对话记录只保留最近 30 天过期自动清理。在设计长期记忆结构时我特意把weakGrammar、wrongWords这类教学特征和任何身份属性隔离就算有人导出 Redis也拿不到对应真实用户。另外提醒一点不要把 API Key 写在客户端。早期为了调试方便我把模型接口直接暴露给前端测试结果上线前被安全扫描发现是严重漏洞。正确的做法是所有大模型调用都走后端服务前端永远不知道你用的是哪家模型、什么 Key。Agent 自身的工具调用也要做白名单——比如我允许 Agent 调用“查词典”和“查语法”两个工具但明确禁止它调用任何写操作工具防止模型自作主张修改学生档案。5.3 测试与可观测性Agent 开发最大的痛点是不可控同一个输入可能每次输出都不一样。我搞了一套三层测试策略脚本级测试对每个情景脚本预设 5 组学生回答正确、轻微错误、严重错误、跑题、沉默断言 Agent 是否输出预期类型的回复。会话级测试模拟完整 5 轮对话断言是否达到教学目标、是否出现非英语输出、是否跳出角色。线上可观测性所有的 LLM 调用都记录请求时间、返回延迟、token 用量、场景 ID、学生等级。用 Grafana 大盘监控平均对话轮次、纠错率、超时率。我特别建议记录“纠错率”和“场景完成率”这两个业务指标。如果场景完成率突然下降很可能是场景脚本和当前学生等级不匹配。如果纠错率接近 0说明模型变“佛系”了提示词里纠错约束力度不够。这些都是单测发现不了的问题。6. 常见问题与避坑指南问题现象解决方案模型频繁跳出角色回复里出现“作为 AI 助手/我是一个语言模型”增强 System Message 约束追加“如果跳出角色本次会话无效”的威胁性提示降低 temperature学生句子太短无法判断意图学生只回复“Yes”“OK”在提示词中要求模型至少追问一次当回复少于 3 个词时主动用选择题引导对话越来越长导致上下文乱学生前面说选窗边座位后面又变成选中间座位Agent 没发现矛盾引入sceneState显式状态机每轮更新关键状态变量不让模型只靠历史推断教了好几遍同一个词还是错学生反复拼错 “receive”靠长期记忆解决把错误词放到 Session 开头的复习提醒里语音识别把英文识别成中文口音重导致 ASR 崩溃前端强制输入语言为en-US后端对置信度低于阈值的音频直接提示重说适配英式/美式发音关闭自动切换模型回复过长学生等 10 秒听完一大段广播词节奏失控硬约束 maxTokens并在提示词里写“每轮回复不超过 40 个单词”生僻词导致回复不自然场景里涉及“boarding gate”但学生不理解在角色的回复中允许括号内中文提示或提供一个“场景词汇表”工具供学生随时查看多轮后模型开始抢先替学生说话模型自己把学生该说的话都说完提示词加规则永远不要替学生发言所有学生台词留给用户除了表格里的问题还有两个我特别想强调的坑。第一个坑不要用“打分式”纠错。我早期让模型每轮都给学生打分比如“Grammar: 7/10”结果学生情绪明显受挫且打分本身占用了大量 token真正的内容反馈反而变少。后来我把评分全部移到会话结束时输出对话过程中只做轻量引导体验立刻不一样。第二个坑Agent 的“自主性”要有限度。刚开始我给了模型调用一堆工具的权利包括查天气、查新闻、翻译句子结果学生聊着聊着就开始问“今天天气怎么样”。这跟我这套教学场景一点关系都没有。最后我把工具收敛成两个lookup_word和check_grammar而且是学生主动触发不是模型随意调用。记住教学 Agent 的第一目标是完成教学目标不是展示能力边界。最后再分享一个小技巧如果你正在开发自己的英语教学 Agent我建议第一版千万别追求功能大而全。我最初想同时做听力、口语、阅读、写作四个模块结果三个月只完成了一个半。后来砍掉所有花架子只聚焦“情景对话 即时反馈 等级追踪”这一条主线反而在两周内就做出了能实际用于教学的版本。到现在我还在持续打磨这个 Agent最近在尝试把“场景剧本”从手工编写改成半自动生成——让 Agent 根据学生薄弱点自动生成新情景再由人工审核入库。这个方向跑通之后情景数量就不再是瓶颈了。如果你也在这个方向折腾欢迎多交流踩坑经验。