为什么仅有LLMs并非智能体

Source: Dev.to

Introduction

大型语言模型（LLM）功能强大，但单独把它们称作“代理”是一种范畴错误。这种混淆在真实项目中屡见不鲜，尤其是当人们期望一次提示就能像一个能够推理、行动、适应的系统一样工作时。如果你已经构建了超出演示的东西，可能已经碰到这堵墙了。

Core Behavior of an LLM

从本质上讲，LLM 只执行一项工作：

给定一系列 token，预测下一个 token。

其余的一切——推理、规划、解释——都是该过程的涌现行为。

Important Constraints

• 模型 没有记忆，只能记住提示内容。
• 它 不知晓结果。
• 除非你向它提供观察信息，否则它 无法感知世界。
• 除非你显式地接线动作，否则它 不能行动。
• LLM 并不会“决定”去做某事；它只会在被询问时生成描述决策的文本。

What People Expect vs. What Happens

当人们把 LLM 当作代理时，通常期待它：

1. 决定下一步该做什么
2. 验证自己的输出
3. 从错误中恢复
4. 适应新信息

这些都不会自动发生。LLM 会乐意生成：

• 一个从未执行的计划
• 一个在不知道失败的情况下的修正
• 一个缺少数据却自信的答案

因为它 没有反馈回路。

Agency Requirements

代理来源于控制流，而不是语言生成。一个代理需要：

• 一个 目标
• 一个 循环（迭代）
• 它能够执行的 动作
• 用于跟踪进度的 状态
• 用于调整行为的 反馈

LLM 默认不提供上述任何东西。

Planning Is Not Agency

让模型“逐步思考”并不赋予它代理能力；这只是让它在文本中模拟推理。一旦输出生成，模型的工作就结束了。

一个常见的误区是把规划等同于代理：

1. 你问模型：“制定解决此问题的计划。”
2. 它生成了一份整洁的多步骤计划。

但随后什么也没有发生。模型：

• 不会执行这些步骤
• 不会检查步骤是否成功
• 不会根据结果修订计划

没有执行和观察，计划仅仅是文本。

Tool / Function Calling

即使使用工具调用，LLM 本身仍然不是代理。

为什么？ 因为模型并不：

• 决定何时停止
• 强制执行约束
• 验证工具输出
• 智能地重试

这些行为必须在 模型之外 实现。

Common Architectural Mistakes

最常见的错误是期望模型管理：

• 状态
• 错误
• 重试
• 成本
• 安全

LLM 不是状态机。当系统出错时，通常是因为：

• 没有最大步骤限制
• 未定义失败模式
• “代理”一直在“思考”却没有进展
• 没有人能解释决策的原因

这些是 系统设计问题，而非 AI 问题。

Embedding an LLM in a Loop

只有当 LLM 被嵌入到一个循环中时，它才成为代理的一部分，该循环：

1. 提供观察信息
2. 接受决策
3. 执行动作
4. 更新状态
5. 决定何时停止

代理就是这个循环。LLM 只是根据当前上下文生成文本的组件。

Reframing the Question

与其问：

“模型能做到这点吗？”

不如问：

“我允许模型影响哪些决策？”

这种重新表述迫使你思考：

• 边界
• 权限
• 失败模式
• 可调试性

并帮助系统保持稳定。

Conclusion

LLM 是强大的推理引擎，但代理并非仅凭智能就能产生。它来源于 结构、反馈和限制。把模型视作组件，而不是演员。当你这样做时，具备代理特性的系统不再神秘，而是可以构建的。