返回首页
最新
嗨，HN！在过去几个月里，我的团队和我一直在开发 Tusk Drift，一个记录您服务的真实 API 流量的系统，然后将这些请求重放为确定性的测试。通过记录的数据，出站 I/O（数据库、HTTP 调用等）会自动模拟。
我们试图解决的问题是：编写 API 测试是一项繁琐的工作，而手动编写的模拟往往与现实脱节。我们希望测试能够保持真实，因为它们来自真实的流量。
与模拟库相比：像 VCR/Nock 这样的工具在测试中拦截 HTTP 请求。Tusk Drift 外部记录完整的请求/响应跟踪（HTTP、数据库、Redis 等），并将其重放到您正在运行的服务上，无需编写或维护测试代码或固定数据。
它的工作原理：
1. 添加一个轻量级的 SDK（我们目前支持 Python 和 Node.js）。
2. 在任何环境中记录流量。
3. 运行 `tusk run`，CLI 会将您的服务沙盒化，并通过 Unix 套接字提供模拟。
我们在每个 PR 的 CI 中运行这个工具。同时也将其用作 AI 编码代理的测试工具，它们可以进行更改，运行 `tusk run`，并在不需要实时依赖的情况下获得即时反馈。
源代码： [https://github.com/Use-Tusk/tusk-drift-cli](https://github.com/Use-Tusk/tusk-drift-cli)
演示： [https://github.com/Use-Tusk/drift-node-demo](https://github.com/Use-Tusk/drift-node-demo)
欢迎提问！
由于需要跨多个系统进行协调以及链式调用大型语言模型（LLM），目前许多代理的响应速度可能会显得非常缓慢。我很想知道其他人是如何解决这个问题的：
- 你们是如何识别代理中的性能瓶颈的？
- 哪些类型的改动为你们带来了最大的速度提升？
对我们来说，我们开发了一个分析工具来识别缓慢的LLM调用——有时我们可以在这个步骤中更换为更快的模型，或者意识到可以通过消除不必要的上下文来减少输入的令牌数量。对于需要外部访问（如浏览器使用、API调用）的步骤，我们已经转向使用快速启动的外部容器和线程池来实现并行处理。我们还尝试了一些用户界面的改动，以掩盖部分延迟。
还有哪些其他提升性能的技术是大家在使用的？
在最近一次旧金山地铁停运期间，我决定开发一个网络应用，灵感来自于“我需要带伞吗？”这个问题，基本上是为了回答“我应该乘坐地铁还是公交车？”<p>为了学习新工具，我决定尽可能多地使用代码编写。<p>首先，我让Claude Code编写了一个后台脚本，用于下载地铁实时电路图的图像，这些图像在这里是公开可用的：<a href="http://sfmunicentral.com/" rel="nofollow">http://sfmunicentral.com/</a><p>接下来，我让它在tkinter中构建一个图像标记工具，结果发现这个工具在我能够开始标记之前需要很多手动调整。虽然看起来是合适的工具，但如果我自己从零开始构建，可能会节省时间。<p>最有趣的部分是将标记后的图像数据转化为预测，使用了pytorch。Claude很快写出了初始脚本，但像这种事情一样，它需要手动调整，并且我对标记为异常值的图像进行了反复推测。我承认，在意识到Claude没有启用pytorch的GPU支持之前，我已经走得相当远；这真是让我感到尴尬的时刻。<p>对于那些好奇、勇敢或疯狂到愿意深入了解的人，源代码在这里以MIT许可证的形式提供：<a href="https://github.com/MrEricSir/munimet.ro" rel="nofollow">https://github.com/MrEricSir/munimet.ro</a>
背景：我管理一个电子商务网站。最近，机器人的流量增加了。大部分流量可以追溯到一两个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 端点，帮助将输入数据映射到大量结果）一段时间了。最近我们有一个有趣的想法，想看看当我们将决策表用户界面与 Claude 的 PreToolUse 钩子结合使用时会发生什么。
结果是一个出乎意料的有用的政策/门控层——这些表格让您的团队能够：
- 编写多因素、友好的例外政策（例如，当使用 --force 时拒绝 rm -rf /；仅允许在 node_modules 中进行清理；在网络调用（如 curl/wget）时询问；阻止 kubectl delete 或 SQL DROP，每个操作都有明确的理由）
- 立即推出政策变更（在运行中，将一个风险操作从允许 → 询问；下一个开发者和代理的尝试会立即受到限制——无需 git pull、代理重启或协调）
- 采用轻量级治理，具有一定的代理无关性并能适应人员变动（MCP/技能等）——只需在新工具和元数据出现时添加列/规则
- 快速获取中心实用工具，以了解哪些工具正在使用，哪些工具被阻止的频率最高，以及原因
意思是将旧的SCSI硬盘连接到现代Mac上，而不是将固态硬盘（SSD）安装到旧的Mac上。