AI 智能对话 — 右侧组件面板

1.1 业务背景

平台为企业提供 AI 智能对话能力，对话窗口（左侧）已定义清晰的输入形态（文本/文件/图片/视频/压缩包）。目前 AI 回复仅以纯文本/Markdown 呈现，无法承载结构化业务输出（表格、图表、表单、审批流等），导致用户需要离开对话界面去业务系统操作，体验断裂。

1.2 核心问题

• 输出形态单一 — 文本无法满足数据查询、流程操作、可视化等场景
• 缺少交互闭环 — 用户看到 AI 建议后无法在同一界面直接操作
• 场景扩展成本高 — 每新增一种输出都需要前后端联合定制开发

1.3 目标

量化指标：

• 新场景接入零前端开发（只写 Dify 工作流 / Skill 定义）
• Phase 1 覆盖 80% 高频办公场景
• 用户单次对话完成率提升 ≥ 40%

2.1 分层架构

2.2 核心数据流（四阶段）

2.3 前端渲染层核心组件职责

右侧面板的渲染能力由四个解耦组件协作完成，新增组件类型只需向 Renderer Registry 注册，不改动其余三者：

2.4 渲染时序

从用户发送消息到 artifact 可交互，前端走如下时序，关键点是文本与 artifact 分离投递：

2.5 状态管理与上下文回流

artifact 不是一次性渲染的死图，而是与会话绑定的活动状态。State Manager 维护三类状态，保证用户操作能反馈给 AI：

2.6 技术选型与边界

3.1 顶层结构

{
  "message": "AI 的文本回复（展示在左侧对话）",
  "artifacts": [
    {
      "id": "artifact_001",
      "type": "table | chart | kpi | form | checklist | markdown | ...",
      "title": "费用明细",
      "data": { /* type-specific payload */ },
      "actions": [
        { "label": "导出Excel", "action": "download", "params": {} },
        { "label": "筛选", "action": "filter", "params": {} }
      ],
      "meta": {
        "source": "finance_query_skill",
        "timestamp": "2024-05-15T10:30:00Z",
        "ttl": 3600
      }
    }
  ]
}

3.2 各 type 的 data 结构

3.3 Action 协议（交互回流）

// 用户在右侧面板点击按钮/提交表单时，前端生成：
{
  "role": "user",
  "type": "artifact_action",
  "artifact_id": "artifact_001",
  "action": "submit",
  "content": "[用户操作] 在「报销申请」中提交了表单",
  "metadata": {
    "type": "artifact_action",
    "artifact_id": "artifact_001",
    "action": "submit",
    "params": {
      "expense_type": "差旅费",
      "amount": 4560,
      "date": "2024-05-08"
    },
    "request_id": "req_8f3a2b"
  }
}
// → 和用户手动打字走同一条 sendMessage 通道
// → 对网关和 Dify 来说，这就是一条新的用户消息

3.4 交互回流保障机制

右侧面板的用户操作能否可靠传递到模型/智能体并触发下一步，是方案成立的核心前提。保障分三层：

第一层：前端 — Action 标准化收口

// 所有面板交互统一通过 onAction 收口
function handleArtifactAction(artifact, action, params) {
  const actionMessage = {
    role: "user",
    content: `[用户操作] 在「${artifact.title}」中执行了「${action.label}」`,
    metadata: {
      type: "artifact_action",
      artifact_id: artifact.id,
      action: action.action,
      params: params,
      request_id: generateUUID() // 幂等键
    }
  };
  // 和普通对话消息走完全相同的 sendMessage 函数
  sendMessage(actionMessage);
}

第二层：Dify 工作流 — 智能路由

# 工作流入口的 Code 节点 — 判断消息来源
def route_input(message):
    metadata = message.get("metadata", {})
    if metadata.get("type") == "artifact_action":
        # 结构化操作 → 直接路由到对应 Skill，跳过意图识别
        return {
            "route": "skill_direct",
            "skill": resolve_skill_by_artifact(metadata["artifact_id"]),
            "action": metadata["action"],
            "params": metadata["params"]
        }
    else:
        # 普通文本 → 正常走意图识别 LLM 节点
        return {"route": "intent_classify"}

关键：artifact_action 类型的消息绕过 LLM 意图识别直接路由到 Skill，既省 token 又保证确定性。

第三层：可靠性保障

完整回流链路一览

4.1 五大分类 · 33 种组件

4.2 Renderer Registry 注册机制

// 前端注册一个新渲染器
rendererRegistry.register('table', {
  component: TableRenderer,
  validator: (data) => data.columns && data.rows,
  fallback: 'markdown'  // 验证失败时降级渲染
});

// 收到 artifact 后的调度逻辑
function renderArtifact(artifact) {
  const renderer = rendererRegistry.get(artifact.type);
  if (!renderer) return rendererRegistry.get('markdown'); // 兜底
  if (!renderer.validator(artifact.data)) {
    return rendererRegistry.get(renderer.fallback);
  }
  return renderer.component(artifact);
}

5.1 现状：多智能体相互隔离

平台目前已有多个独立智能体，每个智能体是一个垂直领域的"专家"——接收用户输入后，自主理解意图并自动跑完它所负责的那条业务流程（多步骤编排），最终产出业务结果。但智能体之间当前是隔离孤岛：

5.2 统一输出层：组件面板作为所有智能体的共同出口

无论用户当前在哪个智能体对话，AI 的结构化产出都遵循同一套 Artifact JSON Schema（见第 3 章），渲染到同一个右侧组件面板。这让"多智能体隔离"与"体验一致"两者并不矛盾：

5.3 从隔离到协同的演进路径

统一输出层只是第一步。在 Artifact 协议落地后，多智能体可沿如下三阶段渐进打通，每一阶段都不破坏前一阶段的隔离保证：

5.1 为什么需要 Skill 方案

Dify 工作流适合 AI 编排逻辑，但在以下场景存在局限：

5.2 Skill 输出 Schema 声明

# skill.yaml
name: finance_query
version: 1.2.0
description: 财务数据查询与报表生成

input_schema:
  type: object
  properties:
    query_type: { type: string, enum: [expense, revenue, budget] }
    date_range: { type: object, properties: { start: {type: string}, end: {type: string} } }
    department: { type: string }

output_schema:
  artifacts:
    - type: table
      data_schema:
        columns: { type: array, items: { properties: { key: {type: string}, label: {type: string} } } }
        rows: { type: array }
      actions: [download, filter, sort]
    - type: kpi
      data_schema:
        items: { type: array, items: { properties: { label: {}, value: {}, delta: {} } } }

triggers:
  - intent: ["查费用", "报销记录", "预算"]
  - entity: ["expense", "budget", "revenue"]

5.3 Skill 执行流（与 Dify 协同）

5.4 Skill vs Dify 选型建议

6.1 开发者视角：新增一个场景需要做什么

6.2 智能体开发平台集成点

6.3 前端 Renderer 的开发流程

// 1. 创建渲染器文件
// src/renderers/ApprovalRenderer.tsx

// 2. 实现组件（接收标准 data + actions）
function ApprovalRenderer({ data, actions, onAction }) {
  return (
    <div className="approval-flow">
      {data.steps.map(step => (
        <StepCard key={step.name} {...step} />
      ))}
      {actions.map(act => (
        <Button onClick={() => onAction(act)}>{act.label}</Button>
      ))}
    </div>
  );
}

// 3. 注册到 Registry
rendererRegistry.register('approval', {
  component: ApprovalRenderer,
  validator: (data) => Array.isArray(data.steps),
  fallback: 'markdown'
});

7.1 三期交付路线

7.2 里程碑

8.1 关键依赖

8.2 风险与应对

8.3 开源参考