返回首页
最新
3.27.0 的 RC1 版本压缩包现已发布，下载地址为：
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2
（md5 校验和 = bd95111c1a9f81f136c5e4e2c62b493e）
（sha1 校验和 = 0eefb3a7d86a3bd0154480db3d2173bb8bd6d7c1）
https://sourceware.org/pub/valgrind/valgrind-3.27.0.RC1.tar.bz2.asc
公钥可以在以下地址找到：https://www.klomp.org/mark/gnupg-pub.txt
请在对您重要的配置中尝试使用，并报告您遇到的任何问题，可以在开发者/用户邮件列表中反馈，或者（更好）通过我们的错误跟踪系统提交，地址为：https://bugs.kde.org/enter_bug.cgi?product=valgrind
预计 RC2 将于 4 月 17 日（星期五）发布。
最终的 3.27.0 版本计划于 4 月 20 日（星期一）发布。
我们运营着 Superglue，一个开源的代理集成平台。上周，我与另一家 YC 初创公司的创始人进行了交谈。她发现了一个我们尚未正式推出的 CLI 的用例。
她面临的问题是：客户希望能够在她的应用程序中的聊天界面内创建 Salesforce 的机会（Opps）。
我们不断看到这样的模式：团队构建代理，而他们的用户能够准确描述他们的需求：“在 X 条件为真时，从 Salesforce 中提取这三个对象并推送到 nCino”，但将其转化为代理可以调用的通用硬编码工具是一项繁重的工作，并且由于每个用户的逻辑不同，这种方法并不具备可扩展性。
Superglue CLI 的功能是：你可以将其指向任何 API，代理便可以在运行时对该 API 进行推理。无需预构建的工具。代理读取规范，规划调用，并执行它们。
在生产中使用这一功能的创始人这样描述：她将 CLI 交给她的代理，并提供了一组指令，告诉它不要构建工具，只需针对 API 运行。它正确处理了多步骤的 Salesforce 对象创建，包括每个用户的字段逻辑和记录类型模板。
具体来说：与其编写一个处理联系人 -> 账户 -> 机会创建的 createSalesforceOpp 工具，并包含所有条件逻辑，不如编写一个技能文档，让代理自行决定要访问哪些端点以及访问的顺序。
权衡在于：你赋予代理更大的自主权来决定进行哪些 API 调用。这需要良好的指令和一些保护措施。但对于长尾的、用户特定的连接器，这比为每种情况构建工具要实用得多。
乐意讨论。想知道其他人是否在基于 MCP 的连接器中遇到过“预定义工具”的瓶颈，以及你们是如何解决的。
文档： [https://docs.superglue.cloud/getting-started/cli-skills](https://docs.superglue.cloud/getting-started/cli-skills)
代码库： [https://github.com/superglue-ai/superglue](https://github.com/superglue-ai/superglue)
Doors：一个基于服务器驱动的用户界面框架和运行时，用于在Go语言中构建有状态的反应式Web应用程序。
一些亮点：
* 在服务器端的Go中具备前端框架能力。反应式状态原语、动态路由、可组合组件。
* 没有公共API层。不需要设计端点，私有的时间传输在后台处理。
* 统一的控制流。后端与前端之间没有上下文切换。
* 集成的Web堆栈。打包资产、构建脚本、提供私有文件、自动化CSP，并以一个二进制文件发布。
工作原理：
Go服务器是用户界面运行时：Web应用程序在有状态的服务器上运行，而浏览器则充当远程渲染器和输入层。
安全模型：
每个用户只能与您渲染给他们的内容进行交互。这意味着您在渲染按钮时检查权限，这足以确保相关操作不会被其他人触发。
思维模型：
将DOM链接到其依赖的数据。
限制：
* 对于静态非交互式网站、具有简单路由的客户端优先应用程序，以及不适合离线PWA的情况没有意义。
* 在不干扰用户的情况下进行负载均衡和发布需要不同的策略，涉及有状态服务器（简化机制已包含）。
最佳适用场景：
用户流量较大且业务逻辑复杂的应用程序。单一执行上下文和无API/端点权限管理负担使得开发更为简单。
特点：
* 特意构建的[Go语言扩展](https://github.com/doors-dev/gox)，具有自己的LSP、解析器和编辑器插件。将HTML作为Go表达式和`elem`原语添加。
* 自定义并发引擎，支持非阻塞事件处理、并行渲染和树感知状态传播。
* 准备好支持HTTP/3的同步协议（滚动请求 + 流式传输，事件通过常规POST，无WebSockets/SSE）。
来自作者（我）的说明：
我花了1年9个月才达到这个阶段。我重写了框架6到7次，直到每个部分都连贯，每个决策都感觉正确或是合理的妥协。我对自己的工作非常挑剔，看到了一些缺陷，但总体来说，结果还是很扎实的，作为用户我喜欢开发者体验。思维模型需要一些前期思考，但通过明确的代码和可预测的结果会得到回报。
代码示例：
```go
type Search struct {
input doors.Source[string] // 反应式状态
}
elem (s Search) Main() {
<input
(doors.AInput{
On: func(ctx context.Context, r doors.RequestInput) bool {
s.input.Update(ctx, r.Event().Value) // 反应式状态
return false
},
})
type="text"
placeholder="search">
//~ 订阅结果到状态变化
~(doors.Sub(s.input, s.results))
}
elem (s Search) results(input string) {
~(for _, user := range Users.Search(input) {
<card>
~(user.Name)
</card>
})
}
```