Plugin Mechanism Based on MCP and Semantic Workflow Visualization Suggestions

[lostlight530]

Background
I have set up some practical agents (single-agent and multi-agent) on Nexent, and have long used agent platforms like Koosh and Define that support drag-and-drop workflows, as well as flowwith's canvas and other agents.
Combining these experiences with your documentation's positioning of "zero-code agent creation + MCP tool ecosystem + plugin architecture + workflow control", my overall layered understanding of Nexent is:
Prompt interaction layer → semantic workflow control → function/tool calling → MCP tools/resources → underlying data and system

Requests
Natural language creation of agents is already very user-friendly for new users.
However, for advanced users / teams, we hope to have the following capabilities in complex scenarios:

1. Ability to reuse a set of mature capabilities, instead of reconfiguring them repeatedly;
2. Ability to "see and lightly edit" the workflow generated by natural language, to facilitate issue troubleshooting and fine-tuning

Suggestions
Plugin abstraction (based on MCP)
Introduce the concept of "plugins" at the application layer above MCP:
Plugin = several MCP tools + prompt templates + a default small workflow;
Support official plugins and user-defined plugins;
Enable / configure plugins within agents or in the "plugin market"

This way:
MCP remains the standardized protocol for accessing capabilities;
Plugins are "capability packaging units" from the application perspective, making it convenient for non-developers to reuse complex capabilities.
Semantic workflow visualization and lightweight editing
Keep the current default experience of "pure natural language agent creation, no drag-and-drop" unchanged.
Provide an optional workflow view for advanced users:
Display the steps, branches, and tool call chains generated by the system based on the description;
Allow for limited editing in this view (e.g., inserting an MCP call node, adding a manual confirmation node, etc.);
Use UI complexity control to avoid disrupting the zero-code main path

Expected benefits
For new users: Continue to retain the ultra-simple experience of "just talking to build an agent"
For advanced users / teams:
 Reuse complex capabilities through plugins, reducing repetitive work;
 Improve observability and debuggability of complex scenarios through workflow visualization;
Meanwhile, maintain Nexent's differentiation from traditional "pure drag-and-drop workflow platforms": underlying workflow exists, but the construction path is "natural language → automatically generated workflow → advanced users can optionally view and fine-tune"
Welcome to point out any misunderstandings
背景
我在 Nexent 上已搭建了一些实际智能体（单智能体多智能体），也长期使用过扣子、Define 等支持拖拽工作流的 Agent 平台和flowwith这类画布和其余agent
结合这些体验和你们文档中“零代码创建智能体 + MCP 工具生态 + 插件架构 + workflow control”的定位，我对 Nexent 的整体分层理解是
Prompt 交互层 → 语义工作流控制 → Function/Tool Calling → MCP 工具/资源 → 底层数据与系统

诉求
新用户用自然语言创建智能体已经很友好
但对进阶用户 / 团队来说，希望在复杂场景下：
1.可以复用一组成熟能力，而不必反复配置；
2.可以在必要时“看见并轻量编辑”那条由自然语言生成的工作流，便于排查问题和调优

建议
插件抽象（基于 MCP 之上）
在 MCP 工具之上，引入应用层“插件”概念：
插件 = 若干 MCP 工具 + Prompt 模板 + 默认小型 workflow；
支持官方插件和用户自定义插件；
可在智能体内或“插件市场”中启用 / 配置
这样：
MCP 仍然是标准化接入能力的底座协议；
插件则是站在应用视角的“能力打包单元”，方便非开发者复用复杂能力
语义工作流的可视化查看 / 轻量编辑
保持当前“纯自然语言创建智能体、无需拖拽”的默认体验不变
为进阶用户提供一个可选的工作流视图：
展示系统根据描述自动生成的步骤、分支、工具调用链路；
允许在此视图中做少量编辑（如插入一个 MCP 调用节点、增加人工确认节点等）；
用 UI 复杂度控制，避免破坏零代码主路径

预期收益
对新手：继续保留“只用说话就能搭智能体”的极简体验
对进阶用户 / 团队：
通过插件复用复杂能力，减少重复工作；
通过工作流可视化，提高复杂场景的可观测性和可调试性；
同时保持 Nexent 与传统“纯拖拽工作流平台”的差异化：底层有 workflow，但构建路径是“自然语言 → 自动生成 workflow → 进阶用户可选查看和微调”
如有理解偏差，欢迎指正
（以下为图片）

[loveTsong]

非常感谢你如此深入且结构化的建议。

不过在这里想稍微澄清一下我们当前对“workflow”机制的理解和实现方式。目前 Nexent 并没有采用预定义或静态的工作流引擎来调度智能体行为，而是依托大语言模型的语义理解能力，在运行时动态识别任务意图、自动拆解步骤并灵活调度 MCP 工具调用链路。也就是说，所谓的“workflow”实际上是动态生成、上下文驱动的结果，而非预先固化在某个流程图中。这种设计让我们能更自然地响应复杂多变的用户指令。

关于你提到的“插件”构想，这个看起来和我们智能体空间和智能体市场是一致的，你可以使用最新版本或在线体验环境尝试看下。

至于内部是否增加workflow这种承载的方式，我们也有讨论过，将来可能会规划进来，到时候欢迎探讨。

再次感谢你的建设性反馈！后续如果有相关原型进展，也非常欢迎你继续参与讨论和试用。