Agents Need “State” Instead of “Memory”
Link
正如我在此文中所提及，当我们设计 agent 的时候，我们最终想要的是一个无所不能的超级函数：给定输入，获得输出，中间产生一些副作用。
但作为程序员我们都知道，函数还是一个比较低级的抽象，在业务场景下表达力不够强。这其中的一大原因是：函数自己是不维护状态的，它只能通过产生副作用来改变外部状态。为了解决这个问题，现代软件工程有两种解法：一是 continuation 或称 coroutine，二是 object 或称 OOP。后者显然由于其更贴近业务建模而更流行。
那么我们怎么把 agent 从“超级函数”升级为“超级object”？熟悉大模型应用的朋友们或许已经想到了，那就是给 agent 加上 memory。
使用 memory 一词的时候我们不妨想想，到底有什么是值得记忆的？比如，作为终端用户来说，我希望我的 chatbot 能记住我们之间每一次对话的每个细节，这是一种 memory。但是如果我的 agent 要处理一个特定的任务，它一轮一轮地调用 tools，它用 memory 记住每一个 tool 的每一个具体输出，这有价值吗？
由此看来，tools 的输出对于 agent 来说更像是 log，而 agent 真正需要的答案藏在 log 当中，那些将影响 agent 下一轮行动的信息，才是 agent 内在需要记忆的信息。
因此相比于 memory，我们应该换一个词称呼它：state。agent 在每一轮运行过程中，它首先根据自己的 state 做出决策、调用工具，然后根据 tool output 更新自己所处的 state，再进入下一轮运行。就像一个寻路机器人要知道自己在迷宫中的位置及先前探索过的路线，然后据此做出下一步移动。
而 memory 一词所描述的，指的大概是将 agent “所观察到的所有的历史”，完整地视为 agent “所处的 state”。当我们讨论在开放世界中活动的 AGI agent 时，这确实是最 general 的理解。
但如果我们想要一个解决问题的“工业机器人” agent，这种 memory 既不符合我们欣赏的软件哲学，在技术上也值得质疑。“工业机器人” agent 需要设计的是 state。
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.