1. 论文基本信息

1.1. 标题

AgentBuilder: 探索用于原型设计界面智能体用户体验的支架 (AgentBuilder: Exploring Scaffolds for Prototyping User Experiences of Interface Agents)

1.2. 作者

JENNY T. LIANG*, Carnegie Mellon University, USA
TITUS BARIK, Apple, USA
JEFFREY NICHOLS, Apple, USA
ELDON SCHOOP, Apple, USA
RUIJIA CHENG, Apple, USA

1.3. 发表期刊/会议

该论文发布于 arXiv 预印本平台，其发布时间为 2025-10-06T02:58:42.000Z。在相关领域的正式期刊或会议发表情况未明确说明，但根据 ACM 参考格式和多位来自 Apple 的作者信息，推测其可能目标是高水平的 HCI（人机交互）或 AI 领域会议。

1.4. 发表年份

2025年 (预印本发布时间)

1.5. 摘要

由生成式 AI 模型（统称为“智能体”，agents）驱动的界面智能体能够根据用户指令自动化执行操作。开发智能体的一个重要方面是其用户体验（即智能体体验，agent experience）。目前越来越需要为更广泛的人群（而非仅限于 AI 工程师）提供支架（scaffolds）来原型设计智能体体验，因为这些人能为设计智能体体验贡献宝贵的视角。在这项工作中，我们通过对 12 名对智能体有不同经验的参与者进行需求启发研究（requirements elicitation study），探索了智能体原型设计系统应提供的功能。我们确定了智能体体验原型设计中的关键活动和智能体原型设计系统所需的能力。我们将这些能力实例化为用于智能体原型设计的 AgentBuilder 设计探针（design probe）。我们使用 AgentBuilder 对 14 名参与者进行了一项现场智能体原型设计研究（in situ agent prototyping study），以验证设计需求并深入了解开发者如何原型设计智能体以及他们在此过程中的需求。

1.6. 原文链接

https://arxiv.org/abs/2510.04452

1.7. PDF 链接

https://arxiv.org/pdf/2510.04452v2.pdf

2. 整体概括

2.1. 研究背景与动机

核心问题： 传统的智能体开发通常需要 AI 工程专业知识和对特定 API 的了解，这限制了非 AI 专家（如 UX 设计师、产品经理甚至普通用户）参与智能体体验的设计和原型开发。然而，这些非专家群体对于智能体体验的设计具有宝贵的视角，可以帮助识别和避免潜在的负面影响，并创造更符合实际用户需求的智能体。

问题的重要性： 随着大型语言模型（LLMs）和多模态大型语言模型（MLLMs）的快速发展，智能体在自动化用户操作方面展现出巨大潜力，但其用户体验（UX）设计仍面临挑战。当前缺乏能够让非 AI 专家轻松原型设计这些智能体体验的工具和方法。

现有研究的空白： 尽管有一些工具用于生成式 AI 的提示开发（prompt development）或对话原型设计，但很少有工作专注于为更广泛的受众提供无代码（no-code）支架，以支持智能体体验的整体原型设计，尤其是在考虑智能体与用户交互的复杂性时。

论文的切入点/创新思路： 论文旨在探索智能体原型设计系统应提供哪些功能（affordances），以有效地设计智能体体验，并让更广泛的人群能够参与其中。通过需求启发研究，识别关键活动和所需能力，并构建一个设计探针 AgentBuilder 来实例化这些能力，最终通过现场研究验证这些需求并深入了解开发者的真实需求。

2.2. 核心贡献/主要发现

这篇论文的核心贡献体现在以下三个方面：

1. 一套经过验证的设计需求： 论文阐明了智能体原型设计系统的设计需求，具体表现为五个原型设计活动（prototyping activities）和六项智能体原型设计系统应支持的能力（capabilities）。这些需求是基于对具有不同智能体经验的参与者的需求启发研究得出的。
2. AgentBuilder 设计探针： 论文提出了 AgentBuilder，这是一个设计探针（design probe），它实例化了上述设计需求，通过无代码界面（no-code interface）使不同智能体熟悉程度的个体都能够原型设计智能体体验。
3. 智能体原型设计过程的洞察： 基于对 AgentBuilder 的现场用户研究，论文获得了关于智能体原型设计需求和过程的宝贵洞察。这些洞察揭示了开发者在原型设计智能体时的实际需求和所面临的挑战。

关键结论或发现：

• 智能体原型设计过程可以分为五个核心活动：设计智能体的范围和边界、设计智能体的信息显示、设计智能体与用户的交互、运行智能体原型、理解智能体的运行时行为。
• 智能体原型设计系统应支持六项关键能力：使用无代码界面、帮助限制智能体的任务空间和用户知识、定义智能体在聊天和环境中的用户界面、提供调用不同用户交互的组件、提供运行和控制智能体的环境、帮助用户调试智能体的运行时行为。
• 尽管提供了无代码界面，但用户仍希望对智能体的修改有更深入的理解和控制。
• 智能体原型设计与 LLM 提示开发有相似之处，但也存在独特挑战，例如需要理解多种形式的智能体输入输出，以及构建关于智能体如何工作的心理模型。
• 研究提出了针对智能体原型设计系统的设计建议，包括使交互组件易于理解、使用和定制；允许在显示不同数量智能体运行时信息之间切换；以及启用智能体运行时的审查和定制。

3. 预备知识与相关工作

3.1. 基础概念

为了更好地理解这篇论文，我们需要了解以下几个核心概念：

• 界面智能体 (Interface Agents): 界面智能体是一种软件实体，旨在通过自动化任务、提供个性化帮助或代表用户执行操作来增强用户与计算机系统或应用程序的交互。它们通常能够理解用户意图并基于此采取行动。在本文中，特指由生成式 AI 模型驱动的智能体。
• 生成式 AI 模型 (Generative AI Models): 这是一类人工智能模型，能够从训练数据中学习模式，并生成新的、原创的、与训练数据相似的数据。常见的生成式 AI 模型包括大型语言模型（LLMs，如 GPT 系列）和多模态大型语言模型（MLLMs，能够处理和生成文本、图像、音频等多种模态的数据）。它们是本文中界面智能体的核心驱动力。
• 智能体体验 (Agent Experience): 这是指用户在使用界面智能体时所经历的整体感知和感受。它包括智能体的交互方式、响应能力、可靠性、透明度、易用性以及它如何融入用户的工作流。设计良好的智能体体验对于提高用户满意度和智能体的有效性至关重要。
• 支架 (Scaffolds): 在教育学和技术领域，支架指的是一种结构或工具，用于支持学习者或开发者完成一项原本对他们来说过于困难的任务。在本文中，支架特指能够简化智能体原型设计过程的工具和框架，从而让非 AI 专家也能参与其中，降低技术门槛。
• 原型设计 (Prototyping): 在软件开发和用户体验设计中，原型设计是创建系统或产品初步版本的过程，用于测试概念、收集反馈并迭代改进设计。它允许在全面开发之前，以低成本验证设计思路和功能。
• 无代码界面 (No-code Interface): 一种允许用户通过图形用户界面（GUI）而非编写代码来创建应用程序或自动化工作流的界面。它通过拖放、配置选项等方式，使非程序员也能进行软件开发，实现“开发民主化”。

3.2. 前人工作

论文在“Related Work”一节中回顾了与界面智能体、生成式 AI 用户体验设计以及生成式 AI 提示开发相关的关键前人研究。

• 界面智能体 (Interface Agents):

  • 早期工作： 界面智能体的概念由来已久，如早期的 collaboration with agents [30, 42] 和利用应用 API（application APIs）为日历等应用开发智能体 [9, 10]。这些工作关注智能体如何向用户提供行动的足够理解、何时应暂停或接管任务、如何将智能体集成到用户界面中，以及如何在自主性和用户控制之间取得平衡 [2, 10, 31, 40, 50, 60]。
  • 基于 M(L)LMs 的智能体： 随着大型语言模型的发展，界面智能体现在能够通过语义理解用户输入，在 Excel [5]、电子表格 [1, 70]、浏览器 [1, 23, 24, 56, 68] 和操作系统 [59] 中完成操作。Web agents 是其中一种突出类型，它们可以在网页中执行点击按钮等用户界面操作。
  • 现有研究重点： 当前关于 web agents 的研究主要集中在开发新的生成式 AI 架构和方法 [8, 11]、基准测试 [8, 45, 68] 以及评估环境 [23, 41, 68] 以提高性能。
  • 人机协作工作流： 现有工作鲜少关注人机协作工作流的设计，但像 vLLM [4] 这样的工作通过在所有智能体操作前提供暂停来支持用户监督 web agent 任务。
  • 本文关注点： 本文扩展了现有工作，将关注点放在通过 (M)LLM-based agent experiences 原型设计时需要考虑的用户体验方面。

• 生成式 AI 的用户体验设计 (Designing for User Experience in Generative AI):

  • 设计挑战： 生成式 AI 体验带来了独特的 UX 挑战，因为它们的复杂性和不确定性 [13, 17, 33]。理解生成式 AI 的能力（capabilities）和限制（limitations）以及想象其输出（outputs）可能很困难。
  • 现有技术： 研究人员开发了技术来帮助原型设计生成式 AI 的用户体验，例如 FauxPilot [63] 和 UX [5]，它们允许设计师通过组合预定义组件来原型设计对话，并通过 Wizard-of-Oz 协议进行测试。PromptInUser [47] 是唯一一个已知的工具，允许 UX 设计师为生成式 AI 设计用户体验。
  • 本文关注点： 本文旨在将这些技术与智能体中的提示开发技术相结合。

• 生成式 AI 提示开发 (Developing Prompts for Generative AI Experiences):

  • 提示工程 (Prompt Engineering): 这是开发和完善自然语言提示（natural language prompts）的过程，这些提示嵌入在应用程序中 [65, 69]。提示开发是高度迭代和探索性的 [12, 36, 65]，开发者通过与 AI 的多次交互来原型设计和完善提示，以决定在提示中包含什么内容 [37]。然而，这项任务对开发者来说是一个主要挑战 [3, 14, 36]。
  • 提示开发工具： 已经出现了一些工具来支持提示开发，例如基于 notebook 的方法 [5, 53, 26, 28] 和基于 node 的方法 [19, 67, 71]，用于创建提示管道。
  • 智能体提示开发： 智能体开发是提示开发的子集，但有其独特的挑战。现有的关于智能体提示开发的研究相对较少，但像 ZaePereira 等 [5] 的工作研究了非 AI 专家如何为非 AI 体验设计提示，以及 vLLM [4] 和 Hao 等 [60] 的工作对多智能体工作流的开发者进行了定性研究。PROMPTER [71] 提供了一个基于 node 的界面，用于定义、查看和编辑智能体工作流。
  • 本文关注点： 本文扩展了关于提示的文献，包括 ZaePereira 等 [5] 关于非 AI 体验提示的研究，通过探索非专家如何为智能体体验设计提示，以及如何使用无代码支架来支持这种提示需求。

3.3. 技术演进

该领域的技术演进可以概括为从早期的基于规则和 API 的界面智能体，到近年来由大型语言模型（LLMs）和多模态大型语言模型（MLLMs）赋能的更智能、更自主的智能体。

• 早期阶段： 智能体概念在人机交互领域出现较早，主要通过预设规则和调用应用程序编程接口（APIs）来执行特定任务，如日历管理或个性化推荐。这一阶段的智能体设计重点在于用户理解、行动的透明度以及人机协作模式。
• 生成式 AI 赋能： 随着深度学习和生成式 AI 模型的突破，特别是 LLMs 的兴起，智能体获得了强大的自然语言理解和生成能力。这使得智能体能够语义化地理解用户输入，并在更广泛的应用程序（如网页浏览器、操作系统）中执行复杂操作，甚至生成多模态内容。
• 挑战与民主化需求： 尽管能力增强，但开发这些 LLM 驱动的智能体仍然高度依赖 AI 工程师的专业知识。这导致了智能体设计过程的瓶颈，限制了来自 UX 设计师、产品经理等非技术角色的宝贵投入。本文正是针对这一挑战，旨在通过提供无代码支架，实现智能体开发和原型设计的“民主化”，让更多人参与到智能体体验的设计中来。

3.4. 差异化分析

本文的工作与相关工作相比，其核心区别和创新点主要体现在：

1. 聚焦非专家用户 (Focus on Non-Expert Users):

   • 现有工作： 许多关于智能体或提示开发的工作，无论是早期的界面智能体还是基于 LLM 的新智能体，往往仍然面向具有一定技术背景（如 AI 工程师、开发者）的用户。即使是像 PromptInUser 这样的工具，虽然面向 UX 设计师，但主要关注生成式 AI 的提示本身，而非智能体在真实环境中的复杂交互体验。
   • 本文创新： 本文明确将目标用户群体扩展到“更广泛的人群”，包括那些“不是智能体专家且缺乏编程知识”的个体。通过需求启发研究和无代码工具 AgentBuilder，旨在打破技术壁垒，让 UX 设计师、产品经理甚至普通用户也能参与到智能体体验的原型设计中。

2. 强调“智能体体验”的整体原型设计 (Emphasis on Holistic "Agent Experience" Prototyping):

   • 现有工作： 现有的工具可能专注于智能体的某个特定方面，例如：
     • LLM 提示开发工具侧重于提示本身的迭代和优化。
     • 某些智能体开发工具可能更侧重于后端逻辑或性能基准。
     • 对话原型设计工具（如 FauxPilot）主要关注对话流程。
   • 本文创新： 本文提出的是一个用于原型设计智能体体验的系统。这意味着它不仅关注智能体的内部逻辑或提示，还关注智能体如何通过 UI actions 在真实应用环境中与用户互动、显示信息、接收用户输入以及在运行时如何被调试和理解。它将 prompt development、UI design 和 interaction design 整合到一个统一的原型设计流程中。

3. 无代码支架的系统化探索与实例化 (Systematic Exploration and Instantiation of No-code Scaffolds):

   • 现有工作： 尽管提到了 node-based 或 no-code 概念，但很少有研究像本文这样，通过严谨的需求启发研究来系统地识别智能体原型设计所需的关键活动和能力，并将其具象化为一个名为 AgentBuilder 的设计探针。
   • 本文创新： AgentBuilder 不仅仅是一个概念，它是一个具体实现的工具，能够让用户通过图形化的工作流编辑器、可配置的交互组件和直观的调试模式来设计、运行、检查和迭代智能体。这种从需求到设计探针再到现场验证的完整研究流程，为未来智能体原型设计工具的开发奠定了坚实基础。

4. 关注运行时行为的理解和调试 (Focus on Runtime Behavior Understanding and Debugging):

   • 现有工作： 很多 LLM 提示开发工具可能在模型输出层面提供调试信息，但对于智能体在真实应用界面（如网页）中执行操作时的具体行为，以及如何将这些操作与智能体的决策逻辑关联起来，关注较少。
   • 本文创新： 本文特别强调了理解智能体运行时行为（runtime behavior）和调试能力的重要性。AgentBuilder 提供了 UI action 预览、可配置的理由显示以及调试模式，让开发者能够深入了解智能体在执行任务时的每一步决策和操作，这对于非技术背景的设计师来说，是理解和迭代智能体体验的关键。

4. 方法论

本文的方法论主要分为三个阶段：需求启发研究 (Requirements Elicitation Study)、设计探针 AgentBuilder 的开发 (AgentBuilder Design Probe Development) 和 现场智能体原型设计研究 (In Situ Agent Prototyping Study)。这三个阶段相互联系，共同构建了对智能体原型设计支架的探索和验证。

4.1. 需求启发研究

4.1.1. 研究目的与问题

这项研究的目的是深入理解智能体原型设计过程以及为支持该过程所需的工具能力。研究旨在回答以下两个问题：

• RQ1： 开发者在原型设计智能体用户体验时会从事哪些重要活动？
• RQ2： 一个系统应提供哪些能力来支持智能体体验原型设计？

4.1.2. 研究方法

• 参与者： 招募了 12 名来自一家大型科技公司的参与者。这些参与者对智能体的经验水平各不相同，包括：
  • 具有相关领域专业知识的技术专业人员（$N = 6$），例如 2 名机器学习工程师、1 名软件工程师、2 名质量保证工程师和 1 名产品设计师。
  • 当前终端用户（$N = 5$）。
  • 对智能体完全不熟悉的人（$N = 1$）。
• 研究过程：
  • 所有参与者首先被询问他们与智能体相关的经验。
  • 对于专家参与者，研究人员会深入探讨他们如何原型设计智能体。
  • 对于非专家参与者，会探究他们对智能体体验的期望。
  • 然后，研究人员向所有参与者展示了多个现有智能体的体验模式示例（许多智能体通过面板和网页视图一起出现），并询问他们希望智能体在各种场景中具备哪些功能。
  • 访谈通过视频会议远程进行，时长为 60 到 90 分钟，并进行录音和转录以供分析。参与者获得 24 美元餐券作为补偿。
• 数据分析： 研究人员采用了开放式编码（open coding）方法，独立编码了所有转录文本，然后通过共同协商达成一致。这些代码根据访谈记录中出现的代码进行修改，属于初步编码过程。在进行 10 次访谈后达到了代码饱和。活动（Activities）通过理论编码（theoretical coding）进一步组织成更高阶的智能体原型设计阶段。代码、活动和智能体原型设计阶段由另一位研究人员进行审查，以验证结果。

4.1.3. 研究结果：活动与能力

研究发现智能体原型设计过程主要包括两个阶段：设计智能体 (Design the Agent) 和 检查智能体 (Inspect the Agent)。这进一步细化为五个核心活动（Activities，记作 A）和六项支持智能体原型设计系统所需的能力（Desired Capabilities，记作 C）。

设计智能体阶段的活动与能力：

• A1. 设计智能体的范围和边界 (Design the scope and boundaries of the agent): 开发者首先需要确定智能体能够执行哪些任务（例如，访问日历、管理消息应用中的聊天）以及它应该了解用户的哪些信息。
  • C2. 帮助限制智能体的任务空间和用户知识 (Help constrain the agent's task space and knowledge of the user): 原型设计工具应允许开发者定义智能体的任务范围和它可访问的用户信息，以帮助设计过程。
• A2. 设计智能体的信息显示 (Design the agent's information display): 开发者需要考虑智能体如何向用户显示其活动和信息（例如，在网页上突出显示操作、提供决策所需的信息）。
  • C3. 定义智能体在聊天和环境中的 UI (Define the UI of the agent in the chat and the environment): 用户应能够配置智能体如何在聊天界面和应用程序环境中显示信息，包括智能体如何征求用户输入。
• A3. 设计智能体与用户的交互 (Design the interactions between the agent and user): 参与者普遍希望工具支持人机协作工作流，包括智能体如何与用户沟通信息、在遇到问题时征求用户输入。
  • C4. 提供组件以使智能体能够调用不同的用户交互 (Provide components that enable the agent to invoke different user interactions): 原型设计工具应提供可配置的交互组件，允许开发者定义智能体在何种条件下调用何种交互（例如，确认、澄清）。

检查智能体阶段的活动与能力：

• A4. 运行智能体原型 (Run the agent prototype): 开发者需要在一个能够运行和控制智能体的环境中验证其原型行为，例如观察智能体是否正确到达预期页面，或在错误时提供暂停、取消或继续的命令。
  • C5. 提供运行和控制智能体的环境 (Provide an environment to run and control the agent): 系统应提供一个实时环境来运行原型，并允许开发者暂停、恢复或取消智能体的执行，甚至在运行时修改其行为。
• A5. 理解智能体的运行时行为 (Understand the agent's runtime behavior): 开发者需要了解智能体在执行过程中的具体行为，包括视觉表现（如屏幕截图、UI 操作轨迹）和文本表现（如 HTML 结构、智能体的理由）。
  • C6. 帮助用户调试智能体的运行时行为 (Help the user debug the agent's runtime behavior): 系统应提供工具来暴露智能体的内部状态、决策过程、工具调用和输出，以帮助用户调试其行为。

通用能力：

• C1. 使用无代码界面 (Use no-code interfaces): GUI 驱动的原型设计工具可以降低非 AI 专家参与智能体体验开发的门槛。

4.2. AgentBuilder 设计探针

为了实例化上述在需求启发研究中确定的设计能力，研究人员开发了一个设计探针 AgentBuilder。AgentBuilder 包含两个主要接口：Design (设计) 界面用于智能体体验设计，以及 Execution (执行) 界面用于本地运行和检查智能体。

4.2.1. 智能体设计支架 (Scaffolds for Designing the Agent)

AgentBuilder 的设计界面（Prototyping Interface）通过多种模块支持智能体的设计，如图 1 所示。

该图像是论文中展示AgentBuilder设计与研究流程的示意图，分为需求调研、设计探针和现场原型研究三部分，展示了关键系统功能及界面示例。

以下是原文 Figure 1 的描述： 描述: 该图像是论文中展示AgentBuilder设计与研究流程的示意图，分为需求调研、设计探针和现场原型研究三部分，展示了关键系统功能及界面示例。

• 工作流选项卡 (Workflow tab):

  • 这是一个图形化的编辑器，采用了常见的无代码（no-code）界面范式，允许用户通过节点和边来设计智能体的意图（intents）和行为（behaviors）。

  • 节点 (Nodes): 代表智能体可以采取的动作或交互。例如，Interact 节点代表与用户的交互，Plan 节点代表智能体展示其高层步骤。

  • 边 (Edges): 代表定义智能体何时应采取某个行动的条件。

  • 核心交互节点（C4能力体现）: AgentBuilder 提供了一些预定义的交互组件，用于调解智能体与用户的界面：

    • Start (开始): 工作流的起点，用户向智能体发出任务指令。
    • End (结束): 工作流的终点，智能体完成任务。
    • UI Actions (UI 操作): 智能体在网页上执行的操作（如点击、滚动、输入文本、访问网页）。
    • Plan (计划) (图 3-E): 智能体展示完成任务的高层步骤列表。
    • Message (消息) (图 3-F): 智能体显示文本以传达信息。
    • Interact (交互) (图 3-A, 图 3-F): 智能体向用户提出开放式询问，用户可以以选项列表或开放文本响应。
    • Confirmation (确认) (图 3-C): 智能体提出一个确认询问，用户可以接受或拒绝。

  • Inspector (检查器): 用于进一步定制所选节点的属性，例如修改 Risk 选项。

  • 用户界面更新： 开发者可以编辑智能体 UI 操作的显示方式，例如显示操作名称、简要描述或不显示任何信息。这些更改会实时更新到预览界面中。

    以下是原文 Figure 3 的描述： 描述: 该图像是一个界面代理构建器的聊天式用户交互示意图，展示了代理在星巴克菜单页面搜索并引导用户选择咖啡选项的对话流程，体现了代理规划与用户选择的交互细节。

• 提示界面 (Prompt Interface): (图 4)

  • AgentBuilder 的 Prompt 界面允许开发者编写结构化的自然语言提示，这些提示是为原型设计生成式 AI 体验而设计的功能性无代码表示。

  • 工作流提示 (WorkFlow Prompt): (图 4-A) 描述智能体通过工作流可以完成的步骤。AgentBuilder 促进图形工作流和提示之间的双向编辑。工作流被合成到 WorkFlow Prompt 中，开发者可以手动编辑。

  • 智能体能力提示 (Agent Capabilities Prompt): (图 4-B) 开发者可以在此部分编写关于智能体能力、权限的指导方针。

  • 用户信息提示 (User Information Prompt): (图 4-C) 描述关于用户的信息，例如偏好、敏感数据。

  • 预览选项卡 (Preview tab): 允许用户查看组装好的系统提示。

    以下是原文 Figure 4 的描述： 描述: 该图像是一个界面代理构建器中用于设计和编辑界面代理工作流程的界面，包括流程节点（如Start、Message、Interact等）和Inspector面板的多种配置与预览窗口。

4.2.2. 智能体检查支架 (Scaffolds for Inspecting the Agent)

• 执行界面 (Execution Interface):

  • AgentBuilder 提供了一个作为用户网页浏览器扩展的智能体执行界面（图 5），智能体在此执行 UI 操作并与用户聊天。
  • 运行控制 (C5能力体现): 提供了本地智能体控制，例如：

    • Pause (暂停) 按钮：暂停执行。

    • Run (运行) 按钮：继续执行。

    • Cancel (取消) 按钮：结束智能体运行。

      以下是原文 Figure 5 的描述： 描述: 该图像是一个界面原型示意图，展示了一个咖啡订购界面及对应的智能代理聊天框，体现了AgentBuilder系统在用户体验代理设计原型中的应用。

• 调试模式 (Debugging Mode): (图 6)

  • AgentBuilder 提供了调试模式，暴露了额外的智能体信息，例如工具调用和智能体推理。

  • 导航和检查 (C6能力体现): 用户可以通过滑块来导航智能体之前动作的输入和输出，查看聊天中对应消息的工具调用和智能体推理，以及访问网页的辅助功能树（accessibility tree）、文本输入等。

    以下是原文 Figure 6 的描述： 描述: 该图像是三张连续界面截图的示意图，展示了AgentBuilder中咖啡订单代理的调试过程，包含用户选择、代理思考及调试日志三部分，体现了代理交互和调试功能。

4.2.3. 实现细节

• AgentBuilder 的原型设计界面（Prototyping Interface）和执行界面（Execution Interface）都作为 TypeScript React 应用程序实现。
• 原型设计界面是一个 Web 应用程序。
• 执行界面是 CowPilot Chrome 浏览器扩展 [23] 的修改版本。
• 对 CowPilot 的修改包括：添加自然语言描述到 UI 操作中，使网页中的 UI 操作预览可配置，以及添加调试智能体输出。交互组件也作为工具提示（tool prompts）实现。

4.3. 现场智能体原型设计研究

4.3.1. 研究目的与问题

这项研究的目的是通过 AgentBuilder 验证智能体原型设计系统中的设计需求，并进一步了解开发者在智能体原型设计过程中的工具需求。研究旨在回答以下两个问题：

• RQ3： 开发者如何原型设计智能体？
• RQ4： 开发者在智能体原型设计系统中有什么样的工具需求？

4.3.2. 研究方法

• 参与者： 招募了 14 名参与者。他们的背景多样，包括软件工程师、项目经理、设计师、产品经理、机器学习工程师等。他们对生成式 AI 的使用频率、提示工程经验和智能体熟悉程度各不相同。所有参与者都是生成式 AI 的用户。 以下是原文 Table 1 的结果：

  PID	Job Role	GenAI Usage	Prompt Engineering	Agent Familiarity
  P1	Software Engineer	More than once daily	No experience	Never used or seen demos of an agent
  P2	Software Engineer	More than once daily	Some experience	Never used or seen demos of an agent
  P3	Designer	Once daily	A little experience	Never used or seen demos of an agent
  P4	Machine Learning Engineer	Once daily	Extensive experience	Used an agent as an end-user
  P5	GenAI Software Engineer	Once daily	Extensive experience	Seen demos of an agent
  P6	Product Manager	More than once daily	Some experience	Seen demos of an agent
  P7	Web Software Engineer	More than once daily	Extensive experience	Seen demos of an agent
  P8	Human Factors Engineer	More than once daily	No experience	Never used or seen demos of an agent
  P9	Technical Project Manager	Once daily	Some experience	Seen demos of an agent
  P10	Engineering Program Manager	More than once daily	A little experience	Seen demos of an of agent
  P11	Modem Systems Test Engineer	Weekly	A little experience	Seen demos of an agent
  P12	Machine Learning Engineer	More than once daily	Extensive experience	Seen demos of an agent
  P13	Acoustics Experience Engineer	Once daily	Some experience	Used an agent as an end-user
  P14	Product Manager	More than once daily	Substantial experience	Seen demos of an agent

• 研究任务： 参与者被要求使用 AgentBuilder 为星巴克网站上的咖啡订购场景设计一个智能体用户体验。研究人员提供了一个基线智能体，并鼓励参与者思考其 UX 限制。任务持续 30 分钟。

• “思考出声”协议： 参与者被鼓励在整个过程中“思考出声”（think-aloud），以捕捉他们的决策过程和面临的挑战。

• 预填充提示： 为了简化任务，AGENT CAPABILITIES PROMPT 和 USER INFORMATION PROMPT 预先填充了信息。

• 数据收集： 会话通过视频会议远程进行，并录音和转录。

• 数据分析： 研究人员对转录文本和录音进行开放式编码，以识别参与者的原型设计活动和工具需求。

4.3.3. 研究结果：原型设计过程与工具需求

研究发现，AgentBuilder 使得所有背景的参与者都能够原型设计智能体体验，并验证了需求启发研究中提出的活动（A）和能力（C）。原型设计过程可以概括为四个步骤：

1. 设计智能体的初始原型 (Designing an initial prototype the agent): 参与者从设想的智能体用户体验开始，设计一个粗略的目标。他们会探索工作流中可用的交互组件，并编写自然语言指令来指定智能体应如何响应查询、处理边界情况、定义语气等。他们还会考虑智能体应如何显示信息。
2. 运行和监控智能体 (Running and monitoring the agent): 参与者会运行初始原型来测试智能体对不同用户查询的响应，并观察它如何处理各种情况。在执行过程中，他们会密切监控智能体，审查智能体的消息，观察网页上的 UI 操作、行动描述、推理或 UI 操作预览。许多人会激活调试模式来实时查看智能体的推理。
3. 调试智能体 (Debugging the agent): 参与者在发现智能体遇到意外行为或错误时进行调试。他们会使用调试模式来理解智能体的行为，例如查看 UI 操作预览，以了解智能体在网页上具体点击了什么。
4. 迭代智能体 (Iterating on the agent): 识别出缺陷或确定改进智能体体验的方法后，参与者会迭代他们的原型。这通常包括更新工作流（例如，添加更多的交互节点、修改条件）和提示（例如，添加澄清指令、修改约束）。

关于工具需求的洞察 (Insights on Tooling Needs)：

• C1. 使用无代码界面 (Use no-code interfaces): 所有参与者都使用了 AgentBuilder 的无代码界面，但使用程度不同。有人侧重于工作流界面，有人更依赖直接修改自然语言提示。无代码提示能够快速配置智能体行为，而工作流表示则反映了开发者的工作习惯。然而，参与者仍希望获得更多支持来理解智能体可修改的部分，感到代理能力被限制。
• C2. 帮助限制智能体的任务空间和用户知识 (Help constrain the agent's task space and knowledge of the user): 即使预填充了智能体能力和用户信息提示，许多参与者仍会主动修改这些提示，以测试智能体将如何根据约束或对用户个人信息的了解采取行动。这使得他们能够反思智能体如何处理敏感信息。
• C3. 定义智能体在聊天和环境中的 UI (Define the UI of the agent in the chat and the environment): 大多数参与者都修改了智能体向用户显示的信息。这些决定受用户行为预期和开发者自身需求的指导。然而，参与者在实时运行时理解智能体的推理（reasoning）方面遇到了困难，需要工具来帮助理解智能体过去、现在和预期的行为。
• C4. 提供组件以使智能体能够调用不同的用户交互 (Provide components that enable the agent to invoke different user interactions): 工作流中的有限交互选项帮助参与者以更简洁明了的方式设计指令。然而，参与者对交互组件是否能按设计交付感到不确定，表达了需要可靠地预览和测试交互组件的需求。
• C5. 提供运行和控制智能体的环境 (Provide an environment to run and control the agent): 所有参与者都运行和观察了智能体至少一次，但很少有人使用 CowPilot 中的暂停和恢复功能。在智能体运行时，虽然参与者关注网页上的操作，但许多人难以追踪智能体何时何地与用户聊天或征求输入。他们需要能够跟踪详细运行时信息和潜在错误的界面，并以易于理解的格式呈现多个运行时数据源。
• C6. 帮助用户调试智能体的运行时行为 (Help the user debug the agent's runtime behavior): 大多数参与者使用了 AgentBuilder 的调试模式，发现它在理解智能体行为方面很有帮助。然而，他们无法修改 AgentBuilder 提供的推理或启用开发者调整智能体决策方式。

5. 实验设置

本论文主要通过用户研究来验证其设计需求和洞察，因此其“实验设置”与传统机器学习模型或算法的实验设置有所不同，主要集中在参与者招募、研究任务和数据分析方法上。

5.1. 数据集

本研究并未采用传统意义上的“数据集”，而是通过用户访谈和用户在特定任务场景下使用 AgentBuilder 进行原型设计所产生的交互数据、思考过程（think-aloud）和口头反馈作为研究数据。

• 需求启发研究阶段： 访谈了 12 名对智能体有不同经验的参与者。数据包括访谈的录音和转录文本，内容涉及他们对智能体体验原型设计的看法、现有工具的痛点以及理想工具的功能。
• 现场原型设计研究阶段： 招募了 14 名具有不同背景的参与者。研究任务是使用 AgentBuilder 为星巴克网站设计一个咖啡订购智能体。研究数据包括：
  • 参与者在使用 AgentBuilder 过程中的屏幕录像。
  • think-aloud 协议记录下的口头评论和思考过程。
  • 参与者设计的智能体原型（工作流和提示配置）。
  • 研究人员对这些数据进行编码和分析。

任务场景示例： 现场原型设计研究的任务是为星巴克网站设计一个咖啡订购智能体。以下是原文中提供的用户输入示例，用于测试智能体应如何处理：

• “给我点杯咖啡。我不确定我想要什么。” ("Order me a coffee. I'm not sure what I want.")

• “给我点一杯大杯的卡布奇诺。” ("Order me a tall Caffè Misto.")

• “给我点一杯大杯冰镇奶茶拿铁和一个黄油可颂。” ("Order me a tall iced chai latte and a butter croissant.")

• “给我一个可颂。” ("Get me a croissant.") (目的是点巧克力可颂)

• “我不确定我想要什么。给我一些基于我过去点过东西的建议。” ("I'm not sure what I want to order. Give me a couple of ideas based on what I've ordered in the past.")

  为了帮助参与者理解用户背景，研究还提供了智能体已知的用户信息：

• 用户在西雅图 Terry Ave N, Seattle, WA 98109 的 Terry & Republican 门店取货。

• 用户在星巴克账户的密码是“REDACTED2025”。

• 用户之前的订单包括生日蛋糕棒、卡布奇诺和星巴克的冷萃咖啡。

5.2. 评估指标

本研究主要采用定性评估方法，而非传统的量化指标。其核心“评估”是验证设计需求和发现用户需求。因此，没有特定的数学评估指标，而是通过以下方式进行：

1. 需求验证 (Validation of Requirements):

   • 通过现场研究观察参与者如何使用 AgentBuilder，以验证在需求启发研究中识别出的五个活动（A1-A5）和六项能力（C1-C6）是否与实际的原型设计过程相符。
   • 对参与者反馈进行编码，以确认这些需求是否得到满足，以及 AgentBuilder 是否能支持这些能力。

2. 需求启发 (Elicitation of Needs):

   • 通过对参与者的 think-aloud 数据和访谈记录进行主题分析（thematic analysis），识别出他们在原型设计过程中遇到的挑战、痛点以及对未来工具的期望。
   • 这些发现进一步细化和补充了最初的设计需求。

3. 可用性评估 (Usability Assessment - Implicit):

   • 尽管没有直接的可用性指标，但通过观察参与者能否成功完成任务、他们遇到的困难以及对 AgentBuilder 界面的评论，间接评估了工具的易用性和有效性。

5.3. 对比基线

本研究旨在探索和验证智能体原型设计系统所需的功能，并构建一个设计探针 AgentBuilder。因此，它没有将 AgentBuilder 的性能与任何现有的智能体原型设计工具进行直接的量化对比。

相反，本研究的“基线”更多体现在：

• 需求启发阶段： 通过与不同智能体经验的参与者访谈，了解他们当前进行智能体原型设计（或设想的）方式，以及现有工具的不足。这构成了对当前实践的“基线”理解。

• 相关工作： 论文在“Related Work”中回顾了现有的一些 LLM 提示开发工具、对话原型设计工具以及智能体开发工具。这些构成了对现有技术能力的“基线”了解，从而凸显了本文 AgentBuilder 在为非专家提供无代码支架以原型设计完整智能体体验方面的差异化和创新性。

  本研究的重点是探索性和验证性，即理解智能体原型设计过程的本质，并验证 AgentBuilder 作为设计探针能否有效地支持这一过程，而不是在性能上超越现有工具。

6. 实验结果与分析

6.1. 核心结果分析

现场原型设计研究的结果表明，AgentBuilder 成功地使所有背景的参与者（无论他们对智能体的熟悉程度如何）都能够原型设计智能体体验。这有力地验证了在需求启发研究中确定的五个活动（Activities，A）和六项所需能力（Desired Capabilities，C）。

研究观察到开发者原型设计智能体的四个迭代步骤：

1. 设计智能体的初始原型： 参与者首先围绕一个设想的用户体验设计智能体的粗略目标。他们探索工作流中的交互组件，并编写自然语言指令，定义智能体如何响应查询、处理边界条件和确定语气。他们也考虑智能体应如何显示信息。
2. 运行和监控智能体： 参与者运行初始原型来测试智能体对不同用户查询的响应，并观察它如何处理各种情况。他们密切监控智能体，审查消息，观察 UI 操作、描述、推理或 UI 操作预览。许多人会激活调试模式来实时查看智能体的推理。
3. 调试智能体： 当智能体遇到意外行为或错误时，参与者会进行调试。他们使用调试模式来理解智能体的行为，例如查看 UI 操作预览以了解智能体在网页上点击了什么。
4. 迭代智能体： 识别缺陷或发现改进智能体体验的方法后，参与者会迭代他们的原型。这通常涉及更新工作流（例如，添加交互节点、修改条件）和提示（例如，添加澄清指令、修改约束）。

对各项能力的验证与深入洞察：

• C1. 使用无代码界面 (Use no-code interfaces):

  • 验证： 所有参与者都使用了 AgentBuilder 的无代码界面来原型设计智能体行为。这表明无代码界面确实降低了门槛，允许不同背景的个体参与。
  • 洞察： 参与者对无代码表示（如工作流）和自然语言提示（如直接修改 WorkFlow Prompt）的使用程度不同。许多人发现自然语言提示能让他们快速配置智能体的交互，而工作流表示则更好地反映了他们的工作实践。然而，参与者也表达了对智能体可修改部分的更多支持需求，有时会感到代理能力受限，未能完全理解可用的选项。

• C2. 帮助限制智能体的任务空间和用户知识 (Help constrain the agent's task space and knowledge of the user):

  • 验证： 即使 AgentBuilder 预填充了 AGENT CAPABILITIES PROMPT 和 USER INFORMATION PROMPT，许多参与者仍会主动修改这些提示。这表明他们积极思考智能体的范围和用户知识，以测试智能体将如何根据约束或对用户个人信息的了解采取行动。
  • 洞察： 这种能力使得参与者能够反思智能体如何处理敏感的用户信息，并意识到他们之前可能忽略的方面（例如，智能体自动插入用户密码）。

• C3. 定义智能体在聊天和环境中的 UI (Define the UI of the agent in the chat and the environment):

  • 验证： 大多数参与者修改了智能体向用户显示的信息。
  • 洞察： 他们的决定受终端用户行为预期和作为开发者的自身需求的双重指导。然而，参与者在智能体运行时很难理解其推理过程。例如，他们看到智能体在网页上暂停，但无法确定它是在思考、已经做出了选择还是在等待页面加载。这表明系统需要提供机制，帮助开发者全面理解智能体过去、现在和预期的行为。

• C4. 提供组件以使智能体能够调用不同的用户交互 (Provide components that enable the agent to invoke different user interactions):

  • 验证： 参与者认为工作流中有限的选项集（如 Interact、Confirmation 节点）帮助他们以更简洁和清晰的方式设计指令。
  • 洞察： 尽管如此，参与者仍然不确定交互组件是否能如他们所设计的那样被交付。他们表达了对可靠地预览和测试不同场景下交互组件的需求。

• C5. 提供运行和控制智能体的环境 (Provide an environment to run and control the agent):

  • 验证： 所有参与者都至少运行和观察了他们的智能体一次，但很少有人使用 CowPilot 中的暂停和恢复功能。
  • 洞察： 在智能体运行时，尽管参与者对网页上的操作非常关注，但许多人难以追踪智能体何时何地与用户聊天或征求输入。这凸显了对界面支持跟踪详细运行时信息和潜在错误的需求，需要以易于理解的格式呈现多个运行时数据源。

• C6. 帮助用户调试智能体的运行时行为 (Help the user debug the agent's runtime behavior):

  • 验证： 大多数参与者使用了 AgentBuilder 的调试模式，发现它在理解智能体行为方面很有帮助。
  • 洞察： 然而，参与者无法修改 AgentBuilder 提供的推理，也无法调整智能体做出决策的方式。这表明调试工具需要更强的交互性和可配置性，以帮助用户理解和调整智能体的决策过程。

6.2. 数据呈现 (表格)

以下是原文 Table 1 的结果，展示了现场原型设计研究中参与者的背景信息：

表格说明：

• PID： 参与者 ID。
• Job Role (职位角色)： 参与者的职业背景，涵盖了软件工程师、设计师、产品经理、机器学习工程师等多样化角色。
• GenAI Usage (生成式 AI 使用频率)： 参与者使用生成式 AI 的频率，从每周一次到每天多次不等，表明所有参与者都是生成式 AI 的用户。
• Prompt Engineering (提示工程经验)： 参与者在提示工程方面的经验水平，从无经验到广泛经验都有。
• Agent Familiarity (智能体熟悉程度)： 参与者对智能体的熟悉程度，从从未使用或见过演示到作为终端用户使用过。

6.3. 消融实验/参数分析

本论文的核心是用户研究和系统设计探针的验证，而不是优化一个模型或算法。因此，论文中没有进行传统的消融实验或参数分析来评估模型组件或超参数的影响。

研究的重点在于：

1. 识别智能体原型设计过程中的关键活动和所需能力。

2. 开发一个工具 (AgentBuilder) 来实例化这些能力。

3. 通过用户研究验证这些能力是否能有效支持智能体原型设计，并发现更深层次的用户需求。

   因此，这里不适用消融实验或参数分析的讨论。

6.4. 设计建议 (Design Implications)

基于研究发现，论文提出了针对智能体原型设计系统的设计建议：

• 使交互组件易于理解、使用和定制 (Make interaction components easy to understand, use, and customize):
  • 交互组件是构建智能体体验的基石。原型设计系统应通过提供预定义的组件、清晰的工具名称和有限的抽象层次来简化这些组件的理解和使用。
  • 系统还应提供机制，让开发者能够预览和测试智能体调用这些交互组件时的行为，并允许他们修改这些组件。
• 允许在显示不同数量智能体运行时信息之间切换 (Allow toggling between presenting different amounts of agent runtime information):
  • 智能体开发者和终端用户对信息的需求不同。开发者需要详细的智能体内部状态和决策过程，而终端用户则关注流畅的体验。
  • 原型设计系统应支持在开发者心态（关注细节）和终端用户心态（关注整体体验）之间切换。这可以通过提供一个可配置的界面来实现，该界面可以显示从最小到最大化的运行时信息，以帮助开发者在不同层面理解智能体行为。
• 启用智能体运行时的审查和定制 (Enable reviewing and customizing the agent's runtime):
  • 参与者对智能体是否会按照设计执行操作感到不确定，并希望在运行时进行干预和调整。
  • 系统应提供“回放”（replay）功能，让开发者能够逐步查看智能体的过去行为。此外，还应允许在运行时对智能体进行编辑或干预，这对于智能体开发中的一个挑战性活动——理解和调整智能体行为——至关重要。

7. 总结与思考

7.1. 结论总结

本文深入探讨了智能体体验的原型设计过程。首先，通过对具有不同智能体经验的个体进行访谈，识别并总结了智能体原型设计所需的五个核心活动和六项关键能力。这些需求构成了构建有效智能体原型设计系统的基础。其次，研究人员基于这些设计需求，开发了一个名为 AgentBuilder 的设计探针，该工具能够支持智能体的设计、开发和执行。最后，通过对 14 名参与者使用 AgentBuilder 进行现场原型设计研究，验证了先前确定的设计需求，并获得了关于开发者在智能体原型设计过程中所面临的需求和挑战的宝贵洞察。这些洞察揭示了开发者需要机制来帮助他们理解和调整智能体的实际执行。基于这些发现，论文提出了面向智能体原型设计系统的设计建议，强调了交互组件的易用性、运行时信息的灵活展示以及运行时审查和定制的重要性。

7.2. 局限性与未来工作

7.2.1. 论文作者指出的局限性

• 样本规模与泛化性： 两次用户研究的样本规模相对较小（分别是 12 人和 14 人），且所有参与者都来自同一家大型科技公司。这可能限制了研究结果向更广泛的智能体开发者群体和开发环境的泛化性。
• 任务特异性： 现场原型设计研究中的任务（星巴克咖啡订购）相对具体。尽管它提供了丰富的交互场景，但可能无法涵盖所有类型的智能体体验原型设计挑战。
• 研究者作为工具构建者： 由于 AgentBuilder 是研究人员自己构建的，因此在研究过程中可能存在无意识的偏见，或者参与者可能受到研究人员预设概念的影响。

7.2.2. 未来工作

论文在“Discussion”部分提出了基于研究发现的设计建议，这些建议也隐含了未来的研究方向：

• 提升交互组件的理解、使用和定制性： 未来工具应进一步简化交互组件的设计和使用，并提供更可靠的预览和测试机制。
• 灵活展示智能体运行时信息： 开发能够根据用户角色（开发者 vs. 终端用户）和需求，动态调整运行时信息显示粒度的系统，以平衡详细调试信息和简洁用户体验的需求。
• 增强智能体运行时的审查和定制能力： 探索更强大的运行时干预和调整机制，例如允许开发者“回放”智能体行为，并在关键决策点进行修改，以更好地理解和控制智能体的执行。

7.3. 个人启发与批判

7.3.1. 个人启发

• AI 开发民主化： 本文最核心的启发在于，AI 智能体的发展不应仅仅是 AI 工程师的领域。通过提供适当的支架和工具，可以将智能体体验的设计能力赋予更广泛的用户群体，包括 UX 设计师、产品经理等。这不仅能加速智能体产品的开发，更能确保产品从设计之初就充分考虑用户需求和潜在风险，从而创造出更人性化、更负责任的 AI 产品。
• 无代码工具的潜力： AgentBuilder 作为设计探针，有力地证明了无代码界面在复杂 AI 系统原型设计中的巨大潜力。它通过图形化的工作流和直观的交互，将复杂的提示工程和智能体逻辑抽象化，使得非技术用户也能快速构建和测试智能体概念。
• UX 在 AI 时代的关键作用： 论文强调了“智能体体验”的重要性，这提醒我们，即使 AI 技术再强大，最终仍需通过优质的用户体验才能真正落地并被用户接受。UX 设计师在定义智能体的范围、交互模式、信息显示和错误处理机制方面，具有不可替代的价值。
• 运行时洞察与调试： 智能体行为的“黑箱”特性是其应用的一大障碍。本文强调了提供运行时洞察和调试能力的重要性，这对于开发者理解智能体决策、诊断问题和建立信任至关重要。这不仅仅是技术问题，更是人机协作和信任构建的基石。

7.3.2. 批判与可改进之处

• 通用性与任务特异性： 尽管论文通过需求启发和现场研究验证了所提出的活动和能力，但研究主要集中在星巴克订购这一特定任务。不同领域（例如，医疗、金融、教育）的智能体可能涉及更复杂的决策流程、更高的风险以及更严格的合规性要求。AgentBuilder 的设计和发现是否能直接泛化到这些更复杂的领域，仍需进一步验证。未来的工作可以考虑在更多样化的任务场景下进行测试。
• 无代码的深层限制： 尽管无代码降低了门槛，但研究中也提到参与者有时感到代理能力被限制，未能完全理解可用的选项。这反映了无代码工具在提供简易性的同时，可能牺牲了一定的灵活性和透明度。未来的系统需要找到更好的平衡点，例如提供“渐进式披露”（progressive disclosure）的设计，允许用户在需要时深入到更底层的配置或代码。
• 智能体推理的透明度与可干预性： 参与者在运行时难以理解智能体的推理过程，且无法直接修改推理。这是 LLM 驱动智能体普遍面临的挑战。未来的工具应探索更高级的“可解释 AI”（XAI）技术，将智能体的内部决策逻辑、权重和证据以更直观、可交互的方式呈现给用户，并允许用户在决策链中进行干预或修正。
• 协作功能： 论文提到了“更广泛的人群”参与原型设计，但 AgentBuilder 作为一个单用户工具的描述更多。考虑到团队协作是现代软件开发的关键，未来的智能体原型设计系统可以集成多用户协作功能，允许不同角色（设计师、产品经理、工程师）在同一平台上共同设计、评论和迭代智能体原型。
• 评估指标的丰富： 作为一个定性研究，本文的结论主要基于访谈和观察。未来可以结合量化指标（如任务完成时间、错误率、用户满意度评分、设计效率等）来更全面地评估原型设计工具的有效性，尤其是在对比不同设计方案或工具迭代时。