真正被设计的，是行动权

最近和人聊 Agent 产品，话题几乎总会落到同一类地方：对话体验怎么做、工具调用稳不稳、MCP 接了几个、自动化率能不能再高一点。这些当然重要。但我越来越觉得，我们真正缺的不是更多控件，也不是更聪明的模型，而是一套能把“委托”这件事说清楚的界面观。

今天一提 UI，很多人想到的是颜色、字体、图标、布局，或者一个叫“UI 设计师”的职位。用户界面逐渐被等同于图形界面，图形界面又进一步等同于 Figma 上的视觉稿。页面能截图、能评审、能交付，于是最容易被看见的东西，慢慢变成了 UI 的全部。

可一旦产品里出现了 Agent——一个能形成计划、调用工具、改变真实系统状态的行动者——这套想象就开始不够用了。用户不再只是“点按钮完成操作”，而是在把一部分判断和行动交出去。这时，界面设计真正要处理的，已经不只是看起来顺不顺眼，而是：

谁有权行动，谁验证结果，谁可以中断，谁承担后果。

这篇文章想做的，是把界面从“屏幕表面”拉回它更原本的含义，再顺着 CLI、GUI 到 Agent 的变化，看清复杂度究竟被交给了谁。最后我会给出一个我越来越依赖的模型：人、Agent 与系统之间的交互三角。

界面从来不只是“面”

如果回到本义，界面不是一块可见的“面”，而是一种关系。

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

代码里其实还保留着这个意思。比如 TypeScript：

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

这份约定不负责规定按钮放在哪里。它只承诺：对外提供什么能力，调用者要传什么，可以预期得到什么。调用方不必知道背后连了哪家银行、退款走了几步；实现方也不必知道对面是网页、脚本，还是 Agent。双方靠同一份契约协作，又各自保持内部独立。

所以一种界面至少要说清四件事：边界在哪里，抽象成什么模型，输入输出遵守什么协议，以及行动之后如何反馈和恢复。它不是静态物体，而是一个持续运行的闭环：

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

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

用户界面只是其中的一个特例：它连接人和计算系统。

一侧是人。人有目标，却不一定说得准；依赖感知、经验和记忆；会犹豫、误解、犯错；也需要掌控感和安全感。另一侧是系统。它要明确输入，按规则改状态，内部塞满数据、权限、异常和用户看不见的过程。

UI 的核心工作，就是在这两种世界之间做双向翻译：把人的意图译成系统可执行的操作，把系统的状态译成人能感知和理解的信息。

所以一个按钮真正难的，从来不只是颜色、圆角和阴影，而是用户是否理解它、此刻能否执行、会影响什么、系统有没有接收、失败怎么办、能不能撤销、谁有权限、谁为后果负责。屏幕只是最常见的载体，不是 UI 的本体。CLI、语音、提示音、震动，甚至方向盘和门把手，都在做类似的翻译与反馈。页面也只是某一时刻的截图；完整的 UI 活在时间里，包含等待、错误、恢复、权限和历史。

UI 还是产品内部模型的外显。项目、任务、负责人、状态、优先级，看起来像字段，其实是系统对“工作”这件事的定义。很多所谓体验问题，并不是页面画得不好，而是系统模型与人的认知模型对不上。

更进一步，界面从来不是中立的。它决定什么可见、什么被藏起；什么好做、什么被故意加阻力；谁能行动、谁只能看；什么默认发生、什么可以撤销；系统犯错时，损失落在谁头上。

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

从 CLI 到 GUI：复杂度换了个肩膀

早期批处理时代，人通过打孔卡、纸带、作业说明和操作员把任务交给机器，再等结果。界面当然存在，只是由介质、语言、规程和组织流程一起构成。交互不实时，反馈可能要几个小时。

到了 20 世纪 60 年代，分时系统和交互终端让人能直接跟正在运行的计算机对话：敲一条命令，读一段文本，再敲下一条。后来我们叫它 CLI：

用户意图
→ 符号命令
→ 系统执行
→ 文本响应
→ 下一条命令

CLI 把人机关系变成高频反馈循环。人不必直接碰内存和设备，只要学会命令、参数和组合规则。它很强：可组合、可重复、可脚本化，过程还会自然留下文本记录。但代价也很清楚——系统“能做什么”往往不主动显现，而是藏在手册和人的记忆里。

CLI 的基本关系是：人用系统规定的语言描述动作。

另一条线几乎同时长出来。1963 年，Ivan Sutherland 的 Sketchpad 已经让人用光笔直接操纵图形；1968 年，Douglas Engelbart 团队在后来被称为“演示之母”的展示里，亮出了鼠标、窗口、超文本和协作文档；1973 年的 Xerox Alto，以及后来的 Xerox Star、Apple Lisa 和 1984 年的 Macintosh，把图形交互从实验室推进到更广泛的使用者手里。

GUI 不只是给命令贴了图标。它改的是系统如何向人呈现自己：

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

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

文件从路径变成可拖动的图标；可用动作从“你得想起来”变成菜单和按钮里“你能认出来”；系统从一种要掌握的语言，变成一个由对象、空间和规则组成的可见世界。

真正的差异，其实不只是文本还是图形，而是复杂度由谁承担。

CLI 把更多工作留给人：记住命令和语法，在脑子里维持对象与状态，把目标拆成步骤，再从文本错误里判断下一步。系统提供语言，人负责理解语言背后的世界。

GUI 则让系统多做翻译：对象、合法动作、参数范围、进度、错误和恢复路径，都尽量外化出来。于是 CLI 更依赖回忆，GUI 更依赖识别。

但这不等于 CLI 把全部复杂度甩给人，也不等于 GUI 把系统真实结构全摊开。命令本身已经是抽象；优秀 GUI 呈现的，也是经过选择和压缩的操作模型。领域里消不掉的复杂度，只会在人、界面和系统之间重新分配：

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

GUI 的成功，其实是一次责任转移：系统和界面变复杂，换人的学习与操作成本下降。副作用也很致命——界面开始被重新想象成屏幕上的表面。页面和控件最好截图、最好评审、最好交付；能力边界、状态机、权限、错误协议，全退到视觉之后。久而久之，一个描述人与系统关系的概念，缩成了可见产物和职业分工。

CLI 和 GUI 也不是前后替代的两个阶段，而是长期并存的两种界面：一个把能力组织成可调用的语言，一个把状态组织成可感知的对象。开发、运维和基础设施领域，从来没有真正离开过 CLI。

这段历史真正说明的是：每一种界面都在回答同一个问题——

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

Agent 的出现，会再改一次这个分配。

二元关系不够了

传统产品里，交互几乎总被建成一条二元闭环：

Human ↔ System

用户表达意图，系统改状态、给反馈。系统内部再怎么自动化，对用户来说通常仍是一个黑盒式的“系统”。用户仍是主要决策者和操作主体。

自动化和软件代理其实并不新鲜。真正变的是：Agent 开始以可被委托、能形成计划、能作用于真实系统的显式行动者，站进产品里。它不是更聪明的搜索框，也不是多出来的控件。它被授予了有限的感知、判断和行动能力：理解目标，选工具，走多步，并在过程中改变真实系统的状态。

过去由人扛的一部分活——发现能力、记操作语言、拆目标、排步骤、看反馈再决定下一步——现在可以交给 Agent。人不再亲自规定每个动作，而是开始规定目标、边界和判断条件。

复杂度没有消失。它从人的操作过程，挪到了 Agent 的理解与执行里，也挪到了系统如何向 Agent 暴露能力，以及人如何授权、监督和核验整件事。

所以我越来越觉得，继续把一切封装在“系统”这个词里已经说不清了。更有用的做法，是把协作关系显式建成一个三角：

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

三条边都要设计：

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

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

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

三角之所以重要，就是因为它保留了 Human ↔ System 这条不依赖 Agent 叙述的事实与控制通道。这里的“直接”不是没有界面，而是用户能读到权威状态，独立核验结果，必要时亲自干预。Agent 不能控制或伪造这条通道——所以它是制衡边，也是安全边。

我现在几乎会把这句话当成 Agent 产品的底线：没有独立事实通道的自动化，不是委托，是交出控制权。

三条边，三种设计任务

Human ↔ Agent：设计如何委托

传统 UI 通常逼用户说“怎么做”：选地区、选规格、填名称、点部署。

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

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

用户不再决定每一步，而是把目标与一部分行动权交出去。所以这里真正该设计的，不是聊天框漂不漂亮，而是一份逐步成形的委托契约：目标是什么，哪些是硬约束，哪些只是偏好，Agent 拿到了什么权限，准备怎么做，哪些决定可自主，哪些必须批准，怎样算完成，如何暂停、接管或撤销，失败了谁负责。

Human ↔ Agent 这条边的核心交换物，不是文字，而是意图、判断权与行动权。

它也不必长成聊天 GUI。语音、结构化计划、动态表单、画布、通知、对象操作，都可以。自然语言擅长表达模糊目标和例外，却不擅长大量比较、精确调参、复杂 diff 和持续盯盘。我更相信未来的常态会是：自然语言负责意图，结构化界面负责计划、证据、审批和控制。

Agent ↔ System：设计如何行动

Agent 得把抽象目标落成真实系统里的具体行动。这条边可以叫 ACI：Agent 面向计算机、面向系统的那一层。它从系统拿走状态、对象、权限和错误，再向系统发出查询、命令、修改和补偿。核心交换物是观察与行动。

CLI、API、函数调用和 MCP 都可以构成 ACI，但它们不等于 ACI 本身。Agent 也可以靠 DOM、无障碍树、截图和键鼠去操作现有 GUI。凡是让 Agent 能观察系统并作用于系统的东西，都属于这条边。

媒介差异很现实：结构化的 API 和 MCP 语义清楚，通常更可靠；CLI 和代码执行通用、可组合，还天然留下可读记录；直接操作 GUI 能覆盖还没开放结构化接口的系统，但更容易被界面变化和视觉歧义坑到。

CLI 在这里换了位置。过去它是人直接操作系统的界面；对 Agent 来说，它可以变成行动通道——Agent 负责理解目标、选命令、处理返回，CLI 负责把系统能力暴露成可调用、可组合、可记录的操作。

过去
Human → CLI → System

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

这不是 CLI 要重新取代 GUI，而是同一种界面开始服务新的行动主体。人曾经要扛的记忆、组合和执行，正好变成 Agent 的工作材料；CLI 的表达力、可组合性和文本记录，也变成了自动化和审计的基础。

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

click_create_button
select_region_dropdown
fill_instance_name
click_confirm

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

search_deployment_options
preview_deployment
create_deployment
get_deployment_status
rollback_deployment

前者逼 Agent 模仿人点 GUI；后者让 Agent 直接碰领域模型。这其实和传统 UI 设计很像：好 UI 不会机械暴露数据库字段，好的 Agent 界面也不该机械包装后端接口。两者都要围绕任务模型重组能力，只不过新的“使用者”是一个概率性的、上下文有限的、可能误解工具语义的 Agent。

Human ↔ System：设计如何验证和接管

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

当执行工作越来越多地交给 Agent，GUI 会从“用户亲自完成所有操作的面板”，部分变成“用户监督执行者的控制面”：看真实状态，查 diff，比方案和成本，批高风险动作，处理冲突，中断或接管，回滚，查证据和审计。

操作步骤少了之后，计划、权限、影响范围、不确定性和执行证据反而要更清楚。如果 Agent 说“部署已经完成”，用户不该只拿到一句自然语言结论。独立事实通道至少还该摆出这些东西：

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

“人在回路中”也绝不等于每个步骤弹一个确认框。没有计划、参数、影响范围和替代方案，人根本做不了有效判断——那不是控制，那是免责仪式。真正的人类控制，必须让人知道将要发生什么、实际发生了什么，以及偏了以后怎么回来。

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

三角中央：共享事实，而不是共享一段上下文

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

三角中央需要一层共享的东西：共享任务模型、共享系统状态，以及权限与责任记录。

注意，这不是“Human 和 Agent 同时看到同一段上下文”。Agent 的上下文是它当前能访问的工作集，可能被压缩，也可能已经过期；人的界面是为理解、判断和控制组织出来的视图。形式可以不同，但必须指向同一批对象、版本、计划和行动记录。

我把它理解成一套权威协作状态：是双方各自上下文的共同事实基础，也是系统判断计划、审批和权限是否仍然有效的依据。用户看到的对象版本，就应该是 Agent 正在操作的版本；Agent 改了系统，GUI 得跟上；人手动改了系统，Agent 也得知道世界已经变了；审批必须绑到具体计划、参数和版本上，不能让 Agent 拿着旧授权去执行已经变了样的新操作。

举个很常见的坑。Agent 提交删除计划：

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

用户批准后，如果 Project A 又多挂了一个生产库，原来的批准就不该自动覆盖新状态。计划已经过期，系统必须重新预览影响，再请求批准。

这类问题既不只是体验，也不只是 MCP 字段怎么定。它是三条边之间的状态一致性、时序一致性和权限一致性。你只要在真实系统里踩过一次“批过了，但批的时候世界已经变了”，就会明白这为什么要命。

真正的设计对象是行动权

三角里的三个参与者并不对称。

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

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

三条边还跑在不同频率上。Agent ↔ System 是高频执行循环；Human ↔ Agent 是围绕计划、进度和例外的中频监督；Human ↔ System 相对低频，却往往决定异常时是否仍然可控。低频不等于不重要。安全边安静的时候没人在意，出事的时候它是唯一还能把方向盘夺回来的东西。

未来最难的，恐怕不是每条边各自长什么样，而是控制权如何流转：Agent 何时必须问人，什么风险值得打断，一次批准覆盖多大范围，人改完系统后 Agent 如何知道上下文已变，失败后如何从中间状态继续，接管之后又怎样交还，多 Agent 并行时谁拥有有效状态，从 API 切到 GUI 后权限和审计能否一致。

所以 Agent 时代真正的设计材料，正在从页面、组件和流程，扩展到目标与上下文、能力与权限、计划与审批、控制与接管、不确定性与证据、轨迹与恢复，以及评价与责任。

说白了，我们开始设计的不是“更好看的操作面”，而是有限行动权如何被授予、约束、核验和收回。

缺口不在某个职位，在整张三角没人负责

眼下更常见的现实是：组织仍把三条边割裂开。

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

结果也就不意外：Agent 的计划对不上 GUI 里的真实对象；用户批的是一句摘要，不是确定动作和参数；MCP 改了系统，监督界面却没跟上；人接管之后，Agent 还拿旧上下文继续干；技术日志很全，却解释不清目标、决策和责任；产品追自动化率，却低估不可逆错误和用户修正成本。

这缺口没法靠多招一个“AI 设计师”填平。它要求产品、设计和工程面对同一套领域模型、状态模型、权限模型和评估标准。评价 Agent 产品，也不能只看任务完成率、耗时和满意度。还得看它有没有选对工具，计划是否贴着真实意图，无效调用和无效审批有多频繁，人发现并修正偏差要花多大代价，它会不会在该求助时求助，旧上下文和旧授权会不会在该失效时失效，以及用户对它的信任是否和真实可靠性匹配。

我也不相信未来会是 UI 被某种 Agent 体验取代，或者 GUI 被 CLI / MCP 取代。更可能的组合是：

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

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

可以用三句话收住这个三角：

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

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

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

最终，我们设计的不再只是界面的样子，也不只是某一个主体的体验，而是一套行动权结构——不是不受约束的自主性，而是在具体目标、权限和责任边界内，感知、判断与行动的能力。

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

重要的不是系统看起来多“会自己干活”，而是出事时你是否还知道：现在谁在动，动的是什么，依据是什么，以及你还能不能把行动权收回来。