最新

一个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

没有课程，只有船，即使它坏了。