综合模拟面试 3 · 工程落地与设计#

面试官画像: CTO / 技术总监，考察系统设计、技术判断力、全局视野时长: 45 分钟 · 难度: ★★★★★ 覆盖方向: 技术选型 → 工程基础设施 → 成本控制 → 部署运维 → 未来规划

第一阶段 · 技术选型（10 分钟）#

面试官: 为什么选 LangGraph 不自己写 Agent 循环？

候选人: LangGraph 提供三个关键能力：middleware 挂载点让 Harness 无侵入接入、recursion_limit 做迭代兜底、终结性工具检测做自然终止。自己写要重新实现这些。但我们大量主动更正了 refdocs 的设计——create_react_agent 废弃改 create_agent、post_model_hook 改 middleware、全局 store 改选后端 Store。框架学思想，代码不照抄。

面试官: 向量库为什么选 Qdrant 不选 Milvus？

候选人: 原生 payload filter（价格/平台/评分可在向量搜索时过滤），单节点开箱即用。Faiss 不支持 payload filter，Milvus 适合分布式但当前规模不需要。

面试官: 偏好存储为什么用 SQLite 不用 Redis？

候选人: 零依赖、开发期够用、接口与 Redis 同构（read/write/delete）。切 Redis 只需改 env 配置。YAGNI——当前不需要多实例共享。

第二阶段 · 工程基础设施（15 分钟）#

面试官: 你做了哪些后端工程增强？

候选人: P0+P1 共 7 块已全部落地：① 并发背压（任务槽+fork Semaphore+429）② 韧性工程（断路器+退避重试+降级链）③ 可观测性（Prometheus /metrics + structlog）④ 事件回放（Redis Stream 断线补发）⑤ 语义缓存（category_insight 弱时效域）⑥ FinOps 预算闸（全树聚合+越线夺权收尾）⑦ JWT 鉴权（身份只认 token 的 sub）

面试官: 账户体系怎么做的？

候选人: SQLAlchemy + Alembic 可追踪迁移。JWT 鉴权校验 sub 绑定 user_id。WS token 走 query 参数（日志留明文，接受的 trade-off）。M16 已落地，公网部署开放注册。

面试官: 部署架构？

候选人: 单节点 VPS（gcjp），Docker Compose 编排（FastAPI + Qdrant + OpenSearch + Redis）。前端 Vite build 静态文件由 FastAPI 代理。tar-over-ssh 部署。Qdrant 快照跨版本恢复必炸——升级需重建索引。

第三阶段 · 成本控制（10 分钟）#

面试官: Token 成本怎么控制？

候选人: 四层：① FinOps 预算闸（全树 token 聚合，越线夺权收尾）② 四档模型路由降级 ③ 子 Agent 关 reasoning 省解码 ④ Cache Breakpoint 保前缀缓存命中。端到端一次购物链路 token 成本实测在可接受范围。

面试官: 延迟和成本的 trade-off？

候选人: 96% 延迟是 LLM 解码——省 token = 省延迟。子 Agent 关 reasoning 一刀两得。但 fallback 档牺牲质量换成本，是显式 trade-off。

第四阶段 · 诚实边界（10 分钟）#

面试官: 你觉得这个项目最大的短板？

候选人: 三个。① LLM 单点依赖（一个 provider 挂了全停）② 进程内状态（多副本需迁 Redis）③ 数据偏斜（amazon 占 99.75%）。每个都有升级路径但还没做——YAGNI，当前规模不需要。

面试官: 如果重新来过会做什么不同？

候选人: ① 候选缓存从 module dict 改 ContextVar 防多会话串扰 ② 评测集从一开始就做大（18 条太少）③ 部署从一开始用 CI/CD 而非手动 tar-over-ssh。