个人回顾与深度思考：我的2025，MCP、Agent与AI Coding开发工具、生态演进

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

前两年的总结，更多是罗列产品。

• 2023，我做过的 AI 项目
• 2024，我追过的 AI 风口

过去两年，我基本上把能尝试的 AI 产品方向都摸索了一遍，但大多是浅尝辄止，没有在单一赛道上进行深耕。

喧嚣过后，留下不少遗憾。那些短线项目虽然带来一时快感，却未能提供持续的成就感和正向反馈。

2025年，我收敛了许多，没有再盲目追逐众多产品，主要精力集中在了三个方面：MCP、Agent 和 AI Coding。

MCP

2024年11月，Anthropic发布了模型上下文协议（MCP），在AI圈内引起了短暂的轰动。

一时间，有人叫好，有人看衰，也有人表示看不懂。不少追热点的团队迅速上线了MCP服务器导航站，但由于缺乏持续迭代，随着MCP初期热度下降，这些站点也大多销声匿迹。

MCP.so

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

我们抓取了网络上公开的数千个MCP服务器，利用AI对每个服务器进行了结构化总结，生成了大量相关网页，并在2025年1月至3月期间保持了内容更新。

转机出现在3月初。随着Manus的发布引爆了市场，业界开始热烈讨论其背后使用的MCP服务器技术。国内外众多知名厂商相继宣布支持MCP，导致“MCP”关键词的搜索量暴涨。得益于前期的搜索引擎优化积累，MCP.so迅速占据了相关搜索结果的前列。

马太效应开始显现。国外知名投资机构a16z在其行业报告中引用了MCP.so的数据，国内自媒体也开始推荐这个网站。网站的访问量随之快速增长，仅2025年4月的访问量就达到了270万次。

回顾整个2025年，MCP.so网站总访问量达1100万，新增用户150万。

不过，由于产品功能相对简单、缺乏持续的精细化运营，MCP.so的用户留存率并不高，商业化探索也较为有限。

MCP.so的主要商业化收入来源于品牌广告，曾与Trae、硅基流动、PPT.ai、Skywork、AlphaVantage等品牌合作，累计广告收入约1.2万美元。

今年4月，曾有买家出价20万美元意图收购MCP.so，但我没有接受。当时的想法是趁热打铁，继续迭代优化。可惜后来由于个人精力分散、时间有限，未能将其做得更好。

2026年，我计划继续在MCP.so上投入精力，做好品控，筛选和推荐优质的MCP服务器，并扩展Skills品类，以提升用户粘性，同时进行更多商业化尝试。

《这就是 MCP》

3月底，人民邮电出版社图灵教育的编辑联系到我，希望我能撰写一本关于MCP的书籍。

其实我们相识已有两年多，之前曾计划合作出版关于GPTs的书籍，未能成行。后来ThinkAny火爆时，又打算写一本关于AI搜索的书，同样搁浅。

这次终于赶上了第三次机会。当时MCP热度正高，而我又恰巧是对其研究较深的人之一，加之MCP.so具备一定知名度。多种因素叠加，我似乎成了撰写MCP书籍的合适人选，于是我们一拍即合，开始了写作。

4、5、6整整三个月，我几乎没怎么写代码，将所有时间都投入到了写书之中。

写书的过程异常痛苦。与写代码相比，它显得枯燥而繁琐。需要查阅大量资料、运行验证案例、配置插图，工作效率很低。同时还要注重表述的一致性、逻辑的严谨性，常常需要咬文嚼字，反复修改。

我们最初计划4月完稿，5月出版。但最终，直到7月份才正式定稿。

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

第一次出书，心情非常激动。我自购了1500本，赠送给“1024全栈开发社群”、“ShipAny天使股东群”的成员，以及一些在网上结识的朋友。

10月份，我收到了第一笔版税：2.3万元。《这就是 MCP》在上市后的三个月内累计销售了3700余册，在纯技术类书籍中算是不错的成绩。不过，由于我个人自购了1500本，支出超过6万元，这意味着需要销售约一万本才能回本。

从纯粹的经济学角度来看，《这就是 MCP》的投资回报率尚未转正，是一笔亏损的投资。

但从心理学的角度来看，这本书给予我一种全新的体验，解锁了一类前所未有的成就感。这份快乐，或许是无价的。

2026年，如果时间允许，我想写一本关于全栈开发的书。将自己掌握的技能进行系统化总结，帮助有需要的人，这对他人和自己都是一件有意义的事。

MCPRouter

MCP最常被诟病的一点是上手门槛过高。用户想要使用一个MCP服务器，通常需要将代码拉取到本地，进行安装依赖、配置环境等操作，这难住了不少非技术背景的用户。

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

我在2025年9月启动了MCPRouter项目，其定位是一个基于MCP的原子能力平台，旨在为各种Agent提供丰富多样的工具（Tools），让Agent能够专注于业务逻辑的实现，按需引入所需能力。

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

MCPRouter发展的关键在于走精品路线，采集或自研高质量的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的成功在于其用户体验上的创新，它包含了足够丰富的工程细节，例如基于沙盒（Sandbox）的云端虚拟机、以todo.md文件为基础的“规划-执行”（Plan + Act）流程，以及会话回放等功能。

在Manus爆火的那几天，国内许多团队都在尝试复刻，短时间内便出现了好几个“OpenManus”类型的项目。然而，这些产品在产品体验上均无法与Manus媲美。所谓的复刻，大多只复刻了Agent自主规划、执行任务的流程框架，缺少沙盒环境、真实的浏览器操作（browser-use）等关键组件，很难称得上是面向普通用户（toC）的通用Agent产品。

据我了解，Manus在正式推出前，大约投入了一个10人团队，研发了三个月时间。

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

我研究了一遍市面上知名的Agent产品，将这类产品的底层构成拆解为三大件：框架（Framework）、工具（Tools）、沙盒（Sandbox）。

Agent 三大件

1. 框架（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产品。

2. 工具（Tools）

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

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

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

例如，一个主打深度研究（Deep Research）的Agent，需要用到联网搜索、网页内容提取、文件解析等工具。
一个主打播客生成的Agent，则需要用到联网搜索、文本转语音（TTS）、音频合成等工具。

前文讨论MCPRouter时提到，我希望打造一个基于MCP的原子能力平台。它将成为Agent的“工具箱”，让各种业务类型的Agent都能按需挂载适合自身场景的工具。

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

3. 沙盒（Sandbox）

Manus能够出圈，我认为其云端虚拟机的使用是关键因素之一。它让普通大众第一次直观地看到“有一个AI在干活”，每一个步骤在做什么、产出什么，都清晰可见。这才是智能产品该有的样子。

如果以“交付结果”为第一性原理，沙盒并非Agent产品的绝对必需品。例如，某些Agent产品在用户提交任务后，只是启动了一个Agentic流程或执行一个工作流。用户无法知晓Agent具体在做什么、产出了什么，等待20分钟后，才在右侧的展示框里看到一个网页或一段音频。如果不评价最终结果，整个交互流程的用户体验并不理想，这很难称得上是一个真正的Agent产品。

接入沙盒的Agent，至少有两个显著好处：

1. 提供更完整的隔离机制，让每个用户的每个任务都在独立的沙盒环境中运行，安全性更高，控制也更精细。
2. 可视化输出每个步骤的关键产出，给予用户更优的体验，也便于实现“人在回路”（human-in-the-loop）。例如，让用户输入验证码，或者在发现某个步骤偏离预期时，用户可以及时纠正或终止任务。

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

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

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

AI Coding

AI编程（AI Coding）这个赛道，时不时就有黑马涌现，带给我们许多惊喜。

最初是Cursor，它让程序员习惯了用Tab键来编写代码，显著提升了编码效率，引发了AI辅助编程的热潮。
接着是Devin，作为首个AI软件工程师，它将自动化编程推向了新的高度，也启发了Manus的设计。
然后是Bolt / Lovable，它们让产品经理也能自己动手制作产品，带火了“氛围编程”（Vibe Coding）的概念。
而Coding Agent赛道的王者无疑是Claude Code，6个月达成10亿美元年度经常性收入（ARR）的成绩，相当震撼。

AI Coding是我个人非常看好且感兴趣的领域。2024年9月，我做了一个名为Pagen的产品，主打功能是“一句话生成落地页”。后来，随着大模型能力的不断增强，“一句话生成网页”的功能逐渐被模型内化。Pagen的产品定位变得尴尬，我便没有继续下去。

2025年2月，我发布了CopyWeb，主打网页复刻功能。用户上传截图或输入网址，AI可以快速复刻出一个相似的网页或UI组件。CopyWeb上线初期只是一个工作流（Workflow）类型的产品，不具备Agentic的自动化流程，也没有沙盒作为项目容器，整体体验不算完美。后期由于没有持续迭代和推广，全靠自然增长。令人意外的是，CopyWeb在2025年实现了2.4万美元的ARR。

2025年3月，同样主打网页复刻功能的Coding Agent产品“Same”发布。其开发者是硅谷的一个创业团队，由三位“05后”少年组成。在没有进行付费推广的情况下，四个月时间做到了三百万美元的ARR，非常厉害。

目前的Coding Agent赛道主要分为两个流派：一个是以Claude Code为代表的“终端Agent”，另一个是以Lovable为代表的“Web Agent”。竞争已非常激烈，对于后来者而言，最佳窗口期或许已经错过。我一直在思考，2026年如果继续深耕Coding Agent，可以从哪个方向切入？

我想到了两个可能的方向。

1. 深耕垂直场景
   CopyWeb和Same的成功，验证了“网页复刻”这个场景确实存在市场需求。
   可惜的是，Same在获得几轮融资后，转向了全场景的Coding Agent，并未在网页复刻这个垂直场景继续深耕。
   CopyWeb在今年的目标，就是改造为Coding Agent，结合ShipAny、浏览器操作（Browser Use）和沙盒环境，通过Agentic的方式深入分析用户输入的参考网站，以期达到更好的复刻效果。

2. 基于模板进行增量填充
   Lovable用户的典型使用场景是制作Demo，将其作为演示工具。在专业程序员看来，Lovable生成的项目可能更像是“玩具”，功能不完整，缺乏实用价值。
   Lovable这类Web Agent自然也意识到了这个问题，正在朝着集成后端、数据库等全栈功能的方向发展。同时，它们也提供了一些高频场景的模板（Templates），供用户快速复用和修改。
   比起让AI从零开始生成一个项目，基于成熟模板进行增量填充，是让Coding Agent产出更完整、更实用项目的好方法。其本质是让AI的产出范围更加收敛，从而使效果更加可控。
   ShipAny作为一个集成了数十项Web项目常用功能的成熟代码模板，下一步的发展方向自然是成为云端的Coding Agent基础。希望2026年，我能让ShipAny成为Coding Agent的坚实底座，帮助Coding Agent在项目交付质量上迈上一个新台阶。

总结

回顾我的2025年，总体而言还算满意。我依然按照自己的喜好做产品，保持着自由的状态。

• 继ThinkAny之后，做出了一个新的爆款产品：MCP.so。
• 发布了ShipAny Two版本，堆叠了许多功能，明确了未来的迭代方向。
• 出版了一本书，多了“《这就是 MCP》作者”这个头衔。
• 在GTLC、AI Con两个知名技术大会上做了分享，获得了明星讲师的称号。
• 遇到了欣赏我并愿意投资我做产品的人，虽然最终并未接受投资。
• 去了一趟济州岛，通关了游戏《黑神话：悟空》，体重从150斤减到了135斤。

2026年，我最想探索的方向是“Agent基础设施 + Agent工厂”。

• 围绕框架（Framework）、工具（Tools）、沙盒（Sandbox）三大方向，打造一套好用、易用的Agent基础设施。
• 将过去两年尝试过的各种产品理念，都用Agent的方式重构一遍，运行在自己搭建的这套Agent基础设施之上。

我越来越能理解“性格决定命运”这句话，也越来越能接纳自己的性格。
不喜欢社交便不勉强社交，暂时组建不了团队就坚持独立开发，拿不到投资就自己努力赚钱，无法长期专注就广泛尝试探索。
与其为了得不到的东西而痛苦，不如顺其自然，享受当下的自由。

新的一年，希望自己少一些宏大叙事，多一些落地执行。
感谢所有在过去一年中支持我、信任我、帮助我、陪伴我的人。

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

希望这篇来自独立开发者的年度复盘，也能为你带来一些启发。如果你对MCP、Agent或全栈开发有更多想法，欢迎在云栈社区这样的技术论坛进行交流探讨。