1. 为什么我要认真聊聊 mcp-ssh-manager 这个工具
第一次看到 mcp-ssh-manager 这个名字，我脑子里蹦出来的第一个念头是：终于有人把 MCP 和 SSH 这两件事捏到一起了。MCP 是 Model Context Protocol，简单说就是让 AI 助手能够调用外部工具、读取外部资源的一套标准协议，你可以把它理解成 AI 世界的“USB 接口”——只要设备符合这个接口规范，AI 就能直接插上去用。而 SSH 是每个运维和开发人员每天都在用的远程登录协议，管服务器、传文件、跑脚本全靠它。把这两者结合，意味着 AI 助手可以安全、规范地通过 MCP 协议去操作远程服务器，不用你手动敲一堆命令，也不用把密码明文写在配置文件里。
这个工具解决的核心痛点非常明确：以前想让 AI 帮你操作远程服务器，要么得自己写一堆胶水代码，要么得把 SSH 凭据暴露在对话上下文里，既不安全也不优雅。mcp-ssh-manager 做的事情就是把这些脏活累活封装成一个标准的 MCP Server，AI 通过它来执行 SSH 命令、管理连接、处理认证，整个过程对上层 AI 应用透明。适合谁来用？DevOps 工程师、后端开发、自动化运维人员，以及任何想让 AI 助手接管一部分服务器操作的人。哪怕你之前没接触过 MCP 协议，只要你会用 SSH，这篇文章就能帮你把这个工具跑起来。
我花了大概两周时间在测试环境里反复折腾这个工具，踩了不少坑，也总结了一些官方文档里没写的经验。下面我把整个思路、操作细节和避坑指南完整地分享出来。
2. 整体设计思路与方案选型拆解
2.1 MCP 协议到底解决了什么问题
在 mcp-ssh-manager 出现之前，让 AI 操作远程服务器大概有这么几种做法。第一种是直接在对话里让 AI 生成 SSH 命令，然后你自己复制到终端执行，这种方式最原始，效率极低，而且 AI 看不到执行结果，没法做后续判断。第二种是写一个自定义的 Function Calling 接口，把 SSH 操作包装成函数让 AI 调用，这种方式可行但每个 AI 平台都要重新适配一遍，迁移成本很高。第三种就是用 MCP 协议，一次开发，所有支持 MCP 的 AI 客户端都能直接用。
MCP 的核心价值在于标准化。它定义了三种能力：Tools（工具调用）、Resources（资源读取）、Prompts（提示模板）。mcp-ssh-manager 主要用的是 Tools 能力，把 SSH 连接、命令执行、文件传输这些操作注册成一个个 Tool，AI 根据用户意图自动选择调用哪个 Tool、传什么参数。这就好比以前每个电器都有自己的充电口，现在统一成 Type-C 了，随便拿哪个充电器都能用。
2.2 为什么选择 SSH 作为远程管理协议
有人可能会问，现在都有 Ansible、SaltStack 这些配置管理工具了，为什么还要用 SSH？答案很简单：SSH 是底线。任何一台 Linux 服务器，哪怕是最小化安装的，SSH 服务几乎都是默认开启的。你不需要在目标机器上预装任何 Agent，不需要开放额外的端口，不需要配置复杂的认证体系。mcp-ssh-manager 选择 SSH 作为底层协议，意味着它的适用范围几乎覆盖所有 Linux 服务器，从树莓派到大型集群都能用。
另一个关键考量是安全性。SSH 本身就提供了加密传输、密钥认证、跳板机转发等成熟的安全机制。mcp-ssh-manager 不需要重新发明一套安全体系，只需要在 SSH 之上做一层封装，把连接管理和命令执行抽象成 MCP Tool 就行了。这种设计思路很务实，不追求花哨的功能，先把最核心的场景做扎实。
2.3 连接池与凭据管理的设计取舍
我在实际使用中发现，mcp-ssh-manager 在连接管理上做了一个很重要的设计决策：它维护了一个连接池。什么意思呢？就是当你第一次通过它连接某台服务器时，它会建立 SSH 连接并保持住，后续再执行命令时直接复用这个连接，而不是每次都重新握手。这个设计对性能提升非常明显，尤其是需要连续执行多条命令的场景，省去了反复认证的开销。
凭据管理方面，它支持多种认证方式：密码认证、密钥认证、以及 SSH Agent 转发。我强烈建议用密钥认证，原因后面会详细说。连接池的配置参数包括最大连接数、空闲超时时间、连接重试次数等，这些参数需要根据你的实际服务器数量和操作频率来调整。如果服务器很多但操作不频繁，可以把空闲超时设短一点，避免占用过多资源；如果是对同一台服务器高频操作，就把连接保持时间长一些。
2.4 与同类工具的差异化定位
市面上其实已经有一些 SSH 相关的 MCP 工具了，比如有些是专门做批量命令执行的，有些是专注于文件传输的。mcp-ssh-manager 的定位更偏向“管理”，它不只是执行命令，还包括连接的生命周期管理、多服务器切换、会话保持等功能。你可以把它理解成一个 SSH 连接管理器，只不过这个管理器是给 AI 用的，不是给人用的。
这个定位决定了它的使用场景：适合需要频繁在多台服务器之间切换操作的场景，比如排查线上问题、部署多节点服务、批量收集日志等。如果你只是偶尔连一台服务器执行一条命令，那用系统自带的 ssh 命令就够了，没必要上这个工具。但如果你每天要在十几台服务器之间来回操作，而且希望 AI 能帮你记住每台服务器的上下文，那 mcp-ssh-manager 的价值就体现出来了。
3. 核心细节解析与实操要点
3.1 安装部署的三种方式及选择建议
mcp-ssh-manager 提供了三种安装方式，我逐一试过，各有优劣。第一种是直接下载预编译的二进制文件，适合快速体验，下载下来加个执行权限就能跑。第二种是通过包管理器安装，比如 npm 或 pip，适合已经熟悉对应生态的开发者。第三种是从源码编译，适合需要自定义功能或者贡献代码的场景。
我个人的建议是：如果你只是想快速试用，直接用二进制文件，五分钟就能跑起来。如果你打算长期在项目里用，建议用包管理器安装，方便版本管理和依赖更新。源码编译我试过一次，主要是想看看它的连接池实现细节，编译过程不算复杂，但需要提前装好 Go 环境（这个工具是用 Go 写的，性能上有优势）。
安装完成后，你需要创建一个配置文件。配置文件的位置默认在当前用户目录下的.mcp-ssh-manager/config.yaml，你也可以通过命令行参数指定其他路径。配置文件的核心结构包括服务器列表、认证信息、连接池参数三部分。下面是一个最小可用的配置示例：
servers: - name: "web-server-01" host: "192.168.1.100" port: 22 user: "deploy" auth: type: "key" key_path: "~/.ssh/id_ed25519" tags: ["web", "production"] - name: "db-server-01" host: "192.168.1.200" port: 22 user: "admin" auth: type: "password" password_env: "DB_SERVER_PASSWORD" tags: ["database", "production"] pool: max_connections: 10 idle_timeout: 300 connect_timeout: 15 retry_count: 3注意：密码认证方式中，我强烈建议用
password_env从环境变量读取密码，而不是直接写在配置文件里。配置文件如果被意外提交到代码仓库，明文密码就泄露了。
3.2 SSH 密钥认证的完整配置流程
密钥认证是 mcp-ssh-manager 最推荐的认证方式，也是我在生产环境中唯一使用的方式。配置流程分三步：生成密钥对、分发公钥到目标服务器、在 mcp-ssh-manager 中配置私钥路径。
生成密钥对的时候，我建议用 Ed25519 算法而不是传统的 RSA。Ed25519 的密钥更短、签名更快、安全性也更高。命令很简单：
ssh-keygen -t ed25519 -C "mcp-ssh-manager" -f ~/.ssh/mcp_ed25519执行后会生成两个文件：mcp_ed25519是私钥，mcp_ed25519.pub是公钥。私钥文件权限必须是 600，否则 SSH 会拒绝使用。公钥需要追加到目标服务器的~/.ssh/authorized_keys文件中。如果你有多台服务器，可以用ssh-copy-id命令批量分发：
ssh-copy-id -i ~/.ssh/mcp_ed25519.pub deploy@192.168.1.100 ssh-copy-id -i ~/.ssh/mcp_ed25519.pub deploy@192.168.1.200分发完成后，先手动测试一下密钥登录是否正常：
ssh -i ~/.ssh/mcp_ed25519 deploy@192.168.1.100 "hostname && uptime"如果这条命令能正常返回结果，说明密钥配置没问题，接下来在 mcp-ssh-manager 的配置文件里把key_path指向这个私钥文件就行了。
实操心得：我遇到过一种情况，密钥配置看起来都对，但 mcp-ssh-manager 就是连不上。排查了半天发现是目标服务器的
authorized_keys文件权限不对，SSH 要求这个文件必须是 600，.ssh目录必须是 700。权限不对的话 SSH 会静默忽略这个文件，不会报错，特别容易踩坑。
3.3 连接池参数的计算与调优
连接池的参数配置直接影响到工具的性能和稳定性，这部分我想展开讲讲怎么算。假设你有 20 台服务器，平均每台服务器每天需要执行 50 次命令操作，操作集中在工作时间的 8 小时内。那么平均每秒的操作次数大约是 20 × 50 / (8 × 3600) ≈ 0.035 次/秒。这个频率非常低，理论上 1 个连接就够了。
但实际情况是，操作往往不是均匀分布的，而是集中在某些时间段爆发。比如你同时部署 10 台服务器，每台要执行 5 条命令，那就是瞬间 50 次操作。这时候如果连接池太小，就会出现排队等待。我的经验值是：max_connections设置为服务器数量的 1.5 倍左右，idle_timeout设置为 300 秒（5 分钟），connect_timeout设置为 15 秒，retry_count设置为 3 次。
connect_timeout这个参数需要特别注意。如果目标服务器网络延迟高，或者 SSH 服务响应慢，15 秒可能不够。我有一台海外服务器，SSH 握手需要 8 秒左右，15 秒的超时勉强够用。如果你遇到连接超时的问题，先把这个值调大到 30 秒试试，确认是超时问题还是其他问题。
3.4 多服务器切换与标签管理
mcp-ssh-manager 支持给服务器打标签，这个功能在实际使用中非常实用。比如你可以给所有 Web 服务器打上web标签，给数据库服务器打上database标签。当 AI 需要执行“在所有 Web 服务器上检查 Nginx 状态”这样的操作时，它可以直接根据标签筛选目标服务器，不需要你手动指定每一台的名称。
标签的设计建议遵循几个原则：按角色分（web、db、cache）、按环境分（production、staging、development）、按地域分（beijing、shanghai）。不要打太多标签，否则管理起来反而混乱。我一般每台服务器打 2 到 3 个标签，足够覆盖大部分筛选场景。
服务器名称的命名也要有规律，我习惯用“角色-序号”的格式，比如web-01、web-02、db-01。这样在 AI 对话中引用的时候很直观，不容易搞混。如果你有多个环境，可以在名称里加上环境前缀，比如prod-web-01、staging-web-01。
4. 实操过程与核心环节实现
4.1 从零开始搭建一个可用的 MCP SSH 管理环境
我以一台干净的 Ubuntu 22.04 机器为例，完整走一遍搭建流程。这台机器将作为运行 mcp-ssh-manager 的“控制端”，它需要能够通过网络访问目标服务器。
第一步，安装 mcp-ssh-manager。我用的是二进制安装方式：
# 下载最新版本 wget https://github.com/example/mcp-ssh-manager/releases/latest/download/mcp-ssh-manager-linux-amd64 # 添加执行权限 chmod +x mcp-ssh-manager-linux-amd64 # 移动到系统路径 sudo mv mcp-ssh-manager-linux-amd64 /usr/local/bin/mcp-ssh-manager # 验证安装 mcp-ssh-manager --version第二步，创建配置目录和配置文件：
mkdir -p ~/.mcp-ssh-manager touch ~/.mcp-ssh-manager/config.yaml第三步，编辑配置文件，填入你的服务器信息。这里我建议先用一台测试服务器验证流程，确认没问题后再批量添加。配置文件写好后，可以用内置的检查命令验证配置格式是否正确：
mcp-ssh-manager config validate如果配置有问题，这个命令会指出具体的错误位置和原因。我遇到过最常见的问题是 YAML 缩进错误，YAML 对缩进非常敏感，建议用支持 YAML 语法高亮的编辑器来写。
第四步，测试连接。mcp-ssh-manager 提供了一个test子命令，可以测试与指定服务器的连接：
mcp-ssh-manager test --server web-server-01这个命令会尝试建立 SSH 连接，执行一条简单的命令（通常是echo或hostname），然后返回结果。如果连接成功，你会看到类似这样的输出：
Connecting to web-server-01 (192.168.1.100:22)... Authentication: key (~/.ssh/mcp_ed25519) Connection established in 1.2s Remote command output: web-server-01 Connection test passed.如果失败，输出会包含具体的错误信息，比如Authentication failed、Connection refused、Timeout等，根据错误信息可以快速定位问题。
4.2 在 AI 客户端中接入 mcp-ssh-manager
mcp-ssh-manager 本身是一个 MCP Server，它需要被一个 MCP Client 调用才能发挥作用。目前支持 MCP 协议的客户端有不少，我以最常见的配置方式为例说明接入流程。
在客户端的 MCP 配置文件中，添加一个 server 条目，指向 mcp-ssh-manager 的可执行文件：
{ "mcpServers": { "ssh-manager": { "command": "/usr/local/bin/mcp-ssh-manager", "args": ["serve", "--config", "/home/user/.mcp-ssh-manager/config.yaml"], "env": { "DB_SERVER_PASSWORD": "your-password-here" } } } }配置完成后重启客户端，如果一切正常，客户端会显示已连接到ssh-manager这个 MCP Server，并且能看到它注册的所有 Tool。我数了一下，当前版本大概注册了 8 个 Tool，包括：ssh_connect、ssh_exec、ssh_upload、ssh_download、ssh_list_servers、ssh_disconnect、ssh_session_info、ssh_batch_exec。
这些 Tool 的命名很直观，AI 根据用户意图自动选择调用。比如你说“帮我在 web-01 上看看磁盘使用情况”，AI 会调用ssh_exec，参数是server: web-01、command: df -h。你不需要手动指定调用哪个 Tool，AI 会根据 Tool 的描述自动匹配。
4.3 批量命令执行的实现与参数调优
批量执行是 mcp-ssh-manager 的一个亮点功能。ssh_batch_exec这个 Tool 允许你同时在多台服务器上执行同一条命令，并汇总结果。它的参数包括：servers（服务器名称列表或标签）、command（要执行的命令）、parallel（是否并行执行）、timeout（单台服务器的超时时间）。
我实测下来，并行执行 10 台服务器的一条简单命令（比如uptime），总耗时大约 2 到 3 秒。如果改成串行执行，耗时会线性增加到 15 到 20 秒。所以只要目标服务器之间没有依赖关系，一律用并行模式。
但并行模式有一个坑：如果命令的输出量很大，比如cat一个几百 MB 的日志文件，并行执行会导致控制端内存暴涨。我建议在执行可能产生大量输出的命令时，加上输出重定向，比如cat /var/log/syslog | tail -100，只取最后 100 行。或者用timeout参数限制单台服务器的执行时间，避免某台服务器卡住导致整个批量操作挂起。
还有一个细节：批量执行时，如果某台服务器连接失败，默认行为是跳过并继续执行其他服务器，最后在汇总结果里标记哪些失败了。这个行为可以通过fail_fast参数改成“一旦有失败就中止”。我一般不开fail_fast，因为批量操作中个别服务器不可用是常态，没必要因为一台机器的问题中断整个操作。
4.4 文件传输的实操记录与注意事项
ssh_upload和ssh_download这两个 Tool 分别用于上传和下载文件。上传的时候，源路径是控制端的本地路径，目标路径是远程服务器的路径。下载则相反。
我实测上传一个 50MB 的文件到内网服务器，耗时大约 3 秒，速度约 16MB/s。这个速度受网络带宽和 SSH 加密开销的影响。如果你需要传输大量小文件，建议先打包成 tar.gz 再传输，减少 SSH 连接上的往返次数。
注意：文件传输的路径参数不支持通配符。如果你想上传多个文件，需要多次调用，或者先在本地打包。另外，目标路径的目录必须已经存在，mcp-ssh-manager 不会自动创建目录。如果目录不存在，会报
No such file or directory错误。
下载文件的时候有一个权限问题需要注意：如果远程文件是 root 用户创建的，而你的 SSH 登录用户不是 root，下载会失败。解决办法是用sudo配合cat命令把文件内容输出到标准输出，然后重定向到本地文件。不过这种方式对二进制文件不友好，只适合文本文件。
5. 常见问题与排查技巧实录
5.1 SSH 认证失败的五种典型场景
认证失败是最高频的问题，我整理了五种典型场景和对应的排查方法。
第一种，密钥权限问题。SSH 对私钥文件的权限要求非常严格，必须是 600。如果你从其他地方拷贝了私钥文件，权限可能变成了 644，SSH 会拒绝使用。解决方法很简单：chmod 600 ~/.ssh/mcp_ed25519。
第二种，公钥没有正确分发。有时候你执行了ssh-copy-id，但目标服务器的authorized_keys文件权限不对，SSH 会静默忽略。检查方法是登录目标服务器，执行ls -la ~/.ssh/，确认authorized_keys是 600，.ssh目录是 700。
第三种，SSH Agent 干扰。如果你的控制端运行了 SSH Agent，并且加载了其他密钥，mcp-ssh-manager 可能会尝试用错误的密钥认证。解决方法是在配置文件中明确指定key_path，或者在启动 mcp-ssh-manager 前清空 SSH Agent：ssh-add -D。
第四种，目标服务器的 SSH 配置限制了认证方式。有些服务器在/etc/ssh/sshd_config中设置了PubkeyAuthentication no或者PasswordAuthentication no，只允许特定认证方式。你需要确认目标服务器允许你使用的认证方式。
第五种，账户被锁定或过期。有些系统设置了账户密码过期策略，或者多次认证失败后账户被临时锁定。这种情况需要联系服务器管理员解锁。
5.2 连接超时与网络问题的排查思路
连接超时的排查可以按照从近到远的顺序进行。先确认控制端到目标服务器的网络是否通：ping 192.168.1.100。如果 ping 不通，说明是网络层的问题，检查路由、防火墙规则。
如果 ping 通但 SSH 连不上，用telnet 192.168.1.100 22或者nc -zv 192.168.1.100 22测试 22 端口是否开放。如果端口不通，可能是目标服务器的防火墙拦截了，或者 SSH 服务没有运行。
如果端口通但 mcp-ssh-manager 连接超时，可能是 SSH 握手阶段的问题。可以在 mcp-ssh-manager 的配置中开启调试日志，查看详细的握手过程：
logging: level: "debug" file: "/var/log/mcp-ssh-manager.log"调试日志会记录 SSH 握手的每一个阶段，包括密钥交换、认证协商等，根据日志可以精确定位卡在哪一步。
5.3 命令执行结果异常的排查方法
有时候命令执行成功了，但返回的结果不符合预期。这种情况通常有几个原因。一是环境变量不同。通过 SSH 非交互式执行命令时，加载的环境变量和交互式登录不同。比如PATH可能不包含/usr/local/bin，导致某些命令找不到。解决方法是在命令中使用绝对路径，或者在命令前加上source /etc/profile &&。
二是工作目录不同。SSH 非交互式执行命令时，默认工作目录是用户的家目录，而不是你上次操作所在的目录。如果命令依赖当前目录，需要显式cd到目标目录。
三是 Shell 类型不同。有些服务器的默认 Shell 是/bin/sh而不是/bin/bash，一些 bash 特有的语法（比如[[ ]]）会报错。解决方法是在命令前指定 Shell：bash -c "your command"。
四是权限问题。有些命令需要 root 权限才能执行，但你的 SSH 登录用户不是 root。如果配置了sudo免密，可以在命令前加sudo。如果没有免密，sudo会等待输入密码，导致命令挂起直到超时。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 认证失败 | 私钥权限不对 | ls -la ~/.ssh/ | chmod 600私钥文件 |
| 认证失败 | 公钥未分发 | 检查目标服务器authorized_keys | 重新执行ssh-copy-id |
| 连接超时 | 网络不通 | ping目标服务器 | 检查网络和路由 |
| 连接超时 | 端口未开放 | nc -zv host 22 | 检查防火墙和 SSH 服务 |
| 命令找不到 | PATH 不含目标路径 | echo $PATH | 使用绝对路径或 source profile |
| 命令挂起 | sudo 等待密码 | 查看进程状态 | 配置 sudo 免密或改用 root |
| 文件传输失败 | 目标目录不存在 | 检查远程目录 | 先创建目录再传输 |
| 批量执行部分失败 | 个别服务器不可达 | 查看汇总结果 | 检查失败服务器的网络和 SSH 服务 |
| 输出乱码 | 字符编码不一致 | locale检查 | 统一使用 UTF-8 编码 |
| 连接池耗尽 | 并发操作过多 | 查看连接池状态 | 调大max_connections |
5.5 我踩过的三个印象最深的坑
第一个坑是配置文件里的波浪号。在 YAML 配置文件中写key_path: ~/.ssh/mcp_ed25519，mcp-ssh-manager 不会自动展开波浪号，而是把它当成字面路径。结果就是找不到密钥文件，认证失败。解决方法是用绝对路径，比如/home/deploy/.ssh/mcp_ed25519。
第二个坑是连接池的空闲超时设置太短。我一开始设了 60 秒，结果在连续操作的时候，两次操作间隔超过 60 秒，连接就被回收了，下次操作又要重新握手。后来改成 300 秒，体验好很多。这个值需要根据你的操作频率来调整，没有标准答案。
第三个坑是批量执行时的输出顺序。并行执行的时候，各台服务器的输出返回顺序是不确定的，汇总结果里服务器和输出的对应关系可能看起来是乱的。如果你需要严格的顺序，要么改成串行执行，要么在命令输出里加上服务器标识，比如echo "=== $(hostname) ===" && your_command。
6. 生产环境使用的安全建议与扩展思路
6.1 最小权限原则的具体落地
在生产环境使用 mcp-ssh-manager，安全是第一位的。我的做法是给 mcp-ssh-manager 单独创建一个 SSH 账户，这个账户只拥有完成必要操作所需的最小权限。比如如果只是查看日志和状态，就不需要 sudo 权限；如果需要重启服务，就只给特定的 systemctl 命令配置 sudo 免密，而不是给全部命令。
具体操作是在目标服务器的/etc/sudoers.d/目录下创建一个文件，内容类似：
mcp-user ALL=(ALL) NOPASSWD: /bin/systemctl restart nginx, /bin/systemctl status nginx这样 mcp-user 只能免密执行重启和查看 Nginx 状态的命令，其他需要 sudo 的操作仍然需要密码。即使 mcp-ssh-manager 的凭据泄露，攻击者能做的事情也非常有限。
6.2 审计日志的配置与查看
mcp-ssh-manager 支持记录所有通过它执行的命令，这个功能在生产环境中非常重要。审计日志默认是关闭的，需要在配置文件中开启：
audit: enabled: true log_file: "/var/log/mcp-ssh-manager/audit.log" log_format: "json" include_output: falseinclude_output我建议设为 false，只记录命令本身，不记录命令的输出。因为输出中可能包含敏感信息，比如密码、密钥等。日志格式用 JSON，方便后续用日志分析工具做结构化查询。
审计日志会记录每次操作的时间、服务器、用户、命令、执行结果状态。定期检查这个日志，可以发现异常操作模式，比如非工作时间的操作、高频的失败尝试等。
6.3 后续可以扩展的方向
mcp-ssh-manager 目前的功能已经覆盖了大部分日常运维场景，但还有一些可以扩展的方向。比如可以增加对 SFTP 协议的支持，实现更高效的文件传输；可以增加命令模板功能，把常用的命令组合预定义成模板，AI 直接调用模板名称就行；还可以增加与配置管理工具的集成，把 Ansible Playbook 的执行也封装成 MCP Tool。
另外一个有意思的扩展方向是增加“会话录制”功能，把 AI 通过 mcp-ssh-manager 执行的所有操作录制成可回放的会话，方便事后审计和问题复现。这个功能在排查复杂问题时特别有用，你可以回放整个操作序列，看看是哪一步导致了问题。
我在实际使用中的体会是，mcp-ssh-manager 最大的价值不是替代人工操作，而是把重复性的、模式化的服务器操作自动化了。以前我需要手动登录五台服务器分别执行相同的检查命令，现在只需要跟 AI 说一句话，它就能通过 mcp-ssh-manager 并行执行并汇总结果。省下来的时间可以花在更有价值的事情上。最后再分享一个小技巧：把常用的服务器分组和命令组合写成配置文件中的预设，AI 调用的时候直接引用预设名称，比每次输入完整参数要高效得多。
