我们正处在一个AI Agent（智能体）爆发的时代。从简单的ReAct循环到复杂的Multi-Agent Swarm（多智能体蜂群），新的架构层出不穷。但在这些眼花缭乱的名词背后，开发者的工作往往更像是一门“玄学”，我们凭直觉调整提示词，凭经验增加Agent的数量，却很难说清楚为什么某个架构在特定任务上表现更好。
扩散语言模型（Diffusion Language Models）以其独特的 “全局规划” 与并行解码能力广为人知，成为 LLM 领域的全新范式之一。然而在 Any-order 解码模式下，其通常面临
RAG效果不及预期，试试这10个上下文处理优化技巧。对大部分开发者来说，搭一个RAG或者agent不难，怎么把它优化成生产可用的状态最难。在这个过程中，检索效率、准确性、成本、响应速度，都是重点关注问题。
Context Pruning如何结合rerank，优化RAG上下文？
最近半年，我阅读了业界关于 AI Agent 的工程实践：Anthropic 的 Context Engineering 论文、Manus 的工程分享、Cline 的 Memory Bank 设计等。同时自己也一直在做跟 AI Agent 相关的项目，如：Jta[1]（开源的翻译 Agent，基于 Agentic Workflow）。
在大模型研究领域，做混合专家模型（MoE）的团队很多，但专注机制可解释性（Mechanistic Interpretability）的却寥寥无几 —— 而将二者深度结合，从底层机制理解复杂推理过程的工作，更是凤毛麟角。
谷歌在第三天发布了《上下文工程：会话与记忆》(Context Engineering: Sessions & Memory) 白皮书。文中开篇指出，LLM模型本身是无状态的 (stateless)。如果要构建有状态的（stateful）和个性化的 AI，关键在于上下文工程。
如果你也在做 RAG 或智能体应用，大概经历过这些瞬间：文档切得太碎，答案失去上下文；切得太大，又召回不准；加了更多提示词，效果可能更不稳定。
在几天前，上海交大发布了一篇名为 《上下文工程2.0：上下文工程的上下文》（Context Engineering 2.0: The Context of Context Engineering） 的重磅论文。
近期，DeepSeek-OCR提出了“Vision as Context Compression”的新思路，然而它主要研究的是通过模型的OCR能力，用图片压缩文档。
