AI 的使用方式一直在变化,最开始大家习惯在网页里和 ChatGPT 对话；后来有了 Function Calling，AI 不再只是"聊天"，而是能够真正调用工具完成任务；再到现在，越来越多开发者开始把 AI 放进 Terminal，让它直接帮自己操作电脑、执行命令、分析结果。
于是，CLI Agent（命令行 AI 助手）开始流行起来。
如果你用过 Claude Code、Codex CLI 或者 Gemini CLI，大概都会有一种感觉：
与其说是在聊天，不如说是在和一个真正会干活的开发搭档协作。
今天我们就自己动手，用 Python + Ollama 做一个完全运行在本地的 CLI Agent。
整个过程不需要任何 OpenAI API，也不用联网调用模型，只要电脑能运行 Ollama 就可以。
为什么 CLI Agent 会越来越受欢迎？
对于开发者来说，Terminal 一直都是工作时间最长的软件之一。
查看日志、Git 操作、Docker 管理、服务器维护、Python 开发等等，几乎每天都会输入大量命令。
传统方式是：
我 -> 查文档 -> 想命令 -> 输入命令
而 CLI Agent 更像这样：
我："帮我看看磁盘快满了吗？" AI：理解需求 → 自动生成命令 → 执行命令 → 分析结果 → 给出结论
它并没有取代 Terminal，而是让 Terminal 多了一个"会思考的助手"。
本地部署最大的优势是什么？
目前 CLI Agent 大概可以分成三类。
第一种：云端模型
例如 Claude Code，模型运行在云端，本地 CLI 负责调用工具，优点是模型能力强。；缺点也很明显，它需要联网和API成本，在企业环境可能存在数据安全顾虑。
第二种：开源 Agent 框架
例如 Hermes 等项目，框架开源，可以自由替换模型。
既可以连接远程 API，也可以连接本地模型。
第三种：完全本地运行
今天介绍的方法属于这一类。
整个流程都是：
Python→ Ollama→ 本地 Qwen→Shell Command
所有数据都留在自己的电脑上，不需要上传任何内容，对于一些涉及源码、日志或者服务器配置的场景，这种方式会更加安心。
如果后续准备把这类 Agent 部署到自己的测试环境或者云服务器，也可以提前准备好运行环境。我之前在折腾一些 AI Demo 时，就直接放在 Hostease 的 Linux 云服务器上跑，一方面方便远程 SSH，另一方面需要测试不同发行版时也比较省事，不用来回切换本机环境。平时开发还是推荐本地调试，真正需要长期运行再迁移到服务器即可。
第一步：安装 Ollama
先安装 Ollama，安装完成之后，下载一个支持 Tool Calling 的模型，这里推荐 Qwen 系列。
例如：
ollama pull qwen2.5
Python 中只需要指定模型名称即可：
import ollama llm = "qwen2.5"
第二步：让 AI 学会执行命令
光有模型还不够，如果模型不能调用电脑上的工具，它依然只是一个聊天机器人，因此需要给它准备一个 Tool。
Python 最方便的方式就是 subprocess。
例如：
import subprocess def execute_shell_command(command): ...
模型真正调用的是 Tool。
而 Tool 再去执行：
ls pwd df -h top git status
等系统命令，随后把执行结果返回给模型。整个过程其实就是：
用户 → LLM → Tool → Shell → 返回结果 → LLM 总结
这也是目前主流 AI Agent 的工作模式。
第三步：告诉模型什么时候使用 Tool
仅仅有 Python 函数还不够。
模型并不知道什么时候应该调用它，所以还需要给 Ollama 提供 Tool Schema。
Schema 的作用可以理解成给模型一份工具说明书，里面会描述：
工具叫什么
能做什么
接收哪些参数
参数类型是什么
当用户说：帮我看看磁盘剩多少空间。
模型就会判断：
我应该调用 execute_shell_command。
然后自动生成：
df -h
整个过程完全由模型决定。
第四步：维护聊天上下文
CLI Agent 和普通脚本最大的区别就是：
它不是一次性执行，而是一直运行。
通常都会维护一个 messages 列表：
System → User → Assistant → User → Assistant
这样模型才能记住之前发生过什么。
例如：
用户： 进入我的 Downloads。 AI： (cd Downloads)
接着：
用户： 看看里面最大的文件。
模型就知道这里的"里面"指的是刚刚进入的目录。
第五步：处理 Tool Calling
真正的 Agent 都会经历一个循环。
用户提问 → 模型思考 → 是否调用 Tool？ → 执行 Tool → 拿到结果 → 再次交给模型 → 输出最终答案
注意，这里通常不是一次调用模型。
而是：
第一次：
AI： 我要执行 df -h
Python：
执行命令
第二次：
AI： 根据结果来看， 磁盘剩余还有 138GB。
所以真正完成一次问答，中间其实经历了两轮推理。
实际体验怎么样？
搭好之后，可以直接在 Terminal 对话。
例如：
我的 CPU 占用高吗？
模型可能执行：
top
然后总结：当前 CPU 使用率约 XX%，其中占用最高的是 XXX。
再比如：
还有多少磁盘空间？
模型执行：
df -h
最后直接告诉你哪个磁盘快满了。
整个体验和 Claude Code 已经有几分相似，区别只是所有推理都发生在自己的电脑上。
使用时需要注意什么？
虽然 CLI Agent 很方便，但也意味着它拥有执行系统命令的能力。
因此最好增加一些限制，例如：
建立命令白名单
删除命令前进行二次确认
禁止执行 sudo
限制联网命令
设置超时时间
例如：
帮我清理 Downloads
这类需求就比较危险，如果模型理解错误，可能真的会删除大量文件。
因此在真正投入使用前，一定要做好安全控制，而不是让模型无限制执行任何 Shell 命令。
写在最后
CLI Agent 的本质，其实并不复杂。
可以把它理解成三个部分：
大模型+Tool Calling+系统工具
有了这套框架之后，Shell 只是其中一种工具。
你还可以继续扩展更多能力，比如：
Python 代码执行
Git 自动操作
Excel 数据处理
数据库查询
Docker 管理
浏览器自动化
MCP Server 接入
一步一步搭建下去，它最终会越来越接近 Claude Code、Codex CLI 这类成熟产品。
对于想深入学习 AI Agent 的开发者来说，从一个本地 CLI Agent 开始，是一个投入成本低、实践价值很高的练手项目。
如果后续还准备让 Agent 长期运行、远程访问或者部署一些实验环境，本地调试完成之后再迁移到云服务器会更加方便。把本地验证过的 Agent 放到服务器持续运行，而不会影响日常开发机器。
