Archer OS 这个项目从标题就能读出它的定位它不是又一个用于生成图片或视频的 AI 模型也不是某个双击就能运行的客户端工具而是一份面向 AI Agent 的规范草案draft spec。这份规范要解决的核心问题非常具体AI Agent 在操作系统授权之下如何安全、可控、可审计地操作应用程序。现在市面上绝大多数 AI Agent 操作 App 的方式本质上依然是“非授权”的。要么是截图加坐标点击的 GUI 自动化要么调用系统辅助功能接口要么读取 UI 控件树后模拟输入。这三种方式各有各的毛病截图坐标方案极易受窗口大小、分辨率、弹窗状态影响辅助功能接口的权限范围往往比 Agent 实际需要的更大应用脚本接口则碎片化严重每个应用都要单独适配。更麻烦的是用户对操作过程几乎没有可见性不知道 Agent 正在做什么、已经获得了哪些权限、这些权限什么时候会被收走。Archer OS 想给的答案是一套“在 OS 授权之下操作应用”的机制。Agent 不再是躲在无障碍服务背后偷偷执行动作而是通过操作系统暴露的、有边界的、可追踪的接口去操作应用。用户、系统、应用三方都能看到 Agent 的动作也能在任意时刻中止它。这篇文章不会假装已经有一个完整可运行的 Archer OS 发行版等待下载。从项目状态看它更接近一份协议设计文档。因此我换一个更落地的思路先拆解这份规范想解决的问题和可能的架构模型再给出一套可以照着实现的接口设计、权限模型、批量任务编排方案以及常见问题排查清单。如果你正在做 AI Agent 产品、RPA 工具、桌面自动化框架或者研究方向与系统安全相关这篇文章可以直接收藏。1. Archer OS 核心能力速览由于 spec 本身不是软件这里用表格列出理解这份规范时需要首先关注的维度。能力项说明项目定位面向 AI Agent 操作应用程序的规范草案不是直接可运行的软件核心目标在操作系统授权OS authority下让 AI Agent 以受控、可审计方式操作 App主要解决问题GUI 自动化脆弱、辅助功能权限过大、应用接口碎片化、缺少操作审计设计对象操作系统层、应用层、Agent 层之间的权限协议与执行机制当前阶段Draft spec协议和权限模型需要社区讨论与实现验证适用人群AI Agent 开发者、RPA 工程师、操作系统与安全研究人员落地方式系统级权限服务、IPC 通信、能力声明、审计日志批量任务支持可通过任务队列与多会话机制实现但需要以具体实现方能力为准API 接口规范层面可落地为本地 IPC、HTTP 服务或 SDK具体路径由实现方定义硬件要求不依赖特定推理硬件CPU 即可完成协议解析与权限校验从材料看Archer OS 目前没有一个可以立刻 clone 下来跑 demo 的完整实现。但这不影响我们把它当做一个架构参考来研究。选择这类 spec 型项目的正确方法是先弄清楚它想定义什么再考虑怎么在自己的工程里落地。2. 适用场景与使用边界从设计动机看Archer OS 这一类系统级 Agent 操作规范最适合解决的是“Agent 操作真实应用”时的信任与控制问题。适合的典型场景有三类。第一类是桌面级 AI 助手。用户对着电脑说一句“把这份文档整理成邮件发给同事”Agent 需要打开文档应用、读取内容、打开邮件客户端、创建草稿。如果没有系统级授权机制Agent 每一步都要靠截图识别坐标识别错了就会点到无关位置。有规范之后邮件客户端可以主动声明“我支持创建草稿、填写收件人、发送邮件”这几个能力Agent 直接调用整个流程可控得多。第二类是企业 RPA 工具。RPA 最大的痛点是界面变化导致脚本失效。Archer OS 这类规范如果用“能力声明”替代“控件坐标”RPA 脚本就不再绑定到具体的像素位置而是绑定到应用主动暴露的操作语义。应用升级之后只要能力接口语义不变RPA 依然可用。第三类是手机端的 AI 代理。移动应用权限模型更严格Agent 操作 App 的合规空间更小。系统级授权机制可以做到“临时授权、用完即收”比长期打开无障碍模式更安全。使用边界也要说清楚。spec 不是成品不包含具体的模型推理、OCR、语音识别组件也不解决应用是否愿意暴露能力的问题。如果一个应用根本不想被 Agent 操作再完整的规范也无法通过后门强行控制它。Archer OS 的落地高度依赖操作系统厂商和应用开发者的配合。3. 从 draft spec 到落地三层架构拆解如果要把这份规范落地成可运行系统最合理的方式大概率是三层架构。3.1 Agent 层Agent 是任务的发起方负责理解用户意图、拆解任务步骤、发起权限申请、调用应用能力。在 Archer OS 模型里Agent 本身不直接操作 UI也不再通过截图去猜坐标。它只面向一组接口和数据结构做决策。这意味着 Agent 需要内置一套“能力路由”逻辑知道什么任务该调用哪个应用也知道权限不足时应该停下来申请权限而不是强行执行。Agent 层还有一个容易被忽略的问题记忆和上下文的持久化。Agent 在执行长任务时需要记住已经完成到哪一步、哪些操作被用户撤销过、哪些能力声明已经过期。这部分状态如果放在 Agent 进程内崩溃后就要重来。规范设计上应该考虑让 Agent 把任务状态同步到系统服务形成可以恢复的会话记录。3.2 系统授权服务层这一层是整个规范的核心。系统授权服务接收 Agent 发来的权限申请检查用户是否已经授权、授权范围覆盖哪些应用和操作然后把 Agent 的调用请求分发到对应应用最后收集执行结果回传给 Agent。所有请求先过授权校验再进入执行链路。这个层需要有四张基础数据表模型Agent 注册表、应用能力注册表、授权记录表、执行日志表。Agent 注册表记录谁能发起调用能力注册表记录应用暴露了哪些操作授权记录表维护权限的有效期和范围执行日志表记录每一次调用的完整信息。3.3 应用桥接层应用需要有一个“桥”把自己的操作语义暴露出来比如“打开文档”“选择文本”“创建邮件”“点击发送”。这层可以由应用自己实现也可以由操作系统为传统应用提供默认适配器。三层结构带来的第一个直接变化是权限边界变得清晰。Agent 的每一次操作都有明确的发起者、目标应用、操作类型和触发时间。用户不再面对“这个助手能不能访问我的全部屏幕”这种二元选择而是可以精细到“它只能操作文档应用并且只能执行打开文档和提取文本这两类动作”。第二个变化是操作可追踪。所有 Agent 发起的操作都经过系统授权服务系统可以记录完整调用链。每一条记录包含 Agent ID、目标应用、操作名称、输入摘要、结果状态、耗时。出现问题时可以直接回到时间线定位是哪一步出错。3.4 授权模型设计授权模型是整份规范设计的灵魂。一个可行的模型至少包含这几个要素。权限主体Agent ID用来标识谁来发起操作。不同 Agent 应当有不同信任等级本地助手、企业自动化脚本、第三方插件的默认权限范围不应该一致。权限客体App Bundle 或应用唯一标识用来标识操作目标。授权范围通常精确到单个应用不推荐做“所有应用”级别的授权。操作集合Capabilities用来标识允许做什么。应用能力需要分类管理比如只读类读取文本、获取选中内容、写操作类创建文档、发送消息、破坏性操作删除文件、发送邮件。不同类型应有不同的授权策略。有效期Duration用来标识授权持续多久。一次性授权用完即失效长任务授权可以设置最长执行时间。过期后即使 Agent 还在运行系统服务也应当拒绝执行。风险等级Risk Level用来区分操作是否需要用户二次确认。低风险的读取操作可以预先授权高风险的写操作、发送类操作必须用户确认。这个逻辑和手机系统里的“单次允许 / 使用期间允许 / 永不”类似只是粒度更细。4. 核心协议设计思路一份没有接口定义的 Agent 操作规范很容易停留在概念层面。真正开发时至少要把下面几个交互点定义清楚。下面的 JSON 片段是通用设计示意不是 Archer OS 官方数据结构实际实现时可以根据自己的协议格式调整。4.1 能力发现应用启动时通过系统服务注册自己支持的操作。协议层可以设计成 JSON 格式声明。{ app: com.example.docs, version: 1.3.0, capabilities: [ { name: open_document, description: 打开指定路径的文档, category: read, schema: { type: object, properties: { path: { type: string } }, required: [path] } }, { name: extract_text, description: 提取当前文档的纯文本, category: read, returns: { type: string } } ] }Agent 在任务开始前先查询“哪个应用能做我要做的事”系统服务返回可用应用列表Agent 再决定调用谁。这个机制的应用价值在于Agent 不需要预先硬编码每个应用的细节而是通过运行时发现获得能力列表。应用新增了一个能力Agent 不需要升级本身就能感知到。4.2 权限申请Agent 拿到能力列表后向系统申请调用权限。一次权限申请应当包含目标应用、需要调用的能力集合、任务描述、请求时长。{ agent_id: local_assistant, request_time: 2025-01-01T10:00:00Z, permissions: [ { app: com.example.docs, capabilities: [open_document, extract_text], duration_minutes: 30, purpose: 为用户整理当前文档摘要 } ] }系统服务的处理逻辑是先查用户预设策略再查是否有临时白名单。若高风险操作未在策略中则弹出用户确认窗口用户同意后生成一条带 expire_time 的授权记录。收到授权记录后Agent 才能继续发起执行请求。4.3 任务执行权限通过后Agent 通过系统服务调用应用能力。执行层建议采用请求 ID 加异步回调的方式避免长时间操作阻塞 Agent。执行请求大概长这样{ request_id: req_0001, agent_id: local_assistant, app: com.example.docs, capability: open_document, args: { path: /home/user/example.md } }系统服务收到请求后先校验 request_id 对应的授权记录是否仍然有效再校验参数是否符合能力 schema最后转发给应用执行。应用执行完成后回传结果系统服务把结果返回给 Agent。4.4 结果回传与错误处理结果回传需要定义完整的错误码体系。最重要的不是常规业务错误而是权限类错误授权过期、能力不存在、操作被用户撤销、请求频率超限。Agent 拿到权限错误后应当停止操作并向用户重新申请而不是自作主张反复重试。如果目标是幂等操作Agent 可以复用原 request_id 重试如果目标是不确定是否已执行的写操作重试前必须向用户确认。5. 批量任务与多 Agent 编排如果 Archer OS 只解决单个 Agent 的调用问题工程价值就少了一半。实际场景中批量任务和多 Agent 协作才是关键。批量任务的核心思想是把“一个 Agent 逐步操作”升级为“一个队列管理大量操作”。设计上通常包含四个部分任务队列、调度器、执行器、状态存储。任务队列负责接收批量请求。比如“把输入目录下的 50 个文档逐一打开、提取文本、生成摘要、导出 Markdown”。在 Archer OS 模型里这个批量任务会被拆成多次权限调用和多次能力执行。队列负责保证每步只发生一次失败后能重试。调度器负责把步骤分配给可用 Agent。如果有多个 Agent 实例调度器需要考虑负载和当前授权状态。如果一个 Agent 已有某个应用的授权调度器可以优先复用如果没有需要在任务开始前统一申请批量授权。状态存储记录每个任务的执行进度。这样异常中断后可以从断点恢复而不是从头跑。下面给出 Python 风格的伪代码演示批量任务如何与权限系统交互import requests import time AUTH_SERVICE http://127.0.0.1:8901 def apply_batch_license(agent_id, app, caps, count): resp requests.post( f{AUTH_SERVICE}/v1/permissions, json{ agent_id: agent_id, app: app, capabilities: caps, duration_minutes: 120, purpose: fbatch processing {count} docs }, timeout10 ) resp.raise_for_status() return resp.json()[permission_id] def run_batch(doc_paths, callback): permission_id apply_batch_license( agent_idagent_a, appcom.example.docs, caps[open_document, extract_text, export_markdown], countlen(doc_paths) ) for idx, path in enumerate(doc_paths): resp requests.post( f{AUTH_SERVICE}/v1/executions, json{ permission_id: permission_id, app: com.example.docs, capability: open_document, args: {path: path} }, timeout60 ) if resp.status_code ! 200: callback(error, path, resp.text) continue callback(ok, path, resp.json()) time.sleep(0.2)这里要说明伪代码中的/v1/permissions和/v1/executions不是 Archer OS 官方路径只做架构示意。任何实现方定义自己的 REST 或 IPC 路径都是合理的关键是把协议字段保持一致。批量任务最容易踩的坑有两个。第一个是授权过期。批量任务运行时间超过授权有效期时后续调用全部失败。好的做法是先估计批量任务预计耗时再申请足够长的授权窗口如果任务中途授权过期则需要实现重新申请、从断点继续的机制。第二个是单点失败重试策略。批量任务里的文档偶尔会损坏或格式不对不能因为一个文件失败就让整个队列停下来。应当把失败项单独标记等主流程结束后再统一处理失败项并记录失败原因。6. 安全边界、隐私保护与合规使用讨论到这里必须单独强调安全与合规。让 AI Agent 以系统级权限操作应用本身就是一把双刃剑。第一最小权限原则是底线。Agent 申请操作权限时应当只申请完成任务所必需的最小子集。比如只是提取文档摘要就不需要申请发送邮件权限。系统实现方应当在规范层面支持权限细粒度拆分并在用户确认页面里用通俗语言解释每个权限的用途而不是甩出一长串技术术语。第二用户授权必须显式、可撤回。任何 Agent 都不能在用户不知情的情况下长期持有操作某个应用的权力。授权记录要有过期时间用户可以在系统设置里查看当前所有 Agent 的授权列表并一键撤销。撤销动作必须立刻失效所有相关授权记录并且让正在执行的调用返回 permission_denied。第三敏感操作必须有二次确认。发送邮件、删除文件、转账、发布内容这类不可逆操作无论权限是否已经预先授予都应在执行前要求用户确认。系统服务应该把这类操作标记为 high_riskAgent 侧也应该在发起这类调用前给用户提示。第四数据处理和隐私保护。Archer OS 这类系统级 Agent 机制天然会让系统服务收到大量应用操作日志。这些日志可能包含文档路径、邮件内容、聊天记录等敏感信息。实现方需要设计日志脱敏、访问控制、存储加密和保留期限策略。如果操作的是企业内部系统还要遵守数据本地化和合规审计要求。第五涉及人脸、声音、版权素材的操作边界。如果 Agent 操作的是生成或编辑图片、音频、视频的应用并在其中使用了他人肖像、声音或版权素材必须确保已经获得合法授权。系统实现者应当在能力声明和 Agent 请求字段中预留来源信息便于事后审计。这个点在生成式 AI 功能越来越普及的当下尤其重要。7. 性能与资源观察虽然 spec 本身不消耗 GPU 资源但只要实现成系统服务性能和资源占用就是必须回答的问题。权限校验开销。系统授权服务每收到一个 Agent 调用都要查询授权记录、校验有效期、检查能力白名单。如果授权数据用数据库存储查询需要控制在毫秒级如果授权数据是高频访问的可以在服务进程内用缓存保存活跃授权记录权限被撤销时通过事件实时失效缓存。日志写入开销。可审计性是这套体系的卖点但完整审计日志的写入可能在高峰期拖慢执行链路。更稳妥的做法是采用异步日志队列请求先返回日志异步落盘避免把日志写入设计成同步阻塞点。同时要监控日志队列积压情况积压过多时要及时扩容或者降级采样。批量任务会对系统服务造成请求洪峰。50 个文档批量处理如果每个文档都拆成独立权限调用就会产生大量请求。建议对同一 Agent、同一应用、同一批次的多次执行共用一条权限记录减少权限查询次数。这个设计和伪代码里的 permission_id 复用逻辑是一致的。应用侧性能影响。应用能力桥接层不要在主线程里执行重操作尤其是文档解析、文本抽取这类 IO 密集操作。如果 Agent 调用的能力需要较长执行时间应该通过异步任务接口处理让系统服务先返回一个“已受理”状态再通过回调或轮询获取最终结果。显存和 GPU 方面Archer OS 规范不依赖特定推理硬件。真正占用显存的是 Agent 使用的语言模型、视觉模型、OCR 组件这部分应当与操作应用的系统服务分离部署。操作通道和模型推理通道互相独立既能隔离故障也方便单独扩容。对于只需要跑 Agent 的开发机CPU 上跑系统授权服务完全没有压力真正需要评估的是模型推理部分的资源需求。8. 常见问题与排查思路下面是这套体系比较容易出现的问题清单无论你是在实现自己的 Archer OS 原型还是在给 Agent 接入某个系统级授权服务都可以参考。问题现象可能原因排查方式解决方案Agent 发起调用被拒返回 permission_denied授权未申请、已过期或用户已撤销检查授权记录状态和 expire_time重新申请授权确认高风险操作需要用户确认应用没有出现在能力发现列表里应用未启动或未正确注册能力声明检查应用日志与系统服务注册表确保应用启动并重新注册 capability调用应用能力时应用无响应应用桥接层同步执行了重任务查看应用侧 CPU/IO 占用和日志把执行逻辑改为异步任务并设置超时批量任务跑到一半全部失败授权窗口过期或应用崩溃查看失败请求的错误码和时间点批量前申请更长时间授权实现断点续跑审计日志缺失异步日志队列未落盘或存储权限问题检查日志服务和磁盘空间修复日志队列增加磁盘告警Agent 重复执行同一操作请求重试机制没有幂等控制查看 request_id 是否复用每次执行使用唯一 request_id重试时复用原 ID高频调用导致超时权限校验和日志写入没有做缓存优化观察系统服务吞吐量和耗时增加授权缓存、异步日志、批量权限复用如果 Agent 在一次执行中返回了非预期结果优先检查能力 schema 参数是否匹配。很多问题并不是权限或者协议错误而是参数形状不对。系统服务在做请求转发前最好用 JSON Schema 对请求参数再做一次校验提前拦截无效请求而不是让应用在运行到一半时报错。9. 最佳实践与落地建议如果你决定基于这份 draft spec 做原型下面这些建议可以降低试错成本。先做最小闭环。第一版不需要做一个巨大完整的系统服务。只需要实现 Agent 层、一个假的应用能力声明、一个权限确认窗口跑通“申请权限—执行调用—撤销权限”的完整闭环。确认协议字段能被真实场景理解再往后加功能。统一定义能力 schema。应用的每一个 capability 都要有明确的输入输出 schema最好直接使用 JSON Schema 格式保存并做版本管理。Agent 和系统服务都从这份 schema 生成校验逻辑避免接口漂移。即使应用升级只要 schema 版本向前兼容Agent 就不需要改动。把授权与执行分开存储。授权记录、执行记录、结果回传三组数据分开设计分别设置保留策略。授权记录需要长期保留执行结果可以做短期缓存审计日志要防篡改。这样既便于查询也能控制存储成本。批量任务必须幂等。每个执行请求都要有全局唯一 request_id重试时不能重新生成。这样即使网络抖动导致重复请求目标应用也可以根据 request_id 去重。这个细节在批量处理中特别重要。高风险操作单独配置。系统默认应该为 send_email、delete_file、post_message 这类能力打上 high_risk 标签即使用户已经提前授权执行前也要二次确认。这套默认策略可以降低误操作风险也方便用户理解系统在保护什么。多 Agent 场景要引入信任分级。本地助手、企业内部自动化、第三方插件不应共享同一套权限策略。信任等级越低的 Agent默认授权越少高风险操作的二次确认越严格。这个分级应该体现在授权模型里而不是靠 Agent 自己声明。注重合规。涉及人脸、声音、版权素材的操作在 Agent 请求中带上来源信息涉及企业敏感数据的操作日志要脱敏并限制访问范围。发布任何基于此类规范的自动化能力都要先做安全评审和授权流程确认。10. 总结与下一步Archer OS 这份 draft spec 最有价值的点是它把 AI Agent 操作应用的问题从一个“算法问题”重新定义成了“系统权限问题”。过去大家讨论 Agent 操作 App焦点往往是把截图识别得更准、点击得更稳而 Archer OS 把焦点转移到另一个维度Agent 的操作行为本身应该被操作系统当作一类需要授权、审计和撤销的资源来管理。从这份草案往前走最值得推动的工作有三件事。第一是协议标准化。能力声明字段、权限模型、错误码、审计日志格式这些都应当尽早统一否则不同实现之间无法互通Agent 也不可能跨平台迁移。第二是参考实现。一份规范的生命力在于有可运行的开源实现能让大家跑起来、用起来、发现问题而不是停留在文档里。第三是应用生态接入。只有真正有应用愿意暴露自己的能力声明这套体系的价值才能体现出来。如果你正在做 AI Agent 相关的基础设施建议把 Archer OS 的权限模型拿来做一次对照分析你的 Agent 现在是不是还在用无授权、无审计的方式操作应用如果是说明这是一个值得调整的工程窗口。建议先把最小权限模型跑通再逐步增加能力发现、批量任务和审计能力。这套思路即使不用 Archer OS 的实现也能直接帮助改进现有 Agent 系统的安全性和可维护性。