你有没有注意到，从 2025 年年中到现在，Agent 这个词出现的频率越来越高。它大有接替 2023 年开始流行的 Chatbot 的势头。

身边不少朋友提起 Agent 时，给出的反应是“一个更聪明的聊天机器人”。它能接收更长的提示词，挂载更多的资料，还能帮我们调调外部工具或是写写代码。

说实话，这个理解完全没毛病。Agent 的确比 Chatbot 更强。

不过，今天我们来聊聊这个热闹现象背后的硬核变化。撇开用法，单从系统设计的角度来看，从 Chatbot 演进到 Agent，其实发生了一次范式转变：AI 正在从我们熟悉的“单次请求-响应模式”，走向“基于目标驱动的自主控制循环”。

这到底意味着什么呢？不妨从最基础的交互逻辑来对比看看。

Chatbot：一次请求，一次响应

先从最熟悉的 Chatbot 开始看。从底层的工程逻辑来看，传统的 Chatbot 遵循的是非常标准的“请求-响应”模式。

你给它一段 Prompt（请求），模型根据当前的上下文进行推理，然后吐出 Response（响应）。一旦这段响应生成完了，这个请求的生命周期也就彻底结束了。

这时候，系统会把状态挂起，等待你的下一次显式触发。

一般，我们和它交互是这样的：

在这个模式下，Chatbot 是完全“被动”的。每一次状态往后推进，都得由我们在聊天框里敲回车来触发。Chatbot 本质上是一个具备语义理解能力的对话接口。它很擅长解释、总结和改写，但它的工作流程在单次交互后就断开了。

Agent：给定目标，自主循环

和 Chatbot“你推一下它动一下”不同。与 Agent 交互，你不再需要定义具体的操作步骤。只用给 Agent 定义一个“终态目标”，剩下的由它自主进入控制循环去推进。

举个例子，你给 Agent 提了一个目标：“排查当前分支 CI 跑测试失败的原因，并尝试修复它。”

面对同样的需求，Chatbot 和 Agent 二者的处理路径会截然不同：

• Chatbot 的做法：受限于单次交互的模式，它需要你手动把终端里的报错堆栈复制粘贴过去。它会帮你分析这段报错大概是什么原因，可能卡在第几行。再给出一两点修改建议，接着就挂起状态，等待你手动改完代码再次运行。

• Agent 的做法：它会直接启动一个自主的控制循环。

  • 观察与思考：读取 CI 系统的报错日志，发现测试卡在了数据库连接超时上（dial tcp: i/o timeout）。
  • 行动：调用本地的 Shell 工具，运行 docker ps 检查本地的测试数据库容器是否正常拉起。
  • 再观察与思考：发现数据库容器压根没启动。它接着去查看 Makefile 或者 docker-compose.yml 脚本。
  • 再行动：发现脚本里某个环境变量配置错了，导致容器启动失败。它自主调用文件工具修改了配置文件，并在本地重新执行 make test。
  • 再观察与思考：本地测试顺利通过。
  • 终态判定：确认问题已解决，最终自动提交代码变更，并向你输出一份结构化的排查与修复报告。

关键点在于：前一步的执行结果，会直接决定下一步的决策。

如果工具调用报错了，比如执行 docker ps 时发现权限不足，Agent 会自己捕获异常，尝试用 sudo 重试或者切换排查路径。如果发现报错日志不全，它会主动去查更底层的系统日志。如果判定本地测试已经完全通过，它得知道在什么时候终止循环并提交代码。

这就是大模型经典的 ReAct（Reasoning + Acting） 控制范式：观察 (Observe) → 推理 (Reason) → 行动 (Act) → 再观察。

AI 正是在这个循环中，完成了它的第一层质变：从“生成一段文本”，转变为“自主推进一个完整的复杂任务”。

从研发视角看五大系统演进

当 AI 走向目标驱动的控制系统时，底层的后端架构设计和研发关注点也随之发生了变化。

从单步对话，到多步任务编排

Chatbot 的一轮交互通常是标准的同步阻塞模式：你问一句，它答一句。而 Agent 面对的任务往往生命周期很长，很难靠单次的模型推理搞定。

看看这两个典型的长任务场景：

• 自动化修 Bug：包含读取源码 → 运行本地测试 → 捕获报错堆栈 → 迭代修改代码 → 重新跑测试，直到测试完全通过。这整个流程是一个连续的闭环。
• 本地数据分析：包含读取本地的异构表格 → 动态生成并执行 Python 脚本 → 渲染图表 → 验证并校对统计结果。

这时候你会发现，大模型本身在系统里只扮演了一个“控制器（大脑）”的角色。而外围的工具链接口、有向无环图（DAG）或者图结构的工作流编排、以及异常恢复机制，才共同决定了整个长任务能不能顺利跑完闭环。

从用户反馈，到环境反馈

在 Chatbot 模式下，回答得好不好，主要靠用户在前端输入文字来纠错或者补充。但 Agent 的反馈，直接来源于它所处的实际运行环境。

比如在日常的自动化流里：

• 执行代码时：反馈是编译器的退出码和捕获到的堆栈报错。
• 调用接口时：反馈是 HTTP 状态码和返回的结构化 JSON 响应体。
• 操作浏览器时：反馈是 DOM 树的节点状态变更。

真实的运行环境充满了很多不可控因素——接口会超时、网络会抖动、权限会隔离、环境会变化。因此，在开发 Agent 系统时，工程上的难点往往已经不再是如何去调优那几句 Prompt，而是在于后端怎么做好异常处理与容错恢复。

从自然语言，到结构化动作

Chatbot 输出的自然语言主要是为了让人类看懂，语句通顺、逻辑合理就可以。而 Agent 输出的内容，很大一部分是给代码系统去解析并执行的。

当大模型决策要执行“写入文件”或“调用外部 API”这些操作时，它必须输出极其精确的结构化数据，像是标准 JSON 或者特定的 XML 标签。工具的命名、参数的类型、甚至字段的格式，都必须和后端的代码完全匹配，差一个字符都会导致程序崩溃。

这也是为什么现在聊 Agent 架构，大家都绕不开编排层或者说是 Runtime。这层运行时要负责：解析模型的真实意图、安全地分发并调用工具、拿到工具回执后再去更新系统状态，同时还要卡死最大执行步数的上限。没有这层严密的工程外壳包裹，模型就算想法再完美，也根本没办法在数字世界里稳定落地。

从简单的 Context，到状态与记忆

在 Chatbot 里，我们常说的上下文表现为一个线性递增的聊天记录窗口，每次对话把历史记录一股脑全带上就行。但在 Agent 系统中，因为有频繁的工具交互和长周期的任务推进，产生的信息量呈指数级增长。

如果还用老办法，很快就会撑爆大模型的 Token 窗口限制。为了解决这个问题，系统必须引入更工程化的状态管理与分级记忆机制：

• 状态：我们需要引入类似状态机的设计，清晰地记录当前任务走到了哪个分支、哪些子任务已经收敛、哪些中间数据已经就绪。
• 短期记忆：用来精准记录当前执行循环里，上一步工具返回的原始回执和执行上下文，供下一步推理直接使用。
• 长期记忆：通过向量数据库或图数据库，将全局的用户偏好、历史任务的成功路径进行持久化沉淀，并基于语义检索（RAG）在需要的时候按需加载。

从文本幻觉，到行为风险与安全边界

Chatbot 如果翻车，表现形式一般是“幻觉”——也就是生成了事实性错误的文本，或者一本正经地胡说八道。它的副作用基本局限在信息和文本层面，不直接引发系统破坏。

但 Agent 拥有了向外部环境施加影响的“行动权”，它一旦翻车，直接就是高危的线上故障。日常开发中，不得不防备这些真实发生的行为风险：

• 误删或破坏了服务器上的敏感文件或数据库记录。
• 错误调用接口，导致重复发送高昂费用的业务请求，或给用户发了成千上万条垃圾通知。
• 遭遇 Prompt 注入攻击，被恶意指令带偏，把系统内部的机密凭证或敏感数据发送给了外部第三方。
• 在执行循环里陷入了逻辑死循环，一晚上默默烧光你成百上千美金的 Token 资产。

所以，Agent 越被赋予自主行动的能力，系统就越需要建立硬性的安全边界。哪些高危操作必须引入“人在回路”的人工确认？最大重试上限和执行步数卡在多少合适？对外的 API 权限如何做到最小化隔离？这些全变成了硬核的系统安全设计与工程防线问题。

小结

归纳来看，这两者在设计导向上有着本质的不同：

• Chatbot 面向会话过程：它更侧重于单次生成的文本质量、语气是否通顺以及语义对齐。
• Agent 面向最终目标：它更侧重于长任务的最终达成率、执行路径的可控性、以及整个系统的鲁棒性。

如果把一个完备的 Agent 系统拆开来看，它必然是由以下几个核心模块共同拼装而成的：

1. 目标：明确定义任务的终态与判定标准，让系统知道什么时候该停下来。
2. 规划：任务的自主拆解、执行过程中的动态调度与自我反思能力。
3. 工具：让系统能够与外部数字世界交互的 API、SDK 或者是底层命令行。
4. 记忆与状态：工程化的上下文管理、多级数据沉淀与状态流转机。
5. 边界：确保整个执行行为可预测、可审计、且能随时被强制熔断的安全框架。

所以，别被前端那个轻量级的聊天框给骗了。聊天框不再是 AI 的全部，它仅仅是一个交互入口。真正让 Agent 能够稳定运转起来的，是入口背后那一整套跟复杂、动态的环境死磕的后端系统工程。

参考资料

• Haggai Roitman, The Hitchhiker’s Guide to Agentic AI: From Foundations to Systems, arXiv:2606.24937

《夸克》非常好用的免费AI浏览器

下载APP查看