不像面试题-技术负责与架构决策

「随便聊聊」才是真面试：4 道不像面试题的架构决策题

技术面最难受的不是被问住，是面试官说「随便聊聊」，然后扔过来一个没有标准答案的问题。你越答得像背模板，分越低。

这类题有个共同点：它们没有正确答案，只有水平高低。下面 4 道是 25 道题里最能分档的。

---

一、没有 LangChain 这类框架，你怎么开发 Agent？

这题不考你熟不熟框架，考你知不知道框架替你做了什么。 只会写 AgentExecutor(...) 的人，遇到框架不支持的场景就废了。

答法：拆成 6 层，一层一层说「这层干什么、没框架我自己怎么实现」。

1. 主循环 —— 整个 Agent 的心脏，本质就是个 while：组装上下文 → 调模型 → 有工具调用就执行并回填历史 → 没有就结束。
2. 工具层 —— 工具只要三样东西：名称、参数 schema、它会不会改外部状态。第三样最容易被漏，但它决定后面能不能重试。
3. 上下文层 —— 别把聊天记录整个丢进去。历史要裁剪、工具描述要按需加载、任务状态要单独注入，构造一个最小的 json。
4. 状态层 —— 多轮任务得有地方存中间结果，否则一中断就得从头再来。
5. 可观测层 —— trace、每步耗时、中间产物。没这层，Agent 出错你只能看到「它答错了」，看不到「它从第几步开始错」。
6. 成本层 —— token、工具调用次数、存储、缓存。

插一句：剩下 21 题，我整理成笔记了

上面 4 道是从 25 道题里挑的。剩下 21 道（含每题完整拆解、追问话术、踩坑记录）塞不进一篇文章，都整理成笔记了：

笔记就长这样，25 题全在里面。 想要整份的，扫码加我，备注「笔记」👇

不用关注、不用转发，加上直接发你。

---

二、系统出事了，先保住什么？

考的是降级分级能力。答不出分级，说明你没在故障现场待过。

所有功能先分三类：

级别	典型功能	处理
不能到	下单、付款、登录、查订单	挂了就是事故
可以降	推荐位、评价、相关推荐	给兜底，别报错
可以没有	排行榜、弹幕、皮肤	直接关

注意第二类：降级的关键不是「关掉」，是关掉之后用户看到的还是个正常页面。

处理顺序：能不能不要它 → 能不能晚点补 → 都不行，才多备一份。

追问预警：「降级开关谁来按？」——必须有人、有阈值、有话术。否则真出事时全在等别人按。

---

三、边缘场景频繁超时，先改架构还是先改代码？

这题的分水岭是：你有没有先看数据，而不是先动手。

先看超时分布——是整体都慢（资源/容量问题），还是只有长尾慢（慢查询、外部依赖、特定参数）？分布决定方向，凭感觉改一定改错地方。

然后才是顺序：

1. 先止血 —— 超时时间、重试策略、熔断、兜底返回。这些是配置级动作，当天能上。
2. 再定位 —— 拿 trace 找最慢的那一段，而不是猜。
3. 最后才谈架构 —— 只有当「同一类超时反复出现、且每次都不是同一个原因」时，才是架构问题。

点睛：边缘场景超时，90% 不是架构不行，是没有超时预算的概念——每个下游各花 3 秒，链路一长必然超。

---

四、方案纸面完美，但团队没人有把握，上不上？

先分类，再回答，这是这道题真正的分水岭：

• 战略性的技术投入 → 可以上，本来就是赌未来，没把握是常态；
• 项目交付性的技术选择 → 不能上，交付要确定性，不要先进性。

三个判断问题：

1. 失败代价谁承担？公司、客户，还是你的绩效？
2. 有没有退路？能灰度、能回滚、能留降级开关吗？
3. 能不能延后？等两周会不会有更多信息？

再把「没把握」拆开：不会但能学会 → 能力缺口，可补，只要评估学习成本；不会而且出了事没人看得出来 → 坚决不上。看不懂的系统，出事连定位的人都没有。

---

最后

这 4 道看似在问技术，实际在考同一件事：你做决策时，是靠数据、靠分级、靠退路，还是靠感觉。

面试前一天扫一遍上面四条就行。篇一讲的是「怎么想」，另外六篇讲「怎么答」：