openJiuwen发布RSI原生AgentOS，支持Agent自主开发并热插拔功能
openJiuwen推出RSI原生AgentOS，核心在于让Agent具备递归自我改进能力。通过Web客户端、网关和Agent层的扩展点，用户可直接指令Agent生成“系统插件”，实现如桌宠形态、Token监控等功能的热插拔与版本回退。该架构支持从个人界面定制到企业级鉴权适配，真正落地“Agent所想即所得”的开发范式
当Agent开始给自己写代码
过去开发软件，想给应用添个新功能，一般要走需求评审、排期、编码、测试这一整套流程，耗时不短。到了Agent时代，这套逻辑正被重新改写。
设想你正在用一个AI工作流工具，忽然觉得少了桌面小挂件，想随时问上两句。这时候不用去GitHub提Issue，也不必等官方发版，直接跟Agent说一句：“给我加个桌宠，我要在桌面上能直接跟你聊天。”
几分钟后，Agent就把扩展包做出来了，还会自动装上，桌面上随即多出一个能交互的小图标。点一下，工作台收起，对话接着进行；双击，又回到完整的工作台，上下文不断档。
这并非科幻桥段，而是openJiuwen新近发布的RSI原生AgentOS亮出的本事。该系统想做的事，是让Agent从“执行者”转为“开发者”，实现递归自我改进（Recursive Self-Improvement, RSI）。
什么是RSI原生AgentOS？
openJiuwen提出的HyperAgent架构里，有一项关键特征：从“开发者友好”转向“RSI友好”。说白了，过去的扩展机制面向程序员，如今这套扩展机制面向Agent。
RSI原生AgentOS负责为这种自我进化提供运行环境。应用生命周期的各个环节都埋了“扩展点”，界面、网关、服务端和Agent执行层均有覆盖。新功能借助这些扩展点以“热插拔”方式接入，原有代码不用动，版本管理和故障回退也能支持。
WorkSwarm就是基于这套系统搭建的，也是第一个吃螃蟹的应用。在WorkSwarm中，Agent生成的扩展包叫“系统插件”。用户可在“我的扩展”里一键启用或禁用，效果实时可见。用着不顺手，再反馈给Agent，让它继续改。openJiuwen把这称作“Agent所想即所得”。
拆解架构：扩展包是如何生效的？
想弄明白Agent如何给自己加功能，先得看RSI原生AgentOS的底层架构。从用户发出请求到Agent完成任务，系统大体分三层：Web客户端、Gateway（网关）和Agent层。
这三层之间并非密不透风，而是留出了大量扩展入口：
- Client层：管界面展示。按钮、面板、设置项都能加，整体主题也能换。
- Gateway层：管请求接入。鉴权逻辑可以插进去，路由规则可以调，请求转发前也能做预处理。
- Agent层：核心执行单元。会话由AgentServer管理，任务由Harness组织。协作规则可定制，提示词可调整，新工具能注册，MCP服务也能接入。
扩展包的运作机制
所有改动都封装进“扩展包”。每个包都带一份manifest.json清单文件，里面声明包的ID、版本、依赖关系以及代码入口。若属于界面扩展，还会指明组件显示的位置（如输入区上方、侧栏或设置页）。
用户安装扩展包时，系统读取清单，按包ID和版本把文件存好。到了加载阶段，Gateway和AgentServer各自筛出属于自己的扩展包，定下加载顺序，再把包内的处理函数注册到各自的事件总线上。
随后，工作流程就转为事件驱动：
- 用户点击界面按钮，Client层发出事件。
- 网关收到HTTP请求，Gateway层发出事件。
- Agent开始组装提示词，Agent层发出事件。
匹配到事件后，事件总线会执行对应的处理函数。系统对外开放的接口由这些函数通过 **Ops（Operation能力）** 来调用，包括读取会话历史、登记新工具、查询团队状态，以及刷新界面数据等。
核心逻辑和扩展功能由此被拆开。Agent只要清楚两件事——什么时候该介入、能调用哪些能力，其余的调度工作由事件总线负责。
实战演练：从桌宠到Token监控
光讲道理不够，直接看两个落地例子。
案例一：把自己变成桌宠
WorkSwarm默认打开就是一套完整的工作台界面。可有些时候，用户只是想随口问一句，并不愿意展开那个大窗口。
用户发出的指令是：“给WorkSwarm加个桌宠，我想在桌面上点一下就能聊天。”
Agent把需求拆解完，做出一个扩展包，里面既有UI组件，也有状态切换逻辑。装上并启用之后，工作台右上角多出一个切换按钮。点一下，主窗口收起，桌面上留一个能拖动的胶囊或小蜜蜂图标。单击图标会弹出迷你对话框，双击就回到工作台，此前的对话上下文一点没丢。
整个过程中，WorkSwarm的核心代码一行没动，靠的全是Client层的扩展点。
案例二：Token Weather监控
对用得多的人来说，掌握Token消耗是件要紧事。可原生界面往往只给个总数，看起来不够直观。
用户指令：“在输入框上方加个状态栏，用天气图标显示Token占用程度。晴天表示用量低，暴雨表示快超限了。”
Agent做出的扩展包会监听会话消息事件。只要收发消息，它就算一遍当前会话的Token用量和窗口占用率，再按阈值换掉状态栏图标和百分比。要是嫌状态栏占地儿，用户可以接着提：“做得紧凑点，只保留百分比。”Agent马上改代码，重新热加载，界面立刻跟着变。
系统插件的管理与容错
允许Agent随意改动应用，稳定性自然成了大问题。RSI原生AgentOS在设计阶段就把这层考虑进去了。
安装与启用
系统插件的安装方式相当灵活：
- 自动生成：通过开发Skill对话生成的插件，会自动安装到WorkSwarm。
- 手动安装可以将解压后的插件文件放入安装目录，重启加载；或者在扩展页面下载安装；甚至通过命令行
/extension install安装本地ZIP包。
在“我的扩展”面板里，已安装插件的状态一目了然，启用或禁用随时可调。也就是说，多版本“Token监控”可以并存，想用哪个切哪个。
故障回退
这正是RSI友好型系统的关键之处。新装的插件要是让页面打不开，或者Agent行为不对劲，用户用不着慌慌张张去删文件。
系统提供了存档点恢复。挑一个故障前的配置快照，一键退回即可。退回之后，应用回到先前的稳定状态，用户可以接着调试，也可以直接扔掉这个有问题的插件。试错成本这么低，Agent才敢放手去改。
不止于个人：团队协作与企业级适配
RSI原生AgentOS的本事不只在个人定制界面，放到团队协作和企业集成里同样有看头。
Swarm协作增强
多Agent协作里，分工和交接常常最容易出问题。借助扩展能力，项目特有的协作规则可以被写进系统。
拿开发一个“团队协作可视化”插件来说：任务被分给多个Agent之后，插件会盯住Swarm的状态变化事件，在同一个视图里实时呈现每位成员负责什么任务、进度如何、彼此有哪些依赖。万一某项任务卡在“等待中”，用户能沿着依赖链一路追查，看看是哪个前置任务还没做完。复杂项目管理要的就是这种透明度。
企业接入适配
企业环境对安全合规卡得很严。RSI原生AgentOS的做法是，让企业在Gateway和AgentServer这两层各自加载不同的扩展，以适配分布式部署。
- 鉴权与路由：在Gateway一侧装上登录系统插件，应用入口就有了登录页，用户凭证在这里校验。没登录的请求会被拦住，只有授权用户进得来。
- 上下文隔离：到了AgentServer一侧，可以给不同部门的会话补上各自的项目上下文，也能调整服务端命令的执行参数。
- 沙箱隔离：通过适配器接入第三方沙箱，Agent的代码执行和命令运行都放在隔离环境里，把潜在安全风险挡在外面。
企业还能自定义Harness选项。比如新建会话时，界面上可以选Claude Code、Codex或openJiuwen等执行引擎，前端界面跟着动态切换，不同技术栈的需求都能照顾到。
结语：从“默认样子”到“自我进化”
openJiuwen RSI原生AgentOS的发布，是Agent应用开发模式的一个转折点。
以前，软件功能边界由产品经理和工程师划定；往后，这条边界由用户当下的需求和Agent的执行能力一起决定。WorkSwarm刚装好时只有一个默认的样子，可随着用户和Agent不断互动，它会慢慢长出桌宠、监控面板、协作视图这些“器官”，最终变成最贴合用户习惯的模样。
一边用一边改、一边改一边用，这种闭环才是Agent技术落地的真实形态。它不再是静态工具，而是能随任务演进、持续自我优化的数字伙伴。
对开发者来说，这意味着应用架构设计得重新想：扩展点留多少才够？事件和Ops接口怎么定义才清楚？扩展的安全性又该怎么保障？普通用户则只需记住一件事：想要什么功能，直接告诉Agent，让它自己做出来。
说到底，在RSI原生的世界里，Agent所想，即所得。
