2025，MCP、Agent、AI Coding

这是我从 腾讯裸辞 成为自由职业以后，写的第三篇年终总结。

前两年的年终总结，以罗列产品为主。

过去两年，我基本上把能做的 AI 产品都做了一遍，大多都是浅尝辄止，没有在一个赛道上深耕。

喧嚣过后，留下一堆遗憾。短线项目图一时之快，并没有带来持续的成就感和正反馈。

2025，我收敛了很多，没有再做很多产品，主要关注点集中在三个方面：MCP、Agent、AI Coding。

MCP

2024 年 11 月，Anthropic 发布了 MCP，在 AI 互联网引起了短暂的轰动。

有人叫好，有人看衰，有人看不懂。有人追热点上线了 MCP 服务器导航站，没有持续迭代，等 MCP 热度下降之后，这些导航站自然也销声匿迹了。

MCP.so

我在 2024 年 11 月底上线了 MCP.so，初期定位是 MCP 服务器导航站。

抓取了网上大几千个 MCP 服务器，用 AI 对每个 MCP 服务器做了结构化总结，生产了几千个 MCP 服务器相关的网页，并在 2025 年 1-3 月保持着更新。

直到 3 月初，Manus 的发布，引爆了 MCP。业界都在讨论 Manus 用到了 MCP 服务器。

国内外知名厂商都宣布支持 MCP，MCP 关键词搜索量暴涨。由于前期的 pSEO 积累，MCP.so 很快拿到了 MCP 关键词搜索引擎前几名的位置。

马太效应开始显现，国外知名投资机构 a16z 引用 MCP.so 做行业报告。国内自媒体开始推荐 MCP.so。网站访问量快速增长，2025.04 月份访问量 2.7M。

回顾 2025 年，MCP.so 网站总访问量 11M，新增用户 1.5M。

由于产品功能简单、缺乏持续运营等原因，MCP.so 的用户留存不高，也没有很好的商业化。

MCP.so 的商业化主要靠品牌广告收入，跟 Trae、硅基流动、PPT.ai、Skywork、AlphaVantage 等品牌有过合作，广告收入 1.2w 美金。

4 月份的时候，有人出价 20w 美金收购 MCP.so，我没有卖，想着要趁热打铁好好迭代下去，可惜因为个人精力分散、时间有限，没有做得更好。

2026 年，我会在 MCP.so 上继续投入，做好品控，筛选和推荐优质的 MCP 服务器，扩展 Skills 品类，让网站有更高的用户粘性，也要做更多的商业化尝试。

《这就是 MCP》

3 月底的时候，人民邮电出版社图灵教育的英子老师找到我，让我写一本关于 MCP 的书。

跟英子老师认识两年多了，之前准备合作出 GPTs 的书，没写成。

后来 ThinkAny 火的时候，打算写本关于 AI 搜索的书，也没写成。

终究还是赶上了第三次机会。MCP 热度很高，而我刚好是对 MCP 研究最深的人之一，同时 MCP.so 也有一定的知名度。几个因素叠加在一起，我似乎成了写 MCP 书的最佳人选，于是我们一拍即合，开始写书。

4, 5, 6 三个月，我基本上没写代码，全部时间投入到写书之中。

写书的过程非常痛苦。跟写代码相比，非常的枯燥乏味。需要查资料、跑案例、配图，工作效率非常低。还要注重表达的一致性、逻辑的严谨性，咬文嚼字，反复修改。

我们最初计划 4 月份写完，5 月份出版。最终，7 月份才定稿。

8 月份，《这就是 MCP》正式出版了。

第一次写书，我很激动。自购了 1500 本，送给 1024 全栈开发社群、ShipAny 天使股东群 的成员，以及网上认识的一些朋友。

10 月份收到了第一笔版税：2.3w。《这就是 MCP》三个月累计销售 3700 余册，在纯技术类书籍里面算是卖得还不错了。其中我自购 1500 本，支出 6w 多，要卖到一万本才能回本。

从经济学的角度来说，《这就是 MCP》 ROI 没打正，是一笔亏本的投资。

从心理学的角度来说，《这就是 MCP》给了我一种新的体验，解锁了一类新的成就感。快乐无价。

2026 年，如果时间允许，我想写一本关于全栈开发的书。把自己掌握的技能，系统化地总结出来，帮助到有需要的人，于人于己都是一件有意义的事情。

MCPRouter

MCP 最为人诟病的一个点是，上手门槛过高。用户使用 MCP 服务器时，需要拉代码到本地运行，安装依赖、配置环境等操作难住了不少非专业用户。

因此，我一直认为，一个纯云端的 MCP 路由平台是必要的。

我在 2025.09 月份做了一个 MCPRouter 项目，定位是一个基于 MCP 的原子能力平台，给 Agent 提供各种类型的 Tools，让 Agent 可以专注于业务逻辑的实现，按需引入各种能力。

MCPRouter 后端是一个 K8S 集群，部署了常用的 MCP 服务器，对前端提供 HTTP 的接入方式，只需一个 API Key，即可连接云端的 MCP 服务器，调用各种类型的工具。

MCPRouter 发展的关键是走精品路线，采集或自研高质量的 MCP 服务器，通过 MCP 服务器对接下游服务，给前端暴露丰富的原子能力。重点是供应链的整合，在对接的下游平台绑卡、充值、监控余额，与下游供应商建立合作关系，确保服务的稳定性和可靠性。

2026 年，MCPRouter 继续完善，重点投入。

MCP 会不会凉？

2025.10 月，Anthropic 发布了 Agent Skills，旨在将重复性工作流程打包成可复用的指令，让 Agent 能自动、可靠地完成任务，无需每次都重复提醒。

Agent Skills 的核心理念是 渐进式暴露，可以有效解决 MCP 一次性加载工具污染上下文的问题。

有人问我：Agent Skills 的发布，是否意味着 MCP 要凉了？

我认为 MCP 不会凉。主要观点有二：

1. MCP 从发布之初，定位就是 AI 应用与外部工具之间的连接器。

在互联网和移动互联网时代，API 是应用接入外部服务的标准方式，其背后是 HTTP 协议。

在 AI 互联网时代，Function Calling 是 AI 应用接入外部工具的主流方式，MCP 是基于 Function Calling 的标准化协议。

跟 HTTP 类比，MCP 应该是一个幕后的角色。

• 提供服务的厂商基于 MCP 开放能力（以前是开放 API）
• 接入服务的 AI 应用基于 MCP 挂载工具（以前是直接调用 API）
• 普通用户使用 AI 应用，不需要感知 MCP 的存在

Agent Skills 的工作原理是通过本地的提示词文档，指导 Agent 在什么情况下做什么事情，主要解决的是上下文管理的问题。

Agent Skills 可以通过 MCP 挂载外部工具，自身并不是连接器的角色，从这个角度来说，Agent Skills 与 MCP 不是单向的替代关系。

2.MCP 是原子能力的包裹器，外部工具的说明书。

模型的数量是有限的，能力的数量是无限的。

MCP 是原子能力的包裹器，每一个内置在 MCP 内的工具，都会有针对使用场景和参数格式的描述。

随着 MCP 生态的发展，越来越多的开发者用 MCP 包裹工具，每个工具的定义，相当于给调用的 API 写了一份使用文档。

Agent Skills 的定位是给 Agent 看的说明书，把能够 SOP 化的流程，做成给 Agent 调用的 Skills。对外部工具的调用，是流程的一部分，所以 Skills 可以按需挂载 MCP 包裹的工具。

MCP 给海量工具写说明书，广播给整个 AI 互联网；Agent Skills 给具体的流程写说明书，指导 Agent 完成特定任务。

从这一角度看，Agent Skills 是 MCP 的补充。

Agent

2025 年被认作是 Agent 的元年。

最具代表性的产品是 Manus，把通用智能体的热度推向了新的高度。今年大大小小的 AI 活动，演讲者的 PPT 基本都以 Manus 作为开篇。不到一年时间，Manus 持续高走，最终被 Meta 以 20 亿美金的价格收购。成为 AI 时代一个足以被铭记的经典案例。

我认为 Manus 的成功在于用户体验的创新，包含了足够丰富的工程细节，比如基于 sanbox 的云端虚拟机，以 todo.md 为基础的 plan + act 流程，会话回放等。

在 Manus 爆火的那几天，国内很多团队都在尝试复刻 Manus，没几天就出了好几个 OpenManus 类型的产品。然而这些产品，并没有在产品体验方面媲美 Manus。所谓的复刻，也只是复刻了 Agent 自主规划、执行任务的流程，没有 sanbox，没有 browser-use，不能算是一个 toC 的通用 Agent 产品。

据我了解，Manus 产品推出之前，大致投入了 10 人的团队，研发了三个月的时间。

这一年我一直在思考一个问题，作为独立开发者，或者三五人的小团队，我们如何才能在一周内、或者一月内，做出一个 Manus 级别的 Agent 产品。

我研究了一遍市面上知名的 Agent 产品，我把这类产品的底层构成拆解成三大件：Framework、Tools、Sanbox。

Agent 三大件

Framework（框架）

开发一个 Agent 产品，需要一个框架来支撑。这个框架需要提供一个 Agent 的骨架，包括 Plan（规划）、Act（执行）、Memory（记忆）、Context Manager（上下文管理）等核心能力。

一个好的 Agent 开发框架，应该做到开箱即用，开发者只需要针对业务场景，调试提示词、定制工作流，再挂载一些必要的工具，就能实现最基本的 Agentic 能力。

市面上流行的 Agent 开发框架有 LangGraph、AutoGen、CrewAI、LlamaIndex、Mastra 等。我认为这些框架还是过于底层，虽然封装了很多功能，保留了足够的灵活性，但还是很难做到开箱即用。

一个很简单的类比，做 AI SaaS 项目，常选的开发框架是 Next.js，作为一个全栈开发框架，封装了路由、服务端渲染、中间件、缓存等基础功能。但是对于一个不熟悉 MVC 架构的开发者来说，上手成本还是略高。

所以我做了 ShipAny，把 AI SaaS 常用的登录注册、数据库、文件存储、多语言、支付、落地页、管理后台都集成进去，让开发者只需要修改几个配置文件 + 写一个业务相关的 Generator 组件，就能快速上线一个 AI SaaS 项目。

ShipAny 主打的定位是：一小时上线 AI SaaS 网站。我希望 2026 年能实现一个 Agent 开发框架，主打定位是：一天内上线一个 Manus 级别的 Agent 产品。

Manus 级别 这个定语是非常关键的，意味着这不是对 Agent 调度流程的复刻，而是一个包含完整交互体验的 Agent 产品。

Tools（工具）

Tools 是 Agent 的工具箱，包含了各种原子能力。

据说 Manus 上线初期，包含了 29 个供大模型调度的工具，涉及浏览器操作、Shell 操作、文件操作、信息查询、消息交互等方面。

要实现 一天内上线一个 Agent 产品 的目标，除了梳理清楚业务需求，给 Agent 提供系统提示词和内置工作流之外，还需要给 Agent 提供必要的工具。

比如，一个主打 Deep Research 的 Agent，需要用到联网搜索、阅读网页、文件解析等工具。

一个主打 播客生成 的 Agent，需要用到联网搜索、TTS、音频合成等工具。

前面聊 MCPRouter 的时候提到，我希望做一个基于 MCP 的原子能力平台。作为 Agent 的工具箱，让各种业务类型的 Agent 都能按需挂载适合自己业务场景的工具。

如果这个原子能力平台完善了，就能大大降低 Agent 的开发门槛，让开发者从开发工具的繁琐中解脱出来，专注于业务逻辑的实现。

Sanbox（沙盒）

Manus 出圈很大一个原因，我觉得是云端虚拟机的使用。让普罗大众第一次看到了有个 AI 在干活，每个步骤在做什么，产出什么，清晰可见，这才是智能产品该有的样子。

如果以交付结果为第一性原理，Sanbox 不是 Agent 产品的必需品。比如某些 Agent 产品，当用户提交一个任务后，启动了 Agentic 流程或者只是执行一个 Workflow，用户不知道 Agent 具体在干什么，产出了什么，等了 20 分钟，在右边的展示框看到了一个网页，或者一个播客。如果不评价最终的交付结果，整个交互流程，用户体验是非常不好的，这也很难算得上是一个真正的 Agent 产品。

接入 Sanbox 的 Agent，至少有两个好处：

1. 提供更完整的隔离机制，让每个用户的每个任务，在独立的沙盒运行，安全性更高，也更可控。
2. 可视化输出每个步骤的关键产出，给用户一种更好的体验，也更方便做 human-in-the-loop，比如让用户输入验证码，或者用户看某个步骤走偏了，可以及时纠正或终止任务。

Sanbox 的技术关键在于集群部署、动态扩容、毫秒级启动、并发控制、资源隔离、数据持久化等，没有一定的容器化经验、不熟悉 K8S 的开发者，一般很难搞定这些技术细节。

当然，我们可以选择像 Manus 一样接入 e2b，或者像 Bolt 一样接入 Webcontainers，这里又会涉及到对开源项目的部署和运维技巧，以及成本管控等问题。

我们目前不能做到一个周末就上线一个 Manus 级别的 Agent 产品，我觉得最大的卡点在于 Sanbox 的部署和接入。期待 2026 年，会有更轻量级的 Sanbox 解决方案，成本可控，接入便利。让 Agent 开发者可以专注业务逻辑的实现，针对业务流程定制工作流，选择合适的工具，快速上线。

AI Coding

AI Coding 这个赛道，时不时有黑马出来，给了我们很多惊喜。

最初是 Cursor，让程序员习惯了用 Tab 键来写代码，提升了编码效率，引发了 AI 辅助编程的热潮。

后来是 Devin，首个 AI 软件工程师，把自动化编程推向了新的高度，也启发了 Manus 的设计。

然后是 Bolt / Lovable，让产品经理学会了自己做产品，带火了 Vibe Coding 的概念。

Coding Agent 赛道之王毫无疑问是 Claude Code，6 个月 10 亿美金 ARR，相当炸裂。

AI Coding 是我个人很看好，也很感兴趣的方向。2024.09 月，我做了一个叫 Pagen 的产品，主打的功能是一句话生成 Landing Page，后面大模型的能力越来越强，一句话生成网页的功能被模型内化。Pagen 的产品定位变得很尴尬，我就没有继续做下去。

2025.02 月，我发布了 CopyWeb，主打网页复刻功能，用户上传截图或者输入网址，AI 快速复刻一个相似的网页或者 UI 组件。CopyWeb 上线之初只是一个 Workflow 类型的产品，没有 Agentic 的自动化流程，没有 Sanbox 做项目容器，整体的体验不算很好。后面没有持续迭代，也没有推广，全靠自然增长，CopyWeb 2025 年 ARR 2.4w 美金，有点意外。

2025.03 月，同样主打网页复刻功能的 Coding Agent 产品 Same 发布，开发者是硅谷的创业团队，3 个 05 后少年，在没有投流的情况下，四个月做到了三百万美金的 ARR，非常厉害。

现在的 Coding Agent 赛道分为两个流派，一个是以 Claude Code 为代表的终端 Agent，另一个是以 Lovable 为代表的 Web Agent。竞争已经非常激烈，对后来者而言，错过了最佳的窗口期。我一直在想，2026 年继续做 Coding Agent，我可以从哪方面切入？

我想到了两个方向。

做垂类场景

CopyWeb 和 Same 验证了网页复刻这个场景，是有需求的。

可惜后面 Same 融资几轮之后，转向去做全场景的 Coding Agent 了，没有深耕网页复刻场景。

CopyWeb 今年的目标就是要改成 Coding Agent，结合 ShipAny + Browser Use + Sanbox，用 Agentic 的方式深入分析用户输入的参考网站，给出更好的复刻效果。

基于模板做增量填充

Lovable 的用户，用 Lovable 的典型场景是用来做 Demo，当做 Presentation 工具使用。在专业程序员看来，Lovable 产出的项目顶多算是玩具，功能不完整，不具备实用价值。

Lovable 之类的 Web Agent 自然也意识到了这个问题，朝着全栈功能集成的方向在做，引入 Backend、数据库等功能。同时也提供了一些高频场景的 Templates，让用户可以快速 Remix。

比起让 AI 从零生成一个项目，基于模板做增量填充，是让 Coding Agent 做出更完整项目的好解法。本质是让 AI 的产出更加收敛，效果更加可控。

ShipAny 作为一个包含几十项 Web 项目常用功能的成熟代码模板，下一步方向自然是云端的 Coding Agent。希望 2026 年，我能让 ShipAny 成为 Coding Agent 的基础底座，让 Coding Agent 在交付质量方面上一个台阶。

总结

回顾我的 2025，总的来说还算如意。按照自己的喜好做产品，依旧自由。

• 继 ThinkAny 之后，做出了一个新的爆款：MCP.so
• 发布了 ShipAny Two，堆了很多功能，明确了迭代的方向
• 写了本书，多了“《这就是 MCP》作者”这个 Title
• 在 GTLC、AI Con 两个知名大会做了分享，拿了明星讲师称号
• 遇到了很欣赏我的人，愿意投资我做产品，虽然最终没有拿钱
• 去了一趟济州岛，通关了黑神话悟空，从 150 瘦到了 135

2026，我最想做的方向是 Agent Infra + Agent 工厂。

• 围绕 Framework、Tools、Sanbox 三个方向，做一套好用的 Agent Infra
• 把过去两年尝试过的产品，都改成 Agent，跑在自己的 Agent Infra 之上

越来越能理解“性格决定命运”这句话，也越来越能接受自己的性格了。

不喜欢社交就不社交，组不了团队就独立开发，拿不到投资就自己赚钱，不想专注就广泛尝试。

与其求而不得，感受痛苦。不如顺其自然，享受自由。

新的一年，少一些宏大叙事，多一些落地执行。

感谢所有支持我、信任我、帮助我、陪伴我的人。

2026，愿家人健康平安，望世界和平。

文章来自于微信公众号 “艾逗笔”，作者 “艾逗笔”