★ FEATURED ARTICLE 1. 桌面工作台与 MCP 的碰撞为什么要把本地工具链接进 Agent1.1 从“手动切窗口”到“Agent 直接调用”的转变日常开发里最割裂的一件事就是工具链散落在桌面各处。终端一个窗口、编辑器一个窗口、数据库客户端一个窗口、调试器一个窗口Agent 想帮你干点活只能靠你复制粘贴上下文或者写一堆脚本把结果导出来再喂进去。MCPModel Context Protocol出现之后这件事有了标准答案把本地能力封装成 Agent 能直接调用的工具让模型自己决定什么时候该执行什么命令、读什么文件、查什么数据。Termexo 这个项目做的事情就是把这套思路落地到桌面工作台上。它把终端、文件系统、进程管理、代码检索、任务编排等 19 个常用能力统一封装成 MCP 工具然后通过标准协议暴露给 Claude Code、Codex 这类 Agent 客户端。你不需要改 Agent 的源码也不需要写复杂的适配层只要在配置文件里加一段 MCP server 声明Agent 就能像调用内置工具一样调用你桌面上的这些能力。我最初关注这个方向是因为在实际项目里频繁遇到一个痛点Agent 能写代码但看不到我本地真实的运行环境。它不知道当前目录下有哪些文件、不知道某个服务有没有起来、不知道日志里报了什么错。每次都要我手动把信息贴给它效率极低。Termexo 这类工具的价值就是把这层“环境感知”和“操作执行”的能力补齐让 Agent 从“只会聊天写代码”变成“能真正动手干活”。1.2 19 个工具到底覆盖了哪些场景Termexo 的 19 个工具不是随便凑数的它基本覆盖了桌面工作台上最高频的几类操作。我把它分成四组来看终端执行类执行 shell 命令、获取命令输出、管理后台进程、查看进程状态。这类工具解决的是“Agent 想跑个命令但没法直接跑”的问题。文件系统类读取文件、写入文件、列出目录、搜索文件内容、获取文件元信息。这类工具让 Agent 能直接操作本地文件而不是靠你复制粘贴。代码检索类按关键词搜索代码、按文件类型过滤、获取代码片段上下文。这类工具对大型项目特别有用Agent 不用把整个仓库读一遍就能定位到关键代码。任务编排类创建任务、查询任务状态、取消任务、获取任务结果。这类工具让 Agent 能管理长时间运行的操作比如跑测试、构建项目、执行数据迁移。这四组工具组合起来基本能覆盖一个开发者日常 80% 的桌面操作。更重要的是它们是通过 MCP 标准协议暴露的意味着任何支持 MCP 的 Agent 客户端都能接入不绑定特定厂商。1.3 适合谁来用这套方案这套方案最适合三类人第一类是重度使用 Agent 编码的开发者。如果你已经在用 Claude Code 或 Codex 写代码但总觉得 Agent 对本地环境“感知不足”那接入 Termexo 之后体验会有明显提升。Agent 能自己去看文件、跑命令、查日志你只需要给高层指令。第二类是需要自动化重复任务的技术人员。比如每天要跑一遍构建、检查服务状态、清理临时文件这些操作可以通过 MCP 工具编排成 Agent 任务让 Agent 按需执行。第三类是对 Agent 架构感兴趣的学习者。Termexo 的 19 个工具设计本身就是一个很好的 MCP 实践案例你可以从中学习如何把本地能力抽象成标准工具接口如何设计工具的参数和返回值如何处理错误和超时。注意Termexo 目前主要面向桌面环境如果你主要在远程服务器上工作需要确认它的工具是否支持远程执行模式或者考虑在本地做端口转发。2. MCP 协议核心机制与 Termexo 的工具设计思路2.1 MCP 到底是什么用生活化类比讲清楚MCP 全称 Model Context Protocol直译是“模型上下文协议”。你可以把它理解成 Agent 和外部工具之间的“USB 接口标准”。以前每个 Agent 想调用外部能力都要自己定义一套接口工具提供方也要为每个 Agent 单独适配工作量巨大。MCP 做的事情就是定义一套统一的“插头”和“插座”标准工具提供方按标准做一个 MCP serverAgent 客户端按标准做一个 MCP client双方就能即插即用。具体到技术层面MCP 定义了三种核心能力Tools工具Agent 可以调用的函数有明确的输入参数和返回值。Termexo 的 19 个工具就是这类。Resources资源Agent 可以读取的数据比如文件内容、数据库记录。Termexo 的文件读取工具也涉及这部分。Prompts提示模板预定义的提示词模板帮助 Agent 更好地使用工具。Termexo 目前主要聚焦在 Tools 层面。通信方式上MCP 支持 stdio标准输入输出和 SSEServer-Sent Events两种传输模式。Termexo 作为本地桌面工具通常用 stdio 模式Agent 客户端启动时把 Termexo 作为子进程拉起通过标准输入输出交换 JSON-RPC 消息。这种模式的好处是不需要网络端口安全性好启动快。2.2 为什么 Termexo 选择封装这 19 个工具工具设计最怕两件事一是工具太少Agent 干不了活二是工具太多Agent 不知道该用哪个。Termexo 选 19 个这个数量我觉得是经过权衡的。从覆盖度看19 个工具刚好能覆盖“执行-读取-检索-编排”这个完整闭环。少了任何一个环节Agent 都会卡住。比如只有执行没有读取Agent 跑完命令看不到结果只有读取没有检索Agent 在大项目里找不到关键文件。从认知负担看19 个工具对 Agent 来说还在可控范围内。MCP 客户端通常会把所有工具的名称和描述塞进模型的上下文工具太多会挤占宝贵的 token 预算。19 个工具的描述加起来大概几百个 token对现代模型来说完全可以接受。从实现复杂度看这 19 个工具背后复用的底层能力很多。比如终端执行和进程管理共享同一套进程池文件读取和代码检索共享同一套文件遍历逻辑。这种设计让代码量可控维护成本低。2.3 工具参数设计的几个关键决策我仔细看了 Termexo 的工具定义有几个参数设计决策值得拿出来说第一个是超时参数。几乎所有执行类工具都带timeout参数默认值通常在 30 秒左右。这个设计很关键因为 Agent 调用的命令可能卡住没有超时机制会导致整个会话挂起。默认 30 秒是个平衡点大部分命令能跑完异常情况也能及时释放。第二个是工作目录参数。文件类和执行类工具都支持cwd参数让 Agent 能指定在哪个目录下操作。这个设计避免了 Agent 必须依赖全局状态每次调用都是显式的更安全也更可预测。第三个是输出截断参数。执行命令的输出可能非常大Termexo 提供了max_output之类的参数来控制返回给 Agent 的内容长度。这个设计很实用因为 Agent 的上下文窗口有限返回几万行日志会直接撑爆。第四个是错误处理策略。工具执行失败时Termexo 不是简单抛异常而是返回结构化的错误信息包括错误码、错误消息、部分输出。这样 Agent 能根据错误类型决定是重试、换命令还是向用户求助。提示如果你自己开发 MCP 工具建议参考这套参数设计。特别是超时和输出截断这两个不做的话实际使用中很容易出问题。3. Agent 自动接入的完整实操流程3.1 环境准备安装 Termexo 与 Agent 客户端先说前置条件。你需要一台桌面环境Windows、macOS、Linux 都行然后安装两样东西Termexo 本体和至少一个支持 MCP 的 Agent 客户端。Termexo 的安装方式取决于它的发布形式。如果是二进制包下载后解压到某个目录记下可执行文件路径。如果是包管理器安装比如通过 npm 或 brew安装后确认命令在 PATH 里。我建议把 Termexo 放在一个固定路径下比如~/tools/termexo/后面配置 MCP server 时会用到这个路径。Agent 客户端这边Claude Code 和 Codex 都支持 MCP。Claude Code 的安装方式通常是通过 npm 全局安装Codex 也有对应的安装包。安装完成后你需要确认客户端版本支持 MCP 功能太老的版本可能没有这个能力。验证安装是否成功可以跑一下 Termexo 的版本命令比如termexo --version确认能正常输出。然后再跑一下 Agent 客户端的版本命令确认两者都能正常工作。3.2 配置 MCP Server让 Agent 找到 Termexo这一步是整个接入的核心。不同 Agent 客户端的配置文件位置和格式略有差异但核心逻辑是一样的告诉客户端“有一个 MCP server它的启动命令是什么参数是什么”。以 Claude Code 为例配置文件通常在用户目录下的.claude/目录里可能叫mcp.json或类似名字。配置内容大概长这样{ mcpServers: { termexo: { command: /Users/yourname/tools/termexo/termexo, args: [--mcp, --stdio], env: { TERMEXO_WORKSPACE: /Users/yourname/projects } } } }几个关键点解释一下command是 Termexo 可执行文件的绝对路径。一定要用绝对路径因为 Agent 客户端启动子进程时工作目录可能不是你预期的位置。args是启动参数。--mcp表示以 MCP server 模式运行--stdio表示用标准输入输出通信。具体参数名以 Termexo 文档为准。env是环境变量。TERMEXO_WORKSPACE用来限制 Termexo 能操作的工作目录范围这是个安全边界建议设置。Codex 的配置方式类似但配置文件位置和字段名可能不同。Codex 通常用 TOML 格式的配置文件在~/.codex/config.toml里加一段[mcp_servers.termexo]的配置。具体写法参考 Codex 官方文档的 MCP 章节。配置完成后重启 Agent 客户端。客户端启动时会读取配置拉起 Termexo 子进程然后通过 MCP 协议握手。如果配置正确你会在客户端的工具列表里看到 Termexo 提供的 19 个工具。3.3 验证接入用几个简单命令测试配置完不要急着上复杂任务先用简单命令验证链路是否通。第一个测试让 Agent 列出当前目录下的文件。你可以说“列出我工作目录下的所有文件”Agent 应该会调用 Termexo 的目录列表工具返回文件列表。如果返回正常说明文件系统类工具通了。第二个测试让 Agent 执行一个简单命令比如echo hello。Agent 应该调用终端执行工具返回hello。如果返回正常说明执行类工具通了。第三个测试让 Agent 搜索一个关键词。比如“在项目里搜索 TODO 注释”Agent 应该调用代码检索工具返回匹配的文件和行号。如果返回正常说明检索类工具通了。这三个测试覆盖了主要工具类别都通过的话基本可以确认接入成功。如果某个测试失败先检查配置文件路径和参数再看 Agent 客户端的日志输出通常会有具体的错误信息。注意有些 Agent 客户端在首次加载 MCP server 时会弹出权限确认需要你手动允许。如果发现工具列表是空的先检查是不是有未确认的权限请求。3.4 参数调优超时、并发与输出限制默认参数能跑通但实际使用中可能需要调优。我整理了几个常见场景的调优建议场景参数建议值理由跑单元测试timeout120-300 秒测试套件可能跑几分钟默认 30 秒不够构建大型项目timeout300-600 秒全量构建耗时较长需要放宽超时读取大日志max_output5000-10000 字符太大撑爆上下文太小看不到关键信息并发执行max_concurrent2-4太多并发会拖慢系统太少效率低搜索大仓库max_results50-100结果太多 Agent 处理不过来这些值不是固定的需要根据你的机器性能和项目规模调整。我的经验是先从默认值开始遇到问题再针对性调整不要一上来就把所有参数拉满。4. 19 个工具的深度拆解与使用技巧4.1 终端执行类工具不只是跑命令终端执行类工具看起来简单就是跑个 shell 命令返回输出但实际使用中有很多细节。第一个细节是 shell 选择。Termexo 默认可能用/bin/sh或系统默认 shell但有些命令依赖 bash 或 zsh 的特性。如果发现命令行为不符合预期检查一下 shell 配置。有些实现支持通过参数指定 shell比如shell: bash。第二个细节是环境变量继承。Agent 启动 Termexo 时环境变量是从 Agent 客户端继承的。如果你在 shell 里配置了 PATH 或自定义变量Agent 可能看不到。解决办法是在 MCP 配置的env字段里显式传入需要的变量。第三个细节是交互式命令处理。有些命令会等待用户输入比如read或sudo密码提示。这类命令在 MCP 场景下会卡住因为 Agent 没法交互。Termexo 通常会检测到这种情况并返回超时错误。遇到这类命令要么改用非交互模式要么提前配置好免密。第四个细节是输出编码。如果命令输出包含非 UTF-8 字符返回给 Agent 时可能乱码。Termexo 一般会做编码转换但特殊字符仍可能出问题。遇到乱码时可以在命令里加LC_ALLC或类似设置强制用 ASCII 输出。实操心得我习惯在让 Agent 执行命令前先自己手动跑一遍确认命令没有交互式提示、没有超长输出、没有特殊编码问题。这样能避免很多莫名其妙的失败。4.2 文件系统类工具安全边界很重要文件系统类工具让 Agent 能直接读写本地文件这是能力也是风险。Termexo 在这方面做了几层防护第一层是工作目录限制。通过TERMEXO_WORKSPACE环境变量Termexo 只允许操作指定目录下的文件。Agent 想读/etc/passwd或写~/.ssh/config都会被拒绝。这个边界一定要设置不要图省事放开整个文件系统。第二层是路径规范化。Agent 可能传入../../etc/passwd这种路径试图逃逸Termexo 会对路径做规范化处理解析成绝对路径后再检查是否在工作目录内。这个逻辑必须严谨否则容易被绕过。第三层是文件大小限制。读取超大文件时Termexo 会截断或拒绝避免把整个文件塞进 Agent 上下文。默认限制通常在几 MB 级别可以通过参数调整。使用技巧方面我建议让 Agent 读取文件时尽量指定行号范围而不是读整个文件。比如“读取 src/main.py 的第 50 到 100 行”这样返回的内容更精准也节省 token。Termexo 的读取工具通常支持start_line和end_line参数。写入文件时要特别小心。Agent 可能会覆盖重要文件建议在让 Agent 写文件前先确认目标路径必要时先备份。有些实现支持 dry-run 模式可以先预览要写入的内容再确认。4.3 代码检索类工具大项目里的导航仪代码检索类工具是我用得最多的。在一个几万行代码的项目里Agent 不可能把整个仓库读一遍必须靠检索定位关键代码。Termexo 的检索工具通常支持几种模式按关键词搜索传入关键词返回匹配的文件和行号。适合找函数名、变量名、注释。按文件类型过滤只搜索.py或.ts文件减少噪音。正则表达式搜索支持复杂模式匹配适合找特定代码结构。上下文获取找到匹配行后获取前后几行的上下文帮助理解代码。使用技巧方面关键词选择很关键。太宽泛的关键词会返回大量结果太具体又可能漏掉。我的经验是先用宽泛关键词定位大致范围再用具体关键词缩小范围。比如先搜auth找到认证相关文件再搜validate_token找到具体函数。还有一个技巧是结合文件类型过滤。在混合技术栈的项目里搜config可能返回 Python、JavaScript、YAML 各种文件。加上file_type: python就能只看 Python 配置。提示如果检索结果太多可以让 Agent 先返回文件列表再逐个文件深入。这样比一次性返回所有匹配行更高效。4.4 任务编排类工具管理长时间运行的操作任务编排类工具解决的是“命令跑太久Agent 不能一直等”的问题。比如跑一个全量测试套件要 10 分钟Agent 不可能阻塞 10 分钟等结果。Termexo 的做法是把这类操作变成异步任务Agent 提交任务后立即返回任务 ID然后可以定期查询任务状态任务完成后获取结果。这套机制的核心是任务队列和状态管理。Termexo 内部维护一个任务表每个任务有状态pending、running、completed、failed、开始时间、结束时间、输出结果。Agent 通过任务 ID 查询状态根据状态决定下一步操作。使用技巧方面我建议对超过 30 秒的操作都用任务模式。具体做法是让 Agent 先提交任务然后每隔几秒查询一次状态直到任务完成。这样 Agent 不会被阻塞可以同时处理其他事情。任务取消也很重要。如果发现任务跑错了方向Agent 可以调用取消工具终止任务。Termexo 收到取消请求后会尝试终止对应的进程。需要注意的是有些进程可能不响应终止信号需要强制 kill。4.5 工具组合使用的实战案例单独用某个工具能干活但组合起来威力更大。我分享一个实际案例让 Agent 自动排查一个服务启动失败的问题。第一步Agent 调用终端执行工具尝试启动服务捕获错误输出。假设错误是“端口被占用”。第二步Agent 调用终端执行工具用lsof -i :8080或netstat查看哪个进程占用了端口。第三步Agent 调用进程管理工具获取该进程的详细信息判断是不是自己之前启动的残留进程。第四步如果是残留进程Agent 调用终端执行工具 kill 掉它然后重新启动服务。第五步Agent 调用终端执行工具确认服务启动成功再调用文件读取工具查看日志确认没有其他错误。这个流程里用到了执行、进程管理、文件读取三类工具Agent 自主完成了排查和修复。如果没有 MCP 工具这些操作都要人工介入效率差很多。5. 常见问题排查与避坑经验实录5.1 接入失败类问题速查接入阶段最容易出问题我整理了一个速查表现象可能原因排查方法解决方案工具列表为空配置文件路径错误检查客户端日志确认配置文件在正确位置工具列表为空可执行文件路径错误手动跑 command 看是否报错改用绝对路径启动即崩溃参数不兼容看 stderr 输出对照文档确认参数握手超时stdio 模式冲突检查是否有其他输出确保 Termexo 只输出 JSON-RPC权限被拒客户端未授权查看权限提示手动允许 MCP server其中“握手超时”这个问题比较隐蔽。MCP 用 stdio 通信时要求 server 端只往标准输出写 JSON-RPC 消息不能有任何其他输出。如果 Termexo 启动时打印了欢迎信息或日志到 stdout就会干扰握手。解决办法是把日志输出重定向到 stderr 或文件。5.2 工具调用失败类问题工具调用阶段的问题通常和参数、环境、权限有关超时问题命令跑太久超过 timeout 设置。解决办法是调大 timeout或者改用任务模式异步执行。我遇到过跑数据库迁移脚本超时的情况调到 600 秒才够。路径问题Agent 传入的路径不存在或不在工作目录内。排查方法是让 Agent 先列出目录确认路径再执行操作。有时候是 Agent 拼错了路径有时候是工作目录设置不对。权限问题Agent 尝试执行需要特权的命令比如安装软件包、修改系统配置。这类操作在 MCP 场景下通常会被拒绝。解决办法是提前配置好权限或者改用不需要特权的替代方案。编码问题命令输出包含特殊字符导致解析失败。解决办法是在命令里设置LC_ALLC或者让 Termexo 做编码转换。并发冲突多个工具调用同时操作同一个文件或进程。解决办法是让 Agent 串行执行相关操作或者加锁机制。5.3 性能与稳定性优化建议用了一段时间后我总结了几条优化建议第一条是限制工作目录范围。不要图省事把整个用户目录设为工作区只设项目目录。这样既安全又能减少文件遍历的开销。第二条是合理设置超时。默认 30 秒对大部分命令够用但构建、测试、迁移这类操作需要更长。我建议按操作类型设置不同超时而不是全局调大。第三条是控制输出大小。Agent 的上下文窗口是稀缺资源返回几万行日志会挤占其他内容。建议设置max_output在 5000 到 10000 字符之间超出部分截断并提示。第四条是定期清理任务。异步任务完成后任务记录会占用内存。Termexo 通常有清理机制但如果你发现内存增长异常检查一下任务表是不是没清理。第五条是监控资源占用。Termexo 作为常驻进程会占用一定的 CPU 和内存。如果发现系统变慢用进程管理工具看看 Termexo 的资源占用必要时重启。5.4 安全使用的几条底线MCP 工具让 Agent 能操作本地环境安全底线必须守住底线一工作目录限制不能放开。这是最重要的安全边界一旦放开Agent 可能误删系统文件或读取敏感信息。底线二危险命令要拦截。rm -rf /、dd if/dev/zero、mkfs这类命令应该在 Termexo 层面拦截不能指望 Agent 自己判断。底线三敏感文件要排除。.env、id_rsa、credentials.json这类文件应该在工作目录里排除不让 Agent 读取。底线四操作日志要保留。Termexo 应该记录所有工具调用包括时间、参数、结果。出问题时可以追溯。底线五定期审查 Agent 行为。不要完全放手让 Agent 操作定期看看它调用了哪些工具、执行了什么命令及时发现异常。注意安全不是一次性的而是持续的过程。随着 Agent 能力增强攻击面也在变化建议定期回顾安全配置。5.5 我踩过的几个坑最后分享几个我实际踩过的坑希望能帮你省点时间。坑一配置文件用了相对路径。Agent 客户端启动子进程时工作目录不确定相对路径经常找不到文件。改成绝对路径后问题消失。坑二忘了设置工作目录环境变量。结果 Termexo 默认用当前目录Agent 在项目 A 里操作时跑到了项目 B 的目录。设置TERMEXO_WORKSPACE后解决。坑三让 Agent 跑交互式命令。比如npm init会等待输入结果卡到超时。后来改成npm init -y非交互模式。坑四输出太大撑爆上下文。让 Agent 读了一个 10MB 的日志文件结果整个会话卡死。后来加了max_output限制。坑五并发调用导致文件冲突。两个工具调用同时写同一个文件结果内容错乱。后来让 Agent 串行执行写操作。这些坑看起来都是小问题但实际遇到时很影响体验。提前知道能省不少排查时间。6. 从 Termexo 看 MCP 工具生态的演进方向6.1 工具粒度粗一点还是细一点Termexo 的 19 个工具粒度算是中等偏细。比如文件操作拆成了读、写、列目录、搜索、获取元信息五个工具而不是一个“文件操作”大工具。这种设计的好处是 Agent 能精确选择需要的操作参数也更清晰。坏处是工具数量多Agent 选择时需要更多推理。我观察到 MCP 生态里两种设计都有。有些项目倾向于粗粒度一个工具搞定一类操作通过参数区分具体行为。有些倾向于细粒度每个操作一个工具。哪种更好没有定论取决于使用场景。对于高频操作细粒度更高效对于低频操作粗粒度更简洁。Termexo 的选择我理解是偏向高频场景优化。终端执行、文件读写、代码检索这些都是开发者每天用几十次的操作细粒度能让 Agent 更快选对工具。6.2 错误处理让 Agent 能自我修复MCP 工具的错误处理设计直接影响 Agent 的自我修复能力。如果工具只返回“失败”两个字Agent 不知道该怎么调整。如果返回结构化的错误信息包括错误类型、错误位置、建议操作Agent 就能尝试修复。Termexo 在错误处理上做得比较细。比如命令执行失败时会返回退出码、stderr 内容、部分 stdout 内容。Agent 可以根据退出码判断是命令不存在、参数错误还是运行时错误然后采取不同策略。我觉得这是 MCP 工具设计里最容易被忽视但最重要的部分。很多工具开发者只关注正常路径错误路径随便返回个异常就完事。结果 Agent 遇到错误就卡住用户体验很差。6.3 与 Agent 客户端的协作模式Termexo 作为 MCP server和 Agent 客户端是松耦合的。客户端负责决策server 负责执行。这种分工的好处是 server 不需要理解业务逻辑只需要把工具做好。坏处是 server 无法主动发起操作只能被动响应。未来可能会看到更多协作模式。比如 server 可以主动推送事件告诉 Agent“你之前提交的任务完成了”或“监控的文件发生了变化”。这样 Agent 就不用轮询效率更高。MCP 协议本身支持 server 发通知但目前的工具实现用得还不多。另一个方向是工具之间的组合。Termexo 的 19 个工具目前是独立的Agent 需要自己编排调用顺序。未来可能会有更高层的“工作流”工具把常见操作序列封装成一个调用。这样 Agent 不用每次都重新编排效率和可靠性都更高。6.4 给想自己开发 MCP 工具的人的建议如果你看完 Termexo 的设计想自己开发 MCP 工具我有几条建议第一条是从真实需求出发。不要为了做工具而做工具先想清楚 Agent 在什么场景下需要这个能力没有它会怎样。真实需求驱动的工具才有生命力。第二条是把错误处理做扎实。正常路径谁都能写错误路径才见功力。每种可能的失败都要有清晰的错误信息让 Agent 能理解并尝试修复。第三条是控制工具数量。工具不是越多越好每个工具都会占用 Agent 的上下文预算。宁可少而精不要多而杂。第四条是做好安全边界。MCP 工具能操作本地环境安全是底线。工作目录限制、危险命令拦截、敏感文件排除这些都要做。第五条是持续迭代。工具发布后要收集使用反馈看 Agent 在哪些场景下用得不顺然后针对性优化。MCP 生态还在早期很多最佳实践还在形成中。我在实际使用 Termexo 的过程中最大的体会是MCP 工具的价值不在于单个工具多强大而在于组合起来能不能让 Agent 真正“动手干活”。19 个工具单独看都很普通但组合起来就能覆盖桌面工作台的大部分操作让 Agent 从“顾问”变成“执行者”。这个转变带来的效率提升比单纯提升模型能力更明显。如果你也在用 Agent 编码建议花点时间把本地工具链接进 MCP体验会有质的改变。
阅读完成 · 觉得有帮助？
