Agent 到底比普通 Chatbot 多了什么？

今天先记住

Chatbot 的核心是“回答当前问题”，Agent 的核心是“围绕一个目标推进状态”。两者都可能用同一个模型，差别不在模型名字，而在系统有没有目标、状态、工具、观察和修正。

它在大地图里的位置

昨天我们先看了 Agent 系统的大图：

txt

用户目标
  -> 上下文 / 记忆
  -> 规划 / 决策
  -> 工具调用 / 外部系统
  -> 执行 / 观察结果
  -> 评估 / 修正
  -> 最终输出

今天只放大第一个分岔口：什么时候这件事还是 Chatbot，什么时候已经需要 Agent。

如果系统只在“用户目标 -> 最终输出”之间生成一段话，它更像 Chatbot。只要中间开始出现“查资料、改文件、运行命令、读取结果、失败后换方案”，它就进入 Agent 范围。

它到底是什么

普通 Chatbot 可以很强。它能解释概念、写文案、总结材料、给建议，也能在一轮对话里表现得很聪明。

但它通常不拥有外部世界的状态。它不知道文件是否真的写入，不知道命令是否成功，也不会天然记住“任务已经推进到第几步”。

Agent 则把模型放进一个执行环境里。模型不只是说“你可以运行构建”，而是由系统授权后真的运行构建；不只是说“如果失败就修复”，而是读取错误日志，再决定改哪里。

所以一句判断很有用：Chatbot 主要产出文本，Agent 主要推动状态变化，文本只是其中一种结果。

为什么 Agent 里会用到它

工程任务经常不是“给我答案”，而是“帮我把事情做完”。比如每天生成一篇学习文档，不只是写正文，还要选主题、保存文件、检查格式、构建站点、提交代码、推送仓库。

如果把这种任务塞给纯 Chatbot，它最多给你一份操作说明。真正的 Agent 系统要能把说明拆成动作，并且让每个动作都有可观察结果。

这也是为什么 Agent 设计里总会反复出现工具、权限、日志、重试和评估。它们不是装饰，而是为了回答一个朴素问题：这件事到底有没有被正确执行？

怎么判断它有没有用

如果任务的结果只是一段文本，而且用户读完自己决定下一步，Chatbot 通常够用。

如果任务需要访问外部系统，比如文件、数据库、浏览器、Git、日历、微信消息，那就要考虑 Agent。

如果中途结果会改变下一步，比如构建失败就修文档、查不到资料就换来源、权限不足就停止并请求确认，这已经是 Agent 闭环。

如果动作可能造成真实后果，比如发消息、删文件、花钱、改线上配置，就不能只问“模型会不会”，还要问“谁授权、谁校验、谁回滚”。

一个小例子

以“文档站每日发布”为例：

txt

Input:
生成并发布今天的 AI Agent Daily lesson。

Chatbot Output:
这是一篇可以发布的 Markdown 草稿，以及建议你运行 npm run docs:build。

Agent Process:
读取写作框架
-> 判断上一课讲到哪里
-> 写入 docs/ai-agent/2026-07-10.md
-> 运行 npm run docs:build
-> 根据构建结果决定是否修正
-> git commit
-> git push origin main

Agent Output:
文件已落盘，构建通过，提交已推送，返回当天 URL。

这里的关键不是“文章写得更像人”，而是状态从“没有今日课程”变成了“今日课程已发布”。这个状态变化可以被文件、构建日志和 Git 提交验证。

常见误区

以为 Agent 就是更会聊天的 Chatbot。真正差别是能不能执行动作并观察结果。
以为有工具调用就一定是 Agent。一次性查天气也可能只是增强版 Chatbot，关键看有没有多步状态推进。
以为 Agent 必须完全自动。很多生产系统会在高风险动作前停下来，让人确认。
以为 Agent 越自主越好。边界不清的自主，常常只是更难调试的失败。

今天自测

为什么“能产出文本”和“能推进状态”是两个不同能力？
一个系统用了工具调用，但每次只查一次资料并直接回答，它一定是 Agent 吗？
如果让 Agent 自动发微信消息，系统至少应该在哪些步骤设置权限或确认？

Agent 到底比普通 Chatbot 多了什么？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​