工具信号｜Agent权限边界更新

OpenBot和Cumora在8月22日各自发了一个小版本。两者分属不同项目和产品线：OpenBot来自CopilotKit生态，主张把可观察、可审计的“AI coworker”跑在企业自己的基础设施里；Cumora是把人和agent放在同一套团队聊天、看板、日历和工作流里的协作产品。它们共同指向一个落地问题：当agent开始点击网页、读写文件、连MCP或接管本地CLI时，产品默认值应该怎样收紧。

可核验的时间点很明确。GitHub API显示Cumora v0.2.0发布于2026-08-22T18:31:50Z，OpenBot v0.0.4发布于2026-08-22T21:48:02Z。OpenBot这版的新闻增量是三个权限边界细节：无法解析快照ref的点击现在会拒绝；tenant package可以携带skills.yaml；技能编辑界面可以选择所需工具。Cumora这版的新闻增量则是开源后一周首个版本，release正文称合并33个社区PR、来自12名贡献者，并新增Grok Build和Cursor Agent BYOA、1650个中英文i18n key、项目级agent memory、Novita provider和一串可靠性修复。

需要保留边界的是，两个release都主要来自项目自身披露。OpenBot的“失效ref曾导致同一按钮在redeploy后被执行”是release中描述的失败模式，不等于公开安全事故；Cumora的缓存读从32%到76%也是项目自报优化，没有独立压测。这里把它们作为工程信号处理，不上升为行业转折。

对开发者和企业买方来说，这类版本比模型跑分更贴近落地。agent产品的部署难点，正在从模型调用转向权限决策、失败默认值和事后复盘。

双 release 的新闻 peg

OpenBot v0.0.4的第一项更新围绕“引用页面元素的点击”。release解释说，Bot执行页面动作时会引用来自快照的ref，服务器再把ref解析成元素，然后把这个元素交给边界策略判断。此前某类失败路径是：服务器持有快照却解析不了ref，动作仍继续执行，边界决策里的元素部分为空。这样一来，类似“不要点击任何名为submit的东西”的规则根本没有看到被点击的元素。

这次改动把这个路径改成拒绝。只要当前部署持有快照却无法解析引用，点击就不继续执行，并提示用户重新取新快照。release还特别说明，不带元素的动作不受影响，例如滚动、页面级按键、shell调用和文件读取；如果这个deployment压根没有对应computer的快照，引用仍会转发给computer，因为那时只有computer能回答。这个边界比“所有失败都拒绝”更窄，只在本来应该由服务器判断、却无法还原判断对象的地方fail closed。

OpenBot另外两项更新是技能和工具。tenant package现在可以携带skills.yaml，里面声明skill slug、标题、摘要、instructions，以及需要的serverId/toolName引用。启动时这些内容会作为deployment skills种入，用户可以在/菜单里看到。它同时强调，package声明工具不等于授予工具：最终可用工具仍会与Bot grants求交集；未知connector里的工具引用保持惰性，不会变成隐式授权。

第三项是UI补上技能所需工具的选择。此前保存接口里有tools字段，但界面没有入口，导致产品里写出的skill无法声明工具，只能手动打API。现在写或编辑skill时，会列出每个已连接server的工具，并标记会改变状态的工具。这个改动看似不大，但它把“工具选择”从隐藏API移到管理员和作者实际使用的页面上，减少了部署后靠手工约定维护权限清单的空间。

Cumora v0.2.0的新闻 peg不同。它把开源后一周收到的社区贡献收束成一个版本。release正文第一句写明：开源以来首个版本，一周内合并33个社区PR，来自12名贡献者。这更接近社区启动后的稳定化版本，新增能力和修复并列出现。

OpenBot把边界判断前移

OpenBot README对项目的定位很直接：每个Bot都有自己的computer、浏览器登录态、文件和获授权工具；任何Bot对computer、文件、MCP server或component做的事，都要经过一个gateway决定并记录。产品页也把卖点放在公司权限、computer use和AG-UI上，聊天只是入口。

v0.0.4的点击ref修复，正好落在这个定位的核心路径上。agent使用浏览器时，页面元素不是稳定对象。快照、部署、浏览器状态和真实DOM之间可能漂移。若权限策略判断的是“元素名称、host、page URL、intent”等字段，解析失败时继续执行就等于把策略输入变成空洞。OpenBot这次选择的是先写审计行，再拒绝动作。这样做牺牲了一点流畅性，换来两点收益：动作不会在边界看不清对象时落地；后续审计仍能看到有人或某个Bot试图这么做。

这和一般UI自动化失败不同。普通自动化脚本找不到按钮，大概率只是报错；agent产品里找不到按钮但继续执行，风险在于它可能点击“当前ref指向的东西”。release原文强调，同一个按钮、同一个policy，在redeploy之前曾被拒绝，redeploy之后却被执行。问题同时涉及陈旧快照、部署层和computer层对同一ref的解释差异。

skills.yaml和工具选择UI则把权限边界推到配置层。OpenBot README里已经说明，技能是instructions，capabilities另由授权系统控制；v0.0.4把这句话落到package和界面。一个skill可以声明自己需要哪些工具，但是否真的拿到工具，仍由Bot grants和connector状态决定。这个设计避免了一个常见误区：把“给模型看某段说明”误当成“给模型开权限”。两者必须是分开的系统对象，否则agent调度越自动，权限越容易被prompt文本裹挟。

Cumora把BYOA做进团队协作

Cumora README说它是“AI agents are first-class participants alongside humans”的团队聊天：同一roster、同一DM、同一群聊、同一Kanban和calendar。它提供两条brain路径：Cumora Cloud在托管pod里运行agent；BYOA让用户把自己的Mac或VPS通过npx cumora agent computer配给agent，底层可以是Claude Code、Codex、Grok Build或Cursor Agent CLI，provider key不进服务器。

v0.2.0新增Grok Build和Cursor Agent两个BYOA引擎，说明这个项目的竞争点从单一模型适配转向多种本地CLI的统一团队体验。release对Grok Build的描述包括persistent ACP stdio sessions和real-model ledger reporting；对Cursor Agent的描述包括one-shot stream-json、--resume continuity，以及triage runs read-only的--mode ask。这些都不是面向用户的漂亮按钮，目标是让外部CLI进入协作系统后还能保持会话连续、成本可记账、只读任务不误写。

项目级agent memory同样值得注意。release写到，一个agent在两个group里时，group A的工作笔记不应泄漏到group B；persona、climate、pinned notes和既有memories仍保持全局，新产生的unpinned work则限定到project。这个变化对应的是多人、多项目环境里的基本隔离问题。对于企业使用者，memory泄漏的严重性不一定低于工具误调用，因为它会把上下文、任务状态和组织信息混入错误空间。

可靠性修复部分则反映了BYOA落地后的真实摩擦：message delivery idempotency避免重试产生重复消息；WebSocket client启动时只开一个socket；BYOA daemon修复涉及可恢复session保留、stream chunk边界解析、孤儿engine子进程、--stop停止npx启动的daemon、HTTP deadlines和EOF reconnect backoff。release还称heartbeat classifier prompt变得可prefix-cacheable，使agenda cache reads从约32%到76%。这些指标仍属项目自报，但问题类型都非常具体，说明v0.2.0的重点是把“能接入本地agent”往“可连续运行、可停止、可恢复、可计账”推进。

数字和边界怎么读

这张表的重点，是防止把两条新闻合并错。OpenBot的主角是“执行边界”：ref解析失败时拒绝点击，技能工具声明不能自动越过grants。Cumora的主角是“协作运行时”：本地CLI作为agent brain接进团队系统以后，要处理会话、账本、只读模式、memory隔离、socket和daemon生命周期。两者都谈agent边界，但边界所在层级不同。

如果只看功能名，这些更新不如模型发布显眼；如果看部署风险，它们反而更接近agent产品能不能被企业接受的门槛。一个能操作浏览器的agent，最怕的是边界判断输入缺失；一个能接入本地CLI的团队agent，最怕的是会话和权限语义在不同引擎之间不一致。OpenBot和Cumora都在补这些基础层，只是一个从gateway和技能声明补，一个从BYOA runtime和协作记忆补。

对开发团队的直接启发

第一，失败默认值需要单独设计。OpenBot没有把所有异常都简单归为拒绝，而是区分“服务器应该能解析但没解析出来”和“服务器本来没有快照，只能转发给computer”。agent边界不能停在一句“fail closed”，它必须列出每类动作的判定主体、输入字段和审计时机。否则过度拒绝会让系统不可用，过度放行又会让策略只是摆设。

第二，instructions和capabilities必须分离。OpenBot的skills.yaml只是声明skill需要哪些工具，真正授权仍由Bot grants决定；Cumora的BYOA路径让本地daemon承担agent brain，避免把provider key交给服务器。两者在不同层面表达同一个原则：模型能看到的上下文、用户能选择的skill、agent实际能调用的工具，应当是三张表，不应合并成一段prompt。

第三，跨项目memory正在变成agent协作的安全边界。Cumora把unpinned work限定到project，而把persona、pinned notes等保留为全局，是一个折中：完全无记忆会牺牲协作连续性，完全共享又会带来上下文污染。这个设计后续值得看，因为企业agent一旦进到多项目、多团队环境，“记住什么”和“不能带去哪儿”会比“能不能多轮对话”更关键。

接下来看什么

OpenBot接下来的验证点，是这次ref拒绝会不会暴露更多“之前被静默放行”的动作。release已经提醒部署可能看到以前没有的refusal，这属于原先边界看不见目标的动作开始被挡下。后续如果项目能公开拒绝类型、误拒绝修复和管理员审计视图，会更有助于判断它的企业可用性。

Cumora要看的则是BYOA的一致性。Claude Code、Codex、Grok Build和Cursor Agent CLI的会话语义、输出格式、停止机制和账单口径并不天然一致。v0.2.0把多个边角问题列进release，是好信号；下一步需要看这些修复能否在真实团队里减少重复消息、孤儿进程、断线恢复失败和跨项目记忆污染。

更大的问题是，这类开源agent工作台会不会形成一套默认安全清单：工具声明与授权分离、写操作显式标记、只读模式可验证、每次动作先记录再执行或拒绝、memory有项目边界、BYOA不泄露provider key。今天这两条release的共同增量，正是把这些清单项从架构图推进到具体版本。