至于你的要求：
必须可以运行多个工作流，以及具有不同上下文（不同数据/业务对象）的相同工作流的多个实例。
WF 没有问题。
一些工作流程会长时间运行，
涉及多个用户/客户端会话
并等待外部用户输入。
所以工作流必须能够
坚持并响应一些信号
从客户端应用程序。这也意味着
工作流的执行必须
在服务器应用程序上完成（对吗？）。
WF 专为可以与外部影响交互的长时间运行的任务而设计。但是，这并不容易实现。没有可以挂钩的通用解决方案。您可能必须设计与 Workflow Extensions 交互的自定义活动，以处理将用户输入移动到工作流中。将工作流暴露给外部也是如此，尽管 WF4 确实带有许多 WCF 活动，可用于完成此任务。
我希望能够运行各种
服务器应用程序上的工作流程，我做
不想重新部署
工作流更改时的服务器应用程序。
这更难实现。您必须至少将工作流与服务器代码分开。最简单的方法是将您的工作流存储为 xaml 和 load it at runtime，例如来自数据库。
其他选项是使用某种在运行时加载工作流程序集的依赖注入框架（例如 Structure Map 或 Unity）。如果工作流程发生变化，您可以将新程序集放在服务器上，更改配置并重新启动。或者，您可以将工作流程序集隔离在它们自己的 AppDomain 中，在运行时加载它们，并在必须重新加载新版本时丢弃域。你做哪一个取决于你的要求；我实际上是在做第三种选择，因为我必须在运行时加载许多不同版本的工作流程序集，同时运行它们，而且它们通常具有嵌入式资源，因此阻止了我走 XAML 路线。
我的第一个想法是工作流程
服务。经过大量研究我
断定这是不对的
自工作流服务以来的路径基本上
提供执行的可能性
远程活动
工作流在客户端应用程序中开始。是
这个对吗？
我在标准 Windows 服务应用程序中托管我的工作流。我必须管理和维护客户端用来与我的工作流交互的 WCF 前端。据我所知，如果我理解正确的话，工作流服务似乎是稳定工作流的可行选择。在 AppFabric 中托管应用程序也是一个不错的选择，我相信它比使用 Windows 服务更简单。但无论主机是什么，您都有两种选择 - 您的工作流定义您的服务合同，或者您必须定义服务合同并处理所有执行和与您管理的工作流的通信。
第一个是具有简单外观的稳定工作流的不错选择。这对您来说似乎不是一个好选择，因为您必须在工作流发生变化时动态加载它们；这需要工作流之外的逻辑来处理来自客户端的通信（“这是工作流 X 的新版本！”），还需要管理工作流的生命周期。
您似乎必须找到某种主机应用程序（IIS WebService 应用程序、Windows 服务、AppFabric、Azure），定义您的 WCF 服务并将其联机，处理来自客户端的调用，将这些调用传达给您正在运行的工作流代码，然后必须加载并执行这些调用，并将结果返回到链上。
我不禁注意到，您似乎对等待您的旅程准备不足。我强烈建议创建一个原型，该原型可以巧妙地切入您需求的最核心部分。带有 WCF 前端的托管应用程序（我建议使用 AppFabric），该前端加载基于 XAML 的工作流来处理客户端调用。一旦确定了简单版本，您就可以扩大范围以涵盖您的所有要求。