跨国深谈← 返回←当命令行的使用者变成人工智能助手

当命令行的使用者变成人工智能助手

关联

人物 Pedro Lopez

公司 Airbyte

概念 MCP · CLI · 智能体 · 上下文存储 · OAuth · 技能

Airbyte 是一家做数据搬运起家的公司：把 Zendesk、Stripe、GitHub 这些工具里的数据，接到你的分析流程里。

现在他们往前走了一步，把这些数据做成一个上下文存储，供人工智能智能体查询和调用。

工程师 Pedro 在这场演讲里分享的，是他们为智能体提供两套入口——MCP 和命令行工具——时踩过的坑。

智能体需要哪三种能力？

Pedro 说，不管什么接口，都要覆盖三件事 。

第一，管理产品里的核心资源，比如组织、工作区、连接器。

第二，也是最要紧的：安全地授权第三方服务，但不能把你的账号密码暴露给智能体。

第三，能查、能写、能动手——既要搜索数据，也要能对那些系统执行操作。

他们的原则是：这两套接口都做薄，只是平台的统一入口，不在外面重新实现一遍平台。

平台每天部署 10 次以上，接口必须跟着随时更新，靠 OpenAPI 规格说明作为唯一事实来源 。

MCP：给不想碰代码的人用

MCP（模型上下文协议）是让 ChatGPT、Claude 这类智能体直接调用外部工具的标准方式。

对普通用户来说它足够友好：在应用商店点一下安装，或者贴一个网址就能连上。

演示里，Pedro 问了两个问题：「我有哪些连接器？」以及「找出 5 个有 Zendesk 工单的付费客户」。

智能体自动去上下文存储里查，把 Zendesk 的工单数据和 Stripe 的付费数据交叉比对，给出了答案。

经验教训有 3 条。一是工具数量要少：连接器再多，也只暴露描述和执行两个工具，靠逐步发现来展开能力，别把上下文塞爆 。

二是认证要走 OAuth：协议和主流客户端都押注在 OAuth 上，想用其他令牌方式会处处碰壁。

而且用户期待 MCP 像手机应用一样，登录一次长期可用，而不是像网页那样反复登录 。

三是一条反面经验：协议里的 elicitation 机制（服务器主动向用户要信息）看上去正合适，但各家客户端支持程度参差不齐。

Claude Desktop 就直接告诉他不支持 URL 模式。最后他们只好自己实现授权链接，绕开协议 。

Pedro 的总结是：MCP 有规范是一回事，客户端实际支持什么，是另一回事。

命令行工具：换一套设计思路

命令行工具面向技术用户，但真正的使用者往往是智能体本身。

Pedro 的核心观点是：要为智能体设计命令行，很多对人类友好的设计，恰恰是智能体的障碍 。

第一，输入输出都用 JSON。人类喜欢一堆旗标参数，但智能体更擅长直接构造 JSON，出错更少。

输出也是 JSON 的好处在于，可以用管道把结果交给 JQ 这类工具去筛选、裁剪——这正是命令行的传统强项 。

第二，命名要前后一致。命令用名词加动词的结构，比如 connectors list、connectors create，那 workspace 也必须是 workspace list。这样智能体不用翻文档就知道该怎么做。

还有个反直觉的建议：

如果发现智能体反复调错同一个命令，别怪它笨，把它的错误用法变成正式命令——这说明你的设计不够直白 。

第三，技能（skills）要随命令行一起发布。智能体怎么知道这台机器上装了你的工具？靠技能描述来发现。

但也别把说明全塞进技能里，拆成多个参考文件，让智能体按需加载。

第四，绝对不能有交互式提问。传统命令行经常停下来等你输入确认，智能体会直接卡死在那里。

所有配置都得走环境变量、配置文件，提前准备好 。

那到底选哪个？

Pedro 的答案：各有各的位置 。

MCP 适合非技术用户，快速做原型、跑一次性报表，生态里各个工具还能互相打通。

但限制也实在：Claude 对服务器和工具描述有 2KB 的大小限制，工具运行时长也有限，长时间任务不好做。

命令行没有这些限制，反而危险——没有上限时，智能体可能陷入循环一直空转。

另外命令行需要考虑版本管理，不像托管的 MCP 服务器永远是最新的。

一句话：临时的事交给 MCP，长任务、超长输出、要用管道和文件的地方，交给命令行。

本集带走

• 接口要做薄，都压在共享平台和 OpenAPI 规格之上，才能跟得上每天 10 次以上的部署节奏。
• MCP 的规范和客户端的实际支持是两回事， elicitation 这类新特性落地前别指望它。
• 为智能体设计命令行：JSON 进出、命名严格一致、绝不交互提问。
• 智能体反复犯同一个错，说明的是你的接口设计有问题，改接口比改智能体容易。
• MCP 与命令行各有定位：前者快速易装，后者擅长长任务和 Unix 管道。

所以 MCP 和 CLI，我们构建它们的方式是，它们是接入我们平台的薄而统一的接口，而不是平台的重实现。
So the MCP and the CLI, the way that we’ve structured things is that they are thin, unified interfaces into our platform, not re-implementations of the platform.
—— Pedro Lopez · [03:04]

但我们发现，真正有效的是把它保持得很窄，用渐进式发现来了解连接器可用的所有能力，并真正限制你塞进去的上下文数量。
But instead what we found is really keeping it narrow, using progressive discovery of all of the capabilities that the connector has available and really limiting the amount of context that you shove into
—— Pedro Lopez · [06:30]

技术上讲，你可以通过 MCP 使用其他认证机制，但如果你用 bearer auth 或类似的东西，你会非常难受，因为规范非常偏重 OAuth，而且所有的客户端，至少是主流的那些，都非常倾向于把 OAuth 作为安装该连接器的更好用户体验。
And technically, you can use other authentication mechanisms through MCP, but you’re really going to have a hard time if you do like bearer auth or anything like that, because the spec is really heavy on OAuth, and all of the clients, the main ones at least, are really leaning towards the OAuth as a better UX for installing that connector.
—— Pedro Lopez · [07:15]

当你制作一个 CLI 时，一些可能对用户有帮助的东西，反而会成为智能体的阻碍。
Some of the things that might be helpful for users when you’re making a CLI are going to be like blockers for agents.
—— Pedro Lopez · [11:18]

这里另一个有趣的事实是，如果你看到智能体一遍又一遍地犯同样的错误，多次调用错误的命令，考虑把那个（错误的）用法变成你的契约。
And another interesting fact here is if you see agents making the same mistake over and over, calling the wrong command a bunch of times, consider making that your contract.
—— Pedro Lopez · [13:23]

让智能体能够极其简单地撞见正确的使用方式。
Make it dead simple for agents to stumble across the right way to use things.
—— Pedro Lopez · [13:33]