猫鱼周刊 vol. 060 MCP 可能是通用人工智能的最后一公里

关于本刊

这是猫鱼周刊的第 61 期，本系列每周日更新，主要内容为每周收集内容的分享，同时发布在

博客：阿猫的博客-猫鱼周刊

RSS：猫鱼周刊

邮件订阅：猫鱼周刊

微信公众号：猫兄的和谐号列车

私信：leslieleung@proton.me

午后的香港街头，阳光打在彩色的维他饮料框上，呈现出很好看的色彩。香港算是非常适合扫街的地方，有老旧又很干净整洁的街巷，也有很摩登繁华的闹市，市区里藏了很多街角公园，也有海边和港口，很多风景都很新鲜。

因为上周末去香港玩了，所以周刊暂停了一期。然后这周因为更多的一些事情，延迟到周一发布。

文章

MCP 终极指南

文章链接

上期我们介绍过 MCP(Model Context Protocol)，本来想写一篇文章稍微介绍一下相关的资源，结果找到了这篇已经非常完善的文章，就不狗尾续貂了。

比较有意思的是，MCP 相比 Function Calling，它是一个更加底层的协议，定义的是 Client 和 MCP Server 的交互，而且不需要模型本身支持，可以通过 Client 端去实现。

MCP 很像是 LLM 的触手，LLM 通过 MCP 去感知世界（获取上下文）和与世界交互（操作工具）。可以预见的是，MCP 会是 LLM 实用化很重要的一步，或者说它可能是通用人工智能的最后一公里。

Linus Torvalds 谈 AI 编程

视频（BiliBili）
视频（YouTube）
文字稿

Linux 基金会一次访谈（应该是 2024 年初）中 Linus 和主持人谈到关于 AI 编程的话题，两个人其实体现出两种截然不同的态度。

Linus 对 AI 编程是比较乐观的：

认为 LLM 会逐渐被用于代码编写，并类比编程语言的演变（从机器码到高级语言），强调这是工具的自然发展，而非革命性颠覆。
看好 LLM 在发现“低级错误”和代码模式异常方面的作用，类似于编译器警告的升级版，能帮助开发者更高效地维护代码质量。

而另一个 host 则比较悲观，或者说持有一点质疑：

将 LLM 描述为“增强版自动更正”，强调其基于概率预测的底层逻辑。
重点指出 LLM 的“幻觉”问题，担忧在缺乏人类监督时，自动化可能导致更多隐蔽的 bug。

关于这方面其实我还有一些想法，会在下面「想法」栏目展开一下。

AI is Making Developers Dumb

原文链接

也是一篇谈 AI 编程的文章，认为 AI 会让开发者变笨。

文章提到 Copilot Lag 的现象，就是习惯于用代码自动补全之后，在写代码的时候会习惯等待 AI 的补全，甚至被 AI 牵着鼻子走；久而久之，会削弱开发者独立思考和解决问题的能力，甚至遗忘基础语法和编程概念，对技术一知半解。

想法

我谈 AI 编程

我算是非常早开始使用 AI 辅助编程的人，从 Copilot 的内测开始，我就一直使用 Copilot 和类似的工具完成我的编程工作。去年的时候，我写过一篇使用 Copilot 辅助我完成一个前端网站的文章，还得到了阮一峰老师的推荐；另外，我也在公司内部做过一些 AI 进行 Code Review 的实践，最近结合 Cursor 也折腾了一个新的 AI CR 方式。我是 AI 编程的坚定支持者。

Linus 的访谈中，看到两种平时也很常见的态度：乐观和质疑，不得不说，我在工作中听到质疑的声音会比较多。这类声音的核心主要是担心 AI 写 bug，又或者担心 AI 对其职业产生威胁等等。

我觉得 Linus 的回答也很耐人寻味：

Well, I see the bugs that happen without them every day. So that may be why I’m not so worried.

在没有 AI 的时候我也每天能见到 bug，所以这可能是为什么我并不太担心（AI 会写 bug）。

他说得算比较委婉，以我的经历，很多人写得甚至不如 AI，尤其是一些常见的算法或者逻辑。因此，担忧 AI 写 bug，只是自己抗拒接受新事物的一种借口。

我觉得随着 AI 编程逐渐铺开，以后编程会逐渐变成一个新的范式：将来的程序员会通过描述需求和技术设计，而最终的大部分代码都由 AI 生成，程序员的工作会从编写代码逐渐变成设计方案。这其实也是我近几个月使用 Cursor 的感受，自从有了 Agent 模式，在实现业务需求的时候会更多去想设计、逻辑方面的东西，而不是代码具体怎么写。

想法的另一部分是对「AI 会让开发者变笨」的回应。确实在有 Copilot 之后我很少写 go 的循环之类的语法，以至于如果突然要我手写一下，我可能会想不起来怎么写，这就是他说到的「Copilot Lag」。我平常会把代码分成两种，一种是千篇一律反反复复的代码，例如 CRUD，这类我很倾向于交托给 AI，写得快，写得干净整洁，往往不需要太多改动就可以跑起来；另一种是新奇的代码，一般是我没接触过的新领域，就算让 AI 写了我也没法 review 是否符合我的想法，这些代码我会自己去写。简而言之，我会让 AI 帮我干繁杂的活，剩下有趣的部分自己操刀。

另外你会发现，一些很新奇的东西，AI 很可能不会写，就例如下面的 mcp server，至少在目前版本的 Claude 3.7 它还没有相关的知识，这就是我们人的学习能力大放异彩的时候。所以说：

AI 决定生成代码的下限，人决定上限。

项目

mcp-server-memos

项目地址

我写的一个 Memos 的 mcp server，算是一个 mcp 的模板。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("memos")

@mcp.tool()
def search_memos(query: str) -> List[Dict[str, Any]]:
	pass

@mcp.tool()
def create_memo(content: str, tags: List[str] = []) -> Dict[str, Any]:
	pass

def main():
    mcp.run(transport="stdio")


if __name__ == "__main__":
    main()

这里省略了具体的 API 交互逻辑，但实现一个 mcp server 最简单的方式就是这样。

mcp-go

项目地址

Go 的 MCP 框架。目前来说，比较主流的是 Python 和 JS，他们都有官方的 SDK 支持。但其实 Go 是更加适合的，它跨平台分发原生二进制的特性我觉得非常适合这种场景。

langmanus

项目地址

社区复刻的 Manus，从演示视频来看完成度颇高。甚至我觉得比原版的 Manus 更加 promising，毕竟「Talk is cheap, show me the code.」，而这个开源项目是真的有全部可运行的代码的。

Awesome-Dify-Workflow

项目地址

Dify 工组流集合分享，收集了挺多示例，有些还是比较复杂的。

说起 Dify，这个项目我很早就在用，它比较大的特点就是可视化工作流编排，后续很多厂商的交互都或多或少致敬了它；而它在编排、低代码上确实挺好用，适合快速做一些 demo，比用 gradio 之类的工具写起来还要快一些。比较坑的是，在实际用起来发现，私有化部署一个 Dify 的吞吐量非常低，能抗的 QPS 很低，定制一些业务逻辑也很麻烦，因此正式使用还是得自己写代码。