今天要聊一个偏向系统层面的 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 OS：AI Agent 操作应用的权限难题
现在的 AI Agent 操作应用，大致有四类做法。第一类是视觉模拟，截取屏幕，用 OCR 或视觉模型识别位置，再控制鼠标键盘点击输入。这种方式实现成本低，但看不清后台状态，也容易误操作。第二类是辅助功能 API，比如 Windows UI Automation、macOS Accessibility，可以读到界面树，定位按钮，然后模拟点击。这种方式比纯视觉稳定，但需要应用配合，权限范围也很大。第三类是应用主动暴露接口，比如插件、命令行、SDK，Agent 直接调用。这种方式最高效，但接口一旦开放，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": ["user@example.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 生态里，MCP（Model 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", encoding="utf-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", encoding="utf-8") as f: f.write(json.dumps(record, ensure_ascii=False) + "\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
