企业官网建设流程全解析

1. 为什么做这个Agent：口语教学的痛点与机会

1.1 英语口语学习最缺的，是"敢说"的练习环境

我有个表弟，大学四级过了，词汇量也不差，但一开口就卡壳。他跟我说，自己也试过跟ChatGPT用英语聊天，聊了两轮就放弃了——因为他一旦停顿或者不知道怎么说，AI会自动帮他把句子接下去，特别丝滑，但这样根本练不到他自己。我听完就明白了一个事：现在的大模型不缺对话能力，缺的是"教学纪律"。它太想顺着用户了，太想显得聪明了，所以它会在你卡壳的瞬间替你把话说完，然后把整个沉浸感破坏掉。

传统的口语学习工具也解决不了这个问题。背单词App解决的是词汇输入，题库软件解决的是考试技巧，那些带对话树的学习软件更僵硬——你选A它走A分支，选B它走B分支，稍微说一句不在剧本里的话，整个流程就崩了。真人外教当然好，但一节课两三百，约课还有通勤成本，大多数人坚持不下来。

所以我当时就想，能不能做一个Agent，它不急着展示自己有多能聊，而是像一位有耐心的老师一样，设定一个英语情景（点餐、问路、面试），让你在那个情景里开口，说错了它纠正，卡住了它提示，练完了它打分。这个Agent的开发难度其实不高，真正难的是怎么把"教学逻辑"塞进Agent的行为里。整个项目从敲第一行代码到能稳定跑通一个场景，我用了三周，这篇文章就是完整复盘。

1.2 情景教学法：语言不是背出来的，是用出来的

为什么强调"情景"？这背后是语言教学里的交际法。简单说，语言能力不是一个单词表的堆叠，而是完成交际任务的能力。你在餐厅里需要做到的是：告诉服务员你想吃什么、说明忌口、询问价格、提出打包。这些表达拆开都不难，但合在一起，需要你在那个压力场景里快速组织语言。脱离情景背一百个"点餐句式"，真到了餐厅里照样紧张。

我用一个游泳类比来理解这件事：看再多游泳教学视频，下水该呛还是呛。情景教学的作用，就是创造一个安全的水池，让你在泳池里练动作、呛几口水、被教练纠正，然后才敢去河里游。过去的AI做不到这个——因为免费对话没有教学目标，而对话树又不够开放。现在的大模型Agent可以做到，因为它既能扮演某个特定角色，又能根据你的水平动态调整对话难度和提示强度，这其实是真人老师的工作方式。

想清楚这个产品逻辑之后，我没急着写代码，而是先列了一张问题清单。这个Agent必须做到三件事：第一，情景要够真实，角色要够清楚；第二，它必须遵守"不替用户说完整句子"的规则，得让用户自己开口；第三，整个对话要有流程，而不是无限闲聊。这三条后来全部变成了我的开发红线，也分别对应了情景模板、系统提示词和状态机三块代码。

2. 技术选型：轻量自建而不是重框架

2.1 低代码平台和Agent框架都不完全合适

决定动手之后，我先把市面上的Agent开发路线梳理了一遍，大概分成三类：低代码Agent平台（比如Coze、Dify这类）、通用Agent框架（比如LangChain、LangGraph），以及完全自建（直接用Python调用大模型API，自己写流程控制）。

先说低代码平台。它们确实方便，拖拽几个节点就能搭出一个聊天机器人，内置的知识库、插件编排、工作流都做得挺成熟。但我很快发现两个问题：一是教学流程里的"纠错时机""评分逻辑"这种精细行为，在可视化编排里很难表达清楚，它不是"触发→响应"的简单流程，而是一套带状态的教学节奏；二是这类平台生成的数据和用户对话内容都会经过云端，如果以后真要给学生用，数据合规是个麻烦事。用来做产品原型验证还行，作为最终方案我不太放心。

再说LangChain这类框架。它们的杀手锏是封装了各种工具调用、记忆管理、链式调用，生态很全。我对这套东西不陌生，但在这类项目里体会是：如果你只是做一个“单场景多轮对话 + 结构化输出”的Agent，框架带来的抽象层反而会干扰调试。我调Prompt的时候往往要同时面对两层问题——一层是我的模板写得不好，另一层是框架的某些默认行为把消息格式改了。比如有些版本会自动把system prompt合并进历史，导致角色行为漂移，排查起来非常痛苦。

所以我最终选了完全自建。这不是说框架不好，而是"情景教学Agent"这个项目的核心复杂度不在Agent框架，而在教学状态机、情景模板、评分逻辑这三块。这些全是业务代码，用框架帮不上太多忙，反而用纯代码写最直接、最好调。

2.2 最终架构：四大模块，各行其是

整个项目的代码结构如下：

english_agent/ ├── app.py # Gradio界面层 ├── agent/ │ ├── core.py # Agent主流程：编排状态机 + 调用LLM │ ├── prompts.py # 系统提示词模板 │ ├── state.py # 教学状态定义和转移逻辑 │ └── scenarios/ # 情景模板目录 │ ├── restaurant.json # 餐厅点餐 │ ├── airport.json # 机场值机 │ └── interview.json # 求职面试 ├── evaluator/ │ ├── scoring.py # 评分结构定义与解析 │ └── asr.py # 语音转写（Whisper） └── requirements.txt

四个模块的职责非常清楚。情景目录就是教学大纲，每新增一个场景，只需要加一个JSON文件，不用改代码。核心主流程负责把"用户消息 + 当前状态 + 情景模板"拼成一次完整的Prompt，然后调用大模型，把返回结果解析出来。状态机负责判断这轮对话处于教学的哪个阶段，决定下一步是继续引导、给提示还是进入总结评分。界面层用Gradio，因为它是Python生态里最快能出聊天界面的东西，十分钟就能跑起来。

依赖也很少，核心就三个：

openai>=1.0 # OpenAI兼容接口，很多模型都支持 gradio>=4.0 # 界面 PyYAML # 读情景配置（也可以用json，随意）

这里多说一句，我用的是OpenAI的Python SDK，但base_url可以改成任意兼容服务（比如阿里云百炼的DashScope、DeepSeek、智谱AI等），这样模型层就能灵活切换。后面我会专门讲模型怎么选。

2.3 模型选型：教学Agent需要的是"听话"，不是"聪明"

模型选择这件事，我一开始走了弯路。我最早用的是当时最强的通用模型，想着英语教学嘛，模型越强越好。实测下来发现，模型太聪明有时候反而是灾难：它太容易理解用户的意图了，用户只说一个词"coffee"，它就能脑补出一整句"I would like to have a cup of coffee, please"，然后替你说了。真正的老师不会这样，老师会强迫你说完整。

后来我换了个思路，把教学场景对模型的核心要求拆成了四条：

• 指令遵循能力：能不能严格做到"不替用户说句子""先给提示再说答案"
• 角色保持：能不能从头到尾都扮演餐厅服务员，而不是聊着聊着变成英语老师开始讲语法课
• 结构化输出稳定性：最后能不能稳定输出JSON评分，不夹带多余文本
• 价格与部署成本：如果要给一个班的学生用，成本得压得住

按这个标准，我最后主力用的是国内几个走OpenAI兼容接口的模型，比如Qwen和DeepSeek系列，实测下来指令遵循都够用，价格便宜一大截。GPT-4级别的大模型我只用在一个地方：生成情景模板和少数难点句的参考译文，而不是跑在线对话。在线对话追求的是"稳"，离线生成追求的是"强"，分开用性价比高很多。

3. 情景模板设计：把英语教学法写进系统

3.1 先写教案，再写Prompt

做这个项目最大的一个教训是：不要一上来就写Prompt，先写教案。什么是教案？就是一段教学流程的书面设计，规定这节课怎么开场、学生练什么、老师什么时候介入、什么时候收尾。我一开始直接写了个"你是一名英语老师，请和学生对话"，结果模型表现得像个没有教案的实习老师——想到哪讲到哪。

后来我老老实实把一节课拆成了五个阶段：

1. 开场引入：介绍情景，说明这次课的任务（比如"你今天要独自完成一次餐厅点餐"）
2. 情景展开：AI以服务员身份开场，自然地把学生拉进对话
3. 引导表达：学生卡壳的时候，先给词汇提示，再给句式提示，最后给示例
4. 纠错与复述：学生说错时，用"肯定+正确形式+一句话解释"的方式纠正，并让她复述一遍
5. 总结评分：练得差不多之后，按维度打分，给出2-3条下一步建议

这五步对应到Agent的行为上，就是状态机里的几个阶段。教案是写给教学法看的，Prompt是写给模型看的，但本质上是同一个东西的两套表达。我先把教案写好，把它翻译成Prompt的规则，再把它固化成代码里的状态转移，整个过程就顺了。

这里有一个特别关键的经验：教案里要明确写"学生的目标表达"是什么。比如点餐场景，核心表达是"I'd like..."（我想要）、"Could I have..."（能给我...吗）、"I'm allergic to..."（我对...过敏）。Agent的引导必须围绕这几个目标句式，不能偏到讨论食材料理上去。

3.2 一个情景模板长什么样

我把每个情景都做成了独立的JSON配置，这样后续加场景完全不用动代码。下面这份是餐厅点餐的简化版：

{ "id": "restaurant", "title": "餐厅点餐", "level": "A2-B1", "objective": "能独立完成一次餐厅点餐，包括点菜、提出忌口、要求结账", "scenario_setting": "你在伦敦的一家意大利餐厅，服务员正在为你服务。", "roles": { "ai": "餐厅服务员，礼貌、温和，语速适中", "user": "顾客" }, "target_expressions": [ "I'd like...", "Could I have...?", "I'm allergic to...", "Can I have the bill, please?" ], "hints": { "vocab": ["menu", "appetizer", "main course", "dessert", "bill"], "patterns": ["I'd like + 菜品", "Could I have + 菜品 + please?"], "example": "I'd like the grilled chicken, please." }, "common_mistakes": [ { "wrong": "I want chicken.", "fix": "I'd like the chicken.", "note": "在餐厅里'I want'不够礼貌，用'I'd like'更自然。" } ], "stages": ["intro", "scenario", "guided_practice", "free_practice", "review"], "max_turns": 12, "review_dimensions": ["语法", "内容表达", "语言丰富度", "互动效果"] }

max_turns这个字段值得单独说。教学课不能无限聊下去，一般10到14轮之后就该进入总结和评分。如果用户一直表现得很好，状态机会自动推进到REVIEW；如果用户一直原地打转，到了最大轮数也要收束这节课，不能让它变成无意义的循环。这个设计在后期帮了大忙，避免了很多"聊不下去又结束不了"的尴尬局面。

3.3 System Prompt逐段拆解

情景配置是"静态知识"，System Prompt是"行为规则"，两者加在一起才能让Agent像老师。以下是我调试了十几版之后沉淀下来的Prompt模板，可以直接抄：

你是{role_ai}，正在进行英语情景教学。 【教学目标】 本次情景是：{scenario_title} 本节课的教学目标是让学生能够{objective} 【对话铁律】 1. 你只能用英语和学生交流，可以用极少量中文提示（仅在学生长时间无法理解时）。 2. 每轮对话最多说3句话，绝不替学生说完一句话。 3. 学生说错时，先用简短肯定（Good try/Almost），再给出正确说法，再给一句解释。 4. 学生卡住不说话时，先提示关键词，再给句式模板，最后才给完整示例。 5. 每轮结束前，默默判断状态，不要主动终结话题。 【引导策略】 - Level 1（学生完全说不出）：给1个关键词提示 - Level 2（学生说了但磕巴）：给句式模板填空 - Level 3（学生表达基本正确）：直接肯定并自然延续对话 【评分要求】 当用户说完最后一轮或达到轮次上限时，输出如下JSON结构，不要附加任何其他文字： { "scores": { "grammar": 0-10, "content": 0-10, "lexical": 0-10, "interaction": 0-10 }, "summary": "用三句话总结学生表现", "suggestions": ["建议1", "建议2"] }

我重点解释一下"对话铁律"里的第2条和第4条，这两条是让AI当老师的核心。

第2条"每轮最多3句话，绝不替学生说完一句话"，是直接针对大模型"太爱表现"的毛病。如果不设这条，你会发现AI经常一口气给你写出一段完整的英文，你只需要念一遍就行，这已经不是练习了，是配音。三条以内是刻意限制，让模型必须留白，把表达空间让给学生。

第4条"卡住时先提示关键词，再给句式，最后给示例"，这是教学里的"支架"理论。学生卡住时，老师不能立刻给答案，而是分级给帮助。这个分级我在Prompt里直接用Level 1/2/3写死，让模型不用自己琢磨该给多少帮助。

我还把"纠正格式"固定成了"肯定+正确+解释"三段式。这个格式看着简单，但非常有效。你想想真人老师是怎么纠错的——几乎都是先说"嗯，我听懂了"，再给出正确说法，最后说一句"因为什么"。如果Agent上来就劈头盖脸说"No, you should say...",学生几轮就被打击得不想开口了。这套格式不是我想的，是从教育心理学的反馈原则里搬过来的，只是让模型去执行。

4. 多轮对话管理：让对话成为一节有流程的课

4.1 为什么要用状态机

做了这个项目之后，我越来越认同一个观点：Agent不是一个聊天机器人，而是一套有目标、有状态、能调度工具的程序。如果只是把用户消息和System Prompt一起丢给模型，它天然倾向于均匀用力——开场白像闲聊，中段不知道推进目标，快结束了也没有收尾意识。

教学对话尤其需要"流程感"。你上一节英语课，不可能20分钟都停在"打招呼"环节；练习点餐，练到一定程度就得让他试试脱离提示独立完成一次点餐，最后还得有小结。这个流程感靠模型自发理解是不行的，必须由代码强制控制。

我的做法是在Agent主流程里维护一个教学阶段变量，每个阶段决定这轮消息的构造方式。

4.2 四个教学阶段的实现

from enum import Enum class Stage(str, Enum): INTRO = "intro" # 开场介绍 SCENARIO = "scenario" # 情景展开 GUIDED_PRACTICE = "guided" # 带引导的练习 FREE_PRACTICE = "free" # 自由练习 REVIEW = "review" # 总结评分

每个阶段做的事情不一样。INTRO阶段，我用系统消息直接输出开场，不允许用户提前进对话。SCENARIO阶段，AI以角色身份说出第一句情景引导语。之后进入GUIDED_PRACTICE，此时如果检测到用户连续两轮回复都很短（少于5个单词），就把引导Level提升一级；如果连续两轮回复都超过8个单词且没大错，就推进到FREE_PRACTICE。REVIEW阶段则是在轮次上限或者用户主动说"结束"时触发。

状态迁移的代码在这里，它决定了"什么时候该给帮助、什么时候该收课"：

def transition(self, user_input: str, prev_rounds: int): word_count = len(user_input.split()) if self.stage == Stage.GUIDED_PRACTICE: if prev_rounds >= 2 and word_count >= 8: self.stage = Stage.FREE_PRACTICE return if self.stage in (Stage.SCENARIO, Stage.FREE_PRACTICE): if prev_rounds >= self.scenario["max_turns"]: self.stage = Stage.REVIEW return

这个状态机看似简单，但它解决了一个很实际的问题：它把"教学策略"这种抽象的决策，从模型那里抽出来放到代码里了。模型不需要靠运气去理解"现在该不该推进"，代码直接告诉它。这样即使模型偶发抽风，教学流程也不会崩。

4.3 上下文管理与成本控制

多轮对话必然面对上下文膨胀的问题。一节课最长15轮，如果每轮都完整塞进上下文，再加上很长的System Prompt，一次调用可能就要消耗几千token，一节课下来成本相当可观。

我的处理办法是分块管理：固定的情景配置 + 当前教学阶段 + 最近6轮对话历史，拼成一次请求上下文。更早的对话不再逐字保留，而是每5轮自动让模型生成一句浓缩摘要，存进场变量里。比如"学生已完成点餐，成功表达了不吃香菜的需求，但不太熟悉过去时"。这句摘要在后续轮次里作为"已掌握情况"注入Prompt，让模型仍然"记得"前面的进展，但不需要每次都把全量历史翻出来。

这个裁剪策略在成本和效果之间取得了很好的平衡。实测下来，连续对话10轮以上，"还记得前面说过什么"这个需求95%靠最近几轮就能满足，真正需要跨10轮以上记忆的内容很少。当然，如果你的场景是"半个小时后还要回到上一节课"，那就得做持久化记忆了，这个我放在文章最后说。

5. 评分与反馈：Agent要会教，还要会评

5.1 评分维度是怎么定的

我一度想过直接用模型输出一个总分完事，但被一个做老师的同学否决了。她说，给学生的反馈如果只有一个总分，学生根本不知道下次怎么改。评分必须分维度，让问题显性化。

最后我定了四个维度：语法准确性（grammar）、内容表达完整度（content）、语言丰富度（lexical）、互动流畅度（interaction）。这四个维度覆盖了"说得对不对""说没说完""说得好不好""聊不聊得下去"四个方面，对学生改进有具体指向。

5.2 让模型输出结构化评分

评分靠的是模型在REVIEW阶段的判断。我给Prompt里明确规定了输出JSON结构，并且要求"不要附加任何其他文字"。但做过LLM开发的人都知道，模型输出JSON这件事，永远存在不稳定概率。哪怕你写了"必须只输出JSON"，它偶尔也会在前面加一句"好的，以下是评分："然后才输出JSON。

所以解析环节我做了三层容错：

import json, re def parse_review(raw: str) -> dict: # 第一层：直接解析 try: return json.loads(raw) except json.JSONDecodeError: pass # 第二层：用正则提取最外层大括号 match = re.search(r"\{.*\}", raw, re.DOTALL) if match: try: return json.loads(match.group()) except json.JSONDecodeError: pass # 第三层：把"```json"标记去掉后再试一次 cleaned = raw.replace("```json", "").replace("```", "").strip() return json.loads(cleaned)

三层容错处理了99%的情况，剩下1%我会让模型重试一次。这个不值得写复杂逻辑，重试一次就行。

5.3 语音评测的折中方案

做完文字版之后，我一度想加上发音评测。最理想的做法是用专门的发音评测API（比如科大讯飞那类专业服务），但价格和集成复杂度对个人项目来说偏高。我的折中方案是用Whisper做ASR转写，再比对"用户实际说的单词"和"标准文本"。

思路很朴素：学生在第5轮被要求表达一个特定句式，Whisper把她的语音转成文字，然后我用编辑距离算法算出转写文本和目标文本的匹配率。匹配率高说明发音清晰，低说明可能吞音、漏音或者表达偏了。但这个方案有个明显的坑：用户自由说一句话，Whisper转写出来和教学目标不匹配，不代表发音不标准，也可能是表达内容不同。所以我只把这个匹配率作为参考维度，不直接当成发音分数，最终还是靠模型综合判断。

关于语音的实际经验是：在界面层，语音输入和文本输入必须并行。很多人不愿意用打字练习口语——那太慢了；但在评测场景里，语音输入一旦失败，用户不至于完全卡死。我提供了两个输入框，默认语音输入，预览转写文本，用户确认后再提交。这个设计在试用阶段被验证为"是否愿意继续用下去"的关键体验点。

6. 调试实录：AI老师最常见的9个行为问题

6.1 问题清单与根因

主体功能三天就写完了，剩下两周半全在调行为问题。我把踩过的坑整理成了表格，这些都是"模型会在最不该犯错的地方犯错"的经典案例：

6.2 三个最有用的调试手段

如果只让我推荐三个调试技巧，我会说：few-shot示例、结构化约束、温度调节。

few-shot是最有效的。单靠规则描述，模型总会在边缘情况上犯错。我在每个情景模板里加了两个对话示例：一个是"学生卡壳时老师怎么引导"的正确案例，一个是"老师替学生说话"的错误案例。注意，错误案例也很重要——模型看反例比看正例更容易理解边界。加了反例之后，"替学生说完句子"这个问题发生率下降了至少一半。

结构化约束用在两个地方：评分JSON和检测"该给哪一级提示"。我让模型在一轮对话开始时先输出一个内部标记，比如"[[L2]]"表示我要给出Level 2的句式提示，然后再输出面向用户的文本。这个内部标记不会展示给用户，但会让模型的决策显性化，调试的时候能从日志里直接看到它的真实意图。

温度我只从0.7调到了0.3。教学Agent不需要创造力，需要稳定性。0.3这个值是我试过的甜点区间——再低会显得死板，再高又开始飘。

6.3 建立Prompt回归测试集

调Prompt最怕"修好一个问题，弄坏另一个问题"。后来我学聪明了，做了一套最小回归测试集：手工设计了10条典型用户回复，覆盖了"用户沉默""用户说中文""用户只用单词回答""用户完美表达""用户连续多轮说错"等常见情况。每次修改Prompt，我就把这个测试集跑一遍，看每条回复下的Agent行为是否符合预期。

这套测试集不到两百行代码，但它成了整个项目最重要的资产。我可以放心地试新Prompt，出了问题马上能定位是哪条案例被破坏了。如果你也要做类似的Agent项目，我强烈建议第一天就把测试集建起来。用LLM做产品，规则是写不完的，但测试集是可控的。

7. 交互界面与部署：从代码变成能用的产品

7.1 用Gradio搭教学界面

后端逻辑再完善，没有一个好用的界面，项目就停留在"能跑"而不是"能用"。我用Gradio搭了一个极简但完整的教学界面，包括三块：顶部是一个情景下拉框，中间是聊天区，底部是输入区（支持文字和语音）。

核心代码其实很短：

import gradio as gr with gr.Blocks() as demo: gr.Markdown("# 英语情景教学Agent") with gr.Row(): scenario_dropdown = gr.Dropdown( choices=["restaurant", "airport", "interview"], label="选择情景" ) start_btn = gr.Button("开始新一节课") chatbot = gr.Chatbot(height=450) text_input = gr.Textbox(placeholder="在这里输入你的英文回答...") state = gr.State() # 保存Agent实例和对话缓存 start_btn.click(start_lesson, [scenario_dropdown, state], [chatbot, state]) text_input.submit(handle_user_input, [text_input, state], [chatbot, state])

有个体验细节值得提：在学生说完整句之前，界面上不要预置任何"标准答案"文本。我一开始在情景下方显示了几条例句给学生参考，结果发现几乎所有试用者都会直接照着念，完全没经过思考。后来我把例句藏到一个"实在没思路再点开"的折叠区域，练习效果立刻好了很多。教学产品的交互设计，本质上也是教学法的一部分。

7.2 部署与合规的注意点

部署方面，如果只是自己用或者小范围测试，本地跑就够了。要给一个班的学生用，我建议放到国内云服务器上，把模型API的key留在服务端，用户通过网页访问，不要暴露在客户端。数据方面，学生对话内容要定期清理，界面上明确提示"对话用于练习，不会用于其他用途"。如果面向未成年人，还要注意内容安全过滤，不能让Agent在自由对话中被诱导聊一些不适合未成年人的话题。这些不是技术难题，但必须在产品阶段考虑进去，否则后患无穷。

我不太推荐在初期就上很重的服务化架构。这个项目完全可以把界面、状态机、模型调用装在一个进程里，等真有了大量并发需求再拆服务也不迟。开发的第一原则永远是先跑通，再优化。

最后分享一点我的体会。三周做完这个项目，我发现"开发一个Agent"的技术门槛已经很低了，真正有门槛的是你想让这个Agent在哪个专业领域里稳定工作。如果它只是一个通用聊天窗口，价值平平；但如果它承载了一套教学SOP、一个评分体系、一种纠错的节奏感，它就开始像一个真正的老师了。这个过程里，我最大的收益反而不是Agent技术，而是逼着自己把"教英语"这件事拆成了可计算的规则。

后面我想给它加两个能力：一个是长期记忆，记录每个学生反复犯的错误，下次课程开始时自动复习；另一个是把几个情景串成一条难度曲线，让学生的练习像打游戏闯关一样有进阶感。如果你也在这类项目上折腾，欢迎一起交流。