有几个基础问题请教下：分布式、mcp、agent相关的

问几个非专业性的问题：

1. workflow为什么不是分布式的，感觉好像支持大并发都是k8s？没研究过分布式，纯靠直觉问的这个问题，可能概念有混淆；
2. 最近比较火的mcp（模型上下文协议）是不是也可以封装为workflow编程模式里的协议？
3. 假如协议是mcp，那算法和任务流对应到agent系统的什么概念呢？

[Barenboim]

你好，你是我们的老用户了啊，好早之前就给我们发过issue。

我们这边workflow的应用很多都是分布式的，但我们没有进一步提供搭建多机服务的框架代码。这些也没有什么必要吧，主要是业务需求千差万别，我们很难提供统一的分布式模式让用户都可以接受。workflow的服务治理能力非常强大，可以方便的支持各种服务发现。例如内置的Consul client和upstream结合就可以对接consul机群，同时具备服务发现和服务注册的能力。

mcp的话，目前我们可以通过wfrest实现基于SSE协议的mcp server，好像已经有用户这么做了。作为AI client的话，我们目前能力上都是具备的，我确实有想法搞点类似最近Sprint AI的东西。至于任务流，算法这些，在AI client里都是很有用的基础能力啊。

@Barenboim 大佬好，哈哈距离上次使用好久了，技术水平还是原来的，发现还是做独立开发更有机会用workflow，上班没啥机会用到，想把workflow用在独立开发的场景里是不是可以降维打击，
用workflow做服务器端功能的话，是不是一般用nginx做前端解析https，然后转发给workflow的http，因为在workflow文档里没搜到https，所以我想应该是workflow做后端然后nginx做前端这个架构，早知道把计算机知识系统学一下了。
现在各种agent相关协议变多了，高性能的实现还很少，感觉传统的计算机要求还是很多，主要是算法和任务流规划环节增加了AI，数据本身的传输还是要高性能

[Barenboim]

别的问题一会我再回答，workflow明显就是完全支持https以及其他任何协议运行在SSL上啊。甚至完全支持MySQL over TLS。我们基本上是SSL支持最好的框架了。

…

------------------ 原始邮件 ------------------ 发件人: eatcosmos ***@***.***> 发送时间: 2025年5月27日 10:07 收件人: sogou/workflow ***@***.***> 抄送: xiehan ***@***.***>, Mention ***@***.***> 主题: Re: [sogou/workflow] 有几个基础问题请教下：分布式、mcp、agent相关的 (Issue #1725) eatcosmos left a comment (sogou/workflow#1725) @Barenboim 大佬好，哈哈距离上次使用都失业好几次了，技术水平还是原来的，发现还是做独立开发更有机会用workflow，上班没啥机会用到， 用workflow做服务器端功能的话，是不是一般用nginx做前端解析https，然后转发给workflow的http，因为在workflow文档里没搜到https，所以我想应该是workflow做后端然后nginx做前端这个架构，早知道把计算机知识系统学一下了。 现在各种agent相关协议变多了，高性能的实现还很少，感觉传统的计算机要求还是很多，主要是算法和任务流规划环节增加了AI，数据本身的传输还是要高性能 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

能不能推荐个nginx web服务迁移到workflow全栈的教程，搭建网站（现在AI生成网站很火，所以搭建网站的需求变多了）平时都是照着网上的教程，教程几乎都是配置nginx.conf，因为确实计算机背景知识这块然后就懵了，不知道怎么迁移配置成workflow（是否需要把nginx.conf参数一一对应到workflow），要是全部用workflow应该会省事很多，用nginx反向代理到workflow的各个端口可能会损失性能

[Barenboim]

这个其实没有必要把接入层的nginx替换成workflow。workflow做后端的逻辑，nginx作为反向代理请求workflow http server就可以了。workflow主要是为了高性能的后端服务，而nginx作为接入层支持更丰富的配置，不是替换的关系。

当然workflow本身也可以作为web服务器直接对公网服务，但肯定不能支持nginx的所有配置。我认为搭建网站的话，nginx+workflow是一个很好的组合，实际上我们很多用户也是这么用的。这种情况下可以不使用workflow的SSL，因为nginx和workflow之间是内网。

[Barenboim]

例如这个企业用户的用法：wfrest/wfrest#280

他甚至不知道运维部门某个时候在workflow前面架设了一个nginx。

谢谢，原来如此，我还以为我用法错了，这样组合就方便了，自己一个人瞎折腾也不知道技术方案可行性，大佬有没有计划把workflow拓展到agent，主要是看workflow里面有任务流这个概念，然后现在dify、langgraph、n8n也都是基于“workflow”概念，不过都python、ts，workflow名字记就是workflow，应该可以性能更高

[Barenboim]

谢谢，原来如此，我还以为我用法错了，这样组合就方便了，自己一个人瞎折腾也不知道技术方案可行性，大佬有没有计划把workflow拓展到agent，主要是看workflow里面有任务流这个概念，然后现在dify、langgraph、n8n也都是基于“workflow”概念，不过都python、ts，workflow名字记就是workflow，应该可以性能更高

是啊，我们完全可以做一个性能更好的langgraph。基本上所有的基础组件都非常好的适配需求。

[Barenboim]

看一下workflow-ai项目：https://github.com/holmes1412/workflow-ai