最近在调研 AI Agent 落地业务操作时遇到一个很现实的问题Agent 能理解任务、能生成步骤却难以安全、稳定、可控地操作系统里的应用。接入 API 的方式受限于应用是否开放接口UI 自动化的方式又非常脆弱更麻烦的是权限边界含糊不清——Agent 拿到什么权限、做了什么操作、出了问题如何回溯这些问题在现有方案里几乎没有统一答案。“Archer OS” 这个方向值得关注。它发布的 draft spec 核心命题就是让 AI Agents 在 OS authority操作系统权威约束下操作应用。这个视角把 AI Agent 从“应用层的临时脚本”提升到了“系统级协作服务”的高度。本文会完整拆解这份草案规范的设计思路、核心组件与实际操作流程并给出一个最小可运行的概念原型帮助理解这类架构。这篇文章适合正在做 AI Agent 平台、RPA 工具升级、系统自动化服务开发的工程师也适合想了解 Agent 安全边界和系统集成方案的技术负责人。读完你会掌握为什么 Agent 需要 OS 级权限、规范草案中的关键模块如何设计、一次授权操作的全链路长什么样以及在落地时最容易踩的坑。1. 为什么 AI Agent 需要 OS 级权限1.1 从“生成回答”到“操作系统”早期 AI 助手的核心能力是理解自然语言并生成文本答案应用边界只停留在对话框内部。但随着 Agent 能力增强用户期望它不只是“告诉你怎么做”而是“替你完成”。比如自动整理邮件并发送、跨应用拉取数据生成报表、在办公软件里批量处理文档。这些操作无法靠单纯的文本生成完成Agent 必须“伸手”去操作系统中的应用。于是一个关键问题出现了谁来定义 Agent 能做什么、不能做什么如果让 Agent 直接操作应用安全边界在哪里我们需要的不是又一个被应用绑定的脚本框架而是一个可以跨应用、跨窗口、可管控、可追溯的系统级操作机制。这正是 Archer OS draft spec 试图回答的问题。1.2 现有 Agent 操作应用的三种方式及其局限在 Archer OS 这类草案出现之前开发者要 Agent 操作应用通常只有三套思路。第一种是“API 集成”。应用开放 HTTP API 或 SDKAgent 调用接口完成操作。优点是稳定高效但缺点明显要求应用必须主动开放接口传统桌面应用、老旧系统、第三方商业软件根本不会有而且每个接口都需要独立对接Agent 的适配成本很高。第二种是“RPA/UI 自动化”。通过图像识别、坐标点击或控件抓取来模拟用户操作。这种方式不依赖 API但极其脆弱界面布局一变脚本就失效并且很难获得系统层面的权限控制。RPA 脚本拿到的是用户级权限一旦脚本出错可能造成不可预期的操作。第三种是“辅助功能接口”。部分操作系统提供无障碍接口如屏幕阅读器、辅助功能树等。Agent 可以读取界面控件树、模拟点击输入。这比坐标点击可靠但辅助功能接口本身并不是为自动化设计的权限校验、跨应用会话、审计能力都很弱。这三种方式有一个共同的问题Agent 直接面对的是“应用”而不是“操作系统”。缺少一个在系统层面统筹权限、会话、策略和审计的机制。1.3 理解 “OS Authority”“OS authority” 直译是“操作系统权威”。它不是说给 Agent 一个管理员账号也不是让 Agent 拥有 root 权限。它的含义应当更精确Agent 对应用的操作必须在操作系统的监视和授权之下进行由操作系统作为权威方来决定某个 Agent 是否有资格对某个应用执行某个动作。可以理解为 OS 扮演了“裁判”角色。应用和 Agent 是比赛的双方规则由 OS 制定。任何跨应用操作都先经过 OS 的权限校验、策略评估随后在审计系统里留下记录最后才被允许执行。对比项传统 API 方式RPA 方式OS Authority 方式权限来源应用自己管理用户账号权限系统级策略引擎跨应用统一不支持不支持支持审计能力依赖应用日志较弱系统级完整审计操作稳定性高低中高实现成本高需应用开放中中高这样设计的最大价值在于权限不是由每一个应用自己私下授权而是由操作系统集中管理。任何一个 Agent 的越权行为都可以在系统层面被拦截而不是等到应用被误操作后才被发现。2. Archer OS 草案规范的核心设计目标2.1 一份真正可落地的“操作规范”Archer OS 作为 draft spec首先要解决的是“标准化”问题。Agent 操作应用不能每次都走一套自定义协议。规范草案需要定义统一的操作语言、标准化的权限模型、可预测的执行流程。这份草案不是某一个公司的私有 SDK而是一个开放规范。第三方开发者可以根据规范实现自己的 Agent Runtime也可以基于规范开发客户端、策略引擎和审计服务。它的价值在于为整个生态提供一套“共同语言”。2.2 核心设计目标从当前公开的草案方向来看我觉得 Archer OS 至少承载了四个核心设计目标。第一统一动作抽象。Agent 操作应用无论用的是什么技术底层都应该被抽象为一组标准动作。比如打开窗口、点击按钮、填写输入框、读取列表内容、提交表单。这套动作语义是跨应用统一的Agent 不需要关心目标应用具体实现。第二系统级权限管控。所有操作动作必须经过策略引擎评估。策略引擎由系统层面配置支持按 Agent、按应用、按动作类型、按时间条件做细粒度控制。用户对 Agent 操作的授权记录可以被回溯而不是一笔糊涂账。第三会话与审计完整性。Agent 的每次操作都应归属到某个会话里。会话头记录了哪个 Agent、哪个用户、从什么时间开始每个动作都有序列号和结果状态。这个设计能保证问题发生后可以还原“当时到底发生了什么”。第四可恢复性。如果 Agent 执行到一半失败了应该能基于会话信息做补偿或回滚。至少也应该留下标记让用户知道哪些操作已执行、哪些未执行避免用户误以为任务没有发生而重复操作。2.3 与现有方案的区别Archer OS 与当前 RPA 工具的核心区别在于“谁在掌控”。RPA 工具是 Agent 进程自己去控制鼠标键盘本质上绕过了系统边界。Archer OS 则是把 Agent 变成“被操作系统管理的一等公民”Agent 要做任何操作先向系统申请由系统调度执行。这与 macOS 的辅助功能授权、Android 的无障碍服务有相似之处但 Archer OS 的野心更大它不只做“授权开关”还提出了统一动作层、策略引擎、会话审计这样的完整体系面向的是可编程、可治理的企业级自动化场景。3. 草案规范中的关键组件3.1 OS Agent Runtime 与 Agent 生命周期在 Archer OS 的设计里Agent 并不会直接接触应用进程而是由 OS Agent Runtime 统一托管。这个 Runtime 可以理解为一个常驻的系统服务负责三件事启动 Agent、管理 Agent 生命周期、代理 Agent 的所有操作请求。Agent 的生命周期分为创建、授权、运行、暂停、终止几个阶段。每个阶段都在系统里留下状态记录。这个设计的直接好处是用户随时可以查看当前系统有哪些 Agent 在活动它们被授予了哪些权限活动了多长时间。如果某个 Agent 长时间不活动Runtime 可以自动回收它的授权。相比传统方式里“授权一次永久有效”这种过期机制能显著减少 Agent 遗忘或休眠造成的安全风险。3.2 Application Action Layer 应用操作抽象层这是整个草案里最有价值的部分。它定义了一套标准动作协议让 Agent 通过统一动作来操作任何已适配的应用。简单来说一个动作至少需要包含四部分信息应用标识、动作类型、动作参数和期望结果。以“打开邮件并发送”任务为例{ app: com.example.mail, action: open, params: { target: compose_window }, expected: { result: window_opened } }发送邮件阶段{ app: com.example.mail, action: input, params: { field: recipient, value: userexample.com }, expected: { result: filled } }这套抽象接口的意义在于Agent 侧永远不需要知道目标应用的内部实现。应用侧只要实现一套适配器把标准动作映射到真实 UI 控件或内部 API 上即可。后续应用改版Agent 侧代码不用动只要适配器保持标准动作不变。3.3 Policy Engine 权限策略引擎权限策略是安全设计的核心。Archer OS 草案中策略引擎负责在动作执行前判断“这个 Agent 是否被允许对目标应用执行该动作”。一份概念性的策略配置如下路径为policies/example-policy.yamlpolicies: - agent: email-assistant resource: app: com.example.mail rules: - action: read:inbox require_user_approval: false max_frequency: 30 - action: send:mail require_user_approval: true rate_limit: 10 time_window: 09:00-18:00 - action: delete:mail require_user_approval: true irreversible: true这套配置说明了几层含义require_user_approval表示该动作是否需要在执行前弹出用户确认窗口。读收件箱这类低风险操作可以静默授权删除邮件这类高风险操作则必须用户确认。rate_limit限制单位时间内动作的最大次数防止 Agent 因异常循环导致海量操作。irreversible标记该操作不可逆系统会给予最高级别的拦截和提示。策略引擎的价值在于将“能不能做”从 Agent 代码里抽离出来变成系统级的配置决策。这样安全团队和运维人员可以在不修改 Agent 代码的前提下动态调整权限边界。3.4 Session 与审计体系审计是 Archer OS 规范中最不能妥协的模块。每条动作执行都必须生成一条审计记录格式类似{ session_id: 8f3a2c91-7b1e-4c6d-9a24-1c0f9e2a5d88, seq: 12, agent_id: email-assistant, user_id: user-10086, action: send:mail, target: { app: com.example.mail, window: compose_window, element: send_button }, policy_result: allow, user_approval: true, execution_result: success, timestamp: 2025-06-18T14:32:07.125Z }这套审计日志解决的是“信任问题”。当系统出现误操作时可以通过 session_id 把整个操作过程拉出来逐条还原。哪个 Agent、经过谁确认、在什么时间、执行了什么操作、结果是成功还是失败一目了然。4. 一次完整的授权操作流程4.1 从用户意图到操作系统动作为了更直观地理解整个链路我们把一次“让 Agent 帮我发送邮件”的完整流程拆成六个步骤。第一步用户向 Agent 提出请求。Agent 解析用户意图生成操作计划。 第二步Agent 将计划中的动作提交给 OS Agent Runtime请求执行。 第三步Runtime 将动作发送到 Policy Engine进行权限评估。 第四步如果动作被标记为需要用户确认则弹出系统级授权窗口。用户确认后策略结果附带 user_approvaltrue。 第五步Runtime 将动作转发给 Application Action Layer由应用适配器完成实际操作。 第六步执行结果回传给 Agent同时写入审计日志会话状态更新。在这个过程中Agent 不直接接触应用每一步都在系统监视下完成。即使动作执行失败也有完整的上下文可以用来定位问题。4.2 最小原型用 Python 模拟 Agent Manager为了验证上面的状态流转我写了一个精简的概念原型。它不依赖真实操作系统只是把“权限校验、用户确认、动作执行、审计记录”这套核心逻辑用代码表达出来。路径为prototype/agent_manager.pyimport uuid import time from dataclasses import dataclass, field dataclass class AuditRecord: session_id: str seq: int agent_id: str action: str app: str policy_result: str user_approval: bool execution_result: str timestamp: str dataclass class Policy: agent_id: str app: str action: str require_user_approval: bool rate_limit: int 100 class PolicyEngine: def __init__(self, policies): self.policies policies self.action_count {} def check(self, agent_id, app, action): policy None for p in self.policies: if (p.agent_id agent_id and p.app app and p.action action): policy p break if policy is None: return {allow: False, reason: no_policy, require_approval: False} count self.action_count.get((agent_id, app, action), 0) if count policy.rate_limit: return {allow: False, reason: rate_limit_exceeded, require_approval: False} return { allow: True, reason: policy_ok, require_approval: policy.require_user_approval, } class AgentManager: def __init__(self, policy_engine: PolicyEngine): self.policy_engine policy_engine self.audit_log [] self.sessions {} def create_session(self, agent_id, user_id): session_id str(uuid.uuid4()) self.sessions[session_id] { agent_id: agent_id, user_id: user_id, seq: 0, created_at: time.time(), status: running, } return session_id def execute(self, session_id, app, action, user_click_confirmTrue): session self.sessions.get(session_id) if not session: raise ValueError(session not found) session[seq] 1 seq session[seq] agent_id session[agent_id] decision self.policy_engine.check(agent_id, app, action) audit AuditRecord( session_idsession_id, seqseq, agent_idagent_id, actionaction, appapp, policy_resultdecision[reason], user_approvalFalse, execution_resultskipped, timestamptime.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()), ) if not decision[allow]: self.audit_log.append(audit) return {status: denied, reason: decision[reason]} if decision[require_approval] and not user_click_confirm: audit.execution_result blocked_waiting_approval self.audit_log.append(audit) return {status: blocked, reason: user_approval_required} if decision[require_approval]: audit.user_approval True # 模拟实际执行过程 try: execution_result self._run_action(app, action) audit.execution_result execution_result self.audit_log.append(audit) return {status: success, result: execution_result} except Exception as exc: audit.execution_result ffailed: {exc} self.audit_log.append(audit) return {status: failed, reason: str(exc)} def _run_action(self, app, action): # 在真实实现中这里会调用 Application Action Layer if action not in [read:inbox, send:mail, delete:mail]: raise RuntimeError(funsupported action: {action}) return f{app}:{action}:done def session_audit(self, session_id): return [r for r in self.audit_log if r.session_id session_id] if __name__ __main__: policies [ Policy(email-agent, mail-app, read:inbox, require_user_approvalFalse, rate_limit50), Policy(email-agent, mail-app, send:mail, require_user_approvalTrue, rate_limit10), Policy(email-agent, mail-app, delete:mail, require_user_approvalTrue, rate_limit5), ] engine PolicyEngine(policies) manager AgentManager(engine) session manager.create_session(email-agent, user-10086) print(manager.execute(session, mail-app, read:inbox)) print(manager.execute(session, mail-app, send:mail)) print(manager.execute(session, mail-app, send:mail, user_click_confirmFalse)) for record in manager.session_audit(session): print(record)这段代码虽然简单但已经覆盖了一个 Agent 管理系统最重要的骨架会话创建、策略评估、用户审批、动作执行、审计记录。4.3 运行验证与预期结果运行上面代码预期输出大致如下{status: success, result: mail-app:read:inbox:done} {status: success, result: mail-app:send:mail:done} {status: blocked, reason: user_approval_required} AuditRecord(session_id..., seq1, actionread:inbox, policy_resultpolicy_ok, user_approvalFalse, execution_resultmail-app:read:inbox:done, ...) AuditRecord(session_id..., seq2, actionsend:mail, policy_resultpolicy_ok, user_approvalTrue, execution_resultmail-app:send:mail:done, ...) AuditRecord(session_id..., seq3, actionsend:mail, policy_resultpolicy_ok, user_approvalFalse, execution_resultblocked_waiting_approval, ...)可以看到读收件箱低风险不需要用户确认直接执行成功发邮件中风险第一次弹了确认所以执行第二次模拟用户没点确认就被阻塞每次执行都写入了审计日志。这个原型能帮助我们理解规范的抽象流程。真实实现会复杂得多应用适配器需要对接具体 UI 框架策略引擎要支持动态配置下发审计日志要落到分布式存储或安全分析平台但核心的状态模型是通用的。5. 常见问题与风险边界规范设计得很理想但落地时一定会遇到实际问题。下面是我觉得最容易踩坑的几个方面。5.1 常见问题排查表问题现象常见原因解决思路Agent 操作被策略引擎拒绝策略未配置或 rate_limit 超限检查策略配置确认 agent_id、app、action 是否匹配用户确认窗口反复弹出require_user_approval 配置过严按风险等级重新划分动作低风险动作降级为静默授权应用执行成功但 Agent 报错应用的 standard action 返回值与预期不一致检查 Application Action Layer 适配器的返回值映射审计日志缺失审计写入失败被忽略审计日志应采用独立通道写入失败必须告警应用改版后操作失败适配器依赖 UI 控件结构降低适配器对控件细节的依赖优先使用稳定接口Agent 出现循环重复操作缺少频率限制或运行超时为敏感动作配置 rate_limit 和执行超时用户撤销授权后再执行被放行会话缓存了旧权限授权状态变更时必须使相关会话重新鉴权5.2 误操作与追责Agent 执行了错误操作之后谁来负责这必须提前想清楚。如果不是系统级审计用户根本说不清“到底是 Agent 自动做的还是我确认后做的”。Archer OS 的会话审计天然回答了这个问题。每一次高风险动作都留有证据用户什么时候点了确认、Agent 在什么上下文里发起了操作、当时的策略评估结果是什么。有了这个基础企业才能制定问责规则。5.3 权限过度授予不少团队为了让 Agent 跑通流程会图省事直接给 Agent 配置大范围权限。例如一个只负责汇总报表的 Agent被授予了整个文档目录的删除权限。一旦 Agent 逻辑出现边界问题删错文件的风险就成倍放大。安全设计上应当坚持权限最小化。Agent 能完成当前任务即可多一个不必要的动作授权都是风险敞口。策略引擎应该支持“按需临时授权”任务完成自动回收。5.4 应用兼容性Application Action Layer 的思路很好但适配工作并不轻松。不同桌面应用、Web 应用、传统客户端其控件体系完全不一样。有些应用甚至没有标准控件树只能用图像识别兜底。规范草案不应该限定适配层只能用某一种技术。合理做法是优先用原生接口其次 UI 控件树最后图像识别。但对图像识别兜底的场景审计日志里必须标记“使用低可靠性识别方式”让用户知道这次操作的风险等级更高。5.5 与 RPA 工具的边界Archer OS 不会彻底取代 RPA但会挤压纯模拟点击类 RPA 的生存空间。RPA 适合处理特定的重复流程Archer OS 这类系统级方案适合需要权限治理、跨应用协作、长期稳定运行的 Agent 服务。企业在选型时不必二选一。可以保留 RPA 处理存量历史遗留流程同时基于规范围绕新场景构建系统级 Agent 能力两者通过统一调度平台协同工作。6. 最佳实践与工程建议6.1 权限最小化与动态授权在实际工程中给 Agent 授权要像给员工开权限一样谨慎。Agent 创建时只授予当前任务必需的应用和动作并设置有效期。任务结束后权限自动回收。对于高权限动作可以加一层额外的二次校验例如要求管理员审批。policies: - agent: report-agent resource: app: excel-app rules: - action: read:sheet require_user_approval: false - action: write:sheet require_user_approval: true expires_at: 2025-12-31T23:59:59Z6.2 用户确认策略设计用户确认不能一刀切。所有动作都弹窗用户会产生确认疲劳逐渐变成“无脑点同意”确认机制形同虚设。正确做法是分级确认。低风险动作读取数据、查询状态直接执行。中风险动作发送消息、写入文件首次执行时确认同一会话内可设置白名单免确认。高风险动作删除数据、转账、退出登录每次都强制确认且确认界面要显示动作的完整上下文。6.3 审计日志与可观测性审计日志要做到“防篡改、可追溯、可告警”。生产环境中应使用独立的日志通道不允许 Agent 自己删除或修改日志。高风险动作的审计日志可以设置实时规则比如 1 分钟内有超过 10 次发送操作立即触发告警。同时审计不只是给安全团队看也要为 Agent 开发者提供调试视图。一个便捷的方式是提供按 session_id 查询的可视化时间线列出每个动作前后应用的界面状态截图帮助开发者快速定位失败原因。6.4 操作补偿与回滚不是所有操作都能回滚。发送邮件、提交订单这类动作一旦执行就无法撤销。对这类动作能做得只有“操作前充分确认”和“操作后清晰告知”。对于文件修改、配置变更这类可恢复操作设计时应支持快照。执行动作前由系统对应用状态做快照失败或误操作时可以从快照恢复。建议在规范草案中把“可回滚”作为动作的一个属性来标记策略引擎可以据此决定该动作的审批等级。6.5 安全与合规底线涉及系统级权限的 Agent 架构必须在封闭的测试环境里充分验证。不要在未授权设备上执行批量操作测试不要给 Agent 配置超出任务范围的数据访问权限。在生产环境使用时建议先以“半自动模式”运行Agent 生成操作计划由人确认关键步骤确认方式可以是批量审批或单一确认。运行一段时间审计数据和成功率稳定后再逐步放开为“自动执行 事后审计”。另外Agent 本身可能被恶意提示词攻击。比如通过邮件内容诱导 Agent 执行删除操作。策略引擎和内容过滤要配合对于高风险动作即使 Agent 发出请求系统也要强制用户确认从机制上阻断恶意指令链。6.6 关注草案演进Archer OS 目前还是 draft spec很多细节没有最终定稿。作为开发者不建议盲目为尚未稳定的协议写大量生产代码。更稳妥的做法是先基于核心抽象做原型验证沉淀适配器经验和安全模型同时持续跟踪规范更新。技术选型上可以保持模块化。把 Agent、策略引擎、审计服务、应用适配器解耦成独立模块即使后续规范细节调整也能低成本切换到新版本。7. 总结与下一步关注点Archer OS 草案的核心价值不是提供一个“更好的 RPA”而是把 AI Agent 操作应用这件事从“应用私有的临时机制”提升到“操作系统统一治理的规范体系”。它强调的不只是怎么做更是如何安全地做、可审计地做、可恢复地做。现阶段值得重点关注的方向有三个第一是统一动作协议层能否被足够多的应用适配器支持这是生态基础第二是权限策略引擎在真实系统中的性能与安全表现第三是审计体系能否满足企业合规要求。如果你也在做 Agent 平台或自动化工具建议先按照本文的最小原型思路在本地搭建一个概念验证把策略、审批、审计、执行这四个核心模块跑通。实践后再回来看 Archer OS 的草案更新理解深度会完全不同。希望这篇分析对你有帮助。如果有疑问欢迎在评论区交流实际落地中遇到的问题。
AI Agent操作系统级操作规范：Archer OS草案解析与最小原型
最近在调研 AI Agent 落地业务操作时遇到一个很现实的问题Agent 能理解任务、能生成步骤却难以安全、稳定、可控地操作系统里的应用。接入 API 的方式受限于应用是否开放接口UI 自动化的方式又非常脆弱更麻烦的是权限边界含糊不清——Agent 拿到什么权限、做了什么操作、出了问题如何回溯这些问题在现有方案里几乎没有统一答案。“Archer OS” 这个方向值得关注。它发布的 draft spec 核心命题就是让 AI Agents 在 OS authority操作系统权威约束下操作应用。这个视角把 AI Agent 从“应用层的临时脚本”提升到了“系统级协作服务”的高度。本文会完整拆解这份草案规范的设计思路、核心组件与实际操作流程并给出一个最小可运行的概念原型帮助理解这类架构。这篇文章适合正在做 AI Agent 平台、RPA 工具升级、系统自动化服务开发的工程师也适合想了解 Agent 安全边界和系统集成方案的技术负责人。读完你会掌握为什么 Agent 需要 OS 级权限、规范草案中的关键模块如何设计、一次授权操作的全链路长什么样以及在落地时最容易踩的坑。1. 为什么 AI Agent 需要 OS 级权限1.1 从“生成回答”到“操作系统”早期 AI 助手的核心能力是理解自然语言并生成文本答案应用边界只停留在对话框内部。但随着 Agent 能力增强用户期望它不只是“告诉你怎么做”而是“替你完成”。比如自动整理邮件并发送、跨应用拉取数据生成报表、在办公软件里批量处理文档。这些操作无法靠单纯的文本生成完成Agent 必须“伸手”去操作系统中的应用。于是一个关键问题出现了谁来定义 Agent 能做什么、不能做什么如果让 Agent 直接操作应用安全边界在哪里我们需要的不是又一个被应用绑定的脚本框架而是一个可以跨应用、跨窗口、可管控、可追溯的系统级操作机制。这正是 Archer OS draft spec 试图回答的问题。1.2 现有 Agent 操作应用的三种方式及其局限在 Archer OS 这类草案出现之前开发者要 Agent 操作应用通常只有三套思路。第一种是“API 集成”。应用开放 HTTP API 或 SDKAgent 调用接口完成操作。优点是稳定高效但缺点明显要求应用必须主动开放接口传统桌面应用、老旧系统、第三方商业软件根本不会有而且每个接口都需要独立对接Agent 的适配成本很高。第二种是“RPA/UI 自动化”。通过图像识别、坐标点击或控件抓取来模拟用户操作。这种方式不依赖 API但极其脆弱界面布局一变脚本就失效并且很难获得系统层面的权限控制。RPA 脚本拿到的是用户级权限一旦脚本出错可能造成不可预期的操作。第三种是“辅助功能接口”。部分操作系统提供无障碍接口如屏幕阅读器、辅助功能树等。Agent 可以读取界面控件树、模拟点击输入。这比坐标点击可靠但辅助功能接口本身并不是为自动化设计的权限校验、跨应用会话、审计能力都很弱。这三种方式有一个共同的问题Agent 直接面对的是“应用”而不是“操作系统”。缺少一个在系统层面统筹权限、会话、策略和审计的机制。1.3 理解 “OS Authority”“OS authority” 直译是“操作系统权威”。它不是说给 Agent 一个管理员账号也不是让 Agent 拥有 root 权限。它的含义应当更精确Agent 对应用的操作必须在操作系统的监视和授权之下进行由操作系统作为权威方来决定某个 Agent 是否有资格对某个应用执行某个动作。可以理解为 OS 扮演了“裁判”角色。应用和 Agent 是比赛的双方规则由 OS 制定。任何跨应用操作都先经过 OS 的权限校验、策略评估随后在审计系统里留下记录最后才被允许执行。对比项传统 API 方式RPA 方式OS Authority 方式权限来源应用自己管理用户账号权限系统级策略引擎跨应用统一不支持不支持支持审计能力依赖应用日志较弱系统级完整审计操作稳定性高低中高实现成本高需应用开放中中高这样设计的最大价值在于权限不是由每一个应用自己私下授权而是由操作系统集中管理。任何一个 Agent 的越权行为都可以在系统层面被拦截而不是等到应用被误操作后才被发现。2. Archer OS 草案规范的核心设计目标2.1 一份真正可落地的“操作规范”Archer OS 作为 draft spec首先要解决的是“标准化”问题。Agent 操作应用不能每次都走一套自定义协议。规范草案需要定义统一的操作语言、标准化的权限模型、可预测的执行流程。这份草案不是某一个公司的私有 SDK而是一个开放规范。第三方开发者可以根据规范实现自己的 Agent Runtime也可以基于规范开发客户端、策略引擎和审计服务。它的价值在于为整个生态提供一套“共同语言”。2.2 核心设计目标从当前公开的草案方向来看我觉得 Archer OS 至少承载了四个核心设计目标。第一统一动作抽象。Agent 操作应用无论用的是什么技术底层都应该被抽象为一组标准动作。比如打开窗口、点击按钮、填写输入框、读取列表内容、提交表单。这套动作语义是跨应用统一的Agent 不需要关心目标应用具体实现。第二系统级权限管控。所有操作动作必须经过策略引擎评估。策略引擎由系统层面配置支持按 Agent、按应用、按动作类型、按时间条件做细粒度控制。用户对 Agent 操作的授权记录可以被回溯而不是一笔糊涂账。第三会话与审计完整性。Agent 的每次操作都应归属到某个会话里。会话头记录了哪个 Agent、哪个用户、从什么时间开始每个动作都有序列号和结果状态。这个设计能保证问题发生后可以还原“当时到底发生了什么”。第四可恢复性。如果 Agent 执行到一半失败了应该能基于会话信息做补偿或回滚。至少也应该留下标记让用户知道哪些操作已执行、哪些未执行避免用户误以为任务没有发生而重复操作。2.3 与现有方案的区别Archer OS 与当前 RPA 工具的核心区别在于“谁在掌控”。RPA 工具是 Agent 进程自己去控制鼠标键盘本质上绕过了系统边界。Archer OS 则是把 Agent 变成“被操作系统管理的一等公民”Agent 要做任何操作先向系统申请由系统调度执行。这与 macOS 的辅助功能授权、Android 的无障碍服务有相似之处但 Archer OS 的野心更大它不只做“授权开关”还提出了统一动作层、策略引擎、会话审计这样的完整体系面向的是可编程、可治理的企业级自动化场景。3. 草案规范中的关键组件3.1 OS Agent Runtime 与 Agent 生命周期在 Archer OS 的设计里Agent 并不会直接接触应用进程而是由 OS Agent Runtime 统一托管。这个 Runtime 可以理解为一个常驻的系统服务负责三件事启动 Agent、管理 Agent 生命周期、代理 Agent 的所有操作请求。Agent 的生命周期分为创建、授权、运行、暂停、终止几个阶段。每个阶段都在系统里留下状态记录。这个设计的直接好处是用户随时可以查看当前系统有哪些 Agent 在活动它们被授予了哪些权限活动了多长时间。如果某个 Agent 长时间不活动Runtime 可以自动回收它的授权。相比传统方式里“授权一次永久有效”这种过期机制能显著减少 Agent 遗忘或休眠造成的安全风险。3.2 Application Action Layer 应用操作抽象层这是整个草案里最有价值的部分。它定义了一套标准动作协议让 Agent 通过统一动作来操作任何已适配的应用。简单来说一个动作至少需要包含四部分信息应用标识、动作类型、动作参数和期望结果。以“打开邮件并发送”任务为例{ app: com.example.mail, action: open, params: { target: compose_window }, expected: { result: window_opened } }发送邮件阶段{ app: com.example.mail, action: input, params: { field: recipient, value: userexample.com }, expected: { result: filled } }这套抽象接口的意义在于Agent 侧永远不需要知道目标应用的内部实现。应用侧只要实现一套适配器把标准动作映射到真实 UI 控件或内部 API 上即可。后续应用改版Agent 侧代码不用动只要适配器保持标准动作不变。3.3 Policy Engine 权限策略引擎权限策略是安全设计的核心。Archer OS 草案中策略引擎负责在动作执行前判断“这个 Agent 是否被允许对目标应用执行该动作”。一份概念性的策略配置如下路径为policies/example-policy.yamlpolicies: - agent: email-assistant resource: app: com.example.mail rules: - action: read:inbox require_user_approval: false max_frequency: 30 - action: send:mail require_user_approval: true rate_limit: 10 time_window: 09:00-18:00 - action: delete:mail require_user_approval: true irreversible: true这套配置说明了几层含义require_user_approval表示该动作是否需要在执行前弹出用户确认窗口。读收件箱这类低风险操作可以静默授权删除邮件这类高风险操作则必须用户确认。rate_limit限制单位时间内动作的最大次数防止 Agent 因异常循环导致海量操作。irreversible标记该操作不可逆系统会给予最高级别的拦截和提示。策略引擎的价值在于将“能不能做”从 Agent 代码里抽离出来变成系统级的配置决策。这样安全团队和运维人员可以在不修改 Agent 代码的前提下动态调整权限边界。3.4 Session 与审计体系审计是 Archer OS 规范中最不能妥协的模块。每条动作执行都必须生成一条审计记录格式类似{ session_id: 8f3a2c91-7b1e-4c6d-9a24-1c0f9e2a5d88, seq: 12, agent_id: email-assistant, user_id: user-10086, action: send:mail, target: { app: com.example.mail, window: compose_window, element: send_button }, policy_result: allow, user_approval: true, execution_result: success, timestamp: 2025-06-18T14:32:07.125Z }这套审计日志解决的是“信任问题”。当系统出现误操作时可以通过 session_id 把整个操作过程拉出来逐条还原。哪个 Agent、经过谁确认、在什么时间、执行了什么操作、结果是成功还是失败一目了然。4. 一次完整的授权操作流程4.1 从用户意图到操作系统动作为了更直观地理解整个链路我们把一次“让 Agent 帮我发送邮件”的完整流程拆成六个步骤。第一步用户向 Agent 提出请求。Agent 解析用户意图生成操作计划。 第二步Agent 将计划中的动作提交给 OS Agent Runtime请求执行。 第三步Runtime 将动作发送到 Policy Engine进行权限评估。 第四步如果动作被标记为需要用户确认则弹出系统级授权窗口。用户确认后策略结果附带 user_approvaltrue。 第五步Runtime 将动作转发给 Application Action Layer由应用适配器完成实际操作。 第六步执行结果回传给 Agent同时写入审计日志会话状态更新。在这个过程中Agent 不直接接触应用每一步都在系统监视下完成。即使动作执行失败也有完整的上下文可以用来定位问题。4.2 最小原型用 Python 模拟 Agent Manager为了验证上面的状态流转我写了一个精简的概念原型。它不依赖真实操作系统只是把“权限校验、用户确认、动作执行、审计记录”这套核心逻辑用代码表达出来。路径为prototype/agent_manager.pyimport uuid import time from dataclasses import dataclass, field dataclass class AuditRecord: session_id: str seq: int agent_id: str action: str app: str policy_result: str user_approval: bool execution_result: str timestamp: str dataclass class Policy: agent_id: str app: str action: str require_user_approval: bool rate_limit: int 100 class PolicyEngine: def __init__(self, policies): self.policies policies self.action_count {} def check(self, agent_id, app, action): policy None for p in self.policies: if (p.agent_id agent_id and p.app app and p.action action): policy p break if policy is None: return {allow: False, reason: no_policy, require_approval: False} count self.action_count.get((agent_id, app, action), 0) if count policy.rate_limit: return {allow: False, reason: rate_limit_exceeded, require_approval: False} return { allow: True, reason: policy_ok, require_approval: policy.require_user_approval, } class AgentManager: def __init__(self, policy_engine: PolicyEngine): self.policy_engine policy_engine self.audit_log [] self.sessions {} def create_session(self, agent_id, user_id): session_id str(uuid.uuid4()) self.sessions[session_id] { agent_id: agent_id, user_id: user_id, seq: 0, created_at: time.time(), status: running, } return session_id def execute(self, session_id, app, action, user_click_confirmTrue): session self.sessions.get(session_id) if not session: raise ValueError(session not found) session[seq] 1 seq session[seq] agent_id session[agent_id] decision self.policy_engine.check(agent_id, app, action) audit AuditRecord( session_idsession_id, seqseq, agent_idagent_id, actionaction, appapp, policy_resultdecision[reason], user_approvalFalse, execution_resultskipped, timestamptime.strftime(%Y-%m-%dT%H:%M:%SZ, time.gmtime()), ) if not decision[allow]: self.audit_log.append(audit) return {status: denied, reason: decision[reason]} if decision[require_approval] and not user_click_confirm: audit.execution_result blocked_waiting_approval self.audit_log.append(audit) return {status: blocked, reason: user_approval_required} if decision[require_approval]: audit.user_approval True # 模拟实际执行过程 try: execution_result self._run_action(app, action) audit.execution_result execution_result self.audit_log.append(audit) return {status: success, result: execution_result} except Exception as exc: audit.execution_result ffailed: {exc} self.audit_log.append(audit) return {status: failed, reason: str(exc)} def _run_action(self, app, action): # 在真实实现中这里会调用 Application Action Layer if action not in [read:inbox, send:mail, delete:mail]: raise RuntimeError(funsupported action: {action}) return f{app}:{action}:done def session_audit(self, session_id): return [r for r in self.audit_log if r.session_id session_id] if __name__ __main__: policies [ Policy(email-agent, mail-app, read:inbox, require_user_approvalFalse, rate_limit50), Policy(email-agent, mail-app, send:mail, require_user_approvalTrue, rate_limit10), Policy(email-agent, mail-app, delete:mail, require_user_approvalTrue, rate_limit5), ] engine PolicyEngine(policies) manager AgentManager(engine) session manager.create_session(email-agent, user-10086) print(manager.execute(session, mail-app, read:inbox)) print(manager.execute(session, mail-app, send:mail)) print(manager.execute(session, mail-app, send:mail, user_click_confirmFalse)) for record in manager.session_audit(session): print(record)这段代码虽然简单但已经覆盖了一个 Agent 管理系统最重要的骨架会话创建、策略评估、用户审批、动作执行、审计记录。4.3 运行验证与预期结果运行上面代码预期输出大致如下{status: success, result: mail-app:read:inbox:done} {status: success, result: mail-app:send:mail:done} {status: blocked, reason: user_approval_required} AuditRecord(session_id..., seq1, actionread:inbox, policy_resultpolicy_ok, user_approvalFalse, execution_resultmail-app:read:inbox:done, ...) AuditRecord(session_id..., seq2, actionsend:mail, policy_resultpolicy_ok, user_approvalTrue, execution_resultmail-app:send:mail:done, ...) AuditRecord(session_id..., seq3, actionsend:mail, policy_resultpolicy_ok, user_approvalFalse, execution_resultblocked_waiting_approval, ...)可以看到读收件箱低风险不需要用户确认直接执行成功发邮件中风险第一次弹了确认所以执行第二次模拟用户没点确认就被阻塞每次执行都写入了审计日志。这个原型能帮助我们理解规范的抽象流程。真实实现会复杂得多应用适配器需要对接具体 UI 框架策略引擎要支持动态配置下发审计日志要落到分布式存储或安全分析平台但核心的状态模型是通用的。5. 常见问题与风险边界规范设计得很理想但落地时一定会遇到实际问题。下面是我觉得最容易踩坑的几个方面。5.1 常见问题排查表问题现象常见原因解决思路Agent 操作被策略引擎拒绝策略未配置或 rate_limit 超限检查策略配置确认 agent_id、app、action 是否匹配用户确认窗口反复弹出require_user_approval 配置过严按风险等级重新划分动作低风险动作降级为静默授权应用执行成功但 Agent 报错应用的 standard action 返回值与预期不一致检查 Application Action Layer 适配器的返回值映射审计日志缺失审计写入失败被忽略审计日志应采用独立通道写入失败必须告警应用改版后操作失败适配器依赖 UI 控件结构降低适配器对控件细节的依赖优先使用稳定接口Agent 出现循环重复操作缺少频率限制或运行超时为敏感动作配置 rate_limit 和执行超时用户撤销授权后再执行被放行会话缓存了旧权限授权状态变更时必须使相关会话重新鉴权5.2 误操作与追责Agent 执行了错误操作之后谁来负责这必须提前想清楚。如果不是系统级审计用户根本说不清“到底是 Agent 自动做的还是我确认后做的”。Archer OS 的会话审计天然回答了这个问题。每一次高风险动作都留有证据用户什么时候点了确认、Agent 在什么上下文里发起了操作、当时的策略评估结果是什么。有了这个基础企业才能制定问责规则。5.3 权限过度授予不少团队为了让 Agent 跑通流程会图省事直接给 Agent 配置大范围权限。例如一个只负责汇总报表的 Agent被授予了整个文档目录的删除权限。一旦 Agent 逻辑出现边界问题删错文件的风险就成倍放大。安全设计上应当坚持权限最小化。Agent 能完成当前任务即可多一个不必要的动作授权都是风险敞口。策略引擎应该支持“按需临时授权”任务完成自动回收。5.4 应用兼容性Application Action Layer 的思路很好但适配工作并不轻松。不同桌面应用、Web 应用、传统客户端其控件体系完全不一样。有些应用甚至没有标准控件树只能用图像识别兜底。规范草案不应该限定适配层只能用某一种技术。合理做法是优先用原生接口其次 UI 控件树最后图像识别。但对图像识别兜底的场景审计日志里必须标记“使用低可靠性识别方式”让用户知道这次操作的风险等级更高。5.5 与 RPA 工具的边界Archer OS 不会彻底取代 RPA但会挤压纯模拟点击类 RPA 的生存空间。RPA 适合处理特定的重复流程Archer OS 这类系统级方案适合需要权限治理、跨应用协作、长期稳定运行的 Agent 服务。企业在选型时不必二选一。可以保留 RPA 处理存量历史遗留流程同时基于规范围绕新场景构建系统级 Agent 能力两者通过统一调度平台协同工作。6. 最佳实践与工程建议6.1 权限最小化与动态授权在实际工程中给 Agent 授权要像给员工开权限一样谨慎。Agent 创建时只授予当前任务必需的应用和动作并设置有效期。任务结束后权限自动回收。对于高权限动作可以加一层额外的二次校验例如要求管理员审批。policies: - agent: report-agent resource: app: excel-app rules: - action: read:sheet require_user_approval: false - action: write:sheet require_user_approval: true expires_at: 2025-12-31T23:59:59Z6.2 用户确认策略设计用户确认不能一刀切。所有动作都弹窗用户会产生确认疲劳逐渐变成“无脑点同意”确认机制形同虚设。正确做法是分级确认。低风险动作读取数据、查询状态直接执行。中风险动作发送消息、写入文件首次执行时确认同一会话内可设置白名单免确认。高风险动作删除数据、转账、退出登录每次都强制确认且确认界面要显示动作的完整上下文。6.3 审计日志与可观测性审计日志要做到“防篡改、可追溯、可告警”。生产环境中应使用独立的日志通道不允许 Agent 自己删除或修改日志。高风险动作的审计日志可以设置实时规则比如 1 分钟内有超过 10 次发送操作立即触发告警。同时审计不只是给安全团队看也要为 Agent 开发者提供调试视图。一个便捷的方式是提供按 session_id 查询的可视化时间线列出每个动作前后应用的界面状态截图帮助开发者快速定位失败原因。6.4 操作补偿与回滚不是所有操作都能回滚。发送邮件、提交订单这类动作一旦执行就无法撤销。对这类动作能做得只有“操作前充分确认”和“操作后清晰告知”。对于文件修改、配置变更这类可恢复操作设计时应支持快照。执行动作前由系统对应用状态做快照失败或误操作时可以从快照恢复。建议在规范草案中把“可回滚”作为动作的一个属性来标记策略引擎可以据此决定该动作的审批等级。6.5 安全与合规底线涉及系统级权限的 Agent 架构必须在封闭的测试环境里充分验证。不要在未授权设备上执行批量操作测试不要给 Agent 配置超出任务范围的数据访问权限。在生产环境使用时建议先以“半自动模式”运行Agent 生成操作计划由人确认关键步骤确认方式可以是批量审批或单一确认。运行一段时间审计数据和成功率稳定后再逐步放开为“自动执行 事后审计”。另外Agent 本身可能被恶意提示词攻击。比如通过邮件内容诱导 Agent 执行删除操作。策略引擎和内容过滤要配合对于高风险动作即使 Agent 发出请求系统也要强制用户确认从机制上阻断恶意指令链。6.6 关注草案演进Archer OS 目前还是 draft spec很多细节没有最终定稿。作为开发者不建议盲目为尚未稳定的协议写大量生产代码。更稳妥的做法是先基于核心抽象做原型验证沉淀适配器经验和安全模型同时持续跟踪规范更新。技术选型上可以保持模块化。把 Agent、策略引擎、审计服务、应用适配器解耦成独立模块即使后续规范细节调整也能低成本切换到新版本。7. 总结与下一步关注点Archer OS 草案的核心价值不是提供一个“更好的 RPA”而是把 AI Agent 操作应用这件事从“应用私有的临时机制”提升到“操作系统统一治理的规范体系”。它强调的不只是怎么做更是如何安全地做、可审计地做、可恢复地做。现阶段值得重点关注的方向有三个第一是统一动作协议层能否被足够多的应用适配器支持这是生态基础第二是权限策略引擎在真实系统中的性能与安全表现第三是审计体系能否满足企业合规要求。如果你也在做 Agent 平台或自动化工具建议先按照本文的最小原型思路在本地搭建一个概念验证把策略、审批、审计、执行这四个核心模块跑通。实践后再回来看 Archer OS 的草案更新理解深度会完全不同。希望这篇分析对你有帮助。如果有疑问欢迎在评论区交流实际落地中遇到的问题。
