Interview on Hao · AI Agent 学习记录

第 1 章面试 · 05 LLM Gateway（统一模型调用服务）

Mon, 10 Aug 2026 20:50:00 +0800

目标岗位：Agent Harness 研发/工程方向（参考 ~/agent/jb/jd.md）配套讲义：讲义 05 · LLM Gateway 用法：先自己口头答一遍，再对照"参考回答"；重点看"考察点"和"坑"。原则：所有回答结论先行 → 项目证据 → 原理 → 边界与改进，不要背概念。

0. 面试官视角：Gateway 题到底在考什么

Gateway 是"把分散的厂商调用收敛成平台能力"的典型系统设计题：

概念层：Gateway 解决什么问题（密钥、协议、可观测）；
实践层：你的网关怎么分层、每个模块在哪、有没有测试；
判断层：为什么这么设计？并发和性能边界？新增厂商要改什么？——拉差距。

回答公式：一句话结论 → 你项目里的实现/例子 → 原理 → 边界与改进。

1. 按讲义章节的题目与参考回答

Q1：LLM Gateway 解决什么问题？为什么不直接让业务调厂商 SDK？

参考回答：四个问题——密钥分散（每个组件持 key，泄露面大）、协议差异（每家格式不同）、不可观测（没有统一日志）、无法统一治理（限流/回退/成本）。网关收敛成一层：密钥集中在 config 层、协议统一成 OpenAI Compatible、每次调用留痕、限流回退统一做。我的网关 create_app 组装了路由、限流、模板、用量、provider 链，业务只发 HTTP。

Q2：密钥为什么集中？怎么防泄露？

参考回答：集中后业务组件不碰厂商密钥，泄露面从"每个组件"缩小到"网关一个点"。密钥从环境变量读（config.py，支持 DASHSCOPE_API_KEY 等厂商命名空间），不进代码库。诚实边界：网关本身是新的攻击面——生产上密钥应放密钥管理服务（KMS/Vault），网关进程还要做最小权限和审计。

Q3：为什么对外统一成 OpenAI Compatible，而不是自定义协议？

参考回答：OpenAI Compatible 是事实标准，DeepSeek、DashScope、本地 Ollama/vLLM 都兼容，生态里现成 SDK 和工具直接可用。对内用 ChatProvider 接口 + adapter 屏蔽差异（讲义 01 §6），对外格式稳定、对内可演进。收益：换厂商不改业务代码、OpenAI 官方 SDK 能直连网关。

第 1 章面试 · 04 Structured Output 结构化输出

Mon, 10 Aug 2026 20:40:00 +0800

目标岗位：Agent Harness 研发/工程方向（参考 ~/agent/jb/jd.md）配套讲义：讲义 04 · Structured Output 用法：先自己口头答一遍，再对照"参考回答"；重点看"考察点"和"坑"。原则：所有回答结论先行 → 项目证据 → 原理 → 边界与改进，不要背概念。

0. 面试官视角：结构化输出题到底在考什么

结构化输出是 Agent 工程的地基——工具调用、下游解析全靠它。面试官三层递进：

概念层：JSON Schema、Pydantic、原生结构化输出是什么；
实践层：你项目里三家厂商怎么实现的？校验失败怎么处理？
判断层：为什么不能只靠 prompt？失败降级怎么设计？流式 + 结构化怎么组合？——拉开差距的地方。

回答公式：一句话结论 → 你项目里的实现/例子 → 原理 → 边界与改进。

1. 按讲义章节的题目与参考回答

Q1：为什么 Agent 系统不能依赖自然语言解析？

参考回答：模型输出要喂给代码——查词结果填卡片、工具参数发请求、SQL 要执行。自然语言输出换行、加粗、解释文字都会破坏解析；更糟的是解析失败时分不清是"格式错了"还是"答案错了"。所以原则是协议先行 + 校验兜底 + 失败有出路：先定义输出形状，返回后校验，不过就纠错重试或降级，绝不把脏数据传给下游。

考察点：能不能说出"解析失败无法区分错误类型"这个深层原因。

Q2：JSON Schema 有哪些关键字段？additionalProperties 为什么重要？

参考回答：type（对象/数组/标量）、required（必填）、properties （字段类型）、数组的 items/minItems、字符串的 enum。additionalProperties: false 很重要——它禁止模型自作主张加字段，协议边界一旦被突破，下游解析就容易悄悄出错。我 /v1/structured 的 schema 都关掉了多余字段。

第 1 章面试 · 03 Prompt Engineering

Mon, 10 Aug 2026 20:30:00 +0800

目标岗位：Agent Harness 研发/工程方向（参考 ~/agent/jb/jd.md）配套讲义：讲义 03 · Prompt Engineering 用法：先自己口头答一遍，再对照"参考回答"；重点看"考察点"和"坑"。原则：所有回答结论先行 → 项目证据 → 原理 → 边界与改进，不要背概念。

0. 面试官视角：Prompt 题到底在考什么

Prompt 题最容易答成"背技巧"，面试官想听的是：

概念层：System Prompt、Few-shot、注入是什么；
实践层：你的模板怎么管理、注入怎么防、版本怎么回滚，代码在哪；
判断层：隔离为什么不是银弹？Prompt 变更怎么灰度？怎么评估 Prompt 好坏？——这里拉开差距。

回答公式：一句话结论 → 你项目里的实现/例子 → 背后的原理 → 边界与可改进点。

1. 按讲义章节的题目与参考回答

Q1：System Prompt 和普通用户消息有什么区别？你们怎么管理 System Prompt？

参考回答：System Prompt 是"岗位说明书"——定义角色、目标、边界和输出约定，独立于用户消息（role: system），模型通常给它更高权重。我把 System Prompt 当成模板资产管理：prompts.json 里存 reading_assistant 这类模板，带变量（{user_level}）和版本号，网关 /v1/prompts 统一渲染，业务层只传变量。这样角色设定变更走模板版本，不碰业务代码。

考察点：能不能区分"角色设定"和"用户消息"两个通道；模板化管理的动机。

Q2：角色定义怎么写才有效？

参考回答：角色定义 = “你是谁 + 怎么干活”，关键是行为约束要具体。弱约束 “你是代码审查助手"模型会自由发挥；强约束要写明审查维度、每个问题的输出要素、以及"没有问题时明确说无问题，不要编造”。我的种子模板 translate_assistant 就是"只输出译文"这种带边界的角色，约束和输出协议分开写。

第 1 章面试 · 02 Streaming 流式输出

Mon, 10 Aug 2026 20:20:00 +0800

目标岗位：Agent Harness 研发/工程方向（参考 ~/agent/jb/jd.md）配套讲义：讲义 02 · Streaming 流式输出用法：先自己口头答一遍，再对照"参考回答"；重点看"考察点"和"坑"。原则：所有回答结论先行 → 项目证据 → 原理 → 边界与改进，不要背概念。

0. 面试官视角：流式题到底在考什么

流式是"理论简单、工程全是坑"的题目，面试官按三层递进：

概念层：SSE 是什么、TTFB 是什么；
实践层：你的网关/前端怎么实现的，能不能现场演示；
判断层：两段流式缺一段会怎样？取消怎么贯穿三层？流中出错为什么不能重试？长文本断了怎么办？——这一层才是拉开差距的地方。

回答公式：一句话结论 → 你项目里的实现/例子 → 背后的原理 → 边界与可改进点。主动说"这里我做得不彻底，我的方案是 X"，比被追问出来强得多。

1. 按讲义章节的题目与参考回答

1.1 为什么需要 Streaming

Q1：流式和非流式在用户体验上差在哪？你项目里有数据吗？

参考回答：LLM 生成要几十秒，非流式是"等全部生成完才出现第一个字"，用户看到一片空白；流式是"边生成边显示"，用户感知延迟从"总耗时"降到"第一个 token 的时间"。我首页有个对比面板：同一消息 × 两种模式并排跑，流式栏会显示首字节耗时、总耗时、分片数和分片表。改流式链路之前实测过一次：非流式总耗时 20662ms，流式首字节 20655ms——首字节几乎等于总耗时，这恰恰暴露了"上游整体缓冲后回放"的问题，说明只传 stream: true 而不打通传输层，用户体验没有任何提升。

考察点：是否真的理解"感知延迟"；能不能用自己项目里的指标讲，而不是背概念。

Q2：首字节耗时（TTFB）和总耗时有什么区别？

参考回答：TTFB 是请求发出到收到第一块内容的时间，总耗时是收到最后一块的时间。非流式里两者基本相等（必须等完整结果）；真流式里 TTFB 约等于"模型生成第一个 token 的时间"，总耗时不变但感知变快。工程上这是流式最重要的监控指标——如果首字节≈总耗时，说明链路里某一段被缓冲了（浏览器、反向代理、或者上游 HTTP 客户端整体读 body）。

第 1 章面试 · 01 LLM API 与模型调用基础

Mon, 10 Aug 2026 20:10:00 +0800

目标岗位：Agent Harness 研发/工程方向（参考 ~/agent/jb/jd.md）用法：先自己口头答一遍，再对照"参考回答"；重点看"考察点"和"坑"。原则：所有回答结论先行 → 项目证据 → 原理 → 边界与改进，不要背概念。

0. 面试官视角：这类题到底在考什么

同样的知识点，面试官会按三层递进考察：

概念层：懂不懂（Chat Completions 结构、token 是什么）；
实践层：做没做过（你项目里怎么实现的，代码在哪）；
判断层：为什么这么设计、哪里做得不好、怎么改（这是拉开差距的地方）。

回答公式：一句话结论 → 你项目里的实现/例子 → 背后的原理 → 边界与可改进点。最后一步尤其重要——主动说"这里我还没做/做得不好，我的方案是 X"，比被追问出来强得多。

1. 按讲义章节的题目与参考回答

1.1 Chat Completions / Responses API

Q1：你们网关为什么对外暴露 chat.completions，而不是直接调各家 SDK？

参考回答：因为 chat.completions 是事实标准，DeepSeek、DashScope、Moonshot、本地 Ollama 都提供兼容端点。我在 provider 层定义了统一接口 ChatProvider，各家用 adapter 做格式转换（openai_compatible.py / anthropic.py / gemini.py），上层代码只认一个接口。收益是：换模型不改业务代码、可以跨厂商回退、用量和错误统一统计。本质是把"协议差异"收敛到 adapter 层。

考察点：是否理解"统一抽象"的动机（协议差异、切换成本、回退、可观测）。

Q2：Chat Completions 和 Responses API 有什么区别？你们为什么没做 Responses？

Interview on Hao · AI Agent 学习记录

第 1 章面试 · 05 LLM Gateway（统一模型调用服务）

0. 面试官视角：Gateway 题到底在考什么#

1. 按讲义章节的题目与参考回答#

第 1 章面试 · 04 Structured Output 结构化输出

0. 面试官视角：结构化输出题到底在考什么#

1. 按讲义章节的题目与参考回答#

第 1 章面试 · 03 Prompt Engineering

0. 面试官视角：Prompt 题到底在考什么#

1. 按讲义章节的题目与参考回答#

第 1 章面试 · 02 Streaming 流式输出

0. 面试官视角：流式题到底在考什么#

1. 按讲义章节的题目与参考回答#

1.1 为什么需要 Streaming#

第 1 章面试 · 01 LLM API 与模型调用基础

0. 面试官视角：这类题到底在考什么#

1. 按讲义章节的题目与参考回答#

1.1 Chat Completions / Responses API#

0. 面试官视角：Gateway 题到底在考什么

1. 按讲义章节的题目与参考回答

0. 面试官视角：结构化输出题到底在考什么

1. 按讲义章节的题目与参考回答

0. 面试官视角：Prompt 题到底在考什么

1. 按讲义章节的题目与参考回答

0. 面试官视角：流式题到底在考什么

1. 按讲义章节的题目与参考回答

1.1 为什么需要 Streaming

0. 面试官视角：这类题到底在考什么

1. 按讲义章节的题目与参考回答

1.1 Chat Completions / Responses API