L3-1 第二篇 · AI Agent 不是聊天 Bot，也不是插件
上篇：L3-1 第一篇《AI Agent：核心定义与运作原理架构》 ｜ 下篇：L3-1 第三篇《AI Agent 的应用形态：从 RPA、Copilot 到自主智能体》
前阵子去一客户那做技术交流，他们 CTO 特自豪地跟我讲：我们系统已经全面 Agent 化了。
我职业病犯了，顺嘴问了一句：那你那 Agent，是自己会换手子把活干完，还是得你一步步教它？
他顿了一下，说：那个……咱接了个大模型做客服，外加几个定时跑的脚本。
我没当场戳破。但回来一路上琢磨，这不就是典型的"名字叫响了，概念糊了"么。这两年 Agent 这词儿被喊得震天响，啥都往上贴——聊天框贴个 Agent，定时脚本贴个 Agent，连个网页翻译按钮都敢叫"翻译 Agent"。真配得上这名儿的，我估摸着一半都不到。
上篇咱们把 Agent 肚子里的五个零件（规划、记忆、工具、行动、观察）拆明白了。这篇反过来，专门划边界：Agent 不是啥？那些最容易和它撞脸的东西——聊天 Bot、插件、工作流、RPA、Copilot——到底差在哪？ 顺手给你一张选型表，以后做架构别再拍脑袋。
不过在掰扯那些撞脸概念之前，我得先把一个更根儿上的事说透，不然你后面会一直是"知其然不知其所以然"。
"一个东西自己会动"，到底是啥意思
计算机科学里"Agent"这个词，不是这两年才冒出来的。早在一九九五年，Wooldridge 那帮人写《多智能体系统》那书的时候，就把"智能体"的定义钉在三个性质上：
- 自主性（autonomy）：不用人一步步教，它自己知道往哪走；
- 反应性（reactivity）：环境变了，它会有反应；
- 主动性（proactiveness）：不光等你问，它会朝目标自己凑。
他们还分了"弱定义"和"强定义"两档。弱定义松一点，只要能对环境反应、自主行动就算；强定义狠，要求它还得有"心理状态"——就是 BDI 那套符号主义的东西：信念 Belief（它信啥）、愿望 Desire（它想干啥）、意图 Intention（它现在下定决心干哪件）。
我第一次啃 BDI 的时候头大，觉得这是哲学不是工程。后来真做项目摔了几次才咂摸出味儿：一个真 Agent，得"知道自己信啥、想干嘛、现在决心干哪件"。你那条写死的流水线，它啥都不"信"，也不"想"，它就是条 if-else 的河，水往低处流罢了。
这就要引出我特别想让你记住的一个视角——控制论视角。你把它当成一个反馈控制系统看，一下子就透亮了。任何能"自我纠错"的系统，本质上都有一个环：定个目标 → 比一比现状离目标差多少 → 决定咋调 → 动手调 → 再看调完啥样 → 不对就再调。控制论祖师爷维纳（Wiener）早把这套叫 cybernetics 了。
还有条更硬的原理，叫阿什比必要多样性定律（Ashby's Law of Requisite Variety）：一个系统要想管住外界的扰动，它自己内部的"花样"（多样性）必须至少跟扰动一样多。翻译成人话——外界一乱，你那套写死的脚本就傻了，因为它内部没"花样"可换；而 Agent 那个环，模型临场能生出各种新招，所以它扛得住意外。
这就是为什么 Agent 能"自我纠错"——不是它聪明，是它有反馈、有多样性。下面那张图，建议你存脑子里：
目标 Goal（设定值）
│
▼
┌───────────┐
│ 比较器 │◄──────────────┐
│(差多少?) │ │
└─────┬─────┘ │
▼ │
┌───────────┐ │
│ 控制器 │ 大模型干这 │
│(LLM:下一步)│ 儿的活儿 │
└─────┬─────┘ │
▼ │
┌───────────┐ │
│ 执行器 │ 工具 / 行动 │
│(动手) │ │
└─────┬─────┘ │
▼ │
┌───────────┐ 世界/环境 │
│ 被控对象 │───────────────┘
│ (Plant) │ 观察:成没成?
└───────────┘
看见没？大模型在这个环里干的是控制器的活儿——它决定下一步咋走。世界是被控对象，工具是执行器，观察是反馈。这套环一旦转起来，意外就能被"环"掉。Bot 和插件，缺的就是这个环。
顺带一句：上篇讲"感知→规划→行动→观察→再规划"，你拿这张控制论图一对，本质就是一个东西。规划=控制器，行动=执行器，观察=反馈，目标=设定值。打通了这层，后面看任何 Agent 框架你都不会晕。
我当年也干过"乱贴标签"的事
先交代个我自己的黑历史，免得显得我居高临下说别人。
刚摸 Agent 那阵，我做过个"技术动态监视器"：每天抓几个社区的新帖，摘要、分类、整理成简报发我邮箱。第一版我老老实实写了条流水线，先抓、再摘、再分、再发。跑通那天我还挺得意，跟同事吹：看，我的 Agent 成型了。
结果有天源站改了版，抓取挂了，返回一坨空。它呢？不报错，不喊停，安安静静把"无内容"摘了、分了、发了。我邮箱里躺了一排空白简报。
那一刻我脸有点热。这玩意儿压根不知道自己在干嘛，它只是把我写死的那几步机械走完。它不是 Agent。它就是条脚本。 因为它没有上面那个环——它没有"观察→比较→再调"的回路，源站一变，它内部没多样性可换，只能照原样走完。
从那以后我学了个乖：判断一个东西是不是 Agent，别听它叫啥名，要看它"出岔子的时候靠谁兜底"。
先掰扯两个最爱被误认成 Agent 的
聊天 Bot：它只会"说"，而且只在语言空间里说
聊天 Bot 的本质是个对话外壳。早年是规则/检索式，你问"退款"，它匹配关键词弹话术；现在铺天盖地是 LLM 驱动的问答，能聊得人模狗样。
但无论哪一代，有个根儿上的限制它跳不出去：它活在"语言空间"里。 它所有的本事，就是"生成下一段更合适的文本"。你跟它说"帮我把明天的车订了"，它大概率回你一段正确的建议，然后等你自已去点。它动不了世界分毫——因为它没有工具这个"手"，更没有"观察结果再决定"的环。
我给你画一下 Bot 的边界：
它再能聊，也只是在语言空间里打转。这是 Bot 的天花板。
插件：它只是"被挂上去的一个零件"
插件是能力挂载点——钉在宿主应用里的某个固定功能，比如"一键总结当前网页""把选中文字翻成英文"。它通常要你点一下、或程序显式触发，自己不会判断"此刻该不该用我"，更不会把结果拿去推进一个更大的目标。
这儿有个特别关键的认知，我建议你拿笔划一下：
插件是 Agent 的"工具"，但插件本身不是 Agent。
这就好比扳手是工人的工具，你不能把扳手叫工人。上篇讲的"工具"那个零件，落到产品里往往就是个插件；但光有扳手，成不了工人。
顺带把话挑明：现在火得一塌糊涂的 MCP（Model Context Protocol），它定义的那一堆"工具（tool）"，本质上就是标准化的插件。一个 MCP server 暴露出来的能力，跟浏览器插件没本质区别——都是"挂上去的一个功能"。区别只在：有没有一个 Agent 来自主地挑它、串它、在环里跑它。MCP 给 Agent 供弹，但 MCP 本身不是 Agent。这点后面 L3-6 专门讲，这儿先埋个伏笔。
那 Agent 到底特殊在哪
一句话，我平时这么跟人比划：
Bot 会"说"，插件能"用"，Agent 会"想了之后自己用，用了看结果，不对再改"。
回到上篇那五个零件（规划/记忆/工具/行动/观察）：Bot 顶多算有个 LLM 大脑的外壳，缺规划闭环、也缺工具行动；插件只是被挂上去的"工具"零件。只有 Agent，把规划→工具→行动→观察串成了一个自己能转起来的环——也就是前面那张控制论图。
所以你拿不准一个系统是不是 Agent，别看它会不会聊天，盯死这三件事：
- 有没有自主决策——下一步干啥，是它自己临场定的，不是你写死在代码里的；
- 有没有多轮闭环——办不成会换个法子接着试，而不是答完即止；
- 有没有作用于外部世界——调工具、改状态，而不只是吐文本。
这三样，缺一样都不算真 Agent。
我再给你个更狠的判据，是前面控制论那段的推论：它出意外的时候，是靠你写死的 if-else 兜底，还是靠自己的环绕过去？ 能自己绕的，才是 Agent。这条比上面三条还好使，因为"自主闭环"全浓缩在这一句话里了。
Bot 和 Agent 的圈，我画一起你扫一眼：
Bot 那个圈，转半圈就停了，得你再推它才动。Agent 那个圈，是自己一圈圈转，转不动了还知道绕——因为它有反馈、有多样性。
光讲道理没劲，上段代码一起看
下面这三段，左边是我当年那版"假 Agent"（写死的流水线），中间是真 Agent 的最小骨架，右边是在骨架上加了一层"从失败里学"的反思环——你重点看"下一步谁决定"和"失败咋办"这两件事。
# ---------- 左：写死的流水线（我当年的"假 Agent"） ----------
def fake_pipeline():
html = crawl("https://tech-news.example.com") # ① 抓
summary = llm_summarize(html) # ② 摘要
tags = classify(summary) # ③ 分类
send_email(tags) # ④ 发
# 源站一改版，crawl 返回空，后面三步照跑不误，
# 安安静静给我发了一堆"无内容"——它没有环，不知道自己挂了
# ---------- 中：真 Agent 的循环（下一步由模型临场决定） ----------
def run_agent(goal: str, max_steps: int = 5) -> str:
history = []
for step in range(1, max_steps + 1):
plan = llm_decide(goal, history) # 模型当控制器，决定下一步
if plan.is_done: # 干完了？收工
return plan.answer
obs = do_tool(plan.action, plan.arg) # 真去执行工具
if obs.failed: # 出岔子了？
history.append(f"试了 {plan.action} 挂了：{obs.err}")
continue # 换法子再来，不甩手
history.append(f"{plan.action} -> {obs}")
return "到步数上限，没干完"
# ---------- 右：在骨架上加"反思"（会话内从失败学习，预告 Reflexion） ----------
def run_agent_with_reflect(goal: str, max_steps: int = 6) -> str:
history, lessons = [], []
for step in range(1, max_steps + 1):
# 把"已吸取的教训"也喂给模型，逼它别踩同一个坑
plan = llm_decide(goal, history, lessons)
if plan.is_done:
return plan.answer
obs = do_tool(plan.action, plan.arg)
if obs.failed:
lessons.append(f"教训：{plan.action} 在 {plan.arg} 上失败，因 {obs.err}")
history.append(f"{plan.action} 挂了：{obs.err}")
continue
history.append(f"{plan.action} -> {obs}")
return "到步数上限，没干完"
同一件事，左边是人编排、机执行，且无环；中间是机编排、机执行，还带自我纠错；右边更进一步，把失败变成"教训"记下来，下一轮主动避开——这中间的差距，就是 Agent 和"不是 Agent"的鸿沟，而最右那步，已经是后面要讲的 Reflexion（反思）范式的小苗了。
一张表，把五个撞脸的摊开看
光说 Bot 和插件还不够，市面上跟 Agent 撞脸的一共五个。我列张表，维度拉齐了比，还多加一列"典型翻车"——你选型时心里有数：
| 维度 | 聊天 Bot | 插件 | 工作流 Workflow | RPA | Copilot | AI Agent |
|---|---|---|---|---|---|---|
| 核心动作 | 问答 | 执行单一功能 | 按固定顺序跑步骤 | 跑脚本模拟人操作 | 给建议，人拍板 | 自主达成目标 |
| 谁决定下一步 | 无（单轮） | 用户/宿主 | 开发者写死 | 脚本写死 | 人 | Agent 自己 |
| 在语言还是世界空间 | 仅语言 | 世界（但孤立） | 世界 | 世界 | 语言为主 | 世界 |
| 多轮闭环 | 否 | 否 | 否（线性） | 否 | 否（人兜底） | 是 |
| 有反馈环吗 | 无 | 无 | 无 | 无 | 人充当环 | 有（自闭环） |
| 能应对意外 | 不能 | 不能 | 不能 | 不能 | 部分（靠人） | 能自我纠错 |
| 典型翻车 | 一本正经胡说 | 功能孤立用不上 | 一步挂全断 | 界面一改就废 | 人没看就翻车 | 转圈烧钱/乱动生产 |
| 代表 | 客服问答 | 浏览器翻译 | Zapier 流程 | 财务对账脚本 | GitHub Copilot | Manus 类 |
一句话区分开：
- Workflow 是"人编排、机执行"——步骤你定死，它照走，优点是确定性高；
- RPA 是"机模仿人去点界面"——规则明确、界面稳的时候最香，但界面一改版就瘫；
- Copilot 是"机建议、人拍板"——它出主意，最后那下还得你点，风险最低；
- Agent 是"机编排、机执行、还能自己纠错"——你把目标一丢，它自己折腾，代价是可控性和成本。
那到底该用哪个：一张选型决策树 + 风险矩阵
理论说完，落地怎么办？我给你画个决策树，从上往下问自己：
我再多说一句掏心窝的话：别一上来就奔着 Agent 去。Agent 那栏"风险高"三个字，是无数生产事故换来的。能 Workflow 解决的，别上 Agent；上了 Agent 的，一定把 Human-in-the-loop、权限最小化、日志记录这几道闸焊死——
小小透漏下，后面我会有系列知识分享：L3-4、L3-5、结课安全篇都会拆解这些概念。
说个我帮人 review 的真事
上个月一创业团队找我，说他们"Agent 产品"上线了，问我架构咋样。我看了眼他们画的图——一个固定 DAG：用户提问 → 检索 → 喂给 LLM 写答案 → 返回。我问他：这 DAG 里，下一步是 LLM 临场决定的，还是你画死的？他愣了，说画死的。我又问：检索挂了它会自己换路子吗？他说不会，会报错给用户。
那我就直说了：兄弟，你这是 RAG 问答，是"LLM 当零件"的经典架构，不是 Agent。它不是不能卖，但你别按 Agent 的期待去宣传、去招人、去定价——用户冲着"自主"来，发现它连换条路都不会，落差会非常大。
后来他们把定位改回"智能问答 + RAG"，反而卖得踏实了。这事儿让我更信上篇那句话：名字叫啥不重要，重要的是它内部有没有那个环。 你拿"三判据"和"控制器/零件"这两条往自己项目上一套，立马知道该不该叫 Agent，也知道该不该上 Agent。
一个高频误区：加 LLM ≠ 加 Agent（以及"控制器"vs"零件"）
写到这，我得暴漏一个我听过最多次的误解。
好多人以为："给 Bot 接了个大模型，那不就是 Agent 了么？"
错。加 LLM 不等于加 Agent。
更精准的说法是——要看大模型在这套系统里当什么角色：
- 当零件（component）：它只在固定流程里生成一段文本。比如一个 RAG 问答，LLM 负责"根据检索到的内容写答案"，但"先检索、再让 LLM 写、最后返回"这顺序是写死的。LLM 是流水线上的一个工人，不是工头。这叫"用了 LLM 的系统"，不是 Agent。
- 当控制器（controller）：它决定"下一步干嘛、调哪个工具、成了没成、不成换啥招"。流程是它临场跑出来的，不是你写死的。这才是 Agent。
一个 LLM 驱动的问答机器人，只要还缺"规划/记忆/工具/行动的自主闭环"，它就还是 Bot。反过来，一个 RPA 哪怕一行 LLM 都没用，它在固定流程里也只是自动化，也不是 Agent。
判据永远是那句：看它有没有"自主闭环"（LLM 是否当控制器），不看它"有没有用大模型"。 大模型是 Agent 常用的脑，但不是 Agent 的身份证。
收个尾，顺便立条铁律
回到开头那家客户。
我现在要是再坐那 CTO 对面，大概会这么讲：你们那套，客服是 Bot，定时脚本是 Workflow，都挺好用，但先别急着叫 Agent。不是非要叫 Agent 不可——Agent 的自主是一把双刃剑，能力越强，可控性、成本、风险越高。
所以我给你立条铁律，记心里：
能用简单方案解决的，别上 Agent。
把 Agent 留给"路径不确定、需要试错"的地方，才是它真正的价值区。该用 Bot 用 Bot，该用 Workflow 用 Workflow，别拿大炮打蚊子，也别拿蚊子拍去轰大炮。
下一篇咱换个角度，把 Agent 放到一条"自主程度演进光谱"上，从 RPA、Copilot 一路看到全自主智能体，再给你份业务选型矩阵，帮你判断自己那项目该落在光谱的哪一段。
咱下篇见。
上篇：L3-1 第一篇《AI Agent：核心定义与运作原理架构》 ｜ 下篇：L3-1 第三篇《AI Agent 的应用形态：从 RPA、Copilot 到自主智能体》
