只谈模型选型的团队，可能还没碰过长任务

有设计指南提到，浅层智能体会遇到上下文溢出、被分散注意力、无法长时间维持状态。换句话说，长任务崩掉，往往不是模型不够强，而是外围工程没接住。

面试时你可以直接问："一个跑五十步以上的任务，上下文怎么管？"如果对方只回答"我们换了更强的模型"或"提示词调得很细"，却说不清预算怎么分配、超长工具返回怎么处理、状态存在哪里，那这个岗位大概率偏接口调用，而不是长任务工程。

反过来，如果对方能讲出具体取舍——比如某次工具响应超过两万token就落盘、只留路径加前几行预览——说明他们真的被长任务打过脸。

优先补三类可迁移的工程思路

上下文管理的做法很多，但求职者不必背某个产品的具体阈值，优先理解三类思路：

  • 预算控制：一次任务里输入输出比例可能接近100:1，token是要花钱的，得知道哪里该省。
  • 压缩取舍：压缩不是删干净就完事。有做法是压缩后重新读取最近修改的文件、重新注入技能正文，并设上限。你要能说清"保留什么、丢什么、为什么"。
  • 状态外置：把目标、进度写到文件或外部存储，而不是全塞进上下文。

这三类思路换个团队、换个模型都成立，比记住某个产品的参数更值钱。

判断团队成熟度，看评测和成本意识

选岗时别被"我们在做Agent"这种概念吸引，问两个更硬的问题：

第一，压缩之后目标漂移怎么发现？有没有针对性的评测？如果团队连"压缩后任务跑偏"都没测过，说明长任务还没进入他们的日常。

第二，持久记忆是不是被当成有成本的设计决策？有研究指出上下文文件会推高推理成本，记忆不是越多越好。如果对方默认"全都记住"，可能还没算过账。

以上判断基于公开设计资料和报告，不代表所有团队的实际做法，具体以你面试时对方的回答为准。

一个实际可做的小建议：下次面试前，把"长任务失败时你们怎么定位"写进你的提问清单，听对方讲的是模型，还是工程。