重新定义 Kaeso

发布: 1天前 (2026年3月9日 GMT+8 01:15)

4 分钟阅读

原文: Dev.to

Source: Dev.to

Introduction

Kaeso 并不是定义错误。有时产品会发生变化——并不是因为想法错了，而是因为在解决问题的过程中自然会发现更多想要改变的地方。既然我们甚至还没有真正开始，这时候把方向调转只要成本不太高，就是合理的选择。

一开始我并没有追求什么特定目标。我主要想要一个动力，一个让自己投入这个项目并进入这个环境（与 AI 共事）的理由。

我已经知道市场在寻找什么。几乎所有当前关于 AI 的发明都围绕着一个核心话题：AI agents。无论是电信公司的客服代理、编码代理，还是其他任何类型的代理，大家都在思考代理。

我设想通过创建一个平台来集中这一想法，使其能够使用大型公司提供的各种模型，配合多种工具和集成来执行工作流。我已经知道代理需要数据。没有你提供的计划，建筑工人做不到你想要的事；没有了解你的案件，律师也无法为你辩护。

在构建这个平台的过程中，我意识到为每一个你想要创建的与其他数据源的微小连接都为代理构建一个工具，实在是非常烦人。代理只处理数据，而有一个设计原则是许多开发者、设计师和创作者遵循的：“The User Is Stupid.”（用户是笨的）。代理需要防呆设计。

代理应如何在不让用户每次手动提供的情况下获取数据？

答案很简单：代理应该能够自行完成。这正是用户的期待。这也是人们喜欢 OpenClaw (ClawdBot) 之类项目的原因。你把代理连接到一个 connector，它就能自行检索所需的数据。

普通人很懒。大多数人甚至不想为代理设置一个单一的网关来访问他们的数据，更别说多个不同的网关了。每个服务都有自己的登录、邮箱、密码、双因素认证等。同时，人们仍然期待隐私，却常常忽视其背后的复杂性。

Kaeso 通过创建一个 统一的 API 网关 来解决这个问题，代理只需连接一次。它提供了文档完善、结构化的 API，你可以一次性定义权限，并控制哪些 API key 可以访问哪些服务。它还支持每个服务的多账户，使得代理能够访问远超其自身能力的海量数据。

于是这就是 Kaeso v1。