为何我们移除了 MCP 集成——以及我们所构建的新方案

以下为译文：

我们从 @duetchat 一开始就完整支持 MCP 集成，甚至实现了 OAuth 和动态客户端注册。但在 v2 版本，我们直接把这个功能删掉了。下面说说我们为什么切换，以及这对 AI 代理架构的未来意味着什么。

TL;DR：让 AI 代理自己用代码写集成的方案，在上下文效率、能力广度、长期适应性三个维度上，都全面碾压 MCP 工具包装。
MCP 的做法是提前把几十个工具定义塞进上下文；而代码执行代理则什么都不预加载，需要时再写代码、保存、复用。

MCP 的上下文膨胀问题

MCP（Model Context Protocol）是目前 AI 代理连接外部服务的主流标准：定义一堆工具（带 schema 的函数），塞进 agent 的上下文，让它调用。

它能用，但问题很快暴露。

核心问题是线性上下文成本。
每增加一个 MCP 工具（名字、描述、参数 schema、示例），都要占用上下文空间。
接 10 个服务，每个服务 5 个工具，agent 还没干活，上下文就烧掉几千 token。

这就形成痛苦的权衡：

要么全部预加载 → 实际任务的推理空间、对话历史、工作记忆都大幅缩水；
要么限制集成数量 → agent 只能对接少数几个服务；
要么做动态工具加载 → 又引入延迟和复杂的工具选择中间件。

都不理想。上下文窗口是 agent 最宝贵的房地产，用它来塞可能永远用不上的工具定义，纯属浪费。

替代方案：让代理自己写集成

如果 agent 根本不需要预定义的工具呢？

我们的新做法是：不注入 MCP 工具定义，而是给 agent 一个持久化服务器环境，让它自己写代码、执行代码。
当 agent 需要对接外部服务时，它会：

查 API（读文档、找 endpoint、理解鉴权）
写集成代码（Python 或 TypeScript，直接调用 API）
执行代码（在自己的服务器上跑，拿到结果）
保存代码（存到持久化内存，下次直接复用）

下次再需要同一个集成时，它什么都不用重新发现，直接加载已保存的代码运行。
随着使用时间推移，agent 会自己建起一个越来越庞大的“自写集成库”。

启动时的上下文成本？零。
它只在需要时加载需要的东西。

为什么代码执行完胜工具包装？

这不只是性能优化，而是根本性的能力跃升。

MCP Tools vs 代码执行（对比表）：

上下文成本：MCP 是 O(n)（每加一个工具就膨胀）；代码执行是 O(1)（只加载当前需要的）
API 覆盖度：MCP 只暴露工具作者定义的部分；代码执行能覆盖整个 API 表面（所有 endpoint、参数、边缘情况）
定制能力：MCP 被预定义参数限制；代码执行完全无限制，agent 想写啥写啥
错误处理：MCP 只有通用工具级错误；代码执行能写自定义重试、fallback、数据转换
组合能力：MCP 一次只能调用一个工具；代码执行能在一个脚本里串联多个 API 调用、转换数据、搭建流水线
适应性：MCP 需要开发者手动更新工具；代码执行让 agent 自己维护代码，API 一改它立刻自更新

举个具体例子：
一个 MCP 的 Linear 工具可能只暴露 create_issue、list_issues、update_issue 这几个固定操作。
而能自己写代码的 agent，可以调用 Linear 的任意 endpoint、把多个调用组合成一个操作、转换数据格式、处理工具作者根本没想到的边缘情况。

agent 不受任何人预设的限制，它拥有整个 API 的全部力量。

自进化软件

这个架构最有意思的地方在于：agent 会自己进化自己的集成。

API 调用失败 → agent 调试、修复代码、保存改进版
需要新数据转换 → agent 自己写并加到库里
服务改 API → 下次运行时 agent 自动更新代码

这就是自进化软件。agent 的集成层不再是静态的，而是随着使用不断生长、适应。

而 MCP 工具永远冻结在开发者发布的版本：
API 改了等工具作者更新；需要新功能就提 issue 等。agent 完全受外部维护者摆布。

有了代码执行，agent 就是自己的维护者。

基础设施要求

这个架构有一个前提：agent 必须同时拥有三样东西：

持久化服务器（能运行代码、存文件、跨会话保持状态）
记忆系统（保存集成代码，不占用上下文）
代码执行环境（支持网络、包管理、文件系统）

这就是为什么大多数 session-based AI（ChatGPT、Claude.ai 等）做不到——它们每次对话都是全新环境，没有持久化、没有记忆、无法积累。

你需要一个永远在线的云服务器，agent 今天写的脚本下周还能跑，能安装包、保存凭证、逐步构建自己的代码库。

这也正是 @duetchat（duet.so）的核心架构赌注：
每个用户都获得一个持久化云服务器 + 常驻 AI 代理。agent 有自己的文件系统、记忆、定时任务、代码执行环境。它自己写集成、自己保存、自己复用，用得越久就越强大。

这也是为什么这种方案目前还很少见——大多数 AI 产品天生就是无状态的。搭建持久化、服务器后端的 agent，是一条完全不同的基础设施道路。

这对 AI 集成的未来意味着什么？

MCP 并不会完全消失。它对简单、定义清晰的工具交互仍然很有用，也是快速启动 agent 能力的捷径。

但对于需要在几十个服务间工作、处理边缘情况、长期进化的生产级 AI 代理，未来属于持久化基础设施上的代码执行。

未来的集成层不再是一份预制工具目录，而是一个能读 API 文档、自己写代码的 agent。

以下内容由译者添注：

结合评论区的社区总结

针对此论调评论观点非常分裂，但已形成清晰共识：

主流声音（支持代码执行派，占多数）：

很多人高度认可“上下文膨胀”和 O(n) vs O(1) 的对比。
@grankin_d（Vexa.ai 创始人）提出最务实的中间方案：“MCP 做 discovery（发现层）+ 代码执行做实际工作” —— 用 MCP 找到可用 API，再让 agent 自己写自定义代码。这条建议获赞最多。
@morganlinton（Perplexity 相关）回复说自己在 benchmark 中也观察到同样趋势。

质疑/反驳声音（少数但尖锐）：

@zby 指出：保存的实现还是需要上下文去查找，“工具描述本质上就是告诉 agent 什么时候用”。他认为“为每个用户独立重写 API 实现”从程序员角度看是“灾难”。
@essamsleiman 建议：可以预加载常用集成到 agent 的 memory/fs，只对新 API 才让它自己写。David 本人回复：“取决于使用场景——垂直 agent（95% 固定场景）值得；通用聊天型 agent 不值得。”

长期观察派：

David 本人回复一条经典金句：“save this tweet and we can compare notes in a year :)” —— “存好这条推文，一年后我们再对比谁对”。这句话被很多人点赞，认为最冷静。

哲学派：

@GetVasily 说：“协议本来就是人类为旧问题发明的，agent 自己发明新协议很正常，就像自然界一样。”

总体社区共识：

MCP 不是彻底死了，而是正在从“标准”降级为“可选发现层”。
大厂（Perplexity、DuetChat）抛弃它，是因为要极致性能和自进化能力；
中小团队和垂直场景短期内还能继续享受它的优雅和 Laravel 原生融合优势。

David 这篇长文写得非常理性、数据化、对比清晰，已经成为目前“反 MCP”阵营最有说服力的宣言之一。

如果你刚开始学 MCP，看完这篇翻译后，建议你先别急着删代码——可以按 @grankin_d 的混合方案走（MCP 发现 + 代码执行实际工作），既保留优雅性，又跟上未来趋势。