给 Agent 换块"画布"：用拖拽编排代替手动配库

配一个 Agent，以前要手动往数据库里填一堆关联表；现在，画张图就行。

一、先感受一下"手动配 Agent"有多疼

一个 Agent 要跑起来，数据库里得有一串配置关系：

ai_agent            → 智能体本身（名称、策略）
ai_agent_flow_config → 挂哪些角色客户端（分析员/执行员/质检员）
ai_client            → 角色定义
ai_client_config     → 关联表（client → model / prompt / tool_mcp / advisor）
ai_client_model      → 用哪个模型
ai_client_tool_mcp   → 挂哪些 MCP 工具
ai_client_system_prompt → 角色人设
...

其中那张 ai_client_config 关联表，要人手动填：

source_type="client", source_id="3101", target_type="model",  target_id="3001"
source_type="client", source_id="3101", target_type="tool_mcp", target_id="5006"
source_type="model",  source_id="3001", target_type="tool_mcp", target_id="5006"

每个字段不能错：target_type 写错、ID 对不上、状态忘开 1，Agent 就静默失灵，还贼难查。

更要命的是——这事只有懂表结构的人能干。运营配不了、测试配不了、客户更配不了。

二、换个思路：把"配 Agent"变成"画图"

如果你玩过 Coze、Dify 这类 Agent 平台，你会知道它们都长这样：一块画布，拖节点、连线、保存。

[Agent] ──→ [Client: 任务执行]
              ├─→ [Model: gpt-5-mini]
              ├─→ [Prompt: 你的角色提示词]
              ├─→ [Advisor: 记忆]
              └─→ [Tool_MCP: 搜索] ──→ [Tool_MCP: CSDN发帖]

每个节点 = 一个资源（客户端/模型/工具/提示词），每条线 = 一个关联。 画完这张图，一个 Agent 就配好了。

这就是 3-19 干的事：用 flowgram.ai 做画布，让配置可视化、可拖拽。

三、数据库为此变成了三层

这是本文的核心——加了画布之后，数据库的表被清晰分成了三层：

┌─ 资源层 ─────────────────────────────┐
│  ai_client / ai_client_model /       │   "有哪些素材"
│  ai_client_tool_mcp / ...            │   画布节点下拉的数据来源
└──────────────────────────────────────┘
            ↓ 被画布引用
┌─ 编排层 ─────────────────────────────┐
│  ai_agent_draw_config (+nodes/edges) │   "怎么拼成一个Agent"
│  整张画布的 JSON 图纸                 │   画布保存时自动写入（新增）
└──────────────────────────────────────┘
            ↓ 解析落库
┌─ 执行层 ─────────────────────────────┐
│  ai_agent / ai_agent_flow_config /   │   "运行时真正用的配置"
│  ai_client_config                    │   运行时调度器读这里
└──────────────────────────────────────┘

资源层：管"有哪些素材"，画布节点从这里拉数据
编排层：管"怎么拼"，存整张画布的图纸（3-19 新增）
执行层：管"怎么跑"，是运行时真正读的配置

以前只有资源层和执行层，靠人手动把它们关联起来；现在多了编排层，关联由画布自动生成。

四、画布"图纸"长什么样

ai_agent_draw_config 表核心字段：config_id、agent_id、config_data（整张图 JSON）、version、create_by……

config_data 就是这张图，结构很直观——nodes 是节点，edges 是连线：

{
  "nodes": [
    {"type":"agent",    "data":{"inputsValues":{"agentName":"固定任务模型", "strategy":"fixedAgentExecuteStrategy"}}},
    {"type":"client",   "data":{"inputsValues":{"clientId":"2103", "sequence":1}}},
    {"type":"model",    "data":{"inputsValues":{"modelName":"3001"}}},
    {"type":"tool_mcp", "data":{"inputsValues":{"toolMcpName":"5006"}}},
    {"type":"prompt",   "data":{"inputsValues":{"promptName":"6002"}}},
    {"type":"advisor",  "data":{"inputsValues":{"advisorName":"4001"}}}
  ],
  "edges": [
    {"sourceNodeID":"agent_...",  "targetNodeID":"client_..."},
    {"sourceNodeID":"client_...", "targetNodeID":"model_...",    "sourcePortID":"..."},
    {"sourceNodeID":"model_...",  "targetNodeID":"tool_mcp_..."}
  ]
}

节点里存的就是选中的资源 ID，edges 里存的就是"谁连谁"。 后端拿到这张图，用解析器（DrawConfigParser）拆开，就能还原出 Agent 需要的完整配置。

五、数据流转全链路

用户在画布拖节点、连线
   ↓ 点保存
前端把整张图转成 JSON
   ↓ 调 saveDrawConfig 接口
后端存进编排层（ai_agent_draw_config），并解析
   ↓ 解析出 agent + 资源 + 关联
落成执行层配置（ai_agent / ai_agent_flow_config / ai_client_config）
   ↓ 运行时
调度器读执行层配置 → 装配 → 跑 Agent

一条链路下来：画图 → 存图纸 → 解析 → 落执行配置 → 跑。人只负责画图，剩下的都是系统干的。

六、为什么值得这么做：四个层面的收益

收益	说明
降门槛	配置从"写 SQL"变"拖鼠标"，不懂数据库也能配
防出错	线连对了配置就对，错了画布上一眼看见
可追溯	图纸有 version / create_by / history，能回滚、能审计
可平台化	配置能力从程序员手里交出去，平台能交付给普通用户

尤其最后一条——能不能可视化配置，是 Agent 项目从"个人工具"走向"可商用平台"的分水岭。Coze、Dify 卖的就是这个。

七、也别忘了边界

照例泼冷水：

图纸 ≠ 可执行配置：画布存的是 JSON 图纸，运行时用的是解析后的执行配置，图纸和解析器之间要保持同步，画布新加节点类型，解析器也得跟上。
数据一致性：资源表里的模型/工具被删了，画布图纸还引用着它——需要校验"图纸里引用的资源都还存在"。
权限与校验：可视化让"谁都能配"，也就意味着"谁都能改配置"——要配合用户权限和配置审批，否则是新的风险面。
大图可维护性：节点一多，画布会乱，需要分组、模板、版本管理来兜底。

八、总结

三句话收尾：

配置 Agent 的本质是"组织资源关系"——以前用手填表，现在用画布连线，同一个目的，更好的手段。
画布把数据库分成了三层：资源层（有什么）、编排层（怎么拼）、执行层（怎么跑），中间用一张 JSON 图纸衔接。
可视化编排是平台化的分水岭——把配置能力从程序员手里交出去，项目才能从一个"能对话的 demo"变成一个"能交付给别人用的平台"。

至此，Agent 平台四部曲完成：

《让 AI 学会"自己干活、自己检查、自己改"》——一个 Agent 怎么自我闭环
《让 AI 学会"先写计划再干活"》——Agent 的两种执行哲学
《给 Agent 装个"总机"》——多种 Agent 怎么组织调度
《给 Agent 换块"画布"》——配置 Agent 怎么可视化

从"执行"到"组织"到"配置"，从"代码"到"数据库"到"用户"，这套 Agent 平台的设计地图就算完整了。