多智能体工作台中基于 Schema 动态渲染的 Agentic UI 与表单流转

💡 AI全栈能力映射：第二层（编排层） 面试官考核点：Agent 的输入输出是极度多变的，系统有没有做到模型和业务逻辑解耦？你的平台是硬编码的，还是真正的“编排引擎”？

1. 业务痛点：为什么不能写死前端组件？

在多智能体编排层（Orchestration），我们允许用户定义各种不同的 Agent 节点（比如：需求分析专家、代码审查员、数据库设计师）。 每一个 Agent 节点的：

1. 输入配置不一样（比如代码审查员需要提供 github_token 和 review_strictness，而数据库设计师需要提供 db_dialect）。
2. 输出结构不一样（有的输出 Markdown 报告，有的输出 JSON 格式的 Schema 表结构）。

如果在前端为每一种 Agent 都硬编码一套表单组件和展示组件，这系统根本没法维护，也无法支持未来的自定义插件扩展。这就违背了“全栈架构”中高扩展性的原则。

2. 架构设计：UI 即数据 (UI as Data) 与 Schema 驱动

我们要实现的是一套纯数据驱动的动态界面体系：后端的编排定义了一切，前端只是一个解释渲染引擎。

策略 1：JSON Schema 定义输入边界

• 契约先行：后端编排引擎为每个 Agent 类型注册一份标准的 JSON Schema。
• 动态渲染：前端引入类似 @rjsf/core (React JSON Schema Form) 的动态表单渲染引擎。当用户选中一个 Agent 节点时，前端拉取它的 Schema，引擎自动将其转换成带校验规则的输入表单。
• 这样，新增任何一种 Agent 工具或配置，前端都不需要改一行代码，完全实现了业务逻辑与视图解耦。

策略 2：Agentic UI 与动态卡片渲染

当 Agent 执行完毕，返回结构化数据时，前端如何呈现？

• 类型注册表 (Registry Pattern)：前端维护一个展示组件的注册表（如 MarkdownRenderer, CodeDiffViewer, JSONTree, MermaidChart）。
• 基于 MIME-Type 的智能路由：Agent 返回的产物（Artifact）必须带有元数据标识（比如 type: "application/vnd.mermaid"）。前端根据这个标识，动态路由到对应的渲染组件。这就构成了所谓的 Agentic UI（随内容自适应的智能界面）。

策略 3：安全的表达式沙箱

在编排流转中，往往需要配置前置条件（如：当 review_score < 60 时流转到重写节点）。

• 这些条件通常以简单的 JavaScript 表达式或自定义 DSL 形式存在。
• 前端需要提供一个安全的沙箱（Sandbox）或解析引擎（如基于 estree 的安全求值器）来执行这些验证逻辑，防止恶意脚本注入。

3. 面试话术模板 (怎么跟面试官讲)

“在设计我们的多智能体编排层时，我非常坚决地推行了 UI 即数据 (UI as Data) 的架构。因为 Agent 的类型和工具是无限扩展的，如果前端硬编码表单，系统就会僵死。

我们的做法是，所有的 Agent 配置项都由后端统一下发 JSON Schema，前端基于 Schema 引擎动态渲染表单并接管校验规则。同样地，Agent 产出的结构化数据也会附带类型元数据，前端通过组件注册表进行智能路由，动态渲染成图表、代码块或富文本卡片。这种基于 Schema 协议和组件注册表的架构，让我们做到了底层逻辑和视图表现的彻底解耦。之后后端无论新增什么千奇百怪的 Agent 节点，前端都不需要发版就能完美承接，这才是工业级编排平台该有的扩展性。”

4. 总结与延展

这个话题向面试官传达了一个强烈的信号：你具备抽象能力和平台化思维。你不是在实现一个“页面”，你是在实现一个能够自我衍生的前端渲染引擎。这种能力是高级前端和架构师的核心差异。