Agent 大脑 = 模型 + 规则 + 当前上下文

大模型负责：
听懂人话
处理模糊表达
做语义推断
在信息不全时做合理猜测

规则/上下文负责：
告诉它哪些事不能做
告诉它你现在有哪些工具
告诉它你当前目录、历史状态、用户偏好
限制它必须按什么流程来

目标理解
任务拆解
工具选择
风险判断
执行校验
结果总结

用户给目标
-> Agent 理解
-> Agent 决定下一步
-> 调用工具
-> 工具返回结果
-> Agent 再理解结果
-> Agent 再决定下一步
-> …
-> 直到完成任务

Agent 与 CLI 学习笔记

这份笔记把我们前面聊过的内容重新整理成一版更通俗、更适合反复看的版本。核心围绕 3 个问题：

CLI 是什么
Agent 是什么
CLI 怎么一步步升级成带 Agent 能力的系统

一、先搞清楚 CLI 是什么

CLI 就是命令行工具，你通过“输入文字命令”来让程序做事。

比如：

folder create demo
folder list
folder delete demo

这 3 句就是典型的 CLI 使用方式。

你可以把 CLI 理解成：

GUI：点按钮
CLI：敲命令

它们都是程序的“入口”，只不过交互方式不同。

二、GUI 的底层是不是 CLI

不一定。

更准确的说法是：

GUI 和 CLI 都会调用更底层的程序能力
有些 GUI 会调用 CLI
但 GUI 的底层不等于 CLI

比如：

点“新建文件夹”是 GUI
输入 mkdir test 是 CLI
两者最后都在调用系统的文件夹创建能力

所以重点不是 GUI 套 CLI，而是它们共享底层能力。

三、你写的 folder CLI，本质是什么

你做的 folder 命令，本质上还是 Python 程序，只是被包装成了终端命令。

也就是说：

folder delete test-demo

背后其实还是：

Python 启动
解析参数
调用删除函数
操作文件系统

所以 CLI 不是一种“完全不同的程序”，而是“程序的一种使用方式”。

四、你的 folder CLI 现在做了什么

当前这个 CLI 主要支持文件夹增删改查：

create：创建文件夹
list：查看文件夹列表
show：查看某个文件夹详情
rename：重命名文件夹
delete：删除文件夹

比如：

folder create demo
folder list
folder show demo
folder rename demo demo2
folder delete demo2

这些动作都很明确，所以 CLI 能稳定执行。

五、CLI 的特点是什么

CLI 很能干，但前提是你要说得足够明确。

例如：

“创建 demo 文件夹”很明确
“删除 test-demo”很明确

但如果你说：

“帮我整理一下目录”
“把那些没用的测试文件夹处理掉”

CLI 就不太知道该怎么做了，因为这种话是“目标”，不是“命令”。

这也是为什么需要 Agent。

六、Agent 到底是什么

最通俗的一句话：

CLI 是执行器，Agent 是会思考、会安排、会检查的调度员。

CLI 擅长：

接收明确命令
稳定执行

Agent 擅长：

理解你的目标
拆解步骤
选择工具
根据结果继续判断
最后把结果讲清楚

所以 Agent 的价值，不是替代 CLI，而是让系统从“执行命令”升级到“完成任务”。

七、Agent 和 CLI 的两种关系

第一种：Agent 调 CLI

意思是：

Agent 是大脑
CLI 是工具

比如用户说：
“帮我把当前目录里带 test 的文件夹清理一下。”
Agent 会去调用：

folder list
folder show
folder delete

第二种：CLI 包 Agent

意思是：

终端本身就是 Agent 的入口
你打开终端，就像在和一个会思考的助手对话

前者像“AI 调工具”，后者像“终端版 AI 助手”。

八、Agent 的理解能力是谁在做

“理解”不是 CLI 做的，而是 Agent 层在做。

更准确地说，通常由两部分一起完成：

大模型/推理模型
规则、上下文、安全限制

大模型负责：

听懂人话
识别模糊意图

规则和上下文负责：

告诉它有哪些工具
哪些操作有风险
当前环境是什么
哪些目录不能乱删

所以成熟的 Agent，通常不是只有模型，也不是只有规则，而是两者结合。

九、只有模型行不行，只有规则行不行

都行，但都不够理想。

只有规则：

很稳
但听不懂复杂自然语言

只有模型：

很灵活
但容易飘，可能乱猜

更好的方式是：

模型负责理解目标
规则负责边界和护栏
工具层负责真正执行

十、Agent 的本质是一个循环

这是最重要的理解之一。

Agent 不是：

一开始就知道所有信息
一次性想完全部步骤
然后无脑执行到底

Agent 更像：

得到用户输入
-> 理解目标
-> 规划下一步
-> 调用工具
-> 拿到结果
-> 再理解当前情况
-> 再决定下一步
-> 再调用工具
-> ...
-> 直到完成

这个过程可以概括成：

Plan -> Act -> Observe -> Replan

也就是：

计划
执行
观察结果
重新计划

十一、Agent 为什么是循环，不是直线

因为很多任务的信息不是一开始就知道的。

比如用户说：
“删除当前目录下带 test 的文件夹。”

Agent 一开始只知道大方向：

先看目录
找 test
再删

但它还不知道真实目录有哪些，所以必须先执行：

folder list

拿到结果后，它才能继续往下判断。

所以 Agent 更像“边看边做”，不是“闭着眼睛跑完”。

十二、一个具体案例：删除 test 目录

用户说：

“把当前目录里名字带 test 的文件夹清理掉，但别误删重要目录。”

Agent 第一轮理解：

然后执行第一步：

folder list

假设返回：

project-a
test-demo
test-backup
docs

Agent 第二轮理解：

test-demo 和 test-backup 是候选目标
但还不能直接删

于是执行第二步：

folder show test-demo
folder show test-backup

假设返回：

Agent 第三轮理解：

test-demo 可以删
test-backup 先跳过，避免误删

然后执行：

folder delete test-demo

最后总结：
“已删除 1 个空测试目录，1 个非空测试目录已跳过，避免误删。”

这就是一个完整的 Agent 循环案例。

十三、Agent 的第一次理解和后续理解有什么不同

第一次理解，主要是“整体理解目标”。

回答的是：

用户最终想做什么
有什么限制
大方向怎么走

后面的理解，主要是“结合执行结果更新判断”。

回答的是：

当前结果代表什么
下一步该做什么
原计划要不要调整

所以可以这样记：

第一次：定大方向
后面每一步：边走边修正

十四、模型负责“选动作”是什么意思

推荐的做法不是让模型直接生成完整 shell 命令，而是让模型输出“动作标识”。

比如：

{"action": "list_folders"}
{"action": "delete_folder", "name": "test-demo"}

这里：

list_folders
delete_folder

就是动作标识。

模型负责：

选当前该做的动作

程序负责：

根据动作标识去映射表里找真实命令
再拼出参数

比如：

ACTION_MAP = {
    "list_folders": ["folder", "list"],
    "delete_folder": ["folder", "delete"],
}

这样就能把：

{"action": "delete_folder", "name": "test-demo"}

翻译成：

folder delete test-demo

十五、谁真正推动 CLI 去执行

不是模型自己执行，也不是 CLI 自己执行自己。

真正“按下回车”的，是 Agent 程序。

也就是说：

模型输出动作
程序查映射表
程序拼命令
程序调用系统执行 CLI

比如：

subprocess.run(["folder", "delete", "test-demo"])

这一步就相当于：
Agent 程序替你在后台敲下了命令。

十六、Agent 可以调底层函数，也可以调 CLI

这是很重要的工程实现点。

假设你的底层函数是：

delete_folder(base, name, force=False)

那 Agent 有两种接法。

第一种：调 CLI

subprocess.run(["folder", "delete", "test-demo"])

第二种：直接调底层函数

delete_folder(".", "test-demo", False)

两种都可以。

一般建议：

自己控制的项目，优先直接调底层函数
已经做成独立工具的系统，调 CLI 也很合理

一句话：
Agent 可以调底层函数，也可以调由底层函数封装出来的 CLI。

十七、你这个 folder 系统，推荐的结构

最推荐的结构是：

用户输入
-> Agent 理解层
-> 规则/安全层
-> 动作映射层
-> folder CLI 或底层函数
-> 文件系统
-> 返回结果
-> Agent 输出总结

你也可以理解成 3 层：

底层能力层
负责真正操作文件夹
CLI 层
把底层能力暴露成命令
Agent 层
负责理解目标、拆步骤、调工具、做总结

十八、最适合记忆的 Agent 抽象模型

推荐你记这句：

Agent = 全局目标 + 局部反馈 + 循环决策

解释一下：

全局目标：

用户最终想做什么

局部反馈：

每执行一步后拿回来的真实结果

循环决策：

每一轮都结合“原始目标 + 当前结果”决定下一步

所以 Agent 每一步本质上都在做这件事：

当前动作 = 全局目标 × 当前反馈

通俗点说就是：
Agent 不是按剧本死跑，而是带着目标，根据现场反馈不断修正。

十九、再用一个生活类比帮助记忆

你可以把整个系统想成装修现场。

用户：业主，说“帮我把这间房整理一下”
大模型：会听懂人话的项目经理
规则层：安全规范和施工制度
Agent 程序：调度员，负责安排谁去干活
CLI：工人手里的具体工具
文件系统：真正被改动的现场

所以：

模型不是工人
CLI 不是大脑
Agent 是把“大脑、制度、工具、执行”串起来的那套系统

二十、最后的总总结

这次最核心的收获，可以压缩成 8 句话：

CLI 是程序的一种入口，不是另一种神秘技术。
你写的 folder 命令，本质上还是 Python 程序。
CLI 适合执行明确命令，不擅长理解模糊目标。
Agent 的价值，是把“目标”变成“可完成的步骤”。
Agent 不是直线执行，而是循环执行。
每一步都要结合“初始目标 + 当前结果”决定下一步。
模型最好输出动作标识，不要直接自由拼命令。
真正推动命令执行的是 Agent 程序，CLI 只是被调用的执行器。

一句话终极版

CLI 负责做，模型负责懂，Agent 负责把“懂”变成“一步步做完”。

输入层
目标理解层
上下文管理层
规划层
工具抽象层
映射层
执行器
观察与解析层
校验层

安全与权限层
状态与记忆层
总结与输出层
日志与评估层

Agent概念