今天要聊一个偏向系统层面的 AI Agent 架构草案Archer OS。标题写得很直白——draft spec for AI agents operating apps under OS authority意思是“让 AI 智能体在操作系统授权下操作应用的规范草案”。它不是大模型权重不是 RPA 工具也不是可以直接拉下来的整合包而是一套解决“AI Agent 怎么安全、可控地操作各种应用”的协议设计思路。如果你之前做过 UI 自动化、写过 RPA 脚本或者正在给 Agent 接入工具调用这篇文章值得仔细看。最值得关注的地方是把权限控制从应用层、Agent 层提升到操作系统层。传统方案里Agent 想操作应用要么直接模拟鼠标键盘要么通过辅助功能 API 抓取界面元素要么让应用自己暴露接口。这三种方式都缺少一个统一的“授权边界”Agent 能做什么、不能做什么、每一步操作是否被记录往往取决于工具本身的实现而不是系统级规则。Archer OS 的设想是让操作系统成为 Agent 与应用之间的唯一裁判所有操作都要经过系统授权、执行和审计。这个思路如果落地自动化流程的失控风险会明显降低。本文会拆解这份草案可能包含的权限模型、操作原语、应用适配层、安全审计机制并给出一套从协议定义到模拟验证的落地方向。由于 Archer OS 目前处于草案阶段公开信息有限文中的协议示例、配置结构属于基于系统设计常识给出的“可参考草案”不是已验证的真实实现。为了可读性我会尽量用技术语言把抽象概念写具体。1. 核心能力速览能力项说明项目类型AI Agent 操作系统层规范草案draft spec核心目标让 AI 智能体在操作系统授权下安全操作应用关键概念Agent 身份、权限策略、操作原语、审计日志、应用适配层当前状态草案阶段无完整公开实现是否可部署未明确需等待后续实现或参考设计支持平台未明确设计上应面向桌面/移动操作系统与 RPA 的关系可理解为“系统级 RPA 权限治理框架”与 MCP 的关系MCP 负责 Agent 访问工具/数据的协议Archer OS 侧重应用控制授权二者可互补核心卖点系统级授权、最小权限、操作审计、跨应用统一协议适合读者系统架构师、客户端开发、AI Agent 框架作者、自动化工程师从结构上看Archer OS 要解决的并不是“模型能不能生成写代码的指令”而是“指令对应的操作能不能被执行”。模型负责决策OS 负责裁决。裁决的依据不是模型的意图而是明确的策略文件和应用能力描述。这种分层方式比在 Agent 内部堆规则更加可靠因为 OS 层是系统资源的天然所有者拥有不可绕过的执行边界。2. 为什么需要 Archer OSAI Agent 操作应用的权限难题现在的 AI Agent 操作应用大致有四类做法。第一类是视觉模拟截取屏幕用 OCR 或视觉模型识别位置再控制鼠标键盘点击输入。这种方式实现成本低但看不清后台状态也容易误操作。第二类是辅助功能 API比如 Windows UI Automation、macOS Accessibility可以读到界面树定位按钮然后模拟点击。这种方式比纯视觉稳定但需要应用配合权限范围也很大。第三类是应用主动暴露接口比如插件、命令行、SDKAgent 直接调用。这种方式最高效但接口一旦开放Agent 可以做的事情就完全取决于接口设计缺少细粒度控制。第四类是 RPA 专用录制回放本质还是把操作序列固化再嵌套条件判断。问题是这些方式都建立在“Agent 已经获得足够权限”的前提下运行时没有真正的授权检查。更麻烦的是审计缺失。Agent 执行一个工作流可能点击了 20 个按钮、填写了 5 个表单、发起了一个请求。如果流程出错我们往往只能从界面结果倒推哪里出了问题。至于 Agent 是否访问了不该看的文件、是否在用户不知情的情况下提交了操作普通自动化工具给不出完整的操作日志。Archer OS 的动机就是把这些状态抽出来统一放到 OS 层控制。还有一个动态授权问题。用户希望 Agent 只在下达任务时临时获得权限任务结束后立刻回收。现有方案很难做到。要么授权后一直有效要么每次授权重新输入密码体验很差。OS 层可以设计“一次性授权”“短时授权”“应用级授权”等策略让授权具有生命周期。这才是一个真正可商用系统的样子。3. 适用场景与使用边界从草案定位看Archer OS 适合三类场景。第一类系统级个人助手。比如未来操作系统的 AI 助理想帮你整理文件、发送邮件、调整系统设置。这类场景需要对系统全局有控制能力但又要防止 Agent 越权。OS 授权模型能保证小到某个文件夹、大到系统设置每项操作都有明确的权限依据。第二类企业级工作流自动化。比如财务系统、CRM、内部 OA这些系统通常没有稳定的公共 API但界面繁杂。用 Archer OS 这类架构可以让 Agent 在 OS 层被授予“只能操作某几个业务应用”的权限并且每一步操作都有审计方便合规部门复盘。第三类跨应用协同任务。Agent 需要从 Excel 读取数据填入 Web 系统再从邮件系统发送报表。跨应用数据流容易出问题Archer OS 的统一授权和操作日志能帮助定位是哪个环节卡住。但也有不适用场景。如果只是一个简单的定时脚本不需要跨应用交互引入 OS 层权限框架会显得笨重。如果应用完全不支持系统级能力暴露Archer OS 也无法凭空控制它。如果在纯云端容器环境没有传统桌面 OS这套“OS 授权”就需要重新定义。使用边界方面必须强调Archer OS 作为权限治理规范不能代替模型判断能力。模型仍然可能给出错误的操作意图OS 层能做的只是阻止无权限的操作无法阻止有害但有权限的操作。所以在实际落地时仍然需要叠加行为检测和人工审批。涉及人脸、声音、隐私数据、支付等敏感操作必须提供二次确认机制并要求使用者确认拥有对应授权。这是技术底线也是产品能长期存在的前提。4. 草案核心设计Agent 身份与授权模型要设计一套“操作系统授权下的 Agent 操作应用”规范第一步是定义 Agent 的身份。操作系统需要知道“谁在请求操作”。这个身份不是模型名称也不是对话会话 ID而是一个由系统签发的 Agent 凭证。凭证里包含 Agent 名称、开发者、权限范围、有效期、签名信息。下面是一个参考用的 Agent Manifest 示例。它描述一个 Agent 实例希望获得哪些权限{ agent_id: assistant-alice-001, agent_name: Alice Office Assistant, developer: org.example, version: 1.0.0, public_key: ecdsa-p256-public-key-placeholder, requested_permissions: [ { resource: app:mail:*, operations: [read, compose, send], constraints: { max_per_day: 50, requires_user_confirmation: true } }, { resource: app:calendar:*, operations: [read, create], constraints: { time_window: [09:00, 18:00] } } ] }这个 Manifest 会在 Agent 启动时提交给 OS 权限服务。权限服务会检查 Agent 的签名比对系统策略然后生成一个受限令牌。Agent 在后续每一次操作请求中携带令牌OS 根据令牌中的权限范围决定是否放行。简单的授权检查流程如下1. Agent 向 OS 权限服务请求令牌。 2. 权限服务读取 Agent Manifest 和系统策略。 3. 系统策略通过则签发令牌并记录授权事件。 4. Agent 携带令牌调用应用操作接口。 5. OS 校验令牌权限如果不匹配则拒绝。 6. 每次操作写入审计日志。这里最核心的是权限策略与资源描述。资源描述可以用统一资源名来定义比如app:mail:*表示所有邮件应用file:project:*/read表示读取项目目录文件。操作符则包括read、write、create、delete、send、open、click、type等。策略文件本身也需要可管理。企业用户可以把策略放在安全管理平台个人用户可以在系统设置里批准或撤销授权。OS 层负责加载策略、缓存决策结果并且支持策略热更新。这比把权限写在 Agent 配置里安全得多因为 Agent 可能被篡改但 OS 的策略存储受到系统保护。5. 操作原语与指令集设计仅定义权限还不够OS 需要知道 Agent 请求的具体操作是什么。Archer OS 需要定义一套跨应用的操作原语类似 Android Intent 或 Windows UI Automation 里的控制模式。考虑到未来 AI Agent 的场景操作原语应当包含几层应用级操作、界面级操作、数据级操作。应用级操作包括launchApp、closeApp、switchWindow、getAppState。界面级操作包括findElement、click、inputText、scroll、selectOption。数据级操作包括readField、writeField、getClipboard、setClipboard。这些原语不是给 Agent 直接控制鼠标而是通过 OS 的统一接口去影响应用。一个请求示例{ request_id: req-20250417-001, agent_token: token-xxx, operation: click, target: { app_id: com.example.mail, window_title: Compose, element: { by: accessibility_id, value: send_button } }, timestamp: 2025-04-17T12:00:00Z }OS 收到这个请求后会先校验 token 是否允许对这个应用执行click操作然后查找目标元素执行点击最后返回操作结果。返回结果可以是简单的{success: true}也可以是结构化的状态描述比如截图、界面树变化摘要。为了让 Agent 更容易理解执行结果返回结果可以携带“当前界面状态描述”。但注意这个描述只是增强信息授权判断必须基于结构化权限不能由模型自由发挥。否则模型可能通过描述绕过权限控制比如读取本来无权限的字段内容。指令集设计还需要考虑批量操作。Agent 可能需要先读取某个列表然后对列表中每个元素执行操作。规范可以定义batch请求但每个子操作仍然需要独立授权。OS 可以在批处理级别做一次性审批也可以逐条审批这取决于安全级别。6. 应用适配层从 UI 自动化到系统级应用控制Archer OS 不可能直接理解每一个应用的内部实现。所以规范里需要有一个适配层让应用能够以统一的方式暴露操作能力。这个适配层有两种形态一种是 OS 内置桥接适用于系统自带应用和主流桌面框架另一种是应用侧 SDK应用开发者主动接入把内部功能映射成标准操作原语。在桥接模式下OS 可以直接调用应用的辅助功能接口把按钮、输入框、菜单映射为可操作元素。这个过程可以和传统 UI 自动化类似但区别在于控制权归 OS 而不是 Agent。Agent 提出的是语义化操作比如“发送邮件”“调整音量”OS 负责把语义操作转换成具体的界面操作。在应用侧 SDK 模式下应用可以暴露一个本地 JSON-RPC 接口接收 OS 转发的操作指令。这样比界面操控更稳定也不容易被界面变化影响。应用侧接口示例{ method: com.example.mail.sendEmail, params: { to: [userexample.com], subject: Hello, body: This is a test message. }, id: 1 }这个接口不直接对 Agent 开放而是由 OS 代理。OS 收到 Agent 的sendEmail操作请求后先检查 Agent 是否有app:mail:send权限再调用应用接口。应用接口可以设计成需要 OS 令牌才能调用其他进程无法直接使用从而避免安全隐患。适配层的存在也能让同一个 Agent 在不同操作系统间迁移。Windows、macOS、Linux 各自实现适配层但上层的 Agent 操作协议保持一致。这类似于浏览器成为 Web 应用的适配层Archer OS 希望成为桌面应用自动化的系统级适配层。7. 安全、审计与隔离机制系统级授权最大的价值是能实现完整审计。每一次操作请求无论成功失败都应当记录关键字段。审计日志的参考结构如下{ log_id: audit-20250417-001, agent_id: assistant-alice-001, request_id: req-20250417-001, operation: click, resource: app:mail:send, decision: allow, reason: policy_match, target_app: com.example.mail, sensitive_data: false, timestamp: 2025-04-17T12:00:00Z }审计日志不能只存在内存里需要异步落盘并支持加密存储。对于涉及隐私数据的操作日志中不应记录具体内容只记录操作类型和结果。比如发送邮件可以记录“发送了一封邮件”而不是邮件正文。这样既能回溯问题又能保护用户隐私。隔离机制方面Agent 不应直接持有一个系统的完整权限。OS 可以为每个 Agent 创建独立沙箱限制文件系统目录、网络端口、系统调用。Agent 之间的数据也要隔离避免恶意 Agent 读取其他 Agent 的上下文。操作应用时Agent 的进程与应用的进程可以保持隔离只通过 IPC 通信。动态撤销是另一个关键点。当用户停止任务或者系统检测到异常行为时OS 能立即吊销 Agent 的令牌。吊销后Agent 无法发起新的操作但正在执行的原子操作可以继续完成也可以强制中断这取决于操作类型。规范应当支持“原子操作不拆分跨应用操作可中断”的原则。8. 与现有 Agent 框架和 RPA 的关系当前 Agent 生态里MCPModel Context Protocol是一个重要协议它定义了模型如何通过工具调用外部能力。但 MCP 并不直接解决“应用操作授权”问题。MCP 的 tools 通常是开发者预先定义好的粒度往往较粗。Archer OS 的定位更像是一个“应用操作层的 MCP”它把每个具体界面操作都变成了一次需要授权的调用。与 RPA 相比RPA 是工作流固化Archer OS 是权限治理。好的架构应当是 RPA 工具和 AI Agent 都接入 Archer OS而不是被它取代。企业可以保留之前的 RPA 机器人但把它们的操作纳入 OS 审计。机器人同样需要身份、权限和日志只是实现方式不同。在实际落地上Archer OS 规范可以与 MCP 共生。MCP server 负责封装业务能力Archer OS Client 负责能力调用前的授权检查。Agent 先通过 MCP 发现工具再通过 Archer OS 申请权限最后执行操作。整个链路是模型生成指令 - MCP 变成工具调用 - Archer OS 做权限裁决 - 系统执行并审计。9. 实践路径如何从规范到落地如果 Archer OS 只有一份文档那它还不能直接使用。从草案到可验证实现至少需要三步。第一步定义最小可用协议。不要一开始就做所有原语只定义getAppList、getWindowState、clickElement、inputText、readText这五个基础操作加上一个简单权限策略格式跑通端到端链路。第二步做一个模拟器。不直接修改操作系统内核先在用户态模拟“OS 权限中心 应用适配层”。可以选一个开源桌面应用作为测试对象通过辅助功能 API 读取窗口元素然后实现一个本地 HTTP 服务对外提供操作接口。Agent 调用接口前服务先读取本地策略文件再执行界面操作并记录日志。这个模拟器能快速验证权限模型是否合理。一个极简的模拟授权检查伪代码如下import json import time import subprocess POLICY_FILE policy.json def load_policy(): with open(POLICY_FILE, r, encodingutf-8) as f: return json.load(f) def check_permission(policy, agent_id, operation, resource): for p in policy.get(agent_permissions, []): if p[agent_id] ! agent_id: continue if operation not in p[operations]: continue if resource_match(p.get(resources, []), resource): return True return False def resource_match(resource_list, resource): for pattern in resource_list: if resource.startswith(pattern.replace(*, )): return True return False def audit(record): with open(audit.log, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def execute_operation(agent_id, operation, resource, payload): policy load_policy() if not check_permission(policy, agent_id, operation, resource): audit({ time: time.time(), agent_id: agent_id, decision: deny, operation: operation, resource: resource }) return {error: permission_denied} # 实际执行界面操作这里用命令示例代替 subprocess.run([echo, payload.get(text, )]) audit({ time: time.time(), agent_id: agent_id, decision: allow, operation: operation, resource: resource }) return {success: True}第三步接入真实应用。模拟器跑通后选择一个有辅助功能接口的应用比如用开源文件管理器或浏览器实现真实的操作执行器。此时再验证权限拒绝是否生效、批量任务是否稳定、审计日志是否完整。这一阶段能暴露大量细节问题比如窗口状态变化、元素定位失败、权限缓存过期等。10. 挑战与风险Archer OS 这类系统级规范最难的是操作系统厂商是否愿意支持。微软、苹果都有自己的辅助功能框架Google 也有自己的自动化测试框架。要让它们统一遵循一份新的授权规范需要极强的生态推动力。如果只是社区级别草案只能先做用户态模拟器。此外引入系统级权限裁决会增加操作延迟。Agent 发起一次点击原本 10 毫秒能完成现在要先校验 token、查询策略、记录日志可能变成 50 毫秒。对于高频操作比如每分钟上百次的界面交互这个延迟会直接影响体验。优化方式包括策略缓存、批量审计、异步写日志。另一个风险是过度授权。如果 OS 为 Agent 的动态需求自动批准权限安全边界就形同虚设。但如果每次都弹窗询问用户会烦。平衡点在于分级授权低风险操作自动放行中风险操作通知用户高风险操作强制二次确认。这就需要一套稳定的风险评级模型而不是简单用操作类型判断。兼容性也是现实问题。不同操作系统的窗口管理、元素定位、权限模型差异很大。Archer OS 草案中的协议可以统一但每个平台的适配层实现差异会很大这需要大量工程投入。如果只做 Windows 平台可能更快出成果但适用范围会缩小。数据隐私方面系统级审计日志如果包含过多细节会成为新的隐私风险点。规范需要在设计之初就定义哪些字段被允许记录、哪些字段必须脱敏、日志如何存储和销毁。没有隐私设计这种系统反而可能变成一套高级监控工具这是需要警惕的。11. 常见问题与思考问题思考方向Archer OS 是一个可安装的操作系统吗从标题看更像一份规范草案不是完整操作系统。它能控制任意应用吗取决于应用是否有辅助功能接口或主动接入 SDK完全封闭应用很难控制。Agent 需要额外训练吗不需要模型只需要学会调用 Archer OS 的操作接口不需要理解底层系统权限。与现有 AutoGPT、LangChain 等框架兼容吗可以把操作接口封装成 tool 接入这些框架。普通开发者能参与吗可以先阅读草案实现一个模拟器或适配层验证自己的想法。这套规范安全吗安全取决于授权策略、审计、沙箱是否严格规范本身并不能保证安全。如果从工程师视角去看Archer OS 最大的贡献是“把 AI Agent 的控制面变成系统级问题”。它提醒我们Agent 的能力不只要靠模型推理还要靠基础设施赋权。否则Agent 越强大潜在破坏力也越大。只有像操作系统管理进程权限那样管理 Agent 操作自动化才能从“好玩”变成“可信”。12. 总结与下一步Archer OS 的草案目前没有给出可运行的代码但它勾勒了一个值得关注的方向AI Agent 应用操作授权应该由操作系统接管。最值得尝试的实验不是等官方实现而是自己写一个极简授权模拟器把文件读取、窗口点击、输入文本这些基础操作纳入权限检查。这样能直观感受到“操作前授权”和“操作后审计”到底意味着什么。最容易踩的坑是权限策略设计过细或过粗。过细会让 Agent 频繁申请权限过粗则形同虚设。建议先用 3 到 5 个权限规则跑通流程再逐步增加严格度。下一步可以关注 Arc