OPEN SOURCE DEEP DIVE
OpenMausBot:本地多智能体与电脑操作控制平面
一个本地优先的多智能体控制平面,统一接入多种代理引擎,持久管理任务委派、审批、隔离浏览器、远程访问和无界面运行。
多数桌面代理产品把重点放在一个聊天窗口里,让模型完成更多任务。这个项目选择了另一条路线:把本地电脑变成多个机器人共享的操作平面,每个机器人可以接不同的代理引擎,而人只需要在一个界面里观察工作、回答提问、审批高风险动作,并控制每个机器人可以在哪里行动。
仓库是一个由桌面应用承载的本地运行时。它自己管理代理进程,通过本地接口接收结构化命令,再把不同供应商的输出汇成一条统一事件流。这个分层很关键。不同代理引擎没有共同的本地协议,项目因此把编排层和某个模型供应商解耦,让界面面对稳定的运行时契约,而不是分别适配每一种协议。
两个进程,一套事件契约
桌面渲染层连接本机回环地址上的控制服务。渲染层没有自己的代理传输通道,只发送创建机器人、开始回合、回答权限请求和切换模型等结构化命令,同时消费一条统一事件流。控制服务内部维护驱动注册表,把每个机器人配置对应到实际运行的代理实例。不同本地命令行代理和兼容协议代理都被转换成同一套运行时词汇。
统一事件流不只是日志。界面需要借此知道模型正在思考、调用工具、等待审批、生成回复,还是一个回合已经结束。供应商仍然负责自己的推理和工具机制,控制服务负责生命周期、事件汇聚、持久化和权限中转。某个驱动启动失败时,系统把该机器人标记为不可用,而不是让整个机器人队列一起崩溃。
| 层次 | 负责内容 | 边界带来的价值 |
|---|---|---|
| 桌面应用 | 对话、模型选择、审批、电脑面板和设置 | 更换引擎不必改变人的操作方式 |
| 本地接口 | 回合、机器人、线程、权限、电脑生命周期和连接器 | 不同客户端共用一套命令和事件 |
| 供应商驱动 | 本地代理会话与协议转换 | 厂商特有行为被隔离在较小契约后面 |
| 任务运行时 | 委派树、队列、提问、预算和重启恢复 | 多机器人协作有持久状态,而不是界面里的临时承诺 |
委派被当作持久任务系统处理
仓库最有价值的部分是任务运行时。一个机器人把工作交给另一个机器人时,请求会变成一条持久记录,包含根任务、父任务、深度、请求者、执行者、审批级别、状态、结果、证据和完整事件历史。进程重启以后,系统读取这条记录恢复工作,而不是询问模型“你还记得刚才做到哪里吗”。
任务状态覆盖排队、运行、等待子任务、等待人的回答、可以恢复、完成、失败和取消。父任务把工作分给多个子任务后进入等待状态,所有结果到齐时只恢复一次。子任务遇到需要人决定的问题时,父任务会带着问题恢复,而不是自行编造答案。外部运行环境可以轮询任务状态,单向通知则可以完全不等回报。
系统还设置了防止协作失控的预算。每个任务树从上次有效进展开始统计请求数、执行次数和唤醒次数。仓库中的默认值允许四层深度、二十四次请求、四十八次执行和四十八次唤醒。排队任务超过二十四小时会过期,四小时没有有效进展会失败,单个回合二十分钟没有活动会被判定为停滞。这些是运行时默认值,不代表所有团队都应照搬。
| 保护项 | 默认值 | 作用范围 |
|---|---|---|
| 委派深度 | 四层 | 同一任务树允许的父子层级上限 |
| 请求与执行预算 | 二十四次请求、四十八次执行、四十八次唤醒 | 从任务树上一次有效进展开始统计 |
| 排队过期 | 二十四小时 | 尚未开始的排队任务 |
| 停滞判定 | 任务树四小时、单回合二十分钟 | 分别约束整棵树和一个活动回合 |
重启处理尤其具体。回合在派出子任务之前被中断,系统可以在原位置重跑一次。回合已经派出子任务后中断,任务返回等待状态,再根据子任务结果恢复。控制端已经确认这个回合发出了消息、推送了提交或执行了其他外部动作时,系统不会重跑,避免重复副作用。每次恢复都会写入事件。很多代理系统直到电脑在委派中途休眠,才意识到这些记录不能靠推测补出来。
审批级别不等于统一的安全保证
项目向引擎传递四类权限级别:询问、自动接受编辑、代替我批准和完全访问。每种级别尽量映射到供应商自己的权限模式。仓库明确承认,相同名称在不同引擎里并不总是相同机制。不同代理在沙箱、原生审查和权限请求方式上差异很大。控制服务把最终生效的级别写进任务记录,并根据接收引擎真实支持的能力限制继承的权限。
默认级别是完全访问。这是一个需要认真对待的部署选择,不能当作无风险的便利设置。在该模式下,引擎使用自身最宽松的原生模式,残留权限请求可能被自动回答,连接应用里的发送动作也可能不再出现额外确认卡。完全访问仍不能绕过操作系统隐私控制、登录挑战、服务权限或工作区授权,也不能替人提供缺失的信息。仓库把这些边界写清楚很重要,因为权限弹窗并不等于完整的安全边界。
团队负责人可以把审批级别传给被委派的任务,但继承方向有明确规则,不会因为普通同伴发起任务而让高权限队友获得更低或更高的意外授权。接收引擎还可以限制请求的级别。运行时把解析后的级别写入任务,并检查实际回合是否按该级别执行。这本身不会让危险流程变安全,但能让操作者事后知道当时使用的是哪一级权限。
一组机器人,多种执行电脑
项目把代理身份和实际执行位置分开。机器人可以在云端桌面、隔离的本地虚拟机、自动浏览器、安卓工具、已连接应用或受支持的本机电脑上工作。模型账号不应自动等于所有桌面、浏览器资料、凭据和应用的访问权,这个区分是整个设计的基础。
浏览器路径为每个机器人建立独立资料和浏览器会话,所有连接都通过随机端口上的本地代理门。代理门自己解析域名并检查每个解析地址,重定向和域名重绑定不能悄悄把公开网页请求变成对本地管理接口的访问。机器人无法访问项目自己的回环服务,云元数据地址、链路本地地址、组播和特殊网段默认被拒绝。自建服务器可以显式放行某些私有网段或端口。代理门本身不可用时,浏览器直接拒绝联网。
这种隔离不是模型推理的完整安全沙箱。它限制的是随包浏览器可以连接到哪里。已经拥有文件系统或命令执行能力的代理,仍受引擎自身沙箱和审批级别约束。仓库把不同电脑面的边界分开说明,没有把它们包装成同一种能力。
本机控制按平台刻意区分
在苹果电脑上,打包应用可以在用户明确开启后控制本机。乌班图系统的本机控制仍处于测试阶段,只在某种传统图形会话里经过二次明确开启后可用。随包的原生控制运行时在打包阶段固定版本并校验哈希,启动时关闭装饰性的全屏光标覆盖层。在新式图形会话下,本机控制直接禁用。屏幕预览可以经由系统桌面门户工作,但应用不会借兼容层绕过安全门槛。
这种平台差异不是缺陷包装,而是文档的诚实之处。把屏幕预览和真实键盘鼠标控制混为一谈,很容易对外宣称“支持桌面操作”,实际却无法安全完成输入。仓库拒绝走这条捷径,清楚描述限制和旧选择项的清理方式。云端桌面和本地虚拟机在新旧图形会话下都能使用,因此产品仍保留其他执行面。
对无人值守流程来说,这个警告尤其重要。浏览器自动化、云桌面任务和点击主人真实桌面的任务并不等价,即使界面都把入口放在“电脑”下面。部署时应选择能完成工作的最窄执行面,只有确实需要时才由人授予更宽的本机控制。
远程访问只开放有限的伴随接口
手机和桌面伴随端不会接触完整本地接口。独立伴随服务接收配对设备请求,校验每台设备自己的令牌,按默认拒绝的路径白名单检查请求,再清除响应中的敏感字段后转发。核心控制服务仍然只监听本机回环地址。配对使用一次性短码和只留在页面片段里的启动令牌。设备令牌本身也不足以取得电脑控制权,所有者还要单独给该设备开放电脑访问。
白名单按请求方法和路径逐项定义。配对设备可以读取聊天和审批所需数据,但凭据、任意设置、破坏性账号操作、本地虚拟机生命周期和宿主专属浏览器界面保持关闭。新增接口默认不向远程设备开放,必须有人明确加入白名单。对一个会持续扩展远程面的产品来说,这种默认方式更容易审计。
桌面客户端也可以与另一台主机配对。此时仍然经过同一个伴随边界,客户端模式不会变成完整本地接口的代理。这样做少了一些“把桌面应用变成远程终端”的夸张效果,却在手机丢失或配对过期时更容易撤销和推理。
无界面运行把机器人团队变成自动化组件
命令行工具可以脱离桌面窗口运行团队。用户能够应用团队定义、把一个任务交给某个机器人、等待该机器人和所有被它请求的队友结束,再导出结果。结构化输出和不同退出码让它可用于持续集成和普通脚本。
项目还提供标准输入输出形式的模型上下文协议服务。外部客户端可以查看机器人和频道、读取经过压缩的对话页、创建机器人、发送任务、等待完成、切换模型和中断回合。这个接口刻意不开放审批授权、删除、任意设置、凭据和电脑生命周期。边界很有意义:外部代理可以编排团队,却不能悄悄成为所有密钥和设备的主人。
已连接应用使用第三方的多账号会话。一个安装可以保存同一服务的多个带标签账号,避免第二次授权时静默替换第一个账号。机器人拿到的是明确工具清单,而不是所有已连接服务的总和。这里仍有一个重要信任问题:邮件或协作应用的写入动作会产生真实影响,审批级别决定机器人是否先询问。团队应按角色配置工具,而不是按“谁碰巧连接了账号”配置。
仓库证明了什么,又没有证明什么
仓库展示了一套连贯架构和一个可运行的早期产品,没有给出受控评测来证明多机器人团队一定优于单个长上下文代理,也没有证明同一审批名称在不同供应商下具有完全一致的行为。这些是独立问题。这个项目的主要贡献,是把差异变成显式记录:哪个引擎运行、使用哪种电脑、拥有哪级权限、派生了哪些子任务,以及控制服务观察到了什么证据。
因此当前版本适合审慎试用。先用本地工作区,对涉及重要系统的操作使用询问或供应商审查,保持密钥远离提示词,只给真正需要的设备开放远程电脑权限。默认完全访问适合实验,不适合无人值守的管理员场景。委派真实代码、邮件或桌面修改时,应设置完成条件并检查任务证据,不能只看最后一段流畅回复。
项目适合放在什么位置
这个项目属于代理运行框架和电脑操作控制平面这一类别。它对需要复用具身智能代理工具的团队有参考价值,但它不控制机械臂,也不发布运动策略。实际场景主要是软件工作、浏览器研究、桌面操作、已连接应用流程和多机器人协作。可迁移的经验包括:把模型传输放在契约后面,让委派工作持久化,把机器人身份与执行面分开,并在远程访问前放置默认拒绝边界。
仓库主体采用阿帕奇二点零许可证,企业目录使用单独的源码可见许可证。乌班图支持仍是测试版,新式图形会话的本机控制处于禁用状态,视窗安装包尚未代码签名。这些不是可以藏在脚注里的事实,它们决定当前版本是否适合某个部署。对愿意监督早期本地系统并改进驱动或安全边界的团队来说,这个仓库罕见地完整展示了模型演示与多代理控制面之间真正困难的那一层。