arXiv上的这篇SPE论文很有意思，核心思想是用模型补全本身充当编排程序，框架只做eval，不再强加固定的轮次间策略。说白了，就是让LLM自己决定下一步怎么走，而不是我们写死一个ReAct或Plan-and-Solve的循环。
技术上看，SPE把状态定义为“可通过模型补全加载嵌入式机器副本任意状态的状态”，这其实是在用一个图灵完备的自我修改机制替代传统的手写编排。从形式化角度看，它确实突破了固定编排的瓶颈——模型可以在不同轮次之间动态切换策略，甚至自我修正执行路径。但实际落地时，我遇到几个坑：
- 状态爆炸与收敛性：SPE允许任意状态嵌套，一旦模型生成循环引用或深度递归，框架的eval会直接挂掉。我试过用最大深度截断，但截断后状态语义可能断裂，恢复成本极高。
- 可观测性暴跌：传统编排有明确的step-by-step日志，SPE下模型自己跳转状态，trace链路变成一团乱麻。调试时我只能靠打印每次模型补全的token来反向推理，效率极低。
- 安全边界模糊：如果模型补全生成了恶意状态（比如无限fork子进程），框架作为纯eval方没有拦截机制。个人经验：必须在eval前加一层静态分析，对输出的程序做资源预算检查。
我想问两个问题：1）SPE是否真的能比固定编排在复杂多步任务（如代码生成+测试）上稳定提升？论文的实验场景偏简单，实际长尾场景下状态空间膨胀问题怎么解？2）从行业格局看，这种“无编排”思路会不会让LangChain这类框架的价值被削弱？毕竟它们卖的就是编排能力。
个人认为，SPE更像是一种“元编排”思路，适合探索性任务，但生产环境还需要混合架构——关键路径用固定编排兜底，探索分支用SPE释放灵活性。否则，系统鲁棒性就是一场豪赌。