24小时热榜

I’m Michel, co-founder and CEO of Airbyte (<a href="https:&#x2F;&#x2F;airbyte.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;airbyte.com&#x2F;</a>). We’ve spent the last six years building data connectors. Today we&#x27;re launching Airbyte Agents (<a href="https:&#x2F;&#x2F;docs.airbyte.com&#x2F;ai-agents&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.airbyte.com&#x2F;ai-agents&#x2F;</a>), a unified data layer for agents to discover information and take action across operational systems.<p>Here’s a quick walkthrough: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZosDytyf1fg" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZosDytyf1fg</a><p>As agents move into real workflows, they need access to more tools (e.g. Slack, Salesforce, Linear). That means a ton of API plumbing: authentication, pagination, filters, handling schema, and matching entities across systems.<p>Most MCPs don’t fix this. They’re thin wrappers over APIs, so agents inherit their weak primitives and still get it wrong most of the time, especially when working across tools.<p>An even deeper issue is that APIs assume you already know what to query (think endpoints, Object IDs, fields), whereas agents usually start one step earlier: they need first to discover what matters before they can even start reasoning.<p>So we built Airbyte Agents to be a context layer between your Agents and all of your data. The core of this is something we call Context Store: a data index optimized for agentic search, populated by our replication connectors. All that work on data connectors the last six years comes in handy here!<p>This gives agents a structured way to discover data, while still allowing them to read and write directly to the upstream system when needed.<p>What got us working on this was an insane trace from an agent we were migrating to our new SDK. It was supposed to answer &quot;which customers are at risk of leaving this quarter?&quot; The trace had 47 steps. Most were API calls. The agent first had to find a bunch of accounts, then map them to the right customers, then look for tickets, bla bla... and when the Agent finally responded, the answer sounded ok, but was wrong. Not only that, it was excruciatingly slow. So we had to do something about it.<p>That 47-step agent is one example of a question where Airbyte Agents does particularly well. Other examples: - “Show me all enterprise deals closing this month with open support tickets.&quot; - “Find every support ticket that doesn’t have a Github issue opened”<p>Some of these might sound simple, but the quality of the answer changes dramatically when the agent doesn’t have to assemble all that context at runtime.<p>Once we had an early version of the product, I spent a weekend building a benchmark harness to see if it worked. Also for fun, I like writing benchmarks :). I compared calling the Airbyte Agent MCP vs calling a bunch of vendor MCPs directly. I tested retrieval, and search.<p>For the sake of simplicity, I used token consumption as a unit of measure. I think that’s a good proxy for how well agents are working. A failing agent (like the one that took 47 steps), will churn through lots of tokens while getting nowhere, while a successful one will get straight to the point.<p>Here&#x27;s what I found when measuring: for Gong, it used up to 80% fewer tokens than their own MCP, for Zendesk up to 90% fewer, for Linear up to 75%, and for Salesforce up to 16% (Salesforce’s own SOQL does a good job here).<p>Of course there is the usual obvious bias: we are the builders of what we are benchmarking. So we made the test harness public: <a href="https:&#x2F;&#x2F;github.com&#x2F;airbytehq&#x2F;airbyte-agents-benchmarks" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;airbytehq&#x2F;airbyte-agents-benchmarks</a>. Feel free to poke at it, and please tell us what you find if you do!<p>It&#x27;s still early and some parts are rough, but we wanted to share this with the community asap. We&#x27;d love to hear from people building agents: - Are you indexing data ahead of time, or letting the agent call APIs live? - How are you matching entities across systems?<p>Would also love to hear any thoughts, comments, or ideas of how we could make this better, and if there are obvious things we’re missing. For now, we’re excited to keep building!

我感觉我别无选择，只能接受它。如果我想保住工作，就得用它。我曾为用代码创造东西而自豪，但现在只要在提示框里输入文字，代码就出来了，这让我感到空虚。用这种方式写代码，再也找不到乐趣了。 我知道在我的个人爱好中，我可以这样做……但问题是我需要钱，现在还不能离开，但如果每个工作都变成这样，我想我会离开的。 我并没有否认它的能力，就像今天，我需要做一个能实现HFP功能的蓝牙安卓应用，而且是现在，立刻。凭我现在的知识，我做不到，但AI可以……而且任何会打字的人都能用它，所以我就像是在问，为什么还需要我呢？ 所以，是的，现在我的计划是利用这些工具混日子，做我喜欢做的事情，然后赚足够的钱离开。我会为自己的乐趣编写自己的代码。 我从2013年开始就从事开发/编写代码了。 我不是说我反对这项技术让其他人也能写代码，我是说，如果我必须使用它，而且我不再需要写代码了，我会为此感到难过。没有任何成就感。 还有一件事是，如果你抵制它，就会被看作是消极的人/卢德分子，就像“大家都这么做”一样。

关于 MCP 与 CLI，我有些不理解的地方： 权限：你已经可以控制 CLI 命令的权限。 可发现性：你已经可以通过 help 标志来发现命令/参数。 为什么要给电脑增加一个全新的进程？ MCP 的支持者们是否设想过，未来你电脑上的每个程序都会运行另一个 MCP 进程？ 这似乎是为了微不足道的好处而增加额外的复杂性/移动部件。

我创建了 PaletteInspiration.com，这是一个可浏览的色彩库，其中收录了来自 3000 多位大师级画家（莫奈、维米尔、拉斐尔、梵高）作品的调色板。 我创建它的原因：我尝试过的每一个调色板生成器都只生成相同的五种柔和的粉彩色。画家们花费了几个世纪的时间来研究色彩，而我们在为数字设计选择颜色时，却大多忽略了这一宝贵的经验。 请分享您对“色彩和谐探索器”的反馈——将轮盘拖动到任何颜色上，它都会显示历史上大师级画家将其与哪些色调搭配（不仅仅是标准的互补色、类似色、三色等）。它完全基于数千幅真实绘画作品中的共现。并非基于算法色彩理论规则，而是基于实际的经验搭配。 无需注册，没有付费墙，也不会收集电子邮件。只是想知道大家怎么想。