问HN：OpenClaw与Claude Cowork – 本地技能与MCP集成的对比？
我一直在使用 OpenClaw 和 Claude Cowork 来自动化工作流程，并注意到它们在可扩展性方面采取了根本不同的方法。
OpenClaw 依赖于本地技能——在你的机器上运行的脚本，可以读取文件、控制浏览器、执行 shell 命令。这对于本地自动化非常强大，但所有操作都在你的环境中进行，你只能使用别人编写的技能。
而 Claude Cowork 支持 MCP（模型上下文协议）服务器，这开启了一种完全不同的模型。通过像 Composio/Rube 这样的工具，Cowork 可以直接与 500 多个应用程序进行交互——包括 Slack、GitHub、Google Workspace、Twitter、Notion、客户关系管理系统——所有这些都是通过经过认证的 API 连接实现的。没有数据抓取，没有脆弱的浏览器自动化，只有原生工具调用。它还可以将这些操作串联起来：读取 GitHub 的 PR，在 Slack 中进行总结，在 Asana 中创建后续任务，所有这些都可以在一个工作流程中完成。
这种差距显得相当显著。OpenClaw 为本地任务提供了一个自托管的瑞士军刀，而 Claude Cowork 通过 MCP 则为你提供了一个与整个 SaaS 堆栈原生对话的编排层。
对于那些使用其中一个或两个工具的人来说——MCP 方法是否真的像看起来那么具有突破性？还是 OpenClaw 的自托管灵活性在某些用例中仍然占优势？
查看原文
Been using both OpenClaw and Claude Cowork for automating workflows and noticed they take fundamentally different approaches to extensibility.
OpenClaw relies on local skills — scripts that run on your machine, read files, control browsers, execute shell commands. Powerful for local automation, but everything runs in your environment and you're limited to what someone has written as a skill.
Claude Cowork supports MCP (Model Context Protocol) servers, which opens up a completely different model. With something like Composio/Rube, Cowork can directly interact with 500+ apps — Slack, GitHub, Google Workspace, Twitter, Notion, CRMs — all through authenticated API connections. No scraping, no brittle browser automation, just native tool calls. It can also chain these together: read a GitHub PR, summarize it in Slack, create a follow-up task in Asana, all in one workflow.
The gap feels significant. OpenClaw gives you a self-hosted Swiss Army knife for local tasks. Claude Cowork with MCP gives you an orchestration layer that talks to your entire SaaS stack natively.
For those using either or both — is the MCP approach as much of a leap forward as it seems? Or does the self-hosted flexibility of OpenClaw still win for certain use cases?