一旦人工智能智能体进而成长为开发的常见全新态势, 然而传统图形用户界面控制台居然变为自动化流程里起到阻碍前行作用的事物。在此情形之下, 腾讯云命令行界面V3适时出现, 而且作为专为人工智能智能体进行彻底重新构建的命令行工具。它凭借十五个全新制定出的命令、具备自我解释功能的双横线帮助、面向智能体的文档系统以及全部命令参数以双横线加上全英文“json”输出, 使得智能化体能够依靠自主性完成从环境创建一直进展到项目上线的整个连接起来的一系列操作, 切实做到“一直使用命令行界面进行操作, 零次使用控制台”！

为了进行Agent开发, 腾讯云推出了CLI V3, 它是一个针对AI Agent进行重新设计的命令行工具。

这个版本增添了 15 个顶层命令模块, 涵盖环境管理、数据库、用户权限、路由、域名、日志、AI 智能体等全部能力。如今, 一个云项目从创建直至上线的所有操作, 均能够在终端内达成, 无需打开控制台。

V3 做了以下几个重要改变：

为什么需要 CLI V3

我们留意到, 有越来越多的开发者, 在运用 Code、、等人工智能工具来作业，进而打造环境, 安排函数投身运转, 落实路由的设置, 而整个流程是交由 Agent 去执行的。

而是传统那种在依靠 GUI 构建起来的控制台, 对于 Agent 来讲并不具备友好性: 对于 Agent 来说没办法通过去点击按钮、也不存在能够读取其当前所观看页面之上的视觉反馈这种情况、同时依旧是无法进行处理弹窗确认这一行为。每回当遭遇到依靠 CLI 却覆盖不上的操作之时, Agent 必然就会停止操作, 等待人来进行介入处理。

针对 Agent , CLI 是一种更为适配的设计, 命令行的输入是结构化文本, 输出也是结构化文本, 对于 Agent 而言, 能够直接进行解析以及处理, 并不需要视觉理解, 命令能够进行组合, 也能够进行脚本化, 在多步骤的自动化工作流方面, 天然就很适合。

CLI V3版本所要解决的问题是, 完全面向AI Agent进行重新设计, 使得Agent能够走完全程。

15 个新命令：从环境创建到项目上线的完整覆盖

V3 新增了 15 个顶层命令模块：

同时呢, 对存量命令进行了系统性的整理, 命令风格从冒号分隔, 也就是 tcb :, 统一迁移成为空格分隔, 也就是 tcb fn , 这样更符合 CLI 惯例, 详细的迁移指南可以在文末的 V3 迁移文档中看到。

那就是说, V2 的这个时代, 原本那种得在“CLI 加上控制台”两者之间来来回回进行切换才能实现的操作, 于此时此刻而言, 全都能够在终端的范围里给完成掉了。

–help：命令的自解释能力

在 CLI V3里所包含的每一条命令, 以及每一条子命令之上, 均内置有了 -h / –help 这样的参数, 而这些参数会输出关于该命令完整的用法说明, 以及参数列表, 还有示例。

这表明, 当Agent遭遇一个它并不熟悉的命令之际, 它无需去查看外部的文档, 仅仅直接通过tcb –help这个操作, 便能够获取到结构化的用法说明:

tcb fn –help

对于Agent而言, 存在这样一套零成本的命令发现机制, 首先通过tcb –help查看有哪些顶层命令, 接着借助tcb –help查看具体用法, 然后逐层进行探索, 并且不需要任何外部知识。

tcb docs：面向 Agent 的文档系统

Agent朝着进行开发之际, 常常极易寻觅不到准确无误的文档, 借助搜索引擎所获结果极易陈旧过时抑或不够精准。

要解决此问题, 我们于CLI V3版本里, 新增加了tcb docs命令, 以使Agent不用借助搜索引擎 , 能够直接于终端之中查询官方文档。

# 列出所有文档模块

tcb docs list

# 按路径读取指定文档

tcb docs read 云函数

tcb docs read

# 关键词全文搜索

tcb docs 微信支付

对 Agent 而言, 这构成了一个自主开展排查的闭合循环, 即碰到不晓得的知识时, 朝着 tcb docs 去查阅文档, 接着确认文档当中的内容, 而后执行后续相关操作, 此过程既无需人员进行介入, 也不需要去调用外部的搜索。

PS：tcb docs 无需登录即可使用。

–json 输出模式：对机器可读的输出

V3的所有子命令, 对于–json这个全局参数, 一概统一给予支持。一旦添加了此参数, 输出里面就不存在进度条, 不存在颜色编码, 不存在任何可供人类去阅读的修饰, Agent所获取到的是全然纯粹的那种结构化数据。

成功时：

{“”:”luke--test-new-”}

失败时：

“error”:{

“code”:””,

“”:”函数 ai-reply 不存在”,

“”:4

与 V3 所定义的六个结构化退出码相配合, Agent 能够依据退出码直接去走对应的响应路径。

原本模糊不清的报错文本, 已不再是失败, 现在, 失败成为一个明确的信号, 一个具有确定性意义的迹象。Agent 无需借助语义理解, 来对未来下一步的行动进行猜测。

实战： Code + CLI V3 搭建智能客服工单系统

我们借助Code, 以及CLI V3, 构建起一个智能客服工单系统, 以此来验证V3的实际能力边界, 我们构建的是这样一个系统, 是用于验证其实际能力边界的系统。

该类项目把数据库涵盖其中, 如果是由四个云函数构成的, 那么 HTTP 路由、用户与权限管理、自定义域名以及 SSL 证书全套部署也都在项目范围内。整个过程借助 tcb 命令来完成, 控制台操作次数为 0 次。

6.1 Step 1：创建并激活环境

临时可信边界环境, 使用别名“--prod”, 并且, 还要加上“--”, 同时, 呈现为是“--yes”的状态, 以JSON格式输出。

把tcb环境用于卢克, 测试新的, 以json格式。

返回 { “”: “

luke--test-new-” }。

进行全局默认环境设定以后, 后续全部命令都不用再次传入 –env-id啦。那V3的环境优先级是这样的: 全局配置小于 .json, 小于命令行 -e 参数, 而Agent在有切换需求的时候能够随时去覆盖。

6.2 Step 2：初始化数据库

工单系统需要三个集合：、、。

tcb db nosql \

–'

{“”:””,””:””,””:

“{\”\”:\”\”,\”\”:

{\”key\”:

请你提供完整准确的内容, 以便我能按照要求进行改写, 当前你给出的这个部分不太清晰完整呀。

{\”\”:1,\”\”:-1}, 且它的 \”name\” 是 \”_1\”。

}”}

’ \

–json

一旦命令返回那种退出码 1 的情况, Agent 就会自动去切换命令格式然后重试, 退出码体系在这儿直接起到发挥了作用。

6.3 Step 3：部署云函数

项目包含四个云函数，三个事件函数，一个 HTTP 函数：

tcb fn - –json

tcb fn - –json

tcb fn reply- –json

TCB运行在函数网络中, 人工智能回复, 指向当前目录下, 选择是, 以JSON格式输出信息字符。