清晨，高楼的玻璃幕墙映着淡淡的天光。地铁口陆续有人走出来，手里拿着咖啡和早餐。公交车停靠在站台边，车门开了又关。路边的梧桐树叶上沾着昨夜的水汽，清洁车沿着道路缓慢驶过。太阳从楼群之间升起，玻璃窗上亮起一片金色。写字楼的大门陆续打开，外卖骑手穿过路口，行人沿着斑马线向前走去。城市从安静中醒来，街道上的声音渐渐多了起来。从人类社会文明诞生到现在，亦或是未来，可能都这样一直在忙碌。
随着 2024 年国内 AI 技术爆发，越来越多的人和企业意识到了 AI 技术的前景与巨大潜力。我们经历了大模型爆发元年到 Agent 爆发元年，有人惊喜，有人恐慌，但更多的便是困惑。今天，我们先浅谈一下 Agent。
2024 年国内 DeepSeek 模型的爆火掀起了一股大模型热潮，许多公司和团队开始纷纷下场做模型，从基础的 LLM（大语言模型）开始渐渐发展到多模态模型、视频生成模型以及图片生成模型。早期 GPT-3 系列模型中 RLHF 的 PPO 算法，到 DeepSeek 在 RLHF 中使用的 GRPO 算法（取代了价值模型）从而降低了模型训练成本；Qwen 通过注意力门控机制降低了大模型的注意力稀疏机制；KIMI 团队针对残差连接提出来的基于注意力的残差连接（这里简单代一下：在 Transformer 架构中本质上有两种记忆，第一种是横向的，是 Token 和 Token 之间的注意力，也就是大家了解的 Attention；另一种则是纵向的，是残差流之间的记忆。KIMI 修改了固定的残差传递机制，将残差连接从固定加法升级为动态检索，使 Transformer 具备了跨层选择性记忆能力）。模型能力逐步增强，大家意识到模型不应该仅仅只是单一地回答问题（你问我答），更应该做很多事情。于是，Agent 迎来了属于它的春天。
这里面最经典的便是 Claude Code，其依靠 Claude 系列模型强大的编码能力以及精妙的工程设计深受大家喜爱。人们在享受这种工具带来的极致效率的同时，也发出了很多声音。我把这些声音归纳成两种：第一种是 Agent 未来如何发展？第二种是普通人现在该干些什么，我们将何去何从？
Agent 未来该如何发展呢？我们要从 Agent 的工程设计本质上看待这些问题。当前 Agent 设计本质上大致有这 6 大类：
1.Workflow（工作流）： 比如传统的 ReAct、Router，也有现在使用量多的 Agentic Reasoning、Agent 集群等。
2.工具： 在 System Tools 中大致有 Bash、Git 等命令行工具；在检索方面有搜索工具、RAG 等工具；以及外部工具比如能够链接网页或软件的 MCP、控制浏览器的 Browser 工具等。
3.Context（上下文）： 上下文窗口的设定、裁剪与传递。有些公司采用了 Blackboard 系统，将上下文统一写到数据库中（Manus 在其技术博客 "Context is all you need" 中就采用了 Blackboard 系统作为上下文的共享协作方式）。
4.Prompt（提示词）： 包含 System Prompt、Tool Prompt，这里面也包含了 Skill，因为我认为 Skill 就是 Prompt 的变种。
5.数据库： 也包含知识库。数据库范围会更大，不仅仅包含知识，也包含上下文的存储管理、工具调用信息日志存储、Agent 信息日志存储、用户信息存储等。
6.Runtime（运行时）： 即 Agent 系统运行时的状态。这是一个非常值得考究的工程设计，是协调整个 Agent 系统的关键。比如上下文何时进行裁剪？短期记忆的轮次？Prompt 何时进行加载？我认为一个优秀的工程设计下，Runtime 不应该仅仅处理 Agent 系统运行时的协调调度，还应该处理任务完成后，在“冷时间”中系统该如何完成一系列“加分”任务。如：通过算法判断当前用户数据是否充足？能否检索补充用户数据先进行大范围初步建模？
这里面可能会有争议。首先，在模型层，一个企业级的通用领域 Agent 通常会有一个路由机制，将问题进行分类，然后给到合适的 LLM（比如将编码问题交给 Sonnet 或 Opus 系列模型进行选择），我个人认为这仍属于 Workflow 类别。其次，Memory 层比较复杂，大致分为短期记忆和长期记忆（也有中期记忆和 Working Memory，这里先不单独拎出来）。短期记忆本质就是上下文窗口，工程师需要根据所调用的模型设定一个最大对话轮次，在这个轮次中，Agent 依靠模型自身的短期记忆即可。而在长期记忆中，需要依据数据库中的工具调用信息、用户信息等数据，根据任务相关性进行实体驱动加载、时间驱动加载、目标驱动加载等方式热加载到 Agent。我个人认为这个部分属于上下文窗口、数据库和 Runtime 的结合，所以并没有将其单拎出来。
我们需要注意的重点是，上面这六个分类并不是独立工作的，这好比齿轮一样，每个齿轮的转动都需要另一个齿轮先转动再推动其转动。同理，这个齿轮的转动可能也推动另外一个齿轮的转动。这些齿轮不是链式或平面式，更像是一种空间式的。每一个机制的演变、改动都会带动其余一些机制的变化。我将大胆结合模型未来的发展，围绕着这 6 个机制进行分析，给出我的观点。
先给出结论：我认为未来的 Agent 工程师会变成数据工程师和工具工程师的结合。
我将从 Workflow 为起点进行延伸，以下所有的分析都将会结合模型一起去分析。有一个非常有意思的现象，现在许多 Agent 的 Workflow 其实都借鉴了 LLM 中的设计，比如混合专家模型和 Agent 中的专家 Agent。所以我们大胆猜测，未来随着模型的发展，Agent 工程师可能不需要过多考虑 Workflow 框架设计。模型会分析任务领域，激活对应部分权重（可能会有一个对抗权重去对抗专家模型产出的内容，从而产出更可靠的内容），Workflow 会在模型内部完成推理。
当然，就像我说的，这是一个空间齿轮，得出这样的结论不能单一考虑 Workflow。现在较为先进的 Agent Workflow 框架（例如 Agentic Reasoning）还是需要 System Prompt 去告诉模型哪些 Agent 是干什么的、在什么情况下进行调用、哪些场景下这么调用比较好。所以我推断 Workflow 的变革一定会带动 Prompt 的变革。
现在阻碍模型发展的最困难环节可能是数据类型的缺失。我们缺少那种有逻辑性的数据，比如告诉模型为什么 1+1=2、为什么苹果会落地那种极具逻辑性的数据。现在爆火的 Skill 可能就是未来逻辑性数据的沃土（现在其实已经有一些模型公司将工具的 Prompt 变成了模型的训练数据，让模型的工具调用能力变强。看，多么有意思的现象，Prompt 的变革又推动了工具的变革）。未来会出现那种“超级 Prompt”，这些“超级 Prompt”会变成训练数据，专门训练模型，让其具备真正的逻辑性。我们可以把 Prompt 或 Skill 看成一种逻辑性的“踩坑指南”。如果您设计过一些 Agent，您会发现模型有时会“不听使唤”，这时候你需要在你的 Prompt 加上 Few-shot、命令式语句等（企业级做法还会加上兜底层，至于怎么设计，这里不做赘述），这些其实都是非常好的训练数据。现在的 Skill 更具备逻辑性，而且很多 Skill 都对应某个领域专家们的经验、踩过的坑和逻辑。这会为数据公司节省大量的时间去采集数据。未来模型如果拥有了大量的逻辑性数据，那么模型可能会获得真正的推理能力。所以，未来 Agent 工程师可能不会设计 Prompt。
对于 Context 层面，我们可以看出一些模型公司在近些年对于上下文的处理上有着很大的投入，从之前的 32K 上下文变成了 1M 级别。结合上文 KIMI 给出的残差流论文，我大胆预测模型自身会具备很强的上下文能力。现在因为算力层的不断进化，模型在处理上下文的时候能够处理更多的 Attention。但是未来的上下文能力并不会靠堆量，会通过修改一些算法，使其模仿人类具备“遗忘”能力。因此，Agent 工程师不会再对上下文的处理花费很多心思。
接下来我将分析比较重要的三点：工具、数据库和 Runtime。我们先从工具开始分析。如前所述，模型公司会将工具的一些信息作为数据训练进模型，增强其工具调用的能力，并将一些官方工具深度集成到平台。在这里我要讲到之前 Anthropic 公司提出来的非常火的机制：MCP（模型上下文协议）。这个机制就是通过一个协议（可以是 JSON 脚本）让模型轻松地调用别家公司的工具、软件或网站（比如通过 MCP 连接 GitHub 让 Agent 访问你的项目仓库）。
为什么需要这个东西？举个例子，你现在要到国际舞台上发表演讲，但听众和你不是一个国家，你说的语言他们听不懂，这时候就需要用到翻译器。MCP 类似翻译器这个适配器，将不同的工具通过一个标准化协议让 Agent 轻松调用，不需要再为每个工具写一个适配器（类似不需要你为每个听众单独翻译一遍）。如果您了解 MySQL 会知道当前数据库有很多种（SQLite、Oracle 等），但是这些数据库的操作都使用 SQL 语句（严谨地讲是高度通用，因为数据库服务商提供的一些扩展性服务是他们自己定制的，所以使用的语句不完全一样）。Anthropic 干的事情就和这个类似。现在 Oracle 是收费的，但是你操作 Oracle 的 SQL 语句是免费且开源的。MCP 协议本身免费且开源，但是背后的服务供应商提供的服务是收费的。
介绍完 MCP 之后，我们来看看工具未来将会有什么变革。未来 Agent 的工具将会聚焦于两大类：
•第一类，内部工具： 比如文件读写、代码编写工具等通过调用 Git、Bash 等命令行语句进行调用的内部工具。当前 AI 公司还是在适配当前的计算机操作命令行，从成本角度看，这比重新为 Agent 设计一套操作语言节省成本。但随着 CLI 的爆火，其强大的可定制化能力暗示着未来极大概率会出现一个专属于 Agent 的操作命令行。上面提到的 MCP 抢占了先机，未来 Agent 命令行出现的时候，如果 MCP 能够符合其生态，那么这对于 Anthropic 将非常有利。当然，从其推出 Claude Code 以及各种对于命令行的研究可以看出，该公司也可能率先推出 Agent 命令行。
•第二类，外部工具： 搜索工具、浏览器控制工具等。这部分随着当前 Agent 不断渗透进人们的工作中，会诞生很多垂直领域的工具（现在已经出现了一些 AI SaaS 工具解决初创团队和小微企业付费问题），比如金融数据分析、法律文献分析等工具。这会给很多初创团队和公司一个非常好的机会。这些公司或团队通常会有一部分人以顾问的形式参与开发，顾问提出领域的痛点，工程团队进行解决。当然也存在个人通过自学编程来编写垂直领域工具的情况。这些外部工具大部分会以 To B 的形式进行销售，并提供一系列服务。
但是这里面的服务不会包括数据管理服务，这就引出了数据库这个点。记住，Agent 设计是一个空间式齿轮。数据库是未来最为精彩的部分，也是 Agent 开发最重点的部分。工具调用产出的数据存储到个人数据库，Agent 运行产生的数据（用户画像建模、调用时间等）也会由个人保管。这里面的核心就是安全。现在大部分的流程是让大量数据给到 AI，但是个人和企业的数据都需要安全管理，不能轻易流向 AI。加上企业的数据往往比个人数据更大，所以未来的走向一定是让 AI 走向数据，或者让 AI 变成产生数据的本体。我们可以多多关注做轻量级模型的公司，他们在未来会有很大的市场和机会。
对于 Agent 工程师来说，未来如何设计一个非常安全的个人或企业 AI 数据库将会是关键。在保障安全的同时，也需要做到数据去中心化理念。现在有一个思想叫做“数据不出网”，核心是将重要数据保存在本地。但我个人认为云端数据未必不可靠，比如区块链，那里面保存了很多重要内容并且非常安全，其被攻击成功的概率极低（这里涉及哈希碰撞，在数学层面上虽有概率，但在 SHA-256 等成熟算法加持下，这几乎是不可能完成的。虽然 MD5 是一个成功的碰撞案例）。未来 AI 数据库的搭建可能利用区块链技术和去中心化思想，结合更为先进安全的算法。哪怕是云端数据，数据传输也不会是大量内容的传输，只会传递关键信息。如果可能，数据库中还会部署一个 Agent，负责将关键信息传递给用户和企业，或帮助完成信息安全的重要步骤（付费、注册等）。所以我对于未来 Agent 数据库的设想是：去中心化的、极其安全的、具备信息筛选功能的平台。它不仅仅是数据库，而是连接第三方与个人、企业的数据存放枢纽。或许未来会出现一个数据库版本的“MCP”协议，帮助开发者或企业轻松连接数据库。
既然上面提到的 Prompt、Workflow、工具、数据库、Context 都发生了变化，作为最关键的 Runtime，它的变化是什么呢？其实，现在 MCP 的出现以及各种外部工具能力的增强，已经在为 Agent 工程师解决了一些 Runtime 的问题。我上面设想过，Agent 工程师不再负责 Context、Prompt、Workflow 之后，他们的重心将放在工具和数据库上。这时候工程师需要写一个 Runtime 脚本来确保与这些工具及数据库之间的复杂交互，确保数据安全、高效流转。
以上便是我对于 Agent 未来如何发展的分析。由于篇幅限制，我将在下一部分列出“普通人现在该干些什么”。由于我也是一名刚毕业的大学生，所以上面这些仅代表我个人的看法，不一定准确。希望能给大家一些启发。
楼主