以前啊，咱们跟这些智能体聊天，总觉得是在单线程对话，不是你说完了我再回，就是咱俩聊完了就断了。这次OpenAI弄了个叫Codex的应用服务器，把以前那种“发请求、等响应、再关掉”的模式给彻底抛弃了。现在他们引入了一套特别的“对话原语”，让咱们和智能体聊天变得跟多线程似的自然。 一个简单的用户输入，可能背后藏着好几层动作。用户每按一下键，智能体每吐出一点话，还有那些中间产物，全都被记下来了。客户端只需要盯着界面刷新就行，不用去管那些复杂的内部逻辑。 这套系统里有三个核心概念：Item、Turn和Thread。Item是最小的单位，它有自己的“开始、增加、结束”的一生。Turn就是用户一次输入触发的一轮对话，里面可能有好几个Item。等下一次用户又输入了，新的一轮Turn就开始了，但上一轮的内容不会丢。Thread就更厉害了，它能保存整个会话的历史，就算客户端崩了重启，也能接着从最后一条Item继续聊。 有时候智能体要去干点儿危险的事儿，比如写文件或者改重要代码，服务器会主动喊停。这时候它会把当前的轮次锁住，只有咱们点了“允许”或者“拒绝”，才能接着往下走。这种双向控制让IDE不用自己操心那些复杂的权限判断了。 以前大家试过把Codex包装成MCP（模型上下文协议）服务器，想跟VS Code无缝对接。结果发现MCP那一套强调的是“工具、参数、结果”，很难表达那种流式变化、审批和多轮对话的复杂语义。维护起来也太费劲了。所以OpenAI最后把MCP留作了“简单模式”，主推这个新的应用服务器方案。他们用JSON-RPC协议配合JSONL格式的流式传输来做这件事，这样既兼容老版本的客户端，又能保证新功能正常使用。 部署这块儿挺灵活的：本地捆绑就是咱们常用的那种直接在VS Code或者macOS桌面App里跑的方式；伙伴集成就是第三方IDE可以保持稳定不变，直接用最新版的应用服务器二进制文件；Web运行时就是浏览器通过HTTP/Server-Sent Events跟容器里的服务器通信，那种长时间任务就靠服务器不停推送结果来保持界面简单。 虽然有了Codex应用服务器，但行业里的标准化争论还在继续。由Zed Industries发起、JetBrains也支持的Agent Client Protocol（ACP）也想做成通用标准。OpenAI自己用的Codex CLI已经列在了ACP的兼容清单里。看来大家还在琢磨怎么找那个最合适的边界。 为了方便大家用，所有源代码都开源了放在Codex CLI仓库里。协议文档也带了TypeScript类型定义和JSON Schema模式生成工具。不管你是什么语言背景的开发者，都能很快把自己的客户端连上去。服务器改进了社区就能随时采纳，这是个挺好的良性循环。