1. 为什么我决定自己动手做一个英语学习智能体

去年年底，一个做教培的朋友找我聊，说他们机构想搞个“AI 英语陪练”，找外包报价从八万到三十万不等，功能清单写得天花乱坠，但核心诉求其实就三条：能陪学生练口语、能纠正语法错误、能根据学生水平动态调整难度。我当时的第一反应是——这三件事，用现成的智能体框架加上一套精心设计的提示词工程，两三个人的小团队两周就能跑出原型，根本不需要那么高的预算。

这个判断不是拍脑袋来的。我自己从 2023 年开始陆续做过几个智能体项目，有客服方向的，有知识库问答方向的，也帮朋友搭过考公刷题的辅助工具。踩过的坑多了，慢慢摸清楚一件事：智能体开发真正的难点从来不在“接大模型”这一步，而在于怎么把业务逻辑拆解成模型能稳定执行的指令流，以及怎么设计反馈闭环让它在真实使用中越用越准。英语教育这个场景尤其典型，因为它同时涉及语音识别、语义理解、错误诊断、难度调控四个环节，任何一个环节掉链子，用户体验就会断崖式下跌。

所以这篇内容，我想把“AI 英语教育智能体”从零到一的完整开发过程拆开来讲。不是那种“调个 API 就完事”的浅层教程，而是把我实际做下来觉得真正关键的设计决策、参数选择、踩坑记录都摊开说。适合两类人看：一类是有一定编程基础、想自己动手做一个垂直领域智能体的开发者；另一类是不写代码但想搞清楚智能体到底怎么落地、值不值得投入的产品或教研人员。我会尽量用大白话把技术逻辑讲清楚，代码部分只放最核心的片段，重点放在“为什么这么设计”上。

2. 整体架构设计与技术选型思路

2.1 英语教育智能体的核心能力拆解

在动手写第一行代码之前，我习惯先把一个智能体需要具备的能力列成一张表，然后逐条问自己：这个能力是模型原生就有的，还是需要我额外搭建工程来补足的？这个区分特别重要，因为很多人做智能体失败，就是把本该工程解决的问题硬塞给模型，或者反过来把模型擅长的事用规则写死。

对于英语教育智能体，我拆出来的核心能力有四项：

• 语音输入与识别：学生说英语，系统要能准确转成文本。这件事模型本身做不了，必须接语音识别服务。
• 语法与用词诊断：识别出学生表达中的错误，并给出修改建议。这是大模型比较擅长的，但需要精心设计提示词来约束输出格式。
• 对话管理与难度调控：根据学生水平动态调整对话内容的词汇难度和句式复杂度。这需要工程层面的状态管理。
• 学习反馈与进度追踪：记录学生的常见错误类型，生成阶段性报告。这需要数据存储和简单的统计分析。

把这四项列清楚之后，技术选型的轮廓就出来了。语音识别用现成的云服务，对话和诊断用大模型，状态管理和数据存储自己写，整体架构就是一个“前端采集 + 后端编排 + 模型推理 + 数据沉淀”的四层结构。

2.2 平台化智能体与代码化智能体的选择逻辑

这里要回应一个很多人问过我的问题：用扣子这类平台搭智能体和用 Python 自己写，到底有什么区别？我两个都深度用过，说点实在的。

平台化方案的优势在于上手快、可视化编排、内置了知识库和插件市场。如果你只是做一个简单的问答机器人，或者想快速验证一个想法，平台方案一两个小时就能出东西。但它的局限也很明显：对话状态的精细控制很难做，复杂的条件分支和循环逻辑表达起来很别扭，而且当你想接入自己的语音识别服务或者做深度的数据埋点时，平台往往不给你这个口子。

代码化方案（我用的是 Python + FastAPI）前期搭建慢一些，但胜在完全可控。我可以自己决定什么时候调用模型、什么时候查数据库、什么时候触发难度调整逻辑。对于英语教育这种需要精细追踪学生每一个错误、并且要根据历史数据动态调整教学策略的场景，代码化方案是更合适的选择。

我的建议是：用平台做原型验证，用代码做正式产品。先用平台快速搭一个能跑的 demo，拿去给目标用户试用，收集反馈，确认核心交互流程没问题之后，再用代码重写。这样既不会在需求不明确的时候过度投入工程，也不会在产品化阶段被平台的能力边界卡住。

2.3 模型选型与成本控制

模型选型这块，我试过好几个主流的大模型 API。对于英语教育场景，我的选择标准排序是这样的：指令遵循能力 > 英文语法理解深度 > 响应速度 > 价格。为什么把指令遵循放在第一位？因为教育场景对输出格式的稳定性要求极高。我需要模型每次都按照“错误类型 + 原句 + 修改建议 + 解释”这个固定结构返回结果，如果模型自由发挥，前端解析就会崩掉。

实际测试下来，GPT-4 级别的模型在语法诊断的准确率上明显优于小模型，但成本也高出一大截。我的折中方案是：对话生成用中等模型，语法诊断用高精度模型。因为对话生成对创造性的要求不高，中等模型完全够用；但语法诊断一旦出错，会直接误导学生，这个钱不能省。

成本估算方面，一个学生每天练习 20 分钟，大约产生 30 轮对话，每轮对话消耗约 500 token，加上语法诊断的额外调用，一天下来单个学生的 token 消耗在 2 万左右。按中等模型的定价，一个学生一个月的模型成本大概在几块钱人民币。这个成本对于教育机构来说完全可以接受。

3. 核心模块的详细设计与实操要点

3.1 语音识别模块的接入与优化

语音识别是整个链路的第一环，也是最容易被低估的一环。我一开始图省事，直接用了浏览器自带的 Web Speech API，结果发现两个致命问题：一是对非母语口音的识别准确率惨不忍睹，学生把“think”读成“sink”，它直接识别成“sink”，导致后面的语法诊断完全跑偏；二是网络波动时经常断连，体验很差。

后来换成了专业的语音识别服务，准确率提升明显，但也不是接上就完事。这里有几个实操要点：

采样率的选择。大多数语音识别服务推荐 16kHz 采样率，但如果你用的是浏览器录音，默认可能是 44.1kHz。我试过直接传 44.1kHz 的音频，识别准确率反而下降，因为服务端会做重采样，过程中可能引入失真。所以我在前端录音时就强制指定 16kHz，代码如下：

const stream = await navigator.mediaDevices.getUserMedia({ audio: { sampleRate: 16000, channelCount: 1, echoCancellation: true, noiseSuppression: true } });

静音检测与断句。学生说英语时经常会有停顿思考，如果一停顿就切断，会把一个完整的句子拆成好几段。我的做法是在前端做一个简单的能量检测，当音量低于阈值持续 1.5 秒才认为一句话结束。这个阈值需要根据实际环境调整，安静房间和嘈杂教室的设置完全不同。

口音适配。如果你的目标用户主要是中国学生，建议在语音识别服务的参数里指定语言模型为“英语（中国口音）”或者类似选项。我实测下来，这个设置能把识别准确率提升 10 到 15 个百分点，尤其是对“th”和“s”不分、“v”和“w”不分这类典型问题改善明显。

3.2 语法诊断提示词的设计与迭代

语法诊断是英语教育智能体的核心价值所在。我前后迭代了七八版提示词，才找到一个既准确又稳定的方案。这里把关键设计思路分享出来。

第一版提示词我写得很简单：“请检查以下英语句子的语法错误并给出修改建议。”结果模型经常过度纠正，把一些口语化的表达也改成了书面语，学生看了很困惑。比如学生说“I wanna go”，模型改成“I want to go”，虽然语法上没错，但口语练习场景下这种纠正反而会打击学生的表达欲望。

第二版我加了约束：“只纠正真正的语法错误，不要改变口语化表达。”但模型对“什么是真正的语法错误”理解不一致，有时候漏纠，有时候还是过度纠正。

最终版我采用了结构化输出的方式，把诊断任务拆成几个明确的子任务，并且给出了具体的错误分类标准。提示词的核心结构是这样的：

你是一位英语教学专家，正在分析学生的口语表达。请按以下步骤处理： 1. 判断句子是否存在语法错误（时态、主谓一致、冠词、介词、单复数） 2. 判断是否存在用词不当（词义误用、搭配错误） 3. 判断是否存在中式英语表达 对于每个错误，输出格式必须为： - 错误类型：[时态/主谓一致/冠词/介词/单复数/用词/中式表达] - 原句片段：[错误部分] - 修改建议：[正确表达] - 简要解释：[一句话说明原因] 如果没有错误，输出：无错误。

这个提示词的关键改进在于：把“判断有没有错”和“判断是什么类型的错”分开，并且给出了具体的错误类型清单。这样一来，模型的输出稳定性大幅提升，前端解析成功率从最初的 70% 左右提升到了 95% 以上。

还有一个细节：我在提示词里明确要求“简要解释”控制在一句话以内。因为实际使用中发现，模型如果展开解释，会写一大段语法规则，学生根本没耐心看。一句话的解释既点明了原因，又不会造成信息过载。

3.3 对话难度动态调控的实现

难度调控这个功能，是我觉得最能体现“智能体”和“普通聊天机器人”区别的地方。普通聊天机器人你问什么它答什么，难度是固定的。而英语教育智能体需要做到：学生水平高，它就说得复杂一些；学生水平低，它就说得简单一些。

我的实现方案是维护一个“学生能力画像”，包含三个维度：词汇量估计、语法准确率、平均句长。每次对话结束后，根据学生的表现更新这三个指标，然后在下一次对话生成时，把画像数据注入到提示词里。

具体来说，词汇量估计用的是“生词触发率”——如果学生在对话中频繁使用某个难度的词汇，说明他的词汇量在这个水平以上。语法准确率直接来自语法诊断模块的统计。平均句长则是简单的文本统计。

提示词里注入画像的方式是这样的：

当前学生的能力画像： - 估计词汇量：3000 词左右 - 语法准确率：75% - 平均句长：8 词 请根据以上画像调整你的回复： - 使用的词汇应控制在 3000 词以内，可以偶尔引入 3500 词级别的新词并附带解释 - 句式以简单句和并列句为主，偶尔使用简单的复合句 - 语速相关建议：正常语速

这里有个坑我踩过：画像更新不能太频繁。一开始我每轮对话都更新画像，结果学生偶尔说了一个复杂句，系统立刻把难度调高，下一轮学生就跟不上了。后来改成每 5 轮对话更新一次，并且设置了变化幅度上限（单次调整不超过 10%），稳定性好了很多。

3.4 数据存储与学习报告生成

数据存储这块，我用的是 PostgreSQL，主要存三张表：学生信息表、对话记录表、错误统计表。对话记录表存每一轮的原始文本和诊断结果，错误统计表按错误类型聚合，方便生成报告。

学习报告的生成逻辑不复杂，就是按周或按月做一次聚合查询，统计各类错误的发生频率变化趋势。但有一个细节值得说：报告里不要只列错误，还要列进步。我最初版本的报告全是“你本周犯了 X 次时态错误”，学生看了很受打击。后来改成“你本周的时态错误比上周减少了 30%，进步明显”，同时附上仍然需要加强的项目，接受度就高多了。

报告生成用的是一个单独的提示词，把统计数据喂给模型，让它用鼓励性的语言组织成一段话。这里的关键是给模型一个明确的语气指令：“以鼓励为主，先肯定进步，再指出需要改进的地方，语气像一位耐心的老师。”

4. 完整开发流程与关键环节实现

4.1 环境搭建与项目结构

我的开发环境是 Ubuntu 22.04，Python 3.11，用 Poetry 管理依赖。项目结构大致如下：

english-tutor-agent/ ├── app/ │ ├── main.py # FastAPI 入口 │ ├── config.py # 配置管理 │ ├── routers/ │ │ ├── conversation.py # 对话接口 │ │ └── report.py # 报告接口 │ ├── services/ │ │ ├── asr.py # 语音识别服务 │ │ ├── llm.py # 大模型调用封装 │ │ ├── diagnosis.py # 语法诊断 │ │ └── profile.py # 学生画像管理 │ ├── models/ │ │ └── database.py # 数据库模型 │ └── prompts/ │ ├── conversation.txt # 对话生成提示词 │ └── diagnosis.txt # 诊断提示词 ├── tests/ ├── pyproject.toml └── docker-compose.yml

把提示词单独放在文件里而不是硬编码在代码中，是我强烈建议的做法。因为提示词需要反复迭代，放在独立文件里改起来方便，也便于做版本管理。我甚至给提示词文件加了简单的版本号注释，每次修改都记录改了什么、为什么改。

4.2 对话接口的完整实现

对话接口是整个系统的核心，它需要串联语音识别、语法诊断、对话生成、画像更新四个环节。我用 FastAPI 写了一个异步接口，核心逻辑如下：

@router.post("/conversation/turn") async def conversation_turn( audio: UploadFile, student_id: str, session_id: str ): # 1. 语音识别 audio_bytes = await audio.read() text = await asr_service.recognize(audio_bytes) # 2. 语法诊断 diagnosis = await diagnosis_service.analyze(text) # 3. 获取学生画像 profile = await profile_service.get_profile(student_id) # 4. 生成对话回复 reply = await llm_service.generate_reply( student_input=text, diagnosis=diagnosis, profile=profile, session_history=await get_session_history(session_id) ) # 5. 更新画像（每5轮更新一次） turn_count = await get_turn_count(session_id) if turn_count % 5 == 0: await profile_service.update_profile(student_id, diagnosis) # 6. 存储记录 await save_conversation_record(student_id, session_id, text, diagnosis, reply) return { "student_text": text, "diagnosis": diagnosis, "reply": reply }

这个接口有几个设计决策值得说明。第一，语法诊断和对话生成是分开调用的。我试过用一个提示词同时完成诊断和回复，结果模型经常顾此失彼，要么诊断不准确，要么回复质量下降。分开调用虽然多了一次 API 请求，但两个环节的质量都更有保障。

第二，画像更新是异步的。更新画像需要查数据库、做统计计算，如果同步执行会拖慢接口响应速度。我把它放到后台任务里，学生感知不到这个延迟。

第三，session_history 只保留最近 10 轮对话。因为大模型的上下文窗口有限，而且太长的历史记录反而会干扰模型对当前对话的判断。10 轮是我实测下来比较合适的值，既能保持对话连贯性，又不会让模型“分心”。

4.3 语音识别的流式处理优化

前面说的是一次性上传音频再识别，但实际使用中，学生说完一句话要等两三秒才能看到识别结果，体验不够流畅。后来我改成了流式识别：前端一边录音一边把音频分片传给后端，后端实时返回识别结果。

流式识别的实现稍微复杂一些，需要用到 WebSocket。核心逻辑是前端每 200 毫秒发送一个音频分片，后端累积到一定长度后调用识别服务，把结果推回前端。这样学生说完话的瞬间，识别结果就已经显示出来了。

这里有个参数需要调优：分片大小。分片太小（比如 50 毫秒），请求太频繁，服务端压力大；分片太大（比如 1 秒），延迟明显。我实测下来 200 到 300 毫秒是比较好的平衡点。

4.4 难度调控的边界处理

难度调控逻辑在实现时，有几个边界情况需要特别处理。第一种是学生水平突然波动。比如一个平时水平中等的学生，某天状态特别好，连续说了几个复杂句。如果不加限制，系统会把难度调得很高，第二天学生状态回落就跟不上了。我的处理方式是设置“难度上限”，单次调整幅度不超过当前难度的 15%，并且连续三次表现优异才触发一次调整。

第二种是新生入学。新学生没有历史数据，画像维度全是空的。我的做法是先用一个默认的中等难度开始对话，前 5 轮作为“校准期”，快速收集数据建立初始画像。校准期的对话内容我特意设计得覆盖面广一些，包含不同时态、不同句式，以便更快地评估学生水平。

第三种是长时间未使用。如果一个学生两周没来练习，他的画像可能已经不准了。我的处理是设置一个“衰减因子”，超过 7 天未使用，画像的置信度降低，系统会倾向于回到中等难度重新校准。

5. 常见问题排查与避坑经验实录

5.1 语音识别准确率突然下降

这个问题我遇到过两次，表现是之前用得好好的，某天开始识别准确率明显下降。第一次排查了半天代码，最后发现是录音设备的采样率设置被浏览器更新后重置了。第二次是网络问题，音频分片在传输过程中丢失，导致识别服务收到的音频不完整。

排查这类问题的思路是：先确认输入是否正常，再怀疑处理逻辑。我后来在代码里加了一个音频质量检查环节，如果检测到采样率不对或者音频长度异常，直接返回错误提示，而不是硬着头皮去识别。这样至少能快速定位问题出在采集端还是识别端。

5.2 模型输出格式不稳定的处理

即使提示词写得很明确，模型偶尔还是会“自由发挥”，比如该输出 JSON 的时候输出了一段自然语言。我的处理方式是双重保险：第一层是在提示词里强调格式要求，并且给出示例；第二层是在代码里做解析容错，如果 JSON 解析失败，尝试用正则表达式提取关键字段，再失败就返回一个默认的错误提示，而不是让整个接口崩掉。

下面是我常用的一个容错解析函数：

def parse_diagnosis_response(raw_text: str) -> dict: try: return json.loads(raw_text) except json.JSONDecodeError: # 尝试提取 JSON 块 match = re.search(r'\{.*\}', raw_text, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass # 兜底：返回空诊断 return {"errors": [], "raw": raw_text}

这个函数看起来简单，但实际运行中帮我挡掉了大约 5% 的格式异常，避免了大量前端报错。

5.3 对话内容重复的问题

做了几周之后，有学生反馈说“感觉机器人翻来覆去就那几句话”。我查了对话记录，发现模型在生成回复时确实倾向于使用一些高频句式，比如“That's interesting! Can you tell me more about it?”。

解决这个问题的方法是在提示词里加入“多样性指令”，明确要求模型避免重复使用最近 5 轮出现过的句式。同时我在代码里做了一个简单的重复检测，如果新生成的回复和最近 3 轮中任何一轮的相似度超过 80%，就重新生成一次。

5.4 常见问题速查表

5.5 几个我踩过的坑

坑一：过早优化。我一开始就想着要做多轮对话、要做情感分析、要做发音评分，结果每个功能都做了一半，核心的语法诊断反而没打磨好。后来砍掉了发音评分和情感分析，专注把语法诊断和难度调控做扎实，用户体验反而更好了。

坑二：忽视冷启动体验。新学生第一次使用时，系统对他一无所知，如果直接开始对话，难度很可能不匹配。我后来加了一个简单的水平测试环节，用 5 道选择题快速评估学生水平，作为初始画像的输入。这个改动让新学生的首次体验好了很多。

坑三：没有做降级方案。有一次大模型 API 服务出现波动，整个系统直接不可用。后来我加了一个降级逻辑：如果模型调用失败，就返回一个预设的通用回复，同时记录错误日志。虽然降级回复的质量不如模型生成的，但至少保证了系统可用性。

6. 上线后的效果追踪与迭代方向

6.1 关键指标的定义与监控

系统上线后，我定义了三个核心指标来追踪效果：日活跃练习时长、语法错误率变化、用户留存率。日活跃练习时长反映学生的使用意愿，语法错误率变化反映学习效果，用户留存率反映整体满意度。

监控这些指标不需要很复杂的工具，我用的是一个简单的定时任务，每天凌晨跑一次统计查询，把结果写入一个单独的报表表。然后每周看一次趋势，如果某个指标连续两周下降，就深入排查原因。

6.2 基于真实数据的迭代案例

上线第一个月，我发现一个有意思的现象：学生的平均练习时长在第二周达到峰值，然后开始下降。我查了对话记录，发现很多学生在第二周之后开始重复之前练过的话题，新鲜感消退后就失去了兴趣。

针对这个问题，我做了两个改动：一是增加了话题推荐功能，根据学生的兴趣标签和练习历史，每周推荐几个新话题；二是引入了“挑战模式”，学生可以选择一个特定场景（比如点餐、面试、旅行），系统会模拟真实场景进行对话，完成后给一个评分。这两个改动让第三周的练习时长回升了 40% 左右。

6.3 后续可以扩展的方向

这个智能体目前还是一个比较基础的版本，后续有几个方向我觉得值得探索。一是多模态交互，比如加入图片描述练习，学生看一张图然后用英语描述，系统从流利度、词汇丰富度、语法准确度三个维度打分。二是社交化学习，让学生之间可以互相看到练习记录和进步曲线，增加竞争和互动。三是与线下教学结合，把智能体收集到的学生错误数据同步给老师，让老师在线下课堂上做针对性的讲解。

不过这些都是后话，现阶段最重要的还是把核心的对话和诊断体验打磨到极致。我始终觉得，一个功能做到 90 分，比五个功能都做到 60 分要有价值得多。

6.4 关于成本与规模的现实考量

最后说一个很现实的问题：成本。前面算过，单个学生每月的模型调用成本在几块钱，听起来不多，但如果用户规模到了一万，每月就是几万块的支出。这个成本对于免费产品来说压力不小，对于付费产品来说则需要仔细核算定价。

我的建议是在架构设计阶段就把成本控制考虑进去。具体做法包括：对话生成用中等模型而不是顶级模型；语法诊断做缓存，相同或相似的句子不重复调用；非高峰时段的请求做批处理；设置单用户每日调用上限，防止异常使用。这些措施加起来，能把成本降低 40% 到 60%。

我在实际运营中体会最深的一点是：智能体产品的竞争力不在于用了多先进的模型，而在于对业务场景的理解深度。英语教育这个场景，核心是帮助学生建立表达自信、养成练习习惯，技术只是实现这个目标的手段。把学生的每一次进步都记录下来、反馈给他们，让他们感受到自己在变好，这比任何花哨的功能都重要。