内部系统Agent化实战：CLI-Anything生成CLI

存量系统进入 Agent 生产链路，不必从零开始。飞书开放的 Agent Skills 给出启发，用 CLI-Anything 自动生成 CLI 骨架，再用 skill-up 把 Skill 变成可评测资产，打通命令生成到 Skill Eval 全链路。

最近我拆了一遍飞书开放出来的 Agent Skills（lark-cli）。原本我以为，最值得研究的会是那些 Skill 文件：里面是不是藏了复杂的提示词、工作流编排，或者某种特别的 Agent 框架？

结果看完以后，Skill 本身反而很朴素。主体仍然是 Markdown，写清什么时候使用、调用什么命令、遇到异常怎么办。真正让我停下来的是它下面那层 CLI。

飞书没有让 Agent 直接面对数量庞大的 OpenAPI，而是先把能力整理成稳定的命令，再让 Skill 告诉 Agent 如何组合这些命令。这给了我一个很直接的启发：我们的内部系统也有 API，也有完整的业务能力，为什么 Agent 每次还要重新理解接口、参数和返回值？它缺的可能不是另一个聊天入口，而是一层稳定的执行接口。

也正是从这个问题开始，我想做的就不再只是给内部系统补一个 CLI，而是让它的业务能力真正进入 Agent 的生产链路：模型能理解，CLI 能执行，结果还能被验证。（假装一下）更巧的是，这条链并不需要从零搭起——CLI-Anything 帮我从现有系统生成 CLI，skill-up 帮我把 Skill 变成可以反复运行的评测对象。原来从 CLI 生成到 Skill 评测，已经有一组相对成熟的工具可以串起来。

01 飞书让我看见的，不是一份 Skill，而是一层执行接口

如果是第一次接触这些概念，可以先记住四个分工：Agent 负责理解目标，Skill 告诉它什么时候做、按什么顺序做，CLI 负责确定地执行动作，Eval 则检查整套过程有没有做对。它们不是四个互相替代的产品，而是一条链上的不同环节。

飞书的 CLI 也不是把所有接口平铺出来。它大致分成三层：最上面是高频业务动作，中间是按资源组织的 API 命令，底层才保留 Raw API 作为长尾补充。Agent 先走稳定、语义明确的入口，实在没有现成命令时再下探。

这张图真正有价值的地方，是把“会不会做”和“能不能执行”分开了。Skill 可以持续补充业务知识，CLI 可以独立测试和发布；即便换了模型，底下的命令和权限边界仍然存在。

顺着这条链再看内部系统，方向就清楚了：原系统继续负责数据、权限、事务和业务规则；外围增加一层 CLI，把 Agent 需要的动作收敛成稳定命令；再用 Skill 组织操作顺序和注意事项。Agent 化不是推翻原系统重做，而是给它增加一个更适合机器调用的入口。

这里有一个容易走偏的地方：CLI 不是把 HTTP Endpoint 换个名字。后端可能分别提供“查成员、查状态、更新工作项”三个接口，但 Agent 真正想完成的是“把某个工作项分配给某人”。前者是技术接口，后者才是业务动作。CLI 要做的，是把分散的接口整理成 Agent 可以理解、复现和核验的动作。

我也没有追求把所有 API 都 CLI 化。调试、数据修复、系统配置和高权限接口，本来就不该默认交给 Agent。与其追求接口覆盖率，不如先回答：目标任务需要哪些业务能力，其中哪些可以自动执行，哪些必须确认，哪些应该继续留在人手里。

这一步先把范围划清，后面的生成和测试才不会变成无差别堆命令。

02 我先做内部 CLI，然后才找到 CLI-Anything

方向明确以后，真正麻烦的是工程量。一个已有多年的内部系统，接口命名、鉴权方式、错误格式和业务对象通常都不统一。如果完全手工做，需要先读源码、梳理接口、设计命令、补测试，再写安装文档和 Skill。最关键的是…我也只是个产品，看不懂源码，也正是在找更快起点的过程中，我发现了 CLI-Anything。

CLI-Anything 是香港大学 Data Intelligence Lab（HKUDS）开源的项目，采用 Apache-2.0 许可证。截至 2026 年 8 月 19 日，它在 GitHub 上有 47796 个 Star。这个数字说明它已经获得了相当高的社区关注，但我仍然不会把 Star 当成生产可用性的证明。

CLI-Anything 的价值很实在：它可以先扫描现有项目，理解应用结构和可调用能力，生成 CLI 骨架、命令、测试和配套 Skill。对于“系统已经存在，只是缺少机器入口”的场景，它把大量重复劳动提前做掉了。

但这里必须把预期说清楚：CLI-Anything 生成的是第一个可验证版本，不是一个可以直接上线的成品。 它需要围绕真实问题反复运行和 refine，每一轮都补能力、补测试、补文档。只运行一次、看到命令能启动，就宣布内部系统已经 Agent 化，风险很大。

我后来的收敛顺序比较保守：先把只读查询、分页和名称解析跑稳，再进入创建、更新，最后才开放删除和批量操作。每一类命令都用安装后的真实 CLI 验收，而不是只测内部函数。因为 Agent 最终面对的是终端输入、标准输出、网络错误和真实权限，这些恰恰是源码扫描最难替你判断的部分。

自动生成真正改变的，不是“以后不用写代码了”，而是把工作起点从搭脚手架推进到了验证业务。以前大部分时间花在把 CLI 写出来；现在更需要把时间花在证明它不会认错对象、误解参数，或者在失败后做出危险重试。

03 生成工具绕不过原系统的登录和安全边界

我踩得最深的一处是登录。

最初接企业单点登录（SSO）时，浏览器已经完成认证，也拿到了身份平台返回的 Token，但内部系统并不接受它。原因后来才查清：身份平台证明的是“你是谁”，业务系统还要沿用自己的令牌交换和会话规则。认证页面能成功跳转，不代表 CLI 已经获得了可以调用业务接口的凭证。

最后我没有继续在 CLI 外面另造一套登录，而是回到原系统的实现，分别接通账号密码、企业 SSO 和浏览器会话复用三条路径。三种方式在入口上不同，最终都收敛成同一种认证结果，后面的业务命令不需要知道凭证来自哪里。

这张图也解释了为什么“任何内部系统一键 Agent 化”不太现实。命令骨架可以自动生成，登录、权限和审计却必须参考内部实现。SSO 要校验用于防止回调冒用的随机 state，凭证文件要限制访问权限，TLS 不能为了图省事默认关闭校验；遇到 401（身份失效）应该要求重新登录，而不是把写操作换个 Token 再试一遍。

功能测试也不能只覆盖“命令返回成功”。我会至少检查四层：**命令和参数是否正确，输出格式是否稳定，真实网关与权限是否跑通，删除和批量操作是否有确认与止损。**写请求超时尤其不能直接重放，因为上一次请求可能已经成功，只是响应丢了；更稳妥的做法是先只读核验结果。

到这一步，CLI-Anything 仍然有价值，只是角色变了：它负责快速生成和持续补齐，人负责定义业务动作、接入真实认证，并用大量功能测试把生成结果压到生产边界内。

04 性能优化的重点，不只是让命令更快

CLI 跑通以后，我很快遇到另一个问题。Agent 为了更新一个状态，可能先查工作项，再查状态元数据和成员信息；每条命令又返回一整段 JSON。动作本身没错，但等待时间、工具调用次数和 Token——也就是模型读写上下文的计量单位——都在增加。

我最后把优化拆成四层。没有依赖的查询并行执行，减少接口串行等待；同一次调用里重复使用的元数据做缓存；列表强制分页，并用 –select 只保留标题、状态、负责人等必要字段；主 SKILL.md 只放触发条件、常用路径和安全规则，完整命令与异常处理下沉到按需参考文件（references），需要时再读取。

这类优化有一个很容易吹过头的地方。例如当前实现只能证明“单次调用内缓存”，就不能写成“整个 Agent 会话只查询一次”；做了字段裁剪，也只能说减少了输入内容，不能在没有前后测量时宣布节省了多少 Token。性能优化必须留下基线：一次任务用了多少命令、耗时多久、输入输出多少 Token、失败后重试几次。否则“更快、更省”只是一种感觉。

我一开始把这个收益概括成“可审计”，回头对照实现后发现说过头了。CLI 只是把动作收敛成了明确命令；当前版本还没有把每次操作自动写入持久化审计日志。真正让我能追查一次 Agent 行为的，是后面接上的 Skill Eval。

05 CLI 测试通过后，我才发现还缺一套 Skill Eval

CLI 的测试全绿，并不代表 Agent 会正确使用它。Agent 可能选错命令、漏掉确认、把用户说的“第 3 条”猜成某个对象，或者加载了机器上同名的旧 Skill。代码层测试看不到这些问题。

这也是我后来找到 skill-up 的原因。它由阿里巴巴开源组织（Alibaba Open Source）开源，定位是 Agent Skill 的评测与演进工具，同样采用 Apache-2.0 许可证。截至 2026 年 8 月 19 日，GitHub 上有 609 个 Star。它的关注度还不能和 CLI-Anything 相比，但出品方、开放源码和可复查的评测产物，至少让我能看清它怎么运行、怎么判定，而不是把结果交给另一个黑盒。

在这条链路里，CLI-Anything 把现有系统变成可调用的命令，skill-up 则把 Skill 变成可以持续回归的对象。一个评测用例（Eval Case）不只写用户问题，还要写预期行为、禁做动作和评分方式；运行时再指定 Agent 引擎，保存会话记录，最后由确定性规则或模型评判器给出结果。

具体做法分两层。CLI 先保证机器输出可以被留档：–json 模式下，标准输出（stdout）只放结构化结果；失败时固定返回错误类型、是否可以重试和建议执行的命令，提示与警告则放到错误输出（stderr）。skill-up 再为每个 Case 保存原始会话和评测报告，里面能看到用户问题、Agent 实际调用的命令、命令返回、最终回答、耗时、Token、轮次和评分证据。一次失败出现后，我就能沿着这条记录判断：是命令选错了、CLI 返回错了、Agent 理解错了，还是评测引擎根本没有正常启动。

这仍然不等于生产审计。如果要追查真实写操作，还需要给 CLI 增加持久化操作日志，记录时间、项目、目标资源、危险级别和结果状态，同时排除 Token、密码和完整敏感描述。当前实现还没有完成这一步，所以这里更准确的说法是“评测过程可复盘”，不是“所有 Agent 操作都可审计”。

我最初只是手工试几个正常问题，后来才逐步补上触发、流程、异常、反例和多轮对话。能够用命令、顺序和关键词直接判断的事实，我优先写成规则；只有表达质量、解释是否完整这类语义问题，才交给模型评判。确定的事情尽量不要再让另一个模型“凭感觉打分”。

第一次跑自动评测时，报告几乎全红，Token 统计还是 0。翻完原始日志才发现，不是 Skill 突然坏了，而是评测引擎没有在非交互环境里正常启动。后来 Eval 还暴露过另一个问题：运行时加载的是旧安装副本，并不是仓库里刚改过的版本。这两次经历让我确认，评测报告只能告诉你“有失败”，不能替你完成归因。

真正的测量闭环应该继续往下走：先判断失败属于 CLI、Skill、评测规则还是运行环境；再修改对应层；补一条可以复现的回归用例；最后重新运行受影响的套件。报告只是入口，能够让同一类错误下一次自动暴露，测量才算真正参与了生产。

with_skill 和 without_skill 的基线对比可以继续回答：加载 Skill 后，成功率、步骤数、时间和 Token 到底发生了什么变化。不过完整基线本身也会消耗时间和 Token。我的做法是，结构大改或关键版本跑完整对比，日常修改优先跑受影响的确定性用例，再定期补真实环境回归。测量要形成证据，但也不能变成新的成本黑洞。

06 我现在怎么判断内部系统是否真的完成了 Agent 化

现在再看一个内部系统，我已经不太关心它有没有生成 SKILL.md，也不会被“一句话创建任务”的演示说服。我更看下面五件事：

• Agent 需要的业务动作，是否被 CLI 正确覆盖，而不是把所有 API 无差别暴露出来；
• 账号密码、SSO、权限和审计，是否沿用了原系统真实的信任链；
• 输出、分页、字段投影和按需加载，是否控制住等待时间与 Token；
• 查询、写入、失败和危险操作，是否都经过真实功能测试；
• Skill 是否有基线、回归、原始记录，并且发布的就是刚刚测过的版本。

把这些判断重新串起来，就是我现在理解的内部系统 Agent 化生产链路：

它不是一条从左到右跑完就结束的流水线。评测暴露的问题，必须能继续回到 CLI、Skill 或运行环境里修正；修完以后，还要由同一组用例再次证明问题没有回来。

回头看，飞书 lark-cli 真正改变我的，不是让我照抄一套命令，而是让我看到 Skill 下面还需要一层稳定的执行接口。CLI-Anything 帮我更快得到这个接口的第一版，skill-up 则逼着我证明 Agent 真的会用。

这三件事连起来以后，内部系统 Agent 化才不再是一次漂亮演示。它变成了一条可以反复验证的生产链：能力有边界，执行能追查，失败能归因，改完还能回归。

作者：AI产品零度，公众号：AI产品零度

本文由 @AI产品零度 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自作者提供