devgo.cn你有没有遇到过这种尴尬：在一个聊天界面里调教好了一个AI助手，它记住你的偏好、积累了一堆技能，但换个客户端或者换个模型，一切归零？更烦的是，当你需要它上网查资料、操作某个网站时，它要么被权限困住，要么像个黑盒一样乱来，你完全不知道它背后干了什么。如果你被这个问题折磨过，那Ox这个新开源项目值得你花十分钟看看——它不只是一只本地跑的小代理，而是定义了一套协议，叫OpenOx，试图从根上解决“AI代理的状态和能力被绑死在某个界面或模型上”的问题。
先说核心思路：OpenOx把代理拆成七个独立组件——客户端（Client）、宿主（Host）、智能体（Agent）、模型提供商（Model Provider）、Profile（个人档案）、VM（虚拟机）、服务仓库（Service Repository）。听起来抽象，但拆开看其实很直观。你平时用的ChatGPT网页、桌面App，那是Client；真正承担推理和调用工具的是Agent；模型是通过Model Provider接进来的，OpenOx不规定你用哪家。重点在两个设计：一个叫Profile，一个叫VM。
Profile就是一个文件夹，装着你这个代理的持久状态——身份、记忆、技能、产出物、聊天历史。这有啥用？意味着你换任何客户端、换任何模型，只要把这个Profile挂上去，你的代理就像换了副皮囊但大脑和记忆全在。现在市面上大多数Agent工具，状态跟UI耦合得很死，换个界面就失忆。Ox的Profile把这个彻底解耦了，这才是“本地开源”的真正含义——你的智能体数据不锁在某个云端服务里。
再来看VM，这是我觉得最巧妙的部分。Ox的Agent不是直接跑在系统上，所有能执行的代码都丢进一个受限的JavaScript虚拟机里。这个VM没有DOM、没有Node.js、没有Shell，连文件系统和网络都不直接开放。Agent想访问什么，必须通过它提供的ox.*能力接口——比如ox.fs访问虚拟文件系统，ox.web.browser操作浏览器。你可以理解为：虚拟机是隔离囚室，Agent只能在里面写代码，但想越狱做任何事，都要叫狱警（Host）来审批。Host负责验证请求、做授权、必要时弹出确认让用户批准，然后才执行。这个设计的精妙之处在于，它把“模型能干什么”和“它实际上获准干什么”彻底分离。模型再怎么自由发挥，也绕不过Host的能力边界。
更进一步，OpenOx还把能力插件化。Service是干活的，比如操作浏览器、连接MCP服务器（一种让AI调用外部工具的标准协议）、访问设备；Skill是教Agent“怎么做”的指令，比如“先查库存再下单”，但它不新增权限——Service定义能做什么，Skill定义怎么做，两者配合但不越权。这些Service和Skill可以通过Git仓库共享，装到你本地后即刻可用。这就形成了一个“自进化”生态：Agent不需要等官方更新，就能通过学到的Service和Skill扩展能力，还能分享给别人。
还有一个有意思的产物概念：Artifact。普通聊天输出是一次性的，但Agent可以生成一个“工件”——可以是一篇Markdown笔记、一个HTML画布。这个画布是独立的网页，能复用你之前授权的服务，但同样受权限管控。换句话说，Agent生成的不是一屏文字，而是一个你可以反复打开、修改、再挂在别的对话里的“作品”。
这套协议最让我意外的是，它没有设计一个“万能消息总线”，而是让每个边界各自定义极简的类型化契约。客户端跟Host只聊聊天操作，Agent跟模型走标准化的消息流，JavaScript跨VM只通过ox.*接口。这种“各管各的”哲学，避免了协议变成臃肿的中间层，也方便Host实现——你不需要理解整套系统，只要实现OpenOx的接口子集就能兼容。
对普通开发者来说，这个项目给了你一个现成的脚手架：你想做自己的本地AI代理，不用再从零设计权限模型和状态持久化，直接按OpenOx的组件边界搭。你可以只写一个Client接上任意Host，或者自己实现一个Host来管私有服务。踩坑提醒：VM目前只支持JavaScript，如果你习惯Python生态，得通过Service来桥接；另外，所有外部操作都得走审批流，如果你期望完全无人值守的代理，这里可能会成为瓶颈——但这恰恰是它的安全设计本意。
总而言之（避免？但这里需要），Ox用一套清晰的协议，把Agent从“应用”变成了“可迁移的个人资产”，这方向值得所有在做Agent工具的人看一眼。
内容与图片版权归原作者所有 · 原文: https://openox.ai/