快手面试官问：Agent跑50轮突然变傻了
长任务跑到后面为什么越来越傻？Context 不是越长越好——它是有限资源，需要治理。
一、面试现场
面试题
“Agent 跑到第 50 轮为什么变傻？Context 真的越长越好吗？”
快手 AI 平台组终面。候选人做过一个文档问答 Agent——多轮对话中用户追问越来越深，Agent 到第 50 轮开始忘记早期指令、重复已经给过的答案。候选人尝试把 context window 从 32k 拉到 128k，效果反而更差：延迟翻倍，回答质量并没有提升。
面试官追问的核心不是"用哪个长上下文模型"，而是：你怎么管理上下文这种有限资源？
这不是某一次面试的原题，而是从真实面经和岗位 JD 中提炼的高频判断题。
二、大多数人怎么答的
“换一个支持 200k context 的模型就行。” 或者：“把历史对话全部保留，让模型自己判断哪些重要。” 这两种回答犯了同一个错误——把 context window 当免费缓冲区，而不是需要治理的有限资源。
典型误判
“上下文越长越好 / 全部保留让模型自己判断。”——context 不是免费缓冲区，而是有限资源。
三、正确判断框架
Prompt Engineering 解决单次输入质量，Context Engineering 解决长任务的信息治理。两者不是一回事。四种上下文治理策略各解决一种问题。
Compaction：定期压缩，保留关键决策
每 N 轮（或 token 数达阈值时）做一次摘要压缩。保留什么：decisions（决策结论）+ constraints（约束条件）+ current state（当前状态）。丢弃什么：intermediate reasoning（中间推理过程）。关键：用 structured summary 格式，不是自然语言摘要——自然语言摘要容易丢约束。
Memory：短期工作记忆 + 长期知识记忆
不是所有信息都同等重要。短期记忆保留当前任务状态（bug_description, current_hypothesis, completed_steps）；长期记忆保留跨任务的学习成果（项目编码规范、已知的陷阱）。关键：记忆必须有读写协议——什么时候写、什么格式、什么时候读、过期怎么处理。
Runtime Retrieval：需要时再取
不要预加载所有可能用到的信息。按需从外部取，用完丢掉。适用于参考文档、代码文件等"可重新获取"的内容。
Sub-agents：用隔离降压
上一课已经展开。每个 sub-agent 只看自己需要的信息，做完返回摘要。main agent context 大幅缩减。
四、面试官追问链
追问 1
“Compaction 最容易丢什么信息？你怎么保证关键约束不被压掉？”
最容易丢的是约束条件和否定决策（“我们试了 X 但不行”）。解法：用结构化格式做 summary，不用自然语言概括。格式示例：{decisions: […], constraints: […], rejected_approaches: […], current_state: {…}}。每次 compaction 后跑一次校验——让模型自检"这些约束是否仍在 context 中"。
追问 2
“Sub-agent 什么时候是在隔离上下文，什么时候是在增加编排复杂度？”
判断标准：sub-agent 做完后，main agent 是否还需要全量看一遍它的工作过程。如果只看摘要就够了——隔离有效。如果 main 拿到摘要后又得展开看完整内容——隔离失败，反而多了编排开销。
加分题
“Context 已 80k tokens，‘需要更长 context’还是’需要重新设计流程’？”
方向：看 80k 里有多少是当前决策真正需要的。如果 80% 的 tokens 是中间结果而非当前步骤需要的信息——流程问题，不是 context 长度问题。
五、落地案例
实战拆解
长时间代码修复 Agent 的上下文治理：从"全塞"到"结构化治理"的演进。
**任务：**修复一个涉及 8 个文件的 bug。第一版把所有文件内容都塞进 context——到第 5 轮就开始"忘记"最初的 bug 描述。
优化版——三管齐下：
第一，用 structured memory 保留核心状态：{bug_description,affected_files[], current_hypothesis, completed_steps[]}。不管跑多少轮，这四个字段始终在 context 最前面。
第二，每个文件的修改用 sub-agent 隔离——sub-agent 只看 bug_description + 该文件 + 相关依赖，做完返回 diff。Main agent 只看 diffs + test results。
第三，compaction 规则：每 10 轮做一次。保留 decisions 和 test results，丢弃 intermediate code exploration。压缩后 context 从 80k 降到 15k，质量反而提升。
六、上线坑点
坑 1：中间结果全塞进 context
噪音压过信号，模型在信息海洋里"迷路"。
坑 2：Summary 丢掉否定决策
压缩时只保留结论不保留 rejected approaches——后续步骤重复尝试已经证明不行的方案。
坑 3：记忆只写不读
写了 memory 但 prompt 里没设计读取时机——写了等于没写。
坑 4：没有 compaction 策略
成本和延迟随对话轮数线性增长，没人设止损线。
七、本课总结与面试锦囊
一句话结论
长任务变笨不是因为模型突然傻了，而是因为上下文膨胀、信息污染和记忆治理失败。Context 是有限资源，不是免费缓冲区。
面试锦囊
先说：Context 不是越长越好。Prompt Engineering 管单次质量，Context Engineering 管长任务信息治理。
再说：四种治理策略——Compaction 定期压缩、Memory 持久化存储、Runtime Retrieval 按需检索、Sub-agents 隔离上下文。
最后补：Compaction 用结构化格式不用自然语言，记忆必须有读写协议，不用的信息不塞 context。
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～