LLM时代的人机交互思考

把Decoder从Encoder单拎出来用太天才了你知道吗。

GUI 的意义正在被基于意图的语言交互消解。2026 年 3 月前后软件掀起 CLI 化浪潮，将应用改造为 AI 便于语言操控的模式。

文本接口便于统一、易于构建结构化工作流，GUI 很难做到。

GUI 大多是树状结构，可按遍历顺序展开。UI 适合作为固化模板，其结构蕴含操作顺序、因果和父子关系。

基于这几点碎片，下面展开一个更系统的思考。

交互三体系统

graph TB
    subgraph 人类["人类"]
        intent["意图<br/>(语言/模糊信号)"]
        intuition["直觉判断<br/>(视觉/空间/审美)"]
    end

    subgraph agent["LLM Agent"]
        compile["意图编译<br/>自然语言 → DSL/API 调用链"]
        reason["推理/规划/编排"]
    end

    subgraph system["底层工具/系统"]
        tools["API / CLI / 函数调用"]
        data["数据 / 状态 / 文件"]
    end

    subgraph gui_layer["GUI 确认面"]
        present["结果呈现<br/>(图表/控件/布局)"]
        refine["微调/确认<br/>(连续参数/拖拽/选择)"]
    end

    %% 主流：语言通道
    intent -->|"自然语言"| compile
    compile -->|"结构化指令"| reason
    reason -->|"API/CLI 调用"| tools
    tools -->|"执行"| data

    %% 反馈：当结果需要人类判断时
    data -->|"序列化/渲染"| present
    present -->|"视觉呈现"| intuition
    intuition -->|"确认OK"| intent
    intuition -->|"微调"| refine
    refine -->|"修正后的参数"| tools

    %% Agent 也可直接跳过人类
    data -->|"无需确认的结果"| reason

    style gui_layer fill:#f9e79f,stroke:#f1c40f
    style agent fill:#d6eaf8,stroke:#3498db
    style 人类 fill:#d5f5e3,stroke:#2ecc71
    style system fill:#e8daef,stroke:#9b59b6

三层通道的角色

GUI 不是交互主通道，但一旦人类需要做直觉判断（一看就懂）或连续参数微调（拖一拖就准），GUI 没有替代方案。

graph LR
    a[语言: 粗调<br/>人类→Agent] --> b[CLI: 执行<br/>Agent→系统]
    b --> c{GUI: 确认?<br/>系统→人类}
    c -->|"需要直觉判断"| d[GUI 呈现/微调]
    c -->|"无需人类介入"| e[Agent 直接闭环]
    d --> a

GUI 在三体系统里的位置：夹在输入和输出之间的确认面——用得最少，但被用到时不可替代。

三体运行时（Trinity Runtime）

核心思想：把 Agent、系统、GUI 统一到一张可变能力图（Mutable Capability Graph）上，三者都能运行时读写。

统一抽象：Capability

一切皆能力节点：

Capability {
  id, type          // tool | view | data | workflow
  interface         // 输入/输出 schema
  implementation    // 系统→API端点, GUI→组件渲染器, Agent→编排逻辑
  origin            // 谁创建的 (agent | system | gui | human)
  lineage           // 从哪些能力组合/进化而来
  usage             // 调用频次 / 最后使用时间
}

各类型在三者视角下的含义：

三种生长操作

任何实体都能对能力图发起：

三个自举循环

graph TD
    subgraph L1["Loop 1: 意图驱动生长"]
        h1["人类意图"] --> a1["Agent compose"]
        a1 -->|"缺能力"| a2["Agent generate tool/data"]
        a2 -->|"register"| s1["System 执行"]
        s1 -->|"产出数据"| g1["GUI auto-gen view"]
        g1 -->|"新界面"| h1
    end

    subgraph L2["Loop 2: 模式驱动生长"]
        h2["人类反复操作"] --> g2["GUI 捕捉操作序列"]
        g2 -->|"Weave workflow"| cap2["能力图"]
        cap2 -->|"Agent 直接调用"| a3["Agent 编排"]
    end

    subgraph L3["Loop 3: 数据驱动生长"]
        s3["System 检测新模式"] -->|"gen data capability"| cap3["能力图"]
        cap3 -->|"广播"| a4["Agent 感知新数据源"]
        cap3 -->|"广播"| g3["GUI 建议新组件"]
    end

    L1 -.->|"并发运行"| L2
    L2 -.->|"并发运行"| L3

收敛锚点

• 自动生长是临时的（带 TTL），只有人类确认过的才持久化
• 未使用的新能力自动回收
• 每个能力有 genealogy，冲突回溯合并

与传统软件的区别

基础设施（Trinity Substrate）

Trinity Runtime 需要在传统 OS 之上引入一个新基础层：

Layer 0：根基（缺一个就转不起来）

能力注册表（Capability Registry） — 核心数据面

实时图数据库，存储能力节点及关系。不是静态 API 文档，是运行时一等原语。需支持： - 并发读写（Agent/System/GUI 同时操作） - Schema 强制校验（每个 capacity 的 interface 必须合格才能注册） - 版本化（evolution 需要追溯 lineage） - 按类型/接口/血缘查询（Agent 编织前需要发现可用能力）

事件总线（Event Bus） — 通信面

实体间唯一的通信通道。Agent 生成新能力 → 广播给 GUI 渲染、System 执行。System 发现新数据 → 广播给 Agent 感知、GUI 生成视图。需支持： - Pub/sub 模式，按能力类型过滤订阅 - 至少一次投递保证 - 事件溯源（event sourcing），所有变更都有日志可回溯

安全沙箱（Secure Sandbox） — 安全边界

Agent 运行时生成的代码必须在隔离环境中执行： - 每个 Agent 生成的能力跑在独立沙箱中 - 资源限制（CPU/内存/网络/磁盘） - 能力只能访问已授权的 API（capability-based security） - 审计日志记录所有生成和执行历史

组合引擎（Composition Engine） — 生长引擎

实现 Weave 操作。输入能力 ID 集，输出新能力： - 接口类型检查（输入/输出 schema 是否兼容） - 自动适配器生成（类型不匹配时插入转换层） - 组合验证（循环依赖检测、dead path 分析） - 优化（可扁平化的组合直接内联）

Layer 1：治理（防止自举变自毁）

审批网关（Approval Gateway） — 人类锚点

自动生成的能力默认带 TTL，须审批才持久化： - 能力生命周期状态机：proposed → pending → approved → active → deprecated - 风险分级自动审批（低危自动过，高危必须人类确认） - 回滚机制（被拒的能力标记为 rejected，保留 lineage 供后续审计） - 审批界面本身是 GUI 层的一个特殊 capability

遥测管道（Telemetry Pipeline） — 反馈面

追踪所有能力的运行时行为，驱动 GC 和优化： - 调用频次、延迟、错误率、资源消耗 - 热点识别 → 反馈给 Agent 优化编排路径 - 冷数据识别 → 触发 usage-driven GC - 异常模式检测 → 触发安全审计

谱系引擎（Lineage Engine） — 溯源面

每个能力有完整的 genealogy DAG： - 记录 origin（谁创建的）、ancestors（从哪些能力 Weave/Evolution 而来） - 冲突检测：两个 Agent 同时 Evolve 同一能力 → 按 lineage 合并或标记冲突 - 影响分析：删除/废弃一个能力时，自动追溯所有 descendant

Layer 2：接入面（三套 SDK）

从现有技术看距离