AUI：让 App 在编译时生成 Agent 接口

我想做一个编译器：开发者写一份 App 源码，在构建时同时得到给人使用的 GUI，以及给 Agent 使用的接口。我暂时把这个方向叫作 AUI（Agent UI）。

这篇文章记录的是 2026 年 2 月 21 日与 Kimi Claw、Claude 讨论形成的构想。核心问题还没有经过实验验证：从前端源码中，究竟能自动提取多少足以完成实际任务的信息？

从界面操作到功能调用

当 Agent 通过截图、视觉识别、DOM 或模拟点击来操作软件时，它需要先理解一个为人设计的界面，再把意图转换成界面操作。一个列表里可能有很多外观相同的按钮，Agent 要识别对应对象、判断当前状态，再执行动作。页面加载、布局变化和弹窗也会影响这个过程。

这些方式有很强的兼容性：即使应用没有专门为 Agent 提供接口，也可以尝试操作。但我想探索另一条路径：既然开发者已经在源码里定义了界面和行为，能否在编译时利用这些信息，生成 Agent 可以直接调用的入口？

同一份应用源码
（SwiftUI / Jetpack Compose / React）
                 │
               构建阶段
                 ├── GUI：面向人的界面
                 └── Agent 接口：通过 MCP 暴露受审核的功能

这里的重点是把界面背后的操作能力显式表达出来。例如，Agent 不必先找到商品搜索框再输入文字，而是调用一个带有参数说明的搜索工具。这个变化能否减少延迟和操作失败，需要在具体任务上比较，不能仅凭调用形式就认定它更可靠。

不发明新协议，先降低接入成本

我的选择是使用 MCP 作为协议层。AUI 要解决的是生成接口的成本，而不是再推动一个新标准。目标是让已有 MCP 客户端能够消费这些接口，同时减少开发者重复描述应用功能的工作。

优先考虑移动 App，也是一种切入点选择。与网页相比，我希望在声明式移动 UI 的源码和构建流程里，找到更明确的组件、状态和动作关系。它们是否足以支持自动提取，仍需验证；这里并不意味着移动端没有其他 Agent 接入方案。

这一方案处在两条已有路径之间：

路径	可以利用什么	需要承担什么
Agent 直接操作 GUI	已有界面，不要求应用接入	运行时识别、状态判断和交互失败的成本
从后端 API 生成接口	已有服务定义和参数结构	将接口与用户任务对应起来，并处理授权和暴露范围
从应用源码生成 AUI	界面的可见信息、交互关系和动作绑定	编译器接入、自动提取的局限，以及开发者审核

从 OpenAPI 等后端描述生成接口，是很值得考虑的更短路径。但后端接口不一定直接对应用户在界面中理解的动作，也可能包含开发者不打算开放的能力。因此，我给 AUI 设定的范围是：尽量对应 GUI 中用户能看到的信息、能触发的操作，而不是自动开放整个后端。

这是一条设计边界，不是源码分析天然能保证的结果。尤其是直接调用动作时，不能把界面中的校验、权限和确认步骤一起跳过去。

生成什么，保留什么

最小的输出可以先是一组工具定义：工具名、用途、输入参数及其约束。例如，搜索商品这个动作可以描述为“输入关键词和可选分类，返回匹配的商品”。提交订单则需要收货地址、支付方式等信息，还涉及更严格的授权与确认。

我当时设想的 MVP，是给定一个 Jetpack Compose 或 SwiftUI 项目，输出这样的工具描述。它首先用于检验：从源码里提取出的信息，是否足以让 Agent 理解可用动作。

但工具定义并不等于一个可以工作的接口。真正执行任务，还需要把调用连接到应用动作，保留必要状态和校验，并返回可理解的结果。因此，验证时既要检查描述能否生成，也要检查这些描述能否支撑实际调用。

我不认为必须追求百分之百自动提取。原来的设想是自动完成大部分重复工作，剩余部分由开发者补全，无法覆盖的操作再回退到 GUI。手写接口仍然有价值；问题是编译器能否显著减少这部分劳动，而不把维护成本转移到另一处。

先验证接口，再验证编译器

最先做的实验，不应该是搭一个完整的跨平台编译器。我会先选择一个开源 Jetpack Compose 应用，手动写出它理想情况下应该提供的工具定义，并提供可执行的调用连接，让 Agent 尝试完成搜索、查看详情等基本任务。

这个顺序可以拆开两个不同的问题：

接口是否有用？ 即使工具定义由人手写，Agent 是否就能顺利完成任务？如果仍然缺少状态、上下文或操作语义，自动生成也不会解决这些问题。
接口能否生成？ 对照手写定义，逐项判断哪些信息能从源码中提取，哪些必须由开发者标注或补充。

我在原始讨论中把约 70% 的自动提取率作为一个值得继续探索的目标，把低于 30% 看作需要重新判断方向的信号。这些数字只是早期决策阈值，并不是测量结果，也不是通用标准。实际判断还应考虑：自动生成的部分是否恰好覆盖高频任务，以及人工补全是否比直接手写更省事。

同样，编译时生成是否足以抵消接入构建流程的成本，也需要与 GUI 操作比较。如果只改善很少的任务，或者每次改界面都要大量维护生成结果，方案就未必值得采用。

比技术可行性更难的接入问题

开发者愿不愿意让 Agent 进入应用，是另一层问题。生成接口更容易，并不代表服务方就有开放接口的动力。

一种可能的设计，是让生成的接口默认受限，由开发者审核后逐项激活，并明确 Agent 身份、授权范围和操作边界。尤其不能把“可以生成一个调用入口”直接等同于“应该允许自动执行”。

我想优先寻找主动需要这种能力的场景。例如，企业软件的客户可能希望自己的 AI 助手能操作已采购的软件；商家也可能希望 Agent 帮用户完成商品查找和购买。这些只是候选需求，还要通过实际开发团队来验证。

最关键的判断是：服务方不接入 Agent，究竟是因为开发成本高，还是因为暂时看不到价值？AUI 能降低前者，却无法仅靠一个编译器解决后者。

因此，这个构想的下一步很具体：先在一个应用上验证手写接口的任务表现，再研究编译阶段能提取的内容和需要人工补全的部分。只有这两步都成立，才值得决定第一个目标框架，并实现编译器插件原型。