从今年4月出现 AutoGPT 以来，AI 行业就开始把注意力聚焦在 Agent 上，并试图让它产生一些实际的用途。

虽然创业者和投资人当时都还无法给出 Agent 确切的定义，只知道 Agent 应该是规划+记忆+工具组合在一起的东西。

直到11月 OpenAI 发布 GPTs 和 Assistants API，把 Agent 最核心的定义补完。

为什么聊天机器人不是 Agent？

为什么 New Bing 不是 Agent？

为什么 GPTs 和 Assistants API 是 Agent？

何以为智能？

人最厉害的是什么？使用各种工具。

这是在四月思考 AutoGPT，从手脚到大脑 时对智能的理解。

所谓的人工智能，如何体现智能？知道如何使用各种工具。

而 Agent 落地最难的就是「知道如何使用各种工具」，还原到应用层面就是「知道如何调用函数」。

但是从4月到12月，我们看到的实际有用的 Agent 很少，这其中的原因很多，最大的原因是：

LLM 具有不可控性。

你可以使用通用的 Agent 架构制作演示，或许还可以制作简单的玩具应用。但是当需要提高性能并进行大规模运行时，你会发现它非常不可靠。

既然通用的 Agent 架构仍然不可用，一个 AutoGPT 不可能解决所有问题。开发者只能根据实际的场景去选择和构建合适的认知架构。

认知架构的含义

LLM 的认知架构是什么呢？

认知架构指的就是 LLM 应用的编排。

编排：把事物以一定的方式组织起来，按照既定的顺序或模式安排。

Agent 认知架构与其他架构的核心不同是：

LLM 自己来定义转换的选项。
LLM 会决定它需要什么上下文，然后去索要它。

要说明白这两点不同，需要从认知的架构的不同层次说起。

认知架构的不同层次

具有丰富开发者合作经验的 Langchain 团队，对认知架构的层次做了很好的梳理。

开发者目前正在构建不同层次的认知架构，包括以下几种：

  1. Code，人类决定输出、人类决定步骤、人类判断结果
  2. LLM，一个单独的LLM调用，只决定应用的输出
  3. 链路，一系列的LLM调用，也只决定应用的输出
  4. 路由，LLM作为路由决策，用于单向判断即将执行的动作/Action（tool，retriever，prompt），没有循环
  5. 状态机，LLM作为路由决策，各种步骤处于循环之中，但是每个步骤的可转换选项都是由 Code 定义的。
  6. Agent，应用的输出、路由决策、以及所有可能的转换选项，都是由 LLM 自行决定的。

An image to describe post Agent 到底是什么？

Agent 认知架构与其他架构的核心不同是：

LLM自己来定义转换的选项。

Agent 认知架构的详解

对于非 Agent 认知架构，以简单的搜索为例，虽然也有多种工具的调用，但总体是一个线性过程：

  1. 用户输入内容
  2. 调用LLM
  3. 将用户输入转换为搜索 Query
  4. 用搜索 Query 去请求搜索 API
  5. 将搜索 API 返回的结果进行总结
  6. 将总结好的内容传递给用户
  7. 链条结束

而对于 Agent 认知架构，是这样的：

  1. 用户输入内容
  2. 进入一个循环
  3. 调用 LLM
  4. 调用的结果：回应用户 or 执行动作？
  5. 如果结果是回应用户，那就将结果传递给用户，并结束循环。
  6. 如果结果是采取行动，那就执行动作，并观察行动的结果
  7. 这个动作和观察的结果会被添加到 Prompt 中，产生一个「Agent 草稿本」
  8. 循环从头开始
  9. 将 Agent 草稿本作为输入
  10. 调用 LLM
  11. 调用的结果：回应用户 or 执行动作？
  12. ……

An image to describe post Agent 到底是什么？

可见，两个认知架构在具体步骤中的显著不同：

  1. Agent 架构会让 LLM 判断 ：回应用户 or 执行动作？，而链条架构里，每个步骤都是单向的，且每个步骤的选项都是人来定义的。
  2. Agent 架构会让观察行动的结果，并存储在「Agent 草稿本」，并在下一轮循环中，让 LLM 根据「Agent 草稿本」来做新的调用。而链条架构中，上下文的使用规则都是人来定义的，Push 而非 Pull。

至此，应该可以理解，Agent 认知架构与其他架构的核心不同是：

LLM 自己来定义转换的选项。

Agent 认知架构与其他架构的第二点不同是：

LLM 会决定它需要什么上下文，然后去索要它（Pull, not Push）。

GPTs 和 Assistant API 和 Agent

GPTs，面向用户，用户无需代码即可创建LLM应用，可以自定义指令、自定义知识库、自定义函数。

Assistants API 则是面向开发者的 GPTs。它是一个有状态的 API，可以存储上下文、上传文件、使用内置工具（如代码解释器），使用外部工具（通过函数调用）

两者的面向用户不同，但本质上是一套认知架构。

Function calling 函数调用

Similar to the Chat Completions API, the Assistants API supports function calling. Function calling allows you to describe functions to the Assistants and have it intelligently return the functions that need to be called along with their arguments.

与聊天API类似，助手API也支持函数调用。函数调用允许您向助手描述函数，并智能返回需要调用的函数及其参数。

The Assistants API will pause execution during a Run when it invokes functions, and you can supply the results of the function call back to continue the Run execution.

当助手API在运行时调用函数时，它会暂停执行，并且您可以提供函数调用的结果以继续运行执行。

它们的核心是 Agent 认知架构。

LLM 自己来定义转换的选项。（选择函数或生成文本）
LLM 会决定它需要什么上下文，然后去索要它。

用户在创建 GPTs 的过程中，会发现它创建起来非常简单，只需要描述清楚自己的需求，添加必要的工具，其余的编排和路由都交给 LLM 。

这其实就是 AutoGPT 在4月做的，但是没做好的事情。

结语

所谓的人工智能，如何体现智能？知道如何使用各种工具。

而 Agent 落地最难的就是「LLM 知道如何使用各种工具」。再还原到应用层面就是「LLM 知道如何调用函数」。

虽然看似是一个朴实无华的目标，为了让LLM学会这点，OpenAI 做了不少的工作。

半年以来，OpenAI 推出了 Function Calling 和 Plugin，通过学习数以千计的实际场景，在用户和客户驱动的过程中同步完善和积累技术。

AutoGPT 没做好的事情，OpenAI 最有可能做好，一方面是因为他控制着最强底层模型，另一方面则是学习了最多的实际应用场景。

即便现在还做的不够好，也会随着时间的和技术的进步而做得越来越好，因为GPT5已经在路上，也因为LLM的实际应用场景会越来越多。

全文完