前言
在构建 AI Agent 框架的过程中，基础节点的实现与 gRPC 服务的暴露只是第一步。手动编辑文本配置 Workflow 不仅效率低下，且容易出错。为了提升开发体验与运维效率，我们需要一个可视化的 Web UI 来自动生成和管理 Workflow。
本文将详细介绍如何基于 Rust 的 egui 库，从零开始设计并实现一个支持 Agent/Workflow 的在线编辑器，涵盖界面设计、插件系统架构及核心功能实现。
竞品分析与设计目标
在设计之前，我们分析了现有的主流工具，以明确我们的差异化优势。
Dify 的 UI
Dify 提供了丰富的功能节点，支持多种模型和工具的集成。其优点在于能够打开单个节点的详细内容，并提供 Debug 能力，让用户看到执行细节。但缺点是只能一次查看一个节点的详情，难以把握整体流程。
Coze 的 UI
Coze 的界面交互更加丝滑，支持在编辑页直接查看节点细节，Debug 信息也绑定在节点上。然而，当节点数量增多时，操作难度显著增加，视觉负担较重。
ComfyUI (Stable Diffusion)
ComfyUI 采用了更自由的节点设计，变量间相互链接而非单纯的流转。这种模式灵活性极高，但也带来了维护困难的问题，节点多了之后极难梳理逻辑。
设计目标
综合上述分析，本项目的 UI 设计遵循以下原则：
- 全局视图：能够清晰看到整体节点的流转关系，同时每个界面可以单独打开或关闭（参考 Dify）。
- 调试能力：必须提供 Debug 功能，最好像 Coze 一样直接绑定到节点上，实时反馈执行状态。
- 开放定义：节点的界面设计采用开放式结构，允许用户随意定义输入输出参数及 UI 组件类型（参考 ComfyUI）。
功能预览与操作指南
服务启动后，主要包含以下几个核心区域：
- 顶边控制栏：包含 Project、Setting、About 菜单。点击 Project 会在左侧生成控制界面，用于加载项目的 Service 节点。
- 编辑窗口：
- FlowChart、LLM Script、Workflow 均为具体的服务节点。
- 红色 Clean：清理所有已生成的节点。
- 红色 Reset：重置整个界面状态。
- 绿色 Save：保存配置，默认 30 秒自动保存，时间可在 Project 界面调整。
- 绿色 Debug：执行一次流程调试。
- 右侧节点列表：展示所有可用节点，可在此打开/关闭节点视图或删除节点。
- 底部日志区：显示运行日志，支持展开查看详情。
此外，提供两个关键视图：
- Work-flow-view：查看节点间的流转关系图。
- Plan-text-view：查看执行计划，支持下载所有生成的节点配置，或上传节点配置（会覆盖当前配置）。
窗口设计与数据结构
窗口的结构目前固定为五部分，未来可扩展。每个节点包含以下元数据：
- 节点编号与描述
- Service 类型
- Input（输入参数结构）
- Output（输出参数结构）
- Goto（向哪些节点流转）
- Debug（调试信息）
插件配置示例
所有的视图配置都在 webui/server/plugin 目录下。当点击 Project -> LOAD 按钮时，系统会默认加载该目录下的全部配置。
以下是一个 OpenAI LLM 节点的 JSON 配置示例，展示了如何通过 Schema 定义 UI 控件：
{
"plugin_list": [
{
"code": "openai-LLM",
"class": "LLM",
"desc": "openai LLM chat",
"ui_type": "window",
"service_type": "openai_llm",
"input_vars": {
"model": {
"type": "string",
"default": "gpt-3.5-turbo",
"ui_type": "enum",
"ui_extend_enum": [
"gpt-4o",
"gpt-4-turbo",
"gpt-4",
"gpt-3.5-turbo"
该配置定义了模型的枚举选择、温度参数的滑块范围、Token 数量的数值输入以及 Prompt 的多行文本框。系统根据 ui_type 字段动态渲染对应的 egui 控件。
代码实现架构
本项目采用前后端分离的架构，具体实现如下：
-
后端服务 (
webui/server)：- 使用 Go 语言编写，作为一个微小的服务端存在。
- 负责插件加载、配置管理以及 Debug 调用的路由分发。
- 通过
go run main.go即可启动服务。
-
前端界面 (
webui)：- 基于 Rust 的
egui库开发，实现了跨平台桌面应用。 - 支持作为原生应用打开，也可编译为 WASM 在浏览器中运行（需使用
trunk启动）。 - 界面逻辑主要通过
update循环驱动，根据状态机更新 UI 元素。
- 基于 Rust 的
-
通信协议：
- 前端与后端通过 HTTP/gRPC 进行通信，传递节点配置与执行结果。
- 插件配置采用 JSON Schema 标准，确保扩展性。
技术难点与解决方案
动态表单渲染
由于不同节点需要不同的输入控件（如 Enum、Slider、Text），我们设计了通用的解析器。前端读取 input_vars 中的 ui_type 字段，映射到 egui 的标准控件。例如，ui_extend_slider 定义了最小值、最大值和步进速度，解析器据此创建带范围的滑动条。
状态同步
为了保证多节点间的状态一致性，我们引入了中央状态管理器。任何节点的修改都会触发全局状态更新，并通过 WebSocket 或轮询机制通知其他相关节点刷新。这解决了传统工作流编辑器中常见的状态不一致问题。
性能优化
当节点数量较多时，重绘开销巨大。我们采用了局部更新策略，仅重新绘制发生变化的节点区域，并利用 egui 的内存池机制减少分配次数，确保流畅度。
总结与展望
目前实现的 UI 版本已经具备基本可用性，简洁高效。整个 ai_agent 框架在设计思路上参考了 BaaS Solution 理念，即在 Web UI 上设计好流程后，生产环境部署时无需依赖 Web UI，直接通过 API 调用执行。
当然，如果你觉得当前界面风格无法满足需求，架构本身是开放的，开发者可以自行替换 UI 层，只需保持插件配置格式一致即可。未来我们将进一步优化节点连接体验，引入更多可视化调试工具，并支持自定义脚本节点的嵌入。
通过这套方案，我们成功将复杂的 Agent 编排过程图形化，降低了使用门槛，同时保留了高度的灵活性与可扩展性。
