1. 项目背景与目标
1.1 背景
2025-2026 年，AI Agent 编排平台已从实验性工具演变为企业核心基础设施。Gartner 预测，到 2028 年，超过 50% 的企业应用将包含 AI Agent 能力。当前行业正在发生以下关键变化：
- 从单 Agent 到多 Agent 协作: 扣子 3.0 提出「AI 团队」架构，Dify 支持 Agent Node 嵌套编排，LangGraph 强化分布式 Agent 通信。
- MCP 协议成为标准化底座: Anthropic 推出的 Model Context Protocol 正在成为 AI 工具互操作的事实标准，Dify、n8n、扣子等主流平台均已支持。
- 从 Demo 到 Production: AI Agent 的可靠性、可观测性、成本控制成为工程化落地的核心瓶颈。93% 的 Agent 项目在投产前失败。
现有工作流引擎需要系统性地集成 AI 能力，从传统自动化引擎升级为 AI-Native 编排平台。
1.2 目标
| 维度 |
目标 |
| 能力增强 |
在不破坏现有工作流引擎的基础上，系统性地注入 LLM 调用、RAG 检索、Agent 推理、多 Agent 协作等 AI 原生能力 |
| 开发者体验 |
提供可视化 + 代码双模式，降低 AI Agent 构建门槛，支持从简单 Chatbot 到复杂多 Agent 系统的全梯度构建 |
| 生产可靠性 |
内置可观测性、评估体系、Human-in-the-Loop 控制，确保 AI 工作流在真实业务场景中稳定运行 |
| 生态开放性 |
全面拥抱 MCP 协议，支持多模型、多向量库、多工具的可插拔架构 |
2. 市场分析与竞品对标
2.1 核心竞品能力矩阵
| 能力维度 |
Dify |
扣子 (Coze) 3.0 |
n8n |
LangGraph |
本产品目标 |
| 可视化工作流 |
★★★★★ 画布编排 |
★★★★ 节点编排 |
★★★★★ 拖拽+代码 |
★★★ Studio IDE |
★★★★★ 可视化+代码混合 |
| LLM 多模型 |
★★★★★ 100+ 模型 |
★★★★ 字节生态+第三方 |
★★★★ 主流模型 |
★★★★★ 全模型 |
★★★★★ 全模型网关 |
| 知识库 RAG |
★★★★★ 混合检索 |
★★★★ 基础 RAG |
★★★★ 向量存储 |
★★★ 需自行构建 |
★★★★★ 企业级 RAG |
| 多 Agent 协作 |
★★★ Agent Node |
★★★★★ Agent Team |
★★★★ 多 Agent |
★★★★★ 图编排 |
★★★★★ 多模式协作 |
| MCP 支持 |
★★★★ MCP Server |
★★★★ SDK 支持 |
★★★★ 原生支持 |
★★★★★ 原生支持 |
★★★★★ 双向 MCP |
| 可观测性 |
★★★★ 内置监控 |
★★★ 基础日志 |
★★★★ 执行日志 |
★★★★★ LangSmith |
★★★★★ 全链路追踪 |
| Human-in-Loop |
★★★ 审批节点 |
★★★ 对话交互 |
★★★★ 审批步骤 |
★★★★★ 原生 API |
★★★★★ 多层人机协同 |
| 企业部署 |
★★★★ 私有化 |
★★★ 云端为主 |
★★★★★ 自托管 |
★★★★ 混合部署 |
★★★★★ 全模式部署 |
2.2 趋势洞察
- Agentic Workflow 成为主流范式: 从固定流（确定性）与 Agent 流（自主推理）的混合编排是行业共识。Dify 称之为「Agentic Workflow」，LangGraph 强调「deterministic + agentic」混合。
- MCP 取代自定义集成: MCP 协议快速标准化，已成为连接 AI Agent 与外部工具的默认方式。平台需要同时作为 MCP Client（消费外部工具）和 MCP Server（暴露自身能力）。
- 多 Agent 协作进入工程化: 扣子 3.0 的「Agent Team」和 LangGraph 的「Remote Graph」代表了两种多 Agent 协作路径——中心化调度和分布式图编排。
- 评估体系成为竞争壁垒: 无评估 = 无生产。Agent 行为评估（LLM-as-Judge）、回归测试套件、成本/延迟预算管理成为必备能力。
2.3 差异化机会
现有产品在以下维度仍有空白：
- 工作流引擎原生 AI 化: 大多数 AI 编排平台是从 AI 侧起步，缺乏成熟的流程引擎（如 BPMN 支持、企业级审批流程、SLA 管理）。在成熟工作流引擎基础上增加 AI 能力，可兼顾传统自动化场景与 AI 场景。
- 深度人机协同: 在审批、合规、高价值决策等场景中，AI Agent 的判断需要人类确认。本产品可深度融合审批流 + AI 决策。
- 全链路评估与优化: 从 Prompt 版本管理、A/B 测试、生产环境回归到成本优化，提供闭环的 Agent 运维能力。
3. 产品定位与核心策略
3.1 产品定位
AI-Native 的企业级工作流编排平台 — 在成熟工作流引擎基础上，集成 AI 全栈能力，覆盖从简单自动化到复杂多 Agent 系统的全场景。
3.2 核心设计原则
- 渐进式 AI 化: 用户可在现有工作流中逐步引入 AI 能力——先加一个 LLM 节点试试，再扩展到 RAG、Agent、多 Agent，不需要一次性重构。
- 可视化优先，代码不设限: 默认提供可视化编排，但每个 AI 节点都开放代码模式（Python/JS），让专业开发者不被 UI 束缚。
- 可靠性内建: 每个 AI 节点自带重试、降级、超时、输出校验能力；整个工作流具备可观测、可回溯、可评估的完整能力。
- 协议驱动: 以 MCP 作为模型与工具的连接标准，以 A2A 作为 Agent 间通信标准，避免供应商锁定。
3.3 能力分层
┌─────────────────────────────────────────────┐
│ 第四层：多 Agent 协作 │
│ Agent Team · Supervisor · Swarm · Debate │
├─────────────────────────────────────────────┤
│ 第三层：智能 Agent │
│ ReAct · Plan-Execute · 工具调用 · 记忆 │
├─────────────────────────────────────────────┤
│ 第二层：AI 增强自动化 │
│ 知识库 RAG · 意图识别 · 内容生成 · 分类 │
├─────────────────────────────────────────────┤
│ 第一层：基础 AI 能力 │
│ LLM 调用 · Prompt 管理 · 多模型切换 │
├─────────────────────────────────────────────┤
│ 第零层：现有工作流引擎 │
│ 流程编排 · 触发器 · 条件逻辑 · 集成连接 │
└─────────────────────────────────────────────┘
4. AI 功能模块详细设计
4.1 LLM 模型网关
4.1.1 功能概述
统一模型接入层，屏蔽不同 LLM 提供商的 API 差异，提供一致的调用接口、流式响应、成本追踪和故障转移能力。
4.1.2 核心能力
| 能力 |
描述 |
| 多提供商接入 |
支持 OpenAI、Anthropic、Google Gemini、Azure OpenAI、DeepSeek、Qwen、GLM、Llama（Ollama/vLLM 私有部署）等 30+ 提供商 |
| 模型路由 |
按成本、延迟、能力自动路由到最优模型。例如：简单分类任务走便宜模型，复杂推理走高端模型 |
| 故障转移 |
主模型不可用时自动切换到备用模型，支持提供商级别和模型级别的 fallback 链 |
| 流式响应 |
原生支持 SSE 流式输出，节点间可传递流式数据，前端实时渲染 |
| 成本追踪 |
每个节点记录 token 消耗和费用，工作流运行结束后生成完整的成本报告 |
| 速率控制 |
支持 API 级别的速率限制（QPM/TPM），避免触发提供商限流 |
| 多模态支持 |
统一处理文本、图片、音频输入/输出，支持视觉模型的图片理解 |
4.1.3 配置界面
┌─────────────────────────────────────────────┐
│ 模型网关配置 │
│ ┌─────────────────────────────────────────┐ │
│ │ 模型提供商 │ │
│ │ [OpenAI] [Anthropic] [DeepSeek] │ │
│ │ [Azure OpenAI] [Qwen] [GLM] [+添加] │ │
│ ├─────────────────────────────────────────┤ │
│ │ 路由策略 │ │
│ │ ○ 指定模型 │ │
│ │ ○ 智能路由 (按成本/延迟/能力) │ │
│ │ ● 故障转移链 │ │
│ │ [GPT-4o] → [Claude-3.5] → [DeepSeek] │ │
│ ├─────────────────────────────────────────┤ │
│ │ 参数默认值 │ │
│ │ Temperature: [0.7 ] │ │
│ │ Max Tokens: [4096 ] │ │
│ │ Top P: [0.9 ] │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
4.2 AI Agent 节点
4.2.1 功能概述
AI Agent 节点是本平台的核心差异化节点。它封装了 LLM 推理 + 工具调用 + 迭代循环的完整 Agent 模式，用户在画布上只需配置 Agent 的系统提示、可用工具和推理策略，即可创建一个能自主决策和行动的智能体。
4.2.2 Agent 策略
| 策略 |
描述 |
适用场景 |
| ReAct (默认) |
思考→行动→观察→循环，最通用的 Agent 模式 |
需要工具调用的通用任务 |
| Function Calling |
利用模型原生的 Function Call 能力，结构化工具调用 |
明确工具集的简单任务 |
| Plan-Execute |
先制定计划，再分步执行，每步可重新规划 |
复杂的多步骤任务 |
| Reflection |
执行后自我评估和修正 |
需要高质量输出的内容生成 |
| Multi-Step Tool |
支持并行调用多个工具 |
信息检索类任务 |
| 自定义策略 |
通过插件机制扩展，支持 LangGraph 图导入 |
高级自定义场景 |
4.2.3 Agent 节点配置
Agent 节点配置示例:
name: "智能客服 Agent"
system_prompt: |
你是一个专业的智能客服，负责回答用户关于产品的问题。
如果问题超出你的知识范围，请使用知识库搜索工具。
如果用户要求退款，请使用退款申请工具并引导到人工客服。
strategy: "react"
model: "smart-router"
tools:
- knowledge_search
- order_query
- refund_apply
- transfer_to_human
memory:
type: "conversation"
window: 20
constraints:
max_iterations: 10
timeout: 120
output_schema: {...}
human_approval: ["refund_apply"]
fallback:
on_error: "retry"
max_retries: 3
on_exhaustion: "transfer_to_human"
4.2.4 可视化画布表现
- Agent 节点在工作流画布中以特殊样式呈现（区别于普通处理节点）
- 展开 Agent 节点可查看其内部的推理循环和工具调用子流程
- 运行时可实时观察 Agent 的思考链（Chain of Thought），每一步的工具调用和推理结果可视化展示
4.3 知识库与 RAG 引擎
4.3.1 功能概述
构建企业级 RAG（检索增强生成）能力，让 AI Agent 能够基于企业私有知识进行精准回答。
4.3.2 架构设计
输入文档 → 文档解析 → 智能分块 → 向量嵌入 → 向量数据库
↓
用户查询 → 查询重写 → 混合检索 → 重排序 → 上下文组装 → LLM 生成
4.3.3 核心能力
| 模块 |
能力 |
描述 |
| 文档管理 |
多格式导入 |
支持 PDF、Word、Excel、PPT、HTML、Markdown、TXT、CSV、图片（OCR）、网页 URL |
|
自动同步 |
对接 Google Drive、SharePoint、飞书文档、语雀等，定时增量同步 |
|
元数据管理 |
自动提取文档标题、作者、日期等元数据，支持自定义标签 |
| 智能分块 |
递归分块 |
基于语义边界的分块策略（按段落、按标题、按语义） |
|
父子分块 |
检索时返回父块上下文，避免信息截断 |
|
自定义分块 |
支持按字符数、token 数、正则表达式的灵活配置 |
| 向量化 |
多模型支持 |
OpenAI Embedding、BGE、M3E、Jina 等嵌入模型 |
|
模型切换 |
知识库维度可动态切换嵌入模型，无需重建 |
| 检索策略 |
混合检索 |
BM25 关键词检索 + 向量语义检索的加权混合 |
|
查询重写 |
用 LLM 将用户查询改写为更精确的检索查询 |
|
多路召回 |
同时从多个知识库检索，合并排序 |
|
ReRank 重排序 |
对初检结果用 Cross-Encoder 模型精排 |
| 集成 |
RAG 节点 |
工作流中的独立检索节点，可被任意 Agent 调用 |
|
Agent 工具 |
将知识库暴露为 Agent 的 Tool，Agent 自主决定何时检索 |
4.3.4 支持的向量数据库
- Milvus / Zilliz Cloud
- Qdrant
- Weaviate
- Pinecone
- pgvector (PostgreSQL)
- Elasticsearch (作为关键词检索引擎)
4.4 多 Agent 协作编排
4.4.1 功能概述
多 Agent 协作能力使多个专门的 Agent 可以像团队一样协同完成复杂任务。参考扣子 3.0 的 Agent Team 和 LangGraph 的分布式编排，提供三种协作模式。
4.4.2 协作模式
模式 1: Supervisor（监督者模式）
┌──────────┐
│Supervisor│ ← 主控 Agent，负责任务分解和分配
└────┬─────┘
┌────────────┼────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│Research │ │ Writer │ │ Reviewer │
│Agent │ │ Agent │ │ Agent │
└──────────┘ └──────────┘ └──────────┘
- 一个 Supervisor Agent 负责任务分解、子任务分配、结果汇总
- 适合：需要统一规划和调度的复杂任务
- 控制流：中心化调度，Supervisor 决定每一步由谁执行
模式 2: Swarm（群体协作模式）
┌──────────┐ 交接 ┌──────────┐ 交接 ┌──────────┐
│ 售前 │ ──────────→ │ 技术 │ ──────────→ │ 售后 │
│ Agent │ │ Agent │ │ Agent │
└──────────┘ └──────────┘ └──────────┘
- Agent 之间通过「交接」（handoff）传递任务上下文
- 每个 Agent 有自己的专长领域，遇到不擅长的自动交接
- 适合：多轮对话中需要不同专家角色的客服场景
- 控制流：去中心化，Agent 自主决定何时交接
模式 3: Graph（图编排模式）
┌─────────────────┐
│ 任务入口 │
└────────┬────────┘
│
┌────────▼────────┐
│ 并行检索 │
└────────┬────────┘
┌────────────┼────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Web搜索 │ │ 知识库 │ │ 数据库 │
│ Agent │ │ Agent │ │ Agent │
└────┬─────┘ └────┬─────┘ └────┬─────┘
└────────────┼────────────┘
┌────────▼────────┐
│ 结果融合 │
└────────┬────────┘
┌────────▼────────┐
│ 质量审核 │ ← Human-in-Loop
└────────┬────────┘
┌────────▼────────┐
│ 输出 │
└─────────────────┘
- 在画布上用图来编排多个 Agent 的协作流程
- 支持并行执行、条件分支、循环迭代
- 每个节点可以是 Agent、LLM 调用、代码、人工审批
- 适合：需要精确控制执行流程的复杂业务场景
4.4.3 多 Agent 通信协议
| 维度 |
方案 |
| Agent 间通信 |
通过共享 State（状态对象）在 Agent 间传递上下文 |
| 消息格式 |
标准化消息结构（role + content + metadata） |
| 上下文传递 |
自动压缩和摘要长对话历史，控制每个 Agent 的输入长度 |
| 跨进程通信 |
支持 Remote Agent，通过 HTTP/gRPC 调用外部 Agent 服务 |
| A2A 协议 |
预留 Agent-to-Agent 标准协议接口 |
4.5 记忆与会话管理
4.5.1 记忆层级
┌──────────────────────────────────────────────────┐
│ 长期记忆（Long-term Memory） │
│ 跨会话持久化的用户画像、偏好、知识 │
│ 存储: 向量数据库 + 结构化存储 │
├──────────────────────────────────────────────────┤
│ 会话记忆（Conversation Memory） │
│ 单次会话内的完整对话历史 │
│ 存储: Redis/内存 + 持久化备份 │
├──────────────────────────────────────────────────┤
│ 工作记忆（Working Memory） │
│ Agent 当前任务相关的临时上下文 │
│ 存储: Agent 运行时内存 │
└──────────────────────────────────────────────────┘
4.5.2 记忆管理策略
| 策略 |
描述 |
使用场景 |
| Buffer Memory |
保存完整对话历史 |
短对话 |
| Window Memory |
只保留最近 N 轮对话 |
中等长度对话 |
| Summary Memory |
用 LLM 自动摘要历史对话 |
长对话 |
| Vector Memory |
将历史对话向量化，按相关性检索 |
需要检索历史信息的场景 |
| Entity Memory |
抽取并持久化实体信息（如用户姓名、偏好） |
个性化服务 |
4.5.3 记忆节点配置
┌─────────────────────────────────────────────┐
│ 记忆配置 │
│ ┌─────────────────────────────────────────┐ │
│ │ 记忆类型: │ │
│ │ [✓] 短期记忆 (窗口: 20轮) │ │
│ │ [✓] 摘要记忆 (触发: 每10轮自动压缩) │ │
│ │ [ ] 实体记忆 │ │
│ │ [✓] 向量长期记忆 │ │
│ │ │ │
│ │ 记忆隔离策略: │ │
│ │ ● 按会话隔离 │ │
│ │ ○ 按用户隔离 (跨会话) │ │
│ │ ○ 按自定义 Key 隔离 │ │
│ │ │ │
│ │ 数据保留: [90天 ▼] │ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
4.6 Human-in-the-Loop 人机协同
4.6.1 功能概述
在 AI Agent 自主执行的关键节点，引入人类审批、确认、修正和引导，确保高价值决策的安全性。这是本产品相比纯 AI 编排平台的核心差异化能力。
4.6.2 人机协同模式
模式 1: 审批拦截（Approval Gate）
Agent 执行 → [工具调用:退款操作] → ⏸ 暂停，等待审批 → 人工通过/拒绝 → 继续/回退
- Agent 在执行某些高风险工具调用前，必须先获得人类批准
- 可配置审批规则：按工具类型、按金额阈值、按置信度阈值
- 超时自动降级（拒绝/通过/转人工处理）
模式 2: 修正引导（Human Guidance）
Agent 输出 → 人工审核 → 修正/补充 → Agent 基于修正继续执行
- 人类可以在 Agent 执行的任意中间步骤介入，修正输出或提供引导
- Agent 接收人类反馈后，调整后续的推理和行为
模式 3: 双轨审核（Dual-Track Review）
┌──────┐ ┌──────┐
输入 → │AI 轨 │ │人工轨│ → 对比 → 选择/融合 → 输出
└──────┘ └──────┘
- AI 和人工同时处理同一任务
- 对比结果，AI 学习人工的决策模式
- 适用于高精度的内容审核、合规审查场景
模式 4: 人机接力（Human-Agent Handoff）
Agent 处理 ──→ 遇到无法处理的场景 ──→ 转人工 ──→ 人工处理后交接回 Agent
- 完整的任务交接机制：上下文打包、状态保留、SLA 管理
4.6.3 交互载体
| 载体 |
描述 |
场景 |
| 工作流内审批节点 |
在流程画布中插入审批节点 |
业务流程中的固定审批点 |
| Agent 运行时弹窗 |
Agent 执行到需要确认的步骤时弹窗 |
Agent 工具调用的动态审批 |
| 协作看板 |
集中展示所有待处理的人工任务 |
客服、运营批量处理场景 |
| IM 集成 |
通过企业微信/钉钉/飞书推送审批通知 |
移动办公场景 |
4.7 工具生态与插件体系
4.7.1 功能概述
Agent 的能力边界由它可用的工具决定。构建丰富的工具生态和插件体系，让 Agent 能够与各种外部系统交互。
4.7.2 工具类型
| 类型 |
示例 |
配置复杂度 |
| 内置工具 |
Web 搜索、计算器、代码执行器、时间日期 |
零配置 |
| API 工具 |
HTTP 请求、GraphQL、gRPC 调用 |
低（填 URL + 参数） |
| 数据库工具 |
MySQL、PostgreSQL、MongoDB、Elasticsearch |
中（填连接串） |
| SaaS 集成 |
Gmail、Slack、飞书、Notion、Jira、Salesforce |
低（OAuth 授权） |
| 代码工具 |
Python/JS 自定义函数 |
中（写代码） |
| MCP 工具 |
通过 MCP 协议动态发现和调用工具 |
低（配置 MCP Server 地址） |
| 子工作流工具 |
将已有工作流封装为可调用工具 |
低（选择工作流） |
| Agent-as-Tool |
将一个 Agent 封装为另一个 Agent 的工具 |
低（选择 Agent） |
4.7.3 插件市场
┌─────────────────────────────────────────────┐
│ 插件市场 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 飞书通知 │ │ 数据报表 │ │ 邮件发送 │ │
│ │ v2.3 │ │ v1.0 │ │ v3.1 │ │
│ │ ⭐4.8 │ │ ⭐4.2 │ │ ⭐4.5 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 知识图谱 │ │ OCR识别 │ │ 翻译 │ │
│ │ v1.5 │ │ v2.0 │ │ v1.2 │ │
│ │ ⭐4.0 │ │ ⭐4.6 │ │ ⭐4.3 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ [+ 发布我的插件] [浏览更多] │
└─────────────────────────────────────────────┘
- 社区贡献 + 官方认证的双轨生态
- 插件支持版本管理和依赖声明
- 插件沙箱执行，隔离安全风险
4.7.4 工具调用的安全与治理
| 机制 |
描述 |
| 权限模型 |
每个工具可配置调用权限（按用户、角色、工作流） |
| 数据脱敏 |
工具调用日志中的敏感字段自动脱敏 |
| 频率限制 |
单一工具的单位时间调用次数上限 |
| 审批策略 |
高风险工具调用需人工审批 |
| 审计日志 |
完整记录每次工具调用的参数和结果 |
4.8 提示词工程与管理
4.8.1 功能概述
提示词（Prompt）是 AI 工作流中的核心资产。提供企业级的 Prompt 管理、版本控制、A/B 测试和优化能力。
4.8.2 核心能力
| 能力 |
描述 |
| Prompt IDE |
可视化 Prompt 编辑器：语法高亮、变量插入、模板管理、实时预览 |
| 变量系统 |
支持动态变量注入（工作流变量、系统变量、上下文变量），支持 Jinja2 模板语法 |
| 版本管理 |
Prompt 的 Git 式版本管理：提交历史、差异对比、回滚 |
| A/B 测试 |
同一 Prompt 的多个版本并行运行，按流量分配，对比效果指标 |
| Prompt 库 |
预置 100+ 行业 Prompt 模板（客服、营销、编程、分析等） |
| 自动优化 |
基于反馈数据自动优化 Prompt（DSPy 风格：自动调整 few-shot 示例和指令） |
| 安全扫描 |
自动检测 Prompt 注入风险、敏感信息泄露、偏见语言 |
4.8.3 Prompt 编辑器界面
┌─────────────────────────────────────────────┐
│ Prompt 编辑器 │
│ 名称: [客服开场白 ] 版本: v3.2 │
│ ┌─────────────────────────────────────────┐ │
│ │ {{system}} │ │
│ │ 你是{{company_name}}的智能客服助手。 │ │
│ │ 你的语气应该{{tone_style}}。 │ │
│ │ │ │
│ │ 回答应遵循以下规则： │ │
│ │ 1. 如果不知道答案，诚实告知 │ │
│ │ 2. 保持回复在{{max_length}}字以内 │ │
│ │ │ │
│ │ 参考知识：{{context}} │ │
│ │ │ │
│ │ {{user_query}} │ │
│ └─────────────────────────────────────────┘ │
│ ┌─────────────────────────────────────────┐ │
│ │ 变量: │ │
│ │ company_name = [工作流变量.企业名称 ▼] │ │
│ │ tone_style = ["专业正式" ▼] │ │
│ │ max_length = [300 ▼] │ │
│ │ context = [RAG节点.检索结果 ▼] │ │
│ │ user_query = [触发输入 ▼] │ │
│ └─────────────────────────────────────────┘ │
│ [保存] [发布] [测试] │
└─────────────────────────────────────────────┘
4.9 可观测性与评估体系
4.9.1 可观测性
全链路追踪
请求 → Agent节点 → LLM调用 → 工具调用 → 子Agent → 人工审批 → 响应
│ │ │ │ │ │
└────────┴──────────┴──────────┴──────────┴──────────┘
全链路 Trace
- 执行轨迹: 可视化展示工作流每次运行的完整执行轨迹，每个节点的输入/输出、耗时、token 消耗
- Agent 思考链: 实时展示 Agent 的推理过程（Thought → Action → Observation 循环）
- 错误定位: 自动标记失败节点，展示错误上下文和堆栈
监控面板
| 指标 |
维度 |
| 性能指标 |
端到端延迟、各节点耗时 P50/P95/P99、吞吐量 |
| 成本指标 |
总 Token 消耗、Token 费用、Top 费用节点、成本趋势 |
| 质量指标 |
任务成功率、工具调用成功率、用户满意度评分 |
| 异常指标 |
错误率、超时率、降级次数、重试次数 |
日志与告警
- 结构化日志，支持接入 ELK、Splunk、Datadog 等外部平台
- 可配置告警规则：成本超标、错误率飙升、延迟突增
- Webhook 通知到企业微信/钉钉/飞书/Slack
4.9.2 评估体系（Evals）
评估无法或缺——这是 2025-2026 年 AI 行业的共识。93% 的 Agent 项目失败，核心原因之一就是缺乏系统性评估。
评估维度
| 维度 |
评估方法 |
工具 |
| 准确性 |
对比预期输出 vs 实际输出 |
精确匹配、语义相似度、LLM-as-Judge |
| 完整性 |
输出是否包含所有必要信息 |
LLM-as-Judge 评分 |
| 安全性 |
检测有害内容、Prompt 注入、数据泄露 |
规则引擎 + 安全模型 |
| 工具使用 |
是否正确选择了工具并传参 |
轨迹对比、工具调用准确率 |
| 推理质量 |
推理步骤是否合理、无跳跃 |
LLM-as-Judge + 人工评审 |
| 延迟 |
端到端耗时是否符合 SLA |
自动计时 |
| 成本 |
Token 消耗是否在预算内 |
自动统计 |
评估流程
┌──────────┐ ┌──────────┐ ┌──────────────┐
│ 准备测试集 │ → │ 运行评估 │ → │ 生成评估报告 │
│ (标注数据) │ │ (批量执行) │ │ (分数 + 建议) │
└──────────┘ └──────────┘ └──────────────┘
│
┌─────────────┴─────────────┐
▼ ▼
┌──────────┐ ┌──────────┐
│ 人工复核 │ │ 自动优化 │
│ (抽样) │ │ (可选) │
└──────────┘ └──────────┘
回归测试
- 核心工作流维护「黄金测试集」
- 每次 Prompt 或模型变更后自动运行回归
- 分数下降超过阈值时阻止发布
4.10 MCP 协议集成
4.10.1 功能概述
MCP（Model Context Protocol）已成为 AI 工具互操作的事实标准。本平台需要同时作为 MCP Client 和 MCP Server。
4.10.2 MCP Client 模式
本平台 ──MCP 协议──→ 外部 MCP Server (数据库/API/文件系统/...)
↑
Agent 通过 MCP 动态发现和调用工具
- 支持连接外部 MCP Server（Stdio 和 HTTP/SSE 两种传输）
- Agent 可动态发现 MCP Server 提供的工具列表
- 统一的工具注册中心，同时管理内置工具和 MCP 工具
4.10.3 MCP Server 模式
外部 MCP Client ──MCP 协议──→ 本平台 (工作流/Agent/MCP Server)
↑
将平台内的 Agent 和工作流暴露为 MCP 工具
- 将任意工作流发布为 MCP Server，供其他 AI 应用调用
- 将 Agent 暴露为 MCP 工具，实现跨平台的 Agent 复用
- 这是对标 Dify 的「Publish as MCP Server」能力
4.10.4 MCP 配置界面
┌─────────────────────────────────────────────┐
│ MCP 管理 │
│ ┌─────────────────────────────────────────┐ │
│ │ MCP Client (我调用别人) │ │
│ │ ┌─────────────────────────────────────┐ │ │
│ │ │ [Server名称] [传输方式] [状态] │ │ │
│ │ │ PostgreSQL HTTP/SSE ● 已连接 │ │ │
│ │ │ FileSystem Stdio ● 已连接 │ │ │
│ │ │ Slack API HTTP/SSE ○ 未连接 │ │ │
│ │ └─────────────────────────────────────┘ │ │
│ │ [+ 添加 Server]│ │
│ ├─────────────────────────────────────────┤ │
│ │ MCP Server (别人调用我) │ │
│ │ ┌─────────────────────────────────────┐ │ │
│ │ │ 工作流A → MCP Server ● 已发布 │ │ │
│ │ │ Agent B → MCP Server ● 已发布 │ │ │
│ │ └─────────────────────────────────────┘ │ │
│ │ [+ 发布为 MCP Server]│ │
│ └─────────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
5. 交互流程与用户体验设计
5.1 工作流画布升级
5.1.1 AI 节点视觉规范
| 节点类型 |
图标 |
颜色 |
特殊行为 |
| LLM 调用 |
🤖 |
紫色 |
可展开查看 Prompt 和模型配置 |
| AI Agent |
🧠 |
深紫 |
可展开查看推理循环和工具调用 |
| RAG 检索 |
📚 |
蓝色 |
可展开查看检索结果 |
| 工具调用 |
🔧 |
绿色 |
标记是否为 MCP 工具 |
| 人工审批 |
👤 |
橙色 |
显示待审批状态 |
| 记忆节点 |
💾 |
灰色 |
显示记忆摘要 |
5.1.2 画布交互流程
1. 拖拽 AI 节点到画布
↓
2. 配置节点 (选择模型/策略/工具/记忆)
↓
3. 连接节点形成工作流
↓
4. 调试运行 (单步执行、断点、查看中间输出)
↓
5. 查看执行轨迹 (Agent 思考链、token 消耗、耗时)
↓
6. 迭代优化 (修改 Prompt、调整策略、重新测试)
↓
7. 运行评估 → 通过 → 发布上线
5.2 调试体验
Agent 调试面板
┌─────────────────────────────────────────────┐
│ Agent 调试 - 智能客服 Agent │
│ ┌─────────────────────────────────────────┐ │
│ │ 🧠 思考 #1 │ │
│ │ "用户询问退款流程，我需要先查询订单状态， │ │
│ │ 再判断是否符合退款条件。" │ │
│ ├─────────────────────────────────────────┤ │
│ │ 🔧 工具调用: order_query │ │
│ │ 参数: {order_id: "12345"} │ │
│ │ 耗时: 0.8s │ 结果: ✓ 成功 │ │
│ │ 返回: {"status": "delivered", ...} │ │
│ ├─────────────────────────────────────────┤ │
│ │ 🧠 思考 #2 │ │
│ │ "订单状态为已送达，在退款有效期内， │ │
│ │ 我可以为用户发起退款申请。" │ │
│ ├─────────────────────────────────────────┤ │
│ │ 🔧 工具调用: refund_apply │ │
│ │ 参数: {order_id: "12345", reason: ...} │ │
│ │ 耗时: 1.2s │ 结果: ⏸ 等待审批 │ │
│ │ [审批中...] │ │
│ └─────────────────────────────────────────┘ │
│ │
│ Token 消耗: 1,245 │ 费用: ¥0.032 │
│ 总耗时: 3.2s │ 迭代: 2/10 │
└─────────────────────────────────────────────┘
5.3 模板与快速开始
- AI 工作流模板库: 60+ 预置模板，按场景分类（客服、营销、数据分析、代码生成、文档处理等）
- 一键导入: 从模板创建，自动配置好模型、Prompt、工具
- Agent 配置向导: 三步创建 Agent：选择场景 → 选择工具 → 配置记忆
6. 技术架构设计
6.1 总体架构
┌─────────────────────────────────────────────────────────────┐
│ 前端层 │
│ ┌──────────┐ ┌──────────────┐ ┌──────────────────────┐ │
│ │ 工作流画布 │ │ Agent 调试面板 │ │ 监控 & 评估 Dashboard │ │
│ └──────────┘ └──────────────┘ └──────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ API 网关层 │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ REST API │ WebSocket (实时调试) │ SSE (流式响应) │ │
│ └──────────────────────────────────────────────────────┘ │
├─────────────────────────────────────────────────────────────┤
│ AI 编排层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │Agent 引擎 │ │RAG 引擎 │ │多Agent │ │HITL 引擎 │ │
│ │· ReAct │ │· 检索 │ │· Supervisor│ │· 审批管理 │ │
│ │· PlanExe │ │· 重排序 │ │· Swarm │ │· 任务队列 │ │
│ │· Function │ │· 向量化 │ │· Graph │ │· 通知推送 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────────────────────┤
│ 基础服务层 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │模型网关 │ │MCP 适配层│ │记忆管理 │ │评估引擎 │ │
│ │· 多提供商 │ │· Client │ │· Buffer │ │· LLM-Judge│ │
│ │· 路由 │ │· Server │ │· Window │ │· 回归测试 │ │
│ │· 成本追踪 │ │· 注册中心│ │· Summary │ │· 报告生成 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
├─────────────────────────────────────────────────────────────┤
│ 数据存储层 │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌─────┐ ┌──────────┐ │
│ │PG │ │Redis │ │向量DB│ │OSS │ │消息队列 │ │
│ │元数据 │ │缓存 │ │检索 │ │文件 │ │任务调度 │ │
│ └──────┘ └──────┘ └──────┘ └─────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────┘
6.2 核心组件详细设计
6.2.1 Agent 引擎
Agent 引擎架构:
┌──────────────────────────────────────────────┐
│ Agent Executor │
│ ┌─────────┐ ┌──────────┐ ┌─────────────┐ │
│ │Strategy │ │Tool │ │Memory │ │
│ │Manager │ │Registry │ │Manager │ │
│ └─────────┘ └──────────┘ └─────────────┘ │
│ ┌─────────┐ ┌──────────┐ ┌─────────────┐ │
│ │LLM │ │State │ │Output │ │
│ │Provider │ │Manager │ │Validator │ │
│ └─────────┘ └──────────┘ └─────────────┘ │
└──────────────────────────────────────────────┘
- Strategy Manager: 管理不同的 Agent 推理策略（ReAct, FunctionCalling, PlanExecute 等），策略通过插件式注册，支持自定义扩展
- Tool Registry: 统一的工具注册中心，聚合内置工具、API 工具、MCP 工具、子工作流工具
- Memory Manager: 管理多层记忆（Working / Conversation / Long-term），提供统一的读写接口
- State Manager: 管理 Agent 执行过程中的状态，支持 Checkpoint 和恢复
- Output Validator: 根据配置的 Schema 校验 Agent 输出，支持 JSON Schema 和 Pydantic 模式
6.2.2 模型网关
模型网关架构:
请求
│
▼
┌─────────────────┐
│ 路由层 │
│ · 成本路由 │
│ · 延迟路由 │
│ · 能力路由 │
└────────┬────────┘
│
┌────────▼────────┐
│ 适配器层 │
│ · OpenAI 适配器 │
│ · Anthropic 适配器│
│ · DeepSeek 适配器 │
│ · ... │
└────────┬────────┘
│
┌────────▼────────┐
│ 管理层 │
│ · 速率限制 │
│ · 故障转移 │
│ · 成本追踪 │
│ · 缓存策略 │
└─────────────────┘
- 路由层: 基于规则的路由（成本最低、延迟最低、能力最强），支持自定义路由策略
- 适配器层: 每个 LLM 提供商的适配器，统一为标准接口（chat/completion/embedding），支持流式和非流式
- 管理层: 全局的速率限制（per-provider / per-model）、故障转移（fallback 链）、成本追踪、响应缓存
6.2.3 RAG 引擎
RAG Pipeline:
文档导入 → 解析 → 分块 → 嵌入 → 索引 → 向量数据库
↓
用户查询 → 查询重写 → 多路召回 → 合并排序 → 上下文组装 → 返回
│
┌─────────┼─────────┐
▼ ▼ ▼
向量检索 关键词检索 知识图谱
- 分块策略: 支持 Fixed-size、Recursive、Semantic、Agentic 四种分块方式
- 检索策略: 支持 Hybrid（混合）、Multi-Query（多查询）、Contextual Compression（上下文压缩）
- 重排序模型: 内置 Cross-Encoder 重排序（BGE-Reranker、Cohere Rerank 等）
6.2.4 评估引擎
评估 Pipeline:
测试用例 → 并发执行 → 结果收集 → 多维度评分 → 报告生成
│ │
┌─────┴─────┐ ┌───────┴───────┐
│ 精确匹配 │ │ LLM-as-Judge │
│ 语义相似度 │ │ 人工评分 │
│ 规则检查 │ │ 成本/延迟检查 │
└───────────┘ └───────────────┘
6.3 关键技术选型建议
| 组件 |
推荐方案 |
备选方案 |
| Agent 框架 |
LangGraph (Python) |
自研 / CrewAI |
| LLM 网关 |
自研适配层 + LiteLLM |
Portkey / Helicone |
| 向量数据库 |
Milvus / Qdrant |
pgvector / Weaviate |
| 消息队列 |
Redis Streams / RabbitMQ |
Kafka |
| 可观测性 |
OpenTelemetry + 自研 Dashboard |
Langfuse / LangSmith |
| MCP SDK |
官方 Python/TS SDK |
自研适配 |
| 前端框架 |
React + ReactFlow (画布) |
Vue + VueFlow |
7. 实施路线图
Phase 1: 基础 AI 能力（MVP — 8-12 周）
目标: 让现有工作流能够调用 LLM，完成最基本的 AI 增强
| 模块 |
功能 |
优先级 |
| 模型网关 |
接入 5+ 主流 LLM 提供商（OpenAI / Anthropic / DeepSeek / Qwen / GLM） |
P0 |
| LLM 节点 |
工作流画布中的 LLM 调用节点，支持文本生成、分类、摘要 |
P0 |
| Prompt 管理 |
基础的 Prompt 模板 + 变量系统 |
P0 |
| 流式响应 |
SSE 流式输出，前端实时渲染 |
P0 |
| 成本追踪 |
Token 消耗和费用统计 |
P1 |
Phase 2: 智能 Agent 与 RAG（12-16 周）
目标: 引入 Agent 推理能力和企业知识库检索
| 模块 |
功能 |
优先级 |
| Agent 节点 |
ReAct + Function Calling 策略，工具调用能力 |
P0 |
| 知识库 RAG |
文档导入、向量化、混合检索 |
P0 |
| 工具生态 |
内置工具（搜索、计算器、HTTP）+ 自定义 API 工具 |
P0 |
| 记忆管理 |
会话记忆 + 摘要记忆 |
P1 |
| Agent 调试 |
思考链可视化、单步执行、断点调试 |
P1 |
| Human-in-Loop |
基础审批拦截（工具级别的审批配置） |
P1 |
Phase 3: 多 Agent 协作与生产化（12-16 周）
目标: 支持多 Agent 协作，具备生产级可靠性
| 模块 |
功能 |
优先级 |
| 多 Agent 编排 |
Supervisor + Swarm 协作模式 |
P0 |
| MCP 集成 |
MCP Client + Server 双向支持 |
P0 |
| 评估体系 |
测试集管理、LLM-as-Judge、回归测试 |
P0 |
| 可观测性 |
全链路追踪、监控面板、告警 |
P1 |
| Prompt 工程 |
A/B 测试、版本管理、自动优化 |
P1 |
| 插件市场 |
社区插件发布与安装 |
P2 |
Phase 4: 企业级与生态扩展（持续迭代）
| 模块 |
功能 |
优先级 |
| 图编排模式 |
Agentic Graph 模式（深度多 Agent 编排） |
P2 |
| 高级记忆 |
长期记忆、实体记忆、跨会话个性化 |
P2 |
| 高级人机协同 |
双轨审核、修正引导、IM 集成 |
P2 |
| A2A 协议 |
Agent-to-Agent 标准通信协议 |
P2 |
| 成本优化 |
智能缓存、语义缓存、模型蒸馏建议 |
P2 |
| 合规审计 |
完整的审计追踪、数据驻留、合规报告 |
P2 |
8. 风险评估与应对
| 风险 |
影响 |
概率 |
应对措施 |
| LLM 输出不可控 |
高 |
高 |
多层校验（Schema 验证 + 内容安全扫描 + 人工审批），输出结构化和约束 |
| 成本失控 |
中 |
中 |
成本预算上限、智能路由（便宜模型做简单任务）、语义缓存、token 用量告警 |
| 数据安全与隐私 |
高 |
中 |
敏感数据脱敏、知识库访问权限控制、本地化部署选项、数据不流出选项 |
| Agent 行为不可预测 |
高 |
中 |
Human-in-the-Loop 拦截高风险操作、沙箱执行工具、最大迭代次数限制 |
| 性能瓶颈 |
中 |
中 |
异步任务队列、流式响应、并行执行、智能缓存 |
| 供应商锁定 |
中 |
低 |
模型网关多提供商支持、MCP 标准协议、开放 API、Prompt 和配置可迁移 |
| 用户接受度 |
中 |
中 |
渐进式 AI 化策略（不强制使用 AI）、丰富的模板、交互式教程 |
附录
A. 术语表
| 术语 |
定义 |
| Agent |
能自主推理、规划和使用工具完成任务的智能体 |
| RAG |
Retrieval-Augmented Generation，检索增强生成 |
| MCP |
Model Context Protocol，模型上下文协议（Anthropic 提出） |
| A2A |
Agent-to-Agent，Agent 间通信协议 |
| ReAct |
Reasoning + Acting，推理与行动交替的 Agent 策略 |
| HITL |
Human-in-the-Loop，人机协同 |
| LLM-as-Judge |
用 LLM 评估 LLM 输出的方法 |
| DAG |
Directed Acyclic Graph，有向无环图 |
B. 参考竞品
- Dify (dify.ai) — 开源 AI 应用开发平台，Apache 2.0
- 扣子 Coze (coze.cn) — 字节跳动 AI Agent 平台
- n8n (n8n.io) — 开源工作流自动化平台，Fair-code
- LangGraph (langchain.com/langgraph) — Agent 编排框架
- FastGPT — 开源知识库问答平台
- CrewAI — 多 Agent 协作框架
2
0
已为社区贡献2条内容
所有评论(0)