Agent 入门：从对话到执行

很多人第一次接触大模型，是从一个对话框开始的。你问它答，偶尔让它写段代码、改篇文章。这个阶段的 AI 更像一个知识库，能给建议、能给思路，但事情还得自己动手做。

Agent 带来的变化，是 AI 开始真的“干活”了。它可以直接读文件、运行命令、修改代码、调用工具，甚至在你睡觉的时候把一整套流程跑完。从“告诉我怎么做”到“替我做完”，这是两个完全不同的产品形态。

Agent 的基本结构

把 Agent 拆开看，大概可以分成三层：

模型是大脑：DeepSeek、GPT、GLM 这些大模型负责理解和推理；
Agent 工具是壳：Claude Code、Codex 这类工具负责组织对话、工具调用、记忆和权限；
CLI、文件系统、浏览器是手脚：真正去执行命令、读写文件、访问网页的部分。

所以我会说，Agent 本质上是“LLM + 壳 + 手脚”。但这不是简单的相加，壳里面还有很多细节：提示词怎么组织、工具怎么暴露、记忆怎么保存、多个 Agent 怎么协作。这些细节决定了同一个模型在不同工具里用起来差别有多大。

这也解释了一个现象：当你思路很清楚的时候，大脑反而没那么重要。只要计划足够明确，换一个稍弱一点的模型，执行结果也不会差太多。真正拉开差距的，往往是“手脚”好不好用、壳是否顺手。

理论与架构

Agent 能替你执行，但不能替你定义问题。

如果你对某个领域一知半解，就很难把需求描述清楚，更别说判断 Agent 给的结果对不对。代码跑起来报错时，你也很难判断是环境问题、逻辑问题，还是模型在胡编。理论深度决定了你能把 Agent 用到什么程度。

目前 AI 在已有知识体系内表现很好，但面对全新的、需要深度定制的方向，往往需要你提供清晰的框架。它擅长在已知空间里组合、迁移、优化，不擅长凭空开辟一个新领域。你的专业知识，就是把它拉到正确方向上的那根绳子。

所以我的态度是：让 AI 成为工具，而不是因为有了工具就放弃思考。

Skill、插件与工作流

用 Agent 用久了，会碰到两个概念：Skill 和插件。

Skill 可以理解成封装好的能力，本质仍然是一组提示词、工具和流程，只是被打包成了可以复用的形式；
插件更像一个工具箱，把某个软件相关的一组 Skill 打包在一起，让 Agent 能操作这个软件。

比如文献阅读有一套固定流程：先看创新点，再看理论和方法，最后看实验和局限。这套流程可以写成一个 Skill。再比如代码审查，可以要求 Agent 先看架构、再看边界条件、最后跑测试，也可以固化成 Skill。

但我不建议一上来装一堆插件。很多插件在模型能力还不够强的时候确实有帮助，相当于给模型加上外部约束，让它别乱跑。可当模型自己就能规划好时，这些约束反而会变成束缚：每一步都要写计划、做复盘，执行变慢，Token 也浪费。工具要跟着模型能力一起更新，适合当下才是最好的。

再往上一层，是工作流。Claude Code 的 Workflow 模式会自动拆出多个 Agent：一个负责写计划，一个负责写代码，一个负责审查，一个负责文档，最后还有 Agent 做汇总。用起来确实像一个小团队，考虑会更周全，代价是 Token 消耗得特别快。适合复杂任务，不适合所有任务。

CLI 的作用

我们人习惯图形界面：打开网页，找到搜索框，点按钮，看结果。这套操作对人很自然，因为人有很强的视觉识别能力。

Agent 不适合这套方式。它要理解屏幕上的像素、识别按钮、模拟点击，每一步都慢，而且贵。相比之下，命令行是确定性的：输入一条命令，得到结构化输出，不需要看图，也不需要猜。

以访问 GitHub 为例。人的操作是：打开网页，在搜索框输入关键词，点进仓库，逐个文件查看。Agent 如果也这么做，就要么依赖多模态模型看截图，要么去解析页面结构，两种方式都不稳定。

CLI 的方式是：

gh repo list
gh repo view owner/repo
gh api repos/owner/repo/contents

输出是结构化的文本，Agent 可以直接读、直接判断、直接进入下一步。不需要截图，不需要 OCR，也不需要在页面里找按钮。

购物也是一样。人打开购物 App，一眼看到搜索框；Agent 如果让它操作 App，就要模拟点击、识别商品卡片。如果有一个购物 CLI，它只需要输入关键词和筛选条件，拿到结构化结果。效率完全不是一个量级。

CLI 对人是门槛，对 Agent 反而是最自然的接口。

CLI 的演进

最早的程序员都是用 CLI 的。后来 GUI 盛行，因为软件要面向普通人，图形界面更直观。结果到了 Agent 时代，CLI 又回到了舞台中央。

但这不是简单的复古。现在的 CLI 和以前不一样：

有更好的交互体验，比如补全、彩色输出、进度条；
有结构化的输出格式，比如 JSON；
有完善的认证和权限管理；
可以被脚本、管道、CI/CD 直接调用。

CLI 工具可以说是 Agent 的“最后一公里”。以前很多软件只有 GUI，Agent 只能通过 computer use 模拟鼠标键盘；如果这些软件都提供 CLI，原来复杂的点击操作就变成了一行命令。

比如 Word 排版，现在让 Agent 做，基本是各种点击和拖拽。如果未来每个样式都有对应的命令，排版就变成“选中范围 + 应用命令”的事情。当然，这需要软件厂商愿意开放接口，短期内不会全面发生，但趋势已经很明显了。

GitHub CLI

GitHub CLI 是我最推荐的 CLI 工具之一。安装：

winget install --id GitHub.cli

gh auth login

平台选 GitHub.com，协议选 HTTPS，然后按提示在浏览器里输入一次性验证码。登录成功后，Agent 就能在终端里直接操作 GitHub 了。

几个常用场景：

gh auth status
gh repo clone owner/repo
gh repo create my-project --private
gh api repos/owner/repo/contents
gh pr list
gh issue list

没有 GitHub CLI 时，Agent 想参考一个开源项目，只能由你手动下载，或者去网页上抓。总不能每次看到项目都停下来，让你先下载一份。

有了它，Agent 可以自己搜索、自己读、自己改，整个流程顺畅很多。

终端里还有一个小技巧：Ctrl+C 通常是中止当前程序，不是复制；复制是选中文本后点鼠标右键，粘贴也是在目标位置点右键。习惯之后会比反复按快捷键更顺手。

消费级 App 的入口逻辑

CLI 这么好用，为什么微信、滴滴、外卖平台不直接提供？

原因不只是安全。消费级 App 的商业模式建立在“入口”和“注意力”上：用户打开 App，看到信息流、推荐、广告，平台才能把流量变现。如果提供一个只有聊天、打车、点餐功能的 CLI，用户不再打开 App，广告就没了，平台的入口地位也会被削弱。

所以 2C（面向消费者）的产品对 CLI 天然谨慎。它们更可能选择“有限开放”：只开放部分能力，和第三方合作，或者把入口放到手机厂商的系统级 Agent 里，通过授权费获得收益。

2B（面向企业）的逻辑不一样。企业软件收的是订阅费和服务费，广告反而会显得不专业。飞书、企业微信这类工具，核心价值是提高协作效率，所以它们更有动力提供 CLI、API 和自动化能力。在线文档也是同样的道理：企业需要版本同步、信息传达和权限管理，这些都能通过接口做得更好。

这也是为什么我说，CLI 的普及不会均匀发生。它会先在开发工具、企业软件、内容平台的部分场景里成熟，再慢慢扩展到更多领域。

我也不认为会出现一个 Agent 接管所有 App 的大一统局面。更可能的是有限开放、合作、端侧 Agent 并存：谁想直接掀桌子，都会被其他玩家群起攻之。历史反复证明，入口可以重构，但很难被一家通吃。

最小上手路径

如果你刚开始用 Agent，我建议按这个顺序来：

先装一个 CLI Agent，比如 Claude Code 或 Codex，接一个自己用得起、额度够的模型；
找一个你本来就要做、而且重复性比较高的任务，比如整理文件、跑一组参数、批量改图片；
把任务的目标、边界、验收标准写成一段清楚的说明，交给 Agent 执行；
执行完一定要检查结果，再决定要不要把这一步固化成工作流。

不用一上来就追求“全自动”。先让一个具体的小任务跑通，比收藏一堆教程有用得多。

环境怎么搭、浏览器怎么变成 CLI、文献怎么读进去，这些后面会分别整理。这一篇只需要记住一句话：

LLM 负责思考和决策，CLI 负责执行和获取数据。

Agent 不是魔法，也不是替代思考的按钮。它更像一个执行力很强、但需要清晰指令的同事。你负责定义问题、把控方向、检查结果；它负责把重复的部分做得更快。

完成大于完美，先让想法跑起来。