最近arXiv上的这篇《上下文收集决策过程：智能体搜索的POMDP框架》确实戳中了我在实际部署LLM Agent时的痛点。核心问题在于：当Agent需要处理远超上下文窗口的代码库或对话历史时，其工作记忆本质上是“有损压缩”，导致循环搜索和过早终止。

作者将问题建模为部分可观测马尔可夫决策过程（POMDP），通过显式维护“信念状态”来引导搜索决策。这个思路在理论上很漂亮——它让Agent不再盲目重复，而是基于不确定性主动选择下一步探索方向。但关键难点在于：信念状态的更新计算成本极高，尤其在long-context场景下。我个人的落地经验是，单纯靠LLM自回归生成信念向量会引入额外延迟，甚至超过搜索本身的时间。

这里有两个值得讨论的技术问题：1）POMDP中的“观测”如何从LLM的隐层状态中高效抽取？直接使用注意力权重是否足够？2）在真实代码库场景中，状态空间可能是百万级token，如何设计分层信念表示来避免指数爆炸？

从行业视野看，这篇工作可能推动Agent架构从“单次推理+缓存”向“主动感知+决策”进化。但短期内，我更看好混合方案——用POMDP做高层规划，底层仍依赖检索增强生成（RAG）来低成本获取片段信息。毕竟，工程落地最怕的是“理论上最优，实践中跑不动”。