1. stdio 的本质并不老，它只是更贴近本地执行
stdio 本质上是进程间通信的一种经典方式：一个进程通过标准输入接收指令，通过标准输出返回结果。 在 CLI 场景里，它最大的价值不是“传统”，而是它恰好站在本地进程、文件系统和命令执行的边界上。
你不需要额外开端口、不需要单独维护一个本地 HTTP 服务，也不需要为了一个简单的命令调用引入更多网络栈复杂度。 对本地代理来说，这就是最短路径。
2. 为什么它特别适合 AI Coding Agent
- 权限边界更清晰：通信范围被限制在进程之间，天然比开放本地端口更收敛。
- 反馈链更短：命令输出直接成为下一轮推理输入，不需要再转一道协议层。
- 调试简单：很多问题都可以直接通过日志、管道输出和进程状态定位。
- 集成轻量：命令行工具、编辑器插件、守护进程都更容易围绕 stdio 组织。
这些优点叠加起来，导致 stdio 非常适合“本地工具调用 + 模型回环”这种工作模式。这也是为什么很多 CLI 代理最后都会走到它上面。
3. 它和 HTTP / WebSocket 的区别不只是协议格式
很多人会把 stdio 和 HTTP 看成同级替代方案，但其实它们更像是针对不同边界条件的选择。HTTP 更适合跨进程、跨机器、跨团队暴露服务； stdio 更适合一个本地宿主进程和它启动的工具之间做短链路通信。
如果你面对的是 IDE 插件调本地 agent、本地 agent 再调本地工具，stdio 往往是最自然的选择。只有当系统需要远程化、服务化、可观测化之后， HTTP 或 WebSocket 才会变得更有优势。
4. stdio 不是银弹，它的局限也很明确
它也有缺点，而且必须提前认清：
- 天然偏本地，不适合直接承载跨机器、多租户服务。
- 如果输出流设计混乱，调试时会把控制信息和业务信息搅在一起。
- 长生命周期、多会话复用场景下，需要额外处理进程管理和中断恢复。
所以问题不该是“stdio 好不好”，而应该是“你当前的边界是不是一个本地代理问题”。只要答案是“是”，stdio 往往就很难被绕开。
5. 为什么我会把它和 MCP / CLI 一起看
协议决定结构，传输决定落地难度。
很多协议讨论如果脱离传输层，会显得非常抽象。MCP、各种 CLI agent、甚至一些 IDE 集成，真正落地时都会回到一个问题： 这条链路最终怎么在本地稳定跑起来？
从这个角度看，stdio 不是一个“旧时代遗产”，而是本地 Agent 生态的基础设施之一。只要大家还在强调本地上下文、命令执行和最小部署成本， stdio 就会继续存在。
6. 实操建议
如果你正在做自己的工具链，我的建议很简单：
- 本地阶段优先用 stdio，把链路打短。
- 一开始就设计好标准输入输出的结构，不要把日志和协议混杂在一起。
- 一旦要跨机器或开放服务，再往 HTTP / WebSocket 演进。
先把本地问题解决，再谈服务化。这比一开始就把架构做复杂，更符合真实交付节奏。