企业微信测开一面：两道 Hard 加 Agent 系统连环追问

《面试题目》

1. 算法题：合并 K 个升序链表（ACM 模式）。
2. 算法题：戳气球。
3. 你简历上的这几个项目是学习项目吗？
4. 你用了哪个 Agent 框架？
5. 有没有用过某种 Agent Harness？
6. 自己用 Workflow 搭 Agent，与 Harness + Skill 方案相比，你认为哪种更好？
7. 如果直接使用 AI 做推荐和召回，与你目前的方案相比，哪种效果更好？
8. 有了用户画像之后，具体怎么推荐出内容？
9. 用户最后的采纳、点踩等反馈会回流吗？
10. 如果用户完全没有偏好信息，冷启动怎么设计？
11. 推荐系统的信息茧房和重复推荐问题，你有处理吗？
12. Go 的 Context 是用来干什么的？
13. Context 的超时是怎么传递的？
14. 为什么不建议把 Context 存到结构体里面？
15. 如果推荐 Agent 系统的用户量上来，你觉得最大的性能瓶颈在哪里？
16. 你简历上的 250 条离线评测集是怎么设计的？
17. 评测题目与记忆知识库的重叠率会不会太高，造成作弊？
18. 评测集的覆盖度怎么考虑、怎么保证？
19. 业界有没有类似的 Benchmark 可以参考？

《参考解析》

合并 K 个升序链表：用最小堆存每个链表的头节点，每次弹出最小节点接到结果尾部，再把该节点的 next 入堆；堆大小 K，总时间 O(N log K)，空间 O(K)。也可以用分治两两合并，O(N log K)。ACM 模式注意自己定义节点、读输入。

戳气球：区间 DP。在数组两端补 1，dp[i][j] 表示开区间 (i,j) 内全部戳破的最大得分，枚举最后戳破的 k：dp[i][j] = max(dp[i][k] + dp[k][j] + nums[i]*nums[k]*nums[j])，按区间长度从小到大算，答案 dp[0][n+1]。时间 O(n³)。

Workflow vs Harness + Skill：Workflow 是确定性编排，路径固定、可预测、成本低，适合步骤明确的业务；Harness + Skill 把「执行框架」和「任务知识」分开，模型在边界内动态选工具、调整顺序，适合分支多、需要判断的任务，代价是成本、延迟和不确定性。回答时给判断标准：流程能否穷举、失败是否可接受、是否需要模型做决策。

推荐冷启动与信息茧房：冷启动用热门 + 内容属性 + 少量探索（bandit），先给多样性再收敛；有画像后做召回（向量/协同/规则）→ 排序（CTR 预估）→ 重排（多样性、去重、业务规则）；反馈回流做实时特征和负样本；信息茧房用探索比例、内容多样性约束、跨域推荐缓解。

Go Context：用于跨 API 边界传递取消信号、超时和请求级元数据。超时通过 WithTimeout 生成带 deadline 的子 context，子 goroutine 通过 Done() 感知；父 context 取消会级联到子。不建议存进结构体，是因为它应该随一次请求显式传递、生命周期短，存进长生命周期对象会导致取消信号错乱和泄漏；标准做法是作为函数第一个参数。

离线评测集：按「能力维度 × 场景 × 难度」分层抽样，覆盖正常、边界、对抗、长尾；每条有输入、期望要点、评分规则；与知识库做去重和泄漏检查（评测题不能直接出现在检索库里）；用人工标注校准 LLM judge；每次改动跑同一套并记录版本。可参考 RAGAS、BEIR、MT-Bench、AgentBench 等公开基准的设计思路。

性能瓶颈：模型调用（并发、限流、token 成本）、向量检索（索引规模、延迟）、会话状态存储（读写放大）、工具调用（外部依赖 RT）、编排层的串行等待。优化方向是缓存、批处理、异步化、分级模型、连接池与超时控制。