LLM 不是 Agent

LLM 不是 agent。

这句话听起来像是在抠定义，但这个区分很重要。很多关于 agent 的误解，都是因为把模型本体和模型外面那一整圈系统混在了一起。

可以先把 LLM 理解成一个语言引擎。它拿到当前输入，根据这些输入继续生成后面的 token。它可以写一句话、一段代码、一个计划，也可以生成一个看起来像动作建议的结构化结果。

但单独的 LLM 不天然拥有长期记忆，不天然知道当前任务之前发生过什么，也不天然能操作外部世界。产品里看起来像“它记得上次说过什么”，通常是外层系统把历史、摘要、用户偏好或任务状态重新放进了这一轮输入里。

所以 LLM 更像一个每次被叫起来时，拿着当前材料开始续写和判断的语言处理器。它不是一个天然持续在线、天然记得一切、天然会自己做事的员工。

agent 是另一层东西。

一个 agent 至少会把这些东西组织起来：

- 当前目标

- 当前这一轮模型能看到的 context

- 外部 memory

- 可以调用的 tools

- 权限和边界

- 验证、重试和停止机制

- 推进任务的运行循环

所以一句很粗的公式是：

Agent = LLM + context assembly + memory + tools + runtime + permissions + verification

这不是说每个产品都必须把这些模块做得很完整，而是说“能持续完成任务”的能力通常来自这套外层系统，而不是只来自模型本体。

换句话说，agent 是一套运行系统，不是单个模型的别名。

例如用户说“帮我看看为什么测试挂了”。模型本身可以生成猜测，也可以建议下一步。但 agent 系统会决定要不要读文件、跑测试、搜索错误、编辑代码、再重新验证。真正做事的部分，是模型生成意图之后，runtime 调用工具、记录状态、处理结果，再把下一轮需要看的材料组装回模型输入。

把 LLM 和 agent 分开以后，很多问题会变清楚。

“为什么它忘了刚才的约束？”这可能不是模型完全不会，而是当前 context 组装得不好。

“为什么它没查资料就回答？”这可能是 retrieval 或 tool policy 的问题。

“为什么它做了危险操作？”这不应该只靠 prompt 劝模型小心，而应该有 runtime 层的权限和审批。

“为什么它跑到一半越跑越偏？”这可能需要 checkpoint、verification、human review，而不是只换一个更强模型。

真正可设计、可治理、可产品化的重点，很多都在模型外面那一圈系统里。模型很重要，但 agent engineering 不是只问“用哪个模型”，还要问这一轮让模型看什么、能调用什么、怎么执行、怎么验证、什么时候停。

这也是为什么 新概念不是线性学习的。LLM、context、tool、memory、runtime、permission 这些词会互相牵连。先把 LLM 和 agent 这两个地标分开，后面再看其它概念时，整张地图会清楚很多。