最新

嘿，HN，我在一个项目上需要在不同的电脑之间切换Claude和Gemini时开始感到疲惫，因为这个项目需要在多台机器上同步运行。这种情况变得非常烦人，因此我开发了agent-comms，这是一个零依赖的工具，可以处理在同一台或不同物理机器上异步或同步（实时）工作的不同代理之间的协调。请查看上面链接的代码库，并欢迎留下任何反馈，谢谢！

嗨，HN - 我是一个长期潜水者（自2012年以来！），第一次发帖。 Pizza Bot 是一款自托管的桌面应用程序，支持 Mac、Windows 和 Linux，能够在后台运行 AI 代理，并通过类似电子邮件的用户界面进行展示。完成的工作会出现在“未读”中，而任何等待您批准的内容则会显示在“待处理”中。它采用 Apache 2.0 许可证，无需注册，也没有遥测，您可以使用自己的模型提供者：Anthropic、Amazon Bedrock、Google Gemini、OpenAI、OpenRouter，或者通过 Ollama 使用本地模型。您可以在发布页面找到构建版本，或者从源代码运行它。 Pizza Bot 最初是我和亚马逊的小团队一起开发的一个内部激情项目。 这一切源于我对必须通过浏览器表单手动记录 CRM 活动的沮丧。我构建了一个简单的 REST API，名为“JoeBot”，它通过 CDP 连接到我经过身份验证的浏览器会话，并使用 Playwright 自动填写表单。然后，我快速制作了一个 Obsidian 插件，以便我可以从本地笔记中触发它（没有 AI 也没有 MCP 服务器参与）。 这个想法迅速受到欢迎。我的同事 AWS 解决方案架构师 Igor Fil 加入了我，我们将项目重新命名为“Pizza Bot”，灵感来自亚马逊的“两比萨团队”。我们开始探索可以构建的其他自动化功能。我们找到一个可以查询的 GraphQL API，并快速制作了一些“食谱”，以从 CRM 中提取数据，帮助会议准备。这一切运行得很好，恰好在 MCP 服务器似乎开始流行的时候，我们决定将 Pizza Bot 作为 MCP 服务器公开，这样它就可以通过自然语言为 AI 工具所用。 这对技术用户来说是一个不错的解决方案，但在我们的 CRM 系统中工作的客户经理们也想要一些东西。我们决定将 Pizza Bot 重新构建为一个 Electron 桌面应用程序，模仿电子邮件收件箱的界面，以便非技术用户也能轻松使用，并且能够在 Mac 和 Windows 上运行。我们还将内部 MCP 服务器打包为 OCI 镜像，并将其托管在 Amazon ECR 中，作为“附加市场”，用户可以一键安装，而无需设置亚马逊开发工具。 该项目自然而然地发展，并扩展到全球更广泛的亚马逊组织中。最终有超过2000人使用它进行会议准备、电子邮件草拟、Slack 摘要、CRM 记录、日程优先级排序和网络研究。 当像 Claude Cowork 和亚马逊自己的 Quick Desktop 等应用程序推出时，我们意识到真正的增长机会在亚马逊之外。与其尝试去掉亚马逊特定的集成，我们再次将 Pizza Bot 重建为一个开源项目。我们在编码代理方面投入了大量精力，这也是我们这样规模的团队能够完成全面重写的唯一原因。我很高兴地说，它终于公开了，我们希望吸引社区成员，看看它的发展方向。我们希望为知识工作者做的事情，正如 Claude Code 和 Codex 为程序员所做的那样。 有几件事情需要提前了解。Pizza Bot 在亚马逊内部第一天之所以有用，主要来自于内部技能和 MCP 服务器的目录，而这些内容无法随应用程序一起发布。因此，它的版本比那2000人使用的版本要精简，而重新构建一个其他人实际使用的工具目录是我们最需要帮助的地方。此外，它是一个社区项目，而不是 AWS 服务，因此没有支持或服务水平协议（SLA）。Windows 和 Linux 的构建版本也尚未签名。 在技术方面，Pizza Bot 是一个服务器和一个客户端。桌面应用程序将两者打包在一起，或者您可以将客户端指向远程后端；就我个人而言，我在家用网络上自托管服务器，并通过 Tailscale 从手机访问它。服务器管理线程生命周期，并使用 DeepAgents 和 LangGraph 进行状态检查，客户端根据需要从中重建，因此您可以在运行中断开连接，并从另一个客户端恢复线程。批准的暂停超出创建它的会话，并在“待处理”过滤器中收集，因此您可以在一小时后从不同设备上进行回复。您与之交谈的代理有一个沙箱化的 QuickJS 解释器，只有在您授予它一个文件夹时才能访问您的文件系统，但它的主要工作是委派。每个子代理与一个技能一一对应，活动栏显示该子代理及其正在进行的工具调用。内存是可选的，并以纯 Markdown 文件的形式存储在您的计算机上。每个工具调用都是明确的，包括查找内存 - 我们在透明度上倾向于减少意外。工具来自 MCP 服务器，技能是普通的 SKILL.md 文件，具有每个工具的批准策略，因此不需要代码解释器的现有技能仍然应该可以正常工作。 我最想听到的是应用程序本身在哪些方面妨碍了您，以及您无法通过编写技能或 MCP 服务器来解决的问题。我今天在这里回答问题！

我一直在进行一个项目（Make0 AI），目标是为Codex和Claude Code提供一个共同的上下文。问题很简单——在使用Claude时，由于每天/每周的使用限制，我不得不在Codex中重新开始。当然，我可以让Claude总结一个我可以交给Codex的交接内容，但这效率不高。 因此，我想到在本地为它们创建一个共同的上下文，使用一个简单的指令列表，比如一个共享的md文件。但问题是，这个文件不断增长，最终共同的上下文超过了2万个token，导致token预算不必要地膨胀。 于是，我在这个列表上实施了一种基于RAG的检索方法，只加载该提示所需的内容，经过几次迭代，它最终形成了一个图形记忆——大脑。 这个产品Make0 AI使你能够创建大脑，并通过MCP连接到任何AI代理，这样它们就能立即了解你的喜好、厌恶、偏好等。AI代理可以读取和写入这个记忆。 这可以成为你的长期记忆，而代理仅仅充当token提供者和任务执行者。你可以从一个地方完全控制你的数据/记忆。可以把它想象成一个“USB闪存驱动器大脑”，你可以将其连接到任何代理。 我知道我可能不是第一个实现这个的人，但我尽量使用户体验简单，并且完全不以开发者为中心。你只需将你的记忆/数据拖放到大脑中，甚至可以与可视化的大脑进行互动。 还有一件事，我对记忆进行了基准测试。LoCoMo的整体得分为83.3%，在标准模式下单跳得分为92.5%（现已可用），在另一种配置（实验最大模式）下，整体得分为92%，单跳得分为94.4%。基准测试页面上可以查看。 目前我将其保持为邀请制。如果你们想试试，请告诉我！