看起来 GitHub Actions 又出现故障了： https://www.githubstatus.com/
我们已经使用 Blacksmith 来避免使用 GitHub Runners。如果你还没有尝试过，强烈推荐。不过，我们仍然依赖 GitHub 来实际触发工作流。考虑到他们频繁的故障，我在想是否有其他可用的替代方案？迁移到 GitLab 是一个相当大的工程，因此我想知道是否有办法暂时缓解这个问题，而不依赖 GitHub Actions 定期触发工作流和在某些操作（例如合并到主分支时）上触发工作流？
返回首页
最新
我创建了Entropy是为了针对一个特定问题：传统的API扫描器常常因为依赖静态攻击列表而忽视业务逻辑缺陷。Entropy利用大语言模型（LLMs）分析您的API架构（OpenAPI/GraphQL），并像对手一样思考，以生成定制的攻击序列。注意：我目前正在修复一个小的打包问题，因此“pip install”在接下来的几个小时内可能暂时不可用。与此同时，您可以通过克隆代码库直接从源代码运行它。我非常期待听到您的想法和反馈！
嗨，HN，
我觉得将 traceroute 绘制在地图上，直观地展示数据包的传输路径会很有趣。我知道这个想法之前已经有人做过，但我还是想尝试一下。
最初的版本只是让你粘贴一个 traceroute，然后在地图上绘制跳数。后来我发现了 Globalping（[https://globalping.io](https://globalping.io)），它允许你从全球的探测器运行 traceroute 和 MTR，因此我将其整合到了这个工具中。
在使用过程中，我注意到了一些有趣的事情：
• 很容易发现不正确的 IP 地理定位。如果某个跳数显示延迟为 1-2 毫秒，但却看起来跨越了几个大陆，那么这个地理定位可能是错误的。
• 有时候，次优路由在视觉上比仅仅查看延迟数字更容易被注意到。
• 即使使用像 IPinfo 这样非常好的数据库，IP 地理定位仍然不是完美的，因此路径的某些部分有时可能会产生误导。
非常感谢 Globalping 和 IPinfo 背后的团队——Globalping 提供了测量基础设施，IPinfo 提供了地理定位数据。
欢迎反馈。
AI 编程代理可以生成不错的代码，但问题在于代码周围的一切——检查进度、捕捉偏差、判断是否真的完成。我花了几个月的时间尝试让自主代理正常工作，但瓶颈始终是我自己。
尝试 1 - Claude/GPT 直接使用：适用于小项目，但你需要不断重新解释上下文。
尝试 2 - Copilot/Cursor：自动补全效果很好，但仍然需要自己进行 95% 的思考。
尝试 3 - 持续代理：在没有提示的情况下持续工作，但“没有错误”并不意味着“功能正常”。
尝试 4 - 并行代理：时钟速度更快，但现在你需要手动审查更多的输出。
共同的问题是：没有人验证输出是否满足目标，而这个人一直是我。所以我自动化了这个工作。
OmoiOS 是一个基于规范驱动的编排系统。你描述一个功能，它会：
1. 运行一个多阶段的规范管道（探索 > 需求 > 设计 > 任务），使用 LLM 评估器对每个阶段进行评分。失败时重试，成功时推进。在代理编码之前，需求已经有了机器可检查的验收标准。
2. 为每个任务生成独立的云沙箱。你的本地环境不会受到影响。代理获得具有完整 git 访问权限的临时容器。
3. 持续验证——一个独立的验证代理会根据验收标准检查每个任务。失败会反馈以便重试。步骤之间没有人参与。
4. 发现新工作——当代理发现缺失的边缘案例时，验证可以生成新任务。随着代理的学习，任务图不断增长。
诚实地说，困难在于：
- 规范质量是瓶颈。模糊的规范会导致代理无所作为。
- 验证是领域特定的。API 的正确性较易验证，但 UI 质量则不然。
- 发现分支可能会意外地增加任务图的复杂性。
- 沙箱开销为每个任务增加了延迟。虽然值得，但这是一个权衡。
- 合并具有实际冲突的并行分支是最困难的问题。
- 监控（每个代理的轨迹分析）仍然存在一些粗糙之处。
技术栈：Python/FastAPI，PostgreSQL+pgvector，Redis（约 19 万行）。Next.js 15 + React Flow（约 8.3 万行 TS）。Claude Agent SDK + Daytona Cloud。自 2025 年 11 月以来进行了 686 次提交，独立构建。Apache 2.0。
我不断回到同一个问题：结构化规范生成，能够产生真正机器可检查的验收标准。是否有人找到适用于非平凡功能的有效方法，还是这根本就是一个困难的问题？
GitHub: [https://github.com/kivo360/OmoiOS](https://github.com/kivo360/OmoiOS)
在线演示: [https://omoios.dev](https://omoios.dev)
我花了过去几年的时间来构建 AgnosticUI。最初它是一个以 CSS 为主的单一代码库，逻辑在不同框架的包中手动重复。这导致了维护上的噩梦。
最近，我完成了对其的全面重写，采用了 Lit，以符合网络标准并统一核心。一个主要的架构转变是转向“源优先”模型。与其将 UI 源代码放在 node_modules 中的黑箱里，不如将其置于本地项目工作区中。
这使得组件对大型语言模型（LLMs）完全可见，从而避免了 AI 在尝试猜测隐藏库 API 时常见的幻觉。我在 Frontend Masters 上撰写了一篇技术事后分析，详细说明了这次迁移的挑战（包括 Shadow DOM 可访问性、表单参与以及 @lit/react 与 React 19 的对比）：<a href="https://frontendmasters.com/blog/post-mortem-rewriting-agnosticui-with-lit-web-components/" rel="nofollow">https://frontendmasters.com/blog/post-mortem-rewriting-agnos...</a>
智能代码阅读，适用于人类和人工智能代理。Tilth 是将 ripgrep、tree-sitter 和 cat 结合在一起的产物。
--<p>v0.4.4：为调用者搜索添加了自适应的二次影响分析——当一个函数的唯一调用者数量 ≤10 时，Tilth 会在一次扫描中自动追踪调用者的调用者。首次实现完整的 26 项 Opus 基准（之前仅有 5 项困难任务）。Haiku 的采用率从 42% 提升至 78%，使 Haiku 从成本回归转变为 -38% $/正确率。<p>v0.4.5：将 TOKEN_THRESHOLD 从 3500 提高到 6000 估计标记（约 24KB），因此中等大小的文件返回完整内容，而不是代理通过 5–7 次顺序 --section 调用读取的提纲。修复了两个主要回归问题：gin_radix_tree (+35% → ~持平) 和 rg_search_dispatch (+90% → -26% 胜率)。Sonnet 达到 100% 的准确率（52/52）和 -34% $/正确率。<p>--<p><a href="https://github.com/jahala/tilth/" rel="nofollow">https://github.com/jahala/tilth/</a><p>完整结果：<a href="https://github.com/jahala/tilth/blob/main/benchmark/README.m" rel="nofollow">https://github.com/jahala/tilth/blob/main/benchmark/README.m</a>...<p>-- 附言：我没有预算进行大量基准测试（尤其是 Opus），所以如果有任何有能力的标记大户可以运行一些基准测试，请随时提交结果。