oiia（SubgroupX）
在浏览器里指挥多智能体，让代码真正跑在你指定的云端、SSH 主机或没有公网 IP 的机器上。
- Star 数
- ★ 374
- 最近更新
- 3 个月前
- 主语言
- TypeScript
- FA 评分
- 49/100 · 缺口较多
30 秒速览
- 可在哪里用
- 通用 · 跨平台OpenAI API
- 开始前需要
- 典型场景
- 安全评估人员需要在授权范围内对目标做侦察与工具链操作，并希望使用为“授权评估”配置的会话档案与预装 Java 8/11、SecLists、WASM 逆向工具的 E2B 模板。
- 主要局限
- 许可证状态未知，仓库未给出明确许可，企业采用前需要自行确认授权条款。
- 源码审查
- 49/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
oiia 是 SubgroupX 团队开发的多用户智能体平台，通过浏览器访问，服务端是 Node/Express + ws，并以 SQLite（node:sqlite，WAL 模式）作为唯一事实来源。它把“会话在哪里执行”做成每个会话的创建期选项：connector（由内网机器主动外拨 WebSocket 的守护进程）、ssh（服务端出站 SSH）、e2b（一次性云 VM）与 local（服务器本机，Linux 用 bwrap、macOS 用 seatbelt）。智能体引擎不是自研，而是对 pi-mono 的 Agent 做有状态适配，pi-ai 提供多提供商流式输出，pi-agent-core 负责回合循环。会话是服务端持久对象，刷新、断网、重新部署或换手机都能继续，历史按顺序回放。客户端是 React SPA，同时是可安装的 PWA，安装与否都连接同一批会话。
一次回合由客户端发送 send_message 开始：运行时占用该回合、首次连接 MCP 服务器并组装工具集，然后调用 agent.prompt。pi 的 Agent 循环从模型侧流式输出，增量被转成带 toolKind 的 assistant_* 与 tool_* 线协议事件。每次工具调用前会经过审批闸门，在 on-request 策略下发出 permission_request 并阻塞等待 socket 回传结果。批准后的工具在能力总线上执行：内置工具落在所选沙箱，MCP 工具进入各自的服务器，spawn_subagent 则以嵌套子智能体形式运行并流式展示为嵌套时间线。编排层在 SQLite 中持久化智能体树，配有基于许可的分发器任务队列、跨会话共享队列的智能体团队与声明式工作流；智能体可寻址，能在运行中转向或对已完成者追问。运行时给每帧打上 (epoch, seq)，客户端只向服务端真值收敛；shared/src/timeline-reducer.ts 这个纯 reducer 在服务端与浏览器同时运行，分别产出 timeline（给人看）与 messages（给模型看）两个投影。此外还有文件树、预览与上传、三种审批策略、断线重连回放、带脱敏的分享链接与审计日志。
- 安全评估人员需要在授权范围内对目标做侦察与工具链操作，并希望使用为“授权评估”配置的会话档案与预装 Java 8/11、SecLists、WASM 逆向工具的 E2B 模板。
- 开发者有一台藏在 NAT 或企业网络后的工作站，希望智能体直接在那里读写真实文件，而不申请端口转发、入站规则或 VPN。
- 团队想让同事在笔记本上发起长任务，自己在手机上查看进度并批准命令；会话在服务端运行，关掉浏览器也不会中断。
- 需要并行推进多个子任务的研究或工程场景：用 spawn_subagent 分裂子智能体，通过嵌套时间线观察整棵智能体树。
- 自托管爱好者想在一台服务器上跑完整栈，把模型密钥加密存放在本地（AES-256-GCM），不把上游域名、模型 id 或凭据编译进源码。
- 需要给团队内多个成员共享同一套会话与工具、又要按成员区分权限并留存审计日志的小型组织。
如何安装或部署这个 Agent？
需要 Node 22.19–24（原生 PTY 决定上限，当前 pi/undici 决定下限），CI 与部署使用 24。先安装依赖、构建前端，再用 tsx 启动服务端：
npm install
npm --prefix web install
npm run build:web
PORT=4317 AGENT_WEB_DATA_DIR=./data npx tsx server/src/index.ts开发模式（热重载）需要两个终端，web 端会代理 /api 与 /ws：
PORT=4317 npx tsx watch server/src/index.ts # terminal 1
npm --prefix web run dev # terminal 2关键环境变量（均有默认值或可留空）：
PORT=4317 # HTTP/WS 端口
AGENT_WEB_DATA_DIR=./data # SQLite 与每会话工作区
AGENT_WEB_SECRET=... # JWT 签名密钥，设固定值以保持登录稳定
AGENT_WEB_KEY_SECRET=... # 提供商密钥加密密钥，默认取上者
AGENT_WEB_SEATBELT=1 # macOS 上把 bash 包进 sandbox-exec
AGENT_WEB_E2B_KEY=... # 启用 E2B 云沙箱
AGENT_WEB_E2B_TEMPLATE=...
AGENT_WEB_MCP='[...]' # JSON 数组形式的 MCP 服务器如何使用这个 Agent？
启动后打开 http://localhost:4317，注册账号，并先用 Mock Coder 模型创建会话——它不需要任何密钥，能理解指令，因此可以离线驱动真实工具：
/bash
/write <path>
/read
/ls
/edit
/subagent <task>
/mcp要接真实模型，在 Settings 里填入自己的提供商密钥（落盘时以 AES-256-GCM 加密），此后 pi-ai 支持的任何模型都会出现。运维方还可以配置共享通道作为默认模型，但 AGENT_WEB_JAIL_KEY 与 AGENT_WEB_JAIL_BASE_URL 必须同时给出，没有端点兜底。
想在没有公网 IP 的机器上执行，就在那台机器上运行仓库 scripts/ 目录提供的 connector 守护进程，让它主动向服务端外拨 WebSocket，然后在创建会话时把后端选为 connector。验证与测试：
npm run e2e:install # 一次性下载 Chromium
npm run e2e # 构建 web、启动服务端、跑 141 个 Playwright 用例（mock 模型）
npm run e2e:real # 同样的流程对接真实模型，无密钥时跳过
npm run test:resume # 验证时间线与转写能扛住服务端完整重启
npm run typecheck
npm run check:layout # 校验源码位置与向内依赖边界这个 Agent 有哪些优点和局限？
- 四类沙箱后端（connector/ssh/e2b/local）藏在同一个 Sandbox 接口后，切换执行目标不改变文件树、终端与审批体验；connector 让没有公网 IP 的机器也能成为执行端，无需端口转发、入站规则或 VPN。
- 会话是服务端持久对象，数据库为唯一事实来源、运行时是可重建缓存，因此空闲释放、会话切换、重新部署与回退都是同一个“销毁后惰性重建”操作。
- 不重造智能体引擎：直接适配 pi-mono 的 Agent 与 pi-ai，多提供商流式输出和回合循环由上游承担，oiia 只做有状态适配。
- 架构约定可执行而非仅文档化：check:layout 断言源码根与向内单向依赖，违反即构建失败；前端还有“公共页面绝不发起鉴权请求”的模块图级保证。
- 测试密度高：141 个 Playwright 用例驱动真实浏览器、真实服务端、真实沙箱与文件系统，另有 120 个 check:* 一致性校验脚本。
- 源码树中不编译任何上游域名、模型 id 或凭据，未配置的构建只是让该通道休眠，自托管部署的边界清晰。
- 许可证状态未知，仓库未给出明确许可，企业采用前需要自行确认授权条款。
- 部署不是一条命令的事：要装两套依赖、构建前端、启动 tsx 服务端，还要决定模型通道、密钥管理与沙箱后端，属于中等偏上的运维负担。
- 本地沙箱隔离的是文件操作而非任意代码，README 明确建议不可信执行改用 E2B 或你愿意交出的 connector 机器。
- 运行时被 Node 版本夹在 22.19–24：原生 PTY 定上限、pi/undici 定下限，升级 Node 或替换依赖时要一并验证。
- Connector 的安全模型意味着目标机器上的守护进程要主动连回服务端，等于把该机器的执行权交给这套部署，边界需要自行划清。
- 没有单元测试框架，正确性全靠端到端用例与 check:* 脚本，改动底层模块时反馈周期偏长。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
信任维度：README 明确列出三种审批策略、on-request 审批门、AES-256-GCM 加密存储 provider key、bwrap/seatbelt 本地沙箱、SSH guard 与 connector 出站拨号，且 e2e 测试覆盖审批恢复与拒绝路径，故 least_privilege 与 user_confirmation 给 2。但 README 自承本地沙箱只隔离文件操作、不隔离任意代码，connector 等于把整台机器交给 agent，属于高权限面；数据流透明性只有文字描述，缺少可核验的传输/存储细节，给 1。依赖安全方面 package.json 有大量第三方依赖与 postinstall 补丁脚本，虽有 check:dependencies 与 overrides，但未见漏洞扫描或 SBOM，给 1。外部副作用与回滚：有 rewind、审计日志、会话持久化，但缺少对已执行外部命令的撤销机制，给 1。来源归属：README 致谢贡献者并声明 SSH 签名提交，但发布者身份未经验证、许可证未知，给 1。
可靠性：README 描述 (epoch, seq) 排序、纯 timeline reducer 双端一致、SQLite 为真源、check:layout 强制依赖方向，并有 test:resume 与 141 个 Playwright 用例，自洽性给 2。依赖可用性：engines 限定 Node 22.19–24，原生 PTY 限制上限，postinstall 打补丁，依赖版本用 ^ 浮动，存在安装脆弱性，给 1。失败信息：e2e 明确断言网络失败与 502 时给出人类可读且本地化的错误而非浏览器原文，给 2。
适配性：README 清晰区分四类沙箱后端与适用场景（无公网 IP、SSH、E2B、本地），受众与场景给 2；能力边界有 Notes 明确说明本地沙箱不隔离任意代码，给 2；触发精度方面仅有 /bash、/write 等指令示例，缺少对何时触发何种工具的精确规则说明，给 1；环境适配有完整环境变量表与 PWA 多端说明，给 2。
惯例：README 结构清晰、有 Layout 与运行步骤，信息架构给 2；安装说明含 Node 版本、npm 命令与 Mock Coder 离线路径，给 2；命名稳定性方面仓库名 SubgroupX/oiia/agent-web 镜像名不一致，给 1；示例与 FAQ 只有少量指令示例、无 FAQ，给 1；已知限制有 Notes 段落，给 2；许可证元数据未知且仓库内未见 LICENSE 文件，给 0；版本号 0.1.0 但无 CHANGELOG，给 1；维护责任仅靠致谢与未验证发布者，给 1。
有效性：输出可用性有文件树、终端、审批、分享链接、审计日志等完整产品面，给 2；边际价值在于 connector 让无公网 IP 机器成为执行端、多 agent 编排与持久会话，相对通用 coding agent 有差异化，给 2；成本效益方面需要自托管 Node 服务、SQLite、可选 E2B/SSH/connector 守护进程，运维成本不低且无基准数据，给 1。
可验证性：README 声称 141 个 Playwright 用例与 120 个 check:* 契约，package.json 与 CI 工作流确实列出大量 check 脚本，可追溯性给 1（有清单但未提供运行结果）；跨源印证方面 README、package.json、CI 与测试文件相互一致，给 1；事实与推断分离方面 README 多为断言式描述，部分（如 check:layout 禁止导入 API client）可由脚本名推断但未见实现，给 1。
- 本地沙箱只隔离文件操作、不隔离任意代码；connector 模式等于把整台机器交给 agent，请仅在可弃置或可信任的机器上使用。
- 许可证元数据未知且仓库内未见 LICENSE 文件，商用或再分发前必须自行确认授权。
- 发布者身份未经验证，安装与部署前应独立核验来源与镜像。
- 依赖使用 ^ 浮动版本并带 postinstall 补丁脚本，构建可复现性与供应链风险需自行评估。
- README 中的测试数量与契约声明未提供运行结果，本评估为静态审阅，未执行任何测试。