1. 从月费订阅到自建代理这笔账到底怎么算第一次看到 Claude Cowork 的定价页面时我的反应和大多数人一样——每月 200 美元折合人民币一千四百多对于个人开发者和小团队来说这个数字足够覆盖一台不错的云服务器加上一堆 API 调用费用了。但真正让我决定动手自建的原因不是单纯的价格而是可控性。订阅制产品意味着你的工作流、数据流向、模型选择全部被锁定在别人的框架里想换个模型等更新。想接自己的本地知识库看文档支持不支持。想调整代理的决策逻辑抱歉黑盒。所以我花了大概两周时间用开源方案搭了一套功能对标的 AI 代理系统核心思路是MCP 协议做工具调用层本地模型加云端 API 做推理层自己写调度逻辑做编排层。整套跑下来日常使用成本基本为零本地模型跑在自己的机器上偶尔调用云端 API 的费用一个月也就几美元。更重要的是每一个环节我都能改、能调、能替换。这篇文章适合三类人看一是对 MCP 协议好奇但还没动手的开发者二是想自建 AI 代理但不知道从哪下手的折腾党三是已经在用各种 AI 助手但觉得不够顺手、想深度定制的工作流玩家。我会从架构设计讲到具体实现把踩过的坑和验证过的方案都摊开来说。提示本文涉及的所有工具和方案均为开源或免费额度可覆盖的范围不涉及任何需要特殊网络配置的服务。2. MCP 协议到底解决了什么问题2.1 没有 MCP 之前AI 代理是怎么接工具的在 MCP 出现之前让 AI 代理调用外部工具基本靠两种方式一种是函数调用Function Calling每个模型厂商有自己的格式OpenAI 一套、Anthropic 一套、本地模型又是另一套换个模型就得重写一遍工具定义另一种是插件系统比如某些平台提供的插件市场但插件和平台深度绑定迁移成本极高。我最早做的一个项目是让 AI 助手帮我查数据库、生成报表。当时用的是某平台的函数调用接口工具定义写了三百多行 JSON Schema结果想换成本地模型跑的时候发现格式完全不兼容又花了两天重写。这种重复劳动在 MCP 之前是常态。2.2 MCP 的核心抽象把工具变成标准化的服务MCPModel Context Protocol的思路其实很朴素——定义一个标准协议让工具提供方和使用方解耦。你可以把它理解成 AI 世界的 USB-C 接口不管你是数据库、文件系统、浏览器还是某个垂直领域的 API只要按照 MCP 协议暴露能力任何支持 MCP 的客户端都能直接调用。具体来说MCP 定义了三种核心能力Resources资源静态或动态的数据源比如文件内容、数据库查询结果、API 返回的 JSON。客户端可以读取这些资源作为上下文。Tools工具可执行的操作比如写入文件、发送请求、执行查询。模型决定调用哪个工具、传什么参数。Prompts提示模板预定义的提示词模板方便客户端快速调用常见任务。我实测下来最实用的就是 Tools 这一层。以前写一个数据库查询功能要在代码里硬编码 SQL 模板、参数校验、结果格式化现在只需要写一个 MCP Server 暴露query_database工具任何 MCP 客户端都能用而且模型自己会根据用户意图决定什么时候调用、传什么参数。2.3 为什么说 MCP 是自建代理的基石自建 AI 代理最大的痛点不是模型本身而是工具生态。你不可能自己写完所有工具——文件操作、网页抓取、代码执行、API 调用、数据库查询每一项都要单独开发的话工作量巨大。MCP 的价值在于社区已经有大量现成的 MCP Server 可以直接用你只需要写一个 MCP 客户端来调度这些 Server就能快速搭建起功能完整的代理系统。我目前跑在本地的一套系统里同时接了文件系统 MCP、SQLite MCP、浏览器自动化 MCP、还有几个自己写的垂直领域 MCP Server。整个调度层不到五百行代码但代理能做的事情已经覆盖了我日常 80% 的需求。3. 自建代理的架构选型哪些环节可以省哪些不能省3.1 推理层本地模型和云端 API 怎么搭配这是最关键的决策点。全用云端 API成本下不来全用本地模型复杂任务的推理质量又不够。我的方案是分层路由任务类型推理层选择理由简单工具调用查文件、执行命令本地 7B 模型延迟低、零成本、够用中等复杂度多步推理、代码生成本地 14B-32B 模型质量可接受成本为零高复杂度长文档分析、架构设计云端 API质量优先按量付费敏感数据处理本地模型数据不出本机路由逻辑我写了一个简单的分类器根据任务描述的长度、关键词、历史调用成功率来决定走哪条路。实测下来大概 70% 的请求本地模型就能处理只有 30% 需要走云端月度 API 费用控制在 5 美元以内。本地模型我试过几个方案最后稳定在用 Ollama 做运行时模型选的是 Qwen 系列的中等规模版本。选它的原因是工具调用格式支持好而且中文理解能力比同规模的 Llama 系列强不少。3.2 工具层MCP Server 的选型和自建社区现成的 MCP Server 已经覆盖了大部分通用场景我直接拿来用的有文件系统 MCP读写本地文件、目录遍历、文件搜索SQLite MCP本地数据库查询和写入Fetch MCP网页内容抓取和转换Git MCP版本控制操作但有些场景现成的不好用我自己写了几个项目文档 MCP索引本地 Markdown 和 PDF 文档支持语义搜索API 网关 MCP封装了常用的第三方 API 调用统一鉴权和错误处理代码执行 MCP在沙箱环境里跑 Python 和 Shell 脚本自己写 MCP Server 其实不难官方有 Python 和 TypeScript 的 SDK照着示例改改就能跑。关键是工具描述要写清楚模型能不能正确调用很大程度上取决于你对工具功能的自然语言描述是否准确。3.3 编排层调度逻辑自己写还是用框架我试过几个开源的代理框架最后决定自己写调度逻辑。原因有两个一是框架的抽象层太厚出问题不好排查二是我的需求比较特定框架的通用设计反而碍事。自己写的调度层核心就三件事意图识别判断用户请求需要哪些工具、走哪条推理路径工具调用按照 MCP 协议调用对应的 Server处理返回结果上下文管理维护对话历史、工具调用记录、中间结果代码量不大但灵活性极高。比如我加了一个工具调用失败自动重试并切换备用方案的逻辑用框架的话得改源码自己写就是加个 try-catch 的事。4. 从零搭建的完整步骤4.1 环境准备别急着装一堆东西我见过很多人一上来就 clone 十几个仓库装了一堆依赖结果跑不起来。正确的做法是先跑通最小闭环一个 MCP Server 一个 MCP 客户端 一个本地模型能完成一次完整的工具调用就行。我的最小环境清单Python 3.11MCP SDK 对版本有要求Ollama本地模型运行时一个 MCP Server建议从文件系统 MCP 开始一个 MCP 客户端可以自己写也可以用现成的调试工具装好之后先验证 MCP Server 能正常启动、客户端能列出工具列表、模型能正确调用一个简单工具。这个闭环跑通了再往上加东西。4.2 写第一个 MCP Server从文件操作开始文件系统 MCP 是最容易理解的入门示例。核心逻辑就是暴露几个工具读文件、写文件、列目录、搜索文件。每个工具的定义包括名称、描述、参数 Schema。写的时候有几个坑要注意路径安全一定要限制可访问的目录范围别让模型能读写整个文件系统文件大小限制读大文件的时候要截断不然上下文直接爆掉编码处理统一用 UTF-8遇到二进制文件要正确报错而不是崩溃我第一版没做路径限制测试的时候模型直接去读系统配置文件虽然没造成什么后果但想想还是后怕。后来加了一个白名单机制只允许访问指定的几个工作目录。4.3 接入本地模型Ollama 的配置和调优Ollama 的安装很简单关键是模型选择和参数调优。我试过的几个模型对比模型工具调用支持中文能力推理速度内存占用Qwen2.5-7B好优秀快约 6GBQwen2.5-14B很好优秀中等约 12GBLlama3.1-8B好一般快约 8GBMistral-7B一般较差快约 6GB最后我主力用 Qwen2.5-14B复杂任务切云端。Ollama 的num_ctx参数要调大默认 2048 不够用我设的 8192。temperature设低一点0.1-0.3工具调用场景不需要太多创造性。4.4 调度层实现意图识别和工具路由调度层的核心是一个状态机接收用户输入 → 判断意图 → 选择工具 → 执行 → 判断是否完成 → 返回结果或继续循环。意图识别我用的是规则 模型的混合方案。简单请求比如读一下 xxx 文件直接用正则匹配复杂请求才走模型判断。这样既快又准。工具路由的关键是给模型清晰的工具列表和选择指引。我在系统提示里写了一段工具选择规则比如涉及文件操作优先用文件系统工具需要最新信息时用网页抓取工具模型遵循这些规则的成功率明显提高。4.5 上下文管理别让对话历史撑爆窗口这是自建代理最容易忽略的问题。对话轮次一多上下文窗口很快就满了。我的方案是分层压缩最近 5 轮对话完整保留5-20 轮只保留用户输入和最终回复去掉中间的工具调用细节20 轮以上生成摘要只保留关键信息另外工具调用的返回结果如果太长也要做截断或摘要。我遇到过一次模型调用数据库查询返回了上千行数据直接把上下文撑爆后面所有请求都失败了。后来加了一个结果长度限制超过阈值的自动截断并提示模型结果已截断如需完整数据请缩小查询范围。5. 实测中踩过的坑和解决方案5.1 工具调用格式不兼容模型换了Schema 全废这个问题在早期特别常见。不同模型对工具调用的格式要求不一样有的要求 JSON Schema有的要求特定格式的字符串有的甚至不支持并行调用。我一开始写了一套工具定义换模型的时候发现完全不能用。解决方案是在调度层做格式适配。我写了一个转换层把统一的工具定义转换成各个模型要求的格式。这样上层逻辑不用改换模型只需要加一个适配器。5.2 模型幻觉调用不存在的工具也敢调本地模型有时候会调用不存在的工具或者传错误的参数。这在云端大模型上很少见但本地小模型确实会犯。我的处理方式是双重校验调度层先检查工具名是否存在、参数是否符合 Schema不通过的直接返回错误信息让模型重新生成。另外在系统提示里明确列出所有可用工具的名称和参数格式也能显著降低幻觉调用的概率。5.3 长任务中断跑到一半没反应了自建代理跑长任务比如批量处理文件、多步数据分析的时候经常遇到跑到一半卡住的情况。排查下来主要有两个原因一是模型生成了超长的工具调用链超出了最大迭代次数二是某个工具调用超时但没有正确处理。我的修复方案是加超时和迭代上限每个工具调用设置 30 秒超时整个任务设置 20 次迭代上限超限就返回当前进度并提示用户。同时加了日志记录每次工具调用都记下输入输出方便排查。5.4 成本失控云端 API 调用量意外飙升虽然大部分请求走本地模型但有时候分类器判断失误把简单任务路由到了云端或者某个循环逻辑导致重复调用 API。我设置了一个每日预算上限超过阈值自动切换到纯本地模式同时发通知提醒。另外云端 API 的调用要加缓存。相同的查询请求在一定时间内直接返回缓存结果不用重复调用。我实测下来缓存命中率大概 30%省了不少钱。6. 全生态工具链推荐6.1 MCP Server 生态哪些值得装除了前面提到的文件系统、SQLite、Fetch、Git 这几个基础款还有几个我实测好用的PostgreSQL MCP如果你用 Postgres这个比 SQLite 版本功能更全支持复杂的查询和事务浏览器自动化 MCP基于 Playwright能做网页截图、表单填写、数据抓取代码执行 MCP在沙箱里跑代码适合做数据分析和自动化脚本文档索引 MCP把本地文档做成可搜索的知识库代理能直接引用装的时候注意权限控制特别是文件系统和代码执行类的 MCP一定要限制访问范围。6.2 客户端选择调试和日常使用分开调试阶段我推荐用专门的 MCP 调试工具能直观看到工具列表、调用过程、返回结果。日常使用的话可以自己写一个简单的 CLI 或者 Web 界面也可以集成到现有的编辑器或聊天工具里。我自己日常用的是命令行界面输入问题直接回车代理自动判断是否需要调用工具。复杂任务会显示执行进度完成后输出结果。简单但够用。6.3 模型管理本地和云端的统一调度模型管理这块我用了一个简单的配置文件来定义各个模型的端点、API Key、适用场景。调度层根据任务类型自动选择模型也支持手动指定。本地模型用 Ollama 管理云端 API 直接走 HTTP 请求。关键是统一的接口封装上层调度逻辑不关心底层是本地还是云端只调用统一的generate和chat接口。7. 日常使用中的经验技巧7.1 提示词工程让代理更懂你自建代理最大的优势就是系统提示完全可控。我在系统提示里写了自己的工作习惯、常用工具、输出格式偏好代理的响应质量比通用助手高不少。比如我要求所有代码输出必须带文件路径和语言标注所有命令必须能在当前系统直接执行所有解释必须用中文但保留英文术语。这些细节在订阅制产品里很难定制自建就随便改。7.2 工具组合把多个 MCP 串起来用单个 MCP Server 的能力有限但组合起来就很强。我经常用的一个组合是文件系统 MCP 读取项目文档 → 文档索引 MCP 做语义搜索 → 代码执行 MCP 跑分析脚本 → 结果写回文件。整个流程代理自动编排我只需要说一句分析一下这个项目的代码质量。7.3 监控和日志出问题能快速定位自建系统一定要有日志。我记录每次请求的完整链路用户输入、意图判断结果、选择的模型、调用的工具、返回结果、耗时、是否成功。出问题的时候直接看日志比猜快得多。另外建议加一个简单的监控面板显示每日请求量、成功率、平均延迟、API 费用。我用的是一个轻量的本地 Web 服务数据存 SQLite够用了。7.4 安全边界别让代理权限过大这是最重要的一条。自建代理意味着你给了它执行操作的权限如果权限过大一个错误的工具调用可能造成不可逆的后果。我的做法是文件系统只开放特定工作目录代码执行在沙箱环境限制网络和文件访问危险操作删除、覆盖、发送请求需要二次确认所有操作留日志可追溯注意千万不要给代理 root 权限或者无限制的网络访问权限这是自建系统最容易犯的错误。8. 后续可以继续折腾的方向这套系统跑了一个多月基本稳定了。接下来我打算继续完善几个方向一是加更多的垂直领域 MCP Server比如日历管理、邮件处理、笔记同步二是优化路由逻辑用历史数据训练一个更准的分类器三是做一个 Web 界面方便在手机上也能用。如果你也在自建 AI 代理建议先从最小闭环开始跑通了再逐步加功能。别一上来就追求大而全那样很容易卡在环境配置阶段就放弃了。我踩过的这些坑希望你能绕过去。