最新

在与团队成员讨论或面试时，不得不手动绘制系统设计图让我感到沮丧。于是我想到：“如果有人在我滔滔不绝地思考时，替我画出图来，那该多好？” 这就是 VoiceDraw 的由来。你可以一边思考，或者和朋友/面试官讨论你的系统架构，图表就会随着你的思路、提出的疑问以及权衡的利弊自动绘制出来，并清晰地呈现在旁边。 演示视频：https://youtu.be/36PgHKSuccE

各位 HN 的朋友们： 我们是 MyDecisive.ai 的团队，今天我们向开发者们展示 Octant——为您的 OpenTelemetry 提供点按式控制和可见性。 您可能已经体会到了“可观测性税”的痛苦，尤其是在管理 K8S 集群时。目前行业标准是使用 OpenTelemetry 对一切进行检测，但将所有丰富的 OTLP 日志、指标和追踪直接传输到 SaaS 供应商（Datadog、Splunk、Honeycomb）会迅速变得昂贵。您最终会为嘈杂、低价值的数据支付巨额的摄取和存储成本，只是为了在出现问题时能够搜索到它们。有了 Octant，您可以在几分钟内完成 OTel 的部署。 我们构建 Octant 的目的是颠覆这种模式。Octant 不会盲目地将所有遥测数据发送到集群外，而是配置并帮助管理 OTEL 集群。它为您提供了一个可视化界面来管理 K8s 对象，更重要的是，它充当一个 OTLP 网关，在数据离开您的 VPC 之前就在源头进行过滤。 由于它原生支持 OpenTelemetry，您可以直接指向现有的 OTel SDK 或收集器，而无需修改应用程序代码。以下是它在后台的工作原理： - **OTel 原生追踪和日志采样：** 它能够轻松地摄取 OTLP 流量，并在传输过程中检查日志和追踪。通过等待追踪的完整上下文，然后决定保留哪些数据，它实现了将可操作信号（如错误和高延迟跨度）100% 保留，同时在数据进入您的 SaaS 账单之前丢弃无用信息。 - **实时状态告警：** Octant 可以处理遥测流，而无需等待数据被批处理、传输并由外部提供商索引后触发告警。这缩短了检测时间，并从根本上减少了对 SaaS 供应商的依赖。 - **传输中的 PII（个人身份信息）脱敏：** 它可以实时检测并从您的日志和追踪中移除敏感信息，然后再将其传输到互联网上，从而消除了“事后摄取”的清理成本和合规风险。 - **K8s 上下文注入：** 由于它与您的集群深度集成，它可以在统一的 UI 中将您的 OTel 流直接映射到您的 K8s 资源（Deployments、Pods、CRDs）。 API 使用 Go 编写（[github.com/mydecisive/octant]），整个堆栈可以通过我们的 Helm charts 直接部署到您的集群中。 我们非常希望您能在开发集群上部署并进行测试。我们最近刚刚合并了来自我们第一位社区贡献者的 PR，这对我们来说是一个巨大的里程碑！我们希望保持这种势头。如果您对 K8s 可观测性与自主性、OpenTelemetry 流水线或 Go/React 感兴趣，我们已经标记了一些“适合初学者的问题”，并非常乐意欢迎您加入该项目。 GitHub：<a href="https://github.com/MyDecisive/octant" rel="nofollow">https://github.com/MyDecisive/octant</a> 网站：<a href="https://www.mydecisive.ai/" rel="nofollow">https://www.mydecisive.ai/</a> 我今天会一直关注此帖，很乐意回答任何问题或深入探讨架构！

一个Azure DevOps的TUI（文本用户界面）工具，提供管理指标，用于跟踪停滞项、团队成员过多的在制品（WIP）以及跨Sprint的进度。

您好 HN！ Token 成本已成为我们共同关注的热点问题。我尝试过一些（非常棒的）工具，例如 rtk、caveman 和最近（虽然搞笑但有效）的 ponytail。它们通常的做法是在线 token 缩减，例如尽可能压缩请求/响应。 但随后我想到（我相信其他人也有类似的想法）——就像我们有路由器来选择合适的模型一样，为什么不能有一个工具，根据仓库/上下文来缩小可用工具、技能和 MCP 的范围呢？ 人们通常会积累技能、代理、MCP 服务器、harnesses、提示词、仓库说明和本地脚本。我并不是说我们都是囤积者，但我们确实有点像。你最近一次删除技能是什么时候？一段时间后，模型会有太多选项可供选择。 ctx 试图在会话变得臃肿之前选择上下文来解决这个问题。所以，它不会清理你杂乱的车库，但它会给你一副魔法眼镜，让你只专注于你需要的工具。 它是如何做到的？它通过观察仓库和任务，遍历可用工具的图谱，并推荐一小部分得分最高的技能、代理、MCP 服务器和 harnesses 组合。 它是如何知道的？为了确保结果不被幻觉化且可重复，我精心整理了一个包含 91k+ 技能、467 个代理、10.7k 个 MCP 服务器、207 个 harnesses 的列表，并构建了一个图谱来帮助 ctx 做出推荐决策。虽然我当然是利用 AI 来生成它，但我对其进行了精心策划和修订，以确保数据是最新的。 那么，这与 rtk、caveman、ponytail 和类似的 token 节省工具有什么不同呢？ 如上所述，这些工具大多是在某个东西已经被使用后才进行 token 缩减。 * rtk 压缩命令输出。 * caveman 风格的工具让助手用更少的词语来回应。 * ponytail，嗯，非常棒，但它更侧重于减少代码（YAGNI）。 ctx 是上游的。它试图完全避免将不相关的技能、代理、MCP 和 harnesses 加载到上下文中。 所以它并不是真正的替代品。它应该与它们协同工作！ 使用 ctx 选择正确的工具。 使用 rtk 减少终端输出的噪音。 如果你想要更短的响应，可以使用 terse-output 工具。 目标很简单：在不迫使用户手动测试和比较数千种可能的技能、代理、MCP 服务器和 harnesses 的情况下节省 token。 仓库：https://github.com/stevesolun/ctx