Agent 到底是什么，不是什么

先说一个可能会得罪不少人的观察：这两年，"Agent" 这个词被用得太松了。

很多产品页面上写着"AI Agent"，点进去发现其实就是一个聊天框，问一句答一句，顶多加了个联网搜索。这不是说这类产品不好用，而是它们压根不是 Agent，只是一个反应更快、知识更新的聊天机器人。

这篇文章想先把这个最基础的问题讲清楚：Agent 到底是什么，又不是什么。这也是我准备写的 Agent 系列的第一篇——后面会讲 ReAct 循环、Tool Calling 的坑、上下文管理、怎么验证 Agent 做对了没有，但这些都得建立在一个前提上：你得先知道自己在讨论的东西，到底算不算 Agent。

一个简单的判断标准

我自己想清楚这件事之前，也是稀里糊涂地用这个词。后来想明白了一个粗暴但好用的判断方法：

问自己一句话——"如果我不再追问下一步，它还会不会自己继续做事？"

如果答案是"不会，它会停在那里等我说话"，那它是聊天机器人。

如果答案是"会，它会自己判断接下来该干嘛，直到任务完成或者卡住"，那它才有资格叫 Agent。

区别的核心不是"聪不聪明"，也不是"知不知道很多东西"，而是有没有自主的多步骤行动能力。聊天机器人做的是"回答"，Agent 做的是"执行"。

拿我自己这个博客举例子

我这个博客的 AI 分身——就是你现在如果在读这篇文章、旁边有个聊天框能问我问题的那个——它不是 Agent，它是个很典型的聊天机器人，尽管它看起来会"做事"：推荐文章、播放音频、判断你的问题是不是被问过很多次。

为什么不算？因为它做的每一件事，本质上都是"回答一个问题，顺便在回答里带一个动作标记"。它不会自己决定"我先去查一下这篇文章的阅读量，再看看要不要推荐，再决定要不要追问你一个问题"——这些判断链条不存在。它是单轮的、被动触发的：你问一句，它生成一段文本，文本里可能包含"推荐文章：xxx"这样的标记，前端解析出来渲染成卡片。仅此而已。

这不是缺陷，是我故意这么设计的。我在这个项目的技术文档里写过原因（如果你对细节感兴趣，我甚至专门记录过"为什么不用 Agent 框架"）：一个只需要回答问题、推荐文章的场景，压根不需要 Agent 那套自主决策、多步骤执行的复杂机制。用 Agent 框架去做这件事，属于我自己之前批评过的"既然...于是..."式过度设计。

所以，判断一个系统是不是 Agent，不看它用了多先进的模型，也不看界面上有没有写"AI Agent"，而是看：它是不是在没有你持续追问的情况下，自己决定接下来要做什么，并且真的去做了。

三个容易混淆的邻居

除了聊天机器人，还有两个词经常被和 Agent 搞混，值得一起说清楚。

Workflow（工作流）

Workflow 是"预先写死的步骤序列"。比如"收到表单 → 发邮件 → 更新表格 → 通知负责人"，这是一套固定流程，每一步该干什么、下一步是什么，都是人提前定好的。

Workflow 可以很复杂、很智能（比如某一步用大模型做判断），但它的执行路径是确定的，不会因为情况变化而自己重新规划。

Agent 和 Workflow 的核心区别：Workflow 是"照着剧本演"，Agent 是"自己写剧本、自己演，边演边改剧本"。

Tool-using LLM（会用工具的大模型）

这是最容易和 Agent 混淆的一类。很多产品接了几个 API（搜索、计算器、发邮件），让模型可以"调用工具"，看起来已经很像 Agent 了。

但如果这个系统只能调用一次工具就结束（比如你问天气，它调一次天气 API，返回结果，完了），那它顶多是"工具增强型聊天机器人"，还不是 Agent。

真正的 Agent 需要能够：调用工具 → 看结果 → 根据结果判断下一步 → 可能再调用别的工具 → 持续这个循环，直到任务真的完成，而不是"调用一次就交差"。

这个"观察-判断-行动"的循环，有个专门的名字，叫 ReAct，是系列下一篇的主题。

Agent Platform（Agent 平台）

这个我在 Harness 那篇文章里详细写过，这里简单提一句：Agent Platform 是"把 Agent 包装成产品给团队用"的那一层，解决的是"怎么给业务用"的问题，不是"这东西是不是 Agent"这个问题。一个产品可以有很华丽的 Agent Platform 界面，底层却只是个 Workflow，甚至只是个聊天机器人套了个壳。界面的复杂度，和它是不是真 Agent，没有必然关系。

为什么这个区分值得较真

你可能会说，管它是不是"真"Agent，好用就行，纠结定义有什么意义？

我觉得有意义，原因很朴素：如果你搞不清楚自己在用/在做的是哪一种，你就没法判断该往哪个方向优化。

如果你的系统本质上是聊天机器人，你该优化的是"回答质量"——知识准确、语气恰当、检索精准。这也是我这个博客花了很多精力在做的事（RAG 检索、Query 改写、防止 AI 编造）。

如果你的系统本质上是 Agent，你该优化的是完全不同的东西：任务规划、多步执行的稳定性、上下文管理、失败恢复、验证机制。这些是 Harness 那篇文章讨论的核心，也是这个系列接下来会展开的内容。

用聊天机器人的优化思路去搭一个真正的 Agent，或者反过来用 Agent 的复杂机制去做一个聊天机器人该做的事，都会白费力气——前者会让 Agent 稳定性堪忧，后者就是我自己批评过的过度设计。

先弄清楚自己站在哪一边，才能知道下一步该往哪走。

下一篇

搞清楚了"是不是 Agent"，下一个问题自然是：一个真正的 Agent，内部是怎么运转的？

答案的起点，是一个叫 ReAct 的简单循环——观察、思考、行动，一直重复。这是几乎所有 Agent 系统最基础的心跳，下一篇细讲。