1. 桌面工作台与 MCP 的碰撞：为什么要把本地工具链接进 Agent
1.1 从“手动切窗口”到“Agent 直接调用”的转变
日常开发里最割裂的一件事，就是工具链散落在桌面各处。终端一个窗口、编辑器一个窗口、数据库客户端一个窗口、调试器一个窗口，Agent 想帮你干点活，只能靠你复制粘贴上下文，或者写一堆脚本把结果导出来再喂进去。MCP（Model 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 server，Agent 客户端按标准做一个 MCP client，双方就能即插即用。
具体到技术层面，MCP 定义了三种核心能力：
- Tools（工具）：Agent 可以调用的函数，有明确的输入参数和返回值。Termexo 的 19 个工具就是这类。
- Resources（资源）：Agent 可以读取的数据，比如文件内容、数据库记录。Termexo 的文件读取工具也涉及这部分。
- Prompts（提示模板）：预定义的提示词模板，帮助 Agent 更好地使用工具。Termexo 目前主要聚焦在 Tools 层面。
通信方式上，MCP 支持 stdio（标准输入输出）和 SSE（Server-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 参数调优：超时、并发与输出限制
默认参数能跑通，但实际使用中可能需要调优。我整理了几个常见场景的调优建议：
| 场景 | 参数 | 建议值 | 理由 |
|---|---|---|---|
| 跑单元测试 | timeout | 120-300 秒 | 测试套件可能跑几分钟，默认 30 秒不够 |
| 构建大型项目 | timeout | 300-600 秒 | 全量构建耗时较长，需要放宽超时 |
| 读取大日志 | max_output | 5000-10000 字符 | 太大撑爆上下文，太小看不到关键信息 |
| 并发执行 | max_concurrent | 2-4 | 太多并发会拖慢系统，太少效率低 |
| 搜索大仓库 | max_results | 50-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_ALL=C或类似设置强制用 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_ALL=C，或者让 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，体验会有质的改变。
