用pi agent替换lang graph构建agent

为什么用最好的模型，但是开发的Agent比codex/claude呆，核心智能分水岭在于Agent会不会写代码解决问题，一切问题都可以通过编程解决，所以写代码已经成了Agent智能的分水岭。

为什么 LangGraph 那套该换了：

① 能力边界是提前写死的。靠节点连边、靠预设工具，LLM 拿到题不能自己写代码去解，遇到没写过的场景就卡住。② Skill 渐进式加载，LangGraph 圈一年前还在讲、还在实现。对 PI 来说这根本不是个功能——ls 看一眼目录，cat/grep 挑一个 reference 文件，完事。③ 和开源生态割裂。Claude Code、Codex 生态里现成的 skill 和 MCP，搬到 LangGraph 上得重新适配一遍。

为什么不用 E2B 真沙箱：

用户 → 代理 → 沙箱 → pi/claude/opencode，隔离性确实拉满。但 PI 在那里本质还是 CLI 程序，不是 server 服务：扩展只能靠装扩展，想和别的系统深度集成，你没有控制权。

我们做了一件很直接的事：

把 PI Agent 用 SDK 内嵌进 TypeScript 服务，在应用层用 memfs(模拟文件系统) + just-bash(模拟bash) + isolated-vm(JS执行环境) 搭了一套虚拟环境——进程内就有文件系统和 shell，不需要真沙箱。

再配一组扩展就够了：pi-subagents、pi-background-tasks、pi-image-gen、pi-mcp-adapter、pi-turn-limiter。

我们的方案优势就三条：① 通过 SDK 内嵌进 TS 服务，本质是 server 端程序，控制权完全在自己手里，想怎么集成怎么集成。② 复用 PI 的扩展生态：自进化、memory，直接站在生态上。③ 复用 skill / MCP 生态：codex / claude 能装的，就能直接搬到服务端产品化。

我感觉，PI 会成为 Agent 领域的基础设施，地位和 Java 里的 Spring 差不多。