AI Agent 的 CLI 超能力：组合工具的思维与实践
真正的『AI 原生』不是只会调用模型 API，而是学会借 cmdline 能力反过来驾驭模型。—— 来自 QPC 实践笔记
引子：原地踩坑与破局
写 Agent 项目半年，发现两个现象：
生产坑 ——
- 代码库 2k 文件，怎么快速撤离所有第三方 key？
- 日活跃 agent 实例上百，如何一眼看清谁在泄露内存？
- 高频需求：提取出所有对话里的意图标注。
AI 间歇性失能 ——
- 模型擅长创造，不擅长精确执行。
- 一次 agent 调用动辄 50k token，代价高昂。
真正的破局，不是让模型变聪明，而是把操作系统现成的精确能力用起来。
下面展示 10 个实例，每个都是agent项目中频繁踩坑后找到的确定性答案。
工具清单：让你恍然大悟的『不需要Python』场景
| 命令 | 干嘛用 | 代替的 Python 操作 | 节省 token 效果 | AI 友好度 | 成本效益 |
|---|---|---|---|---|---|
rg | 搜代码 / 搜日志 | open(file) + re.findall | ★★★★★ | ★★★★★ | 极高 |
fd | 搜文件 / 批量处理 | glob.glob + os.path | ★★★★☆ | ★★★★★ | 极高 |
jq | JSON 解析与过滤 | json.load + 遍历提取 | ★★★★★ | ★★★★★ | 极高 |
bat | 高亮代码查看 | open, syntax highlight 滚轮 | ★★★☆☆ | ★★★★☆ | 高 |
htop | 系统进程监控 | psutil + 表格输出 | ★★★★★ | ★★★★☆ | 中 |
fzf | 模糊搜索交互 | 无 | ★★★☆☆ | ★★★☆☆ | 中 |
awk | 结构化聚合 | pandas 等价加载 | ★★★★★ | ★★★★☆ | 高 |
sed -i | 文件批量编辑 | open()+写回+临时文件 | ★★★★★ | ★★★☆☆ | 高 |
✅ AI 友好度 指的是工具的输出格式是否易于 agent 解析。
jq和rg的输出最干净，agent 直接接受一行不需要再清洗。
智能体问题：可靠性与中途崩溃
智能体的"半途而废"之痛
写代码的人都知道——程序崩溃不可怕，可怕的是崩溃后状态全丢，只能从头再来。
智能体面临的就是这个问题。一个 20 步的自动化任务，执行到第 15 步时 LLM API 超时了，所有中间状态消失。下次运行从第 1 步重新开始，前面的 14 步白做了。如果有副作用（已经发了一封邮件、已经创建了一条数据库记录），那就更麻烦——重做会导致重复操作。
Temporal 的技术博客 2026 年 4 月发表了一篇引起广泛共鸣的文章，核心观点是：AI 可靠性是一个十年前就该解决、现在仍然只解决了一半的问题。我们应该用基础设施手段而非更好模型来解决它。
为什么智能体会中途崩溃？
原因一：LLM 推理本身就是不稳定的
传统软件的执行路径是确定性的——给定相同输入，永远走同一条路。LLM 不是。每一次推理都是一次概率采样，天生带有不确定性：
- API 超时：模型推理慢时，HTTP 请求可能超时中断
- Token 限制：上下文窗口满了，前面的轮次被截断
- Rate Limit：API 调用频率受限，被 429 返回
- 服务降级：高峰期模型响应质量下降
- 随机中断：GPU 集群节点切换、负载均衡导致连接中断
这些问题不是偶尔发生的，在大规模生产环境中是常态。
原因二：智能体状态是"内存态"的
大多数 Agent 框架把执行状态存在内存中：
# 典型的 Agent 循环
state = initial_state
for step in plan:
state = llm_call(step, state) # state 在内存
state = tool_call(step, state) # 一旦进程挂了，state 全丢
传统软件有数据库保驾护航——应用挂了重启后数据还在。Agent 框架呢？进程一死，所有中间推理、工具返回、上下文积累全部消失。
原因三：长链路任务的脆弱性
智能体任务越复杂，包含的步骤越多，执行成功率呈指数下降：
单步成功率 95%
10 步任务成功率: 0.95^10 = 59.9%
20 步任务成功率: 0.95^20 = 35.8%
50 步任务成功率: 0.95^50 = 7.7%
即使每步有 95% 的成功率（这已经是优秀的表现），一个 20 步任务就有近 2/3 的概率在某步失败。而大多数真实业务场景不止 20 步。