--- title: "人机权限与能力对等：为什么我们需要为 AI Agent 重新构建软件系统的原生接口？" subtitle: "告别“模拟点击屏幕的二等公民”与“绕过鉴权的裸奔脚本”：以“AI 的权限 = 用户的权限”为第一公理，在单一领域内核上构建面向人与智能体协作的对偶基础设施。" author: "Hui Zhao (@0xSynapse, Heurion Research)" date: "2026-11-03" canonical_url: "https://heurion.org/blog/human-agent-capability-parity-ai-native-software" alternate_language_url: "https://heurion.org/en/blog/human-agent-capability-parity-ai-native-software" code_repository: "https://github.com/heurion-org/heurion" paper_preprint: "https://github.com/heurion-org/heurion/blob/main/paper/main.pdf" --- # 人机权限与能力对等：为什么我们需要为 AI Agent 重新构建软件系统的原生接口？ > **告别“模拟点击屏幕的二等公民”与“绕过鉴权的裸奔脚本”：以“AI 的权限 = 用户的权限”为第一公理，在单一领域内核上构建面向人与智能体协作的对偶基础设施。** > > **Executive Summary**: 过去的软件系统只为单一主体——操作图形界面（GUI）的人类——而设计。当自治智能体进入工作流时，传统软件迫使 AI 要么退化为缓慢脆弱的“屏幕点击爬虫”，要么异化为绕过业务鉴权的“特权脚本”。本文阐述为什么我们需要为更好的人机协作重新构建软件系统：通过“AI 的权限 = 用户的权限”与“每个界面能力必有对应原生工具”的对等公理、进程内零分叉同源调用、高风险操作确认卡门控以及编译期全路由反射不变量，构建真正面向人机共生的一等基础设施。 ## 01. 为什么传统软件无法支撑真正的人机协作？ 过去四十年的应用软件工程，建立在一个从未被质疑过的隐含前提之上：**软件唯一的交互主体是坐在屏幕前、手握鼠标与键盘的人类**。因此，大量业务逻辑、状态校验与权限边界被耦合在图形界面（GUI）的视图层、表单状态与点击事件里。 当具备长程规划能力的 AI Agent 成为知识工作的新主体时，试图在传统软件之上嫁接智能体的团队，几乎都会撞上两种畸形的工程妥协： - **妥协一：把 Agent 当成“模拟人类点屏幕的二等公民”（GUI / DOM 爬虫范式）**。因为软件没有给 AI 留出原生语义接口，只能让多模态模型不断截屏、识别像素坐标或解析脆弱的前端 DOM 树去模拟鼠标点击（Computer Use / Browser Automation）。这种范式不仅比原生调用慢两个数量级、消耗高昂的视觉 Token，而且极其脆弱——前端样式的一次常规微调或弹窗遮挡就会让整条自动化链路崩溃。 - **妥协二：把 Agent 当成“绕过应用层的后门脚本”（特权工具函数范式）**。另一种做法是在后端单独为 AI 写几个直连数据库或文件系统的工具函数。结果往往走向两个极端：要么工程师因为害怕 AI 闯祸，只敢开放三五个只读查询工具，让 Agent 沦为旁观式的聊天气泡；要么工具函数绕过了原本为人类精心设计的角色权限（RBAC）、多租户隔离与业务状态机，导致越权读写与无法追责的静默破坏。 > **重新构建软件系统的根本理由**: 理由其实非常简单：**如果未来的科研与工程是由人类与 AI 共同完成的，我们就不能继续在“仅属于人类的软件外壳”上打补丁，而必须重新构建软件系统——为人类提供直觉化的视觉交互界面，同时为 AI Agent 构建一等公民的原生结构化接口（AI-Native Interfaces），并让两者共享同一套权限、状态与审计基础设施。** ## 02. 第一设计公理：AI 的权限 = 用户的权限，人类的能力 = AI 的能力 在重新设计面向人机共生的软件底座时，我们确立了一条极其简单却贯穿全局的架构准则——**人机能力与权限对等公理（Capability & Permission Parity Axiom）**： - **能力对等（Capability Parity）**：凡是人类用户在界面上能够完成的操作——无论是新建与管理项目、精细编辑文档与幻灯片、检索与维护知识库、清洗数据集并运行统计检验，还是管理机构成员与模板——AI 都必须拥有**语义完全等价的原生结构化工具（MCP Primitives）**。AI 不需要“看屏幕猜按钮”，而是直接通过高信噪比的类型化契约操作领域对象。 - **权限同源（Permission Identity：AI 的权限 = 当前用户的权限）**：AI 在系统中绝不是一个拥有全局特权的“超级管理员幽灵账号”，也不是一个权限残缺的外部访客。**AI 严格以当前登录用户的身份、按当前用户的角色行事**：用户在界面上能访问和修改的资源，其 AI 都能通过原生接口操作；用户无权访问的其他课题组数据或管理功能，其 AI 同样在内核层被严格拒绝。普通成员的 AI 协助个人研究，机构管理员的 AI 则天然具备协助管理机构的能力。 > **[Diagram]** 图 1：面向人机协作的双生接口架构——人类 GUI 与 AI 原生工具在底层汇入同一个零分叉权限与业务内核。 ## 03. 零分叉同源内核：进程内回环调用与双轨溯源审计 在工程落地上，如何保证“AI 的权限与人类的权限永远保持 100% 一致，且绝不随代码演进而发生漂移”？ 如果为 AI 的工具单独编写一套权限判断与数据库读写逻辑，只要系统迭代超过三个月，人类接口与 AI 接口的鉴权规则就必然会出现分叉（Permission Drift）。为此，我们在内核中采用了**零分叉进程内同源回环（Zero-Fork In-Process Loopback Invocation）**设计： > **[Diagram]** 图 2：零分叉进程内同源回环流水线——MCP 工具通过内存瞬态密钥直调统一路由内核，与人类共享 100% 鉴权逻辑并输出双轨溯源审计。 - **绝不编写第二套权限代码**：所有的管理类与业务类 AI 原生工具本身不包含任何独立的数据库修改或权限分支，而是将结构化参数映射为对应的标准内部路由请求，交由进程内调用器直接投递给同一个核心应用实例处理。 - **防伪造进程内瞬态密钥（Ephemeral In-Memory Secret）**：进程内调用器在转发请求时，会自动注入一个每次服务启动时在内存中随机生成的 256-bit 瞬态密钥（不落盘、不出进程），并通过恒定时间比对（`timingSafeEqual`）校验。任何来自外部网络的请求一旦试图伪造内部委托头，都会被无条件识别为未授权伪造并拦截。 - **细粒度人机双轨审计（Dual-Track Provenance Audit）**：因为人机共用同一套业务管道，每一次状态变更都会自动落入统一的不可篡改审计日志，并同时记录操作主体 `actor`、触发通道 `via`（`human` / `ai` / `ai-confirmed`）与确认人 `confirmed_by`。 ``` // 零分叉进程内同源调用伪代码 RAM_SECRET = randomBytes(32) // 进程启动时于内存生成，永不落盘或出网 function invokeAsUser(currentUser, method, routePath, payload, via = "ai", confirmedBy = null): headers = { "x-internal-secret": RAM_SECRET, "x-act-as": currentUser, "x-via": via, "x-confirmed-by": confirmedBy } return app.request(routePath, { method, headers, body: payload }) // 进程内直调同一个路由与鉴权内核 ``` ## 04. 权责边界的三分法：自主执行、确认卡门控与人类专属主权 “AI 拥有与用户对等的能力接口”绝不意味着让 AI 在高风险操作上替人类做主。为了让人类在与 AI 高效协作的同时始终手握最终控制权，我们将全部系统接口划分为三个界限分明的治理层级： > **[Diagram]** 图 3：人机权责边界的三分法——日常可逆操作全速自主执行，高风险操作经确认卡门控，主权与终审操作严守人类底线。 - **第一层：可逆日常操作 → AI 直接自主执行（`via = ai`）**。包括文稿起草、数据统计、知识库检索、文档重命名、移入回收站（可随时恢复）以及版本保存。由于底层有 CRDT 靶向回滚与回收站兜底，AI 可以零打扰地全速推进工作。 - **第二层：高风险与不可逆操作 → AI 发起提案 + 人类确认卡门控（`via = ai-confirmed`）**。涵盖三个高敏类别：**不可恢复的物理删除（如清空回收站、删除数据集）**、**权限与安全边界变更（如修改机构设置、变更成员角色、项目所有权移交）**以及**对外机构标识变更**。当用户让 AI 执行此类任务时： AI 调用对应的原生工具后，内核首先校验**当前用户本身是否具备该权限**（若无权限则直接返回 `Forbidden`，绝不生成骚扰卡片），并探测目标资源是否真实存在； - 校验通过后，系统在 `pending_actions` 表中生成一条有效期 24 小时的待确认记录（包含目标接口、结构化参数、AI 给出的执行理由以及供用户微调的可编辑字段），向当前对话流与全局顶栏推送一张**确认卡（Confirmation Card）**； - **防自批铁律（Anti-Self-Approval Guard）**：确认与拒绝接口（`POST /api/actions/:id/confirm`）只接受人类用户本人的真实浏览器登录会话——任何来自 AI 进程内调用的请求一律返回 `403 Forbidden`，其他用户调用返回 `404`。用户点击确认后，系统才以 `via = ai-confirmed` 真正执行该操作。 - **第三层：人类专属主权（`NOT_FOR_AI` 显式登记表）**。有四类操作在哲学与安全上永远只属于人类本人： **对 AI 产出的终审与表决权**：采纳或拒绝 AI 的文档修改建议、批准 AI 自己发起的确认卡、移除约束 AI 自身的自适应避坑规则、以及最终成果定稿签发（**AI 绝不能当自己提议的裁判**）； - **领域真实性核验**：例如AI 可以从原始资料中自动提取并导入候选研究变量（标记为“未核实”），但将变量状态切换为“已核实（Verified）”必须由研究者本人完成； - **身份凭证与密钥操作**：登录、注册、密码重置、验证码核验； - **纯界面传输流**：仅供浏览器渲染消费的 SSE 事件流或原始二进制流（AI 已具备对应的结构化读取原语）。 ### 4.1 为什么“AI 申请权限的过程”本身必须与执行结果同样可审计？ 在传统软件审计中，系统往往只记录“最终成功落库的写操作”。但在人机共治系统中，**“AI 申请了什么权限、基于什么理由申请、人类最终批准还是驳回”这一申请过程本身的可审计性（Auditability of Permission Requests），与最终执行结果同样关键**： - **告别“弹窗点完即焚”的审计黑洞**：许多本地 Agent 工具依赖一次性模态弹窗（“Allow command?”）请求权限，用户随手点击后弹窗即刻消失，事后既无法追溯 AI 当时传入的完整参数，也无法复盘是否存在诱导性提权（Prompt Injection Escalation）。 - **全生命周期留痕（含未获批与越权拦截）**：在我们的内核中，AI 发起的每一次高敏权限申请都会作为一等公民持久化，完整记录**代理主体（`actor`）**、**目标接口与参数快照（`method + path + params`）**、**AI 声明的申请理由（`reason`）**以及**最终裁决状态（`approved` / `rejected` / `expired` / `rbac_denied`）与审批人（`confirmed_by`）**。即便某次权限申请被人类驳回或因越权被内核直接拦截，安全团队依然能通过审计链清晰复盘智能体的每一次边界试探。 ## 05. 用反射测试锁死契约：全路由对等性不变量 在多人协作演进的大型软件系统中，口头倡导“为 AI 构建原生接口”极易退化——当工程师为了赶进度在前端加了一个新按钮和新 HTTP 路由，却忘记同步注册 MCP 工具时，人机对等性就会出现裂缝。 为了将“人机能力与权限对等”上升为不可违背的系统级定律，我们在持续集成流水线中植入了一条**全路由对等性反射不变量（Route-to-Tool Parity Invariant）**： > **[Diagram]** 图 4：全路由对等性反射不变量——在 CI 阶段自动枚举全部路由并执行四条双射断言，从根本上杜绝新增功能遗漏 AI 原生接口。 ``` // 全路由对等性反射不变量伪代码 (CI 门禁) for each route in app.enumerateAllRoutes(): assert (route in MCP_TOOL_MAP) XOR (route in NOT_FOR_AI_REASONS) // 必配原生工具或显式写明豁免理由 if route in MCP_TOOL_MAP: assert resolveToolAction(MCP_TOOL_MAP[route]).matches(route) // 校验工具底层调用路径与路由严格吻合 assert collectToolsWhere(confirm == true) == AI_CONFIRM_REGISTRY // 高风险确认卡清单 100% 闭合 ``` ### 5.1 三代软件人机交互范式对比 | 架构维度 (Dimension) | 传统 GUI 中心软件 | 屏幕爬虫式 Agent (GUI Automation) | Heurion 双生接口对等架构 | | AI 的交互介质 | 无（或仅有零星只读接口） | 像素截图 + 模拟鼠标点击 / DOM 解析 | **100% 路由对等的类型化 MCP 原生工具** | | 单步操作延迟与 Token 开销 | N/A | 2,000–8,000 ms / 海量视觉 Token | **<5 ms 进程内同源调用 / 极简 JSON** | | 权限与多租户安全模型 | 仅校验人类会话 | 极易因共享浏览器会话误触越权操作 | **AI 权限 = 用户权限（零分叉同源鉴权）** | | 高风险不可逆操作保护 | 前端二次弹窗确认 | AI 可直接模拟点击“确定”按钮绕过 | **内核级确认卡门控（AI 自批硬拒绝 403）** | | 操作溯源与合规审计 | 仅记录用户 ID | 与人类鼠标点击混同，无法区分人机 | **双轨审计（`via: human | ai | ai-confirmed`）** | 当我们不再把 AI Agent 视为粘贴在传统软件表面的“外挂插件”，而是从第一行架构契约起就为人类与 Agent 构建对等的双生接口与同源权限内核时，软件系统才真正完成了向**人机共生基础设施**的代际演进。 ## 核心技术问答 (Technical FAQ) ### Q: 什么是 AI 原生软件的“人机同权公理（Capability & Permission Parity Axiom）”？ 人机同权公理包含两条硬性约束：(1) 能力同权（Agent Capability = User Capability），即人类在 GUI 能完成的每一项操作都有 1:1 对应的结构化 MCP 工具，消除脆弱的 DOM 屏幕抓取；(2) 权限同权（Agent Permission = User Permission），即智能体通过进程内 256-bit 环回内核完全继承当前人类用户的租户身份与 RBAC 边界，绝不允许走高权限 Service Role 数据库后门。 ### Q: 为什么“AI 申请权限的过程”本身必须与最终执行结果同样可审计？ 如果系统只记录已批准的操作而不记录权限申请全过程，被提示词注入劫持的智能体就可以静默探测敏感边界、伪造模糊申请理由或高频轰炸诱导疲劳误批。Heurion 与 Aegis OS 将每一次权限申请建模为一等不可变审计事件（记录触发工具上下文、结构化理由、风险分级与审批耗时），并在协议层硬性拦截智能体自批（HTTP 403 Anti-Self-Approval Guard）。