一、Agent 核心(Chat Agent 项目)
核心1. ReAct Loop 自研
必须能讲清楚:你的 ReAct Loop
每一步的角色(思考→工具选择→执行→观察→判断循环),与标准 ReAct
论文的差异点。
追问方向:
-
"自研"体现在哪里?(强调在循环控制、收敛判断、错误兜底上的自定义逻辑,而非仅调用
SDK)
-
单轮最多 10 轮/单工具最多 5
次,这个阈值怎么定的?有没有做过消融实验?
-
如果模型在某一轮"思考"错了,怎么纠偏?有没有做 reflection
或回退机制?
💡 建议准备:画一张状态流转图,标注硬约束(10轮/5次/相似度0.7)和软引导(收敛提示)分别在哪个节点生效。
核心2. MCP 工具调用链路
必须能讲清楚:MCP
协议的核心交互模型(初始化→工具发现→调用→结果返回),你的工具描述(description)是怎么设计的。
追问方向:
-
工具描述怎么写才能减少模型误调用?(字段设计、示例注入、边界说明)
-
工具结果返回后,怎么结构化渲染到前端?(原始 JSON 还是 UI
适配?)
- 如果工具执行超时或报错,怎么反馈给模型让它做下一步决策?
💡 建议准备:准备 1-2 个具体工具(如
web_search、code_execution)的完整调用链路口述。
核心3. 工具调用稳定性治理
必须能讲清楚:"模型反复调用 web_search
无法收束"这个问题的根因,以及你的双层机制设计。
追问方向:
-
相似度 0.7 去重是怎么算的?(URL 去重还是内容去重?embedding
还是字符串匹配?)
- 软引导的"收敛提示"长什么样?是每轮动态拼接还是固定模板?
-
执行层兜底过滤已抓 URL,这个过滤是在服务端做还是传给模型做?
-
如果用户问一个确实需要多次搜索的复杂问题,硬约束会不会误杀?
💡 建议准备:准备"收敛提示"的示例文案,说明怎么在"限制滥用"和"保证必要调用"之间平衡。
二、上下文与 RAG(Chat Agent 项目)
核心4. 上下文压缩策略
必须能讲清楚:"单轮工具链路控量 +
多轮历史记忆治理"的两阶段策略,具体怎么落地。
追问方向:
-
工具结果从 6k→5k
token,压缩逻辑是什么?(相关性筛选的标准?摘要模型还是规则截断?)
-
"超模型上限 80% 强制熔断",这个 80% 怎么定的?是 token
数还是字符数?怎么精确计算?
-
多轮间的"增量摘要":是每轮都把历史重新摘要一遍,还是只摘要窗口外的内容?
-
窗口截断 +
增量摘要,怎么保证摘要后的语义连贯性?(面试官极可能追问 merge
逻辑)
💡 建议准备:口述一个长对话场景(比如 20
轮后),消息是怎么被压缩和保留的。
核心5. RAG /
文档查询(Context7)
必须能讲清楚:Context7
在你的系统里扮演什么角色,向量检索链路怎么走的。
追问方向:
-
pgvector 的索引类型(IVFFlat /
HNSW)?怎么选的?数据量多大?
- 文档是怎么切分的?chunk size 和 overlap 怎么设置?
-
向量检索后有没有做重排序(rerank)?还是直接取 Top-K 塞进
prompt?
- 如果检索到的 chunk 与用户问题语义不匹配,怎么兜底?
💡 建议准备:简要说明文档解析(PDF/图片)→ 切分 →
embedding → 检索 → 注入 prompt 的完整链路。
三、工程架构与部署(Chat Agent 项目)
工程6. SSE 流式通信与断连恢复
必须能讲清楚:FastAPI StreamingResponse
的实现细节,前端自动重连与续传机制。
追问方向:
-
SSE 与 WebSocket 在这个场景下为什么选 SSE?(单向推送、基于
HTTP、自动重连)
-
断连期间的"内存队列"补偿:队列存在哪里?服务端重启怎么办?
- 高并发场景下内存队列的容量上限和淘汰策略?
-
后续计划用 Redis Stream,如果现在让你改,怎么设计消息 ID 和 ACK
机制?
💡 建议准备:口述 SSE
连接→断连→重连→续传的消息时序图。
工程7. 代码执行安全(Piston)
必须能讲清楚:Piston
的沙箱隔离原理,以及你叠加的应用层安全策略。
追问方向:
-
Piston 的任务级运行时隔离具体指什么?(Docker
容器隔离还是进程级隔离?)
- 默认禁止网络访问是怎么实现的?iptables?DNS 拦截?
-
如果用户代码有死循环,10s 超时怎么中断?(信号量?kill 进程?)
- 有没有考虑过沙箱逃逸风险?
💡 建议准备:强调"双层安全模型"——Piston 沙箱 +
应用层超时/网络限制。
工程8. 生产级部署与运维
必须能讲清楚:Docker Compose 编排结构,Nginx
反向代理配置,HTTPS 证书管理。
追问方向:
-
为什么是 Docker Compose 而不是 K8s?(个人项目体量、成本权衡)
-
Webhook 自动构建的流程:GitHub Action 还是自建
CI?构建缓存怎么做的?
- 日志收集和监控告警有没有做?(Prometheus/Grafana)
- 数据库备份和迁移策略?
💡 建议准备:准备一张部署架构图(Nginx → FastAPI →
PostgreSQL/Redis)。
四、基础设施(GEO 采样工具项目)
基建9. Kafka 消费治理
必须能讲清楚:并发阈值控制、暂停/恢复机制的设计动机和实现。
追问方向:
-
Kafka consumer group 的 partition 分配策略?并发控制是在
consumer 端还是 partition 端?
- "任务与资源状态不一致"具体指什么场景?怎么发现的?
- 暂停/恢复是基于什么指标触发的?(手动还是自动?)
- Kafka 消息有没有做幂等处理?防止重复采样?
💡 建议准备:口述一个任务从入队→消费→执行→状态回写的完整状态机。
基建10. Redis 账号池与代理治理
必须能讲清楚:账号预占、分层冷却、动态冷却的实现。
追问方向:
-
Redis 账号池的数据结构是什么?(Hash?List?ZSet
按成功率排序?)
-
"预占"是怎么实现的?(SETNX 分布式锁?还是 LPOP 原子出队?)
- 代理摘除后怎么恢复?(定时探测还是手动介入?)
-
随机打散冷却时间是为了避免什么?(避免瞬时流量高峰被风控)
💡 建议准备:强调反爬策略的工程化思路——"把反爬当成常态故障处理"。
基建11. MySQL 与数据存储
必须能讲清楚:GEO
平台的数据模型设计,采样结果怎么存。
追问方向:
- 采样结果(截图、结构化数据)是存 MySQL 还是对象存储?
- 如果数据量大,有没有做分表或归档策略?
- Playwright 采集的 HTML 体积很大,怎么存储和索引?
- 查询性能优化:索引怎么设计?
💡 建议准备:准备核心表结构(任务表、账号表、采样结果表)的 ER 关系口述。
基建12. Playwright 与自动化采集
必须能讲清楚:为什么选择 Playwright 而不是直接调用
ChatGPT API。
追问方向:
-
Playwright
的浏览器实例是怎么管理的?(常驻还是每次任务新建?pool 化?)
- 页面渲染等待策略?(waitForSelector?固定延时?)
-
资源消耗情况:一个浏览器实例占多少内存?并发上限受什么制约?
- 与前端 Chrome Extension 录制方案的技术关联。
💡 建议准备:结合两个项目,说明 Playwright
在不同场景下的应用。
五、前端工程(全栈视角)
前端13. React / TypeScript /
状态管理
必须能讲清楚:Chat Agent
前端的消息状态管理(多轮对话、工具结果渲染、SSE 消息拼接)。
追问方向:
-
消息列表的渲染优化:长对话 50+
轮,怎么避免重渲染性能问题?(虚拟列表?)
-
工具结果(如代码执行返回的 JSON)是怎么渲染成 UI
的?(动态组件映射?)
-
多模态输入(图片/PDF)的前端处理:文件上传→预览→发送的链路?
💡 建议准备:强调 Redux Toolkit 或 React Context
在消息状态管理中的取舍。
前端14.
复杂编辑器状态(站外广告项目)
必须能讲清楚:Campaign/AdSet/Ad
三层树结构的跨层级联动校验。
追问方向:
-
异步校验与表单状态触发时机不一致,具体是什么问题?(竞态?防抖?)
-
双向模型转换:前端表单 ↔ 后端 API 的数据结构差异怎么抹平?
- 批量编辑组件的"配置驱动"设计:是 JSON Schema 还是 DSL?
💡 建议准备:这个项目虽然离 Agent
较远,但能体现你处理复杂状态的能力,准备 1 个技术难点即可。
六、开放性问题 & 场景设计(高频压轴题)
15. 如果让你重构 Chat Agent,你会怎么做?
🚀 建议方向:
- 上下文压缩引入语义化评分模型(替代规则策略)
- SSE 内存队列升级为 Redis Stream(支持多实例)
-
ReAct Loop 引入 Plan-and-Execute 或 Reflection
机制(提升复杂任务成功率)
- 工具调用引入 Toolformer 或学习式调度(替代固定阈值)
16. 如果 Agent 需要支持 10w QPS,你的架构怎么改?
🚀 建议方向:
- 推理层:模型调用接入批处理或专用推理服务(vLLM/TGI)
-
状态层:对话历史从内存/PostgreSQL 迁到 Redis Cluster + 分片
-
工具层:工具执行异步化(Celery/RQ),结果通过 Webhook 回调
- 部署层:Docker Compose → K8s + 自动扩缩容
17. Agent 的"幻觉"问题你怎么解决?
🚀 建议方向:
- 工具结果注入时加置信度标注
- 关键信息(如代码执行结果)要求模型"复述确认"
- 对不确定的回答引导模型说"我需要再查一下"而不是编造