解放你的 Agents，赋予它们 SSH 访问权限

每个 现代 平台都会给你的 Agent 提供三种集成选项：一个需要注册的 MCP 服务器、一个需要存储和刷新的 API 密钥，或者一个需要安装的技能文件，用来教 Agent 如何完成前两项操作。总有些东西需要 配置，有些东西会 泄露，有些东西会 过时。

Oberik 给你的 Agent 提供的是 SSH 访问权限。

不是给你，你在这个上下文中只是充当代理，它实际上是给你的 Agent 提供 SSH 访问权限。

1 ssh ssh.oberik.com

SSH 是编码 Agent 在与 Oberik 交互时使用的界面（例如，创建工作空间、设置其能力上限、铸造代币、与我们托管的 Agent 聊天等）。无需配置文件，无需环境变量中的令牌，无需安装任何东西。你的机器上已经有客户端，并且它已经知道如何保管所涉及的那一个凭证。

为什么不用 MCP？

长话短说，输出问题。

MCP 成为行业默认标准，是因为它解决了一个实际问题。你编写一个工具一次，每个 Agent 都可以以相同的方式调用它。我们并不反对它。Oberik 会将你自己的 MCP 服务器直接加载到我们托管的 Agent 中，按租户隔离，这对于 Agent 连接 工具来说是个好方法。我们这里要讨论的是另一个方向：某物 最初是如何 配置 账户的。

尽管使用起来很方便，但 MCP 在其核心存在一个缺陷：当工具运行时，整个输出都会被推送到模型的上下文中。模型必须读取所有内容。它无法决定“我只想要第三个字段”，因为当文本到达时，过滤已经失败了。

MCP 原则上支持过滤和分页。但实际上，必须有人为每个工具构建这些功能，而当这些功能缺失时（由于 氛围编码，这种情况经常发生），模型就只能 吞下 原始负载，并为此付出令牌和注意力的代价。

使用 SSH，Agent 可以自行组合其视图，而不是接受工具交给它的视图。

1$ ssh ssh.oberik.com 'documents --json' | jq -r '.data[].name'
2$ ssh ssh.oberik.com 'audit --limit 20 --json' | jq -r '.data[] | "\(.at) \(.command)"'

过滤器在机器上的管道中运行。即时、免费，并且精确到 Agent 想要的范围。模型读取一行，而不是十页。

有两件事让这成为可能。首先，每个响应都使用单行格式，例如 {"ok":…, "command":…, "message":…, "data":…}。这使得 jq 成为读取输出的预期方式，而不是一种变通方法。

JSON 模式还可以防止交互中断你的流程。如果某个命令缺少必填字段，它会告诉你缺少什么，而不是打开一个表单。如果某个命令可能具有破坏性，它会告诉你重新运行并加上 --yes，而不是停下来请求确认。

对于包含多个命令的一行，可以在开头加上 format json;。这会一次性设置好格式，这样你就不需要重复添加该标志。

有一个细节值得了解。该标志必须放在引号内。ssh ssh.oberik.com --json 'documents' 不起作用，因为 ssh 会将目标地址之后的选项视为自己的选项。它会忽略该标志，而客户端会返回自己的使用说明输出。由于该输出既没有提到 Oberik 也没有提到该标志，这可能会让人觉得主机出了问题。

我们想说的是，我们已经训练了这些模型来使用 计算机，那就让它们使用 计算机 吧。

为什么不用 API？

长话短说，凭证问题。

别误会，我们在 Oberik 中有一个 API，而且它很好用。它是你的产品在生产环境中调用的接口，也是 SSH 网关在底层调用的接口。

但是，如果你看看它对调用者的要求：

1. 获取一个令牌
2. 存储它
3. 刷新它
4. 确保它不出现在日志和模型的上下文中。

每一步都成为 Agent 的责任，而 Agent 的上下文并不是存放秘密的安全之地。任何见过模型回显自己环境变量的人都知道这一点。我的意思是，如果你留意的话，你会意识到你最喜欢的编码 Agent 在默认情况下，当它在你的提示中检测到敏感密钥时，会表现得 视而不见。然而，粘贴到 Agent 中的密钥不仅仅存在于 shell 历史记录中；它还会发送给模型提供商，进入日志，进入工具链保存的任何转录记录中。

API 是存在的，但它不是我们为 Agent 设计的主要 自我设置 路径。通过 SSH，Agent 持有你的操作系统本来就设计用来保护的一种凭证类型，即 SSH 密钥，而私钥部分永远不会传输。向 Oberik 进行身份验证不会在模型的上下文中放置任何秘密信息，因为那里根本就没有什么可放的。

为什么不用 CLI？

长话短说，过时问题。

安装 CLI 是要求每个集成商的工具链做出的一项承诺，我们不想这么 冒昧，毕竟我们才刚刚起步。老实说，我们根本不想要 CLI，因为它基本上是产品的一个冻结副本。Oberik 的控制平面会随着我们获得更多反馈而增加功能，这意味着如果我们选择了 CLI，我们将不得不不断推送新版本，并要求用户更新。

我们基本上解决了这个问题，因为我们的 SSH 界面是生成的，而不是编写的。我们控制平面中的每条路由都会连同其描述一起注册，而这个描述就是 SSH 命令。添加到仪表板的路由会立即通过 SSH 出现，因此我们无需担心网关变更。

无需更新，因为没有任何东西被安装。

为什么不用技能？

长话短说，指令问题。

目前与任何面向 Agent 的产品一起推出的流行方法是 技能。一个由你的 Agent 安装的书面程序，告诉它如何调用该产品。技能确实很有用，但它本质上是一个花哨的 README 文件。技能是文档，而不是能力。它并没有给你的 Agent 提供行动的方式；它仍然需要底层的 MCP 或 API 才能做任何事情，而且你也会继承那个问题。

除此之外，技能是一个关于如何使用一个不断变化产品的冻结副本。和 CLI 一样存在过时问题。它在 Agent 做任何事情之前就占据了 Agent 的上下文，将注意力和令牌花费在那些界面本可以在被询问时才打印的指令上。

我们对“Agent 如何知道 Oberik 能做什么”这个问题的回答，不是一个需要它安装的文件。而是一个让 Agent 自己去发现的调用：

1$ ssh ssh.oberik.com 'discover'                  # 每个命令、其参数和类型
2$ ssh ssh.oberik.com 'docs'                      # 每个页面及其涵盖的内容
3$ ssh ssh.oberik.com 'docs search capability'    # 提到某物的行

界面在连接时，根据实时产品描述自身。并且 docs 与文档网站上的文本相同，因此没有任何内容是其他内容的摘要。指令永远不会过时，因为 它们就是产品本身。

为什么用 SSH？

长话短说，它一次性解决了所有五个问题。

1. 密钥是 Agent 真正能够持有的凭证。 SSH 密钥认证已有数十年历史，经过数十亿次实战检验，协议在我们查看指纹之前就已经验证了签名。我们觉得没必要在这里重新发明轮子。我们只是不再要求模型去照看一个秘密，而是让机器去做它一直擅长的那份工作。
2. 你无需共享密码就能参与其中。 当 Agent 还没有密钥时，例如在它首次连接到 Oberik 期间，它会启动一个设备登录流程。Agent 运行 login link，该命令会立即返回一个 URL 和一个代码，并将两者显示给你。你在自己的浏览器中打开该 URL。页面会识别将要附加的确切密钥指纹，为你提供批准或拒绝的选项，并显示一个代码，你可以将其与 Agent 打印的代码进行比较。同时，Agent 运行 login wait 并等待你的决定。这些命令是特意分开的。如果一个命令既生成了链接又等待，Agent 只会在请求过期后才向你显示链接。一旦你批准，密钥就会被注册，所有未来的连接都会自动登录。你不再需要另一个链接。由于整个过程不使用秘密，因此不会有任何秘密被写入 Agent 的聊天历史记录。
3. 输出是为管道设计的。 在命令后使用 --json 请求 JSON，或者在一行开头使用 format json;，每个响应都会以单行信封的形式返回。这使得 jq '.data[0].name' 成为读取输出的预期方式，而不是一种变通方法。过滤器在机器上运行，因此模型只看到过滤后剩下的内容。错误使用相同的信封，并包含底层的 HTTP 状态码。这使得重试能够区分 429 和 400。管道也是双向工作的。网关无法读取你的磁盘，因此接受文件的命令将文件名作为参数，并从连接中读取文件内容。例如，ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf 会上传该文件。
4. 零安装。 无需注册，无需存储，无需在上下文中保留。你的 Agent 配置中无需 MCP 服务器，环境变量中无需令牌，PATH 上无需 CLI，无需技能文件。我们构建的是开发产品，所以我们使用了已经存在且每个 Agent 都知道如何使用的工具：SSH。
5. 自我描述且设计谨慎。 discover 会打印完整的命令目录。它包括每个命令、其参数和类型，以及任何确认要求。该目录是从产品实时生成的。它还会告诉客户端哪些字段期望文件字节而不是字符串，因此上传不会被错误猜测。它不允许的是通过行号来定位目标。破坏性命令需要一个名称，服务器会针对连接所选的项目检查该名称。如果在选择了 Support Bot 时请求 Staging，服务器会返回 400 并保持工作空间不变。

无需教导，因为界面会自我教导。

以下是 Oberik 登录流程的样子：

Oberik 登录流程

一个通向你的产品的 SSH 入口难道不是风险吗？

这是一个合理的问题，但实际情况几乎恰恰相反。

网关本身没有状态或权限。每个命令都通过 HTTP 控制平面会话运行，就像在 React 应用中一样。因此，SSH 客户端所能做的不会超过同一个账户在浏览器中所能做的。如果你注销、撤销密钥或删除账户，更改会立即生效，因为没有什么其他东西需要撤销。

这个终端暴露在公共互联网上，所以任何人都可以匿名连接。每个命令都会被记录，包括连接身份、IP 地址、密钥和结果。凭证永远不会被存储。使用 login 输入的密码，或通过 --values 传递的提供商密钥，在记录写入之前会被替换为 <redacted>。系统还会存储原始命令的哈希值，以便关联重复的命令，同时使凭证无法恢复。记录保留 30 天或 100,000 条命令，以先到者为准。

重复失败的登录会变慢，而不是触发锁定。忘记密码的人可以继续尝试而不会遇到太多阻碍，而使用错误密码的自动重试循环则会逐渐变得不那么有效。这就是预期的权衡。

太长不看版

其他人都给你的 Agent 一个 API、一个 MCP 服务器或一个技能文件。我们给了它一个终端。结果发现这正是它想要的。