终端 Agent 工具难度 2⏱ 17 分钟工具
01Claude Code 入门
Anthropic 官方终端 Agent，原生支持工具调用、MCP、Skills 与 Hooks，2026 年生态最完整的 CLI Agent
Claude CodeAnthropic终端 AgentCLI入门
更新于 2026-04-22claude-code-overview
零基础理解 CLI Agent 是什么、和 IDE 插件 / 网页版的本质区别，以及为什么 2026 年成了主战场
内容摘要
**CLI Agent** 是把"AI 编程助手"装进**终端命令行**里的那一类工具。它不是聊天机器人，也不是 IDE 里的补全插件——它是一个**能在你电脑上自主跑命令、读写文件、调外部工具、改代码、跑测试**的 AI 程序。最典型的代表是 **Claude Code（2025-02）**、**OpenAI Codex CLI（2025-04）** 和 **Google Gemini CLI（2025-06）**。
CLI Agent 是把"AI 编程助手"装进终端命令行里的那一类工具。它不是聊天机器人，也不是 IDE 里的补全插件——它是一个能在你电脑上自主跑命令、读写文件、调外部工具、改代码、跑测试的 AI 程序。最典型的代表是 Claude Code（2025-02）、OpenAI Codex CLI（2025-04） 和 Google Gemini CLI（2025-06）。
要理解它为什么存在，先看清楚它和大家熟悉的另外两类工具到底差在哪：
一句话总结这种差异：网页版让你"问 AI"，IDE 让 AI "看你"，而 CLI Agent 让 AI "替你做"。
| 要素 | 含义 |
|---|---|
| 终端原生 | 跑在 shell 里，输入输出都是文本，没有 GUI 中间层 |
| Agentic（自主） | 有"读文件 / 跑命令 / 看结果 / 再决定下一步"的循环能力，不只是单次问答 |
| 工具调用（Tool Use） | 能调用 bash、git、grep、外部 CLI、MCP server 等 |
| 项目级上下文 | 能整体扫描代码库、读 CLAUDE.md / AGENTS.md 等项目记忆文件 |
| 可脚本化 | 能被管道串、能在 CI 里跑、能被另一个 Agent 调用，符合 Unix 哲学 |
| 沙箱与权限模型 | 工具白名单、危险命令审批、容器隔离等机制保证不乱跑 |
CLI Agent 干活的核心是一个**"想 → 做 → 看 → 再想"** 的循环，下面这张图把循环画清楚：
这就是 "Agent" 这个词在 CLI Agent 里真正的分量——它不是一次问答，而是一段自主完成的工作。你下一个指令，它能自己决定调几次 bash、读几个文件、改几行代码、跑几次测试，最后回报你一个结果。
CLI Agent 不是 2026 年才有的，但 2026 年才真正变成主战场，原因有三条：
larksuite/cli（200+ 命令、20+ AI Skills），都明确瞄准 Claude Code / Codex 这类 Agent。"AI Agent 友好型 CLI" 成了一个独立品类。&& 这些组合方式 Agent 一秒就能学会；GUI 那套 "鼠标点这里、再拖那里" 在 Agent 面前几乎是不可用的。CLI Agent 工具不少，下面用最具代表性的 Claude Code 演示一次"5 分钟从装到跑"的完整流程。其他两家（Codex CLI、Gemini CLI）的形态高度相似，理解一个就能迁移到其他几个。
macOS / Linux / WSL：
# 官方一键脚本，支持自动后台升级
curl -fsSL https://claude.ai/install.sh | bash
或者用 Homebrew：
brew install --cask claude-code
Windows 直接用 PowerShell：
irm https://claude.ai/install.ps1 | iex
cd ~/code/my-app
claude
第一次启动会让你登录 Claude 账号（订阅版或 API Key 都可以）。登录完成后，你会得到一个交互式的 REPL，这就是 Claude Code 的"驾驶舱"。
直接说人话就行：
> 把 auth 模块所有失败的单测修好，跑 npm test 直到全绿，然后 git commit
Claude Code 会自动执行下面这串动作（你能看到每一步）：
ls src/auth 摸清目录结构npm test -- auth 看哪些测试挂了git diff 给你看改动git commit -m "fix(auth): ..." 提交每次涉及"写文件 / 跑可能危险的命令"时它会请求一次确认，安全模型由 permission model 控制。
CLI Agent 真正的爆点不在于 REPL 模式，而在于它能被管道串起来：
# 把最近 200 行日志喂给它，让它判断是否异常并发 Slack
tail -200 app.log | claude -p "如果发现异常请发 Slack 通知我"
# CI 中自动翻译新加的 i18n 字符串并提 PR
claude -p "把新增字符串翻成法语，建一个 PR"
# 让它对 PR 里改动的文件做安全 review
git diff main --name-only | claude -p "审计这些文件的安全风险"
这种"AI + Unix 管道"的组合是 IDE 插件根本做不到的——这正是 CLI Agent 的护城河。
把 CLI Agent 放在更大的"AI 编程助手"光谱里看，它和另外两类有非常清晰的界线：
| 维度 | CLI Agent（Claude Code / Codex CLI / Gemini CLI） | IDE Agent（Cursor / Continue / Cline / Copilot Chat） | 网页版（Claude.ai / ChatGPT 网页） |
|---|---|---|---|
| 工作半径 | 整台电脑：文件系统、git、外部 CLI、容器、远端服务 | IDE 内：当前 workspace、打开的文件、内置 terminal | 仅对话框，无文件系统访问 |
| 能否自主跑命令 | ✅ 可以跑 bash / git / docker / 测试，循环执行 | ⚠️ 部分支持（Cline / Cursor agent 模式），多数只在 IDE 沙箱里 | ❌ 不能 |
| 可脚本化 / CI 集成 | ✅ 一等公民（-p 参数 + 管道 + GitHub Action） | ⚠️ 弱：插件难脱离 IDE 进 CI | ❌ 仅人工复制粘贴 |
| 跨项目 / 多仓库联动 | ✅ 直接 cd 切目录，或 git worktree 并行多 Agent | ❌ 通常受限于单一 workspace | ❌ |
| Token 效率 | 高：能调本地索引、专用 CLI、MCP，避免把全文塞进上下文 | 中：依赖 IDE 的 RAG 实现，质量参差 | 低：只能靠你手动贴片段 |
| 学习曲线 | 中：需要适应纯文本交互、读懂工具调用 | 低：图形界面友好 | 极低 |
| 典型场景 | 跑 TDD 循环、批量重构、CI 自动审查、工作流脚本化、多 Agent 并行 | 写新代码时的边写边问、内联补全、可视化 diff | 概念解释、单段代码翻译润色 |
核心区别一句话：网页版是"AI 助手在远端，你来回搬运"；IDE Agent 是"AI 助手坐在副驾，跟你共享方向盘"；CLI Agent 是"AI 助手有自己的驾照，你下指令它去开"——它能独立完成一段完整的工作，而不是只回答一个问题。
值得注意的是这三类并不互斥。靠谱的工程师 2026 年的常见配置是：网页版用来快速问概念，IDE 插件用来边写边补全，CLI Agent 用来跑长链路任务和自动化工作流——三件套各司其职。
| 误区 | 准确理解 |
|---|---|
| 以为 "CLI 工具" 就等于 "命令行版的 ChatGPT" | CLI Agent 的核心不是"在终端里聊天"，而是自主执行一段任务——它能跑命令、看结果、再决定下一步。聊天只是它的输入方式之一 |
| 觉得 IDE 插件就够了，没必要再装 CLI Agent | IDE 插件解决的是"边写边补全"，CLI Agent 解决的是"自主跑完一段流程"。前者优化打字速度，后者直接替你做掉一个任务，定位完全不同 |
| 担心 CLI Agent 会乱跑命令把电脑搞坏 | 主流 CLI Agent 都有完善的**权限模型**：默认情况下写文件、跑 bash 都需要确认，危险命令（rm / sudo / curl 管道）会被拦截，必要时还能跑在 docker / sandbox 里 |
| 把 CLI Agent 和 MCP 对立 | 两者是互补：MCP 是"让 AI 接外部服务的协议"，CLI Agent 是"让 AI 在终端跑活的产品形态"。Claude Code、Codex CLI 都内置 MCP 支持，可以同时用 MCP server 和直接调系统命令 |
| 认为 CLI Agent 只能写代码 | 写代码确实是它的主战场，但凡是"能在终端表达"的任务它都能干：跑数据分析、批量处理文件、运维巡检、生成内容、调远端 API、操作 Obsidian / 飞书等 |
| 以为 token 一定比 IDE 插件烧得多 | 恰好相反。CLI Agent 走专用 CLI / 索引时往往比 IDE 插件的"暴力 RAG"省得多——Obsidian CLI 能用 100 token 完成 grep 路线百万 token 才能干的事 |
| 以为只有大型项目才需要 CLI Agent | 个人脚本、运维任务、笔记整理、邮件草稿这些"碎活"反而最适合 CLI Agent。一行 claude -p "..." 就能搞定，零启动成本 |
| 优势 | 劣势 |
|---|---|
| 工作半径覆盖整台电脑：文件、git、外部 CLI、MCP、容器全打通，能完成 IDE 插件做不了的端到端流程 | 学习曲线陡于 IDE：纯文本交互对图形派开发者不够直观，需要适应"看输出 + 看 diff"的工作方式 |
天然可脚本化 / CI 友好：claude -p "..." 一行就能塞进 pipeline、管道、GitHub Action | 权限风险显性化：能力越大责任越大，配错权限或乱开 --dangerously-skip-permissions 可能造成真实损失，需要纪律 |
| token 效率高：可以调专用 CLI / MCP / 本地索引，避免把全文塞上下文（Obsidian CLI 案例：~7 万倍差距） | 生态分裂：Claude Code、Codex CLI、Gemini CLI 各家配置文件、hook 体系、Skills 机制都不一样，团队选型要慎重 |
| 多 Agent 并行容易：tmux 多 pane / git worktree 多目录，可以同时跑多个 Agent 处理不同任务 | 观感重于结果时不友好：网页版自带漂亮的 markdown 渲染，CLI 输出靠你自己读纯文本 + diff，对设计/产品同事不够直观 |
| 被工具方主动适配：2026 年起 Obsidian / 飞书 / GitHub / Linear 等都在做"Agent 友好的官方 CLI" | 协议与版本变化快：CLI Agent 工具几乎每周一个 release，settings、hooks、Skills 等机制半年内可能完全重写 |
| 符合 Unix 哲学：和 grep / awk / fzf / jq 等老牌工具完美组合，工程师不需要换工作范式 | 不适合非工程师：产品经理、运营、设计同事更适合 Claude.ai 这类对话式产品，CLI Agent 的门槛对他们偏高 |
参考答案：
三者解决的根本不是同一个问题，而是**"AI 助手介入开发流程的不同深度"**：
举个具体的对比：让 AI 完成 "修复 auth 模块所有测试 + 提交 commit" 这个任务。
所以三者更像是互补的三层：网页版做"问"，IDE 做"写"，CLI Agent 做"做"。靠谱的工程师 2026 年的工作流通常三件都用，按场景切换。
参考答案：
这背后有三层原因，分别对应协议层、效率层、生态层：
1. 协议层：CLI 是"自描述的"
CLI 工具天然有 --help，AI Agent 不需要任何文档就能现场学会怎么用。这是飞书 CLI 团队明确指出的核心理由："larksuite/cli --help 一秒搞定，不需要在 prompt 里塞接口字典"。相比之下，要让 Agent 用 REST API 你得喂 OpenAPI 文档、要让它用 SDK 你得喂方法签名，token 成本和出错率都更高。
2. 效率层：CLI 能把"领域索引"封装进去
Maksym Prokopov 实测的 Obsidian 案例非常典型：让 Agent 用 grep + 逐文件 read 在笔记库里找东西要烧数百万 token，而 Obsidian CLI 直接调内部索引只用约 100 token——约 7 万倍差距。这是因为工具方比谁都懂自己的数据结构，把"如何高效查询"封装成 CLI 命令，比让 AI 自己暴力扫文件省得多。MCP server 理论上能做同样的事，但门槛更高、跨客户端兼容性更复杂。
3. 生态层：CLI 一份代码同时适配所有 Agent
写一个官方 CLI，Claude Code、Codex CLI、Gemini CLI 全都能直接调，因为它们都跑在同一个 shell 里。如果做 IDE 插件，你得给 VS Code、Cursor、JetBrains 各做一份；如果做 MCP server，你得追着每个客户端的协议版本升级。CLI 是"写一次，所有 Agent 通用" 的最低成本路径。
为什么不直接做 IDE 插件？因为 2026 年工具方意识到：真正"替你做事"的 AI 都跑在 CLI 里，IDE 插件偏向"边写边补全"，触达不到 Agentic 工作流。为什么不直接做 MCP？因为 MCP 适合跨进程、需要鉴权、需要多客户端共享的场景；本地工具用 CLI 更轻、上手更快。两条路并不互斥，飞书就同时开源了 larksuite/cli 和 lark-openapi-mcp，分别覆盖不同场景。
总结：这是工具方对"AI Agent 时代主流形态"的押注——他们判断未来主流的 Agent 都跑在终端里，所以提前把 CLI 做成 Agent 友好的形态，而不是等着 AI 自己摸索 REST API。
优先展示同分类且标签更接近的内容，方便继续串联学习。
Anthropic 官方终端 Agent，原生支持工具调用、MCP、Skills 与 Hooks，2026 年生态最完整的 CLI Agent
OpenAI 官方终端 Agent，GPT 模型驱动，开源、跨平台、轻量化，2026 年与 Claude Code 形成生态对位
Google 官方终端 Agent，Gemini 模型驱动，强项是 1M+ 上下文窗口、慷慨免费额度与 Google 生态集成