为智能体设计 CLI，而非只为人设计｜Airbyte Pedro Lopez

简要描述Brief Description

为智能体而非人类设计 CLI——Pedro Lopez，AirbyteDesigning CLIs for Agents， Not Humans — Pedro Lopez， Airbyte

目录Table of Contents

• 简介
  Intro
• 从数据迁移到 AI 智能体
  From data movement to AI agents
• 上下文存储
  The Context Store
• 接口所公开的内容
  What the interfaces expose
• 在单个平台上的轻量级接口
  Thin interfaces on one platform
• MCP 服务器
  The MCP server
• 演示：ChatGPT 中的 MCP
  Demo: MCP in ChatGPT
• 保持工具数量精简
  Keep the tool count small
• OAuth 才是正确之道。
  OAuth is the way
• 用户期待长时间的会话
  Users expect long sessions
• 需求获取尚未准备就绪
  Elicitation isn't ready yet
• 命令行界面 (CLI)
  The CLI
• 演示：命令行界面
  Demo: the CLI
• 为智能体设计 CLI
  Designing CLIs for agents
• 输入 JSON，输出 JSON
  JSON in, JSON out
• 一致性
  Consistency
• 通过 CLI 发布技能
  Ship skills with the CLI
• 无需提示：智能体身份验证
  No prompts: auth for agents
• MCP 与 CLI 的比较
  MCP vs CLI

简介Intro

大家好。呃，我叫 Pedro，是 Airbet 的一名软件工程师。今天我们要聊聊我们是如何构建自己的 agent MCP 和 CLI 的。嗯，在深入探讨这些细节之前，我想先介绍一下 Airbet 是做什么的，以及这一切是如何……Hello everybody. Uh my name is Pedro. I'm a software engineer at Airbet. And today we're going to be talking about how we built our agent MCP and our CLI. Um, and before we go into the nitty-gritty of all of that, um, I wanted to give a bit of context on what we do at Airbet and how all of this kind

从数据迁移到 AI 智能体From data movement to AI agents

……如何融入我们的产品。嗯，Airbite 已经运营有一段时间了。我们最初是数据迁移领域的开源标准，连接你可能会用到的各种 SaaS 工具，比如 Zendesk、Stripe、GitHub 等，并将它们接入你的数据分析管道。现在，我们运用同样的专业经验，发展成为面向 AI 智能体的数据与行动层。我们通过提供一款智能体产品来实现这一点，它……of fits into, uh, our product. So, Airbite's been around for a while. Um, we started as the open- source uh, standard for data movement. Um, connecting all of your SAS tools that you might be using like Zenesk, Stripe, uh, GitHub, etc. to um, your data analytics pipelines. And now we're using that same expertise and have evolved to being the data and action layer for your AI agents. Um, and we do that by offering a or agent product um that has

上下文存储器The Context Store

我们所说的上下文存储库，会连接到我之前提到的所有那些工具，并位于你的智能体之间，提供一个针对搜索优化的数据索引，让智能体能够更高效地查询数据。这样，你就可以通过我们的联系人存储库，轻松收集并关联这些工具中的各类记录、联系人以及其他信息。我们的目标是让数据随处可用、随时可操作。为此，我们提供了几种访问这个上下文存储库的方式。一种是我们的 SDK，如果你正在构建自己的智能体和工具，用它会更方便。另一种是我们的 UI，你可以通过我们的 Web 应用快速使用它。what we call the context store which connects to all of those tools that that I mentioned before and sits in between your agents um to provide a search optimized index of all of your data um that is able to be more efficiently queried by your agents. So, you're able to gather information about all of these um records and and and contacts and stuff that you might have in these all all these tools and join them together in an easy way uh through our contact store. And so, our goal is that we want to make data available and actionable everywhere. And so, we have a couple different interfaces by which you can access this context store. Um, one is our SDK, which is more usable if you are uh building your own agents and your tools. Um, our UI, which is, um, just a quick way that you can use it through our web app.

嗯，接下来我们这次演讲要重点介绍的是 MCP 和 CLI，它们可以让我们轻松地在现有的智能体（比如 ChatGPT 和 Claude）中使用它。嗯，所以……Uh, and then what we're going to be focusing on in this talk, which is our MCP and our CLI, which is um, a way to easily make that um, available within existing uh, agents like Chad GBT um, and and Claude. So

接口所暴露的内容What the interfaces expose

我们通过这些接口究竟要开放什么？嗯，主要有三件事。第一，能够管理我们产品的所有核心资源：组织、工作区和连接器。嗯，所以所有这些接口都应该让你能够与这些资源交互。第二，嗯，非常重要的一点是，能够对我之前提到的那些第三方服务进行身份验证，而且要以安全的方式进行，不让 AI 代理接触到你的凭证。第三，嗯，查询和执行操作。我们希望开放这样的能力：能够搜索上下文存储，能够读取和写入，并在所有这些系统中执行操作。嗯，所以我们希望所有接口都能覆盖这三项能力。嗯，比如 MCP 和 CLI，它们的……what exactly are we exposing through these interfaces? Um three main things. One is the ability to manage all of the the core resources of our product to our organizations workspaces and connectors. Um and so all these interfaces should let you uh interact with that. Second um super important is be able to authenticate those thirdparty services that I mentioned about earlier um and do so in a way that's secure and doesn't expose your credentials uh to to the AI agents. And third um ask and act. So we want to expose the ability to search across the context store uh be able to read and write uh take action on all those systems. Um, and so we want all of our interfaces to be able to span across these uh three capabilities. Um, so the MCP and the CLI, the way the

单个平台上的轻量级接口Thin interfaces on one platform

我们对这些东西的架构方式是：它们是接入我们平台的轻量统一接口，而不是对平台的重新实现。因此，这些接口的大部分表层功能都是用于展示的：接收一条命令，调用平台，再以某种方式格式化结果。所有东西基本上都构建在我们的共享平台和 API 之上。因为我们希望频繁部署——你知道，我们的平台每天变更十多次——所以我们希望随着平台的演进，及时更新这些接口。因此，其中很重要的一部分是将开放的 OpenAPI 规范作为连接我们 API 的事实来源。很多接口都是基于这些规范构建的。好，接下来我们来看看这些接口。way that we've structured things is that they are thin unified interfaces into our platform, not reimplementations of the platform. So most of the surface layer of these uh interfaces are presentational where you take a command uh and you call the platform and format the results in some way. Uh and everything kind of sits on top of our shared platform and APIs. Um and because we want to we deploy a lot, you know, our our platform changes like over 10 times a day, we want to keep these things up to date as we go. And so a big part of this as well is open a open API uh specs as a source of truth for how to connect to to our APIs. And a lot of those interfaces um are built on top of uh those specs. Okay, so let's go into these interfaces.

MCP 服务器The MCP server

我们先从 MCP 开始。MCP 对不太懂技术的用户来说确实很棒。就我们的情况而言，它很适合那些只想轻松地将数据直接接入 ChatGPT 或 Claude 的用户。它们的另一个优点是封装得非常好，也很容易安装。比如，这是我们在 ChatGPT 应用中的上架页面，也就是他们的官方商店。我们也为 Anthropic 的应用提交了申请，目前还在等待审核。如果 Anthropic 的朋友在这里，希望你们能批准我们的申请。不过，即使不通过这些应用市场，终端用户安装起来也相当简单：只要提供托管的 MCP URL，就能很快连接起来。Let's start with let's start with the the MCP. And so MCPs are really great for users that might not be technical. Um, and in our case, it's great for those users that just want to plug their data straight into Chat DBT or Claude in an easy way. Um, and the cool thing is they're they're very nicely packaged. They're very uh easy to install. For example, here's our um listing on the Chad GBT app. uh listing the official uh store that they have. Um and we also have a application for the the anthropic one uh which we're still pending on if there's anybody from Enthropic out there that wants to approve us. Um but even if you're not on these marketplaces, um they are pretty trivial to install uh for a an end user. You just give it the hosted MCP URL and you're able to um connect pretty quickly.

演示：ChatGPT 中的 MCPDemo: MCP in ChatGPT

好，我们来看一个例子。这就是 MCP 实际运行的样子。我在这里问：“我有哪些连接器可用？”它回答说：“嘿，我在这个工作区里设置了四个连接器。”接着，我可以问它一些关于数据的问题，比如：“列出五位有 Zenes 支持工单的付费客户。”此时，它正在查看我们拥有的所有连接器，在上下文存储中搜索我询问的信息，然后整合 Zenesk 和 Stripe 中的信息，为我生成答案。好，结果出来了。它交叉比对了 Zenesk 和 Stripe，然后列出了五位有未解决支持工单的客户。不错。接下来，我们来谈谈构建这个 MCP 时总结的一些经验，以及如果你也要做类似的事情，可以留意哪些方面。Okay, so let's look at uh an example. This is our MCP in action. Here I'm asking, you know, which connectors do I have available? Um, and it goes through, hey, I have four connectors set up in this workspace. And then I can ask it some questions about my data like show five paying customers with Zenes support tickets. Um, and so this right now is looking through all the connectors that we have, searching the context store for that information that I that I asked it about. Um, and then combining that information across Zenesk and Stripe, um, so that it can come up with an answer for me. Okay. And there we go. So it cross referenced Zenesk and Stripe and then came back with, you know, five of those people that um, have open support tickets. Cool. So let's go into kind of some lessons learned while building this uh MCP and things that you might want to keep in mind if you're doing uh something similar.

所以我们经过反复尝试后，决定做的一件事是……So one thing that we decided to do um after trial and error

保持工具数量精简。Keep the tool count small

是为了尽量减少工具数量。对于连接器的执行部分，也就是提取数据的部分，我们只开放或实际使用两个主要工具。一个是描述连接器，以获取查询相关信息的模式；另一个是执行工具，可以读取、写入和删除记录。 与此相反的一种做法是，鉴于我们连接了许多不同的连接器，而且每个连接器都有不同的实体和可执行的操作，我们本可以为其中每一种都开放一个 MCP 工具。但我们发现，更好的做法是尽量保持精简，通过渐进式发现来了解连接器提供的所有功能，并严格限制塞进这些工具描述中的上下文量。这样确实有助于提升 MCP 服务器的性能。is to keep the tool count small. So um we for the execution part of the connector where you're pulling that data, we only expose or really deal with two main tools. one is to describe the connector to get the schema of how do you query that information and two is the execute that's able to read write and delete records. Um the opposite end of the spectrum here would be since we connect to so many different um connectors and each of these has different entities different actions you can take. We could have exposed, you know, an MCP tool for each one of these. Um, but instead what we found is really keeping it narrow, using progressive discovery of all of the capabilities um that the connector has available. Um, and really limiting the amount of context that you shove into the those tool descriptions um really helps with the the performance of the of the MCP server.

OAuth 是解决之道。OAuth is the way

第二，OAuth 是正确的方式。这里指的是如何对 MCP 服务器本身进行身份验证。比如 Anthropic 的这个示例，你点击一个按钮进行连接，就会启动我们的 OAuth 流程。这样你就可以登录 Airbyte，接受所需权限，然后就能使用你已关联的所有连接器了。理论上，你也可以通过 MCP 使用其他身份验证机制，但如果采用 Bearer Auth 之类的方式，会非常棘手，因为规范非常偏重 OAuth，而且所有客户端——至少主要的那些客户端——都倾向于使用 OAuth，因为这样安装连接器的用户体验更好。这就是 Anthropic 自定义连接器注册的一个示例，他们没有提供让你输入 Bearer Token 之类信息的方式。Two, Olaf is the way. So this this refers to how you authenticate the MCP server itself. Um so this is an example for like anthropic. You click a button uh to connect and that spins up our ooth flow. So you can sign in to air bite um accept the the privileges and then you're all set up with all the connectors that you've uh linked up. Um, and technically you can use other authentication mechanisms through MCP, but you're really going to have a hard time um if you do like beer off or or anything like that because the spec is really heavy on ooth and all of the clients, the the main ones at least um are really leaning towards the the OAF as a better UX for uh installing that connector. So that's an example for uh the the enthropic um custom connector um registration where they have no no way of you to put like a bearer token or anything.

它只是全部都默认到 OOTH。所以这这非常重要。第二，用户实际上会期待，嗯，去……It's just all defaulting to to OOTH. So that's is is very important. And two, users actually expect um to

用户期待长时间的会话。Users expect long sessions

通过这些 MCP 服务器维持长期会话。与 Web 应用不同，用户可能可以接受偶尔需要重新登录，但他们希望像使用移动应用一样使用 MCP：不用总想着身份验证，想用的时候随时都能用。因此，在实现 OAuth 时，有一些需要注意的地方，比如维持离线状态下的长期会话；这些会话需要与 Web 应用分开存储，并且有自己的一套生命周期。have long lived sessions uh through these MCP servers. Um unlike a web app where you might be okay with having to sign in again um a couple times, uh users expect to use MCPs more like a mobile app where they don't really have to think about authenticating. It's just available uh whenever they want to use it. And so that has its own little um you know uh things to keep in mind as you're implementing ooth is keeping offline long sessions um that are stored separately from the web app and have its own set of uh of life cycles.

信息采集功能尚未就绪。Elicitation isn't ready yet

好。不过，信息征询并不是正确的方式。接下来我会介绍一下什么是信息征询，但我提到的 MCP 服务器有很大一部分工作是：你需要能够连接自己的工具，也需要能够以安全的方式提供凭据。嗯，要做到这一点，基本上当你问“我该如何连接到 HubSpot？”时，我们会生成一个链接。你打开链接后，会弹出一个小组件，你可以选择想要连接的实体，然后跳转到 HubSpot，完成 OAuth 流程。嗯，从技术上讲，MCP 规范中有一项功能，叫作信息征询，可以让你展示这类 URL 并处理这些输入。它是一种向用户请求信息的方式。很长一段时间里，信息征询只有表单模式，而这并不适用于凭据这类敏感数据，比如 API 凭据。Cool. Elicitation though is not the way. So I'll get into what elicitation is but a big part of um the MCP server that I mentioned is you need to be able to connect your tools. you need to be able to give credentials in a way that's safe. Um, and to do that, uh, basically when you ask, you know, how do I connect to to HubSpot? Um, we generate a link that you go to which you can pops up this widget and you're able to select, you know, which uh entities you want to connect and redirect to to HubSpot to go through the that OOTH flow. Um, now technically MCP has something in the spec that allows you to surface those kinds of URLs um and and process those inputs um called elicitation. It's a way that you can request information from the user. For the longest time um it was only form mode elicitation which is not um applicable for sensitive um sensitive uh data like credentials for an API.

但最近，嗯，这种 URL 模式的信息征询也出现了，嗯，和我们正在做的事情非常相似。但问题在于，呃，各个 MCP 客户端的支持情况。所以，使用 MCP 时有个很重要的主题就是：尽管有规范，各个客户端对功能的支持情况还是相差很大。嗯，这是一个来自 Claude Desktop 的例子，你知道，它只是告诉我：“嘿，我不支持 URL 模式的信息征询，没法这么做。”所以我们不得不回过头来自己实现，嗯，不再使用规范来处理这种……But more recently um this URL mode elicitation became a thing um that is very similar to what we're doing. But the problem is uh support across the MCP clients. So that's a big theme uh when working with MCP is that even though there is a spec features that is are supported across the clients kind of vary quite a bit. Um so this is an example from cloud desktop where you know it just is telling me hey I don't support URL mode elicitation. I can't do that. And so we had to go back to doing our own thing um and not using the spec for that for that kind of

命令行界面The CLI

东西。好，我们稍微聊聊 CLI。如果说 MCPS 对这些非技术用户来说比较容易上手，那么 CLI 可以算是更偏技术的对应工具，在某些方面也更强大。thing. Okay, let's talk about the CLI a bit. So if MCPS are easy for these non-technical users, um CLI are kind of the more technical counterpart might call it the kind of more powerful in some ways that

演示：命令行界面Demo: the CLI

我们稍后会讲到。这个例子和之前看到的是同一个，只不过这次用的是 MCP，哦不，是 CLI。我们问它：“我有哪些连接器可用？”这次它加载了一个介绍 CLI 的技能。然后用 CLI 本身来查询。我们拿到了连接器列表。接着我们问：“显示五位有 Zenes 支持工单的付费客户。”和上次一样。这次它能够使用 CLI 来查询那个查询上下文存储，汇总这些数据，最终应该会返回结果。好，那么这五位用户还是之前那五位。嗯，关于 CLI 的设计方面，我觉得……we'll get into. And this is the the same example we saw earlier, but this time with the the MCP or sorry, with the CLI where we're asking, you know, which connectors do I have available? It's this time loading a skill that tells it about the CLI. Um, and then, you know, using the CLI itself to query things. We got back the connectors. Then we asked, you know, show five paying customers that have Zenes support tickets. Same as last time. um it's able to this time use the CLI to query that query the context store aggregate that data and then eventually it should come back with a result now okay um so there's those same five um five users so um on the design side for CLI I think

为智能体设计 CLI】【。Designing CLIs for agents

需要牢记的一点是，设计这些 CLI 时要考虑到智能体。嗯，你在制作 CLI 时可能觉得对用户有帮助的一些东西，对智能体来说可能会成为障碍。嗯，我们稍后会进一步谈到这一点。嗯，我们在这里做出的第一个设计决策是：采用 JSON。one important thing to keep in mind is to design those CLIs with agents in mind um some of the things that might be helpful for users when you're making a CLI are going to be like blockers for agents. Um, and we'll get into that a little bit more. Um, the first design decision here that we made was take JSON

输入 JSON，输出 JSONJSON in, JSON out

输入 JSON，输出 JSON。因此，对人类来说，指定一堆标志来使用 CLI 非常方便；但遇到这些更复杂的输入时——你得构造它们来发起查询——智能体处理 JSON 就很擅长。相比使用那些标志，它们能够以更直接、也更少依赖猜测的方式构造这些输入。至于输出，JSON 也让处理较长的响应变得容易，还能让你利用 CLI 的一项关键能力：你有一个带管道的 Unix 系统，可以把输出重定向到不同的程序。例如，你可以用 jq 从输出中选出特定内容并精简它。所以，JSON 确实释放了很多……in and return JSON out. So uh for humans it's very nice to specify um a bunch of flags uh to work with CLIs but when it comes to these more complicated um inputs that uh you have to build to to make these queries and agents are really good at working with JSON. um they're able to construct this uh in a much more um direct and and less of a guessy way um than using those flags. And so on the output, JSON also makes it easy to deal with longer responses um be able to leverage one of the key capabilities of CLIs, which is hey, you have these this Unix system with pipes that you can redirect the output to different um programs. So you can use jq for example to select certain certain things from the output and trim that and so JSON really unlocks a lot of

一致性Consistency

这种能力。第二，一致性在这里至关重要。对于你提供的所有资源，智能体都应该能一眼看出该如何操作。比如，如果你的 CLI 采用“名词 + 动词”的结构，例如 `connectors list`、`connectors create`，那么在实现 workspace CLI 命令时，也要确保它们遵循相同的格式。比如，我们还有 `workspace list`。因此，智能体必须知道正确的操作方式，而且应该很容易就能弄清楚，不必阅读一大堆文档。还有一个有意思的现象：如果你发现智能体一再犯同样的错误，比如反复调用错误的命令，不妨考虑把这种行为纳入你的契约。that um capability. Two consistency is very much key here. So it should be dead obvious for agents to know how to do something across all of the resources that you're exposing. If you have structured your CLI in a way that it's it's structured where there's a noun and then a verb for this example you know connectors list connectors create make sure that when you're implementing a workspace um CLI uh commands they also follow that same format. So workspace list is another one that that we have. And so it's very um critical that agents know the right way to do things and it's easy for them to know the right way to do things without having to read a bunch of documentation. And another interesting fact here is, you know, if you see agents making the same mistake over and over, um calling the wrong command a bunch of times, consider making that your contract.

让智能体能轻而易举地找到正确使用各种东西的方法。嗯，因为如果智能体总是犯同一类错误，通常就说明你的 AP 或 CLI 契约里有些东西还不够清晰。第三，技能是随……一起发布的，呃……Make it dead simple for agents to stumble across the the right way to to use things. um because that usually means that something is not quite as obvious as it should be in your AP in your CLI contract if agents keep making the same kind of mistakes. Three, skills are skills ship with uh

通过 CLI 发布技能Ship skills with the CLI

CLI 工具。所以在使用 CLI 时，技能是必不可少的。呃，因为如果你安装了一个 CLI，智能体又怎么会知道这个 CLI 存在呢？所以它对发现你可用的工具很有帮助。嗯，它们也有助于有效地使用这些工具。比如，我们有一个会被呈现出来的技能。只要你问到任何有关连接器的问题，它的描述就能出现。它知道要提到那个 CLI 并调用它。嗯，技能的组织方式也是需要考虑的。你知道，技能里不能放太多内容，不然会占用太多上下文。嗯，技能可以拆分成参考资料：你可以设置一个主技能，让它指向技能目录中的其他文件，以便补充有关不同命令的信息。the CLI tool. So skills are a must uh when you're doing CLIs because how else if you have a CLI installed is an agent going to know that that CLI even exists in the first place. So it helps a lot with discovery of uh your tools that are available. Um and they also help with uh using that tool effectively. So uh we have a skill that gets surfaced. It has a a description that is able to come up whenever you ask anything about connectors. It knows to bring up that CLI and invoke it. Um and then the way that you structure the skill is also something to um think through. you know, you don't want to put too much into the skill uh that you're going to bog down the context. Um, skills have this uh ability to be separated out into references um where you can have a main skill that points to other files in a in a skill directory um that can expand information about the the different commands.

而且这确实有助于减少你加载的上下文量，并利用这些代理的渐进式发现能力。很好。然后，关于 off side，off 在 MCP 方面很有意思。在其他方面也很有意思……And that really uh helps cut down the the amount of uh of context that you're loading in and um leverages the progressive discovery um ability of uh of these agents. Cool. And then another interesting fact uh for off side, off was interesting on the MCP side. It is interesting in other

无需提示：代理身份验证No prompts: auth for agents

这是 CLI 的做法，因为我们不能假设一定会有人在场，能够与这些提示进行交互。嗯，当智能体调用 CLI 时，它没法就这么等着你往 CLI 里输入提示。你必须通过标志参数，或者在凭据的情况下通过环境变量和配置文件来提供这些信息，这样就能在调用 CLI 之前，在带外完成设置，不必每次调用 CLI 时都等着处理这些事情。嗯，我想，除了身份验证之外，这也是一个普遍问题：很多面向人类构建的 CLI，你输入一条命令后，它就会停在那里，等待并询问你一些问题；而这些 CLI 并不适合让智能体正常使用。嗯，智能体就会这么卡在那里。嗯，好。那么 CLI 和 MCP，哪个……ways for CLIs because we can't assume that a human is going to be present to able to interact with those prompts. Um when CLIs are being invoked by agents, it can't sit there and wait for you to type um a prompt into the CLI. you have to expose things either through flags um or in the case of credentials environment variables and config files um so that things can be set up out of band and you don't have to wait for that uh whenever you're invoking the CLI um and I would say aside from off um that's a general thing a lot of CLIs that are built for humans you type a command and it'll wait there ask you for prompts uh and that is not um you know able to be used properly ly by these agents. Um they'll just kind of get get stuck there. Um cool. So CLI and MCPs, which one is

MCP 与 CLI 对比MCP vs CLI

更好吗？嗯，它们各自都有一些取舍。你知道，MCP 的规范并没有在所有地方得到统一实现。嗯，除了规范本身之外，不同的提供方还会决定实现一些限制。比如，Claude 对服务器和工具调用的描述有 2 KB 的长度限制。工具运行时间也有限制。所以，通过 MCP 执行耗时更长的流程会比较困难。嗯，你知道，他们还引入了其他一些限制。至于 CLI，MCP 的一些优点是，你可以使用托管的 MCP 服务器，它会始终保持更新。但 CLI 并非如此。你需要更多地考虑版本管理。要让软件包跟上这些新功能并保持最新，也更困难。better? Well, they both have kind of their own trade-offs. You know, with the MCP, the spec is not uniformly implemented across the board. Um there's a bunch of limits that these providers decide to implement aside from the spec as well. For example, like Claude has a 2 kilobyte limit on server and tool call uh descriptions. There's a limit of how long the tools can run. So it's harder to do more longunning processes through MCP. Um and uh you know there's there's other kind of kind of limits that they've introduced there. And then on the CLI, the cool things about MCP like you know you can have a hosted MCP server that just is always updated. That's not quite the case with the CLI. you have to think more about versioning. It's harder to keep packages up to date uh with all these new features.

嗯，虽然 MCP 端的限制确实会有所约束，但如果 CLI 在各个工具和调用之间没有这些限制，就可能出问题，反复陷入循环，让智能体一直空转。所以我认为两者各有用武之地。MCP 很适合非技术用户，可以快速搭建原型、制作一次性报告，甚至利用 MCP 生态让不同事物彼此交互。而 CLI 更适合技术用户、运行时间更长的任务，或者输出特别长、需要利用 Unix 和管道功能的场景，比如将输出重定向到文件，再对输出使用 tail 或 head。CLI 真正开始大放异彩的，正是这些场景。Um and there's no while the limits can be well limiting on the MCP side, not having any of those on the CLI across the tools uh across the the calls of the CLI can make things go wrong and continually go through loops that um you know make the agent spin. And so really I think both have their place. I think MCPs are great for those non-technical users, be able to quickly prototype things, build one-off reports, um, and even leverage that MCP ecosystem to have things uh, talk to each other. And then the CLI is better for those more technical users, more longer running tasks, maybe outputs that are super long and you need to leverage those um features that Unix and and the pipes give you where you can redirect output to a file. You can do a tail, do a head on that output. Um that's where really the the CLI um starts to to shine.

好了，我要说的基本上就是这些。嗯，我们在那边的 Airbite 有个展位，欢迎去看看，也欢迎来和我们一起工作。谢谢。All right, that is basically all that I had. Um, we have a booth over there at Airbite um that you should check out and come work with us. Thanks.