一.CLI
1.背景
2025 年底到 2026 年初,⾏业⾥对 MCP 的态度发⽣了⼀次集体转向。Vercel CEO rauchg 在 X 上直接说:"CLIs are the de-facto MCPs for agents"――CLI 就是事实上的Agent ⼯具协议.Perplexity CTO、Y Combinator 掌舵⼈ Garry Tan 也在同⼀时期公开站了 CLI 这边。中⽂社区更直接,有⼈甚⾄喊出了"MCP 已死"。微软在 2025 年先做了 Playwright MCP Server,作为浏览器⾃动化的 Agent ⼯具接⼝。功能完整,社区也接受了。然后微软⾃⼰⽤了⼀段时间,发现了⼀个没法忽略的问题:⼀个 15 步的浏览器⾃动化会话,MCP ⽅式要消耗约 114,000 tokens做 15 步浏览器操作。
于是微软在 2026 年初推出了https://github.com/microsoft/playwright-cli,专⻔为 Agent 设计。同样的 15 步任务,CLI ⽅式只需约 27,000 tokens。同⼀个团队,同⼀个产品,token 消耗差了 4 倍以上。
⼤⼚集体押注CLI
Google:Gemini CLI → Antigravity CLI
- 2025年6⽉25⽇,⾕歌正式发布开源 AI 代理命令⾏⼯具 Gemini CLI,采⽤ Apache 2.0 协议,将Gemini ⼤模型能⼒直接集成到终端中。个⼈⽤⼾免费额度为每分钟 60 次、每⽇ 1000 次请求。
- 2026年5⽉19⽇,Google I/O ⼤会上宣布将 Gemini CLI 整合进 Antigravity CLI,作为其"Agent-first"开发平台的⼀部分。
- 2026年6⽉18⽇起,Gemini CLI 和 Gemini Code Assist IDE 插件将停⽌为个⼈免费⽤⼾提供服务,⽤⼾被引导⾄ Antigravity CLI。
分析称,Google 此前拥有 Code Assist、Gemini CLI、AI Studio 等多个重叠⼯具,Antigravity 是
"清理⾏动"------赌注是未来不是 IDE 中的⾃动补全,⽽是"成群结队的 Agent 在桌⾯、终端、
SDK 和 Google Cloud 中并⾏运⾏重构、基础设施变更和代码审查"。
Microsoft:押注 Copilot CLI
- 2026年5⽉,据报道微软计划缩减⼯程师对 Anthropic Claude Code 的使⽤,推动开发者转向⾃⼰的 GitHub Copilot CLI,并将其作为主要的"agentic command line interface tool"。
- 微软⾃ 2025 年 12 ⽉起向员⼯提供 Claude Code 访问权限,数千名员⼯(包括⽆编程经验的项⽬经理和设计师)开始使⽤。但微软现计划移除⼤部分 Claude Code 许可证,尤其是在 Experiences+ Devices 部⻔。
- 微软 Experiences + Devices 部⻔执⾏副总裁 Rajesh Jha 在内部备忘录中表⽰:"当我们同时提供
- Copilot CLI 和 Claude Code 时,我们的⽬标是在真实⼯程⼯作流中快速学习、基准测试,并理解什么最能⽀持我们的团队。"尽管缩减 Claude Code 使⽤,Anthropic 的 AI 模型仍将通过 Copilot CLI 继续提供。
飞书:Lark CLI 开源
- 2026年3⽉28⽇,⻜书官⽅命令⾏⼯具 Lark CLI v1.0.0 正式开源,基于 MIT 协议。
- 通过命令⾏即可调⽤⻜书开放平台 2500+ API,覆盖消息、⽇历、⽂档、多维表格、邮箱、任务、会议等 11 个业务领域。
- 提供 200+ 命令和 19 个 Agent Skills。GitHub 仓库显⽰后续扩展⾄ 26 个 AI Agent Skills。
- ⽀持 Claude Code、Codex、Cursor 等主流 AI ⼯具接⼊。
背景:2026 年初 OpenClaw 爆红后(两个⽉ GitHub 星标突破 25 万),⻜书于 3 ⽉ 6 ⽇率先上线OpenClaw 官⽅插件,随后于 3 ⽉ 28 ⽇开源 Lark CLI,将整套办公能⼒直接开放给 AI 调⽤。
钉钉:钉钉 CLI 开源
- 2026年3⽉27⽇,钉钉 CLI 开源项⽬上架 GitHub,以 Apache-2.0 协议开源。⾸批开放 AI 表格、⽇历、⽇志、待办、机器⼈、通讯录、DING 消息、考勤、开放平台⽂档、⼯作台共 10 项核⼼产品能⼒。
- 原⽣⽀持 Claude Code、Cursor、Qoder 等主流 AI 编程与 Agent 执⾏环境。
- 这是国内⾸个⾯向 AI Agent 开源全产品能⼒的国⺠级应⽤。
- 此前 3 ⽉ 17 ⽇,阿⾥巴巴发布企业级 AI 原⽣⼯作平台"悟空",并宣布钉钉已完成全⾯ CLI 化,
- 为 AI 重写底层代码。
钉钉 CTO 朱鸿表⽰:"我们希望每⼀个 AI Agent,都能像调⽤系统命令⼀样⾃然地调⽤钉钉。开源
是钉钉对全球开发者社区最直接的承诺。"
企业微信:企业微信 CLI 开源
- 2026年3⽉30⽇,腾讯公关总监张军宣布,企业微信 CLI 开源项⽬正式上架 GitHub。
- 开放消息、⽇程、⽂档、会议、待办、通讯录、智能表格七项核⼼能⼒。
- ⽀持 Claude Code、Codex、WorkBuddy、QClaw 等主流 AI Agent 直接调⽤。
⾏业观察:钉钉、⻜书、企业微信在三天内相继开源 CLI,头部办公平台正在争夺同⼀个未来------成为 AI Agent 的⾸选⼊⼝。
2.什么是CLI
GUI(图形⽤⼾界⾯)
**定义:**GUI 的全称是 Graphical User Interface(图形⽤⼾界⾯),它是⼀种通过图形化元素(窗⼝、图标、按钮、菜单)与⽤⼾进⾏交互的操作界⾯,⽤⼾⽆需记忆任何⽂本命令,凭直觉即可完成操作。
- 交互主体:⼈类(普通⼤众),包括⾮技术⼈员、⽇常办公⽤⼾,甚⾄⼉童。
- 交互⽅式:⿏标和⼿指,通过点击、拖拽、滑动等物理⼿势直接操纵屏幕对象。
- 输出设计:图形化输出,包含窗⼝、图标、⾊彩、动画、进度条等丰富的视觉元素,所有信息均经过视觉化包装以⽅便⼈眼快速识别。
- 设计⽬标:降低⻔槛,实现"所⻅即所得",让⽤⼾⽆需培训或学习即可上⼿,追求极致的易⽤性和直观性。

传统 CLI(命令⾏界⾯)
**定义:**CLI 的全称是 Command Line Interface(命令⾏界⾯),它是⼀种通过输⼊⽂本命令与操作系统进⾏交互的界⾯,⽤⼾需要在终端中敲⼊精确的指令并回⻋执⾏,以获得对计算机的精细控制。
- 交互主体:⼈类(专业⼈⼠),包括程序员、系统管理员、运维⼯程师、极客爱好者。
- 交互⽅式:键盘输⼊,⽤⼾逐字敲⼊命令(如 ls -la 、 findstr "error"test.log ),按回⻋执⾏,每个字符必须精准⽆误。
- 输出设计:⽂本⽇志输出,包含颜⾊⾼亮、进度条、状态提⽰和写给⼈看的情感化报错信息(如"哎呀,端⼝被占了"),所有内容均⾯向⼈眼阅读。
- 设计⽬标:提⾼效率,⽀持批量处理、管道组合、脚本⾃动化,让专业⼈⼠能以极⾼的速度完成复杂任务,同时占⽤极少的系统资源。

Agent CLI(智能体命令⾏界⾯)
定义: Agent CLI 的全称是 Agent-oriented Command Line Interface(⾯向智能体的命令⾏界⾯⼯
具),它是⼀种专⻔为 AI 智能体(⼤语⾔模型、⾃动化程序)设计的命令⾏⼯具接⼝,通过 API/函数调⽤的⽅式让机器⾃主完成操作并返回结构化数据。
- 交互主体:AI 智能体(⼤语⾔模型、⾃动化 Agent 程序),⼈类仅作为⽬标下达者,不直接参与具体指令的敲击。
- 交互⽅式:API / 函数调⽤,由程序⾃动发起,传⼊精确参数,整个过程⽆需⼈类⼿动介⼊,完全由机器⾃主完成。
- 输出设计:结构化数据输出(如 JSON、XML、纯机器可读⽂本),不带任何颜⾊、进度条、情感化⽂字或冗余装饰,所有内容均为⾯向机器解析的精简信息。
- 设计⽬标:节省 Token、消除歧义,让 AI 能以极低的算⼒成本、最⾼的解析速度和最强的稳定性去调⽤操作系统或外部⼯具(如操作软件、控制浏览器、调⽤ API),⽀持⾃主决策(如根据错误码⾃动重试)。

体验下Agent CLI
1. 我们使⽤playwright的CLI版本来感受下使⽤CLI 操控浏览器,官⽹地址 Coding agents | Playwright Pythongithub GitHub - microsoft/playwright-cli: CLI for common Playwright actions. Record and generate Playwright code, inspect selectors and take screenshots. · GitHub),⾸先我们进⾏安装
cpp
npm install -g @playwright/cli@latest

2. 检查安装是否成功,正常打印帮助信息说明安装成功

3. 操控浏览器打开B站
cpp
playwright-cli open https://www.bilibili.com/ --headed
4. 获取⻚⾯快照信息
cpp
playwright-cli snapshot
5. 找到输⼊框的id,定位搜索⻚输⼊鹏哥C语⾔检索

cpp
playwright-cli fill e36 "鹏哥C语⾔"
playwright-cli press Enter
6. 选择标签⻚截屏
cpp
playwright-cli tab-select 1
playwright-cli screenshot --full-page --filename=full-page.png
7. 看下效果

8. 安装技能,打开Trae,在终端中给项⽬安装技能
cpp
playwright-cli install --skills

9. 使⽤技能调⽤
cpp
使⽤项⽬下⾯的playwright-cli的技能打开b站,搜索鹏哥c语⾔,搜索结果⻚⾯整个截图保存,⽂件名是full-page-agent.png

10. 查看调⽤过程


3.为什么 LLM 天⽣适配 CLI?
1. ⺟语训练
⼤型语⾔模型的训练语料包含了互联⽹上的海量⽂本------Stack Overflow、GitHub Issues、技术博
客、man pages、Shell 脚本、终端交互记录。这⾥⾯有数⼗亿⾏ CLI 命令和对应的输出。模型在训练过程中"⻅过"了⼤量类似的模式:
cpp
root@iZ2vc1xqd5xvvfp61r6jdwZ:/# ls -l
total 68
lrwxrwxrwx 1 root root 7 Apr 21 2022 bin -> usr/bin
drwxr-xr-x 4 root root 4096 Aug 12 06:11 boot
drwxr-xr-x 5 root root 4096 Dec 11 2025 data
drwxr-xr-x 19 root root 4020 Aug 17 19:22 dev
drwxr-xr-x 113 root root 4096 Aug 23 06:32 etc
drwxr-xr-x 2 root root 4096 Apr 18 2022 home
lrwxrwxrwx 1 root root 7 Apr 21 2022 lib -> usr/lib
lrwxrwxrwx 1 root root 9 Apr 21 2022 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 9 Apr 21 2022 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 10 Apr 21 2022 libx32 -> usr/libx32
drwx------ 2 root root 16384 May 15 2023 lost+found
drwxr-xr-x 2 root root 4096 Apr 21 2022 media
drwxr-xr-x 2 root root 4096 Apr 21 2022 mnt
drwxr-xr-x 6 root root 4096 May 21 20:32 opt
dr-xr-xr-x 219 root root 0 May 20 22:51 proc
drwx------ 10 root root 4096 Aug 25 09:55 root
drwxr-xr-x 36 root root 1180 Aug 25 09:55 run
lrwxrwxrwx 1 root root 8 Apr 21 2022 sbin -> usr/sbin
drwxr-xr-x 7 root root 4096 Jul 8 00:26 snap
drwxr-xr-x 2 root root 4096 Apr 21 2022 srv
dr-xr-xr-x 13 root root 0 May 20 22:51 sys
drwxrwxrwt 12 root root 4096 Aug 25 09:56 tmp
drwxr-xr-x 14 root root 4096 Apr 21 2022 usr
drwxr-xr-x 14 root root 4096 Dec 11 2025 var
将 CLI 称为 AI 的"⺟语"毫不夸张。AI 理解 git log --oneline 远⽐理解⼀张模糊的按钮截图
要顺畅。
2. ⽂本输⼊⽂本输出和 LLM 的⼯作⽅式天然匹配
GUI 对 AI 很⿇烦------要"看懂"按钮位置、颜⾊、弹窗,依赖视觉模型的模糊判断,界⾯⼀改就失效。CLI 则是确定性⽂本交互,输⼊即指令,输出即结果。AI 操作 CLI 是精确的坐标战,操作 GUI 是猜盲盒,前者天然更可靠。
3. CLI 的结构化程度刚好适合模型⽣成
CLI 命令虽然有语法,但⽐编程语⾔简单得多:
cpp
command [options] [arguments]
- 命令名是动词
- 选项是副词/修饰
- 参数是宾语
这种结构接近⾃然语⾔的"动宾短语",LLM ⽣成起来⾮常⾃然。同时它⼜有明确的约束( --
help 、man page、退出码),不像⾃由⽂本那样完全开放,也不像完整代码那样需要复杂上下⽂。
4. CLI 反馈是机器可读的,容易形成闭环
CLI 程序的反馈通常包括:
- 标准输出(stdout)
- 标准错误(stderr)
- 退出码(exit code)
这些都是轻量、可解析、可判断成败的信号。AI 可以据此决定下⼀步:
- 退出码为 0 → 成功,继续
- 退出码⾮ 0 → 读取 stderr,修正命令
- stdout 为空 → 换⼀种查询⽅式
相⽐之下,GUI 的反馈往往藏在界⾯状态⾥:按钮变灰、弹窗出现、⻚⾯跳转。AI 需要"看"屏幕或
者读取⽆障碍树才能理解,成本⾼得多。
5. 极致的上下⽂性价⽐(Token 效率)
CLI 返回短 ID(如 a1b2c3 )和结构化 JSON,相⽐描述 GUI ⻚⾯的整棵 DOM 树或⻓串像素坐标,Token 消耗可节省数倍。这使得 AI 能在有限的上下⽂窗⼝中塞⼊更⻓的历史轨迹和更复杂的推理链。
4.CLI 对⽐GUI的优势
⼀句话概括:GUI 是给⼈点的,CLI 是给机器/AI 说的
1. 可组合性
CLI 的管道机制( | )让 AI 可以将不同⼯具的输出⽆缝衔接,例如 playwright-cli
snapshot | jq '.buttons' | xargs -I {} playwright-cli click {} 。这种"原⼦化能⼒组合"是 GUI 永远⽆法实现的,AI 可以像搭积⽊⼀样动态编排⼯作流。
2. 极致的效率
在批量处理、重复性操作、复杂调试等场景中,CLI 命令组合的执⾏速度通常⽐ GUI 快数倍甚⾄⼀个数量级。对于需要⾼频调⽤⼯具的 AI Agent ⽽⾔,这种效率优势会被成倍放⼤。
3. 资源占⽤低
TUI(终端界⾯)应⽤内存占⽤通常在 10-50MB,⽽功能完整的图形 IDE(如 IntelliJ 系列、VS Code搭配⼤型插件时)可能达到 500MB 甚⾄更⾼。这对于运⾏在容器、服务器等资源受限或远程环境中的AI Agent 来说,是决定性的优势
5.CLI 对⽐MCP的优势
1. 成本悬殊
在典型⻓会话场景中,CLI ⽅式的 Token 消耗可⽐ MCP 降低 4 倍以上(如微软 Playwright 实测案
例:15 步操作,MCP 消耗约 114,000 Token,CLI 仅需约 27,000 Token)。两者在⻓期运⾏中的成本差距可达数⼗倍。
2. 可靠性更强
MCP 依赖⻓连接和集中式⼯具 Schema,在⽹络不稳定或⼯具集庞⼤时容易出现连接超时或中断;
CLI 采⽤"每次调⽤独⽴执⾏"的模型,天然更稳健,容错性更好。
3. ⼯作流逻辑更⾃然
CLI 允许 AI 像⼈类⼀样"先跑 --help 探索参数,再执⾏具体命令";⽽ MCP 要求 AI 在对话开始时就把整本"⼯具说明书"(Schema)全部加载到上下⽂中,既浪费 Token,⼜限制了灵活性。
7.CLI VS GUI VS MCP
我们通过⼀个表格整体⼀览下
结论:
- AI Agent 时代: CLI 正在成为主流,因为它是最经济、直接的AI操作⽅式。
- 标准互操作: MCP 仍是⼀种标准形式。
- ⼈类互操作: GUI 仍是⼈的⾸选。
8.CLI Agent 调⽤分层
现在的 CLI常⻅分类如下:
- 传统 CLI:git、docker、GitHub CLI这是最经典的 CLI 形态,如 git 、 docker 、 curl 等。它们的核⼼定位是"专注做好⼀件事",并依靠强⼤的"管道"机制与其他⼯具⾃由组合。这类 CLI ⽣态成熟、数量庞⼤,是技术⼈的基础⼯具箱,但⻔槛在于需要⽤⼾硬记命令语法。它的交互⽅式是⼈⼿动输⼊命令,系统执⾏。
- ⾯向 Agent 的⼯具型 CLI:Playwright CLI、⻜书 CLI、企微CLI
- 典型CLI:AI 时代演进出的新⼯具形态,Playwright CLI 是典型代表。它虽保留着经典 CLI 的命令⾏语法,但设计初衷并⾮为了⽅便⼈类记忆,⽽是专为 AI Agent(如 Claude Code、Copilot)提供原⼦化的浏览器⾃动化能⼒。其核⼼特征在于:输出⾼度精简以节省 Token、优先保证机器可读性,并⽀持"技能"动态注⼊来拓展 Agent 的⼯具上下⽂。它既可以被⼈⼿动使⽤,但更常⻅的定位是作为 Agent 背后的"⾼效执⾏⼿",连接了传统命令⾏⽣态与 AI 应⽤场景。
- 云服务型CLI : 云服务普及,出现了如 企业微信 CLI 、 ⻜书 CLI 等平台型⼯具。它的定位是将平台的全部 API 能⼒封装成统⼀的命令⾏接⼝,最⼤的价值在于统⼀鉴权,免去了开发者⼿动拼接 HTTP 请求的繁琐。这类⼯具既⽀持⼈使⽤,也易于被⾃动化脚本调⽤。
- Agent 型 CLI:Claude Code、Codex CLI、Gemini CLI
新兴的 AI 原⽣形态,以 Claude Code 、 Codex CLI 和 Cursor 等为代表。它们彻底
改变了交互逻辑:⽤⼾⽆需死记硬背任何命令⾏,只需⽤⾃然语⾔描述意图,AI Agent 便会⾃主规
划并执⾏多步骤任务。它们具备强⼤的上下⽂理解能⼒,能极⼤降低使⽤⻔槛。
a.传统的CLI调⽤的分层如下

链路:精确命令 --> 交互界面 CLI --> 具体的工具软件执行
- 是人直接写精确指令 (比如
ls、cd)交给终端 CLI,CLI 调用底层工具。- 特点:人做思考、人写命令,CLI 只负责执行,没有 AI。
- 例子:你 ssh 登录服务器手动敲
ls -l。
b.⾯向 Agent 的⼯具型 CLI调⽤分层

链路:自然语言 → Agent (LLM) →(自主决策)→ CLI
- 人只说大白话(自然语言),大模型 Agent 自己思考、自主决策,直接输出 CLI 命令执行。
- 特点:Agent 直接生成命令,CLI 就是它的执行工具;Agent 和 CLI 紧耦合。
- 例子:Cursor Agent、Claude Code 看懂你的需求,自动生成 shell 命令操作文件。
c.平台型 CLI调⽤的分层如下

链路:自然语言 → Agent (LLM) → CLI → 云服务
- 自然语言交给 Agent,Agent 调用 CLI,CLI不再操作本地机器,而是调用远端云服务接口。
- 特点:CLI 是云平台的网关,能力在云端,不是本地工具。
- 例子:飞书 CLI、钉钉 CLI,通过命令行调用飞书 / 钉钉云上的能力。
d.Agent 型CLI调⽤的分层如下

链路:自然语言 → 交互界面 CLI → Agent (LLM) 自主决策,三路输出:SKILL 固化流程 / CLI 本地工具执行 / MCP 外部接口
- CLI 作为入口交互层,里面内置 Agent。Agent 有三类执行能力:
- SKILL:写死、预定义好的固化任务流程
- CLI:本地终端工具执行
- MCP:调用外部第三方接口
- 特点:Agent 在 CLI 内部,能力多元化,本地 + 预制技能 + 外部 API 全都能调用。
对比记忆:
- 传统 CLI:人想命令,机器执行(无 AI)
- 工具型 CLI Agent:人说人话,AI 生成本地 CLI 命令执行
- 平台型 CLI Agent:人说人话,AI 通过 CLI 调用云上服务
- Agent 型 CLI:CLI 本身内置 Agent,可同时跑预制技能、本地命令、外部 MCP 接口
9.常见的Agent CLI产品或者框架
| 产品 / 框架 | 简介 | 地址 |
|---|---|---|
| Hermes Agent | 由 Nous Research 开发,具备持久记忆和自动化技能创建能力的自学习 CLI Agent。支持超过 300 种模型,并能在多个平台(如 Telegram、Slack)运行。 | https://github.com/NousResearch/hermes-agent |
| TraeCode CLI | 运行在本地终端里的编码智能体。 | https://docs.trae.cn/cli_get-started-with-trae-code-cli-2 |
| Claude Code (Anthropic) | Anthropic 推出的明星产品,能深度理解代码库,具备强大的规划和执行能力。它被设计为完全自主,能读取文件、执行命令、管理 Git 工作流 | https://www.anthropic.com/claude-code |
| Codex CLI (OpenAI) | OpenAI 的官方终端 Agent。用 Rust 编写,性能出色,支持自主模式(--goal),能在无人监督的情况下长时间运行 | https://github.com/openai/codex |
| Gemini CLI (Google) | Google 出品的终端 Agent。由 Gemini 模型驱动,具备 100 万 token 的上下文窗口和多模态能力 | https://github.com/google-gemini/gemini-cli |
| OpenCode | 一个终端原生的编码 Agent,支持超过 75 种 LLM 提供商 | https://github.com/anomalyco/opencode |
| 飞书 CLI (lark-cli) | 飞书官方推出,为 AI Agent 原生设计,由 Go 语言编写,MIT 协议 | https://www.feishu.cn/feishu-cli |
| 钉钉 CLI | 钉钉官方 CLI | https://open.dingtalk.com/document/development/dingtalk-cli-performing-tasks-within |
| 企业微信 CLI | 企业微信官方 CLI | https://open.work.weixin.qq.com/help2/pc/21676 |
| OpenCLI | 一个能将网站、浏览器会话转化为确定性 CLI 接口的工具 | https://github.com/jackwener/opencli |
| browser-use | 火爆 GitHub 的开源 Python 库,让 AI Agent 直接操控浏览器完成任务 | https://github.com/browser-use/browser-use |
| Playwright CLI | 微软官方出品,专为 AI 编码智能体设计的浏览器自动化命令行工具。它通过高效的 Token 策略和基于技能(Skill)的架构,让智能体能够以极低的成本操控浏览器 | https://github.com/microsoft/playwright-cli |
| CLI-Anything | 为 AI 制造工具的工具 | https://github.com/HKUDS/CLI-Anything |
10.怎么给 AI 写好⼀个 CLI
1. ⽀持静默模式
任何 Agent 可能⾃动化的命令,都不应依赖交互式 prompt。
推荐做法:
- ⽀持 --yes 、 --force 、 --quiet 、 --no-input
- 检测⾮ TTY 时⾃动禁⽤交互
- 必填项都能通过 flag、stdin、配置⽂件或环境变量传⼊
原因很直接:当⼀个 Agent 启动⼦ Agent,再由⼦ Agent 调起 CLI 时,中间通常没有办法把"请输⼊y/n"回传到最上层⽤⼾。
2. --help 要写成"三合⼀⽂档"
别只写 Usage: myctl deploy flags ,每个参数的作⽤、何时⽤、默认值都要写。
为什么对 Agent ⽣死攸关?
Agent 读 help 本质上是⼀次 "⼯具发现"。如果 help 信息不全,Agent 就会猜,⼀猜就错,⼀错就反复试,token 和钱⼀起烧。
更关键的是: Help ⽂本是 离线可⽤ 的,不需要⽹络、不需要 MCP 协议、不需要 schema 协商------这正是 CLI 相⽐ MCP 在成本上的巨⼤优势。
在"学⽣笔记→Word"案例中体现为:
Agent 运⾏ txt2word --help 后,看到:
cpp
--input <file> 输⼊的⽂本⽂件(必须)
--output <file> 输出的 Word ⽂件路径(默认:同⽬录/output.docx)
--format [basic|academic] 排版⻛格(默认:basic)
Agent ⽴刻知道:⽤⼾没给输出路径?⽤默认的。
笔记是学术内容?可以加 --format academic 。没有这个 help,Agent 只能先试跑,报错再改,效率极低。
3. ⽂档⽀持渐进式发现
Agent 通常不会先读完整⽂档,⽽是这样探索:
tool --help
tool subcommand --help
看⼀两个例⼦再尝试执⾏。
4. --dry-run 可安全重试,是 AI 的安全⽹
删除、写⼊操作必须先 dry-run,返回"将要做 X 条修改",确认后再真正执⾏。
为什么对 Agent 尤其必要?
Agent 靠概率推理,有时候它以为"删除过期数据"是正确的,但可能因为⽇期理解偏差,匹配到当
前数据。
dry-run 给了⼈类(或上层审核流程)⼀个 拦截机会。
Google gws 甚⾄把 dry-run 写死在技能规则⾥------说明⼤⼚已经把它当作强制契约。
在学⽣笔记案例中的体现:
假如 Skill ⾥有⼀个"删除旧笔记"步骤。Agent 执⾏:
cpp
clean_notes --older-than 30d --dry-run
返回:
将删除以下⽂件: 2024-03-01_化学.txt 、 2024-03-02_化学.txt ... 共 12 个⽂件。未做任
何实际修改。
你⼀看:"等等,30 天太激进了,改成 10 天吧。"
没有 dry-run,删除就真的发⽣了。
5. 错误信息必须包含"缺什么 + 怎么修",要能指导下⼀步修复
cpp
Permission denied 对 Agent 是死路。要同时给出缺少的权限和申请命令。
为什么这是硬性要求?
Agent 没有"⾃⼰去搜⽂档"的能⼒(除⾮你给它联⽹搜索⼯具,但那样更慢更贵)。
错误信息必须 ⾃包含修复指令,Agent 才能闭环。
在学⽣笔记案例中的体现:
当 Agent 尝试调⽤ MCP 发微信⽂件时,返回:
cpp
Error: missing permission `wechat:send:file`
Fix: run `study-agent auth add --scope wechat:send:file`
Agent 看到后,可以⾃动执⾏修复命令,然后重试。
如果没有这个提⽰,Agent 会卡住,或者傻傻地反复试同⼀个操作。
6. 返回结构化数据
如果命令返回的是数据,⽽不是纯展⽰信息,就应该提供稳定的机器可读格式。
推荐做法:
- 提供 --json
- 成功结果写⼊ stdout
- 警告、进度、错误写⼊ stderr
- 输出字段命名稳定,不要今天叫 id 明天改成 resource_id
否则模型只能靠脆弱的⽂本解析来猜。
以JSON为例,json可解析,Agent 能直接提取字段(不像 table 要猜列对⻬)。
在学⽣笔记案例中的体现:
假设 Agent 要查询过去⼀周⽣成的所有 Word ⽂档,然后删除空⽂件。
cpp
list_docs --since 7d --output json --filter "size=0"
返回json
cpp
{"files": [{"name": "empty.docx", "size": 0}]}
Agent 直接解析,然后调⽤删除。
如果没有过滤和 JSON,Agent 拿到⼀⼤段 ls -l 的⼈类友好表格,要先费⼒提取、再⽐较⼤⼩,
既费 token ⼜容易出错。
7. 输出要有边界
⼀下⼦输出500 ⾏⽇志,Agent 会把这 500 ⾏⼀股脑放进上下⽂窗⼝,容易找不到重点。
推荐做法**:**
- 默认分⻚/限量
- ⽀持 --limit 、 --page 、 --since
- 截断时告诉⽤⼾如何继续缩⼩范围
这不是"抠 token",⽽是让模型把注意⼒放在真正重要的信息上。
11.实战-Cursor CLI使⽤

1. 我们进⼊cursor cli官⽹ https://cursor.com/cn/cli,找到我们适合的系统完成下载,cursor ide的
详细使⽤我们会放到后⾯的章节,⼤家主要感受下命令⾏的使⽤

- irm
是 Invoke-RestMethod 的别名,⽤于发送 HTTP/HTTPS 请求并⾃动解析返回的内容(如
JSON、XML 或纯⽂本)。在这⾥,它会向https://cursor.com/install?win32=true发送 GET 请求,并返回该⻚⾯的响应内容(通常是⼀个 PowerShell 脚本)。
- iex
是 Invoke-Expression 的别名,⽤于将接收到的字符串当作 PowerShell 命令来执⾏。
安装效果


2. 下载完成后我们⾸先创建⼀个⽬录
cpp
mkdir cursorcli
3. 输⼊Agent命令进⼊交互模式,我们输⼊信任⽬录,如果没有登录会提⽰登录

4. 我们输⼊我们的需求

bash
/plan 请⽣成⼀个现代企业官⽹的落地⻚,保存为 landing.html。
要求如下:
【视觉⻛格】
- 极简现代⻛格
- ⻚⾯采⽤⼀⻚式滚动设计,包含4个清晰的模块区块
- 字体使⽤系统默认字体,排版疏朗⼤⽓
【功能模块】
1. 顶部导航栏
- 左侧为品牌Logo(显⽰"⽐特科技")
- 右侧导航菜单:⾸⻚、产品、关于我们、联系我们
- 导航栏在滚动时背景由透明变为⽩⾊(带阴影),有平滑过渡效果
2. Hero主视觉区
- ⼤标题:"引领未来的智能解决⽅案"
- 副标题:"⽤创新技术驱动企业数字化转型"
- 两个CTA按钮:"开始体验"(深⾊主按钮)和"了解更多"(边框按钮)
- 背景使⽤渐变蓝⾊系,带有动态流动的⼏何装饰(⽤CSS动画实现)
3. 产品/服务展⽰区
- 标题:"我们的核⼼服务"
- 3个服务卡⽚横向排列,每个卡⽚包含:图标、标题、简短描述
- 卡⽚有悬停上浮和阴影加深的动效
- 三个服务分别为:
- ☁ 云计算服务:弹性可扩展的云端基础设施
- 🤖 AI智能分析:数据驱动的商业洞察
- 🔒 安全合规:企业级数据安全防护
4. 公司介绍区
- 左侧为⼀段关于公司的⽂字描述(⽤lorem ipsum占位)
- 右侧展⽰⼀组数据指标:客⼾数500+、服务覆盖30+城市、团队100+⼈
- 数据指标数字在进⼊视⼝时有数字递增动画
5. ⻚脚
- 包含版权信息、隐私政策、使⽤条款链接
【技术要求】
- 所有代码注释请使⽤中⽂
- ⻚⾯需响应式(适配移动端和桌⾯端)
- ⽣成完成后告诉我如何打开使⽤

经过⼀段时间分析后,会⾸先⽣成计划

5. 我们审核下计划看是否有问题,没有问题,直接执⾏

6. 执⾏过程会分步骤⼀步步完成

7. 如果中间有⾼级权限诉求,会询问你

8. 我们的企业落地⻚就⽣成好了,当然有问题我们也可以再次提出来进⾏修正。

9. 如果效果通过了,我们可以使⽤agent的命令⾏来完成代码审核, -p 是 Cursor CLI 中⼀个核⼼参数,全称是 --print (或理解为 --non-interactive 模式)。它的核⼼作⽤是让 Agent在 "⾮交互式/⽆⼈值守"模式下运⾏, --force 标志允许智能体⽆需确认,直接修改⽂件。
bash
agent -p --force "请对 landing.html 进⾏代码质量审查。检查规范(var/命名/未使⽤)、性
能(滚动防抖/动画/重排)、安全(eval/innerHTML)、可维护性(重复代码/魔法数字/函数⻓度)、可
以访问性(alt/语义标签)。输出Markdown格式报告,写⼊landing-review.md,按🔴严重/🟢警告/🟣
建议分级,标注⾏号和修复建议。"
10. 审核出来问题,我们可以使⽤命令⾏模式进⾏修复,修复完成后我们对功能再进⾏下检查
bash
cursor-agent -p --force --output-format stream-json "根据 landing-review.md 中的
审查报告,修复 landing.html 中所有🔴严重和🟢警告级别的问题,保持原有功能和样式不变"

11. 我们可以agent --help来看具体的命令进⾏使⽤,当然更多的是这些命令是给Agent观看后使⽤
的。官⽅⽂档 Cursor 命令行界面 | Cursor Docs。如果觉得cursor访问⽹络不太顺利,Trae也有对应的cli版本快速开始

二.⼤模型的幻觉
模型不会错么?
1.什么是幻觉
⼤模型的"幻觉"(hallucination)是指它⽣成的内容看似合理,但实际上是错误、虚构或与事实不
符的现象,也就是⼤家常说的⼀本正经的胡说⼋道。
我们来看个例⼦,可以看到汤⽼师变成鹏哥了,⽽且说的振振有词

值得注意的是,幻觉并不总是坏事。在创意写作、头脑⻛暴等需要发散性思维的场景中,这种"创造性"是优点。但在需要事实准确性、可靠性的场景(如医疗、法律、⾦融、代码⽣成)中,幻觉就是致命的缺陷。
2.常⻅的幻觉
LLM幻觉主要表现为模型⽣成与真实世界事实不符或偏离⽤⼾指令的内容
- 事实性幻觉:编造不存在的历史事件、⼈物关系、统计数据等。
虚构事实: 编造不存在的书籍、论⽂、⼈物、事件或数据。例如,当被问及"请引⽤三本关于
南极洲古代⽂明的学术著作"时,它可能会编造出看似真实的书名、作者和出版社。
提供错误信息: 对已知的事实给出不准确的描述。例如,声称"爱因斯坦获得了诺⻉尔数学
奖"(事实上诺⻉尔奖没有数学奖项,他因光电效应获得了物理学奖)。
- 忠实性幻觉:没有遵循⽤⼾指令,⽐如要求"总结⽂档"却添加了原⽂没有的观点,或是在推理中遗漏了关键条件。
指令不⼀致: 不遵循⽤⼾的具体要求,答⾮所问或过度发挥。
上下⽂不⼀致: 在⻓⽂本⽣成中,后⽂与前⽂信息⽭盾。例如,前⽂提到"市场占有率
10%",后⽂却说"市场占有率50%"。
3.为什么会有幻觉
1. ⽣成式模型的本质:基于概率的预测
语⾔模型并不会验证"事实",只会⽣成最可能的⽂本
由于语⾔模型的⽬标是最⼩化预测误差,⽽不是确保内容的真实性,它追求的是概率上的"像不
像",⽽⾮逻辑上的"真不真",因此即使它⽣成的信息,统计上看似合理,实际上可能是错误的。
例如,模型可能会⽣成⼀个学术理论的"引⽂",这个引⽂的格式完全正确,但实际上这个⽂献可能
并不存在。
2. 训练数据的局限性与偏差
⼤模型的知识来⾃于训练数据 ,但训练数据本⾝可能存在问题,例如:
数据不完整: 如果训练数据中没有包含某些领域的知识,模型只能根据已有知识"胡乱拼凑"出⼀个
合理的答案。另外模型训练完成后,知识就冻结了。对于之后发⽣的事件,它要么不知道,要么在试图"猜测"中产⽣幻觉。
**数据存在错误:**训练数据来⾃互联⽹,包含⼤量错误信息、偏⻅、⽭盾和虚构内容。模型学会了这些"噪⾳"。
3. 上下⽂限制
⼤模型在推理时通常会受到上下⽂窗⼝的限制, 例如最⼤上下⽂⻓度是 128k tokens,如果上下⽂窗⼝不够⻓,模型可能会丢失关键信息,导致⽣成的内容缺乏必要的事实⽀撑。
⽐如DeepSeek V3.2的上下⽂是128K

4.如何减少幻觉
⽬前并没有⼀种⽅案能 100% 消除幻觉,但可以通过以下⼯程和技术⼿段将其降低。
1. ⾼质量数据
我们可以对源头数据处理,确保模型使⽤更⼲净、更结构化、经过事实核查的数据集进⾏训练,减少模型从源头学到错误信息的机会。
举个例⼦:⽐如⼏乎所有⼤模型的都使⽤率互联⽹最⼤的数据源Common Crawl (互联⽹⽹⻚快照)


经过⾕歌清洗后 C4 (Colossal Clean Crawled Corpus)数据集 它是对 Common Crawl 原始数据进⾏极端严格清洗后的版本,也是后来包括 GPT-3、PaLM、Llama 等⼏乎所有主流⼤模型训练时最核⼼的"营养来源"。

2. 检索增强⽣成 (RAG)
这是⽬前对抗幻觉的主流架构。核⼼流程收到⽤⼾问题后,先去⼀个外部知识库(向量数据库、搜索引擎、企业⽂档库等)检索相关信息。将检索到的内容作为"上下⽂"连同原始问题⼀起提交给LLM。因为答案是"有据可查"的,所以可以⼤幅度降低幻觉。
3. 优化提⽰词
⽐如加⼊"如果你不确定答案,请说'我不知道',不要编造信息""请基于以下事实回答"等约
束。或者
在问题中附上相关背景或参考材料,限制模型回答的范围。

更改提⽰词后的效果

4. ⾃洽性检查
模型先⽣成答案,再⽤另⼀个提⽰(或同⼀个模型的不同实例)要求其"检查并批评⾃⼰的回答,找出可能不符合事实的部分",然后进⾏修正。
⽐如⼀些题⽬正向求解很困难,但是反向验证很容易,我们可以让它检查⾃⼰的结果


5. ⼯具调⽤
让模型学会在需要时主动调⽤外部⼯具来验证或获取信息,⽐如调⽤计算器做数学计算、调⽤代码解释器执⾏代码、调⽤搜索引擎查询最新事实。模型不再需要凭"记忆"回答数学题或时事。
我们来看个样例,我们询问DeepSeek 西安交通⼤学医学部教职⼯多少⼈,根据新闻可以看到明显联⽹的数据是更加准确的。
- a. 不开启搜索引擎

- b. 开启搜索引擎,可以看到⼈数的差异很⼤

c. 搜索时候的新闻

三.上下⽂窗⼝(Context Window)
1.概念
如果 LLM 是⼤脑,那么上下⽂窗⼝更像是它的"⼯作记忆"。
Context Window = AI 在⼀次请求中能处理的最⼤ Token 数量。
它是模型在本次⼯作过程中能够"看到"的全部内容;超过这个限制后,较早的内容可能⽆法被当前
推理看到,表现为"忘记前⾯"。
上下⽂窗⼝的范围包含:输⼊ + 输出。也就是说,提⽰词、历史对话记录,以及模型⽣成的回复,所有这些内容的 Token 总数加起来,不能超过上下⽂窗⼝的上限。
例如:⼀个 8k 上下⽂窗⼝的模型,你输⼊了 6k Token 的⽂本,那么理论上最多只能⽣成 2k Token 的回复。不过实际⽣成⻓度还会受到模型输出上限的限制;如果输出上限设置为 1k Token,那么最多只能⽣成 1k Token。
另外,模型本⾝是⽆状态的,它不会⾃动记住上⼀次对话。所谓"记住",其实是每次请求时都把相
关历史对话重新放到上下⽂窗⼝⾥。
2.为什么上下⽂重要?
1. 处理⻓⽂本的能⼒
窗⼝越⼤,模型⼀次性能处理的⽂本就越⻓。例如,在超⼤上下⽂窗⼝下,可以⼀次性处理《红楼梦》的⼤部分内容;⽽在较⼩窗⼝下,可能只能处理其中⼀部分章节。⻓合同、学术论⽂、代码仓库等也是同理。
2. 对话的连贯性
在聊天中,模型要记住之前聊过什么,就需要把之前的对话都放在窗⼝内。窗⼝越⼤,能容纳的历史对话轮次就越多,聊天就越连贯,越不容易"断⽚"。
3. 复杂任务的执⾏
对于"请根据这份 50 ⻚的报告,总结出三个要点并回答相关问题"这样的任务,需要整个报告都在窗⼝内,模型才能"看到"全部信息。
3.上下⽂的⼤⼩
| 模型系列 | 上下文窗口 (Tokens) | 来源 |
|---|---|---|
| DeepSeek-V3.2 | 128,000 | https://api-docs.deepseek.com/zh-cn/quick_start/pricing |
| kimi-k2-0905-preview | 256K | https://platform.moonshot.cn/docs/introduction#模型列表 |
| Qwen3-Max | 262,144 | https://help.aliyun.com/zh/model-studio/models?spm=a2c4g.11186623.help-menu-2400256.d_0_0_2.31223011OdPIRQ&scm=20140722.H_2840914._.OR_help-T_cn~zh-V_1 |
4.上下⽂窗⼝⾥⾯有什么?

Token 上下文窗口构成梳理
输入侧:模型 "看到" 的内容(全部计入上下文)
a. 系统提示词(System Prompt) 系统 / 开发者预设指令,对终端用户不可见,占用 token 窗口。
b. 用户提示词(User Prompt) 用户输入的内容,一般是业务需求、提问。
c. 对话历史 过往多轮问答记录(用户与模型历史消息)。
d. RAG 检索信息 外部知识库检索出来的参考材料,拼入上下文辅助回答。
e. 工具调用定义(Tool / Function Schema) 工具名称、功能说明、参数 JSON 结构,用于模型判断何时调用工具。
f. 工具返回结果 调用工具后得到的返回数据,会继续加入上下文供模型阅读。
g. 格式与结构开销 换行、特殊符号、Markdown 标签、角色标记、JSON 包装结构等; 这类不可见格式字符同样消耗 Token。
输出侧:模型 "生成" 的东西(也占用上下文)
a. LLM 的回答 模型输出的最终回复文本。
b. 思维链输出(Chain-of-Thought / Reasoning) 模型推理中间步骤。部分模型对外展示,部分隐藏; 只要是模型产生的推理内容,都会占用上下文窗口。

5.上下⽂窗⼝为什么有上限
1. 计算复杂度的"平⽅增⻓"
Transformer模型中的"注意⼒"操作需要计算序列中每⼀个token与其他每⼀个token之间的关系。
这使得计算复杂度与上下⽂⻓度 L 呈 O(L²) 关系。简单说,上下⽂翻倍,计算量会变成原来的4倍。当⻓度达到数万甚⾄百万时,计算量会达到天⽂数字。
如果序列⾥有 10 个字,每个字都要看其他 10 个字(包括⾃⼰),总共产⽣ 10 * 10 = 100次计算。如果序列增加到 100 个字,总互动就变成了 100 * 100 = 10,000 次。
2. 缓存瓶颈
模型在⽣成每个新token时,都需要记住之前所有token的"键"和"值"向量(即KV缓存),缓存的位置位于显存中。这个缓存的⼤⼩与 L 成正⽐。⼀个很⻓的对话可能需要⼏⼗GB的显存来存储缓存,远超单张GPU的承载能⼒。
3. 推理延迟增加
随着上下⽂变⻓,模型⽣成每个新 Token 时需要关注的所有历史 Token 变多,导致输出速度逐渐变慢。
6.超出上限会怎样?
1. 信息截断
⼤多数模型在处理超⻓输⼊时,会直接丢弃超出窗⼝的最前⾯内容,只保留最后能放⼊窗⼝的部分。
例如,⼀篇 50 ⻚的论⽂,窗⼝只能容纳 30 ⻚,模型会截断最前⾯的 20 ⻚,只保留最后 30 ⻚。此时如果问:"论⽂第 1 ⻚的核⼼观点是什么?"模型⽆法回答,因为它已经看不到第 1 ⻚。
2. "中间丢失"现象(Lost in the Middle)
模型往往对⽂档开头和结尾的信息利⽤较好,⽽对⽂档中间部分的信息利⽤较差。即使中间部分在上下⽂窗⼝内,模型也可能忽略其中的细节,导致回答中间部分相关问题时表现下降。这是⼀种常⻅的性能退化,但并⾮"⽆论问得多详细都⼀定忽略"。
3. 性能与响应异常
随着上下⽂变⻓,KV Cache 占⽤显存增加,推理延迟会显著上升。如果显存不⾜,系统可能报错,或者使⽤交换内存导致速度急剧下降。
原本秒回的请求,可能需要等待更⻓时间才能开始输出。
⽹⻚端如果⼀次性处理超⻓⽂档,可能因为传输、内存占⽤和界⾯