Agent 时代，Prompt 不再是核心
过去一两年，很多人都在研究 Prompt Engineering。怎么提问、怎么设定角色、怎么拆解任务、怎么让模型输出更稳定，似乎只要提示词写得足够好，就能把大模型的能力榨干。这在 ChatGPT 早期确实有效，因为那时大多数任务还是单轮问答：写一段文案、解释一个概念、生成一段代码、总结一篇文章。单轮任务里，Prompt 的影响非常明显，指令写得清楚，结果通常就会更好。
但到了 AI Agent 时代，情况变了。Agent 不是回答一次就结束，它要连续推理、调用工具、读取文件、搜索资料、修改代码、运行测试、根据反馈继续调整。这个过程中，真正决定结果的，往往不再是某一句 Prompt 写得多漂亮，而是模型在每一步推理时，到底看到了什么信息。换句话说，AI Agent 的核心能力，正在从 Prompt Engineering 转向 Context Engineering。
这个变化会影响很多工程实践。过去我们优化 Prompt，重点是把任务说清楚；现在我们优化 Agent，重点是让它在正确时刻拿到正确材料。一个提示词可以告诉模型你要认真分析，但如果上下文里没有日志、没有接口约束、没有历史决策、没有失败尝试，它也只能认真地猜。
Context Engineering 管的是信息质量
所谓 Context Engineering，可以理解为：为模型构造最合适的上下文。更准确地说，是找到一组最小但高信号的 Token，让模型完成目标的概率最大化。这里有两个关键词：最小，高信号。最小，不是越短越好，而是不塞无关内容；高信号，不是信息越多越好，而是信息要真正有用。Context Engineering 的目标不是把所有资料都丢给模型，而是让模型在正确的时间，看到正确的信息。
这和 Prompt Engineering 的区别非常关键。Prompt Engineering 关心的是怎么说，Context Engineering 关心的是给什么。前者更像写指令，后者更像设计信息系统。一个优秀 Agent 的上下文里，不只有用户问题，还包括系统提示、工具描述、历史消息、外部数据、代码文件、运行结果、长期记忆、当前任务状态等。Prompt 只是 Context 的一部分，而且在复杂任务中，它往往不是最重要的那一部分。
很多人误以为模型表现不好，是因为模型不够强，或者 Prompt 不够细。但在 Agent 场景里，更常见的问题其实是上下文质量太差。就像你让一个工程师排查线上故障，却不给日志、不给最近发布记录、不给架构说明，只说一句帮我看下为什么报错，再强的工程师也只能猜。模型也是一样。它不是不会推理，而是缺少足够准确、相关、及时的上下文。
所以，Context Engineering 真正要解决的不是把上下文塞满，而是做信息治理：哪些内容能直接影响判断，哪些内容只是背景噪声；哪些内容应该常驻，哪些内容应该按需加载；哪些历史经验值得保留，哪些旧信息会误导当前任务。
强 Agent 赢在会找上下文
这也是为什么同一个模型，在不同产品里的表现差距会很大。同样是 Claude，在普通聊天窗口里，它可能只是一个回答问题的助手；但在 Claude Code 里，它更像一个会工作的工程师。差异不完全来自模型本身，而来自上下文系统。Claude Code 不会指望用户一次性把所有信息说清楚，它会自己查看目录、读取文件、搜索关键字、定位调用链、运行命令，再根据结果继续探索。它的优势不是更会答，而是更会找。
这就是 Context Engineering 里非常重要的一种策略：Just-in-Time Context，即即时上下文。传统 RAG 通常是在推理前先检索一批资料，然后塞进上下文里。这个方法适合静态知识问答，但对复杂工程任务不一定够用。真实开发不是这样做的。程序员不会先把整个代码仓库背下来，再开始修 Bug；程序员会先看入口，再查调用，再读相关文件，再运行测试。即时上下文就是模拟这种工作方式：先保留轻量线索，需要时再动态加载。
即时上下文的关键不是多查几次资料，而是把探索过程变成一条可收敛的路径。先用目录、文件名、错误信息建立粗粒度判断，再读取最相关的局部内容，接着用工具结果验证假设。如果发现方向错了，就缩小范围重新定位。强 Agent 不是永远一开始就知道答案，而是能通过工具把不确定性一步步压低。
长上下文会稀释注意力
这背后有一个很现实的问题：上下文不是越长越好。很多人看到 128K、200K、1M token 的上下文窗口，会自然觉得窗口越大，效果越强。但长上下文并不等于有效上下文。信息塞得越多，模型的注意力越容易被稀释。重要内容虽然还在上下文里，但模型不一定还能稳定关注到它。这就是所谓的 Context Rot，中文可以理解为上下文腐烂。
Context Rot 的本质不是信息丢失，而是信噪比下降。比如在对话前面你明确告诉模型认证必须使用 JWT，后面又塞进去几万 token 的代码、日志、工具输出和历史讨论，模型最后写代码时可能就不再严格遵守最开始的约束。不是因为那条信息消失了，而是因为它被大量噪声淹没了。上下文窗口越大，这个问题越隐蔽：你以为信息还在，模型就一定能用上；但实际上，模型的注意力预算已经被消耗掉了。
所以 Context Engineering 的本质，其实是管理模型的注意力预算。每一个放进上下文的 Token，都在争夺模型的注意力。放进去的信息越多，单个关键信息获得的注意力就可能越少。因此，真正优秀的上下文系统，不是不断扩大输入，而是持续优化信噪比：哪些信息必须保留，哪些信息应该压缩，哪些信息应该延迟加载，哪些信息应该写入外部记忆，哪些信息应该直接丢弃。
这也是很多长任务最后变形的原因。任务刚开始时，约束很清楚，目标也很清楚；中间经过几十轮工具调用和讨论后，模型看到的是一堆局部事实、临时判断和过期结论。真正重要的约束没有消失，但它不再显眼。Context Engineering 要做的，就是持续把关键约束重新放回可见位置。
工具决定上下文入口
这也解释了为什么工具设计对 Agent 如此重要。Agent 不是只靠大脑工作，它还要靠工具获取上下文。如果工具设计混乱，Agent 就很难稳定完成任务。文档里有一句非常实用的原则：如果人类工程师都无法明确判断某个场景应该使用哪个工具，就不能指望 AI Agent 判断得更好。很多失败的 Agent 系统，不是模型能力不够，而是工具集太臃肿、职责重叠、命名模糊、返回结果冗余，导致模型不知道该用哪个工具、什么时候用、失败后如何补救。
好的工具应该像好的工程接口：单一职责、用途明确、参数清晰、返回高信号结果。比如 read_file 就是读文件，grep_code 就是搜索代码，run_test 就是运行测试。不要设计一堆 search_docs、query_docs、lookup_docs、find_docs 这种边界模糊的工具。工具越清晰，模型越容易形成稳定策略；工具越模糊，模型越容易在选择工具这一步就开始偏航。
工具的返回结果也同样重要。一个工具如果每次返回几千行日志，却没有摘要、错误定位和可继续操作的线索，模型仍然要在噪声里找重点。更好的工具应该帮助 Agent 缩小问题范围，比如返回匹配位置、相关上下文、失败原因、下一步建议，而不是把原始材料一股脑倒进上下文。
长任务需要外部记忆
当任务变长之后，仅靠即时上下文还不够，还需要长期任务管理机制。第一种机制是压缩，也就是当上下文接近上限时，把历史对话、工具调用、关键决策和中间结果总结成更短的摘要，再继续推进。压缩的目标不是保留所有细节，而是保留任务继续所需的关键事实，比如已经尝试过什么、做过哪些架构决策、遇到过哪些错误、当前进展到哪里。
第二种机制是结构化笔记。相比把所有内容塞在聊天历史里，更好的做法是让 Agent 把关键信息写到外部状态中，比如 TODO.md、NOTES.md、STATE.md 或项目进度日志。这些笔记不必长期占用上下文窗口，但可以在需要时被重新读取。它们相当于 Agent 的外部记忆，既能保持任务连续性，又不会持续污染当前上下文。
第三种机制是子代理架构。当任务足够复杂时，单个 Agent 的上下文窗口很容易被拖垮。更合理的方式是让主 Agent 负责规划和协调，让多个子 Agent 分别处理局部任务。比如一个子 Agent 分析代码，一个子 Agent 分析日志，一个子 Agent 查数据库变更，最后各自返回精简摘要给主 Agent。这样做的好处是，每个子 Agent 都拥有相对干净的上下文窗口，可以深入探索自己的问题域，而主 Agent 只需要接收高信号结论。
这些机制看起来像流程设计，其实都是上下文管理。压缩解决的是历史太长的问题，结构化笔记解决的是任务状态容易丢的问题，子代理解决的是单个上下文窗口装不下所有细节的问题。它们共同指向同一个目标：让模型在需要判断时，看到的是经过筛选的有效信息，而不是全过程录像。
未来壁垒是上下文基础设施
从这个角度看，未来 Agent 系统的竞争重点会非常明确：不是谁的 Prompt 更花哨，而是谁的上下文系统更强。模型会越来越强，上下文窗口会越来越大，工具也会越来越多，但这些并不会自动解决复杂任务中的一致性问题。恰恰相反，随着 Agent 能做的事情越来越复杂，上下文管理会变得越来越关键。
对开发者来说，这个变化非常现实。如果你正在做 Coding Agent、测试 Agent、知识库助手、自动化运维助手，真正应该投入的不是神奇 Prompt 模板，而是上下文基础设施。你需要考虑：任务开始前加载什么，任务过程中如何检索，工具结果如何裁剪，历史信息如何压缩，长期状态如何保存，失败模式如何反馈到系统提示里，哪些内容应该让模型自主探索，哪些内容应该提前提供。
尤其是在测试开发场景里，Context Engineering 的价值非常直接。一个测试 Agent 如果只知道帮我生成测试用例，它的输出大概率泛泛而谈；但如果它能读取接口文档、历史缺陷、代码变更、业务规则、Mock 约束、线上事故记录，它就有可能生成真正有效的测试策略。测试本身就是上下文密集型工作。缺上下文的测试，是模板化测试；有上下文的测试，才可能接近真实风险分析。
这也意味着，测试开发以后不只是写自动化脚本，还要参与上下文资产建设：接口文档是否准确，缺陷记录是否可检索，业务规则是否结构化，测试策略是否能沉淀成可复用经验。Agent 能不能用好这些资料，取决于我们有没有把资料整理成它能稳定获取、理解和执行的形态。
Prompt 会降级，注意力不会消失
这也是为什么我认为，Prompt Engineering 不会消失，但它会降级。它仍然重要，但不再是核心壁垒。未来更重要的是 Context Engineering：如何让模型持续获得高质量上下文，如何让它在复杂任务中保持方向感，如何避免信息污染，如何把有限 Token 用在最有价值的地方。
一句话总结：Prompt Engineering 研究的是如何向模型提问，Context Engineering 研究的是如何组织模型看到的世界。AI Agent 的上限，不只取决于模型会不会思考，更取决于它思考之前看到了什么。模型能力会继续提升，但注意力预算始终有限。谁能把最高信号的信息放进有限上下文里，谁就能构建更强的 Agent。