AI 代理要真正完成复杂任务就不可能只停留在问答层面。它需要操作真实的应用读取表单、点击按钮、填写数据、提交任务。问题在于这些操作一旦脱离系统权限约束就会变成最难控制的安全风险。Archer OS 的草案设计正是围绕 AI agents 在操作系统授权OS authority下操作 apps 这个命题展开的。它讨论的不是给某个自动化工具加一个开关而是让操作系统成为唯一的权限裁决点所有 agent 行为都走系统审计通道。这篇 draft spec 的讨论会聚焦三个部分为什么 AI agent 操作应用必须由 OS 授权Archer OS 草案应该包含哪些核心模型和接口以及从草案走向真实系统时需要考虑的安全边界、审计机制和落地路线。读者如果正在设计 AI 自动化工具、企业级 agent 平台或操作系统级权限服务这篇文章可以作为一个初始的设计参考。如果只是准备实现一个简单的 UI 自动化脚本也能从中看到哪些权限问题是提前就需要埋进架构里的。1. 为什么 AI 代理操作应用需要 OS authority1.1 从传统自动化到 AI 代理操作应用的差异传统自动化工具比如 RPA通常走的是“应用层授权”。也就是说RPA 工具先通过某种方式登录系统拿到会话凭据再在目标应用内部执行按钮点击、表单填写、数据抓取。整个过程由固定流程驱动动作步骤是预先写死的权限也往往是在应用或脚本层面静态配置的。这种方式对规则明确的业务有效但面对 AI agent 时会出现明显缺口。AI agent 的核心特点不是“按固定脚本执行”而是“根据当前输入和目标动态规划动作”。同一句话可以衍生出多条执行路径同一个界面在不同状态下会触发不同操作。如果仍然把权限放在应用层规则会变得非常复杂而且无法回答一个关键问题当 agent 决定执行某个动作时系统凭什么相信这个动作是用户授权的应用层授权的另一个问题是权限粒度。大多数应用只能区分“登录用户”和“未登录用户”或者只有“普通用户”和“管理员”两层。但 AI agent 操作应用时真正需要的权限可能是“只允许读取当前订单列表不允许修改订单金额”“允许打开邮件不允许发送邮件”。这种细粒度权限很难在应用内部实现因为应用并不关心操作者是一个自动化进程还是一个人也不关心操作动机和上下文。传统自动化和 AI agent 操作应用的差异本质上是“可预期性”的差异。自动化流程可预期所以权限可以预先配好AI agent 的动态性更强所以权限必须在动作发生的那一刻由统一机制裁决。这个统一机制不能放在某个应用里否则其他应用无法复用也不能放在 agent 自己手里否则等于让被监管者自己管自己。Archer OS 草案选择把裁决权放到操作系统层正是为了应对这个差异。1.2 什么是 OS authority为什么权限要由 OS 来管OS authority 可以理解为“操作系统作为授权中心”。在普通桌面操作系统中操作系统本来就在管理进程、文件、网络、设备、剪贴板等资源。一个进程能否读取某个文件、是否可以使用摄像头、能否访问网络端口最终都由操作系统内核或系统服务裁决。Archer OS 的思路是把 AI agent 操作应用的动作也纳入这套已有的资源管理框架里。操作系统拥有其他层不具备的三个优势。第一可见性。操作系统能看到进程身份、窗口层级、文件路径、网络连接这些信息是应用层很难伪造的。第二强制力。即使应用本身不配合操作系统仍然可以拦截系统调用、终止进程、隔离文件访问。第三统一性。所有应用都运行在同一个操作系统上只要授权机制在 OS 层实现所有应用都能被覆盖不需要每个应用分别开发安全接口。因此Archer OS 草案里的 OS authority 不是一个简单的“权限开关”而是一套底层的资源访问控制机制。AI agent 不是一个特殊进程而是与其他进程一样受系统约束唯一不同的是agent 的动作需要通过一个标准化的运行时接口提交给操作系统由操作系统判断该动作是否符合当前用户意图和策略。这里需要区分两个容易混淆的概念应用授权和 OS 授权。应用授权是“目标应用是否允许这个用户这样操作”OS 授权是“操作系统是否允许这个 agent 进程执行这样的操作”。Archer OS 草案的关注点主要在后者。操作系统授权的结论可以作为应用授权的前置条件但 OS 授权不能替代应用内部的业务规则。例如OS 可以允许 agent 访问财务软件窗口但财务软件内部是否允许导出报表仍然由应用自己决定。1.3 没有 OS 层授权会出现哪几类风险结合目前 AI agent 开发的常见问题缺少 OS 层授权的风险可以归纳为四类。风险维度具体表现长期后果权限过大Agent 持有整个应用的访问凭证容易误操作或越权一次 prompt injection 可能触发不可逆操作审计缺失只记录 agent 的输出不记录底层系统交互出现事故后无法还原现场无法判定责任撤销困难权限绑定在长期 token 或账号上无法按动作撤销确认恶意行为后仍无法及时止损对抗脆弱Agent 直接操作 UI绕过系统安全策略恶意应用可伪装界面诱导 agent 执行敏感动作权限过大是最常见的问题。很多 agent 框架为了让流程跑通会直接给 agent 一个管理员账号或一个具有完整权限的 API token。开发阶段问题不大一旦进入生产环境prompt injection、模型幻觉、外部指令污染都可能让这个高权限 token 被滥用。操作系统层授权可以缩小每次动作的权限范围避免 agent 以全量权限运行。审计缺失的后果更隐蔽。没有 OS 层记录事后只能看到“agent 输出了一段文本”而看不到“agent 到底调用了哪条系统 API、读写过哪个文件、访问过哪个窗口”。真正的问题排查往往需要这种系统级调用链路。OS authority 的核心价值之一就是让每次操作都能留下操作系统认可的审计记录。撤销困难也是企业落地时最容易踩的坑。传统账号权限是一个静态集合很难做到“刚才那一分钟允许发送邮件下一分钟立即禁止”。Archer OS 草案中可以把授权设计成短时、可撤销、与具体动作绑定才能应对 agent 行为的动态性。没有这一层权限一旦发出去回收就变成了一件高风险操作。对抗脆弱则解释了为什么不能只依赖应用层或 UI 层。应用层授权无法识别“当前点击来自真实用户还是来自 agent 窗口模拟”而 OS 层可以校验进程来源和窗口句柄。Archer OS 草案如果从第一天就把这类校验纳入设计后续在防仿冒、防重放攻击上会轻松很多。2. Archer OS 草案的总体架构与核心模型2.1 核心组件怎么划分一个可讨论的 Archer OS 草案至少应包含四个核心组件Agent Runtime、Authority Service、App Interface、Audit Log。它们各自负责一段边界清晰的职责。组件职责关键问题Agent Runtime承载 AI agent 进程统一提交动作请求如何证明当前请求来自受管 agentAuthority Service负责权限策略解析、动作裁决、授权状态管理如何定义最小权限和动态授权App Interface连接目标应用与操作系统的操作通道如何把应用操作抽象成系统可理解的动作Audit Log记录授权请求、裁决结果、动作执行结果如何保证日志不可篡改且可关联Agent Runtime 是 agent 与 OS 之间的桥梁。它不能直接调用目标应用的内部接口而是要把意图翻译成标准动作提交给 Authority Service。Authority Service 是核心裁决点它根据 agent 身份、用户配置、策略、上下文返回“允许”“拒绝”或“需要用户确认”。App Interface 解决的是“让操作系统能操作应用”的问题例如通过窗口管理、辅助功能接口、操作系统 API 桥接。Audit Log 则贯穿整个过程从请求到执行结果都需要留痕。这四部分不是独立模块而是构成一条请求链路。一个典型的操作流程是agent 生成意图Agent Runtime 将意图转换为动作描述Authority Service 检查策略并授权授权通过后由 App Interface 调用系统 API 操作应用最后把执行结果写回 Audit Log。任何一环缺失OS authority 都会变成空话。2.2 一个动作在 Archer OS 中的完整链路为了让模型更具体下面用一个例子说明。假设 agent 需要在邮件客户端中读取最新一封未读邮件动作链路可以拆成五步Agent 通过模型理解用户指令判断需要调用read_email动作。Agent Runtime 构造动作请求附上 agent_id、request_id、操作目标和上下文摘要。Authority Service 检查当前策略。如果用户只授予了“读取邮件”权限则该请求放行如果同时涉及“删除邮件”则可能被拒绝或进入确认流程。App Interface 拿到授权令牌后通过系统辅助接口定位邮件应用窗口找到未读邮件列表读取内容。执行结果和审计记录同时返回给 Agent Runtime并写入 Audit Log。这条链路最重要的特征是agent 不直接拥有调用邮件客户端的长期权限。每一次读操作都通过 OS 层裁决Agent Runtime 也无法绕过 Authority Service。换句话说即使模型被恶意提示词控制能执行的动作依然被限制在已授予的权限范围内。组件划分上也需要注意App Interface 并不是“万能操作手”。它应该只实现操作系统能力范围内的、经过声明的接口不能允许 agent 通过它执行任意代码。Archer OS 草案在这一点上需要定义十分严格的“动作白名单”而不是开放一个通用的 shell 通道。2.3 草案需要确定的三组接口Archer OS 的 draft spec 如果不能定义清楚接口各组件之间的协作就是概念性的。最少需要定义三组接口Agent Runtime 到 Authority Service 之间的授权请求接口用于提交动作描述和获取授权结论。Authority Service 返回给 Agent Runtime 的授权凭证凭证应包含动作范围、有效期、最大执行次数。App Interface 执行动作后返回的结果结构以及错误信息结构保证审计记录可关联。这三组接口在草案中可以用 JSON Schema 或协议缓冲定义。下面的 JSON 展示一个最小化的授权请求结构{ apiVersion: v1, requestId: req_01ED2G4Y, agent: { agentId: agent_user_mail_01, appId: com.example.mail }, action: { operation: read, target: { resourceType: email, scope: latest_unread }, params: { limit: 1 } }, intent: 读取最新一封未读邮件, requestedAt: 2026-01-01T10:00:00Z }这个结构的关键点是requestId用于关联后续所有日志和结果。agent.appId表示 agent 希望操作的目标应用action.operation和action.target用来描述最小权限需求。请求可以不包含任何敏感内容真正的敏感数据在授权通过后由 App Interface 拉取避免在请求阶段就暴露。2.4 为什么不让 agent 直接调用应用 API很多开发者会问既然目标应用有 API为什么不直接让 agent 调用这些 API答案在于 API 不具备“操作系统级授权”的语义。应用 API 通常只验证调用者是否持有 token不会验证调用者是否是当前用户正在监督的 agent也不会记录操作系统层面的窗口状态、进程来源。更重要的是应用 API 无法统一管理跨应用的策略。用户可能希望“agent 可以读邮件但不能发邮件可以查看订单但不能修改价格”这种策略横跨多个应用只有 OS 层才能统一表达和执行。另一个原因是安全隔离。agent 自身的代码、模型输入、工具调用都可能被污染。如果 agent 直接持有应用 API tokentoken 就会成为攻击面的一部分。Archer OS 草案中agent 不再直接持有目标应用的长期凭据而是由 Authority Service 在授权通过后签发短时凭证给 App Interface 使用。这样即使 agent 被攻破攻击者拿不到能长期访问应用的密钥。因此Archer OS 不是要取代应用 API而是在应用 API 和 agent 之间增加一道由操作系统控制的授权闸门。应用仍然负责业务规则OS 负责“谁在什么条件下可以做什么”两者各司其职。3. 权限模型与授权流程设计3.1 Agent 身份注册与基本信任权限系统第一步是身份。Archer OS 草案需要为每个 agent 建立唯一的身份标识并记录它的受管状态。没有身份就没有办法做策略绑定也没办法审计。身份注册至少要包含以下信息agentId唯一标识比如agent_user_mail_01。所属用户agent 代表哪个用户执行操作。运行环境信息进程路径、可执行文件哈希、运行目标版本。能力声明agent 声称会使用的动作类型。初始信任等级普通、受限、高信任。注册信息不能只保存一次。Archer OS 草案应当考虑 agent 代码更新后的身份重验证。agent 更新后即使 agentId 不变可执行文件哈希也会变化系统的信任决策应当重新评估。否则攻击者只需通过更新入口替换 agent 代码就能继承原有权限。身份注册的示例策略片段可以用 YAML 表达agents: - id: agent_user_mail_01 owner: user_1001 executable_hash: sha256:2c9f... capabilities: - read_email - list_emails trust_level: normal status: enabled这里trust_level不是永久的。系统可以结合 agent 的历史行为动态调整 trust level。比如出现大量被拒绝请求时自动降级连续通过用户确认后可适当放宽单次授权窗口。这种动态机制在 draft spec 中可以作为策略扩展点不宜在早期版本写死。3.2 最小权限策略编写方式最小权限原则在 Archer OS 里不是口号而是策略引擎的默认行为。默认情况下agent 不应该拥有任何权限。只有用户或管理员显式授予的权限才有效。策略可以分为三层全局策略适用于所有 agent 的基础限制例如禁止删除系统关键文件。用户策略某个用户针对自己管辖 agent 的授权。动作级策略针对某个操作、某个资源、某个条件的细粒度规则。一个策略文件可以这样设计policies: - id: policy_mail_read description: 允许邮件助手读取未读邮件但不允许发送或删除 subject: agentId: agent_user_mail_01 effect: allow actions: - read_email resources: - type: email scope: latest_unread conditions: timeWindow: 09:00-18:00 maxAttemptsPerMinute: 10 requires_consent: false这个策略只允许agent_user_mail_01读取最新未读邮件其他操作默认拒绝。maxAttemptsPerMinute是一个常见限流条件避免 agent 陷入循环时频繁调用。requires_consent字段表示该动作是否需要用户实时确认。设计时永远要遵循一个默认方向宁可先拒绝再由用户显式放开而不是先放开等出问题再收紧。策略设计中最容易忽略的是“上下文条件”。Archer OS 草案如果只写“读邮件”粒度仍然太粗。可以增加时间窗口、设备位置、当前前台应用等条件。例如只允许在目标应用位于前台时执行点击操作避免 agent 在后台静默操作。这个条件看似简单却能有效防止许多恶意场景。3.3 用户确认与动态授权窗口OS authority 不等于取消人工参与。相反动态授权恰恰需要用户确认机制来弥补策略无法覆盖的灵活性。Archer OS 草案在选择授权模式时可以采用三种类型授权类型适用场景有效期典型触发本次动作授权高风险、一次性动作执行完即失效发送邮件、删除文件会话授权一整个任务流程内复用任务结束或超时多轮表单填写长期授权用户明确信任的简单场景数天到数月自动读取日程用户确认不应该只给一个“允许/拒绝”按钮。系统应该在确认面板上展示动作语义、目标资源、涉及的应用和可能产生的后果。例如agent 请求发送邮件时确认面板应当显示收件人、主题、正文摘要而不是只显示“邮件助手请求发信权限”。这样才能避免用户盲目确认。动态授权窗口还应支持撤销。用户可以在授权生效中随时终止权限系统收到撤销信号后不仅要停止后续请求还应当尝试中断当前正在执行的动作。虽然中断可能不总是成功但在草案中应当把这个目标定义清楚。3.4 授权状态机与生命周期一个授权请求从创建到结束会经历多个状态。Archer OS 草案应当定义一个清晰的状态机避免状态混乱导致权限泄漏。推荐的状态集合包括REQUESTEDAgent 提交请求等待裁决。PENDING_CONSENT策略要求用户确认等待用户操作。GRANTED授权通过Agent 可以执行。DENIED授权拒绝。REVOKED授权被用户或系统撤销。EXPIRED授权窗口超时。COMPLETED动作成功执行授权标记完成。FAILED动作执行失败授权结果记录失败原因。状态之间的跳转必须被审计。比如从 GRANTED 到 REVOKED需要记录撤销者和撤销原因从 REQUESTED 到 DENIED需要记录拒绝策略 ID。状态机不复杂但能有效防止“授权一直有效”这种典型问题。下面用文本伪代码表示授权裁决逻辑function decide(request, policies): matches find_matching_policies(request, policies) if matches is empty: return DENIED(no_policy_matches) if any policy effect allow and all conditions_satisfied: return GRANTED if requires_consent: send_consent_request(request) return PENDING_CONSENT return DENIED(conditions_not_met)这个伪代码体现了两个原则第一策略匹配不到就默认拒绝第二即使策略允许如果声明需要用户确认只能进入 PENDING_CONSENT不能直接放行。生产环境还可以在裁决逻辑中加入异常检测检测到风险后强制降级为人工确认。4. 动作原语与 OS 级执行4.1 如何描述一个可执行动作Archer OS 草案要想让操作系统执行 agent 的动作必须有一套动作描述标准。动作描述至少要包含执行主体、操作类型、目标资源、参数、超时约束和意图。过于生活化的自然语言不能直接作为系统调用指令必须转换成结构化格式。前面已经给出了授权请求中的动作结构。实际执行时的动作描述可以更进一步包含执行上下文{ actionId: act_20260101_001, agentId: agent_user_mail_01, operation: click, target: { app: com.example.mail, windowTitle: Inbox, elementHint: { type: button, name: Compose } }, params: {}, timeoutMs: 5000, retries: 1, context: { userConsentId: consent_998, policyIds: [policy_mail_read, policy_ui_action] } }elementHint是给操作系统辅助接口定位用的不是给 agent 直接抓取 DOM 用的。这是设计上的一个重要边界agent 描述“我要点哪个按钮”操作系统负责“如何找到并点击这个按钮”。这样 agent 不需要依赖特定应用的私有选择器操作系统也能统一做权限检查和目标识别。4.2 常用动作原语与资源类型动作原语不宜设计得过多否则每个应用都要适配一遍。Archer OS 草案可以先定义一组核心原语原语含义典型示例read读取应用内容读取邮件列表、读取订单详情write写入应用内容填写表单、编辑文档execute触发应用行为点击发送、提交订单navigate切换页面或窗口打开指定页面、切换 Tabconfirm在弹窗上点击确认接受条款、确认删除这些原语应该映射到操作系统能力。比如execute可能映射为发送窗口消息或调用辅助功能接口read可能映射为获取窗口树或读取剪贴板。映射关系在 draft spec 中要明确不同操作系统能力不同但动作语义应该保持一致。这样上层 agent 不需要关心具体系统 API 差异。资源类型则描述 agent 操作的对象常见的包括email、calendar_event、file、form_field、window。资源类型需要和动作原语组合形成“动作-资源”对。策略中通常只允许某些动作-资源对比如read_email允许write_email不允许。4.3 操作系统执行时的检查点权限通过后动作执行不能直接进入应用内部。Archer OS 在执行阶段至少需要设置四个检查点进程校验确认请求来自被注册的 Agent Runtime 进程而不是伪造进程。授权令牌校验校验 Authority Service 签发的凭证是否有效、是否超时、是否对应同一 actionId。目标匹配校验确认动作里描述的目标窗口、元素在授权时与当前实际状态匹配。结果校验确认执行结果符合预期不能把“失败”伪装成“成功”。每个检查点都应该产生审计事件。只要其中一个检查点失败系统就应中止动作并返回错误码。以下伪代码展示执行代理侧的决策逻辑function execute(action, grant): if not verify_process(action.agentId): return ERROR(process_mismatch) if not validate_grant(grant, action.actionId): return ERROR(invalid_grant) target locate_window(action.target) if target is None: return ERROR(target_not_found) if not verify_current_state(target): return ERROR(state_changed) result perform_system_action(target, action) emit_audit(action_result, result) return result其中verify_current_state很关键。它要求目标窗口状态与授权时一致。如果授权时 agent 声称要点击“确定”按钮但执行时窗口已经变成了“删除确认”系统必须拒绝执行。这能防止 agent 拿到授权后执行与授权语义不一致的操作。4.4 失败处理与重试策略真实系统里动作执行失败很常见。Archer OS 草案应该区分失败类型而不是无差别重试。失败类型至少包括权限失败授权缺失或过期需要重新申请授权。定位失败找不到窗口或元素可能是应用状态变化。执行失败系统 API 调用出错可能是应用无响应。安全失败状态校验不通过例如目标窗口发生变化。重试策略需要根据类型设计。权限失败不应重试应返回给 agent 让用户重新授权定位失败可以有限重试比如 2 到 3 次后放弃安全失败必须立即停止并进入人工审核。无差别重试是生产事故的常见来源尤其是点击某按钮会导致破坏性操作时重试只会放大后果。Archer OS 还可以在动作描述中加入retries和backoffMs字段让 agent 显式声明重试范围。但最终是否允许重试仍然由 Authority Service 根据策略决定而不是由 agent 单方面决定。5. 审计、追踪与安全边界5.1 审计日志应该记录什么OS authority 只有配合完整审计才有说服力。Archer OS 草案的审计日志不是简单的操作记录而是一条关联链路从 agent 意图到授权请求、授权决策、动作执行、执行结果每一步都要能串联。一个最小审计事件至少包含以下字段字段含义示例值event_id事件唯一标识evt_9F2Aaction_id关联的动作标识act_20260101_001agent_id发起 agent 标识agent_user_mail_01request_id授权请求标识req_01ED2G4Ydecision授权决策allow / deny / consentpolicy_id命中的策略标识policy_mail_readoperation操作类型readtarget_app目标应用com.example.mailresult执行结果success / failed / revokedreason拒绝或失败原因no_policy_matchestimestamp事件时间2026-01-01T10:00:01Z有了这些字段事后排查时可以从一个action_id查整个链路也可以从agent_id汇总某个 agent 的全部行为。日志字段一定是结构化数据不能是自然语言长文本否则检索和分析都会很困难。5.2 日志的可信性和完整性审计日志如果可以被 agent 或应用随意修改就没有审计价值。Archer OS 草案应该设计日志写入通道使 Agent Runtime 没有权限删除或篡改 Audit Log。一个可行的方式是把 Audit Log 作为系统服务运行所有事件统一由 Linux audit、Windows ETW 或 macOS unified log 这类系统日志框架转发。对于高风险环境可以引入哈希链。每条日志在写入时包含上一条日志的事件 ID 和哈希值形成链式结构。任何中间修改都会导致哈希不匹配。生产环境不一定每一步都需要但至少对敏感操作例如发送邮件、删除文件、修改系统设置应启用完整性校验。日志还需要考虑隐私。Archer OS 的审计日志中不应记录完整的邮件正文、密码、密钥。它应该记录“发生了什么操作、针对什么资源、结果如何”而不是复制所有业务数据。如果需要内容级审计应单独设计脱敏规则避免审计日志成为新的数据泄露面。5.3 安全边界与敏感操作分级安全边界设计决定了 OS authority 能在多大范围内管控 AI agent。Archer OS 草案可以按风险等级把操作分为三档低风险读取非敏感信息、搜索、浏览。一般可以自动授权。中风险读写普通业务数据如修改日程、填写表单。可以自动授权但需要记录完整审计。高风险发送邮件、删除文件、转账、修改系统配置。必须用户确认且建议额外校验。风险分级不能只靠动作名称猜测还需要结合资源敏感度。同样是read操作读取日历和读取密码文件完全不同。因此安全边界要同时考虑操作类型和资源类型。应用在接入 Archer OS 时应当声明自己的资源敏感度。如果资源未声明系统默认按高风险处理。这个原则可以避免“新接入的应用没有权限定义反而获得最大权限”的漏洞。5.4 异常行为识别审计日志不仅能做事后追踪还能用于事前识别。Archer OS 草案可以在 Authority Service 中集成异常检测规则。常见的异常模式包括短时间内请求大量不同权限。同一 agent 反复触发用户确认用户拒绝后仍继续申请。动作目标频繁变化例如从邮件切换到文件系统。请求时间集中在非活跃时段。agent 尝试访问与当前任务上下文无关的资源。异常检测不应该直接阻断所有可疑行为而是与动态授权结合。例如检测到异常后把后续操作全部改为 PENDING_CONSENT强制人工确认或者限制 agent 的每分钟请求数。这种“软降级”比直接拒绝更容易落地用户体验也更好。6. 从草案到落地实现路线与最佳实践6.1 最小可行草案的边界Archer OS 如果作为真实项目推进不要一开始就实现所有组件。更合理的做法是先限定一个最小可行范围把核心链路跑通再逐步扩展。最小可行草案可以这样定义只支持一个操作系统平台比如 Linux 或 Windows。只支持一个目标应用比如桌面邮件客户端。只支持两个最小原语read和execute。权限策略使用本地 YAML 文件管理不支持多用户中心。审计日志写入本地文件不接远程日志系统。这样的范围足以验证最核心的假设agent 能否在不直接持有应用凭据的情况下通过 OS 授权完成一次真实操作。如果这一步跑不通讨论更多功能都没有意义。最小草案的关键交付物是一个可演示的 demo 和一个可阅读的 draft spec 文档而不是一个庞大的平台。开发顺序上建议先做 Authority Service 和策略引擎因为它决定了 permission model 是否可靠再做 App Interface因为操作系统操作应用的实现难度最大最后再做 Agent Runtime 和审计集成因为这两部分依赖前两者提供的稳定接口。6.2 学习环境与生产环境的差异很多团队在开发 AI agent 时会先在本地环境跑通然后直接推到生产。Archer OS 这种系统级权限设计最容易在这里出问题。学习环境和生产环境在权限管理上的差异非常大。维度学习环境生产环境权限配置本地 YAML可快速修改集中管理变更需审批Agent 身份固定调试 ID绑定代码哈希和证书用户确认可选择跳过敏感操作必须确认审计日志本地输出远程收集完整性校验目标应用测试应用或模拟器真实业务应用故障恢复重新执行即可需要回滚和补偿生产环境还面临一个特殊问题agent 的错误操作可能已经对真实数据产生了影响。因此在生产环境落地 OS authority 时至少要提前设计“操作回滚”或“补偿动作”。如果某个动作是删除邮件即使 OS 授权记录完整仍然无法恢复已经删除的邮件。Archer OS 草案应当把这种不可逆操作单独定义为高风险并支持配置二次确认或延迟执行。6.3 落地前检查清单一个可复用的检查清单比单独的架构建议更有价值。Archer OS 或类似系统的发布前检查可以包含以下内容是否已为每个 agent 绑定唯一身份并能校验运行文件哈希。默认策略是否为“拒绝”而不是“允许”。是否每个动作都能关联到一条策略或一个用户确认记录。是否已经覆盖高风险动作的二次确认机制。是否已经实现授权撤销接口并能在用户界面一键触发。审计日志是否包含请求 ID、动作 ID、策略 ID 和结果。是否已经限制 agent 对敏感资源的写入操作。是否已经处理动作重试的安全上限。是否已经明确“授权过期”后的行为。是否已经规划操作失败后的补偿流程。这条清单适用于任何“让 AI agent 操作真实应用”的项目。即使不用 Archer OS 这个名字也应该在架构评审时逐项检查。6.4 扩展方向Archer OS 草案的扩展空间很大。第一个方向是跨平台统一协议。Windows、macOS、Linux 的系统 API 不同但动作原语可以统一。只要有统一协议上层 agent 就能像调用远程 API 一样调用 OS 操作能力。第二个方向是多 agent 协作。多个 agent 同时操作同一个应用时需要基于 OS 层的锁和权限隔离避免两个 agent 抢同一个窗口。第三个方向是策略可视化。普通用户无法直接编写 YAML 策略需要图形化授权界面。第四个方向是策略自动推荐。系统可以根据历史用户授权行为推荐更合理的策略但要防止推荐过度扩大权限。这些扩展方向不应该在 v1 里全部实现。Archer OS 的核心价值永远是“权限可控 行为可审计”在此基础上加功能才有意义。7. 常见问题与排查思路7.1 权限策略未生效现象是管理员已经配置了策略但 agent 仍然拒绝或仍然放行不符合策略的操作。遇到这类问题先检查策略匹配顺序。Archer OS 策略引擎如果有多条策略需要明确优先级。比如“用户策略”和“全局策略”冲突时以谁为准。建议在策略文件中显式声明priority字段避免隐式覆盖。其次检查conditions时间窗口、设备状态等条件不满足也会导致策略失效。最后检查 agent 身份确认请求里的agentId与策略中的subject完全一致大小写、空格差异都很常见。排查链路可以按顺序执行查看授权请求日志确认命中的策略 ID如果显示no_policy_matches说明策略未匹配如果显示DENIED但原因不明确查看reason字段。任何策略修改后都要先在测试环境用最小请求验证不要直接改动生产策略。7.2 Agent 找不到目标应用现象是动作授权通过但执行时报target_not_found或window_not_found。首先确认目标应用是否真的在运行并且窗口是否处于可访问状态。某些应用启动时窗口未加载完成需要等待。其次确认 App Interface 的实现是否覆盖该应用的 UI 框架例如基于 Electron 的应用和原生 Win32 应用的定位方式不同。然后检查动作描述中的windowTitle是否与实际完全一致标题中的空格、特殊字符会导致匹配失败。还有一个容易忽略的原因是权限隔离。如果 Agent Runtime 运行在沙箱中而目标应用运行在另一个会话中窗口句柄可能不可见。Archer OS 草案中应该要求 Agent Runtime 和 App Interface 在同一会话或同一安全域内运行否则需要额外授权才能跨会话操作。7.3 授权通过但动作超时现象是系统已经返回 GRANTED但动作执行超过timeoutMs最后被判定超时。先看目标应用是否无响应。如果应用主线程阻塞系统 API 调用无法返回。再看动作是否被应用弹窗阻断例如应用弹出了一个权限对话框导致点击目标被覆盖。Archer OS 的 App Interface 应当在执行前检查当前前台窗口如果前台窗口与应用目标不一致应返回state_changed而不是继续执行。超时重试要结合失败类型避免无限重试。排查时优先查看审计事件中的result字段。如果resulttimeout记录中应当包含timeoutMs和执行阶段如果是resultfailed需要看错误码定位是哪个系统调用失败。不要只依赖 agent 侧日志因为 agent 可能看不到 OS 层的最终状态。7.4 审计日志不完整现象是动作已经执行但 Audit Log 只有授权记录没有执行结果记录或者两条记录无法关联。最常见原因是写入日志的通道在动作执行后中断。为了防止这个问题Archer OS 应当要求 Agent Runtime 在动作执行完成后主动上报执行结果并附带actionId和requestId。App Interface 也必须把底层系统错误码转换为标准错误码确保日志能够描述失败原因。如果日志仍然缺失要检查是否为异步写入确认日志未因进程崩溃而丢失。审计日志完整性在 draft spec 中应该定义为硬性要求只要授权已发放就必须有对应的最终状态记录。即使进程崩溃也要通过系统侧的“悬挂授权”扫描发现未完成动作并在恢复后生成异常审计事件。8. 对 Archer OS 草案最关键的几点判断如果要把 Archer OS 这个思路落到实处真正重要的不是新增多少炫酷功能而是守住三条底线。第一权限裁决必须集中在操作系统层。Agent 可以聪明但它不能掌握自己的权限审批权。所有动作请求都必须经过 Authority Service而且默认拒绝。这是整个架构的安全基石。第二动作描述与系统执行之间必须有语义校验。Agent 决定“做什么”操作系统确认“是否能做”App Interface 负责“如何做”。三者不能混为一谈否则 agent 可以直接通过某个系统接口跳过策略OS authority 就失去了意义。第三审计链路必须从一开始就设计而不是后补。没有审计的权限系统等于没有刹车。Archer OS 草案应该在第一个 demo 里就支持从requestId查到完整执行链路这样后续每增加一个功能安全性都能被验证。Archer OS 的价值不在于定义了一套新协议而在于它提出了一个正确的判断AI agents 操作 apps本质上是在操作系统资源。只要还在操作资源就必须受 OS 权限约束。这个判断比任何具体代码都重要它决定了后续所有设计的方向。