考察点
这道题出自蚂蚁集团 Agent 暑期实习一面（2026 年牛客面经），是典型的观点题，没有标准答案，面试官想看三件事：你有没有自己的分析框架（而不是复读媒体观点）；你对 agent 生态的理解是否来自一线体感；你敢不敢下明确判断。低分回答是"技术会越来越好、场景会越来越广"这种正确的废话；高分回答敢于点名哪类 agent 会死，并且说得出为什么。回答时最好带一个可操作的判断标准，让面试官看到你平时就是这么评估项目的。追问常往"你自己做的项目在这个框架里处于什么位置"上走，这一问最狠，要提前想清楚。
参考答案
先给判断框架
我的判断框架只有一条主线：模型能力的内化速度，对比 agent 自身 harness 的厚度。基础模型每一代升级都在把原本需要外挂工程实现的能力收进模型内部——早期要精心设计的 few-shot 编排，模型变强后直接会了；早期的思维链模板，被推理模型内化。一个 agent 产品的价值如果主要来自"帮模型补足当下的短板"，那它的护城河就在随模型升级不断漏水的船上。能活下来的，是价值建立在模型之外的东西上的 agent：私有数据、专有工具集成、行业工作流、评测与合规体系。
哪些 agent 会被淘汰
按这个框架，三类 agent 我认为会被淘汰或已经在大浪里。
第一类是薄壳聊天 agent：套个 prompt 就上线的"XX 助手""XX 角色"，价值全部来自一段系统提示词。模型默认能力覆盖这类场景的速度非常快，这类产品这两年已经死了一大批，剩下的靠流量入口续命而非产品力。
第二类是手工编排的工作流 agent：把几十个 prompt 节点拖进 DAG 里、每个节点写死提示词的那种。问题是脆弱——节点间靠脆弱的格式约定衔接，模型一升级整图要重调，维护成本指数上升。它们正在被"强模型 + 简洁 agent loop + 好工具"的架构取代，后者让模型自己决定流程，而不是流程去驾驭模型。
第三类是信息搬运型垂直 agent：翻译、摘要、简单问答这类纯文本变换的垂直工具。通用助手原地就能做，没有独立存在的理由。注意不是所有垂直 agent 都会死——死的是只做信息变换的，深度绑定行业系统和数据的（医疗对接 HIS、法律对接判例库）反而活得更好，因为壁垒在集成不在文本。
新兴 agent 应具备的能力
我认为下一代 agent 拉开差距的能力有六项。
长程任务能力：不是单轮问答，而是持续工作几十分钟到几天——中间会规划、会压缩上下文、会在失败后恢复。这是从"工具"到"同事"的分水岭，checkpoint 和断点续跑是基本功。
自我验证：产出答案之前先验证答案，能跑测试就跑测试、能查数据就查数据，验证不了就明说置信度。只会生成不会验证的 agent 在严肃场景没有位置。
记忆与学习：跨会话记住用户偏好、历史决策、踩过的坑，把经验沉淀成 skill 或记忆文件，越用越懂业务。每次都从零开始的 agent 永远是个实习生。
环境操作能力：从操作 API 走向操作真实环境——浏览器、IDE、终端、桌面软件。computer use 类能力决定了 agent 能介入的工作面有多宽。
多 agent 协作：既能作为 orchestrator 拆任务带 worker，也能作为规范意义上的节点接入更大的协作网络，输出可验证的中间产物而不是一坨自然语言。
成本与可观测自觉：知道自己每一步花多少 token、成本敏感的步骤自动降级模型；全程留 trace，失败可复盘。这不是锦上添花，agent 进生产环境的第一道门槛就是"这玩意儿一个月烧多少钱、出了错谁负责"。
把框架对准自己
我在项目里也用这个框架自查：我做的 agent 如果明天模型能力翻倍，还剩下什么？剩下的是内部系统集成、私有评测集、团队沉淀的 skills——那这些就是我该持续加厚的地方；而那些"教模型怎么做事"的精细 prompt，我默认它们是消耗品，不投入过多雕琢。
可能的追问
你现在做的项目会不会也被淘汰？ 直接拿框架自测：列出项目价值里"模型内化会吃掉的部分"和"吃不掉的部分"，前者收缩投入、后者加厚。诚实承认有会被吃掉的部分，比硬撑"我的不会"更可信。
多 agent 系统是趋势还是泡沫？ 看场景。上下文隔离和并行收益明确的场景（大规模代码迁移、多源调研）是真需求；为了架构好看而拆的是泡沫。判断标准还是那个：拆开带来的协调成本是否低于收益。
To C 和 To B 的 agent 哪个先跑出来？ To B 先。B 端任务边界清晰、效果可量化、付费意愿和节省的人力成本直接挂钩；C 端容错低、需求发散，除非出现新交互入口，否则主要是存量巨头把 agent 能力内化进现有产品。