Agent 应用开发实战日记

几周前，我们为由 Bright Data 和 n8n 主办的实时 AI Agents 挑战赛开发了一个名叫 WYKRA 的 agent。这是一个小实验，可以接受自然语言查询，例如"我在巴塞罗那经营一家小面包店，找出在这里讨论面包的影响者"，并返回相关的 Instagram 账户及其上下文信息。

挑战赛结束后，我以为这个想法只会停留在黑客马拉松阶段：有趣、有用，然后像大多数周末项目一样被遗忘。但事实并非如此。这个想法一直在我脑子里挥之不去，以那种"呃，也许这确实值得开发"的方式烦扰我。所以我开始深入挖掘、阅读 Reddit 线程、创始人评论、营销小组和小企业讨论，同一个模式一次又一次地出现：在线寻找相关的声音和社区仍然非常困难。

目前市场看起来是这样的：

• 过时的影响者电子表格
• 精准度可疑的昂贵"数据库"
• 向初创公司收取高昂费用的代理机构
• 或者手动完成：标签、账户跳转、太多标签页、附带一点存在危机

这……不是很好。而且人们在 2025 年仍然采用这种 DIY 方式，这一事实说明了很多问题。

与其让这个想法悄悄消亡，或像"又一个 AI 工具"一样把它锁在登录墙后，我们决定公开构建它，打造真正有用的东西，为开源社区做出贡献，并花接下来三个月在公众视野中开发它。

这实际上是在解决什么问题

第一个版本专注于 Instagram，但 WYKRA 从来都不是真正关于单一平台，甚至不是关于"影响者"这个狭隘概念。问题更广泛：互联网上充满了塑造品味、信任和关注的人、地方和社区，手动查找和评估它们效率极低。

有时这些声音是内容创作者。有时他们是厨师、小企业主、评论家、利基专家，甚至是 Google 地图上的本地商店。无论形式如何，问题是相同的：你需要知道在你的利基中注意力集中在哪里、谁影响它，以及他们是否值得你花时间。

这对营销人员、独立创始人、小企业主、内容创作者和任何想要在不花费数小时滚动平台搜索的情况下接触正确受众的人都很重要。简单来说：帮我找出如果我想成长而不用被标签页和电子表格淹没，应该和谁交流。

第一次尝试的早期教训

即使在草率的挑战赛版本中，WYKRA 也展现了某些真实的东西。事实证明，通过 Bright Data 拉取公开账户数据并将其输入到生成有意义摘要的模型中是出奇地直接的。一旦你给模型提供好的输入，分析就没问题了。这部分不是问题所在。

困难的部分出现在更早一步：实际上找到正确的账户。

"给我显示在巴塞罗那谈论面包的人"听起来很简单，直到你试图将其自动化。Instagram 标签发现的行为与在应用程序内的行为不同。Bright Data 目前不支持直接的 Instagram 标签搜索。我们尝试通过 Bright Data Google Search API 进行发现路由；有时效果很好，有时什么有用的都返回不了。这种不一致现在是真正的挑战。

还有性能问题。抓取和分析数量可观的账户可能需要五到十五分钟。从技术上讲，这对更深入的研究是可以的，但用户会等那么久吗？我们应该缓存结果并逐渐建立我们自己的经过验证的账户集合吗？"实时"在什么点变成"合理的时间，有明智的工程决策"仍然是开放的。

我们还遇到了另一个非常真实的限制：AI 不便宜。Claude 和 Gemini 直接使用时都有严格的速率限制，一旦你超越玩具示例，推理成本就会迅速增加。我们可能需要尝试像 Anthropic 的 prompt caching 这样的选项，并探索是否有任何提供商为开源 AI 项目提供赠款计划或免费信用额度。我知道很多人使用 OpenRouter 来实现多模型访问和较宽松的速率限制，所以我们可能也会探索这条路线。如果你已经走过那条路并有想法或警告，我真的很想听听，不需要重新发明别人已经经历过的痛苦。这段旅程的一部分就是简单地找出最合理的方式来运行这个，而不会在预算上烧出一个洞。

最后，还有商业方面。在线大规模运行这样的 agent 永远不会是免费的，所以一旦托管版本上线，我们需要一个明确的定价模型。目前的想法很简单，基于使用情况的层级，这样个人创作者、小团队和好奇的实验者可以无痛使用它，而更重的工作负载有助于覆盖计算成本。自托管将保持免费；托管版本存在是为了让项目能够自我维持，而不是因为发票而崩溃。

这些不是我们想要隐藏的问题。它们只是现实的一部分，我们计划公开解决它们，而不是悄悄地修补。除此之外，n8n 对黑客马拉松很有效，但它不是开源工具的正确基础。成本模型造成摩擦，而自定义后端将使在本地运行 agent 或自由 fork 它成为可能。

所以下一个阶段不仅仅是关于完善原型。它是关于一步步理解发现、缓存、性能和产品边界，在公众视野中，而不是假装我们已经有了所有答案。

我们的方向（不是严格的路线图，只是方向）

下一步是将 WYKRA 从黑客马拉松的设置变成实用的东西。我们将用真正的后端替换 n8n，使 agent 易于在本地运行，并记录我们所做的决策，而不是事后再说。目标是支持不仅仅是 Instagram，通过尝试不同的平台、搜索方法和数据信号，取决于什么被证明是可靠的。

我们将采取小的、可测试的步骤：稳定核心，添加 Instagram 之外的源，保留有效的并放弃无效的。

我们还找到了一位实际从事影响者研究的营销人员，我们计划用问题来烦扰他，所以我们构建的东西是基于现实的，而不是基于开发者想象。

我们将在 Dev.to 上分享每周更新，并保持过程开放。社区渠道仍在确定中——可能是 Discord 或 Slack，但 GitHub issues 在开始时可能就够了。重点是保持可访问，而不是在有社区之前过度设计"社区基础设施"。

作为背景，"我们"这里只是两个人：我，Olga——一名资深数据工程师和数据博主——和我哥哥 Alex，一名全栈工程师。(如果你喜欢关注技术构建，我的个人博客在这里：Oh That Data Girl)

如何跟随和加入这个旅程

仓库在这里：https://github.com/wykra-io/wykra-api 目前它是空的，这是故意的，我们从头开始，一步步构建它。

如果你感兴趣，可以给它 star 或一周后回来看看有什么变化。我也会在这里和 Twitter 上分享更新：https://x.com/ohthatdatagirl