为Gemini CLI开发ADK Agent扩展：无缝集成与高效交互指南

1. 项目概述：为Gemini CLI注入ADK Agent交互能力

如果你正在使用Google的Gemini CLI，并且频繁地与基于Agent Development Kit构建的智能体打交道，那么手动切换终端、拼接API请求、解析JSON响应的过程一定让你感到繁琐。这正是我开发adk-agent-extension这个扩展的初衷。简单来说，它是一个专为Gemini CLI设计的插件，让你能直接在熟悉的命令行环境中，像调用本地命令一样，无缝地发现、创建、部署并与ADK智能体进行对话。

这个扩展的核心价值在于“桥接”与“提效”。它充当了Gemini CLI与远端ADK服务器之间的桥梁，将后者提供的复杂RESTful API封装成一系列直观的命令行工具和MCP（Model Context Protocol）工具。这意味着，无论是想快速列出所有可用的智能体，还是需要与某个智能体进行多轮对话以测试其功能，你都不需要离开Gemini CLI的交互环境。对于AI应用开发者、MLOps工程师以及任何需要频繁测试和调试ADK智能体的从业者来说，这能极大提升工作效率，让智能体交互变得像操作本地文件一样自然。

在接下来的内容里，我会带你从零开始，不仅学会如何使用这个扩展的所有功能，还会深入拆解其设计思路、关键实现细节，并分享我在开发和实际使用中积累的一系列实操心得与避坑指南。无论你是想直接上手使用，还是希望了解如何构建类似的CLI扩展，都能找到有价值的内容。

2. 核心架构与设计思路拆解

在动手写代码之前，明确的设计思路是项目成功的关键。adk-agent-extension的目标很明确：让Gemini CLI成为ADK智能体的超级控制台。为了实现这个目标，我主要从两个维度进行架构设计：用户交互层和底层协议层。

2.1 双模交互设计：命令与工具的平衡

用户与扩展的交互主要通过两种模式：自定义命令和MCP工具。这两种模式服务于不同的使用场景和用户习惯。

自定义命令的设计初衷是提供一种显式、结构化的交互方式。例如，/adk-ext:list_adks或/adk-ext:agent_chat。这类命令的特点是需要用户主动触发，并且通常会带有明确的参数或引导式交互（如提示用户输入服务器URL）。它非常适合执行那些步骤清晰、目标明确的任务，比如初始化配置、启动一个特定的测试流程。在实现上，每个自定义命令都对应一个独立的命令处理函数，负责解析参数、调用底层API、格式化并输出结果。这种模式对用户来说学习成本稍高，需要记忆命令格式，但一旦掌握，执行效率极高，且易于脚本化。

MCP工具的设计则是为了无缝、上下文感知的集成。MCP允许我们将扩展的功能以“工具”的形式暴露给Gemini背后的AI模型。当用户在Gemini CLI中直接描述一个任务时，例如“帮我查一下ADK服务器上有哪些智能体”，AI模型可以自动识别并调用list_adk_agents这个MCP工具，而无需用户输入任何具体命令。这极大地降低了使用门槛，实现了自然语言到智能体操作的直接转换。在架构上，MCP服务器作为扩展的核心组件运行，维护着一个工具注册表，当Gemini CLI请求工具调用时，它负责分派和执行。

设计心得：在实际开发中，我建议为所有核心功能同时实现命令和MCP工具两种接口。命令服务于高级用户和自动化脚本，MCP工具服务于探索性交互和自然语言场景。这确保了扩展的灵活性和普适性。

2.2 配置与状态管理策略

一个健壮的CLI工具必须妥善处理配置和状态。adk-agent-extension采用了“静态配置+动态会话”的策略。

静态配置主要由adk_agent_list.json文件管理。这个JSON文件存储在扩展的根目录，用于预定义一组已知的ADK服务器和智能体。它的结构非常简单，一个agents数组，里面每个对象包含name和url。这种设计的好处是清晰、易于手动编辑和版本控制。团队可以共享一个配置文件，快速统一开发环境。在代码中，扩展启动时会读取这个文件，将其加载到内存中，作为可用服务器的初始列表。

动态会话管理则更为关键。当用户通过create_session命令或工具与一个智能体开始对话时，扩展会在后端维护一个会话映射表（通常以session_id为键）。这个会话状态包含了与ADK服务器保持连接的必要信息，用于在后续的send_message_to_agent调用中关联正确的对话上下文。实现时需要注意会话的超时和清理机制，避免内存泄漏。我通常会在会话创建时记录时间戳，并设置一个后台任务定期检查并清理长时间无活动的会话。

配置的优先级与覆盖是另一个需要考虑的细节。扩展支持通过config_add_server命令动态添加服务器配置。这部分动态添加的配置会与静态文件中的配置合并，并且通常给予更高的优先级（或提供去重逻辑）。这样，用户可以在不修改基础配置文件的情况下，临时添加测试服务器，非常灵活。

3. 功能模块深度解析与实操要点

了解了整体架构，我们来深入看看扩展提供的各个功能模块，以及在实际使用中需要注意的关键点。

3.1 MCP服务器工具详解

MCP服务器是扩展的“智能引擎”，它提供的四个工具构成了与ADK交互的基础原子操作。

list_adks: 这个工具的作用是获取所有已配置的ADK服务器列表。它的实现逻辑是合并读取adk_agent_list.json静态配置和运行时通过命令添加的动态配置。这里有一个实操要点：为了增加鲁棒性，工具实现时应该对每个配置的url进行基本的连通性检查（例如发送一个HEAD请求或简单的GET请求到/health端点），并在返回结果中标记服务器的在线状态。这能帮助用户快速识别出无法连接的服务器，而不是在后续操作中才报错。

list_adk_agents: 给定一个ADK服务器URL，这个工具会调用该服务器的对应API（通常是GET /api/v1/agents）来列出所有可用的智能体。关键实现细节在于错误处理。ADK服务器的API版本可能变化，或者网络可能不稳定。代码中必须包含完善的try-catch块，对网络超时、HTTP错误状态码（如404、500）、以及响应体格式不符合预期的情况进行优雅处理，并返回对人友好的错误信息，而不是未处理的异常。

create_session: 这是启动一次对话的起点。它需要两个参数：agent_id和server_url。它会向指定的ADK服务器发送请求以创建一个新的会话，并返回一个session_id。重要注意事项：不同的ADK智能体可能需要不同的初始化参数。基础的create_session实现可能只支持最简单的创建。一个更健壮的实现应该允许通过MCP工具的输入参数传递额外的初始化config对象，以满足复杂智能体的需求。在扩展的后续迭代中，这是需要重点增强的部分。

send_message_to_agent: 这是最核心的工具，它向指定会话发送一条消息并获取智能体的响应。输入参数包括session_id,server_url和message。这里的核心挑战是流式响应。许多ADK智能体支持流式输出（streaming），以提供更好的交互体验。原生的工具调用可能只支持返回完整结果。为了实现流式，我们需要在MCP层面进行更高级的集成，例如支持服务器推送（Server-Sent Events）或利用Gemini CLI对工具调用的特殊处理。在初期版本中，我们可能先返回非流式的完整响应，但必须在设计上为流式预留接口。

3.2 自定义命令使用指南与场景分析

自定义命令是用户主动控制扩展的主要方式。下面我们分类解析这些命令的最佳使用场景和隐藏技巧。

配置管理命令组(config_*):

• /adk-ext:config_add_server <name> <url>: 添加新服务器。技巧：name参数最好起一个简短易记的别名，比如prod,staging,local-dev，这样在后续命令中更容易引用。
• /adk-ext:config_list_servers: 列出所有服务器。输出应该清晰区分静态配置和动态添加的配置。
• /adk-ext:config_remove_server <name>: 移除配置。注意：这个命令通常只移除动态添加的配置，避免误操作修改静态配置文件。移除前最好有确认提示。

智能体生命周期命令组(create_agent,deploy_agent,evaluate_agent): 这些命令通常对应ADK服务器上更复杂的API，可能需要额外的参数文件（如智能体定义YAML、评估配置JSON）。

• 实操流程：以创建智能体为例，最佳实践是先在本地编写好智能体的定义文件（agent_definition.yaml），然后使用命令/adk-ext:create_agent --server=local-dev --definition=./agent_definition.yaml。扩展内部需要读取文件内容，并将其作为请求体发送。
• 参数设计：对于复杂的命令，建议使用--flag的形式传递参数，而不是依赖顺序参数，这样更清晰，也更容易扩展。

交互与查询命令组(list_*,agent_chat,interactive_chat):

• /adk-ext:list_adks和/adk-ext:list_adk_agent是MCP工具的快捷方式，用于快速获取信息。
• /adk-ext:agent_chat与/adk-ext:interactive_chat的区别是交互模式。agent_chat可能是一次性的问答，而interactive_chat会启动一个循环，持续提示用户输入，直到用户输入退出指令（如/quit），模拟一个真正的聊天会话。实现关键：在交互式聊天中，必须妥善维护和传递session_id，确保多轮对话的上下文连贯性。

高级功能命令(scan_safety,visualize,list_agent_tools):

• scan_safety: 这很可能调用ADK的安全评估模块对智能体的输入/输出进行扫描。使用时需要明确扫描的范围和策略。
• visualize: 这是一个非常实用的功能，它可能生成智能体工作流或系统架构的图表（如DOT语言描述或直接生成PNG）。依赖提示：此功能可能需要系统安装Graphviz等图形渲染库。
• list_agent_tools: 列出某个智能体可以调用的所有工具。这对于理解智能体的能力边界至关重要。

经验分享：在实现这些命令时，良好的交互反馈非常重要。例如，当执行一个耗时较长的命令（如deploy_agent）时，应该提供进度提示或旋转指示器，让用户知道系统正在工作，而非卡死。

4. 从零开始的完整实操流程

理论说得再多，不如亲手操作一遍。下面我将以一个完整的场景为例，带你走通从环境准备、安装配置、到实际与智能体对话的全流程。假设我们有一个本地开发的ADK智能体，它部署在http://localhost:8080。

4.1 环境准备与扩展安装

首先，确保你的基础环境已经就绪：

1. Node.js环境：扩展是TypeScript项目，需要Node.js运行环境。建议安装LTS版本（如v18.x或v20.x）。你可以通过node --version命令检查。
2. Gemini CLI：这是扩展运行的主体。请确保你已按照官方指南安装并配置好Gemini CLI，并且能够正常启动一个会话。
3. Git：用于从仓库安装扩展。

安装扩展非常简单，只需在终端中执行一条命令：

gemini extensions install https://github.com/simonliu-ai-product/adk-agent-extension

这条命令会告诉Gemini CLI从指定的Git仓库地址下载、构建并安装扩展。安装成功后，你通常会在Gemini CLI中看到相关提示，或者可以通过gemini extensions list来确认扩展已存在。

首次配置：安装后，我们需要告诉扩展你的ADK服务器在哪里。有两种方法：

• 方法A：修改静态配置文件。找到扩展的安装目录（具体路径取决于Gemini CLI的配置），在其根目录下创建或修改adk_agent_list.json文件。

  { "agents": [ { "name": "my-local-agent", "url": "http://localhost:8080" } ] }

• 方法B：使用动态配置命令。直接在Gemini CLI会话中，输入：

  /adk-ext:config_add_server local http://localhost:8080

  我通常推荐使用方法B，因为它更灵活，且不需要寻找扩展的物理目录。

4.2 核心交互实战：与智能体对话

配置好服务器后，我们就可以开始探索和交互了。

步骤1：验证服务器连接在Gemini CLI中输入：

/adk-ext:list_adks

如果配置正确，你应该能看到输出中列出了名为local或my-local-agent的服务器及其URL。

步骤2：查看服务器上的智能体输入命令：

/adk-ext:list_adk_agent

这时，CLI会提示你选择或输入ADK服务器。如果你之前用config_add_server添加的别名是local，这里就可以输入local。命令会调用该服务器的API，返回一个可用的智能体列表。假设我们看到了一个名为travel-planner的智能体。

步骤3：开启一个聊天会话现在，让我们与travel-planner对话。输入：

/adk-ext:interactive_chat

根据提示，依次选择服务器（local）和智能体（travel-planner）。扩展会在后台调用create_session工具，创建一个新的会话并获取session_id。

步骤4：进行多轮对话进入交互模式后，你会看到类似You (to travel-planner):的提示符。此时，你可以像使用任何聊天机器人一样输入问题，例如：

帮我规划一个为期三天的上海行程，要包含外滩和迪士尼。

智能体会通过扩展返回它的回答。你可以继续追问，比如“第二天中午有什么本地美食推荐？”，扩展会自动使用同一个session_id来维持对话上下文。输入/quit或exit可以结束本次对话。

步骤5：使用MCP工具的自然语言交互除了命令，你还可以直接“告诉”Gemini你的需求。例如，在Gemini CLI中直接输入：

我想知道本地ADK服务器上所有智能体的名字。

Gemini背后的模型会理解你的意图，自动选择并调用list_adk_agents这个MCP工具（可能需要你确认使用哪个服务器），然后将结果以自然语言的形式呈现给你。这种方式更加直觉，适合探索性任务。

4.3 进阶操作：智能体部署与评估

对于开发者，部署和评估是更常见的操作。

部署智能体：假设你已经在本地开发完成了一个新的智能体，其定义文件为my_new_agent.yaml。

/adk-ext:deploy_agent --server=local --definition=./my_new_agent.yaml

这个命令会读取YAML文件，将其发送到本地ADK服务器的部署接口。关键点：部署接口可能需要认证（API Key）。扩展需要支持认证信息的配置，例如通过环境变量或独立的配置文件来管理不同服务器的API密钥。在实现时，需要在HTTP请求头中正确添加Authorization字段。

评估智能体：评估一个智能体通常需要一组测试用例（输入-期望输出对）。假设你有一个测试集文件eval_cases.json。

/adk-ext:evaluate_agent --server=local --agent-id=travel-planner --eval-set=./eval_cases.json --output=./eval_report.md

这个命令会批量运行测试用例，收集智能体的响应，并与期望结果进行比对，最终生成一份评估报告。实现难点在于评估指标的多样化（精确匹配、相似度、自定义校验函数）和异步处理（大量测试用例的并行执行）。在扩展中，这通常是通过调用ADK服务器提供的评估端点来实现的，扩展本身主要负责传递配置和格式化结果。

5. 开发、调试与贡献指南

如果你想深入了解扩展的内部机制，或者希望为其添加新功能，这部分内容将为你提供指引。

5.1 本地开发环境搭建

首先，你需要将代码仓库克隆到本地：

git clone https://github.com/simonliu-ai-product/adk-agent-extension.git cd adk-agent-extension

然后安装项目依赖。由于是TypeScript项目，依赖安装会同时获取运行库和开发工具（如类型定义、测试框架、构建工具）：

npm install

接下来是构建。项目package.json中的scripts里应该定义了构建命令，通常是：

npm run build

这个命令会调用TypeScript编译器（tsc）将src/目录下的.ts文件编译成.js文件，输出到dist/或lib/目录。请确保构建过程没有报错。

5.2 链接本地扩展进行测试

构建成功后，为了让Gemini CLI使用你本地修改后的版本，你需要“链接”这个本地目录，而不是安装远程版本。在项目根目录下执行：

gemini extensions link .

或者使用安装命令指向当前目录：

gemini extensions install .

这两个命令的效果类似，都是告诉Gemini CLI：“请使用这个本地文件夹作为扩展的源”。

重要步骤：执行链接后，必须重启你的Gemini CLI会话。因为扩展是在CLI启动时加载的，热重载机制可能不完善。关闭当前的CLI窗口，重新打开一个新的，你的本地修改才会生效。

5.3 核心代码结构与扩展点分析

让我们浏览一下项目的主要源代码结构（以典型TypeScript项目为例）：

src/ ├── index.ts # 扩展入口点，注册命令和MCP服务器 ├── commands/ # 自定义命令的实现 │ ├── config.ts # config_* 系列命令 │ ├── list.ts # list_* 系列命令 │ └── chat.ts # agent_chat, interactive_chat 命令 ├── mcp-server/ # MCP服务器实现 │ ├── server.ts # MCP服务器主类，工具注册 │ └── tools/ # 各个MCP工具的实现 │ ├── listAdks.ts │ ├── listAgents.ts │ ├── createSession.ts │ └── sendMessage.ts ├── services/ # 业务逻辑层，封装ADK API调用 │ └── adk-client.ts # 封装HTTP客户端，处理请求/响应 ├── types/ # TypeScript类型定义 │ └── index.ts └── utils/ # 工具函数 └── config-loader.ts # 加载和管理配置

如果你想添加一个新命令，例如一个用于导出会话历史的功能：

1. 在src/commands/下创建新文件，如exportHistory.ts。
2. 实现命令处理函数，并按照框架要求导出。
3. 在src/index.ts中导入这个新命令，并将其注册到Gemini CLI的命令系统中。

如果你想添加一个新的MCP工具，例如一个get_agent_status工具：

1. 在src/mcp-server/tools/下创建新文件，如getAgentStatus.ts。
2. 实现工具的定义（名称、描述、输入参数schema）和执行函数。
3. 在src/mcp-server/server.ts中导入并注册这个新工具到工具列表里。

调试技巧：由于扩展运行在Gemini CLI进程中，直接调试比较困难。我常用的方法是：

1. 使用console.log或console.error：在代码关键位置添加日志，输出到标准错误流。在Gemini CLI中运行命令时，这些日志会输出到CLI的后台或启动它的终端中（取决于运行方式）。
2. 编写单元测试：对于services/和utils/下的纯逻辑函数，使用Jest或Mocha等框架编写单元测试，这是保证代码质量最有效的方法。
3. 模拟ADK服务器：为了测试扩展而不依赖真实的ADK服务器，可以使用像nock这样的HTTP模拟库，或者运行一个简单的模拟服务器（如用Express.js写一个），来模拟ADK API的响应。

5.4 贡献流程与代码规范

如果你发现了Bug，或者有很棒的新功能想法，非常欢迎你为项目贡献代码。标准的流程如下：

1. Fork仓库：在GitHub上Fork原项目到你的个人账户下。
2. 创建特性分支：在你的Fork仓库中，基于main分支创建一个新的分支，例如feat/add-export-command。
3. 进行开发：在新分支上实现你的修改。请遵循项目已有的代码风格（检查是否有.eslintrc或.prettierrc配置文件）。
4. 编写测试：如果可能，请为你新增的功能添加相应的测试用例。
5. 提交更改：使用清晰的提交信息（如“feat: add session history export command”）提交你的代码。
6. 发起Pull Request：将你的特性分支推送到你的Fork仓库，然后在原项目的GitHub页面上发起Pull Request（PR）。
7. 讨论与合并：项目维护者（比如我）会Review你的代码，可能会提出一些修改意见。经过讨论和必要的修改后，代码会被合并到主分支。

在提交PR前，请确保：

• 代码可以通过npm run build。
• 现有的测试用例仍然通过（运行npm test，如果有的话）。
• 新代码有适当的注释，特别是复杂的逻辑部分。

6. 常见问题、故障排查与性能优化

即使设计得再完善，在实际使用中总会遇到各种问题。这里我整理了一份常见问题清单和排查思路，希望能帮你快速定位问题。

6.1 安装与配置问题

问题1：gemini extensions install命令执行失败，提示网络错误或仓库不存在。

• 排查：首先确认你的网络可以正常访问GitHub。其次，检查仓库URL是否正确。最直接的方式是在浏览器中打开https://github.com/simonliu-ai-product/adk-agent-extension，确认仓库是公开且存在的。
• 解决：如果网络有问题，可以尝试配置Git代理。如果URL正确但失败，可能是Gemini CLI的扩展安装机制临时故障，稍后重试。

问题2：扩展安装成功，但输入/adk-ext:开头的命令没有任何反应，或提示“命令未找到”。

• 排查：这通常是因为扩展没有正确加载。重启Gemini CLI是最简单有效的第一步。如果重启后问题依旧，使用gemini extensions list查看扩展是否在列表中且状态正常。
• 解决：尝试重新安装扩展。如果是在本地开发并使用了gemini extensions link .，请确保链接后执行了npm run build并且构建成功，然后再重启CLI。

问题3：配置了服务器，但list_adks或list_adk_agent返回空列表或连接错误。

• 排查：
  1. 检查服务器地址：确认adk_agent_list.json文件中的url或通过命令添加的URL完全正确，包括协议（http://或https://）、主机名、端口和路径。
  2. 检查服务器状态：在浏览器或使用curl命令直接访问ADK服务器的健康检查端点（如http://localhost:8080/health），看服务器是否正在运行并响应。
  3. 检查网络和防火墙：确保运行Gemini CLI的机器可以访问ADK服务器所在的网络（例如，如果ADK服务器运行在Docker容器或另一台机器上）。
  4. 检查API版本：有些ADK服务器的API路径可能不是默认的。查看扩展中调用API的具体URL构建逻辑，确认其与你的ADK服务器版本匹配。
• 解决：根据排查结果修正配置、启动服务器或调整网络设置。

6.2 运行时交互问题

问题4：与智能体聊天时，响应非常慢，或者超时。

• 排查：
  1. 智能体本身处理慢：ADK智能体在处理复杂请求时可能需要较长时间。首先直接调用ADK服务器的API，确认是否是智能体本身的性能问题。
  2. 网络延迟：如果服务器部署在远程或云端，网络延迟可能导致超时。
  3. 扩展超时设置：检查扩展中HTTP客户端的默认超时时间设置。对于生成式AI任务，可能需要将超时时间设置得更长（例如60秒或更长）。
• 解决：如果是智能体性能问题，需要优化智能体逻辑。如果是网络问题，考虑将服务器部署在离客户端更近的位置。可以在扩展的HTTP客户端配置中增加超时时间。

问题5：交互式聊天 (interactive_chat) 过程中，会话上下文丢失，智能体不记得之前的对话。

• 排查：这几乎肯定是session_id没有在后续请求中正确传递导致的。检查interactive_chat命令的实现逻辑： 1. 在创建会话后，是否将session_id保存到了某个持续的状态中（如一个变量或缓存）？ 2. 在循环读取用户输入并发送消息时，是否每次都使用了同一个session_id？ 3. ADK服务器端的会话是否有过期时间？是否因为长时间无活动导致服务器端清理了会话？
• 解决：确保代码逻辑正确维护会话状态。对于服务器端会话过期，可以在扩展中实现会话保活机制（定期发送空消息），或者提示用户会话已过期并自动创建新会话。

问题6：使用MCP工具时，Gemini AI没有自动调用正确的工具，或者调用了但参数不对。

• 排查：
  1. 工具描述不清：MCP工具的定义中包含名称和描述。AI模型依赖这些描述来理解工具用途。检查你的工具描述是否足够清晰、准确？例如，list_adk_agents的描述应该明确说明它是“列出指定ADK服务器上的所有可用智能体”。
  2. 输入参数Schema不完整：工具的输入参数必须用JSON Schema明确定义。如果Schema定义有误（例如类型错误、缺少必要字段），AI可能无法正确生成调用参数。
  3. Gemini模型能力：不同的Gemini模型对工具调用的支持程度可能不同。尝试在Gemini CLI中切换不同的模型试试。
• 解决：优化工具的名称和描述，使其更符合自然语言。仔细检查并完善输入参数的JSON Schema定义。确保你使用的是支持工具调用的最新Gemini模型。

6.3 性能优化与最佳实践

随着管理的智能体增多，扩展本身的性能也需要关注。

配置缓存：频繁读取adk_agent_list.json文件是不必要的。可以在扩展启动时一次性将配置读入内存缓存。如果支持动态配置修改，则需要实现一个简单的缓存失效和重载机制（例如监听文件变化或提供重载命令）。

HTTP连接池：扩展的核心操作是发起HTTP请求。为每个请求都创建新的TCP连接开销很大。应该使用一个全局的、可复用的HTTP客户端实例（例如Axios实例），并启用HTTP Keep-Alive。这能显著提升与同一ADK服务器多次交互的速度。

异步操作与错误重试：所有网络请求都必须是异步的，避免阻塞CLI主线程。对于可能因网络抖动导致的失败请求，实现简单的指数退避重试机制可以提高鲁棒性。例如，第一次失败后等待1秒重试，第二次失败后等待2秒重试，最多重试3次。

日志与监控：在生产环境中使用，需要添加详细的日志记录，记录关键操作（如工具调用、命令执行、错误信息）和性能指标（如请求耗时）。这有助于后期排查问题和分析使用情况。日志可以输出到文件，也可以集成到更专业的日志系统中。

安全性考虑：目前配置中的服务器URL是明文存储的。如果涉及生产环境的敏感服务器，需要考虑如何安全地管理凭证（如API Keys）。一种做法是支持从环境变量（如ADK_API_KEY）或安全的密钥管理服务中读取凭证，而不是写在配置文件中。在发送请求时，再将凭证添加到请求头中。

开发这个扩展的过程，也是我不断深化对Gemini CLI生态和ADK理解的过程。最大的体会是，一个好的工具不仅要功能强大，更要贴合用户的实际工作流。将复杂的API封装成简单的命令和自然的对话交互，这中间的“翻译”工作，正是工具价值的体现。未来，我计划围绕工具动态创建、安全扫描可视化报告等方向继续深化这个扩展，也期待社区能提出更多宝贵的想法。如果你在使用的过程中有任何问题或建议，欢迎直接在GitHub仓库中提交Issue或参与讨论。