大模型 Agent 就是文字艺术吗？

最近在技术圈里有一个很有趣的争论：大模型 Agent 是不是就是各种 Prompt 的堆叠？像 Manus 这样看起来很智能的 Agent，本质上是不是就是用巧妙的 Prompt 约束大模型生成更好的输出？换句话说，这是不是一门文字艺术？

这个问题引发了业内专家的激烈讨论，观点分化明显。让我们来看看不同的声音。

两大阵营的观点碰撞

观点一：就是文字艺术，没必要遮遮掩掩

有开发者直言不讳地表示："没人敢说实话吗？是的，就是各种 Prompt 的堆叠。"另一位实战派开发者更加犀利："LLM 的 input 就是 prompt，不管什么工具或模型，都只是优化 prompt。大把人把'优化 prompt'的工具吹得云里雾里，却有意无意回避其目的还是只是生成更好的 prompt。"

这种观点认为，Agent 可以看做 prompt engineering 的升级版。核心在于如何具体设计 prompt，如何拆分，顺序是什么。其他那些复杂的架构设计，在他们看来都是在"象牙塔里扯淡"。

观点二：远不止文字游戏这么简单

但技术专家们显然不买账。有人从工程角度分析："生产级别的工程显然不仅仅是 Prompt 这么简单。"以 OpenHands 为例，对接 LLM 只是其中一个模块，真正驱动 Agent 完成复杂任务的核心，是一整套事件驱动机制，包括状态机、事件流框架、控制器等等，还用到了像 Sandbox 这样的沙箱技术。

另一位专家总结得更加全面："真正可用的 Agent = Prompt（语言接口）+ 程序化编排 + 长期状态/记忆 + 外部工具动作 + 自反馈循环。缺少任何一环，都会从'自治智能体'迅速退化成'高级聊天机器人'。"

Agent 的本质是什么？

从技术定义来看，Agent 本质上是一个循环系统。对于一个给定目标的 AI Agent，它能够自己创建任务、完成任务、创建新任务、重新确定任务列表的优先级，并循环直到达到目标。

用公式表达就是：Agent = LLM + Planning（计划）+ Tool use（执行）+ Feedback（纠正偏差）

这个定义揭示了一个关键点：Agent 让 LLM 具备了目标实现能力，通过自我激励循环来完成给定目标。

关键在于状态管理

有一个被很多人忽视的技术细节：现在几乎所有的大模型 API 都是无状态的。大模型 API 连鱼的七秒记忆都没有，它甚至记不住自己上一次的回答是什么。

那为什么我们在 AI 聊天工具里能看到它"记住"了历史对话呢？实际上，是把以前的历史会话每次都重新传给大模型一遍，让它看起来有了记忆。这就是把无状态的 API 做成有状态的样子。

随着应用复杂化，状态管理变得越来越重要。真正厉害的 Agent 拼的其实是状态管理能力。

Prompt 的真正作用

一位分析过 Manus 和 OpenManus 项目结构的开发者指出，Prompt 确实很重要，它可以在不微调大模型的情况下，根据先验知识引导大模型行为，达到期待的业务效果。

但关键是：Prompt 是 Agent 系统中大模型和其他各个组件的润滑油，而不是全部。

以 OpenManus 为例，其结构主要包括：

Prompt 只是其中一个组件。

技术的进化逻辑

从技术发展的角度看，这场争论其实反映了不同阶段的认知差异：

初级阶段：确实主要靠 Prompt 工程，通过精心设计的提示词让模型表现更好。

中级阶段：开始引入工具调用、多轮对话、简单的状态管理。

高级阶段：构建完整的事件驱动系统，包含复杂的状态机、内存管理、自主规划和执行能力。

企业级阶段：需要考虑并发、容错、监控、安全等工程化问题。

结论：既是也不是

回到最初的问题：大模型 Agent 是不是文字艺术？

答案是：既是也不是。

从某种意义上说，所有与 LLM 的交互最终都要通过文字（Prompt）来实现，这确实是一门语言艺术。设计好的 Prompt 需要对语言有深刻理解，需要巧妙的措辞和精确的逻辑。

但将 Agent 简单等同于 Prompt 堆叠，就像说建筑就是砖块堆叠一样——技术上没错，但忽略了设计、结构、工程等更重要的层面。

真正的 Agent 系统需要：

写在最后

这场争论的价值不在于谁对谁错，而在于推动我们更深入地思考 AI Agent 的本质。

对于初学者，从 Prompt 工程开始确实是一个好的起点，它能让你快速理解如何与 AI 交互。

对于有经验的开发者，则需要跳出 Prompt 的局限，从系统工程的角度思考如何构建真正可用的智能体。

技术的进步往往就是在这样的争论中螺旋上升的。无论你站在哪一边，都要承认：我们正在见证一个激动人心的技术变革时代。

你觉得大模型 Agent