先分清一件事：研究里的对照设置，不等于面试评分表

消息提到，一项研究固定编码 harness 的执行循环，逐一改变规划、动作空间和上下文管理，覆盖 176 组匹配设置、四个模型，并用 SWE-Bench Verified 和 Terminal-Bench 2.1 评测。这只是该研究在特定设定下的做法，原文未说明是否适用于其他模型、任务或生产环境，也未说明是否经过同行评审或复现。

所以下面是一份模拟面试追问思路，用来说明怎么问，而不是断言团队会怎么答。它的价值是帮你在对话里挖到具体例子，不能反过来推出团队水平高低，更不能当作岗位门槛。

追问可以从“最近一次改动”切入，比如：你们上一次单独调整规划、动作空间或上下文管理是什么时候？改之前预期什么，结果和预期差在哪？哪些失败案例让你们回退了改动？对方若只复述框架名词，你就换个问法要例子，但别把“答不上来”直接等同于没做过工程取舍。

上下文管理：先问收益来源，再问验证方式

消息提到，上下文窗口越紧，上下文管理的收益越明显，且主要收益来自防止溢出失败，而非推理更好。这是该研究中的一项发现，适用范围有限。

面试里更有用的做法，是把这个问题抛给对方：你们做上下文管理，主要目标是减少溢出中断，还是提升推理质量？这两类收益，你们用什么指标分开看？如果对方说“都提升”，可以继续问：上一次调整后，失败类型分布有变化吗？

这样问的好处是，你能听出对方是否区分过“任务没做完”和“做完了但做错”。至于你自己怎么讲，重点是描述你实际做过的事，成果只在确实完成时使用，数字用 [实际记录] 这类占位，别编造。

规划与动作空间：把模型强弱当成追问变量，而不是结论

消息还提到，规划对弱模型提升成功率、对强模型主要降成本；动作空间的选择与模型对 bash 的熟练度相关。这些都是该研究在测试环境下观察到的差异，不能直接推广成“你们团队就该这么设计”。

所以合适的问题是：你们现在主力模型偏强还是偏弱？规划模块的目标是提成功率还是压成本？工具接口为什么选现在这种形式？最近一次因为模型换代而调整规划或工具设计，是什么情况？

这些问题的意义是让你听懂对方的取舍逻辑，不是让你背标准答案。面试前可以做的实际小事：挑一个你真实做过的任务，写下当时改了什么、预期什么、结果哪里不一样——比堆概念更能撑住追问。