最新

嗨，Hacker News！过去几个月，我和我的团队一直在开发 Tusk Drift，这是一个系统，可以记录您服务的真实 API 流量，然后将这些请求作为确定性测试进行重放。外发 I/O（数据库、HTTP 调用等）使用记录的数据自动进行模拟。<p>我们试图解决的问题：编写 API 测试很繁琐，而且手写的模拟会脱离实际情况。我们希望测试保持真实，因为它们来自真实的流量。<p>与模拟库的对比：像 VCR/Nock 这样的工具会在您的测试中拦截 HTTP。Tusk Drift 在外部记录完整的请求/响应跟踪（HTTP、数据库、Redis 等），并针对您正在运行的服务进行重放，无需编写或维护测试代码或 fixtures。<p>工作原理：<p>1. 添加一个轻量级的 SDK（我们目前支持 Python 和 Node.js）<p>2. 在任何环境中记录流量。<p>3. 运行 `tusk run`，CLI 会对您的服务进行沙盒处理，并通过 Unix socket 提供模拟。<p>我们在每次 PR 时都在 CI 中运行它。也将其用作 AI 编码代理的测试工具，它们可以进行更改，运行 `tusk run`，并获得即时反馈，而无需依赖实时依赖项。<p>源代码：<a href="https://github.com/Use-Tusk/tusk-drift-cli" rel="nofollow">https://github.com/Use-Tusk/tusk-drift-cli</a><p>演示：<a href="https://github.com/Use-Tusk/drift-node-demo" rel="nofollow">https://github.com/Use-Tusk/drift-node-demo</a><p>欢迎提问！

由于需要跨多个系统进行协调以及链式调用大型语言模型（LLM），如今许多智能体的使用体验都可能感觉非常缓慢。我很想知道大家是如何解决这个问题的： * 你们都是如何识别智能体中的性能瓶颈的？ * 哪些类型的更改为你们带来了最大的速度提升？ 就我们而言，我们编写了一个用于分析性能的工具，以便识别缓慢的 LLM 调用 - 有时我们可以为该步骤换用更快的模型，或者我们意识到可以通过消除不必要的上下文来减少输入 token 数量。对于需要外部访问的步骤（浏览器使用、API 调用），我们已经转移到快速启动的外部容器 + 线程池以实现并行化。我们还尝试了一些 UI 更改来掩盖一些延迟。 大家还在使用哪些其他的性能增强技术？

在旧金山最近一次地铁停运期间，我决定效仿“我需要带伞吗”的精神，开发一个Web应用程序，主要用来回答“我应该坐地铁还是公交车？”这个问题。 为了学习新工具，我决定尽可能多地使用代码生成工具。 首先，我让Claude Code编写了一个后台脚本，用于下载地铁实时线路图的图像，这些图像可以在这里公开获取： [http://sfmunicentral.com/](http://sfmunicentral.com/) 接下来，我让它用tkinter构建一个图像标注工具，结果在开始标注之前就需要进行大量的手动调整。这似乎是完成这项工作的正确工具，但如果我从头开始自己构建它，可能会节省时间。 最有趣的部分是使用pytorch将标注的图像数据转化为预测。Claude 很快就写出了初始脚本，但正如这些事情的发展规律一样，它需要手动调整，并且我对被标记为异常值的图像产生了自我怀疑。我承认，在意识到Claude没有启用pytorch的GPU支持之前，我已经走了很远的路；这真是一个令人尴尬的时刻。 对于那些好奇、勇敢或疯狂到想要深入研究的人，源代码已在此处以MIT许可证提供： [https://github.com/MrEricSir/munimet.ro](https://github.com/MrEricSir/munimet.ro)

背景：我管理一个电商网站。最近的机器人流量有所增加。大部分流量可以追溯到一两个 IP 地址，每天有数百次请求。这些 IP 地址没有反向 DNS 记录，当我在 Cloudflare 中映射这些请求时，一个地址显示来自美国各地不同的数据中心。这是怎么回事？ 源 IP 示例 173.245.58.0 芝加哥，美国 (ORD) 340 次请求 圣何塞，美国 (SJC) 330 次请求 洛杉矶，美国 (LAX) 310 次请求 亚特兰大，美国 (ATL) 310 次请求 达拉斯-沃斯堡，美国 (DFW) 290 次请求 纽瓦克，美国 (EWR) 280 次请求 华盛顿，美国 (IAD) 230 次请求 迈阿密，美国 (MIA) 210 次请求 波士顿，美国 (BOS) 140 次请求 新加坡，新加坡 (SIN) 130 次请求 感谢您的建议。

我们一直在构建可视化规则引擎（清晰的界面 + API 端点，帮助将输入数据映射到大量结果），最近我们产生了一个有趣的 idea，想看看将我们的决策表 UI 与 Claude 的 PreToolUse 钩子结合起来会发生什么。<p>结果是一个出乎意料有用的策略/门控层——这些表格让您的团队能够：<p>- 编写多因素、异常友好的策略（例如，当使用 --force 时，拒绝 rm -rf /；仅允许在 node_modules 中进行清理；对网络调用（如 curl/wget）进行询问；阻止 kubectl delete 或 SQL DROP，并给出明确的原因）<p>- 立即推出策略更改（运行期间，将有风险的操作从允许 → 询问；开发人员和代理的下一次尝试会立即被门控——无需 git pull、代理重启或协调）<p>- 采用轻量级的治理方案，该方案与代理在某种程度上无关，并且在人员变动中也能生存（MCP/技能/等）：只需在出现新工具和元数据时添加列/规则<p>- 获得一个快速的中心实用程序，以了解正在使用哪些工具、哪些工具被阻止的次数最多以及原因

将旧的 SCSI 硬盘连接到现代 Mac，而不是将固态硬盘装到旧的 Mac 里。