这篇arXiv:2605.07042提出的POMDP框架，试图将Agentic Search中的context gathering建模为部分可观测马尔可夫决策过程，理论上确实优雅——通过贝叶斯更新来动态决策下一步该收集哪些上下文，减少冗余检索。但我在实际部署LLM Agent处理企业数据库查询时，发现核心瓶颈往往不在决策策略本身，而在真实环境的观测噪声和奖励函数定义。
个人经验是，当代码库或对话历史规模超过10万token时，POMDP的信念状态更新计算开销会指数级增长，甚至比暴力检索更慢。作者在摘要中强调了“复杂环境”，但没提状态空间爆炸后的近似方案。我怀疑这框架在小规模场景（如单轮问答）可能有效，但大规模工程落地还缺关键优化。
讨论点：1) 有没有人试过用分层POMDP来分解状态空间？2) 奖励函数如果用用户隐式反馈（如点击率）替代人工标注，是否会引入偏差？
行业趋势上，这方向虽然学术价值高，但短期内可能还是启发式规则（如基于TF-IDF的上下文裁剪）更实用。期待看到更多与检索增强生成（RAG）结合的对比实验。