Agent 的不同形态

今天我们的产品，给我们的客户，直接安装了 Claude Code，我不禁怀疑，我能用 Claude Code 做的事情，为什么还要用 Agent 再开发一遍呢？

要谈论这个问题，我们得从服务器端 Agent 和客户端 Agent 的区别说起。

服务器端 vs. 客户端

Agent 的定义里，包含了几个核心的属性，从这几个关键特性来看：

（当然除了这些 Agent 核心功能外，还有客户向的一些问题，本文不作比较，比如上手难易程度，客户如果不是一个有些许开发背景的人，云云……）

Memory

服务器端 Agent

或许你可以开发一个方便检索的文件系统，也可以开发一个 RAG 增强索引的向量数据库，以提供记忆的能力。

如果你能给你的服务器端 Agent 提供这些记忆的能力，那么你的 Agent 会是一个非常牛逼的存在。

绝大多数的情况下，我们能够提供的，仅仅是，某些数据的访问权限，上下文和 Prompt 工程里的记忆。缺少一个可以像 Skill 一样检索的本地文件系统，是一件很致命的事情，当我们很难像操作本地文件一样操作记忆的时候，就没有人会用它了。因为我们有更方便的选择。

记得在没有彩色胶卷的时候，人们用非常复杂的分区曝光 + RGB 滤镜的方式来尝试还原彩色相片，因为大家没有别的选择，那时候拍摄一张彩色相片，可能需要花费数天时间。当彩色胶片成为可能之后，这样的装置也放在了博物馆里，也没有人愿意花费数天时间来做这个事情。

客户端 Agent

客户端 Agent 可以轻松简单的利用本地文件，做一系列自己想做的事，当然，如果你有一个可以检索的文件系统，你有一个 RAG 向量数据库，你也同样能利用 API 去查询自己的知识库。

这回合，客户端 Agent 以配置简单，功能更为齐全而胜出了。

但是跳脱场景，谈优劣，那是不厚道的。服务器端也有得天独厚的优势。

场景

试想一下，Claude Code 给人太多自由，总有企业想用 AI，又想控制大家使用的程度，那就～只好给大家用那些，全都是规定好 Prompt 的 Agent 吧～

另外一个场景，某些企业，真的还在提供服务，这个 Agent 是他们的一个产品。这样的产品一定有一些特性比如：

1. 当我需要控制使用的量（毕竟 Token 还是要花钱的）。
2. 当我需要监控，无论是 Audit 的目的也好，还是内容审查的目的也好这都非常有必要。
3. 当我需要控制用户是如何使用 Agent 的，比如我只希望我的用户用此 Agent 来生成一次会议纪要。

RAMP 公司写了一篇文章，Why We Built Our Own Background Agent

他们利用一个服务器端，掌控了整个开发流程，为什么我们要开发自己的服务器端 Agent？答案再次回到了，垂直，定制两个字上，每个公司的需求都不一样，服务器端 Agent 能够提供的定制化能力，将开发流程牢牢的掌控在自己手里，是客户端 Agent 无法比拟的。

除了开发，是不是每个公司，都应该去挖掘自己的某些独特的流程呢？比如食品公司的 R&D 流程，产品开发公司的商业化流程，财务公司的审批、报账流程。

Tools

在 Tools 的调用中，服务器端 Agent 存在着明显的劣势，这还不像是场景的问题，体现在两个重要的方面：

1. 权限控制：Agent 对所集成的 Tools，如何施加身份认证和权限控制？而在本地，我能以用户的角色来执行。
2. Execution Env：服务器端要开沙盒，才好控制执行任务的环境，这个限制直接让服务器端 Agent 与 Skill 之间跨越了一个巨大的鸿沟。

服务器端 Agent

关于服务器端 Agent 所能调用到的 Tools，就非常的局限，主要是 MCP 和单独接入的 API。虽然客户端也用 MCP，但服务器端对 MCP 的依赖程度更高，因为它没有本地文件系统和命令行这些天然的能力。

及其单独接入的 API Tools，所以在服务器端 Agent 里，许多难题的解题思路就变得相对狭隘起来，比如我要想方设法解决多 Tools 导致的上下文过大的问题，我就不得不开发一个 Tools 来 Search Tools。

比如我要想方设法解决知识库检索的问题，我还是开发一个可以检索知识库的 Tools，也就是某个特殊的 API Call 能够允许我在众多知识中做检索。

服务器端 Agent 的解题思路，也在向客户端靠拢，比如提供一个沙盒，提供一个 Tool Search Tool 的 API，让它实现 Skill + Code Execution 的解题思路。

客户端 Agent

Command Line、API、Execution Env（动态方法）都能够成为客户端 Agent 的利器，这里唯一的问题就是，过大、过于自由的权力，是否会成为你使用 Agent 的一个痛？我觉得只有拿着瑞士军刀不知道原来我还能这么做的困扰，没有因为解题思路太多而有的困扰。

所以，在我心中，当下解题思路的优先级是 Skill + Code Execution > Command Line > MCP。

复杂任务 vs. 简单场景

Agent 区别不仅仅是服务器端、客户端。不同 LLM，也应该有不一样的适配 Agent。为了更简单的讨论这个问题，我们可以思考两个极端场景：

低运算场景

我有一个电风扇，它只听三个指令，开、关、调档。这样的一个场景，我需要内嵌一个 Claude 吗？我只需要一个能听懂这三句话，能执行这三个 Tools 的 Agent。

复杂任务场景

我需要详细的拆解任务，Thinking、Planning、Actioning，然后进入 ReAct 的 Loops 里。我需要用最贵的模型，最牛逼的 Agent Practice。

实际情况

当我们说 Agent 时，很多时候讨论的是一个开发框架，我们关心它管理上下文的办法，拆分任务的办法，检索知识的办法，不同的 Agent 是否能够压榨不同 LLM 的最大性能？用最小化的复杂度，处理最适合的问题。比如，在嵌入式世界里，我只希望安装在我的硬件里的 Agent 是最合适的（占最小内存，满足我所有诉求的）Agent。

定制化 Agent 内核

这里就萌生了一个需求，定制化 Agent 内核，同定制化 Linux 内核一样，我们能够不停的阉割 Agent 的功能，调试它到某个极致的状态，比如只运行最轻量级的开源 LLM，只处理开和关，只处理一个最傻的校验，比如识别到如同火焰一般的图像，就开启报警。

这个需求现在有吗？有，方案有吗？有，但是方案有很大的瑕疵，他们都是把图像上传至服务器端 Agent，在云上做判断，依赖网络，报警速度在秒级别以上。如果我用最小的 GPU，在本地，不依赖网络的情况下运行这样的报警，岂不是资源利用和可靠性都能达到最大化？

昨天的一个幻想

我昨天忽然想到一个科幻小说的设定，那就是万物皆智能，不是只有机器人是智能的，大到你的汽车，小到你的水杯、你的闹钟、你的鞋子和鞋带，都运行着一个小模型，都能自行决策一些动作，开关、挪动、捆绑……

关于短期记忆，长期记忆的思考（题外话）

上面在 Memory 和 Tool 的话题里，都提到了有关知识库检索的问题，我觉得这件事应该类比人类大脑的工作来看。

我的大脑里会保存一些知识，但绝不是所有的知识，当我遇到具体的问题时，我一定是去图书馆，去 Google，寻找解决问题的思路，虽然找不到一模一样的案例，或者答案，但是总能找到足够让我推导的资料。

图书馆有图书馆索引，Google 有搜索算法。

所以知识库索引，完全不必是 Agent 内置的一个仓库，知识库索引只需要是一个能力，一个迅速检索、举一反三的能力。

人类短期记忆的运行机制，是经过生物进化验证的。有些记忆点，只有 20-30 秒。经过反复的强调，逐渐形成长期记忆，最后有人将最有价值的部分，写成书籍，记录在图书馆和互联网上，成为后来者的参考。

题外话的题外话 我对这个项目有一个非常非常深的印象，https://refoundai.com/lenny-skills/ 开发者用自己与大佬对谈的播客，作为数据源，生成了类似 problem definition 这种高度抽象的 Skill，这件事在我看来，是当下最有价值、最值得去做的一件事情。

回到记忆的问题上，我想说，人类有百分之 90 的记忆，都是外挂的，我们只是利用了百分之 10 的记忆来记住，如何获取另外的 90% 的记忆。有时候，获取如何获取记忆的方式甚至都是外挂的。

从强制扩展上下文窗口，到 Tool Search Tool，或许将来可能是 Tool Search Tool Search Tool，都不是一个很奇怪的事情。

推理、联想能力，才是人类大脑的核心能力，大脑里记忆的内容，一直是一个与时俱进、审时度势、优胜劣汰、新陈代谢的特质。

最后

服务器端、客户端、简单、复杂的 Agent，都会一直存在，在各自的应用场景里大放异彩，我已经能预见，有一个做大做强的公司是专门提供低运算场景的软硬件结合的公司。

---

ref:

1. https://builders.ramp.com/post/why-we-built-our-background-agent