一个不能直接用的百分比

消息提到，SemiAnalysis称智能体流量目前已占全部推理流量的70%以上。但这个数字没有说明统计口径、样本范围和时间窗口。对准备数据与算法方向面试的人来说，它不该成为结论，而更适合当成一个提醒：面试前先弄清楚团队到底在谈什么负载。

据同一条消息，智能体负载有几个特征：一个会话包含数十到数百轮，可能带来较高的KV缓存复用；系统提示、工具定义和大量轮次让上下文快速累积；一个会话还会启动多个短生命周期子智能体，产生突发的KV缓存模式。注意，这里说的是负载特征，不是岗位分工，也不是技能清单。

特征只是问题入口，不是分工答案

看到“多轮”“长上下文”，容易顺着想：那一定有缓存管理、上下文组织这类工作。这是分析，不是素材给的结论。素材没有说哪些公司、哪些团队因此设了哪些岗位，也没有给出缓存复用的实现方式或效果数据。

所以更稳妥的做法，是把特征当作提问的起点，而不是提前假设岗位内容。假设场景：两个岗位都写“负责智能体相关系统”，一个团队可能更关心每轮请求的开销，另一个团队可能更关心任务怎么拆、工具怎么调。同一句话，日常可能完全不同。

读岗位描述时，凡是只写“智能体相关”的，都值得进一步确认它是偏系统侧还是偏任务侧，别靠关键词猜。

面试里值得问的几个核查问题

问团队现在主要处理哪类负载：多轮对话、长上下文任务，还是短生命周期子智能体的调度？问一个会话几十到数百轮时，上下文怎么组织，谁负责这部分？问子智能体突发出现时，资源分配和排队由谁决定？再问一句：这个方向目前更缺系统侧的人，还是更缺任务设计侧的人？ 延伸阅读：技术面试通关秘籍：系统设计题如何应对？

这些问题的价值不在得到标准答案，而在听对方怎么描述日常。如果对方只能重复产品宣传，说明你拿到的信息有限，需要谨慎判断自己是否匹配，而不是假定这是机会或坑。

想补充准备的话，先确认目标团队实际在做哪一侧，再决定练什么，别照着负载特征直接推出学习路线。一个可做的小动作：挑一份你感兴趣的岗位描述，把里面每个职责标注成“负载/系统”或“任务/流程”，再对照自己的经历，看哪边说得清楚。

这只是模拟问答示例，不代表面试官一定会问，也不构成任何录用判断。