CLI-Anything 实战：开发钉钉 CLI
1. CLI-Anything 是什么
CLI-Anything 是香港大学数据智能实验室（HKUDS）开源的一个 Agent 工具，官方宣传是只需要一条命令，就能把现有的软件能力转成 Agent 可调用的命令行工具。项目在 2026 年 3 月初发布后，短时间内就拿到了 2 万多 Star，也很快在 AI 圈子里引起了讨论。
它的核心价值，是把软件的操作对象从人转向 Agent，把原本面向人的 GUI 操作，整理成更适合 Agent 调用的 CLI，这也可以理解成一种 Agent 原生化。
它的主体流程可以整理成 7 个步骤：
- Codebase Analysis：分析源码、后端引擎、数据模型，以及 GUI 动作和底层调用之间的映射关系。
- CLI Architecture Design：设计命令分组、状态模型、输出格式，并整理软件自己的 SOP 文档。
- Implementation：搭建
agent-harness目录结构，生成核心模块、CLI 入口、REPL 和 JSON 输出。 - Test Planning：编写测试计划，拆出单元测试、E2E 测试和真实工作流场景。
- Test Implementation：把测试真正写出来，包括
test_core.py、test_full_e2e.py这类覆盖核心逻辑和完整流程的测试。 - Test Documentation：汇总测试结果，确认整体通过率，并把验证结论记录下来。
- PyPI Publishing：补齐
setup.py等打包内容，把 CLI 安装到 PATH，变成可以直接调用的工具。
最后产出的也不只是几条命令，而是一整套可以安装、测试、验证使用的 CLI。
这也是它为什么让我感兴趣。尤其是 OpenClaw 出来之后，最大的限制已经不是 AI 大模型，而是软件生态。把软件 CLI 化之后，很多生态接入问题其实就容易解决了。
2. 需求背景
我日常工作里主要使用钉钉，但钉钉的开放性一直不如飞书。现在借助 OpenClaw，已经可以直接操作飞书完成文档编写、日程创建、消息发送等多项任务；同样的事情放到钉钉上，现成方案就少很多。
3 月中旬，阿里正式发布了企业级 AI 原生工作平台“悟空”。外部报道里提到的一个关键信号，是钉钉正在朝 Agent 可调用、可编排的方向推进，并对底层能力进行了全面的 CLI 化改造。
我很认同这个方向，但问题也很现实：截至目前，钉钉并没有对外提供一个可以直接拿来给 Agent 用的原生 CLI。既然没有现成方案，那我就想试试看，能不能借助 CLI-Anything，先做一个可用的 DingTalk CLI 出来。
3. 需求调研
使用 CLI-Anything 改造软件的前提是，要么你有它的源码，要么它对外提供了足够完整的 API / SDK。再说简单点，就是对 API、SDK 套壳，变成 CLI。
钉钉客户端本身当然不开源，但钉钉开放平台提供了比较完整的 OpenAPI 和多语言 SDK：
https://open.dingtalk.com/document/orgapp/sdk-download
既然不能从客户端源码入手，那就从官方 SDK 入手。我最终选择了 Node.js 版本的 SDK，因为它更轻量，也更简单。
4. 实操步骤
4.1. 前置条件
- Python 3.10+
- 目标软件、项目源码或 SDK 已准备好
- 一个支持的 AI Coding Agent，例如 Claude Code、OpenClaw、OpenCode、Codex、GitHub Copilot CLI 等
CLI-Anything 的安装方式可以直接参考官方文档：
https://github.com/HKUDS/CLI-Anything?tab=readme-ov-file#pick-your-platform
本文我使用的是 OpenCode + Claude 4.6 Opus 这套组合来演示。
4.2. 第一轮迭代：初步框架
第一步先不追求“直接可用到生产”，而是先让 CLI-Anything 基于钉钉 Node.js SDK 生成一个初步框架：
/cli-anything <source code path>
这一步完成后，CLI-Anything 会先给出一个基础可运行版本，并把配套测试一起跑通。
这里要注意一点：测试通过，只能说明这套框架先跑起来了。面对钉钉这种能力复杂、权限模型也比较重的平台，还远没到可以直接稳定使用的程度。对我来说，这一步更像是先把骨架搭起来。
4.3. 第二轮迭代：自主完善
有了第一轮结果之后，下一步就是继续让 CLI-Anything 自己做一轮更深入的补全和修正：
/cli-anything:refine <source code path>这一步会根据已有产物继续检查缺口，把前一轮里不够完整的部分进一步补齐。
生成完成后，可以先把 DingTalk CLI 装起来：
# 安装任意生成的 CLI
cd <软件名>/agent-harness
pip install -e .
# 验证安装
which cli-anything-<软件名>除了 CLI 本身，CLI-Anything 还会一起生成对应的 SKLL
<project>/agent-harness/cli_anything/<project>/skills/SKILL.md这点让我很惊喜，因为它不仅会帮你生成“工具”，还顺手把 Agent 如何理解和使用这个工具也一起准备了出来。
接着我让 OpenClaw 站在真实使用者的角度，检查这个 CLI 是否已经足够“Agent 友好”。
于是 OpenClaw 给出了下面这几条改进建议：
# CLI for Agent
1. 单方法 Schema 查询：支持按 `module + method` 查询单个 API 的结构化描述，避免整模块输出过大。
2. 统一 Schema 结构：所有 schema 输出使用固定且稳定的 JSON 格式，便于 agent 长期解析和依赖。
3. Schema 校验：在执行调用前按 schema 校验输入字段、类型、必填项和参数位置。
4. JSON 输入方式：`backend call` 支持通过 `--body-json / --body-file / --header-json / --header-file` 传入结构化请求数据。
5. 结构化错误输出：调用失败时返回统一的 JSON 错误对象，方便 agent 判断原因并自动修复。
6. 示例模板输出：支持生成单个 API 的最小可用请求模板，帮助 agent 快速构造合法调用。这些建议看起来都不大，但它们其实正好打在“Agent 真正能不能把工具用顺”这个关键点上。
AI时代，是一个 Agent 给另一个 Agent 提需求和反馈。
4.3. 第三轮迭代：定向完善
有了上一轮的反馈之后，第三轮就可以不再泛泛地 refine，而是把这些具体需求直接喂给 CLI-Anything，让它做定向修正：
/cli-anything:refine <source code path> "<需求>"这一步很像真实工程里的二次打磨。前面先把框架搭起来，到了这一轮，重点就变成了按具体需求继续修。
最终这次定向完善也顺利完成，并且测试通过：
4.4. 功能测试
代码生成和测试通过之后，真正重要的还是功能实测。
我先提供了钉钉应用的凭证去测试获取 access token，结果一开始并没有成功。后面让 OpenCode 帮忙分析，发现问题不在认证参数，而在生成出来的调用逻辑里默认使用了 HTTP 地址。把它改成 HTTPS 之后，access token 就可以正常获取了。
接着我又测试了发消息能力。这一步遇到的是权限问题，但也恰好说明前面做的几轮 schema、输入和错误输出约束是有价值的。因为当调用失败时，CLI 不会只告诉我“失败了”，还会明确指出缺少什么权限，甚至把对应的开通链接也给出来。
除此之外，我还顺手测了几个别的能力，比如发消息、创建日程，整体都没有什么大问题：
最后我还想继续往前走一步，试试看能不能用这个 CLI 来读写钉钉日报。结果是：读没有问题，但写的能力并没有开放出来。只能说，钉钉这波“主动防御”确实做得很到位。
5. 思考总结
整个过程比我预想中顺利，共耗时 1 小时左右，也让我对 CLI-Anything 的定位和能力看得更清楚了。
另外，CLI-Anything 的 Harness Engineering 做得确实很好：对项目源码的整体理解、对系统功能的细致分析、逐步迭代的开发、单元测试和 E2E 测试的约束，以及自动收集反馈，这些环节基本都串起来了。
但真到真实业务场景里，尤其是像钉钉这种接口多、权限复杂、平台规则又比较重的系统，最后还是要回到真实功能测试。因为认证方式、协议细节、权限边界、产品能力缺口，这些问题不是只靠读 SDK 就能完全推断出来的。
所以在我看来，CLI-Anything 很适合快速搭出一个 CLI 工具骨架，但离“生产级 CLI”还有一段路，这里还有优化空间。
最后我把这个项目也放到了 GitHub，可以供大家参考：