鑫EN

Rethinking the Interface

从操作界面到行动权架构

时间
2026.08.01

Interface 与 User Interface

今天，当人们谈论 UI，通常想到的是颜色、字体、图标、布局和组件，或者一个名为“UI 设计师”的职位。User Interface 逐渐被等同于 Graphical User Interface，后者又被进一步等同于 Figma 上的视觉稿。

但如果回到 interface 的本义，界面从来不只是一块可见的“面”。

Interface 的本质是一种关系。

它存在于两个内部结构不同的系统之间，使双方不必理解彼此的全部复杂性，也能发生连接、交换与协作。它既是一个经过组织的边界，也是在边界两侧生效的一组表示、映射和协议。

interface 在代码中仍然保留着它更原本的含义。例如，在 TypeScript 中可以定义：

interface PaymentService {
  preview(request: PaymentRequest): Promise<PaymentPreview>;
  execute(request: PaymentRequest): Promise<PaymentResult>;
  refund(paymentId: string): Promise<RefundResult>;
}

这个 interface 不是一个可见的表面，也不负责规定按钮应该放在哪里。它定义的是一个组件对外承诺提供什么能力、调用者需要传入什么，以及可以预期获得什么结果。

调用方不需要知道支付服务内部连接了哪家银行、如何保存交易记录，或者退款经过多少个内部步骤；实现方也不需要知道调用者最终是网页、移动应用、自动化脚本还是 Agent。双方依赖同一份契约发生协作，同时保持各自内部结构的独立。

一个 interface 至少包含四件事：

  • 边界：哪些能力属于系统内部，哪些可以被外部访问；
  • 抽象：系统以什么可理解、可操作的模型呈现自身；
  • 协议：什么输入是合法的，输入意味着什么，系统会如何响应；
  • 反馈：行动是否被接收，状态如何变化，失败后如何恢复。

因此，interface 并不是静态物体，而是一个持续运行的闭环：

输入 → 状态变化 → 输出 → 判断 → 再次输入

按钮、表单和页面只是这个闭环在图形媒介上的表现。真正被设计的，是边界两侧如何彼此理解、彼此作用，以及如何确认作用已经生效。

而 User Interface 是 interface 的一个特例：它连接人和计算系统。

一侧是人。人拥有目标，却不一定能准确表达；人依赖感知、经验和记忆，会犹豫、误解和犯错，也需要掌控感与安全感。

另一侧是计算系统。系统依赖明确输入，按照规则改变状态，拥有数据、权限、异常和大量对用户不可见的内部过程。

UI 的核心工作，是在两种截然不同的世界之间进行双向翻译：

把人的意图翻译成系统可以执行的操作； 把系统的状态翻译成人能够感知和理解的信息。

所以，一个按钮的真正设计问题并不只是颜色、圆角和阴影，而是：

  • 用户是否理解它代表什么；
  • 此刻是否可以执行；
  • 执行会影响哪些对象；
  • 系统是否已经接收操作；
  • 操作需要多长时间；
  • 失败时会发生什么；
  • 结果能否撤销；
  • 谁拥有执行权限；
  • 谁需要为后果负责。

屏幕只是 UI 最常见的载体，而不是 UI 的本体。命令行、语音、提示音和震动都可以构成 User Interface；在更广义的人造物界面中，方向盘和门把手也承担着类似的翻译与反馈作用。页面也只是 interface 在某一时刻的截图；完整的 UI 存在于时间之中，包含状态变化、等待、反馈、错误、恢复、权限和历史。

UI 还是产品内部模型的外显。项目、任务、负责人、状态、优先级和截止日期，看似是页面上的字段，实质上是系统对“工作”这件事的定义。数据模型、权限模型、业务规则和状态机，最终都会通过 UI 被用户感知。

因此，很多所谓的“体验问题”并不是页面画得不好，而是系统模型与人的认知模型无法对应。

更进一步，interface 从来不是中立的。它决定什么可以被看见，什么被隐藏；什么容易完成，什么被刻意增加阻力；谁能行动，谁只能观看；什么默认发生；什么可以撤销；系统犯错时由谁承担损失。

UI 是产品的一种属性，不是设计部门的一种产物。

User Interface 简史

在早期的批处理计算中，人们通过打孔卡、纸带、作业说明和操作员向计算机提交任务，等待系统运行后再取得结果。人与计算机之间当然存在 interface，但它由输入介质、程序语言、操作规程和组织流程共同组成。交互并不实时，反馈也可能在数小时之后才出现。

20 世纪 60 年代，分时系统和交互式终端逐渐让人能够直接与正在运行的计算机对话。键盘输入一条命令，系统返回一段文本，使用者再根据结果输入下一条命令。由此形成了后来被称为 Command-Line Interface（CLI）的交互范式：

User intention
→ symbolic command
→ system execution
→ textual response
→ next command

CLI 把人机关系变成了一个高频、持续的反馈循环。它以语言作为抽象层：人不必直接操作内存、线路和设备，只需要学习一组命令、参数和组合规则。

这种 interface 具有很强的表达力。命令可以组合、重复、保存和自动化；同一个动作既能由人输入，也能被脚本调用；操作过程还会自然形成一份文本记录。

但它也要求使用者记住命令名称、语法、对象路径和系统状态。系统“能够做什么”通常不会主动显现，而是隐藏在手册和人的记忆里。

CLI 的基本关系可以概括为：

人用系统规定的语言描述动作。

与此同时，另一条人机交互路线正在形成。

1963 年，Ivan Sutherland 的 Sketchpad 已经允许使用者借助光笔直接创建和操纵屏幕上的图形。1968 年，Douglas Engelbart 团队在后来被称为“演示之母”的展示中呈现了鼠标、窗口、超文本和协作文档等交互方式。

1973 年设计的 Xerox Alto 把位图显示器、鼠标、窗口、菜单和直接操作结合到一台个人工作站中。随后，Xerox Star、Apple Lisa，以及 1984 年的 Macintosh 逐步将图形化交互从研究环境带向商业产品和更广泛的使用者。

Graphical User Interface（GUI）不只是给命令增加了图标。它改变了系统向人呈现自身的方式：

CLI
输入符号 → 调用能力 → 阅读结果

GUI
看见对象 → 直接选择和操作 → 观察对象变化

在 CLI 中，文件主要通过名称和路径被引用；在 GUI 中，它可以表现为一个能够被选择、拖动和放进文件夹的图标。

在 CLI 中，使用者需要回忆命令；在 GUI 中，可用动作可以通过菜单、按钮和控件被识别。

在 CLI 中，系统更像一种需要掌握的语言；在 GUI 中，系统更像一个由对象、空间和操作规则组成的可见世界。

这意味着，CLI 与 GUI 的根本差异不只是文本与图形的差异，还在于交互复杂度在人与系统之间的分配方式。

CLI 提供的是一套精简而强大的符号接口。系统不需要主动展示全部能力，也不需要把每种状态和操作都转化成可见控件；相应地，人需要承担更多工作：

  • 记住存在哪些命令；
  • 记住命令名称、参数和组合语法；
  • 在头脑中维持对象、路径和当前状态；
  • 把目标分解成一连串正确操作；
  • 从文本结果和错误中判断下一步。

在这种关系中，系统提供语言，人负责理解这套语言背后的世界。许多交互复杂度存在于人的记忆、经验和心理模型里。

GUI 则由系统承担更多翻译工作。系统需要把可用对象、合法动作、当前状态、参数范围和操作结果外化出来：

  • 文件被表现为图标；
  • 层级被表现为文件夹和窗口；
  • 可用能力被表现为菜单、按钮和控件；
  • 参数约束被表现为选项、范围、禁用状态和校验；
  • 执行过程被表现为选中、加载、进度和动画；
  • 错误与恢复路径被表现为提示、撤销和回滚入口。

因此，CLI 更多依赖 recall（回忆），GUI 更多依赖 recognition（识别）。CLI 要求人适应系统规定的语言，GUI 则要求系统把自身翻译成人可以感知和操作的世界。

CLI
系统提供命令语言
→ 人记忆能力与规则
→ 人构造系统模型
→ 人规划并输入操作

GUI
系统构造可见模型
→ 系统呈现对象、状态与可用动作
→ 人识别并直接操作
→ 系统约束行为并提供反馈

但这并不意味着 CLI 把系统的全部复杂度交给人，也不意味着 GUI 把系统的全部复杂度展示出来。

命令本身已经是一种抽象，它隐藏了硬件、进程和内部实现；GUI 呈现的也不是系统真实结构，而是经过选择、压缩和翻译的操作模型。优秀的 GUI 不是完整暴露复杂度，而是由系统承担表示、约束和反馈的成本，使人不必在头脑中独自维持这些复杂度。

复杂度没有简单消失。领域中无法消除的复杂度，会在人、界面和系统之间被重新分配：

有些由人记忆，有些由界面表达，有些由系统处理，还有一些被隐藏，直到例外和错误发生。

GUI 的发展可以被理解为一次复杂度责任的转移：系统实现和界面设计变得更加复杂，以换取人的学习、记忆和操作成本降低。

但 GUI 的成功也带来了一个概念上的副作用：

Interface 从一种关系，被重新想象成了屏幕上的表面。

随着个人计算机、桌面软件、Web 和移动应用成为大多数人接触计算系统的主要方式，GUI 几乎垄断了人们对 UI 的日常想象。页面和控件最容易被看见、截图、评审和交付；能力边界、状态机、权限、错误和反馈协议则退到视觉表面之后。

久而久之，User Interface 逐渐被等同于 GUI，GUI 又被进一步等同于视觉表现。一个描述人和系统关系的概念，逐渐变成了某种可见产物和职业分工。

实际上，CLI 与 GUI 并不是前后替代的两个阶段，而是两种长期并存的 interface：

  • CLI 将系统能力组织成可调用、可组合的语言；
  • GUI 将系统状态组织成可感知、可直接操作的对象。

GUI 更适合发现、比较、空间组织和连续反馈；CLI 更适合精确表达、重复执行、批量处理和自动化。开发、运维和基础设施领域从未真正离开 CLI。

这段历史真正揭示的，并不是图形取代了命令，而是系统如何通过不同的抽象，把自身能力变成人能够理解和使用的形式，以及交互中的复杂度由谁承担。批处理依赖程序、介质和组织流程预先安排工作；CLI 把实时控制交给人，也要求人记忆语言、维持状态和规划步骤；GUI 则让系统承担更多表示、约束与反馈，以降低人的操作成本。也正是在这个过程中，UI 原本更广阔的含义被它最成功的载体遮蔽了。

每一种 interface 都在回答同一个问题：

为了让行动发生，哪些复杂度由人承担，哪些由系统承担，哪些被界面吸收？

Agent 的出现，将再次改变这个分配方式。

浮现中的交互三角

在传统软件产品的界面设计中，交互通常被建模为用户与系统之间的二元闭环：

Human ↔ System

用户表达意图，系统接收输入、改变状态并提供反馈。系统内部即使存在大量自动化，对用户而言，它们通常仍被封装在一个统一的“系统”之中，用户是主要的决策者和操作主体。

自动化和软件代理并不是新现象。真正的变化在于，Agent 开始以一个可被委托、能够形成计划并作用于真实系统的显式行动者出现在产品中。此时，原来的二元模型就不再足以描述完整的协作关系。

Agent 不只是 UI 里的一个新控件，也不只是一个更聪明的搜索框。它是一个被授予有限感知、判断和行动能力的代理者：可以理解目标、形成计划、选择工具、执行多步操作，并在过程中改变真实系统的状态。

过去由使用者承担的一部分工作——发现能力、记忆操作语言、分解目标、组织步骤、根据反馈决定下一步——现在可以转交给 Agent。人不再需要亲自规定每个动作，而是开始规定目标、边界与判断条件。

复杂度因此没有消失。它从人的操作过程，转移到 Agent 的理解与执行，也转移到系统对 Agent 的能力表达，以及人对整个过程的授权、监督和核验之中。

因此，有必要把原本封装在“系统”内部的代理能力显式分离出来，将产品中的协作关系建模为一个交互三角：

委托、指导、确认 核验、接管、恢复 观察、工具、行动状态与错误 Human目标与责任主体 Agent System / Environment

这个三角包含三条都需要被设计的边：

  1. Human ↔ Agent：人如何表达目标、约束和授权，Agent 如何解释、汇报和请求判断；
  2. Agent ↔ System：Agent 如何观察环境、发现能力、调用工具、改变状态并处理错误；
  3. Human ↔ System：人如何独立查看真实状态、核验结果、直接操作、接管和回滚。

这不是一条简单的 User → Agent → System 链。

如果用户只能通过 Agent 接触系统，Agent 就会同时成为唯一的执行者、唯一的解释者，以及唯一告诉用户“事情已经正确完成”的信息来源。人看到的不再是系统事实，而只是 Agent 对系统事实的叙述。

三角模型保留了 Human ↔ System 这条不依赖 Agent 叙述的事实与控制通道。这里的“直接”不是没有界面或中介，而是用户能够读取权威系统状态，独立核验结果，并在必要时直接干预。Agent 不能控制或伪造这条通道，因此它是整个 Agent 系统中的制衡边与安全边。

三条边，三种设计任务

Human ↔ Agent：委托与治理界面

传统 UI 通常要求用户指定“怎么做”：

选择地区 → 选择规格 → 填写名称 → 点击部署

Agent 交互则允许用户表达“要什么”：

在深圳部署一个测试环境，
每月预算不超过 500 元，
不要开放公网，
优先复用已有资源。

用户不再决定每一步动作，而是把目标与一部分行动权交给 Agent。这里真正需要设计的不是聊天框，而是一份逐步形成的“委托契约”：

  • 目标是什么；
  • 哪些是不可违反的硬约束；
  • 哪些只是偏好；
  • Agent 获得了哪些信息和权限；
  • 它准备采取什么计划；
  • 哪些决定可以自主作出；
  • 哪些动作必须经过批准；
  • 如何判断任务已经完成；
  • 用户如何修改、暂停、接管或撤销；
  • 失败与损失最终由谁负责。

因此，Human–Agent Interface 的核心交换物不是文字，而是意图、判断权与行动权。

这条边也不必表现为聊天 GUI。它可以是语音、结构化计划、动态表单、画布、通知、对象操作或多种媒介的组合。自然语言擅长表达模糊目标、背景和例外情况，却不擅长大量比较、精确参数调整、复杂差异审查和持续状态监控。未来更常见的形态，很可能是自然语言负责意图，结构化界面负责计划、证据、审批和控制。

Agent ↔ System：感知与行动界面

Agent 必须把人的抽象目标转化为真实系统中的具体行动。这条边可以称为 Agent–Computer Interface（ACI）、Agent–System Interface，或者更宽泛的 Agent-facing Interface。

Agent 从系统获得：

  • 当前状态和可用对象；
  • 数据、事件和上下文；
  • 能力、权限和限制；
  • 操作结果、进度与错误。

Agent 向系统发出：

  • 查询和命令；
  • 工具调用与 API 请求；
  • 文件、数据和系统状态的修改；
  • 事务、重试、回滚和补偿操作。

因此，这条边的核心交换物是观察与行动。

CLI、API、函数调用和 MCP 都可以构成 ACI，但它们不是 ACI 本身。Agent 也可以通过 DOM、Accessibility Tree、截图、坐标和键鼠操作已有 GUI。更准确地说，Agent–System Interface 是一切使 Agent 能够观察系统状态并作用于系统的界面。

不同媒介各有特点：

  • API / MCP / typed tools：语义和结构明确，通常更可靠；
  • CLI / Shell / code execution：通用、可组合，并且天然留下可读的行动记录；
  • DOM / GUI / computer use：能够覆盖尚未开放结构化接口的系统，但更容易受到界面变化和视觉歧义影响。

CLI 在这里获得了一个与过去不同的位置。

在传统人机交互中，CLI 是人直接操作系统的界面。人需要学习系统规定的语言，亲自把目标翻译成命令。对于 Agent，CLI 则可以成为一种行动接口：Agent 负责理解人的目标、选择命令、组织参数和处理返回结果，CLI 负责把系统能力暴露为可调用、可组合、可记录的操作。

过去
Human → CLI → System

Agent 参与时
Human → Agent → CLI / API / MCP → System

这并不是 CLI 重新取代 GUI，而是同一种 interface 开始服务于新的行动主体。它原本要求人承担的记忆、组合和执行工作，恰好可以成为 Agent 的工作材料；它原本为人提供的表达力、可组合性和文本记录，也变成了 Agent 行动、自动化与审计的基础。

一个糟糕的 Agent Interface 只是把人的页面动作翻译成工具：

click_create_button
select_region_dropdown
fill_instance_name
click_confirm

一个更好的 Agent Interface 会围绕领域意图组织能力：

search_deployment_options
preview_deployment
create_deployment
get_deployment_status
rollback_deployment

前者要求 Agent 模拟人在 GUI 上点击；后者让 Agent 直接操作系统的领域模型。

这与传统 UI 设计其实非常相似。优秀的 UI 不会机械地暴露数据库字段，优秀的 Agent Interface 也不应机械地包装后端 endpoint。两者都要围绕使用者的任务模型重新组织系统能力，只是新的“使用者”是一个概率性的、上下文有限的、可能误解工具语义的 Agent。

Human ↔ System：核验与接管界面

Agent 不会让传统 GUI 消失，但会改变它的角色。

当 Agent 承担越来越多执行工作，GUI 会部分地从“用户亲自完成所有操作的面板”，转变为“用户监督和管理执行者的控制面”：

  • 查看系统的真实状态；
  • 检查 Agent 产生的变更和 diff；
  • 比较方案、成本与后果；
  • 批准高风险动作；
  • 处理异常与冲突；
  • 中断 Agent 或手动接管；
  • 撤销、回滚和恢复；
  • 查看来源、证据和审计记录。

这意味着，GUI 所承担的复杂度也在发生变化。过去，它主要帮助人完成操作；现在，它还需要帮助人理解和治理另一个行动主体。操作步骤减少之后，计划、权限、影响范围、不确定性和执行证据反而需要被更清楚地呈现。

如果 Agent 说“部署已经完成”，用户不应该只能看到一句自然语言结论。一个独立的事实通道还应呈现：

部署状态：成功
实际创建资源：3
预计月费用：¥463
公网 IP：无
操作主体：Agent A
使用权限：deployment.write
可回滚期限：24 小时

“Human in the loop”也不等于在每个步骤前放一个确认弹窗。没有计划、参数、影响范围、当前状态和替代方案，用户就没有足够信息作出有效判断。真正的人类控制必须让人知道将要发生什么、实际发生了什么，以及出现偏差后如何恢复。

这条边的核心交换物，是证据与控制权。

三角中央：共享任务、状态与权限

仅仅分别设计好三条边仍然不够。Human、Agent 和 System 必须围绕同一份任务模型与系统状态协作。

三角中央需要一个共享层：

Shared Task / State / Authority Model 共享任务模型、共享系统状态，以及权限与责任记录。

这个共享层不是一段 Human 和 Agent 同时看到的 context，也不要求双方获得完全相同的信息。对 Agent 来说，context 是当前能够访问的工作集，可能经过选择、压缩，也可能已经过期；对 Human 来说，界面呈现的是为了理解、判断和控制而组织的视图。两者形式不同，但必须指向同一批对象、版本、计划和行动记录。

因此，共享层更接近一套权威的协作状态：它是 Human 与 Agent 各自 context 的共同事实基础，也是系统判断计划、审批和权限是否仍然有效的依据。

它需要保证：

  • 用户看到的对象及版本，就是 Agent 正在操作的对象及版本；
  • Agent 调用工具后，GUI 能反映系统的真实变化；
  • 用户直接修改系统后，Agent 能感知状态已经变化；
  • 审批绑定到具体计划、参数和系统版本；
  • Agent 不能拿着旧授权执行已经发生变化的新操作；
  • 每项行动都能说明是谁执行的、为何执行、改变了什么，以及依据来自哪里；
  • Human 和 Agent 能从同一个检查点继续或恢复。

例如，Agent 提交了一份删除计划：

删除 Project A
包括 3 个服务和 1 个数据库
预计释放费用 ¥700 / 月

用户批准后，如果 Project A 又新增了一个生产数据库，那么原来的批准不应自动覆盖新的系统状态。计划已经过期，系统必须重新预览影响并请求批准。

这类问题既不只是 UX，也不只是 MCP schema 的设计，而是三条边之间的状态一致性、时序一致性与权限一致性。

真正的设计对象是行动权

Agent 系统的三个参与者并不对称。

  • Human 是目标与责任的主体；
  • Agent 是被授予有限权力的代理者；
  • System 是状态、资源和真实后果发生的环境。

行动权不是一次性从 Human 转交给 Agent 的开关。感知、提议、选择、执行、批准、中断和回滚可以分别属于不同主体，并随着任务阶段、风险和系统状态变化而重新分配。一个 Agent 可以被允许搜索和比较，却无权购买；可以创建草稿，却必须由人发布；可以执行已批准的计划，却不能在对象或参数变化后沿用旧授权。

三条边运行在不同频率上：Agent–System 是持续发生的高频执行循环；Human–Agent 是围绕计划、进度和例外展开的中频监督循环；Human–System 则是相对低频但不可缺少的核验、接管与恢复循环。频率不同并不意味着重要性不同，低频的安全边往往决定系统在异常情况下是否仍然可控。

未来最难设计的，可能不是每条边各自的界面，而是三者之间的控制权如何流转：

  • Agent 什么时候必须询问 Human；
  • 什么风险值得打断用户；
  • 一次批准覆盖多大的行动范围；
  • Human 修改系统后，Agent 如何得知上下文已经改变；
  • Agent 失败后，人如何从中间状态继续；
  • 人接管之后，怎样再把任务交还给 Agent；
  • 多个 Agent 同时行动时，谁拥有最新和有效的状态；
  • Agent 从 API 切换到 GUI 后，权限与审计能否保持一致。

所以，Agent 时代真正的设计材料正在从页面、组件和流程，扩展到：

  • Goal / Context：目标如何表达，各方知道什么；
  • Capability / Permission：Agent 能做什么，哪些动作需要授权；
  • Plan / Approval：工作如何分解，什么时候需要人的判断；
  • Agency / Control：谁有权判断、行动、中断和接管；
  • Uncertainty / Evidence：不确定性如何呈现，结论如何被证明；
  • Trace / Recovery：过程如何被观察，失败后如何恢复；
  • Evaluation / Responsibility：如何衡量协作是否可靠，后果由谁承担。

尚未被填补的缺口

当前产品和组织通常仍把三条边割裂开来。

传统设计团队主要负责 Human ↔ System 的 GUI；对话设计或 AI 产品团队负责 Human ↔ Agent；平台和工程团队负责 Agent ↔ System 的 API、CLI 与 MCP。每一方都可能局部优化自己的界面，却没有人对整个三角的协作质量负责。

结果是：

  • Agent 的计划与 GUI 中的真实对象无法对应；
  • 用户批准的是一句摘要，而不是确定的动作与参数；
  • MCP 调用改变了系统，监督界面却不能及时反映；
  • 用户手动接管后，Agent 仍基于旧上下文继续行动；
  • Agent 能执行操作，却无法提供足够证据；
  • 系统记录了技术日志，却不能解释目标、决策和责任；
  • 产品追求更高自动化率，却忽视不可逆错误与用户修正成本。

这个缺口不能只靠增加一个 AI 设计职位来填补。它要求产品、设计和工程共同面对同一套领域模型、状态模型、权限模型和评估标准。

评价 Agent 产品，也不能只看传统的任务完成率、耗时和满意度，还需要关注：

  • Agent 选择正确工具的比例；
  • 计划与用户真实意图的一致性；
  • 无效调用与无效审批的频率；
  • 用户发现偏差和修正偏差的成本；
  • Agent 在正确时间请求帮助的能力；
  • 错误恢复率与不可逆错误率；
  • 旧上下文、旧计划和旧授权的失效率；
  • 用户对 Agent 能力形成的信任是否与实际可靠性匹配。

重新定义 Interface Design

未来并不是 UI 被 Agent Experience（AX）取代，也不是 GUI 被 CLI 或 MCP 取代。

更可能出现的组合是：

自然语言负责表达意图，Agent 负责规划和执行，GUI 负责呈现状态、比较、证据与控制，CLI / API / MCP 负责连接真实系统。

从 CLI 到 GUI，再到 Agent，复杂度依次从人的记忆与操作，转移到系统的表示与约束，再转移到代理者的规划与执行；人的角色则逐渐转向目标设定、授权、监督、核验与接管。设计的对象也因此从单个页面和单次操作，扩展到跨越目标、计划、行动、证据、审批、接管和恢复的完整闭环。

可以用三句话概括这个三角：

Human ↔ Agent：设计如何委托。 Agent ↔ System：设计如何行动。 Human ↔ System：设计如何验证和接管。

过去多数产品中的 UI Design，主要设计人如何操作系统。

Agent 时代的 Interface Design，则是在部分复杂度转交给 Agent 后，设计人如何委托有限行动权，Agent 如何作用于系统，以及系统如何向人证明究竟发生了什么。

最终，我们设计的不再只是 interface 的样子，也不只是某一个主体的 experience，而是一套 agency architecture：

这里的 agency 不是不受约束的自主性，而是在具体目标、权限和责任边界内感知、判断与行动的能力。

谁能够感知，谁负责判断，谁获得授权，谁实际执行，谁验证结果，谁可以中断和撤销，以及谁承担最终责任。

这或许才是重新思考 interface 的真正起点。