You want to know the difference between the two policy action objects, cache(no)and bypass_cache(yes).
cache(no) vs. bypass_cache(yes)
This indicates that any object previously cached shall be deleted, and that any future acquisition of such object will not be cached. Typically this is used to indicate that specific content should not be cached. Since it is in the cache layer the rule applies to client, pipelined, and refresh requests. This parameter is only used in the layer, specifically the Web Content Layer.
This indicates that the cache will not be queried for the content and the webserver's response will also not be cached. Typically this is used to bypass caching for certain source attributes such as source ip, auth username, user-agent, etc. This parameter is only used in the layer, specifically the Web Access Layer.
If bypass_cache(yes) is set, then the cache is not accessed and the value of cache( ) is irrelevant.
bypass_cache() prevents the ProxySG appliance from even checking to see if the object is in cache, meaning any existing cached copy will not be touched and can still be served to other clients which run with bypass_cache(no) policy.
On the other hand, cache(no) prevents the ProxySG appliance from writing any new copy of the object it fetches from the origin server into cache, and in fact will cause it to delete the currently cached copy in that case.
An example of a case use for cache(no) is perhaps as a way to actively flush content which was previously cached out of cache when you decide that caching it is no longer a good idea. That wouldn't happen if you use bypass_cache(yes). If the content can truly never be usefully cached, though, using bypass_cache(yes) will be the most efficient approach since it skips the cache lookup from the very beginning.