在2026年3月，我们推出了Knock代理：一个用于管理您在Knock中的所有客户消息资源的AI代理。它可以创建和更新工作流程、模板和受众，帮助细分用户，并回答有关客户消息表现的问题。代理可以通过Knock仪表盘、连接的Slack工作区、API或我们的MCP服务器调用。在这篇文章中，我们将深入了解如何使用bash、虚拟文件系统和我们的管理API来架构和构建我们的代理。\n为我们的代理定义愿景\n我们的愿景是创建一个可以管理从Knock仪表盘访问的所有内容的代理。我们希望代理能够创建符合您公司设计系统、匹配语气，并理解您的数据模型的消息。为了实现这一愿景，我们需要创建一个丰富的代理工具，可以访问您Knock账户中的所有数据，并在创建消息和回答任何问题时使用这些上下文。我们构建了第一个原型，专门用于处理工作流程，这是一个充满细节的深域，围绕其运作方式有很多细微之处。我们采用了按类型划分工具的模式，每个工具都暴露了我们管理API中的一个原语，例如为工作流程添加延迟步骤，或使用我们的可视化块语言构建电子邮件模板。工具描述编码了与该工具使用相关的特性，并给出了示例，而工具输入描述了字段类型和所需内容。虽然这样运作良好，并取得了不错的效果，但我们意识到这种方法无法扩展：我们将为管理API中的每个资源暴露一个工具，这将使代理的上下文窗口膨胀，而我们并未实现更复杂的工具路由层或引入代理使用的脚本语言。\n更少的工具，更多的文件\n我们找到了一篇来自Vercel团队的博客《如何使用文件系统和bash构建代理》，在其中他们描述了为d0（他们的内部数据工具）构建代理的过程。他们解释了文件系统是代理发现所需上下文的好方法，以及如何将一个域映射到文件系统以增强这一上下文层。在Knock，我们长期以来一直拥有一个CLI，使团队能够下载他们的Knock资源，例如消息模板和组件，并通过文件系统在本地操作它们。这里的想法很简单：与其暴露镜像我们管理API的工具，不如给代理提供一个包含您账户内容的文件系统，以及使用bash在该文件系统上进行脚本编写的能力。这样，代理可以探索文件系统以收集上下文，并使用bash有效地编写所需的脚本。当代理想要编辑工作流程或模板时，它在文件系统中就地修改一个文件，并调用Knock以持久化该更改。这种模式比其他产品内助手更接近Claude Code和其他编码代理，它符合我们已经通过CLI和以本地为先的方法维护客户消息所确立的哲学。\n代理的bash，使用Elixir\n在2025年假期期间，Vercel的Malte发布了just-bash。想法很简单：让代理拥有一个unix文件系统和bash环境，而不需要启动Linux镜像。实际上，这意味着在TypeScript中创建一个虚拟的bash实现，代理可以调用一个虚拟文件系统。Knock是一家深植于Elixir生态系统的公司。我们希望拥有一个自己的虚拟bash解释器。我们的选择是1）放弃我们在代理上所做的工作，并在TypeScript中重建它，或者2）将该库的一个版本移植到Elixir。幸运的是，像just-bash这样的库是一个可重现的代理目标。它具有明确定义的表面区域和涵盖其支持的命令（jq、ls、cat等）的全面测试套件——我们的Elixir移植方案逐字重用这些固定示例。在一次史无前例的“书呆子”争论中，我们说服了Knock的朋友、深谙代理之道的Ivar Vong尝试一下。经过多次令牌事务后，我们在Elixir中完成了一个完整的bash解释器和虚拟文件系统，他也称之为just-bash，具有广泛的测试套件和稳健的安全模型。\n为什么不使用沙箱？\n显然的问题是：为什么不给代理一个完整的计算机，使用沙箱，而不是虚拟文件系统？毕竟，我们可以选择很多供应商来支持它。我们认为，考虑到我们简单的需求，完整的沙箱在这个阶段是过杀。启动沙箱的性能成本高于虚拟的内存选项，并为我们希望推迟解决的内容及在我们的应用外部所做的更改引入了更复杂的同步问题。如果复杂性增加，我们将在此决策上进行重新评估。在bash之外，为代理编写完整的脚本语言（如Python）可能是决定性因素。我们遵循将手与大脑解耦的原则，因此转向真实沙箱意味着只需跟踪复杂性。