2 分•作者: stevesolun•6 天前
您好 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