当你以为 AI Agent 的下一步只是更聪明的模型、更长的上下文、更复杂的工具调用时真正难住工程团队的其实是另一个问题Agent 要操作你电脑上的其他软件它的“权限身份”从哪来最近引起我注意的这份规范草案Archer OS直接把矛头指向了这个痛点。它提了一个很锋利的判断AI Agent 不应该继续嵌套在某个应用内部靠模拟鼠标键盘去“伪装成人”而是应该拥有一个操作系统级别的授权身份在 OS authority 的约束下像操作系统认可的一个“特殊用户”那样去操控其他应用程序。这个方向值得认真看因为它正在改变 AI Agent 工程的权限模型、交互方式和安全边界。如果你正在做 AI 自动化、Agent 工具链、跨应用工作流或者只是在思考“AI 能帮我操作电脑”这件事该怎么安全落地这篇文章会帮你把这套思路拆开讲清楚。本文会从三个角度展开先讲清楚 Archer OS 这类规范解决了什么真实问题再谈 OS authority 作为权限模型的关键设计最后给出一套可运行的概念验证流程和工程排错建议。1. 这篇文章真正要解决的问题先说结论AI Agent 操作应用的难点从来不是“模型不会用工具”而是“系统不知道该不该相信它”。如果你做过 RPARobotic Process Automation机器人流程自动化一定体会过那种痛苦。传统 RPA 脚本要操作一个软件最常见的手段是坐标定位、图像识别、控件树抓取。这看起来能用实际上非常脆弱屏幕分辨率一变脚本就崩软件改个版本控件路径就失效遇到验证码和权限弹窗更是直接卡死。AI Agent 出现以后很多人觉得可以靠大模型的视觉和推理能力解决这个问题。模型确实更智能了但自动化链条里的一个核心问题反而暴露得更明显Agent 以什么身份去操作应用过去的答案是“没有身份”。Agent 在应用内部跑或者模拟用户输入本质上是一种“偷渡式”的自动化。今天的答案是应该让 Agent 像操作系统里面的一个独立主体一样拥有自己的授权范围。这就是 OS authority 的意义。Archer OS 这份草案的核心主张就是这个思路。它想定义一个标准AI Agent 不再是被某一个应用“包养”的插件而是操作系统层面被识别和授权的执行体。它可以请求权限可以被审计可以被回收。如果你在看这篇博客时正好处于下面任一场景这篇文章就是为你写的你在设计一个 AI Agent 产品需要操作本地应用比如自动整理文件、自动打开浏览器查资料、自动操作办公软件。你在做企业内部自动化平台担心 Agent 权限过大无法追踪“它到底干了什么”。你在研究 AI Agent 的架构想理解“系统级权限模型”和“应用内工具调用”的本质区别。这篇文章不会给你一个已经成熟的商业产品清单因为按规范草案的定位它更接近协议和架构层面的设计提案。但我会把协议的核心思想、权限模型和工程落地方案展开让你读完以后能自己动手做一个最小版本。2. 基础概念OS authority 与 AI Agent 之间的关系2.1 什么叫做“OS authority”先拆开看。OS authority 可以翻译为“操作系统权威”或“操作系统授权”但我觉得更准确的理解是操作系统作为信任根Root of Trust给 AI Agent 签发一个身份和一组权限。传统操作系统的权限模型是这样的用户登录以后操作系统验证用户身份然后基于用户的权限允许用户启动应用。应用再基于自己的权限去访问文件、网络、硬件设备。AI Agent 进入这个模型以后产生了一个新的实体它既不是用户也不是普通应用而是一个拥有自己身份的执行体。它需要被操作系统识别、分配权限、记录行为。这个设计有几个直接好处权限可被分离。Agent 不需要继承用户的所有权限它可以只有“打开浏览器并读取网页”的权限而没有“删除下载目录”的权限。操作可被审计。Agent 的每一个系统调用、文件访问、应用启动都在操作系统的日志体系里出了问题可追溯。权限可被撤销。当 Agent 的任务结束或者行为异常操作系统可以立即回收它的权限。这就像办公楼的门禁系统。传统模式是员工进入大楼后可以在允许的区域内自由活动。而 Agent 更像是你给一个外包人员发了一张临时访客卡他只能去指定楼层、指定会议室而且所有刷卡记录都被后台留存。2.2 Agent、应用与操作系统的三角关系在“应用内自动化”时代Agent 和应用是嵌套关系。Agent 运行在应用提供的接口里它能不能操作应用完全看应用愿不愿意开放接口。比如浏览器插件能控制浏览器是因为浏览器提供了插件 API。如果某个软件不提供 APIAgent 就只能去模拟鼠标键盘也就是所谓的“外挂式自动化”。Archer OS 的草案把这种关系改成了“三角关系”操作系统是授权方和仲裁方。Agent 是被授权方它向系统声明自己想做什么。应用是被操作方它按照操作系统的规则决定是否接受 Agent 的指令。这个改变的价值在于它把“能不能操作”这个问题的裁判权从应用手里夺回了一部分到操作系统手里。应用即使不主动提供插件 API也可以通过系统级接口被操作。当然这也会带来兼容性问题。不同操作系统的权限机制不同应用是否配合系统的接口约束也是一个现实问题。但从架构层面看这个方向是清晰的。2.3 与现有工具调用方式的对比对比维度应用内工具调用模拟输入自动化OS authority 模式Agent 身份应用插件身份无身份或伪装成用户独立系统身份权限控制应用自己定义基本没有控制操作系统级控制可审计性应用内日志通常不可审计系统级全量审计稳定性依赖应用 API脆弱界面变化即失效稳定系统级接口安全风险较低但受限高无法限定能力边界可通过权限模型约束实施难度低低但维护成本高高需要系统支持从这张表能看出来Archer OS 这一套模式并不是为了让 Agent 更容易地操纵一切而是为了让“让 Agent 操纵一切”这件事情变得可控。它的核心价值是控制而不是自动化。3. Archer OS 规范的核心架构设想虽然材料里没有给出完整的 API 文档但从标题和描述可以推断一份以 agent operating apps under OS authority 为目标的规范至少需要包含下面几层设计。3.1 意图层Agent 表达“我想做什么”规范需要定义一种标准格式让 Agent 把自己要执行的操作表达成机器可读的意图Intent。意图要足够具体不能是一句自然语言“帮我把文件整理了”而应该是结构化描述目标应用、操作类型、操作对象、预期结果。举个例子{ intent_id: intent-001, target_app: com.yourcompany.filemanager, action: move_files, parameters: { source_dir: ~/Downloads/*.pdf, target_dir: ~/Documents/PDFs }, constraints: { dry_run: false, require_confirmation: true } }这个意图表达了几件事我想操作文件管理器应用把下载目录里的 PDF 文件移动到 Documents/PDFs。需要用户确认。意图层的作用是把 Agent 的“想法”从大模型的理解中剥离出来变成系统可以校验的声明。3.2 策略层操作系统决定“能不能做”有了意图之后系统策略引擎要做检查。检查内容包括这个 Agent 有没有权限操作目标应用。这个操作是否在允许的范围内比如源目录和目标目录是否在授权范围内。这个操作是否需要用户确认。是否满足当前系统的安全策略比如不能在后台静默执行高风险操作。这份策略声明可以用类似下面的配置来表达{ agent: { id: agent-file-bot, display_name: 文件整理助手 }, permissions: [ { resource: app://com.yourcompany.filemanager, actions: [move_files, rename_files, list_directory] }, { resource: file://~/Downloads, access: read }, { resource: file://~/Documents, access: write } ], security_policy: { user_confirmation_required: true, max_operations_per_minute: 30, auto_revoke_after_task: true } }如果策略检查不通过系统直接拒绝执行并且把拒绝原因写入审计日志。Agent 需要修正意图或者申请更高权限。3.3 执行层操作系统负责“把它做出来”策略通过以后执行层开始工作。执行层由操作系统提供的基础能力组成启动应用、注入指令、读取界面状态、捕获输出、关闭应用。这一层应该尽量复用系统已有的自动化接口而不是去模拟鼠标键盘。一个理想的执行过程是这样的系统启动目标应用以非交互模式运行或者在一个独立的桌面会话中运行。系统根据意图通过辅助功能接口Accessibility API或者应用提供的系统级服务接口向应用下达操作指令。系统等待操作完成并读取执行结果。系统把结果返回给 AgentAgent 决定是继续下一步还是结束任务。3.4 审计层每件事都被记录OS authority 模式最重要的特征是审计。系统需要记录Agent 发起的所有意图。策略引擎的每一次决策。每一次实际执行的操作。用户是否确认。最终的执行结果。审计日志的意义不只是出了问题以后追责它还提供了 Agent 调试的依据。当 Agent 的行为不符合预期时通过审计日志可以回放整个决策和执行过程找出是模型判断错误、策略配置错误还是执行层接口出问题。4. 环境准备与概念验证前置条件下面我们开始动手做一个概念验证。这部分不是 Archer OS 官方 SDK 的演示因为该草案目前还没有公开的稳定实现。这里的方法是基于它的核心思路用工程方式来验证“OS authority 模式”是否可行。在开始之前先把环境梳理清楚。需要说明的是下面的版本号只是一个通用建议具体以你本机的实际环境为准本文更核心的是演示整体思路。4.1 基础环境清单操作系统Windows 10/11、macOS 12 或主流 Linux 发行版均可。从权限模型的完整度看macOS 和 Windows 可参考性更强因为它们有比较成熟的辅助功能权限体系。Python 版本3.9 或以上。本文的示例以 Python 为主。开发工具VS Code或者你习惯的任何 Python IDE。依赖库pyautogui用于演示传统的界面操作、PyYAML 或 json用于读取权限配置文件、日志模块使用标准库 logging。4.2 安装 Python 依赖建议新建一个虚拟环境避免污染全局环境。python -m venv archer_env source archer_env/bin/activate # Windows 下使用 archer_env\Scripts\activate然后安装依赖库pip install pyautogui pyyaml这里要明确一点pyautogui 只是用来做概念验证的它本质上是“模拟人类操作”。真正的 OS authority 实现应该使用操作系统原生的辅助功能接口比如 Windows 的 UI Automation、macOS 的 Accessibility API。但作为验证思路的最小原型pyautogui 足够了。4.3 初始化项目结构archer-demo/ ├── agent_runtime.py # Agent 运行时 ├── policy_engine.py # 策略引擎 ├── executor.py # 执行器 ├── audit_logger.py # 审计日志 ├── intent.json # 意图声明 ├── policy.json # 权限配置 └── demo_task.py # 演示入口这个结构对应了前面讲的四层设计意图、策略、执行、审计。每一层都是一个独立模块方便后续替换成更真实的实现。5. 完整示例OS authority 模式的最小实现现在我们开始写代码。这个最小实现会模拟一个场景一个名为 file-bot 的 Agent想要把桌面上的截图文件归档到指定目录。用户事先给 Agent 授权了桌面读取权限和归档目录写入权限但禁止它读取其他目录。5.1 策略引擎检查 Agent 是否有权限执行首先实现策略引擎它读取 policy.json根据 Agent 的意图决定允许还是拒绝。# policy_engine.py import json import logging logging.basicConfig(levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s) logger logging.getLogger(policy_engine) class PolicyEngine: def __init__(self, policy_path: str): with open(policy_path, r, encodingutf-8) as f: self.policy json.load(f) def check_intent(self, intent: dict) - tuple[bool, str]: target_app intent.get(target_app, ) action intent.get(action, ) params intent.get(parameters, {}) source_dir params.get(source_dir, ) target_dir params.get(target_dir, ) # 1. 检查 Agent 是否有目标应用的权限 permitted_apps [p[resource] for p in self.policy[permissions] if p[resource].startswith(app://)] if target_app not in permitted_apps: return False, fAgent 没有目标应用 {target_app} 的操作权限 # 2. 检查 action 是否允许 for perm in self.policy[permissions]: if perm[resource] fapp://{target_app}: if action not in perm[actions]: return False, fAction {action} 不在允许列表中 # 3. 检查文件路径权限 # 这里做了一个简单的路径前缀匹配真实系统中需要更严格的路径归一化 read_ok any( p.get(access) read and source_dir.startswith(p[resource].replace(file://, )) for p in self.policy[permissions] if p[resource].startswith(file://) ) write_ok any( p.get(access) write and target_dir.startswith(p[resource].replace(file://, )) for p in self.policy[permissions] if p[resource].startswith(file://) ) if not read_ok: return False, f源目录 {source_dir} 不在读取授权范围内 if not write_ok: return False, f目标目录 {target_dir} 不在写入授权范围内 return True, ok这段代码是策略检查的骨架。第 1 步检查 Agent 能否操作对应应用第 2 步检查具体操作类型是否允许第 3 步检查文件系统路径是否在授权范围内。路径检查这里用的是前缀匹配工程上这种匹配方式不够安全需要做路径归一化防止~/Documents/../Downloads绕过检查。5.2 审计日志记录关键动作审计日志要记录每一次策略决策和执行结果。# audit_logger.py import json import time from pathlib import Path class AuditLogger: def __init__(self, log_path: str audit.log): self.log_path Path(log_path) def log(self, event_type: str, data: dict): record { timestamp: time.strftime(%Y-%m-%d %H:%M:%S, time.localtime()), event_type: event_type, data: data, } with open(self.log_path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n)这个审计日志很简单但形式和真实系统是一致的时间戳、事件类型、事件数据。生产环境里审计日志最好写到独立的日志系统或者至少做日志轮转避免单文件无限增长。5.3 执行器真正执行文件操作下面实现执行器。这一步要完成两件事先做一次 dry-run试运行列出将要发生的操作然后在实际执行前确认文件确实存在。# executor.py import shutil from pathlib import Path import logging logger logging.getLogger(executor) class Executor: def __init__(self, audit_logger): self.audit_logger audit_logger def run(self, intent: dict, dry_run: bool False): params intent[parameters] source_dir Path(params[source_dir]).expanduser() target_dir Path(params[target_dir]).expanduser() source_pattern params.get(source_pattern, *.png) if not source_dir.exists(): raise FileNotFoundError(f源目录不存在: {source_dir}) target_dir.mkdir(parentsTrue, exist_okTrue) files_to_move list(source_dir.glob(source_pattern)) logger.info(f找到 {len(files_to_move)} 个符合条件的文件) if dry_run: self.audit_logger.log(dry_run, { intent_id: intent.get(intent_id), files: [str(f) for f in files_to_move], }) print(Dry run 模式以下文件将被移动) for f in files_to_move: print(f {f.name} - {target_dir / f.name}) return for f in files_to_move: dest target_dir / f.name shutil.move(str(f), str(dest)) logger.info(f移动文件: {f.name} - {dest}) self.audit_logger.log(file_moved, { source: str(f), target: str(dest), })这里引入了一个 dry_run 的概念。它的价值在于在真实执行文件操作之前先让 Agent 和用户都能预判会有什么影响。对于任何有副作用的操作dry-run 都是非常值得保留的工程习惯。5.4 Agent 运行时串联整个流程Agent 运行时是总控模块。它接收一个自然语言任务描述解析成意图调用策略引擎检查再交给执行器执行。# agent_runtime.py import json import logging from policy_engine import PolicyEngine from audit_logger import AuditLogger from executor import Executor logging.basicConfig(levellogging.INFO, format%(asctime)s [%(levelname)s] %(message)s) logger logging.getLogger(agent_runtime) class AgentRuntime: def __init__(self, policy_path: str): self.policy_engine PolicyEngine(policy_path) self.audit_logger AuditLogger() self.executor Executor(self.audit_logger) def execute_task(self, intent_path: str, dry_run: bool False): with open(intent_path, r, encodingutf-8) as f: intent json.load(f) logger.info(f收到意图: {intent.get(intent_id)}) self.audit_logger.log(intent_received, intent) allowed, reason self.policy_engine.check_intent(intent) if not allowed: logger.error(f策略检查未通过: {reason}) self.audit_logger.log(intent_denied, {reason: reason}) raise PermissionError(reason) logger.info(策略检查通过开始执行) self.executor.run(intent, dry_rundry_run) self.audit_logger.log(task_completed, {intent_id: intent.get(intent_id)}) logger.info(任务完成)在这个运行时里策略检查是最关键的一道门。如果策略不允许直接拒绝不会进入执行阶段。审计日志会在每个关键节点写一条记录这样即使后续出了问题也可以回放整个流程。5.5 策略配置和意图声明现在把策略配置写出来。这个配置定义了 Agent 的身份、权限范围和安全策略。{ agent: { id: file-bot, display_name: 文件归档助手 }, permissions: [ { resource: app://com.example.filemanager, actions: [move_files, list_directory] }, { resource: file://~/Desktop, access: read }, { resource: file://~/Documents/Archive, access: write } ], security_policy: { user_confirmation_required: true, auto_revoke_after_task: true } }意图声明文件{ intent_id: intent-2025-001, target_app: com.example.filemanager, action: move_files, parameters: { source_dir: ~/Desktop, target_dir: ~/Documents/Archive, source_pattern: *.png }, constraints: { dry_run: false } }注意到这里的策略配置给 Agent 的写入权限只限于~/Documents/Archive也就是说即使 Agent 试图把文件移动到其他目录策略引擎会拒绝。这正是 OS authority 模式的核心价值Agent 能做一件事是因为它在系统层被授权而不是因为它足够聪明。6. 运行结果与效果验证运行这个最小系统验证两条路径合法操作和非法操作。6.1 合法操作验证在 Desktop 目录下放几个测试用的 PNG 文件然后运行python demo_task.py --intent intent.json --dry-run预期输出2025-06-01 10:30:00 [INFO] 收到意图: intent-2025-001 2025-06-01 10:30:00 [INFO] 策略检查通过开始执行 2025-06-01 10:30:00 [INFO] 找到 3 个符合条件的文件 Dry run 模式以下文件将被移动 screenshot-001.png - /Users/you/Documents/Archive/screenshot-001.png screenshot-002.png - /Users/you/Documents/Archive/screenshot-002.png screencap-001.png - /Users/you/Documents/Archive/screencap-001.png 2025-06-01 10:30:00 [INFO] 任务完成去掉--dry-run参数真正执行移动操作再查看审计日志cat audit.log你应该能看到多条记录包括intent_received、dry_run如果执行过、file_moved、task_completed。这验证了“操作可审计”这个核心特性。6.2 非法操作验证现在修改 intent.json把 target_dir 改成~/Documents/Other这个目录不在授权范围内。再次运行python demo_task.py --intent intent.json预期输出2025-06-01 10:31:00 [INFO] 收到意图: intent-2025-001 2025-06-01 10:31:00 [ERROR] 策略检查未通过: 目标目录 /Users/you/Documents/Other 不在写入授权范围内 PermissionError: 目标目录 /Users/you/Documents/Other 不在写入授权范围内这是一个非常关键的验证Agent 的权限被系统成功约束住了。它不是“做不到”而是“不允许做”而且不允许的原因是系统策略不是模型理解。6.3 判断验证成功的标准合法的操作能正常执行文件移动成功审计日志有完整记录。非法的操作被策略引擎拦截文件没有被移动审计日志记录了拒绝原因。两次验证中策略引擎都先于执行器运行说明“先检查后执行”的流程是有效的。如果验证失败第一步应该查看 audit.log 和终端日志确认是策略配置问题、路径检查问题还是文件系统权限问题。7. 常见问题与排查方法在实际动手过程中你可能会遇到下面这些问题这里给出排查思路。问题现象可能原因排查方式解决方案策略检查总是拒绝路径前缀匹配过严或过松打开审计日志检查被拒绝的路径是否真的在授权范围改进路径归一化将相对路径转为绝对路径再比较文件移动报错 Permission denied操作系统文件系统权限不足检查目标目录的写权限排查是否存在同名文件调整目录权限或引入冲突处理策略如重命名副本--dry-run与实际执行结果不一致dry-run 和实际执行之间文件有变化在 dry-run 与执行之间增加文件状态快照校验在实际执行时再次列出文件列表对比两次结果审计日志文件增长过快每次操作都追加一条 JSON缺少日志轮转查看日志文件大小引入基于大小的日志轮转或日志清理策略Agent 绕过策略直接操作文件代码中直接调用了 shutil.move跳过了运行时检查检查代码调用链确认所有执行入口都经过策略引擎统一执行入口禁止直接调用底层文件操作 APIpyautogui 无法定位窗口应用窗口没有激活或显示器分辨率变化打印窗口标题列表确认窗口状态增加窗口查找和激活逻辑或改用系统辅助功能接口其中最值得强调的坑是“绕过策略引擎”。在一个小项目中你可能会觉得在 Executor 里直接调用shutil.move很方便于是忽略了运行时检查。但随着代码规模扩大这些绕过点会变成安全漏洞。工程上应该规定所有副作用操作必须经过一个统一的执行入口这个入口内嵌策略检查。8. 最佳实践与工程建议8.1 权限模型要遵循最小权限原则最小权限原则的意思是Agent 只需要拥有完成任务所必需的最小权限不要多给。比如“移动桌面图片”这个任务Agent 需要的权限是读取桌面目录。写入归档目录。它完全不需要读取整个用户目录。访问网络。启动其他应用。在设计权限配置时优先从“拒绝一切”开始然后逐项添加必要权限。不要反过来。8.2 高副作用操作必须引入确认机制文件移动、数据删除、发送消息、执行支付这些操作都属于高副作用操作。对于它们工程上应该强制引入用户确认环节。确认机制可以分级完全不需要确认读取文件列表、查询系统状态。需要一次确认移动文件到指定目录。需要二次确认删除文件、批量操作、跨目录复制。Archer OS 这类规范所强调的 OS authority并不是要取消用户确认而是要让 Agent 在获得系统许可的前提下工作用户确认作为最后的兜底。8.3 审计日志要尽早设计而不是事后补充很多团队一开始忽略审计等到 Agent 在生产环境出了事故才想起来要查日志这时候已经晚了。建议从第一天就记录Agent 收到的每一个意图。策略引擎的每一次决策包括拒绝。每一次实际执行的操作。执行结果的成败。用户是否确认。8.4 操作要支持 dry-run 和灰度执行对文件类操作先 dry-run 再执行对批量操作先执行少量样本再执行全量。这个习惯可以避免很多灾难性的错误。即使你的 Agent 调用了大模型模型判断是概率性的但执行体系必须是确定性优先的。8.5 路径安全问题不能只依赖简单匹配前缀匹配在真实环境中是不够安全的。比如~/Documents/Archive前缀看起来只能访问归档目录但如果传入路径是~/Documents/Archive/../../Other前缀匹配就可能被绕过。真实系统中需要对路径做归一化处理使用系统提供的 canonical path API然后再做授权判断。8.6 AI Agent 与 OS authority 的未来关系从趋势看越来越多的 Agent 框架正在把“操作系统级操作”纳入能力范围。未来可能会出现更多系统级的 Agent 权限标准和 API。作为开发者现在就开始理解权限模型、策略引擎和审计机制比等技术标准成熟后再学要有效得多。因为这些底层的安全问题在任何一套标准下都是必须解决的。9. 总结与后续学习方向Archer OS 的核心贡献是在概念层面把 AI Agent 的身份从“应用内插件”提升到了“操作系统授权主体”。它要求 Agent 的每一个操作都通过意图声明、策略检查和审计记录这条链路而不是依赖模型自由发挥或者模拟鼠标键盘。本文做了三件事讲清了 OS authority 与 Agent 的关系画出了规范应有的四层架构——意图层、策略层、执行层、审计层用一套可运行的最小代码验证了“策略先行”的工程模式。如果你接下来要深入学习建议按这个顺序推进先熟悉本地系统的辅助功能接口。Windows 看 UI AutomationmacOS 看 Accessibility API这比 pyautogui 更接近真实方案。然后研究现有 Agent 框架的权限模型比如一些主流框架里 tool permission 的设计理解它们与系统级权限的差距。最后如果你的工作需要可以考虑参与相关规范的讨论或者在自己的平台上实现一版简单的策略引擎。建议把这篇文章收藏起来把它当作一份“系统级 AI Agent 权限设计”的入门地图。等到你开始做真正的 Agent 产品时再回来看一遍会有不一样的收获。