第 1.3.5 节：讲清 Mock 模式和真实供应商接入的切换方式
Mock 模式只有拆成可执行步骤，才容易复核、排错和交接。完成本节后，你应该能够按顺序说明 Mock 模式的触发、处理、复核、记录和兜底步骤。
本节交付物与面试讲法
练习题
基础练习
解释为什么“把公司所有资料直接塞给模型”不是一个可靠方案。
项目练习
设计一个 .env.example，至少包含：
APP_MODEMODEL_PROVIDERMODEL_NAMEOPENAI_API_KEYDEEPSEEK_API_KEY
注意不要写真实 Key（密钥）。
挑战任务
为“企业知识库问答系统”设计模型调用流程，说明哪些内容进入 Prompt（提示词），哪些内容留在数据库，哪些内容通过 RAG（检索增强生成）检索。
面试官追问与回答要点
这一章常见追问集中在“你如何把模型当成可治理服务”。
| 追问 | 回答要点 |
|---|---|
| 如果模型供应商临时不可用，系统怎么处理？ | 模型调用要有超时、重试、排队、降级和人工转接；业务层不要直接依赖单一 SDK（软件开发工具包）。 |
| 工具结果很长，是否全部发给模型？ | 不应该。要把工具结果摘要成用户可见结论、关键字段和风险提示，避免泄露敏感字段并控制 Token（文本计量单位）。 |
| 什么时候用强模型，什么时候用便宜模型？ | 高风险、复杂推理、用户可见回复用更强模型；批量摘要、分类、低风险任务可以用低成本模型，但都要用验收样例验证。 |
| 真实模型模式和 Mock（模拟）模式输出不同怎么办？ | 两种模式必须遵守同一份输入输出契约，Mock（模拟）用于验证流程，真实模型用于验证效果。 |
| 如何证明你控制了模型成本？ | 记录 Token（文本计量单位）、耗时、模型名、调用场景和错误，按任务设置上下文预算和最大输出。 |
面试题和推荐回答
| 面试官可能问 | 推荐回答要点 | 常见扣分点 |
|---|---|---|
| Token（文本计量单位）对 AI（人工智能）项目有什么影响？ | 它影响上下文容量、成本、延迟和稳定性。客服项目里，系统提示、历史、检索片段、工具结果和输出都会消耗 Token（文本计量单位）。 | 只说“字数单位”。 |
| 上下文窗口变大后，RAG 还有没有必要？ | 仍然有必要。RAG 解决资料选择、更新、权限和引用问题，不只是弥补上下文长度。 | 认为大上下文可以替代知识库。 |
| 为什么测试环境默认应该使用 Mock（模拟）模式？ | Mock（模拟）能稳定复现流程，不依赖网络、额度和密钥，适合自动化测试和无密钥学习。 | 认为 Mock（模拟）没有真实价值。 |
| API Key（接口密钥）应该如何管理？ | 放环境变量或安全配置，不进代码、文档、截图和日志；泄露后要轮换。 | 在示例里写真实密钥。 |
| 如何设计一个最小模型适配层？ | 业务层只依赖统一的模型调用契约，供应商、模型名、模式、重试和日志在适配层处理。 | 把业务逻辑写死在某家 SDK（软件开发工具包）里。 |
| 模型调用失败时客服系统怎么办？ | 根据失败类型处理：超时重试，限流排队或降级，输出无效则重新生成或转人工，不能编造结果。 | 只说“捕获异常”。 |
| 如何控制客服 Agent（智能体）的模型成本？ | 做 Token（文本计量单位）预算、限制历史长度、减少无关资料、分任务选模型、记录用量并定期复盘。 | 只说“选便宜模型”。 |
| 多模型适配有什么实际价值？ | 它能降低供应商锁定风险，也能按任务选择不同模型，比如高风险投诉用强模型，批量摘要用低成本模型。 | 为了炫技接很多模型但没有业务理由。 |
本章交付物
| 交付物 | 本章产出 |
|---|---|
| 系统流程图 | 模型调用最小 sequenceDiagram（序列图）。 |
| 字段契约表 | 模型请求、上下文、输出契约和用量记录字段。 |
| 失败与兜底表 | 超时、限流、上下文过长、格式无效、密钥泄露和编造政策的处理方式。 |
| 面试讲法 | 能把模型调用讲成外部服务治理、上下文预算和供应商适配，而不是一次 API（应用程序接口）请求。 |
小结
模型调用是 AI Agent 项目的底座，但不是整个系统。工程师必须理解模型、Token（文本计量单位）、上下文、API Key（接口密钥）、供应商适配和运行模式之间的关系。
下一章会继续往上走，讲 Prompt 与结构化输出。你会看到，模型输出不能只靠“写得像 JSON（结构化数据格式）”，而应该被当成工程接口来设计和校验。