最新

问题： 1. 你尝试使用 Cloudflare 提供的邮件路由功能。 2. 该功能对你无效。 3. 不知为何，你的 DNS 状态变得异常，邮件路由因配置错误而被禁用。 4. 你无法在不先禁用邮件路由的情况下删除你的 DKIM 记录。 5. 你无法禁用邮件路由，因为它已经因配置错误而被禁用！！ 6. Cloudflare 只为免费账户提供“引导”支持，并将你引导到 /dev/null 来处理这类问题。

使用Claude代码会让你更有可能或更不可能使用前端框架吗？ 我已经使用它一段时间来开发内部工具，我对仅用纯HTML/CSS/JS构建复杂应用程序的能力感到非常惊讶。 之前我会使用React，但现在我不太清楚为什么还要这样做，因为无论如何我都是通过Claude进行开发。 这让我感觉框架几乎只是一个实现细节。 我发现自己总的来说使用的库也少了很多。 这有点让人产生NIH（不发明新东西的症候群）综合症，因为有时候自己动手开发的时间成本实在太低了。

这花了多长时间？你经历了多少个想法？是什么让你坚持一个想法而不是转变方向？

构建了一个开放的 JSON Schema 用于定义 AI 代理团队。 多代理系统正成为一种实际的部署模式——不仅仅是单一的助手，而是具有角色、交接和人类检查点的团队。然而，目前没有一种共享的方式可以跨框架定义这些团队。每个实现都是分散的，锁定在你最初选择的工具上。我们构建了这个 schema 来解决这个问题。 该 schema 存放在 schema.openenvelope.org，并已在 SchemaStore 注册，因此如果你在 VS Code 中放入一个 .envelope.json 文件，你可以获得自动补全和验证，而无需安装任何东西。如果你想进行程序化验证，它也可以在 npm 上找到，命名为 @openenvelope/schema。 该规范涵盖：代理定义（角色、提示、模型、访问策略）、监督者/子代理层级、人机交互的门控、管道、调度以及在部署时注入的机密/变量。访问策略允许你明确声明每个代理可以调用哪些主机——运行时在网络层面强制执行这一点，而不是在提示中。 我们的目标是一个可移植的定义格式——只需定义一次团队，任何兼容的运行时都可以执行它。这类似于 Dockerfile 描述容器，而不依赖于特定的主机。openenvelope.org 提供了一个托管的运行时，但该 schema 是 Apache 2.0 许可，任何人都可以实现它。 欢迎对规范的任何部分提出问题——特别希望听到那些构建过多代理系统并对缺少的内容有意见的人的反馈。