尧图网站建设 
Dify Workflow DSL 的 Agent 原生封装实战使用 CLI-Anything 封装 dify-workflow CLI 实现工作流文件命令行创建、校验与编辑【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything导读本篇技术指南聚焦 CLI-Anything 生态中的cli-anything-dify-workflow封装 Harness讲解如何通过 CLI-Anything 将开源的dify-workflowCLI 包装为 Agent 可发现、可调用的统一命令行接口从而实现对 Dify 工作流 DSL 文件YAML/JSON的创建、检查、校验、编辑、导入导出与对比。读完本文你将掌握该封装包的两步安装方式、完整命令面create/inspect/validate/edit/config等 13 组命令的使用姿势并从 dify_workflow_cli.py、dify_workflow_backend.py 与测试用例中理解其零重写、纯转发的封装原理与后端发现机制。本文对应的核心 Skill 文档位于 dify-workflow/agent-harness/cli_anything/dify_workflow/skills/SKILL.md可作为 Agent 运行时加载的元数据。Dify Workflow 与封装式 Harness设计背景Dify 是当前流行的 LLM 应用开发平台其工作流应用本质是一份遵循特定 DSL 结构的 YAML/JSON 描述文件。社区上游项目dify-ai-workflow-toolsCLI 名dify-workflow已经提供了成熟的工作流编排命令行引擎负责 DSL 文件的读写、节点类型管理、图结构变更与模型配置修改。在 CLI-Anything 仓库中每一个子项目对应一种被 Agent 化的软件。对 Dify Workflow 而言架构团队的选择是不重写引擎只做包装DIFY_WORKFLOW.md 开篇即说明该 Harness 聚焦于四件事共享cli_anything命名空间下的打包、AI 可发现的SKILL.md、统一的 REPL 皮肤以及 CLI-Hub 注册表集成而真正的工作流 DSL 引擎逻辑全部由上游提供。从该架构文档可以看到清晰的交互模型AI Agent - cli-anything-dify-workflow - 已安装的 dify-workflow CLI / dify_workflow Python 包 - 本地 Dify YAML/JSON DSL 文件这种模式的优势在于上游 CLI 成熟稳定无需重写CLI-Anything 侧只需让 Agent 能够从 CLI-Hub 发现该命令、读取它的 Skill 元数据即可是一种典型的包装即集成路线。安装先上游、后包装的两步流程Skill 文档与 README.md、setup.py 均强调安装必须分两步先后次序不可颠倒# 第一步安装上游 Dify workflow CLI真实工作流引擎 python -m pip install dify-ai-workflow-tools githttps://github.com/Akabane71/dify-workflow-cli.gitmain # 第二步安装 CLI-Anything 封装 Harness pip install githttps://github.com/HKUDS/CLI-Anything.git#subdirectorydify-workflow/agent-harness关于第二步仓库也支持本地开发式安装在dify-workflow/agent-harness目录下执行pip install -e .即可见 setup.py。上游若日后发布到 PyPI第一步可替换为常规 PyPI 安装。环境前提封装包要求 Python ≥ 3.10setup.py运行时依赖仅两个——click8.0.0与prompt-toolkit3.0.0分别用于命令入口与交互式 REPL 提示。安装完成后setup.py的entry_points会注册cli-anything-dify-workflow控制台命令并指向cli_anything.dify_workflow.dify_workflow_cli:mainsetup.py同时包内skills/*.md作为package_data一并打包保证已安装环境下 Skill 元数据依然可被 Agent 定位。值得注意的细节是setup.py通过find_namespace_packages(include[cli_anything.*])将模块纳入统一的cli_anything命名空间setup.py这与仓库中所有 Harness 的打包约定一致也方便 CLI-Hub 做矩阵式发现。交互模式一次性命令与内置 REPLcli-anything-dify-workflow支持两种调用形态形态一直接传参的一次性命令。Skill 文档给出的典型用法如下cli-anything-dify-workflow guide cli-anything-dify-workflow list-node-types cli-anything-dify-workflow create -o workflow.yaml --mode workflow --template llm cli-anything-dify-workflow inspect workflow.yaml -j cli-anything-dify-workflow validate workflow.yaml -j cli-anything-dify-workflow edit add-node -f workflow.yaml --type code --title Process cli-anything-dify-workflow config set-model -f app.yaml --provider openai --name gpt-4o形态二交互式 REPL。从 dify_workflow_cli.py 可见cli是一个invoke_without_commandTrue的 click 分组——当用户不带子命令直接运行时会进入repl打印带品牌标识的启动横幅后用户可直接输入上游命令无需带二进制名例如guide、list-node-types、create -o app.yaml --template llm输入quit/exit退出输入help查看包装层支持的命令清单dify_workflow_cli.py。REPL 的交互皮肤来自仓库各 Harness 共用的 repl_skin.py基于prompt_toolkit提供历史记录持久化在~/.cli-anything-dify_workflow/history、自动建议、配色风格与框线横幅repl_skin.py。它是 CLI-Anything 统一终端体验的具体实现。命令面全景13 组命令一览Skill 文档列出的完整命令组与包装层 dify_workflow_cli.py 中的 click 定义一一对应整理如下命令功能定位对应源码转发函数guide展示上游使用教程dify_workflow_cli.py#L107-L110list-node-types列出支持的 Dify 节点类型dify_workflow_cli.py#L113-L116create新建 Dify 应用workflow/chat 等模式dify_workflow_cli.py#L119-L122inspect检查/查看工作流文件dify_workflow_cli.py#L125-L128validate校验工作流文件合法性dify_workflow_cli.py#L131-L134checklist工作流发布前检查清单dify_workflow_cli.py#L137-L140edit图结构变更子命令组dify_workflow_cli.py#L167-L200config模型/提示词/变量配置变更子命令组dify_workflow_cli.py#L202-L239export导出 YAML 或 JSONdify_workflow_cli.py#L143-L146import导入并规范化工作流文件dify_workflow_cli.py#L149-L152diff对比两份工作流文件dify_workflow_cli.py#L155-L158layout节点自动布局dify_workflow_cli.py#L161-L164edit与config两个子命令组包装层把上游的edit与config展开为可发现的 click 子命令组edit add-node|remove-node|update-node|add-edge|remove-edge|set-title对应工作流图的节点增删改、边连线增删与标题修改示例cli-anything-dify-workflow edit add-node -f workflow.yaml --type code --title Process表示向workflow.yaml添加一个标题为 Process 的 code 类型节点。config set-model|set-prompt|add-variable|set-opening|add-question|add-tool|remove-tool对应 Chat/Agent/Completion 应用的模型、系统提示词、输入变量、开场白、开场问题与工具配置变更示例cli-anything-dify-workflow config set-model -f app.yaml --provider openai --name gpt-4o表示把app.yaml的模型切换为 OpenAI 的gpt-4o。这里尤其体现了Agent 原生的价值一个只暴露--help的复杂上游 CLI 对 Agent 而言难以稳定使用而包装层将完整子命令结构摊平为静态可发现的命令组同时配合 SKILL.md 的 YAML frontmattername: cli-anything-dify-workflow与description字段让 Agent 在语义检索阶段即可命中并决定是否加载。源码级原理后端发现、参数透传与结果回传该包装器的本质是参数透明转发核心实现在 dify_workflow_backend.py可分为三层。第一层后端解析resolve。require_dify_workflow_command()dify_workflow_backend.py#L18-L31按以下优先级寻找真实执行入口通过shutil.which(dify-workflow)查找 PATH 上的可执行文件若找不到但importlib.util.find_spec(dify_workflow)能定位到已安装的 Python 包则回退为[sys.executable, -m, dify_workflow.cli]的模块调用方式——这正是 SKILL.md 中若dify-workflow不在 PATH 但dify_workflowPython 包已安装包装器回退到python -m dify_workflow.cli这一条 Agent 指引的源码依据两者皆无则抛出带安装指引的RuntimeError引导用户先安装上游 CLI。第二层命令组装。build_command(args)dify_workflow_backend.py#L34-L36把解析出的执行入口与用户参数拼接成完整子进程命令has_upstream_cli()dify_workflow_backend.py#L39-L45对外暴露上游是否可用的能力探测。第三层子进程执行与输出处理。run_dify_workflow(args)dify_workflow_backend.py#L48-L58使用subprocess.run(..., capture_outputTrue, checkFalse)同步执行并捕获 stdout/stderr返回码非零时优先取出 stderr 文本作为RuntimeError消息抛给 click 层转成友好错误成功则回传去掉尾部空白的 stdout。考虑到跨 Windows 环境的编码健壮性输出统一按 UTF-8 解码errorsreplace见 dify_workflow_backend.py#L11-L15同时 dify_workflow_cli.py 在启动时会对 stdout/stderr 调用reconfigure(encodingutf-8)确保被转发的内容在各平台保持可读。参数透传的关键技巧包装层所有命令都设置了context_settings的PASS_ARGSignore_unknown_optionsTrue与allow_extra_argsTrue见 dify_workflow_cli.py#L15-L18click 因此不会拦截上游独有参数而是把未知参数原样放进ctx.args。每个包装命令如_forward(edit, add-node)见 dify_workflow_cli.py#L172-L174只需把固定前缀与ctx.args拼接后交给run_dify_workflow即实现前缀固定、后缀全透传。测试如何验证封装行为该 Harness 附带两层测试可运行python -m pytest dify-workflow/agent-harness/cli_anything/dify_workflow/tests/ -v路径基于仓库根目录test_core.py不依赖上游安装的单元测试。通过 mock 验证三条后端发现路径——PATH 命中二进制时返回[/usr/bin/dify-workflow]test_core.py#L17-L19、仅存在 Python 包时回退为[python, -m, dify_workflow.cli]test_core.py#L21-L26、两者皆缺时抛出安装引导错误test_core.py#L28-L34还验证了build_command([guide, -j]) [dify-workflow, guide, -j]的透传拼接、--help渲染以及 README/SKILL.md 中关键安装文案与包装行为的可发现性test_core.py#L55-L67。test_full_e2e.py见 tests 目录在上游 CLI 确已安装的前提下做包装器子进程冒烟测试与工作流生命周期转发测试验证真实端到端链路。这种单元 mock 端到端可选的测试分层与 DIFY_WORKFLOW.md 中声明的测试策略完全一致也让维护者能同时覆盖无上游可离线自测与有上游可全链路验证两种场景。给 Agent 的使用指引与安全边界Skill 文档在 Agent Guidance 一节给出了三条对自动化调用至关重要的建议值得全文照录并展开优先使用 JSON 输出上游多数命令支持-j/--json-outputAgent 应默认携带该参数以获取结构化结果便于解析与后续决策。牢记包装器边界封装层本身只是转发壳真正的 DSL 逻辑由上游dify-workflow项目提供。当某个能力在包装层不可见时应从上游侧确认而非在 CLI-Anything 内寻找实现。理解回退加载路径只要dify_workflowPython 包可导入即使 PATH 上没有dify-workflow可执行文件包装器也能以python -m dify_workflow.cli方式正常工作源码依据见上文后端解析一节。安全边界同样来自 README.md有两点其一该 Harness 的全部操作都是对本地 Dify YAML/JSON DSL 文件的文件级编辑不会触达远端 Dify 服务其二在把生成的 YAML/JSON 导入到生产 Dify 项目前应人工审查生成内容——尤其是通过config/edit批量修改后的结果。对 Agent 而言先validate -j再提交、提交前跑checklist是一个稳妥的工作流闭环。小结cli-anything-dify-workflow是 CLI-Anything 生态中复用成熟 CLI、以最小成本获得 Agent 原生能力的典型范本它用两步安装 一份 SKILL.md 一层 click 转发壳 一个统一 REPL 皮肤就让 Dify 工作流 DSL 的创建、检查、校验、图编辑与配置变更全部对 Agent 可发现、可调用、可校验。理解它的封装边界——真实引擎在上游、转发发生在本地、输出优先 JSON——是后续在自动化流水线中安全使用它的关键前提。进一步探索可在仓库内查看封装入口 dify_workflow_cli.py、后端适配 dify_workflow_backend.py、架构说明 DIFY_WORKFLOW.md 与单元测试 test_core.py。【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dify Workflow DSL 的 Agent 原生封装实战：使用 CLI-Anything 封装 dify-workflow CLI 实现工作流文件命令行创建、校验与编辑
Dify Workflow DSL 的 Agent 原生封装实战使用 CLI-Anything 封装 dify-workflow CLI 实现工作流文件命令行创建、校验与编辑【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything导读本篇技术指南聚焦 CLI-Anything 生态中的cli-anything-dify-workflow封装 Harness讲解如何通过 CLI-Anything 将开源的dify-workflowCLI 包装为 Agent 可发现、可调用的统一命令行接口从而实现对 Dify 工作流 DSL 文件YAML/JSON的创建、检查、校验、编辑、导入导出与对比。读完本文你将掌握该封装包的两步安装方式、完整命令面create/inspect/validate/edit/config等 13 组命令的使用姿势并从 dify_workflow_cli.py、dify_workflow_backend.py 与测试用例中理解其零重写、纯转发的封装原理与后端发现机制。本文对应的核心 Skill 文档位于 dify-workflow/agent-harness/cli_anything/dify_workflow/skills/SKILL.md可作为 Agent 运行时加载的元数据。Dify Workflow 与封装式 Harness设计背景Dify 是当前流行的 LLM 应用开发平台其工作流应用本质是一份遵循特定 DSL 结构的 YAML/JSON 描述文件。社区上游项目dify-ai-workflow-toolsCLI 名dify-workflow已经提供了成熟的工作流编排命令行引擎负责 DSL 文件的读写、节点类型管理、图结构变更与模型配置修改。在 CLI-Anything 仓库中每一个子项目对应一种被 Agent 化的软件。对 Dify Workflow 而言架构团队的选择是不重写引擎只做包装DIFY_WORKFLOW.md 开篇即说明该 Harness 聚焦于四件事共享cli_anything命名空间下的打包、AI 可发现的SKILL.md、统一的 REPL 皮肤以及 CLI-Hub 注册表集成而真正的工作流 DSL 引擎逻辑全部由上游提供。从该架构文档可以看到清晰的交互模型AI Agent - cli-anything-dify-workflow - 已安装的 dify-workflow CLI / dify_workflow Python 包 - 本地 Dify YAML/JSON DSL 文件这种模式的优势在于上游 CLI 成熟稳定无需重写CLI-Anything 侧只需让 Agent 能够从 CLI-Hub 发现该命令、读取它的 Skill 元数据即可是一种典型的包装即集成路线。安装先上游、后包装的两步流程Skill 文档与 README.md、setup.py 均强调安装必须分两步先后次序不可颠倒# 第一步安装上游 Dify workflow CLI真实工作流引擎 python -m pip install dify-ai-workflow-tools githttps://github.com/Akabane71/dify-workflow-cli.gitmain # 第二步安装 CLI-Anything 封装 Harness pip install githttps://github.com/HKUDS/CLI-Anything.git#subdirectorydify-workflow/agent-harness关于第二步仓库也支持本地开发式安装在dify-workflow/agent-harness目录下执行pip install -e .即可见 setup.py。上游若日后发布到 PyPI第一步可替换为常规 PyPI 安装。环境前提封装包要求 Python ≥ 3.10setup.py运行时依赖仅两个——click8.0.0与prompt-toolkit3.0.0分别用于命令入口与交互式 REPL 提示。安装完成后setup.py的entry_points会注册cli-anything-dify-workflow控制台命令并指向cli_anything.dify_workflow.dify_workflow_cli:mainsetup.py同时包内skills/*.md作为package_data一并打包保证已安装环境下 Skill 元数据依然可被 Agent 定位。值得注意的细节是setup.py通过find_namespace_packages(include[cli_anything.*])将模块纳入统一的cli_anything命名空间setup.py这与仓库中所有 Harness 的打包约定一致也方便 CLI-Hub 做矩阵式发现。交互模式一次性命令与内置 REPLcli-anything-dify-workflow支持两种调用形态形态一直接传参的一次性命令。Skill 文档给出的典型用法如下cli-anything-dify-workflow guide cli-anything-dify-workflow list-node-types cli-anything-dify-workflow create -o workflow.yaml --mode workflow --template llm cli-anything-dify-workflow inspect workflow.yaml -j cli-anything-dify-workflow validate workflow.yaml -j cli-anything-dify-workflow edit add-node -f workflow.yaml --type code --title Process cli-anything-dify-workflow config set-model -f app.yaml --provider openai --name gpt-4o形态二交互式 REPL。从 dify_workflow_cli.py 可见cli是一个invoke_without_commandTrue的 click 分组——当用户不带子命令直接运行时会进入repl打印带品牌标识的启动横幅后用户可直接输入上游命令无需带二进制名例如guide、list-node-types、create -o app.yaml --template llm输入quit/exit退出输入help查看包装层支持的命令清单dify_workflow_cli.py。REPL 的交互皮肤来自仓库各 Harness 共用的 repl_skin.py基于prompt_toolkit提供历史记录持久化在~/.cli-anything-dify_workflow/history、自动建议、配色风格与框线横幅repl_skin.py。它是 CLI-Anything 统一终端体验的具体实现。命令面全景13 组命令一览Skill 文档列出的完整命令组与包装层 dify_workflow_cli.py 中的 click 定义一一对应整理如下命令功能定位对应源码转发函数guide展示上游使用教程dify_workflow_cli.py#L107-L110list-node-types列出支持的 Dify 节点类型dify_workflow_cli.py#L113-L116create新建 Dify 应用workflow/chat 等模式dify_workflow_cli.py#L119-L122inspect检查/查看工作流文件dify_workflow_cli.py#L125-L128validate校验工作流文件合法性dify_workflow_cli.py#L131-L134checklist工作流发布前检查清单dify_workflow_cli.py#L137-L140edit图结构变更子命令组dify_workflow_cli.py#L167-L200config模型/提示词/变量配置变更子命令组dify_workflow_cli.py#L202-L239export导出 YAML 或 JSONdify_workflow_cli.py#L143-L146import导入并规范化工作流文件dify_workflow_cli.py#L149-L152diff对比两份工作流文件dify_workflow_cli.py#L155-L158layout节点自动布局dify_workflow_cli.py#L161-L164edit与config两个子命令组包装层把上游的edit与config展开为可发现的 click 子命令组edit add-node|remove-node|update-node|add-edge|remove-edge|set-title对应工作流图的节点增删改、边连线增删与标题修改示例cli-anything-dify-workflow edit add-node -f workflow.yaml --type code --title Process表示向workflow.yaml添加一个标题为 Process 的 code 类型节点。config set-model|set-prompt|add-variable|set-opening|add-question|add-tool|remove-tool对应 Chat/Agent/Completion 应用的模型、系统提示词、输入变量、开场白、开场问题与工具配置变更示例cli-anything-dify-workflow config set-model -f app.yaml --provider openai --name gpt-4o表示把app.yaml的模型切换为 OpenAI 的gpt-4o。这里尤其体现了Agent 原生的价值一个只暴露--help的复杂上游 CLI 对 Agent 而言难以稳定使用而包装层将完整子命令结构摊平为静态可发现的命令组同时配合 SKILL.md 的 YAML frontmattername: cli-anything-dify-workflow与description字段让 Agent 在语义检索阶段即可命中并决定是否加载。源码级原理后端发现、参数透传与结果回传该包装器的本质是参数透明转发核心实现在 dify_workflow_backend.py可分为三层。第一层后端解析resolve。require_dify_workflow_command()dify_workflow_backend.py#L18-L31按以下优先级寻找真实执行入口通过shutil.which(dify-workflow)查找 PATH 上的可执行文件若找不到但importlib.util.find_spec(dify_workflow)能定位到已安装的 Python 包则回退为[sys.executable, -m, dify_workflow.cli]的模块调用方式——这正是 SKILL.md 中若dify-workflow不在 PATH 但dify_workflowPython 包已安装包装器回退到python -m dify_workflow.cli这一条 Agent 指引的源码依据两者皆无则抛出带安装指引的RuntimeError引导用户先安装上游 CLI。第二层命令组装。build_command(args)dify_workflow_backend.py#L34-L36把解析出的执行入口与用户参数拼接成完整子进程命令has_upstream_cli()dify_workflow_backend.py#L39-L45对外暴露上游是否可用的能力探测。第三层子进程执行与输出处理。run_dify_workflow(args)dify_workflow_backend.py#L48-L58使用subprocess.run(..., capture_outputTrue, checkFalse)同步执行并捕获 stdout/stderr返回码非零时优先取出 stderr 文本作为RuntimeError消息抛给 click 层转成友好错误成功则回传去掉尾部空白的 stdout。考虑到跨 Windows 环境的编码健壮性输出统一按 UTF-8 解码errorsreplace见 dify_workflow_backend.py#L11-L15同时 dify_workflow_cli.py 在启动时会对 stdout/stderr 调用reconfigure(encodingutf-8)确保被转发的内容在各平台保持可读。参数透传的关键技巧包装层所有命令都设置了context_settings的PASS_ARGSignore_unknown_optionsTrue与allow_extra_argsTrue见 dify_workflow_cli.py#L15-L18click 因此不会拦截上游独有参数而是把未知参数原样放进ctx.args。每个包装命令如_forward(edit, add-node)见 dify_workflow_cli.py#L172-L174只需把固定前缀与ctx.args拼接后交给run_dify_workflow即实现前缀固定、后缀全透传。测试如何验证封装行为该 Harness 附带两层测试可运行python -m pytest dify-workflow/agent-harness/cli_anything/dify_workflow/tests/ -v路径基于仓库根目录test_core.py不依赖上游安装的单元测试。通过 mock 验证三条后端发现路径——PATH 命中二进制时返回[/usr/bin/dify-workflow]test_core.py#L17-L19、仅存在 Python 包时回退为[python, -m, dify_workflow.cli]test_core.py#L21-L26、两者皆缺时抛出安装引导错误test_core.py#L28-L34还验证了build_command([guide, -j]) [dify-workflow, guide, -j]的透传拼接、--help渲染以及 README/SKILL.md 中关键安装文案与包装行为的可发现性test_core.py#L55-L67。test_full_e2e.py见 tests 目录在上游 CLI 确已安装的前提下做包装器子进程冒烟测试与工作流生命周期转发测试验证真实端到端链路。这种单元 mock 端到端可选的测试分层与 DIFY_WORKFLOW.md 中声明的测试策略完全一致也让维护者能同时覆盖无上游可离线自测与有上游可全链路验证两种场景。给 Agent 的使用指引与安全边界Skill 文档在 Agent Guidance 一节给出了三条对自动化调用至关重要的建议值得全文照录并展开优先使用 JSON 输出上游多数命令支持-j/--json-outputAgent 应默认携带该参数以获取结构化结果便于解析与后续决策。牢记包装器边界封装层本身只是转发壳真正的 DSL 逻辑由上游dify-workflow项目提供。当某个能力在包装层不可见时应从上游侧确认而非在 CLI-Anything 内寻找实现。理解回退加载路径只要dify_workflowPython 包可导入即使 PATH 上没有dify-workflow可执行文件包装器也能以python -m dify_workflow.cli方式正常工作源码依据见上文后端解析一节。安全边界同样来自 README.md有两点其一该 Harness 的全部操作都是对本地 Dify YAML/JSON DSL 文件的文件级编辑不会触达远端 Dify 服务其二在把生成的 YAML/JSON 导入到生产 Dify 项目前应人工审查生成内容——尤其是通过config/edit批量修改后的结果。对 Agent 而言先validate -j再提交、提交前跑checklist是一个稳妥的工作流闭环。小结cli-anything-dify-workflow是 CLI-Anything 生态中复用成熟 CLI、以最小成本获得 Agent 原生能力的典型范本它用两步安装 一份 SKILL.md 一层 click 转发壳 一个统一 REPL 皮肤就让 Dify 工作流 DSL 的创建、检查、校验、图编辑与配置变更全部对 Agent 可发现、可调用、可校验。理解它的封装边界——真实引擎在上游、转发发生在本地、输出优先 JSON——是后续在自动化流水线中安全使用它的关键前提。进一步探索可在仓库内查看封装入口 dify_workflow_cli.py、后端适配 dify_workflow_backend.py、架构说明 DIFY_WORKFLOW.md 与单元测试 test_core.py。【免费下载链接】CLI-AnythingCLI-Anything: Making ALL Software Agent-Native -- CLI-Hub: https://clianything.cc/项目地址: https://gitcode.com/GitHub_Trending/cl/CLI-Anything创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考