[!note] 旨在解决的问题- Agent 的分析框架：从底层技术出发，不同 agent 只是有限技术的不同组合。 - 搞清楚这一点，我们在看到新的 agent 项目时，就能迅速判断他到底做了哪些工作。 - Agent 的核心技术和能力边界在哪？做到了哪些原来不能做的，还有哪些是短时间做不到的？ - Agent 能力的底层锚定物是什么？业务理解？数据？工程师团队？——发掘潜力企业，or 互联网大厂？ - Agent 在未来的技术拐点有哪些？要关注哪些信号点。
前言 ： 关于 Agent 的研究思路
目前市面上自称“Agent”的产品很多，不同的人对 Agent 的定义都略有不同。一部分人认为能采取行动的、给大模型外挂了知识库和工具的就可以叫 agent。 一部分人认为只有能够自主执行任务并根据过程中反馈自主解决问题的才能叫做 agent。这也是 agent 这个词的原意，也就是"自主性"。 其实二者的差别仅在于技术水平。我认为未来我们对 agent 的定义肯定也是不断变化和门槛提高的，这就好比我们对人工智能的定义的变化：曾经的 NLP、计算机视觉、自动化都被认为是人工智能，但是大语言出来后，曾经的一些智能看起来就差点意思。 所以 agent 作为一个动态变化的概念，没办法直接讨论，更值得关注的是组成 agent 的技术：我们可以通过哪些外在手段拓展模型的能力边界。不同类型和技术成熟度的外在手段的组合，得到不同形态的 agent 产品。层出不穷、千差万别的 agent 底层实际上是有限的几个技术的进步与变化。 比如根据外挂等知识库和工具使用的不同，分为了： - coding agent：业务代码数据库（知识库）+IDE 运行、修改工具（工具调用） - 客服 agent ：商品、话术资料（知识库）+微信聊天窗调用 or 语音工具（工具调用） - 教育 agent：题库（知识库）+相机调用、图片识别（工具调用） - 工业 agent：图纸库、机器操作（知识库）+机器指令的调用 - 专利 agent：专利库（知识库）+交互类工具 - 算命 agent：星象、塔罗、生辰八字（知识库）+算命程序的调用 - PPT agent：PPT 模版知识库+PPT 接口调用 如果一项项单独做研究，一个是纷繁复杂，其次是时效性差，技术稍微改变和进步就会对原有结论产生冲击。所以接下来我们从底层技术的角度，来研究 agent。 关于Agent 技术，之前MetaGPT 发布了一篇很火的超长综述《Advances and Challenges in Foundation Agents: From Brain-Inspired Intelligence to Evolutionary, Collaborative, and Safe Systems》，主要是从学术的角度探讨未来的 agent 应该是什么样的。展望的是一个通用的、能够自进化、自组织的、AGI 的接近终极阶段的 agent 和多 agent 系统。（某种意义上说是科幻级，因为描述的是造一个和真实人类相当甚至超越人类的 agent）。 所以，其说是一份详尽的技术综述，不如说是一份高瞻远瞩的研究议程 (Research Agenda)，其描述的至少是 L5 级的 agent。与当下的业界技术实力和商业实践相差有点远。短期内对我们的项目判断有限。 所以进一步细化，接下来我们主要还是从立足于中短期的 L 3、L 4 级智能体的技术范畴进行研究与讨论 agent 的能力边界。我们需要外在手段提升模型能力，是因为模型本身具有局限。这些局限可以总结为：- 缺乏知识更新能力：知识库、搜索 - 幻觉：思维链、多 agent 交叉验证、工作流、知识库 - 输出结果单一：各种工具调用 - 上下文本长度：记忆问题 Agent 即是解决模型本身局限的系统性方案集合。
当前Agent 的能力与技术
目前的 agent 的核心技术，可以归结为下面四个点：- 知识与记忆 - 工具调用 - 规划反思决策（分歧大） - 多 agent 协作（最不成熟）
以上四个技术按成熟度递进，最原始的 agent （Coze）主要用了前两个，munus 用了前三个，深度赋智用了四个。
关键技术 1：知识与记忆
解决的问题： - 大模型缺乏实时知识更新的能力。 - 行业私域知识没有被训到模型里。例如，在景区场景中，有些景区的内部知识（如售票时间、每日游玩路线安排、开放与关闭的景点信息等）是通用大语言模型无法预先掌握的。 - 用户的交互产生的数据无法被很好利用。比如偏好、口头指令。 前面两种主要通过知识库，最后一个更多属于记忆。但本质上都属于让大模型知道得更多。知识：知识库（RAG ）和搜索
这一部分应该算是技术上分歧比较小的 知识库的核心技术就是 即检索增强生成（Retrieval-Augmented Generation）。通过构建和集成行业私域知识库，AI Agent 就可以弥补大语言模型在实时性和领域专属知识方面的不足，显著提升其在特定场景中的适用性和理解能力。 搜索和知识库放一起，是因为，搜索从技术上讲是一种 tool use，但从结果上讲是一种知识库。个人认为搜索可以理解成一个公开的知识库，只不过由于数据量级的不同，技术实现上和 RAG 不一样。 | 搜索 | 知识库 | 交互记忆 | | ----- | ------- | ----- | | 人类的知识 | 私有领域的知识 | 个人的知识 | | 很成熟 | 较成熟 | 探索阶段 | 发展趋势：个性化、定制化、私有化。在知识库做得差不多之后，下一步肯定是卷交互记忆。记忆：前沿算法探索
问题： - 多轮对话之后遗忘前面的指令和内容。长上下文文本问题（历史对话不能很好的回顾） - 哪些信息应该被大模型写入记忆，选择性遗忘。架构的自注意力机制在处理长度为 $L$ 的序列时，计算复杂度为 $O(L^2)$，导致显存占用和延迟呈指数级增长。以 4096 token 的上下文为例，注意力矩阵需要存储 16.7 M 个权重值，当扩展到 100 万 token 时，矩阵规模将达 1 万亿参数，远超现有 GPU 显存容量。这种计算特性迫使模型在长文本处理时不得不采用截断策略，造成关键信息的丢失。——但是目前对记忆的研究和解决方案还没有一个主流的结论。短期记忆（基于 context 的记忆，即作为 prompt）、长期记忆（无限召回历史信息的能力）与工作记忆等不同类型，包含情景记忆、语义记忆和程序记忆等细分领域。高效的记忆检索、存储、遗忘和泛化机制对于 Agent 至关重要。
单独作为产品的知识库
知识库技术（RAG）上本身并不难，目前市面上已经有很多知识库产品了，核心竞争要素为数据与交互，to C 比较重交互、to B 则重行业数据。 | 秘塔 | Ima | | :--------------------------------------- | :--------------------------------------------- | | || | Farbata （企业知识中台） | GPT “项目模式” | | |
| | 火山知识库 | 飞书知识库 | |
| | To C 领域的单独产品的知识库可能没有什么机会。因为模厂的 Chatbox 也可以直接加知识库功能，比如 GPT 的项目功能。飞书也在做知识库。从使用个性化、私有化、方便程度、和团队协作上说，秘塔是非常不占优势的。甚至未来的操作系统可能就带知识库功能，笔记软件比如 notion，比如 obsidian，办公协作软件飞书，从 ToC 的使用体验上会比秘塔方便。To B 的知识库如果有独特的数据库 （比如 wind 这种、专利撰写、军事情报）还是会有一定机会。 （搜索、知识库功能，一旦模厂大厂开始做了之后，初创就没什么机会了） 但做好知识库是有助于做 agent，秘塔类的企业，未来的出路也会是在往 agent 上走（秘塔也整合了很多私有的研报法律领域的数据，但知识库没有很方便地做搜索）。做好知识库的潜力，我们已经逐渐看到了，秘塔加一个前端代码的撰写就是一个互动网页生成 agent，这个工具更近一步，就是一个教育阅读 agent。PS：秘塔有机会去聊吗？ （纳米也可以生成动态网页了） 
关键技术 2：工具调用
哪些 tool 简单，哪些 tool 难
工具，大致可以分为 image、video、audio、text 这四类。目前市面上最多的是 text 这一类（比如查询时间地点、访问网站、生成网页本身也是 coding）。 不同类别的工具的实现难度是不同的，这个问题直接关系 agent到在不同行业的落地。总的来说，多模态（image、video、audio）的难，text （查询、读写）的简单。 Text< image < audio< video。主要是目前推理仅在文字和图像领域实现了。语音和视频还没有出现推理模型。 所以，个人判断： - 客服销售类 agent、coding、research 类只涉及到文字工作的 agent 会率先落地。 - 教育类（图像搜题解题）会次之。 | Coze 空间目前支持的 MCP | | 纳米的 MCP 目前也主要是搜索、查询类 | | ------------------------------------ | ------------------------------------ | ------------------------------------ | | | | |工具的实现：
MCP（Model Context Protocol，模型上下文协议）由 Anthropic 公司于 2024 年 11 月首次提出并开源。旨在提供一个安全、标准、双向的通道，让 AI 模型可以像人一样自由调动外部知识库和工具库。 一句话解释，MCP 就是 Function Call 的成熟版，企业版，标准化版。在工具的能力上并没有提升，但降低了工具的使用门槛，和 agent 的开发门槛。 | Function call | MCP | | -------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | | | | - 代码量大（详细的函数定义）- 开发门槛高（支持高并发与容错）
- 不能复用，重复开发
- 一般大模型和工具在同一台服务器上。同步，程序会一直等待函数执行完返回结果，才继续执行后续代码； | - MCP 服务端和大模型客户端分离。异步的，发送请求后程序不会等待结果，会继续执行其他代码，等结果出来再处理。
- 可以直接调用别人的 MCP。不需要重复开发
- 不是每次另写一套集成方案 | | | Function call 和 MCP 是可以混用的。 | 目前可以说MCP 初步的生态成功：许多开发者尝鲜建构了 MCP Server 和客户端库。 总体来看，MCP 在技术上填补了模型与工具互动的空白，并通过开源抢占了先机，但其未来能否统一标准，取决于行业巨头和社区的博弈。乐观的话，大家认可其开放价值，共建生态，让 MCP 真正成为 AI 时代的“USB 通用界面”；悲观的话，可能会出现多个变体标准割据，或者被巨头用其它方案取代。然而无论如何，MCP 所代表的理念——让大模型直连外部世界——必将持续下去，并深刻影响 AI 应用的形态。
这一部分接下来的研究方向可以对各种工具的成熟度，大致实现什么样的一个效果做一个梳理。资料可以从各类 agent 开发平台和一些开发项目里去做 mapping。