编程语言SaaSAI算法
重新思考终端 LLMs 和 Agents
本文探讨终端大语言模型（LLMs）与智能体（Agents）的现状与未来趋势。分析了模型能力与限制，包括多模态、推理及规模效应。讨论了云端与终端部署的挑战，如算力资源、隐私保护及成本效益。阐述了 Agent 的核心组件（规划、记忆、工具），并对比了不同交互界面（LUI、GUI、CLI）。最后展望了端云协同模式及厂商模型开放的可能性，为技术决策提供参考。
本文探讨终端大语言模型（LLMs）与智能体（Agents）的现状与未来趋势。分析了模型能力与限制，包括多模态、推理及规模效应。讨论了云端与终端部署的挑战，如算力资源、隐私保护及成本效益。阐述了 Agent 的核心组件（规划、记忆、工具），并对比了不同交互界面（LUI、GUI、CLI）。最后展望了端云协同模式及厂商模型开放的可能性，为技术决策提供参考。
LLM (Large Language Models) 的风头一时无两，席卷万千行业。业内不乏有关于 LLM 的研究和讨论，但鲜有立足终端的视角。团队上半年曾有过对 GPT 进终端的分析，但 LLM 日新月异，旧分析已经不完全跟得上变化了。适逢年底规划季，尝试重新梳理 LLM 的现状，预判未来变化的趋势，希望能为迷茫的同仁提供思考的角度。
非算法出身，如有错漏之处，恳请指正；力争能让 RD、PM、DA 们都能看懂，如果不明处，欢迎讨论；
终端 LLM 应用有一定不确定性，请务必根据自身业务需求做出必要验证后，再做出方案确定；
文档基于 23 年年底的技术现状尝试做出推断，有效期未知，切勿考古刻舟求剑。
下文将分别探讨模型和场景，有一些随性延展，按需取用。
LLM 的设计始于理解和生成广泛的人类语言，而非针对某个特定任务。不同于专攻特定任务的 NLP，出于对语义和语境的理解，LLM 可以进行文本生成、摘要、翻译、情感分析等多样化的工作。这样多元、可泛化、可迁移的能力，使得 LLM 可以作为不同任务的基石，亦即 underlying。
众所周知，当前的 LLM 还没有达到 AGI 的程度，并不是场景通吃，更不是 cost free。本着实用主义的态度，在思考 LLM「怎么用」之前，还得先看看「能用么」 —— 能做什么、不能做什么，以及「好用么」—— 效益几何、成本几何。
那么，开始模型的思考之旅吧。
对于 LLM 的核心能力，笔者有一些可供参考的认知维度：
多模态理解和生成：LLM 能够处理和生成多种不同类型的内容，不仅包括文本，还可以包括图像、音频、视频等其他类型的数据，甚至能够跨越多种数据类型产生更为丰富和复杂的内容。
内建知识：在大量的语料库训练中，LLM 能够学习大量的知识，这种知识可以被视为是模型的内建知识。这使得它们能在回答问题或进行其他相关任务时倾向于生成与已知事实一致的回答。
推理能力：LLM 不仅可以理解并生成语言，还有强大的推理能力。这使得它们能够根据给定的信息，生成新的、有洞见的内容。例如，它们可以根据一个问题的上下文，推理出更加全面和深入的答案。
LLM 的强大之处相信已毋庸置疑，这里仅关注上述维度下，LLM 核心能力存在的问题和局限性：
LLM (Large Language Models)，大是毋庸置疑的。大模型的参数规模在一定程度上披露了模型通过训练所能掌握的知识和规律的上限，此即我们耳熟能详的 Scaling Law。
在特定领域下'small variants'能不能在高质量数据的加持下实现近似大模型的效果，以及如果能，能不能以相近方案覆盖迁移到足够多的领域，直接决定了'small variants'们除迭代频率外的实用价值。微软有研究证实了在高质量数据下，小模型可以匹敌 50 倍于己的大模型。如果'small variants'可用，则至少可以在 MoE 中以成本优势而胜出。但'small variants'能否推而广之尚未定论，有还在等子弹飞的。
'small variants'并不小。
小大之辩未有定论时，最稳妥的选择当然是「全都要」了，这也是一众国内外友商们的共同选择：
| 模型 | 参数规模 |
|---|---|
| Model A | 135b, 1.8b |
| Model B | 175b, 130b, 70b, 1b |
Refs: [Reference].
节内小结：模型大型化和小型化趋势同时存在，关注变化，理性选择。
怎么训练 LLM，最好的介绍莫过于官方文档。面向非科班的综述也有很多，就不拾人牙慧了，只整理一个 take-away 超级省流版：
GPT (Generative Pre-trained Transformer) 是 LLM 主流实现方式
步骤包含：UL (Unsupervised Learning) 预训练海量文本数据，以习得词汇、句子，及复杂的语义信息；
步骤包含：SFT (Supervised Fine-Tuning) 微调以适应特定任务，如指令识别、工具使用等；
可选包含：RLHF (Reward Learning from Human Feedback) 对齐 (Alignment) 输出到人类期望；
UL 的成本相当高，SFT 的成本相对低，在已有 GPT 的情况下，应尽量考虑 SFT 以适应业务场景。
不论是从头开始训练 GPT，还是只做 SFT 微调，都需要数据支撑。UL 可以使用公开数据集来填补，SFT 所需的样本积累恐怕就没有捷径可走，采购专业数据、众包平台打标或 UGC 都是可取的办法。学术领域倒是有一种特别的研究方式，通过调用 ChatGPT 或 GPT-4 来生成样本，经济实惠，足够应付大量的研究应用；但面向商业应用时，是不得此门而入的，OpenAI 在 Restrictions 部分早有申明：
(e) use Output (as defined below) to develop any artificial intelligence models that compete with our products and services. However, you can use Output to (i) develop artificial intelligence models primarily intended to categorize, classify, or organize data (e.g., embeddings or classifiers), as long as such models are not distributed or made commercially available to third parties and (ii) fine tune models provided as part of our Services;
此外，LLM 的数据也符合马太效应 —— 越早上线、能力越强的模型，越能够从用户使用中积累样本， —— 作为数据奶牛的你我都是 OpenAI 数据飞轮中的一份子。
模型的测评也是广受关注的问题，一众模型们分高下需要，业务落地效果评估也需要。通用模型可以挑战 Leaderboard，中文通用模型有 CMMLU，还有 C-Eval 这种'刁难'LLM 的。但通用模型排名高，并不意味着业务效果表现好，需要为业务建立自己的测评集，根据 User Story 设计问题或向用户募集问题都是常见方式，例如，作为天使投资基金的真格就开源了评测集。场景上线之后，则可以使用赞/踩、beam search 多结果选项来进一步收集用户对结果的真实偏好。
既然 LLM 的门槛这么高、投入那么大，能不能不自己 DIY 模型呢？如果具备 SFT 能力，那么所在企业、开源社区的 GPT 模型都是很好的 baseline，使用开源模型时，需要额外关注 license；而如果不具备 SFT 和评估能力，那么采购也是一种选择。LLM 除了门槛高、投入大，还有需求多、好泛化的特点，MaaS、PaaS 都不会缺生意的。
本节将暂时忽略模型落地业务的效果问题，仅讨论模型本身在云端和终端部署时在工程上的挑战和变化趋势。
规模是云端部署的核心挑战，规模压力来源于多方面：
模型：模型的规模本身使得训练和更新需要大量的计算资源，而平台化对多模型的支持还会进一步增加优化难度。高性能计算和分布式优化人才的炙手可热也足可印证市场需求。
任务：云端往往需要同时支撑 B 端和 C 端应用，而涉及专业问题的 B 端业务一般需要比 C 端更长的上下文，进而加重运算负荷。此外，方兴未艾的多模态应用也毋庸置疑是存储和算力资源的黑洞。
吞吐：ChatGPT 上线两月达到一亿 MAU，原因无他，激增的访问量超越了服务器能正常提供服务的极限，吞吐量起伏之剧烈可见一斑。能不能在吞吐压力之下，依然提供稳定的、低延迟的服务，是 LLM 规模化应用的必由之路。
资源是先决条件，也是问题，还是每个人的问题。海外头部企业在 A100 集群上的军备竞赛，H100 集群也已经有相当规模了，之后还有 H200。而 OpenAI DevDay 上日程显示，背靠 Microsoft Azure 也一样标红了每日两段的'look for GPUs'，都缺资源。出于地缘因素，中国企业在资源方面还有天然劣势。
于是，怎么提升资源利用效率，以更低成本 scale up 才是真正的挑战。任何模型的运算成本都可以大致分为计算和 I/O 两类。其中，计算指的是由神经网络中的各层所描述的数学运算，这些计算通常在 GPU 或其他专门的硬件上执行，可以进行大量的并行处理；I/O 指的是运算过程中数据的读取和写入，在模型足够大时，数据需要在显存、内存，甚至磁盘上频繁读写。在 batch 和 context length 的快速增长下，LLM 会很快从计算瓶颈 (compute bound) 滑入内存瓶颈 (memory bound)。于是，优化方案也有如雨后春笋，PageAttention、FlashAttention、低比特的 fp8 或 int4 等都有助于缓解内存瓶颈。
俗话说，软件优化的尽头是硬件。于是，LLM 爆火之后，NVIDIA 股价也水涨船高，但水面之下，AI 芯片大逃杀从来也没有停止：
在 LLM 赛道上能站到最后的，会是 NVIDIA，还是更加 Domain-Specific 的 ASIC 呢？
节内小结：应用多、算的快、回答好、运算省。
在 LLM 出现前，AI 就在缓步从云端向终端迁移，电脑、手机、XR、汽车上的 AI 应用越来越多。终端 LLM 的 AI 三要素似乎也都已齐备 —— 数据方面，终端向来有更丰富的数据；硬件方面，面向的 CPU、GPU 和 NPU 都有处理参数 ≥ 10b 模型的能力；算法方面，10±b 模型在 benchmark 上最高也能取得 60± 的均分。
那么，规模也会是终端部署的核心挑战吗？大概率不是的：
模型：终端设备可以常驻的模型数量是有限的，较可能的情况会是使用一个占据支配地位的 LLM 覆盖较多的场景，再通过量级显著小的 LLM 或 LoRA 或专用模型来优化特定场景。支配地位的 LLM 在短期内应为 10±b 模型，中长期并不排斥可以支持 100b 以上的模型。
任务：生活场景对话的上下文短的居多，而办公场景的长上下文或批量作业又一般可以被宽容占用更长的时间。
吞吐：一般来说，终端设备在单一时刻只会服务少量用户和少量任务，很难构成高吞吐。
那么，提升资源利用效率会是核心挑战吗？终端设备最为突出的特点是环境的碎片化 —— 往上看，高端机配置尚可；往下看，则只有 256MB 内存和闪存，甚至放不下 1b int4 量化的 LLM。在所有设备上覆盖 LLM 注定是不现实的，然而 覆盖设备数 x 单设备效益 = 总收益，没有足够的设备覆盖就无法实现价值的放大。因此，只要选择入局，资源效率优化就是终端 LLM 的核心挑战，需要持续投入以追赶硬件换代的步伐，这也是足以成为壁垒的技术方向。而眼下，参照 iPhone 15 Pro Max 和 Macbook Pro M2 2022 版标配的 8GB 内存，和 CPU/GPU/NPU/AMX 的利用率，可以做的工作显然有很多。
对 Transformer 推理加速感兴趣的可以围观符尧的文章。
那么，单设备效益从哪儿来呢？高通在自己白皮书中探讨了终端和云端在 LLM 中协同工作的三种模式，这里结合个人理解先讨论终端 LLM 的收益来源，再对协作模式做一些补充，终端对 LLM 上下游工程的价值则会在下一章中另外展开。
终端参与 LLM 的收益主要会来源于三个方面：
数据：「越保密、越透明」在 LLM 上也适用。为了有更好的响应质量，LLM 需要知道更多上下文。越是生活化的场景往往也越是需要个性化的上下文，譬如日程、联系人、通讯记录之于私人助理。终端也正可以提供大量个性化、多模态的上下文数据，在终端内闭环 LLM，可以实现数据应用所需的隐私保护。
响应：无网、弱网环境下，终端 LLM 可以提供稳定的响应，在一些场景下，更快有初步的响应也能提升用户体验；在轻量级场景中，终端 LLM 也可以提供更加实时的响应。
成本：终端以分布式运作，除了可以节约 LLM 庞大的运算成本外，在以多模态为主要内容时，也应该可以显著降低内容的传输成本。
终端理论上至少有三种参与 LLM 分工的方式：
推理核心：这种模式下，终端会承担相当比例的任务，但在一定条件下也可以由云端接力完成。脑洞一下，简单点的，可以以上下文长度、精度等为标准，在终端可以满足要求时，仅在终端运算，否则交给云端；复杂些的，让终端 LLM 完成思维链构建或任务分解，把云端用于解决任务的 Remote Agent，逻辑上也不是不可以。
投机采样：这种模式下，终端只会部署一个比目标 LLM 小很多的近似 LLM，且近似 LLM 只需生成一定量的 tokens 供目标 LLM 批量检验，通过检验的 tokens 就可以直接用作答案。在近似 LLM 和目标 LLM 足够协同时，就能取得成本收益。相关原理可以查阅相关论文。
模态转换：这种模式下，终端其实并没有部署 LLM，它只负责交互内容在模态上的转换，例如语音应用中的语音到文字 (Whisper) 和文字到语音 (TTS)。这是终端传统模型的范畴，有相对成熟的方案可以支持，也可以降低云端运算负荷。
题外话。想象一下，作为一个手机用户。想象一下，你愿意让什么样的移动应用占用你 3.5GB/1.5GB/500MB 存储空间？这大约是中小型游戏所需的空间，也大约是 int4 量化 7b/3b/1b LLM 需要的存储空间。每一个移动 LLM 应用开发者都要自问，如果一定要植入自有 LLM 的话，提供的功能所带来的快乐或能免除的苦痛，能否匹敌同等量级的游戏；以及，如果一定是自有 LLM 的话，以存储没有那么寸土寸金的电脑或是 IoT 为起点的话，会不会是更好的出发点。当然，如果你是 ROM 开发者的话，那将是完全不一样的话题。
节内小结：收益 = 覆盖数量 x 单位收益。趟坑期进入，两手都要抓。
ChatGPT 爆火之后，一直有一种声音：所有的 SaaS 都值得重做一遍。那么，如果真的重新做一遍，你会想怎样设计软件的交互？本节将把 LLM 视作黑盒，忽略技术问题，畅想一下未来，例如十年后，AI 的交互界面和硬件载体。
上图是豆包网页和 App 的交互界面。豆包也好，ChatGPT 也好，都可以算作 LUI (Language User Interface)。LUI 并不是新鲜事物了，它的概念早在上世纪六十年代末就已出现了，早几年锤子科技的 TNT (Touch N' Talk) 也可以算做 LUI。比 LUI 更为常见，应用也更加广泛的是 GUI (Graphical User Interface) 和 CLI (Command-Line Interface)。对三者的比较如下：
| 维度 | CLI | GUI | LUI | | --- | --- | --- | | 典型代表 | MS-DOS | Windows、iOS、Android | ChatGPT | | 输入方式 | 键盘输入文本命令 | 鼠标、键盘、触控屏的点击、划动 | 键盘输入语言或麦克风输入语音 | | 输出方式 | 屏幕输出文本 | 屏幕输出图形、文本，可拓展 | 屏幕/音响输出文本/语音，可拓展 | | 使用门槛 | 高，需要记忆许多命令 | 低，所见即所得，操作直观 | 低，自然语言交流即可 | | 功能拓展性 | 加命令即可 | 分割占用图形区域 | 用户自主 Prompt 即可泛化 | | 交互准确性 | 高，确定输入，确定输出 | 中，有一定比例的误触或误操作 | 低，精准描述问题常需要多轮尝试 | | 复杂/规模问题 | 可以实现复杂&规模问题自动化 | 用户交互限制问题的复杂度和规模 | 模型能力限制问题的复杂度和规模 |
应该说 CLI、GUI 和 LUI 各有优长，但同时它们也并不互相排斥，是可以结合使用的。
怎样在需要处理大量文档和结构化数据的专业软件上融入 LLM，给行业打了个样。以 Microsoft Excel 为例，Excel 基本保留了旧有的 GUI，以提供相对直观的功能入口和结构化的图表展示；VBA (Visual Basic for Applications) 脚本 CLI 也得以保留，以优化定制化批处理效率；专家用户依然可以熟练地组合 GUI 和 CLI，达成自己的目标。与此同时，植入 LUI 的 GUI 入口本身就给 LLM 提供了用途指引，GUI 还可以优化 LLM 的结果呈现，CLI 则可以给 LLM 提供 Code Interpreter 环境，LUI 能够为专家用户提供全新的功能组合，例如生成表格的数据分析结果；LUI 还可以显著降低萌新用户的使用门槛，让他们能够通过语言，实现对 GUI 和 CLI 使用的替代。
不过，引入 LUI 大概率也无法改变专业软件对硬件载体的适配性 —— 即使做了结构化的结果呈现，也需要足够的展示区域作呈现哪！电脑、平板依然会是专业软件的主流载体，而 XR 的无限屏显和立体展示能力也很有想象空间。
LUI 在软件中的占比很可能会逐步提升，对于 AI native 软件则可能会成为标配。任何有一定操作复杂度或是学习门槛的软件都应该重新思考是否引入 LUI 扩大自己的受众范围或降低复杂功能的使用成本。
日常应用就无需应付成规模的复杂任务了，那么，时下流行的 Chat App 是最优的交互界面和硬件载体么？
先看看输入。识别够准确的话，最简便的语言输入还是语音，不方便语音的场合，键盘也能够 backup，中短期看，手机应该就够用了。但如果使用频率进一步提升呢？手表类的可穿戴设备是不是更好的硬件载体？再进一步，你会为了全天候伴随的私人助理保持麦克风的开启吗？再再进一步，如果多模态 输入能大放光彩，你会愿意让摄像头也全天候开启吗？如果是的话，手机肯定是不够用的，那时，你会使用类似 Vision Pro 的 MR 头戴设备，还是，甚至是更赛博朋克的眼球义体？
再看看输出。即便不像输入端那样天马行空，LUI 为手表屏显、手机屏显和耳机播报所输出的文本显然是可以有所区别的，类比 GUI，相同的天气 App 在不同设备上所展示的信息就有显著的差异；而体裁上，文字的表达力有时并不那么直观，例如，当问及 H20 分子结构时，一个立体动画可能胜过千言。能选择合适的体裁和内容时，相信 LLM 也能更好地应用于 MR。
除了推理运算外，另一个倍受关注的 LLM 应用是 Role Play，角色扮演。Character.ai 和 Replika 都可以归入这个分类，你可以要求 LLM 扮演某个角色，例如琳娜贝尔、特朗普，或者乔达摩 · 悉达多，交谈常常是灵感迸发或自我开解的源头。而如果 LLM 的扮演得当，它完全可以作为你的私人秘书、法律顾问等，甚至你还可以允许 LLM 扮演你自己，作为与其他人或者 Agent 的初步磋商，例如日程订立等。真到这一天的话，或许可以管它叫 Agent 元宇宙时代。而有一个灵魂拷问：如果有一天，你有一万个可以为你工作的程序员 Agent，你能做些什么？
Note: 或许可以看作对 👆 这个问题的回答。
上边的角色扮演都还是虚拟世界的存在，应用 MLLM 是可以帮助 IoT 打破次元壁来到你身边的。事实上，类似的尝试已经有了 —— 比如某些智能音箱。那么，再过十年，先撇开特别激进的，你会愿意家里有一个可以包干家务的人形机器人吗？如果觉得有点怵，那么老人看护机器狗，或者是被 LLM 开了光的毛绒皮卡丘呢？
很多人会把 LLM 比作大脑，是一个能够思考运作的黑盒。然而，通用 LLM 这个大脑其实并不包含自己的目的和场景上下文，目的和场景讯息是通过 Prompt 植入的。从这个意义上说，补全了目的和场景的，就可以算作是 Agent。只不过，目前通行的 Agent 定义有更加严苛的要求。那么，这些附加的要求是为了解决什么问题呢？为什么？以及，在这样的宏达叙事中，终端到底能做些什么？Let's go on.
人类的知识总能靠文字承载，所以从理论上说，不存在 LLM 不能应用的场景。但出于现阶段 LLM 自身能力限制的考虑，因慎重选择将 LLM 应用于自动化流程的中间过程，可以用于流程的输入或输出点，再加入必要的人工干预。至少在 LLM 的综合收益能显著高于风险期望前，有必要保持这样的审慎。
这里依然从多模态 理解和生成、内建知识、推理能力这三个维度出发，梳理一下行业中已经有的探索。在实际应用中，往往会同时涉及到多个维度。梳理并不全面，仅供激发灵感。
| 维度 | 场景 |
|---|---|
| 多模态理解和生成 | 内容理解。LLM 对语言的理解能力是毋庸置疑的，出错乌龙都有，但在部分测评中甚至强于人类战力标杆大学生的；多模态则是倍受期待的下一个方向。举一个激进一点儿的例子，虽然不一定靠谱，但敢想的确实已经在评估。 |
| 多模态理解和生成 | 安全风控。新闻文章、直播弹幕、商品评论都能搞，召回能准，除了明显的合规问题之外，适配地区法规，按照社区画风抓捕阴阳怪气也完全是能做到的。多模态同样值得期待。AIGC 时代的内容安全，AI 是缺不了席的。各个大厂的安全风控团队应当都是 LLM 的早期用户了，有效提升效率，降低人工成本。 |
| 多模态理解和生成 | 摘要总结。新闻摘要、弹幕精选、评论总结都很常见。 |
| 多模态理解和生成 | 辅助创作。画题图、写小说、写剧本、写代码、写邮件一应俱全，剪视频可能也就在远方不远了，刺激吗？除了生成新内容外，对已有内容的结构化整理也会十分有益，例如时间线、关系图等；还有对内容的审订，例如语法纠错、bug 识别等。 |
| 多模态理解和生成 | 语音合成。虽然可能不是 LLM based，不过相关且有意思，就还是贴上来。包含情绪的 TTS；风格迁移的 STS。声优妖怪们单刷全角色配音会不会不远了？番茄小说、微信读书会加上小说配音的情绪么？ |
| 多模态理解和生成 | 实时翻译。LLM 的翻译能力，尤其是俚语和上下文翻译上是要强于 Google Translate 的。你可能没听过，但我猜你大概率刷到过这就是流浪地球 II 的实时同声传译耳机啊，想要！ |
| 内建知识 | 问答系统。作为智能客服提供用户咨询、问题解答等服务，提高效果，节约人力。To C 的各家都在做，上线没上线就吃不准了；To D 的 … Oncall/WiKi GPT 还少嘛？ |
| 内建知识 | 交互式搜索。从某种意义上说，目前的搜索引擎们可能都还不能算作 LLM 意义上的交互式搜索，交互多是允许用户根据搜索的结果进行问答，而不是根据用户交互理解用户的意图，进而调整搜索的结果本身。 |
| 内建知识 | 教育辅导。为学生在学习过程中提供帮助，比如解答问题、提供学习材料等。在英语对话练习中，就提供了语法纠错和错误解析。 |
| 推理能力 | 角色扮演。除了上文提到的、和机器人之外，另一个被广泛关注的方向是数字人，搭一个 2D 纸片人 LLM Vtuber 已经有一打的开源 repo 和教程了。 |
| 推理能力 | 数据分析。医疗、教育、金融等行业都有需求，展示过 Excel 的报告分析能力，如果有行业知识参与模型 finetune，效果还可能更好。 |
| 推理能力 | 内容推荐。LLM 可以用于深化对用户兴趣和媒体消费习惯的理解，从而提供更精准的个性化内容推荐，相关探索可以参考。 |
在这些场景中，有不少只需要用到最基本的 LLM 能力，例如翻译或是摘要；但教育辅导这样需要多轮对话的场景，就需要在 LLM 有专门的工程建设了。
上图是 LLM Powered Autonomous Agents 这一年的表现，三月之后「LLM Agent」在中美逐步升温。然后，OpenAI 亲自下场做 Agent 工程，市场上一时一片哀嚎，RAG (Retrieval-Augmented Generation) 创业公司纷纷表示可以散伙了。那么，究竟什么是 Agent？做 Agent 工程真的没有前途了么？
Agent 的故事可以一个神奇的咒语讲起：
1. 规划（Planning） • 子目标和分解：AI Agents 能够将大型任务分解为较小的、可管理的子目标，以便高效的处理复杂任务； • **反思和细化：**Agents 可以对过去的行为进行自我批评和反省，从错误中吸取经验教训，并为接下来的行动进行分析、总结和提炼，这种反思和细化可以帮助 Agents 提高自身的智能和适应性，从而提高最终结果的质量。
2. 记忆（Memory） • **短期记忆：**所有上下文学习都是依赖模型的短期记忆能力进行的； • **长期记忆：**这种设计使得 AI Agents 能够长期保存和调用无限信息的能力，一般通过外部载体存储和快速检索来实现。
3. 工具使用（Tool use） • AI Agents 可以学习如何调用外部 API，以获取模型权重中缺少的额外信息，这些信息通常在预训练后很难更改，包括当前信息、代码执行能力、对专有信息源的访问等。
Refs: LLM Powered Autonomous Agents
Note: 单次输入实际可能调用多次 LLM 这个事实，恐怕是最多圈外人理解复杂任务如何靠模型实现的最大遗漏。
Note: Agent 的多轮调用会显著放大 LLM 开销，同时，big one 一轮 vs small variants 多轮哪个效果好还未可知。
Note: 测评 Agent 能力时，一种思路是分别测评它在任务分解、反思细化、记忆取回和工具使用上的能力。
Note: Agent 和 Multi-Agent 的最佳范式都还未出现，且不排除会 scene by scene，stay hungry & stay foolish.
OpenAI 是以 AGI 为愿景的公司，现在的 Agent 在一定程度上可以看作 AGI 的代偿 —— 除工具使用外，规划和记忆本是 LLM 所应覆盖的范畴。如果 LLM 自身能力增强，一切还可能重新洗牌。不过在那之前，Retrieve 和 Task Decomposition 应该会长期把持 LLM 显学的位置。想要了解技术细节的同学，都建议全文刷完 LLM Powered Autonomous Agents 的原文或译文。PM 则可以采用略版译文。
Agent 是角色和目标的承载，LLMs、Plans、Memory 和 Tools 服务于角色扮演和目标实现。那么，自然的，服务于相同或相关目标时，多个 Agent 之间可以共享 thread context，但需要保持自身权限的独立，即 Multi-Agent。举一个 GPT4 给的例子：
假设我们有至少 3 位 Agent，A1 是购物助手，A2 是库存查询员，A3 是物流助手。
（此时，购物助手把线程共享给库存查询员）
（此刻，A1 再将线程同时分享给 A3 物流助手进行查询）
例子中的用户信息、库存、物流访问权限应当被隔离，如果存在多用户，用户间的数据也需隔壁。LLM 系统攻防是个新鲜问题，Open AI 已经有过多起泄露 Prompt、数据、文件的事例了，工程绝非易事。
补一个细思恐极的事儿：ChatGPT beta 测试允许在主 GPT 中'记忆'或'遗忘'历史对话内容，比如 Code Interpreter 的语种偏好等等。如果做不到精确无误的记忆取回，这会是有点儿危险的功能；如果能做到，这就是终身助理的一大块拼图了。
回到 Agent 工程的前途，这是一个带有 threshold 的问题。GPTs 接口的背后，是 OpenAI 为 Agent 实现的 Retrieve、Task Decomposition 和向第三方开放的 Plugins。在假定 LLM 不会很快突破能力限制的情况下，牌桌上的超级玩家们无疑是要自建 Agent 工程的，不论是 To B、To C 还是 To D。如果你既做不出更好的 Agent 工程，核心业务又可以在超级玩家的平台上运作，那么用 Assistant 们就是了；否则，还铆足劲学着搞吧。
节内小结：Agent = LLMs + Plans + Memory + Tools
GPTs 开发 Assistant 的便捷程度，让许多人惊呼。但实际上，GPTs 更多是提供托管部署的开发平台，提供 LLM finetune、Prompt 定义、Plugin 可选集成的开发环境，并隐藏了 Retrieve、Task Decomposition 和 Tool Use 的实现细节；GPTStore 才是市场，但目前而言，模型、Agent 的交付、分发、计划规则都还尚未明确。
可以对几类典型的应用生态做个另类比较，探一探深浅：
| 分类 | 移动应用 | 小程序 | 快应用 | Agent |
|---|---|---|---|---|
| UI | GUI | GUI | GUI | LUI |
| 开发内容 | - iOS 代码
- Android 代码
- 鸿蒙代码 | - XML
- CSS
- JavaScript | - HTML
- CSS
- JavaScript | - LLM
- Prompt
- Plugin |
| 开发者 | 程序员 | 程序员 | 程序员 | 有语言表达能力的人 |
| 场景泛化能力拓展 | - 数据一般有固定来源，逻辑和呈现则固化在代码中
- 通过版本迭代实现场景和能力的拓展 | - 数据一般有固定来源，逻辑和呈现则固化在代码中
- 通过版本迭代实现场景和能力的拓展 | - 数据一般有固定来源，逻辑和呈现则固化在代码中
- 通过版本迭代实现场景和能力的拓展 | - 可通过 Prompt 实现 In-Context Learning 拓展逻辑
- 可通过 Plugin 实现工具拓展 |
用 Andrej Karpathy 的话说：这是 Software 1.0 和 Software 2.0 的竞争。
个人观点，欢迎飞砖：
LUI 的超低开发门槛、跨场域组合数据和工具的能力是未曾有过的存在，这是个新物种。如果 Agent 能服务好个性化需求，它的长尾会远远长于其他生态，作为流量入口的价值也会异常惊人。
除了由 LLM、Retrieve、Task Decomposition 决定的 Agent 工程效率之外，生态之间能分高下的地方在于可以整合的数据和工具的多寡，即「数据在哪儿」和「工具在哪儿」。
从数据在 Query、Agent、Plugin 之间流转的角度考虑：
节内小结：新生态，低开发门槛，破 GUI 型业务数据壁垒。
在 llama.cpp、llamafile 这样的 OS 相关项目出现之后，LLM OS 的概念被越来越多的提及。在围观 llama.cpp 之后，Andrej Karpathy 也在课程专门讨论了 LLM OS。LLM OS 利用传统 OS 能力实现 Agents 的本地化，并有如下增益：
LLM OS 的概念诞生于 OS，除电脑 OS 外，移动端的 iOS、Android 也是适用的，也已有厂商超此方向前进了。
Refs: llama.cpp & llamafile
Note: llama.cpp 中
ask_human_for_help这样'调用'人类协作的指令应适合终端。
一个有意思的讨论是，电脑 App 或移动 App 能否直接套用 LLM OS 的概念。或许也可以，只是限制多一些：
看起来，电脑 App 或许可以涉险过关，移动 App 只能静候天时了？
不尽然。模型存储看似是不可逾越的难题，但实际上，不论是系统级还是应用级的 LLM OS，都不一定需要终端真的可以支持 LLM 部署 —— Agent 内的端云协同即可，且至少有两种模式可选：
终端 Agent 模式。仅将云端用作 LLM Engine，Agent 主体依然在终端实现，记忆调取、任务分解、队列维护、工具调用依然在终端。模式在 Prompt 传输时，会带来隐私泄露的风险，因而需要更多依赖本地工具，如 Code Interpreter，完成核心数据处理，仅传输数据元信息。在 Multi Agent 设计中，终端 Agent 可以承担起 User Proxy Agent 的职责，负责与用户的交互。
云端 Agent 模式。仅将终端视作分布式的记忆和工具环境，终端提交 Query 时还需包含 Memory 和 Tools 的元信息，已备云端 Agent 查询和调用。模式可以权衡利用两端的存储和工具，最优化工程效率，但无疑会让渡更多的控制权给云端，因而隐私泄露风险也需要更加慎重地考虑。
终端在数据和工具方面，还是有自己独到的地方的：数据方面，终端可以提供瞬时和短期数据，如当前设备环境和用户近期的交互操作；工具方面，终端可以提供 Code Interpreter 沙盒，能极大增强终端的数据处理能力，日历、地图、支付等应用也无疑能补全众多业务的功能依赖。
不论是哪一种方式，都可以提升 LLM OS 模式的设备覆盖率，进而扩充系统可以整合的数据和工具，但代价则是系统复杂度和隐私泄露风险的提升。
在应用上搭建 LLM OS 会收到诸多限制，但这并不意味着应用生态一定不如系统生态，快应用与微信小程序之争就是先例，能够赋能第三方的数据、工具和流量才是生态竞争的根本。
节内小结：最大化整合数据和能力。
应用难承载 LLM 的问题，我们已经在前文中两次提及过了。一个有意思的问题是，厂商们已经纷纷在最新的系统中内置了各自的 LLM，且 OPPO 等厂商已经明确要进军 Agent Store，在这种情况下，厂商们会为了最大化生态效益，而在终端上作一定程度的开放吗？尤其在应用可能可以借助 Agent 能力另立生态的情况下？
作为 Plugin 接入生态的问题，已经在前文有过讨论，这里仅讨论应用对厂商 LLM 能力的利用，如下：
实际的开放情况会是如何还有待观察，或许最快也要到 24 年的晚些时候，我们才能看到厂商在这部分的动作。
子曰：「君子不器」。遇到变化要变通嘛。
LLM 在知识领、记忆能力方面甚至是能超越人类顶级专家的存在，再加上身为硅基生物的不知疲倦和超大规模并发信息处理的能力，作为碳基生物的我们应当避免在这些方面与它们正面竞争，人类还领先于 LLM 的地方在于：
目标设定：在拥有自我意识之前，人才是赋予 LLM 目标的存在，记得 Prompt 里写的 goal 么？
敏锐的感受：哪怕 MLLM 掌握了文字、图形和声音，你也还有色声香味触法，掌握着更完整的 Ground Truth；
结构化思考：目标的分解、工作的组织、与人的协作，别让 LLM 的 Task Decomposition 轻易淹没自己；
不受约束地使用工具：超级 Agent，对吧？
就像自行车是人双脚的外延一样，把 LLM 也当作人体的外延吧！只不过这次外延的，是我们的脑子罢了。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online