Agent 技术栈畅想
畅想未来的 Agent 技术栈
这篇畅想源自和两个朋友的讨论。一个朋友在为 Agent 开发软件基础框架,让 Agent 能够跟各种应用交互,也能够嵌入到各种应用里面;而另一个朋友在思考何为 Agent。
Agent 软件基础框架
在软件基础框架的设计、规划能力上,业内都很佩服苹果的能力,但是除了少数软硬兼备的厂商,大家都知道追随苹果的脚步是死路一条。 苹果在生成式 AI 上算是赶了个晚集,但是这不妨碍苹果起了个大早,把相关的软件基础框架都准备好了。
举个例子, App Intents 原本是为了 Spotlight 和 Siri 赋能的,让 App 开发者提供开放的接口,这样 Spotlight 和 Siri 就可以直接调用 App 里的能力。 而现在,有了 LLM,App Intents 就很自然地可以转化为 Function Calling 的一个函数。这是 Siri 和 Apple Intelligence 的一个独特的优势。
可是优势背后的代价,或者需要的准备工作是什么呢?这和把一个大象装进冰箱差不多:
- 造一个大卖的产品
- 围绕这个产品,造一个生态,让开发者有动力为这个生态添砖加瓦
- 在这个生态里,定义互通的协议,这个互通的协议就是第二个 App Intents
这是以比较封闭,或者说全权掌控的视角来看框架和生态的问题,但是没准有更加开放(而且省钱)的解法呢?
我觉得 WASM 和 WASI 是一个思路。准确来说,应该所 WASI 0.2 是关键。
WASM 是什么?WASI 是什么?
详细的介绍可以自己查,简要的概述如下:
WASM 全称是 WebAssembly,可以理解为一种 Low-level 的字节码。WASM 字节码可以在 WASM 运行时上运行,覆盖了各种 OS 还有浏览器。很多语言(如 Javascript, Rust, Go, C/C++)可以编译为 WASM 字节码,这样各种语言写的程序就可以跑在各种不同的环境里。
WASI 全称是 WebAssembly System Interface。在 0.1 版本里,它定义了 WASM 程序、运行时和 OS 互操作的接口;而在 0.2 版本里,它定义了 WASM 程序之间交互的接口。理论上,编译支持 WASI 0.2 的程序,它们之间可以相互调用,即使它们是用不同的语言写的。
其实 App Intents 相当于一个互操作层,而现在,如果我们把 WASI 0.2 作为互操作层,那么 App, Agent, OS 和硬件之间两两配对的交互都能够用同一个互操作层定义。
想象一下,有一个人形机器人:
- 它的脸部表情、UI 是用 React 写的 App 来定义的,但是 App 本身编译为了一个 WASM 模块
- LLM 在做函数调用的时候,调用的是 WASI 定义的函数,这样 LLM 可以让机器人直接抬起手,即使手部控制器的程序是用 C++ 写的
- 机器人和智能家电做交互的时候,调用的是 WASI 函数,即使家电的控制程序是 C 写的
- 你可以在机器人上添加一个摄像头模块,这个模块的控制代码使用 Go 写的
- 对于人形机器人生产商来说,只要把机器人所有的 API 都用 WASI 定义,这样开发者想用什么语言开发机器人都可以
Agent 的能力框架
现在 Agent 被很多人说的神乎其神,似乎能够解决很多问题,甚至 AGI,但是我觉得 Agent 只是三个大组件的组合:
- 基础模型:具备的能力可能有多模态能力、分析能力、推理和规划能力,以及有效的注意力机制或者说有效的长上下文
- 周边能力:比如能够接入和调用各种工具、API,还有长时记忆,不管是数据库存储,还是模型能够直接修改它看到的上下文,还是 RAG
- 行为定义:这个就是提示词工程需要做的事情
基于这三个大组件,我们会给每一个组件都做安全护栏以及跑分:
- 基础模型:做各种各样的对齐,也有各种各样的跑分
- 最值得注意的是跑分项是 HashHop 以及朱泽园在 Physics of Language Models 里提出的各种指标
- 周边能力:
- 对于工具使用,有各种各样工程的安全实践(例如授权、沙箱等),也有各种跑分
- 对于记忆力,我们可以直接监测记忆的内容,也可以让模型自我反省;但是似乎对于记忆力的跑分还不是很成熟
- 行为定义:主要防范的是提示词注入;跑分测试的是遵循指令的能力
元数据
版本:0.0.1
日期:2024.09.01
版权协议:CC BY-SA 4.0