3 步给 Kimi CLI 加上自定义命令从零到调用的完整工具开发指南【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli如果你日常用 Kimi CLI 写代码、跑脚本多半遇到过这样的事它不会执行你项目里才有的那条命令。Kimi CLI 是命令行里的智能代理而自定义命令正是它的扩展口——把一段 Python 脚本包装成工具AI 就能在对话中直接调用它。本文以仓库里现成的 examples/custom-tools/ 为参照带你走完从写工具到注册、验证的完整闭环。先看场景AI 缺的不是一句提示词而是一个能调用的动作假设你维护一个内部项目每次部署前都要先跑一遍本地检查脚本。你可以把用法写在 AGENTS.md 里让 AI 照着做但它终究是人肉执行——容易漏参数也拿不到结构化结果。把脚本包装成 Kimi CLI 自定义工具后情况变成AI 把它当成一个插座需要时插上调用传入参数拿到返回。就像厨房电器不需要懂电路原理插上插座就能工作自定义命令也一样接口清晰AI 就能稳定使用。搭骨架一个自定义工具项目长什么样仓库提供的示例目录就是一个完整的最小工程照着它的目录结构起步最省事my_tools/——工具实现所在的 Python 包myagent.yaml——代理配置声明用哪些工具main.py——演示入口用于验证工具是否被 AI 识别pyproject.toml——依赖声明先把示例跑起来确认环境没问题cd examples/custom-tools uv sync --reinstall uv run main.py写一个 AI 能看懂的工具Ls 实例工具的三要素是名字、参数模型、执行逻辑。示例里的Ls工具做了一件小事——列出指定目录下的文件。核心代码不长关键在于参数用 Pydantic 模型描述AI 才能知道该传什么from kosong.tooling import CallableTool2, ToolError, ToolOk, ToolReturnValue from pydantic import BaseModel, Field class Params(BaseModel): directory: str Field(description要列出文件的目录, default.) class Ls(CallableTool2): name: str Ls description: str 列出目录下的文件 params: type[Params] Params async def __call__(self, params: Params) - ToolReturnValue: import os try: items os.listdir(params.directory) return ToolOk(output\n.join(items)) except Exception as e: return ToolError(output, messagestr(e), brief列目录失败)两个细节值得注意description是给 AI 看的说明书写清楚工具能干什么AI 选工具时才会选对它。失败时返回ToolError而不是抛异常AI 拿到明确的错误信息后能自己调整重试。实现好之后在my_tools/__init__.py里导出即可让my_tools.ls:Ls这个路径可被配置引用。注册到代理配置把工具插进插槽写好工具只是第一步还要告诉代理你有这个工具。这一步改 myagent.yaml一行配置就把自定义工具加进了工具清单version: 1 agent: extend: default tools: - kimi_cli.tools.file:ReadFile - kimi_cli.tools.shell:Shell - my_tools.ls:Ls # 你的自定义命令extend: default表示继承默认代理的工具集你只需要追加自己的部分。整个引用格式是模块路径:类名改哪个类就改哪里不需要额外写注册代码。三十秒验证让 AI 自己报出工具清单注册是否成功不用猜。示例工程的 main.py 会创建会话并直接问 AI 一句你有哪些工具回答里出现Ls就说明注册生效uv run main.py如果回答里没有Ls排查顺序建议是先确认myagent.yaml的引用路径拼写再确认my_tools包内类已正确导出。这类问题 90% 出在路径上而不是工具逻辑。从单个工具到工作流组合、权限与分发单个工具跑通后真正的价值来自组合。常见做法有两类多工具协作——在tools列表里同时挂载文件读取、Shell、你的 LsAI 会自己决定先列目录、再读文件的链路无需你写编排脚本。权限约束——Kimi Code CLI 对工具调用有审批机制敏感工具可以要求用户确认后才执行启动时用--yolo或--afk参数可放开审批适合 CI 场景日常使用保持默认更稳妥。详见 docs/zh/configuration/overrides.md。工具成熟后如何分享两个方向把my_tools打成 Python 包发布到 PyPI别人uv add之后在各自的代理配置里引用即可如果只是团队内部使用直接把这个目录放进项目仓库配合 docs/zh/customization/skills.md 里的 Skills 机制补充使用规范同事克隆仓库就自动拥有这套工具链。走到这里你已经完成了一次完整的 Kimi CLI 工具开发识别缺口、写出最小工具、一行配置注册、让 AI 自证可用。下一个值得做的工具就从你每次都要手动敲的那条命令开始。【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/15 14:08:03 · 阅读 1.2k 3 步给 Kimi CLI 加上自定义命令：从零到调用的完整工具开发指南
3 步给 Kimi CLI 加上自定义命令从零到调用的完整工具开发指南【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli如果你日常用 Kimi CLI 写代码、跑脚本多半遇到过这样的事它不会执行你项目里才有的那条命令。Kimi CLI 是命令行里的智能代理而自定义命令正是它的扩展口——把一段 Python 脚本包装成工具AI 就能在对话中直接调用它。本文以仓库里现成的 examples/custom-tools/ 为参照带你走完从写工具到注册、验证的完整闭环。先看场景AI 缺的不是一句提示词而是一个能调用的动作假设你维护一个内部项目每次部署前都要先跑一遍本地检查脚本。你可以把用法写在 AGENTS.md 里让 AI 照着做但它终究是人肉执行——容易漏参数也拿不到结构化结果。把脚本包装成 Kimi CLI 自定义工具后情况变成AI 把它当成一个插座需要时插上调用传入参数拿到返回。就像厨房电器不需要懂电路原理插上插座就能工作自定义命令也一样接口清晰AI 就能稳定使用。搭骨架一个自定义工具项目长什么样仓库提供的示例目录就是一个完整的最小工程照着它的目录结构起步最省事my_tools/——工具实现所在的 Python 包myagent.yaml——代理配置声明用哪些工具main.py——演示入口用于验证工具是否被 AI 识别pyproject.toml——依赖声明先把示例跑起来确认环境没问题cd examples/custom-tools uv sync --reinstall uv run main.py写一个 AI 能看懂的工具Ls 实例工具的三要素是名字、参数模型、执行逻辑。示例里的Ls工具做了一件小事——列出指定目录下的文件。核心代码不长关键在于参数用 Pydantic 模型描述AI 才能知道该传什么from kosong.tooling import CallableTool2, ToolError, ToolOk, ToolReturnValue from pydantic import BaseModel, Field class Params(BaseModel): directory: str Field(description要列出文件的目录, default.) class Ls(CallableTool2): name: str Ls description: str 列出目录下的文件 params: type[Params] Params async def __call__(self, params: Params) - ToolReturnValue: import os try: items os.listdir(params.directory) return ToolOk(output\n.join(items)) except Exception as e: return ToolError(output, messagestr(e), brief列目录失败)两个细节值得注意description是给 AI 看的说明书写清楚工具能干什么AI 选工具时才会选对它。失败时返回ToolError而不是抛异常AI 拿到明确的错误信息后能自己调整重试。实现好之后在my_tools/__init__.py里导出即可让my_tools.ls:Ls这个路径可被配置引用。注册到代理配置把工具插进插槽写好工具只是第一步还要告诉代理你有这个工具。这一步改 myagent.yaml一行配置就把自定义工具加进了工具清单version: 1 agent: extend: default tools: - kimi_cli.tools.file:ReadFile - kimi_cli.tools.shell:Shell - my_tools.ls:Ls # 你的自定义命令extend: default表示继承默认代理的工具集你只需要追加自己的部分。整个引用格式是模块路径:类名改哪个类就改哪里不需要额外写注册代码。三十秒验证让 AI 自己报出工具清单注册是否成功不用猜。示例工程的 main.py 会创建会话并直接问 AI 一句你有哪些工具回答里出现Ls就说明注册生效uv run main.py如果回答里没有Ls排查顺序建议是先确认myagent.yaml的引用路径拼写再确认my_tools包内类已正确导出。这类问题 90% 出在路径上而不是工具逻辑。从单个工具到工作流组合、权限与分发单个工具跑通后真正的价值来自组合。常见做法有两类多工具协作——在tools列表里同时挂载文件读取、Shell、你的 LsAI 会自己决定先列目录、再读文件的链路无需你写编排脚本。权限约束——Kimi Code CLI 对工具调用有审批机制敏感工具可以要求用户确认后才执行启动时用--yolo或--afk参数可放开审批适合 CI 场景日常使用保持默认更稳妥。详见 docs/zh/configuration/overrides.md。工具成熟后如何分享两个方向把my_tools打成 Python 包发布到 PyPI别人uv add之后在各自的代理配置里引用即可如果只是团队内部使用直接把这个目录放进项目仓库配合 docs/zh/customization/skills.md 里的 Skills 机制补充使用规范同事克隆仓库就自动拥有这套工具链。走到这里你已经完成了一次完整的 Kimi CLI 工具开发识别缺口、写出最小工具、一行配置注册、让 AI 自证可用。下一个值得做的工具就从你每次都要手动敲的那条命令开始。【免费下载链接】kimi-cliKimi Code CLI is your next CLI agent.项目地址: https://gitcode.com/GitHub_Trending/ki/kimi-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考