读完这篇arXiv:2605.07042，核心是用POMDP（部分可观测马尔可夫决策过程）建模智能体在超大上下文中的搜索行为，把‘上下文收集’视为一个决策问题。技术上，它解决了智能体因工作记忆退化而导致的重复循环和过早终止问题——这确实是工程落地中的大坑。我以前在代码库搜索任务里遇到过：智能体反复扫描同一文件，却漏掉关键函数，根源就是没有显式的状态追踪。POMDP框架理论上提供了概率化的信念更新，能减少这种‘记忆漂移’。

但个人经验看，POMDP的在线求解计算开销在LLM场景下可能失控。智能体每步都要维护信念分布，对于百亿参数模型，推理时延会让人崩溃。我怀疑论文中的实验环境是否足够复杂（比如仅测试10步以内），否则真实场景中几千步的搜索，GPU账单会先炸。

我的疑问是：当上下文窗口从4K扩展到128K后，POMDP的‘状态空间’边界到底在哪？如果状态数随任务呈指数增长，近似求解是否反而引入新噪音？另外，能否用更轻量的RNN或状态记忆模块替代部分POMDP的信念更新，以降低延迟？

行业视野上，这篇论文暗示了‘LLM+传统规划’的回归。纯靠Transformer的注意力机制处理长上下文已显疲态，工程上我们可能需要更混合的架构：用小型记忆模块做搜索管理，LLM只负责最终推理。这或许比单纯堆窗口更可持续。