先说结论。开发一个英语情景教学Agent，本质上不是在做“又一个聊天机器人”，而是在做一套在教学法、状态机、记忆和语音交互之间互相咬合的系统。我做完这个项目最深的体会是：真正难的不是让大模型开口说话，而是让它记得住上下文、控得住教学节奏、给得出有梯度的反馈。这篇文章从需求拆解到架构设计，再到逐行实现和排坑记录，完整复盘一个可落地的方案。

1. 项目拆解：英语教学Agent到底在解决什么问题

1.1 核心需求解析

你要做一个英语情景教学Agent，首先得把“情景教学”这件事拆成可以程序化的逻辑单元。情景教学的本质是：在真实或模拟的交际场景中，通过角色扮演、任务驱动、语境输入，帮助学习者掌握语言的实际运用能力。所以这个Agent和普通问答机器人的分水岭在于它必须包含三样东西：

• 情景上下文：机场check-in、餐厅点餐、商务谈判……每个场景有独立的词汇表、对话模板和交际目标。
• 教学策略：不是用户说什么就聊什么，而是要在对话中穿插纠错、提示、示范和分级反馈。
• 学习者模型：Agent要能记住上一个对话里你在哪里卡壳、哪个语法点反复错、词汇量大概在什么区间，然后动态调整会话难度。

我把这三个维度整理成高内聚、低耦合的模块：情景引擎（Scenario Engine）、教学策略控制器（Pedagogical Controller）、学习记忆库（Learner Memory）。

1.2 技术选型背后的取舍

开发Agent，首先要回答一个绕不开的问题：直接用单次大模型调用做对话，还是引入Agent框架做“规划-执行-反思”循环？

我的经验是，教学场景恰恰是Agent框架最能体现价值但也最容易“过设计”的地方。如果只是一个ChitChat API，你可能连“上轮说错时态”都记不住；但如果照搬ReAct模式让模型每一步都高频率调工具去检索、记忆和反思，延迟会高到让口语练习完全失去体验。

这里有一个关键判断：教学Agent的“思考”应该在幕后完成，前台必须低延迟。

我最终的方案是折中路线：

这里解释一下为什么不用全链路ReAct式的Agent框架。我测试过一些主流框架，设计得很强大，工具调用、多智能体协作都没问题，但在教学场景里，一次“规划”动作往往引入2到3次额外的大模型调用，单轮交互会因此多出1.5到2秒的延迟。对话教学最怕的就是延迟。所以我只把“工具调用”保留在需要真正外部数据的时候（比如查词书、加载情景脚本），对话主链路还是走“直连+结构化输出”。

1.3 用户画像和使用场景定位

我最初想把功能做得大而全：岗位面试模拟、雅思口语训练、商务邮件润色……后来发现这样会分散情景设计的精力。最终锁定了三层用户场景：

1. 零基础到初级（A1-A2）：需要高度脚本化的场景，会话以“填空式”引导为主，大量使用提示板和示范句。
2. 中级（B1-B2）：需要半开放性场景，Agent充当出题者，要求用户在场景中解决突发任务，比如“你在餐厅发现菜品有问题，需要向服务员表达不满”。
3. 高级（C1+）：完全开放角色扮演，Agent模拟客户、面试官、谈判对手等角色，甚至刻意使用习语、非标准口音来“刁难”用户。

这个定位影响了下游几乎所有的设计决策。比如低级别用户对“Agent在对话中突然打断纠错”容忍度较高，而高级别用户则希望对话流畅，纠错留到段落结束统一反馈。所以我后来引入了用户偏好的动态调节，而不是一刀切。

2. 情景教学Agent的整体架构设计

2.1 分层架构与数据流

先给出我最终实现的架构图（文字描述版，因为纯文本发布无法贴图，但逻辑是完整的）：

用户 → 语音/文本输入 → ASR（可选） → 对话管理入口 对话管理入口 → 学习记忆库检索 → 情景状态机加载 → 教学策略控制器 教学策略控制器 → 主对话引擎（大模型） → 结构化JSON输出 结构化JSON输出 → 反馈渲染器 → 语音合成（可选） → 用户 ↑ 评测模块（异步执行，不阻塞主链路）

分层逻辑如下：

• 控制层：接收用户输入后，先从Redis取当前会话状态（current_scene_id、stage、round），再把状态和记忆封装到Prompt里。
• 决策层：大模型输出一个固定的JSON结构，包含reply（给用户的回复）、correction（本轮需要纠正的错误，可为空）、stage_transition（状态迁移指令）、assessment（本轮表现评估）。
• 执行层：把JSON拆解开，将correction和assessment异步写入评测队列，将reply渲染给学生，同时根据stage_transition更新状态机。

这种设计的最大好处是：决策和执行解耦。大模型只负责生成“意图明确的结构化内容”，真正修改状态、持久化记忆、做异步语法纠错都是后端代码的事。

2.2 情景脚本建模（Scenario DSL）

情景教学Agent的“灵魂”是一份份情景脚本。我一开始尝试把脚本全部写在Prompt里，例如：

你是一个前台接待员，用户在酒店办理入住……

结果发现了几个问题：

1. Prompt过长后，模型随机会话漂移，有时会忘记这个场景的词汇限制。
2. 无法精确控制会话的“关卡结构”，用户跳过关键步骤时模型不会拦截。
3. 记忆和进度无法结构化存储，每次都得靠模型隐式记忆。

后来我设计了一套轻量的情景脚本DSL（领域特定语言）。每个教学场景由一个JSON描述：

{ "id": "hotel_checkin", "title": "酒店入住", "level": "A2", "goals": ["能完成入住登记", "能询问早餐时间", "能报告房间设施问题"], "vocabulary": ["reservation", "passport", "deposit", "room service"], "stages": [ { "id": "greeting", "flow": ["agent_greets", "user_responds"], "entry_condition": "agent_start", "exit_condition": "user_provides_name_and_reservation" }, { "id": "registration", "flow": ["agent_asks_passport", "user_submits_info", "agent_gives_room_card"], "entry_condition": "stage_greeting_done", "exit_condition": "agent_confirms_room_number" } ], "common_mistake_foci": ["present_tense", "prepositions"] }

然后在系统Prompt里，把这个JSON压缩成一份紧凑的脚本描述，同时保留完整版供后端的流程校验。状态机推进逻辑不靠大模型的自觉性，而是靠严格的exit_condition判断。判断方式很简单：从模型输出中提取用户的关键动作（比如“是否提供了姓名和预订号”），这种动作识别可以交给一个轻量的意图分类模型，或者干脆让大模型在输出stage_transition时带上已完成条件的索引。

2.3 为什么状态机对教学Agent如此重要

没有状态机的教学Agent是什么样？用户说“我想吃汉堡”，Agent可能会跟着聊美食聊到天南海北；用户学到一半，Agent完全不记得这个场景的“教学目标”是什么。状态机则保证教学闭环。

不同的场景我把状态粒度控制在2到5个。太少，场景显得单薄；太多，模型需要频繁做状态判断，出错概率指数级上升。

以“酒店入住”为例：

1. greeting（问候与身份确认）
2. registration（核验护照、填写信息）
3. room_info（介绍房型、早餐等）
4. handling_issue（用户提出房间问题时触发）
5. closing（结束语与反馈总结）

每个状态里定义了Agent的“行为边界”：词汇提示类型、可接受的答案集、拒绝回答时应如何引导。比如说在registration阶段，如果用户直接蹦出一句“Can I have the key”，状态机应该让Agent说“I need your passport first”而不是顺着用户走。

2.4 学习者记忆的分层设计

记忆是Agent区别于普通API的真正价值所在。我分了三层：

1. 短期工作记忆（Working Memory）：存当前会话最近10轮对话内的实体信息，比如用户名、房间号，放在Redis，根据场景ID和会话ID做键。每次请求直接读取，不经过向量检索。
2. 长期知识记忆（Learner Profile）：用户的词汇薄弱点、语法易错点、历史场景完成度、平均语速等，写入向量库。每次启动新场景时，先用embedding模型把用户的历史表现向量化，检索最相关的几段记忆加入Prompt。例如用户过去几次都在preposition上犯错，新场景Prompt里会特别强调“重点注意介词使用”。
3. 教学策略记忆（Metacognitive Strategy）：记录上一个会话的“反馈频率”和“纠错方式”。有些用户喜欢即时纠错，有些喜欢会话后统一讲评。这个偏好一旦形成，就写注释长期保存，并在每次会话开始前加载，调节纠错节奏。

记忆分层最大的收益是降低token消耗。如果每次对话都把用户三个月的完整历史塞进上下文，成本和延迟都会爆。我实测用向量召回TopK memory，单次上下文只增加400到600 token，效果不错。

3. 教学策略与提示词工程的核心设计

3.1 系统提示词的结构化技巧

有了状态机和记忆，Prompt工程就变成了一项“组装”工作。我的系统提示词结构如下：

你是“情景英语教练”，负责引导用户完成场景{scenario_id}。 你的教学级别是{level}。 教学风格：{style: constructive / encouraging / rigorous} ### 本场景教学目标 - goal1 - goal2 ### 当前教学阶段 - stage_id: {current_stage} - 阶段描述: {stage_flow} - 用户当前进度: {progress_in_stage} ### 用户画像与历史薄弱点 - 薄弱点: {other_mistakes} - 近期反馈要求: {feedback_preference} ### 本次会话的即时约束 1. 只能使用{allowed_vocabulary}范围内的词汇给出提示，但可对超出范围的词汇表示理解。 2. 用户出现错误时，{correction_mode}（如：立即纠正 / 段落结束后纠正）。 3. 每次回复都需要输出JSON格式，结构如下： {json_schema}

看到没，我把教学指令的大模型可识别性和硬性格式约束结合起来了。JSON Schema的约束比自然语言描述可靠得多，我建议直接在Prompt里给一个完整的、已经填好示例的JSON对象。

3.2 反馈分级与“脚手架”

教学场景里有一个教学法上非常重要的概念——脚手架（Scaffolding）。简单说，学习者遇到困难时，教师不是直接给答案，而是逐级提供提示，直到学习者自己完成。

我把脚手架算法化，形成五级递增的提示策略：

1. 提示重述：如果用户句子不完整，Agent重复用户的话，用升调暗示需要补充。例：“You want to check in? Your name is……?”
2. 给出首词：例：“I'd like to…… ”
3. 选项制导：例：“Do you want to say ‘reservation’ or ‘appointment’?”
4. 示范句：给出完整标准句，并要求用户跟读。
5. 保证成功：给出简化任务，让用户重试一次。

这个策略在Prompt里用一段专门描述，同时在assessment字段中要求模型标记“本轮用了第几级脚手架”。如果模型连续两轮都停在Level 4，说明阶段设计难度过高，需要动态下降难度。我用这个指标做了一套简单的“会话难度调节器”：连续高等级脚手架次数超过阈值时，主动简化目标，降低任务复杂度。

3.3 评测模块：从“大模型自评”到“组合式评测”

评测是整个教学Agent里最容易被人忽视实际上最容易翻车的地方。大模型自评“你上次答得不错”，对于学习者是几乎没有帮助的。我最终采用了3层评测组合：

1. 即时语法与发音检测：ASR的转写文本先进入一个语法纠错模型（我用了并行的开源或商业纠错API），产出“原句/建议修改/正确解释”。这个调用是异步进行的，因为通常需要几百毫秒到一秒，如果同步等待，对话就会卡顿。
2. 大模型教学评估：主对话模型在每个轮次输出assessment字段，包含单词使用、语法准确度、流利度、任务完成度四个维度，分数范围1到5。
3. 场景结束后的总结报告：会话结束后，后端拉取所有轮次的纠错和评估，生成一份结构化的学习报告，包含错题集、词汇推荐、下阶段学习建议。

三层评测的数据分别进入短期记忆和长期记忆，其中纠错结果直接喂给向量库更新“UserProfile”。

3.4 多轮纠错并发与延迟控制

这里有一个非常容易踩的坑：如果你老老实实把语法纠错API同步串接在主对话链路里，那么用户体验会变成“回复前仿佛思考了很久”，卡顿感极其明显。我的解法是：优雅降级。

主链路直接返回大模型的回复，后端立刻异步发起语法纠错请求。纠错结果回来后，如果会话还在进行，就在下一轮对话中附加“上一轮的小提示”；如果会话已结束，就进入总结报告。

实测下来，这样既能保证交互流畅，又能做到“每句话都有反馈”，是教学效果和体验的平衡点。它需要额外做的是把“上一轮纠错结果”作为Prompt的一部分传入下一轮对话，让模型知道哪些错误曾被指出过，避免重复纠同样的问题。

4. 实操过程与核心实现细节

4.1 开发环境与基础框架

我推荐用Python生态实现这类项目，理由很直接：大模型框架、向量数据库、音频处理库的Python支持最好，排障资料也最多。我的项目核心栈：

• Web框架：FastAPI。用异步接口承载对话请求，天然适合在教学场景中一边返回文本、一边异步处理评测。
• Agent Lite架构：没有采用裸调用的方式，而是写了一个非常薄的AgentRuntime，负责封装会话上下文、调用模型、解析JSON、执行状态迁移。
• Redis：存短期会话和阶段状态。键设计示例：scene:{user_id}:{session_id}:state。
• 向量库：Milvus或Qdrant都可以。我本地开发先用起了sqlite+embedding的简化方案，等数据量上来再切Milvus，这样可以快速验证逻辑，不必一开始就上一套重分布式组件。
• 大模型：开发期用了GPT-4o，并开启严格JSON模式输出，是降低解析出错率最有效的手段之一。

4.2 AgentRuntime的核心代码思路

光讲概念没意思，我贴出来核心调度逻辑的简化版本，并解释每个关键决策。

import asyncio import json import redis.asyncio as aioredis class EnglishTeacherAgent: def __init__(self, llm_client, memory_store, state_store, evaluator): self.llm = llm_client self.memory = memory_store self.state = state_store self.evaluator = evaluator async def chat(self, user_id, session_id, user_text): # 1. 并发拉取短期记忆（不阻塞在模型推理之前） state_key = f"scene:{user_id}:{session_id}:state" scene_state = await self.state.get(state_key) # 2. 加载长期记忆（向量召回 Top5） memory_context = await self.memory.retrieve_top_k( user_id, scene_state["scenario_id"], top_k=5 ) # 3. 将记忆、场景状态、用户输入拼装为 Prompt prompt = self.build_prompt(scene_state, memory_context, user_text) # 4. 调用大模型并获取结构化结果 response = await self.llm.chat_json( messages=prompt, response_format={"type": "json_object"} # 强制JSON输出 ) parsed = json.loads(response) # 5. 根据 parsed 里的 stage_transition 更新状态机 new_state = self.apply_transition(scene_state, parsed.get("stage_transition")) await self.state.set(state_key, new_state) # 6. 异步触发深度评测（不阻塞用户回复） asyncio.create_task( self.evaluator.evaluate_async(user_id, session_id, user_text, parsed) ) # 7. 向用户返回渲染后的回复和可选提示 return await self.render(parsed, scene_state["level"])

这个代码里我认为有三个点对实际工程非常重要：

• 强制JSON输出：如果不强制，哪怕模型回答99%是JSON，1%的Markdown符号都可能是灾难。GPT系列模型现在都支持response_format字段，建议从第一天就打开。
• 状态读取和更新分离：get和set操作分别在模型调用前后执行，这是避免大模型crash后状态不一致的关键设计。如果模型调用失败，旧状态还在Redis里，可以安全重试。
• 异步评测：这里用asyncio.create_task把评测踢到一个后台任务中，用户完全无感。不过要注意的是，生产环境不能简单依赖create_task，最好丢进Celery或一个Worker队列里，防止进程退出时丢失任务。

4.3 状态机核心逻辑与推进条件

状态机本身的代码我尽量写死，不依赖大模型做过于复杂的决策。核心设计是：模型只负责给出“建议转移”，程序负责校验“转移是否合法”。

def apply_transition(scene_state, suggested_transitions): current_stage = scene_state["current_stage"] allowed = SCENARIO_DEFS[scene_state["scenario_id"]]["stages"] # 只允许到达相邻的后续阶段，不允许跳级 stage_index = allowed.index(current_stage) next_stage = None if suggested_transitions in allowed: # 检查是否越界（不能从阶段0跳到阶段4） candidate_index = allowed.index(suggested_transitions) if candidate_index <= stage_index + 1: next_stage = suggested_transitions if next_stage: scene_state["current_stage"] = next_stage scene_state["progress_in_stage"] = 0 else: # 保持原阶段，但可能增加 stage 内部进度 scene_state["progress_in_stage"] += 1 return scene_state

在这段逻辑里，我把“跳级”直接视为非法转移，阻止大模型犯“一步完成整个入住流程”的倾向。很多Agent项目不重视这类逻辑校验，结果大模型经常把教学进度推飞。你还应该在progress_in_stage累计次数超过某个阈值时，触发“降级难度”逻辑。例如在同一个阶段停留过久，就直接给出示范句和跟读任务，避免卡死。

4.4 情景DSL的录入与设计套路

做情景教学Agent，最难的不是技术，而是优质情景脚本的量产。我自己摸索出了一个3步套路：

1. 先用真人对话打底：对每一个想做的场景，先写一份5到10分钟的“理想教师与理想学生的对话”。这份对话就是Agent的行为基准。
2. 标注“教学节点”：在对话中找出“学生可能犯错的点”“教师应该给出提示的点”，每个标注对应DSL里的common_mistake_foci。例如在点餐场景，“I want a coffee”是可以接受的，但“I want two coffees please”才是更高目标；这些梯度目标全部在DSL里写清楚。
3. 拆成2到4个stage：把完整的脚本按教学目标拆成stage，并在每个stage里定义exit_condition的具体判定关键词和语义。这个阶段是最费工夫的，但也是Agent教学质量的护城河。你完全可以把这些脚本当成一门语言教学的课程设计产品来对待。

4.5 记忆检索的Embedding与入库流程

长期记忆入库不能在用户对话的同步链路中做，否则延迟很高。我的做法是有一个定时或事件驱动的离线流程：

1. 会话结束后，评测模块产出结构化记忆对象，例如{"user_id": "u", "grammar_issue": "preposition_at_on", "vocab_gaps": ["deposit", "receipt"], "scene_id": "hotel_checkin"}。
2. 将该记忆对象转成一条文本摘要："用户在第X次入住场景中犯了关于时间介词at/on的错误；在使用deposit一词时需要提示；表现水平有提升。"
3. 用Embedding模型生成向量，写入向量库，并关联user_id和scene_id字段。
4. 每次新会话启动前，用当前用户ID和场景ID做向量检索，filter限定最近30天数据。

注意：不要老是把向量检索接到用户输入里，因为那样会产生语义噪音。场景级。比如用户上一场是餐厅，这一场是酒店，直接拿“餐厅”的记忆去检索“酒店”场景，多半会召回用户对“menu”“bill”的不相关错误。所以我建议检索时把scene_id作为filter参数，严格锁定相关性。

5. 实操过程中遇到的坑与排障实录

5.1 大模型“答非所问”和JSON解析崩溃

我开发第一个MVP时，遇到最多的就是模型不给JSON或JSON中嵌套字段格式漂移。坦白讲，这个问题的根源多数是自己的Prompt不规范。解决方案分为两层：

• 模型层：凡是支持JSON Mode的模型，全开response_format。另外再把Schema里的枚举值都写死，比如stage_transition只能是场景中定义的stage ID之一。
• 代码层：写一个容错解析函数，检测到JSON解析失败时，提示模型重新生成一次。同时记录日志，定位是哪类Prompt导致的输出异常。

我自己在生产里做了计数器：连续2次JSON解析失败，就将当前轮降级为友好的纯文本问答，并同步写入告警日志。这种“兜底路径”能预防线上服务崩溃。

5.2 场景状态“神秘漂移”

遇到过另一个非常诡异的问题：场景状态偶尔会从阶段A跳回初始阶段，类似于游戏存档丢失。排查后发现问题不在大小模型调用逻辑，而是Redis中的键被设置了过期时间，且没有按时续期。用户在对话中停顿5分钟以上，旧键过期，下一轮就被当成全新会话处理了。

排障经验是：短期会话的键，TTL至少设置为场景会话的平均时长乘以3倍或更高，并且在每一轮对话成功结束时主动续期。如果你做的是移动端口语练习，很多用户说两句话就开始想，停顿时间很长，这点尤其重要。

5.3 纠错反馈太快或太慢的节奏控制

异步评测最大的副作用是：纠错结果不一定按顺序回来。比如用户第一句话的纠错很慢，第二句话的纠错却很快，后台排队一乱，用户看到的“上一轮提示”其实是上上轮甚至更早的信息。这会造成非常糟糕的学习体验。

解法是在evaluator模块里维护一个按轮次序号递增的队列，只有当前轮次的纠错结果落到“上一轮”或“更早”位置时才会被送入下一轮Prompt。如果出现乱序，丢弃较早轮次的纠错结果，不做强制交付。

5.4 长对话的上下文漂移

当一场会话进行到20到30轮时，大模型的上下文会非常拥挤，且谈论焦点有可能从酒店入住跑偏到美食推荐甚至人生哲学。我在状态机代码里加了强制规则：任何情况下回复内容都不能跳出当前场景的词汇和主题范围。如果模型生成的内容与主题相似度低于阈值，后端会要求模型重新输出一次，并把旧回复作为“越界样例”加入Prompt，让模型知道这样不行。

5.5 关于微调与工程实现的取舍

很多读者可能会问我：为什么不干脆微调一个专属于自己的英语教学模型？我同样走过这个弯路，但最终发现：微调成本极高，效果却未必比精心设计的Prompt更好。因为情景教学的核心瓶颈在于“会话管理”，而会话管理恰恰是Prompt和代码组合最能发挥的地方。没有上下文状态管理的裸模型，即便微调一百遍，也无法记住用户上一轮说了什么并给出有节奏的教学反馈。等你的教学脚本和记忆系统稳定定型后，再考虑把“高重复的基础评估任务”（比如固定规则纠错）蒸馏到一个小模型上做降本增效，那是更经济的路径。

5.6 教学场景内容全覆盖的风险排查

最后一个要提的是内容安全。英语教学Agent的用户很可能包含未成年人，所以内容安全等级要按极高标准设定。凡是涉及人身安全、医疗建议、暴力或不当内容，模型必须输出指定的安全回复，并结束当前会话。我在大模型Prompt中加入明确的“红线规则”，并在后端增加关键词和分类器双重拦截。另外，所有语音和文本数据都做脱敏处理，不采集真实姓名、地址、证件号码等个人敏感信息。这个方面宁可过度保护，也不要心存侥幸。

6. 性能优化与线上部署建议

6.1 延迟预算与并发量的平衡

教学体验的基础是低延迟，我给自己定了硬指标：文本对话单轮P95在1.2秒内。为此做了几项优化：

• 模型选择分档：简单阶段的流程引导用快速低配模型，复杂评估和开放对话用高配模型。
• 限制输出长度：回复控制在80到150词内，既避免学生阅读负担过大，又减少生成时间。
• 连接复用：大模型Client用异步HTTP长连接池，避免频繁建立连接的开销。
• 缓存场景Prompt：每个场景的系统提示词做模板渲染并缓存，避免每轮重复拼接JSON场景配置的序列化开销。

6.2 并发选型参考

搜索热点里有很多人问“AI Agent怎么扛并发”。我的理解是：常规教学Agent，单实例跑异步Python已经能处理相当可观的并发量，因为主要瓶颈是外部大模型的推理速度，而不是你自己服务的CPU。要做的是：

1. 大模型API的速率限制与重试策略必须严格配置，避免被限流后雪崩。
2. 自己的Web服务必须无状态化，所有会话状态放Redis，这样你才能水平扩展Pod。
3. 异步评测Worker独立部署，即便评测服务崩溃，也不影响对话主链路。

6.3 Docker化部署与安全

我最终将服务打成Docker镜像，编排则由Kubernetes管理。镜像里包含FastAPI服务、Redis客户端、向量库客户端、评测Worker。值得一提的小细节：永远不要把大模型的API密钥写进镜像或环境变量明文，要用密钥管理服务。线上环境的密钥管理、HTTPS终止和鉴权中间件，也务必在第一天就加好，否则后面补会非常痛苦。

7. 效果评估与样本对话复盘

7.1 一次完整的模拟会话分析

我个人实际测试中，一个非常有代表性的中阶会话大概是这样的（内容经过脱敏精简）：

Agent: Good morning! Welcome to the Grand Hotel. Do you have a reservation? User: Yes, I booked a room last week. Agent: Great. Could I have your name, please? User: My name is John Smith. Agent: Thank you, Mr. Smith. I see your reservation for three nights. May I see your passport? User: (犹豫) Passport? I didn't bring it. I have my ID card. Agent: I understand, but we do need a valid ID for check-in. Would you like to show me another official document?

复盘这段会话，Agent表现出两个符合教学设计的点：

• 在用户说“Passport? I didn't bring it”时，模型没有顺着“没带护照怎么办”扯到安全问题，而是把话题拉回到“出示其他证件”这个流程上，这支撑了状态机中registration阶段的推进。
• 在用户出现“booked”过去式时，模型没有打断，而是把这个错误延后到阶段结束时统一反馈。这是由教学设置里的correction_mode=deferred控制的。

从评测报表看，用户完成度85%，语法准确率从上一轮的72%升到了79%，任务达成度不错，所以场景可以进入下一个更难的目标。

7.2 量化评测指标

我建议每个Agent项目都建立一组成体系的评估体系，至少包括：

这些指标会告诉你在“好用”和“能用”之间还差多少。

7.3 数据驱动的内容优化

另外我强烈建议记录每场会话的完整PG（Prompt-Generated）数据，比如哪些stage用户卡住最久、哪类脚手架使用频率最高、哪个场景的完课率最低。我实际开发时发现“餐厅点餐”场景的完成度比“酒店入住”低了15%，后来分析对话日志发现是因为餐厅场景的菜单词汇过难，和A2级别目标不匹配。于是我把菜单词汇从“The truffle-infused ribeye”改成“The steak with mushrooms”，完成度立刻回升。这就要求你有日志分析和数据导向的意识，把教学场景当作产品持续迭代。

8. 常见问题速查表

这个部分是给我的实操复盘，给后来者直接“抄作业”用的。

还有一些我踩过的“软坑”也要提醒：

• 不要给用户过度承诺“AI外教”。很多用户期待Agent像真人教师一样即刻纠音、评估口音，但当前语音链路在真实口语流畅度判定上仍有显著误差。我建议在项目初期就把“跟读评分”和“对话教学”做成两个独立功能，你在UI上明确区分“练习模式”和“对话模式”，避免口碑崩掉。
• 多语言混合输出的处理。很多初学者会不打中文字幕就表达不清，Agent要能区分“学生用中文提问问题”和“学生在句中夹用中文”，前者应提示“请用英文表达”，后者可以给出替代词。
• 保护用户数据，匿名化场景日志。所有真实对话数据，在用于模型改进前必须去标识化。

9. 后续扩展方向

如果这个项目继续演进，我下一阶段会做三件事：

1. 多模态化。接入可选的实时语音链路，把ASR和TTS真正做进去，让用户可以用语音完成整个会话。语音链路与文本链路复用同一套状态机，只是输入端和输出端换掉。
2. 教学数据的闭环反馈。把每场会话的评测数据回传至脚本设计表，定期人工审阅哪些场景的数据不符合教学目标，再优化DSL。这相当于给教学Agent建立一个“教研团队”循环。
3. 自适应学习路径。基于长期学习者画像，动态推荐下一个场景和复习计划。例如用户连续在三个餐厅场景中用错介词，那么系统可以自动安排一个介词专题场景，而不是机械地推进课程列表。

我个人在做这个项目时最大的体会是：Agent开发不是“提示词大赛”，它更接近传统软件工程和教学法的融合。你要对状态、记忆、延迟、安全都有敬畏心。把一个一个细节做扎实，而不是追求炫技的Agent框架，教学效果自然会出现。

如果你也正在做类似的产品，建议先从一个只有2到3个场景的最小闭环开始跑通，别一上来就铺十几个场景。把模型调用、状态机、评测、记忆这四根梁立稳了，后续扩展只是时间问题。