1. 摘要：
现在的 AI Agent（如 Claude Code）通常依赖 Node、Bash 和底层文件系统，部署门槛高且极度依赖云端容器。我使用 TRAE SOLO 辅助开发了 Web Pilot（Browser OS），仅通过一个 10MB 的 WASM 文件，就在浏览器端原生实现了完整的 Node.js + Python + Bash 运行时环境，让全功能 Agent 得以纯前端运行，大幅降低了计算成本和部署难度。
2. 背景：
我是一名全栈开发者/机器人运控算法工程师/硬件黑客。这次想探索些和职业无关的事情，我在探索 AI Agent 的落地场景时，我发现了一个痛点：目前强大的 Agent 往往需要直接读写文件系统、执行 Bash 脚本或运行代码。传统的 Web 部署方案需要为每个用户分配一个昂贵的 Docker 容器（Sandbox），不仅服务器成本极高，还存在安全隔离的隐患。 因此，我希望利用 WebAssembly 技术，打破这个限制，探索一种让 Agent 直接在用户浏览器中“内生”运行的轻量化方案。
3. 实践过程：
这个项目的技术栈非常杂，跨越了前端界面、Web Worker 通信、WASM 运行时以及底层文件系统的虚拟化。
任务拆解：
-
核心运行时构建：引入并配置支持 Node.js 和 Python 的 WASM 模块。
-
虚拟文件系统桥接：实现一套能在内存中运行的 Reactive MemFS，并与 WASM 侧互通。
-
前端界面与交互：搭建 React 界面，实现终端模拟器和文件目录树。
用了 SOLO 哪些能力：
-
全局代码库理解（Codebase Context）：在 Monorepo 架构（包含
apps/web和packages/core）下，SOLO 能精准定位跨包的类型定义和逻辑关联。 -
Agent 自动执行与排错：直接让 SOLO 接管终端运行命令，遇到报错自动分析并修复。
-
跨语言生成：无缝在 TypeScript 业务逻辑、Vite 配置、以及底层 Node Bridge 之间切换。
关键 Prompt / 操作过程：
-
架构设计：“请帮我实现一个基于 Reactive MemFS 的文件系统（
reactive-mem-fs.ts），并桥接到 WASM 的 Node 运行时中（node-bridge.ts）。” -
自动化排错：“给我运行整个前端。” —— 这一步体验极佳，由于环境中缺少依赖且存在执行权限问题，SOLO 自动执行了
npm install，随后在启动vite遇到Permission denied时，它直接在终端利用ls -l和chmod +x node_modules/.bin/*自动排查并修复了权限坑，随后成功在 5173 端口跑起了服务。
中间踩过什么坑： WASM 的加载跨域问题，以及 Monorepo 下前端工作区依赖核心包的构建顺序问题。因为有 SOLO 强大的报错读取和多步修复能力，我基本不需要去 StackOverflow 查资料，直接看它在终端里一遍遍跑通。
4. 成果展示：
成功搭建了 Web Pilot (Browser OS) 原型！ 现在，一个依赖 Bash、Node 和文件系统的 Agent 能够直接在浏览器页面中跑通。
-
可以查看链接来玩一玩：WEB PILOT
5. 效果与总结：
提效了多少？ 探索 WASM 编译和底层文件系统劫持，原本需要查阅大量零散的 C++ 编译和底层 API 文档，耗时可能长达数周。使用 SOLO 后，我只用了很短时间就跑通了最核心的 MVP 原型。效率提升至少在 5 倍以上。
SOLO 在我流程中做了什么？ 它不仅仅是一个“代码补全器”，而是真正的“结对编程伙伴”兼“DevOps 运维”。当我专注于高层架构时，它帮我填补了繁琐的桥接代码；当环境起不来时，它能自己拿终端权限去 debug。而且它可以启动一个沙盒自动运行浏览器，这个功能惊呆了我（图1）。而且他竟然可以绑定我的github直接操作，大大避免了装环境的痛苦。他的QA模式做的很漂亮，然后问题问的都在点子上，他甚至比我思考的还要全（图3）。
可复用的方法： 在开发这类高度复杂的系统时，强烈建议把任务拆解并让 SOLO 先写“接口/协议”。定好 shared-types.ts 后，再让 SOLO 去分别实现核心逻辑和 UI 层。另外，遇到环境报错，直接甩一句“帮我运行并解决报错”，能极大程度解放双手。
个人感受： 这次TRAE SOLO 2.0确实厉害，我使用的国际版的SOLO 2.0版本，使用后，惊呼“WC”，TRAE团队的创新能力相当可以，这次感觉是融入了桌面沙盒在里面。之前是terminal的沙盒+浏览器，个人觉得这个增加自动化程度应该是小事，感觉是进而增加prompt的维度。反正真的是强！
