AI Agent 到底是在解决什么问题？

今天先记住

AI Agent 不是“会聊天的模型”换了个名字，而是把模型放进一个能持续做事的系统里：它要理解目标，拿到上下文，决定下一步，调用工具，看见结果，再修正动作。

它在大地图里的位置

先把 Agent 想成一条闭环，而不是一个模型接口：

txt

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

今天这一课站在最上面看整张图。后面讲工具调用、记忆、RAG、权限、评估时，都只是把这张图里的某个零件放大。

它到底是什么

普通 Chatbot 更像“回答器”：你问一句，它根据当前对话生成一句或一段回复。

Agent 更像“带执行闭环的任务处理器”：你给它一个目标，它不只生成答案，还会拆任务、选择工具、执行动作、读取反馈，并在必要时重新规划。

所以 Agent 的关键不是“更聪明”，而是“能不能把语言模型接到真实动作上”。没有动作，最多是建议；有动作、有观察、有修正，才开始接近 Agent。

为什么 Agent 里会用到它

工程里真正麻烦的任务通常不是一句话能结束的。比如生成一篇文档，要先确定主题，再查资料，再写草稿，再检查格式，再构建站点，最后发布。每一步都有可能失败，也都需要根据结果调整。

Agent 系统要解决的，就是这种“目标明确，但路径需要动态选择”的问题。

它把大模型放在决策位置，但不会把所有事情都交给模型凭空想。可靠的 Agent 需要清楚的状态、可控的工具、可观察的执行结果，以及失败后的恢复策略。

怎么判断它有没有用

看一个系统是不是需要 Agent，不要先看它用了什么框架，先看任务本身。

如果任务只是“问一句，答一句”，比如解释一个词、改一句文案、总结一段文本，普通 Chatbot 就够了。

如果任务需要连续动作，比如先查资料、再改文件、再运行构建、再根据错误修复，那就开始需要 Agent。

你可以用三个问题判断：

这个任务需不需要调用外部工具？
中途结果会不会影响下一步？
失败后需不需要重试、回滚或换方案？

三个问题里只要有两个是“是”，就不要只把它当聊天问题看，它更像一个 Agent 任务。

一个小例子

假设你要做一个“每日学习文档发布助手”，用户输入是：

txt

明天开始每天 9:30 生成一篇 AI Agent 学习文档，放到文档站。

如果只是 Chatbot，它可能输出一篇文章，或者告诉你“可以这样做”。到这里就结束了。

如果是 Agent，它至少要维护几类状态：

txt

目标：每天生成 AI Agent 文档
当前日期：2026-07-09
今日主题：AI Agent 到底是在解决什么问题？
产物路径：docs-preview/docs/ai-agent/2026-07-09.md
执行结果：文件已生成 / 构建已通过 / Git 已推送
失败处理：构建失败就读错误，修正文档或配置后重试

它的处理过程也不只是“写文章”：

txt

读取框架
-> 判断今天主题
-> 生成 Markdown
-> 检查是否含敏感信息
-> 运行 npm run docs:build
-> 构建成功后提交并 push
-> 返回当天链接

这就是 Agent 的味道：不是一次回复，而是一段可追踪、可恢复、可约束的工作流。

如果这条链路里没有“读构建结果再决定下一步”，它就只是自动脚本；如果没有“工具执行”，它就只是聊天；如果没有“状态记录”，它就很难长期稳定运行。

常见误区

以为 Agent 等于更长的提示词。提示词只是入口，闭环、工具和状态才是骨架。
以为模型自己会负责所有可靠性。真正上线时，权限、校验、重试、日志都要工程系统兜住。
以为 Agent 一定要完全自主。很多场景里，半自动、关键步骤让人确认，反而更稳。
以为用了框架就有 Agent。框架只提供结构，任务边界和失败处理仍然要自己设计。

今天自测

Agent 和普通 Chatbot 最核心的区别是什么？
为什么“观察工具结果”是 Agent 闭环里的关键步骤？
如果一个任务可能执行失败，Agent 系统至少应该记录哪些状态？

AI Agent 到底是在解决什么问题？ ​

今天先记住 ​

它在大地图里的位置 ​

它到底是什么 ​

为什么 Agent 里会用到它 ​

怎么判断它有没有用 ​

最近冒出来的词 ​

一个小例子 ​

常见误区 ​

今天自测 ​