一周热榜

GitCredit 是一个 GitHub 之外的 Git 贡献图。

我所看到的每一个智能体系统都存在同样的隐性成本：模型会反复阅读相同的上下文。 工单、Slack 消息、文档、客户历史记录、数据库笔记、操作手册、日志、过往决策。你可以缓存静态前缀，路由到更便宜的模型，或者设置团队预算，但这些都无法解决根本问题：智能体在开始大多数任务时都会试图重新探索一切。 我们构建 Parcle 作为 AI 智能体的共享记忆层。它会摄取操作上下文，索引已发生的事情，并允许智能体为下一步检索一小部分相关的记忆，而不是将所有内容粘贴回提示中——或者更糟的是，让智能体自行探索并消耗 token。 我们开始跟踪在有和没有我们记忆层的情况下，仅通过索引本地文件来完成任务时消耗的 token。在我们的部署/评估中，我们看到最大的 token 消耗减少高达 70%，任务完成速度大约提高 2 倍。中位数 token 消耗减少约 30%。最大的节省通常来自数据和上下文密集型工作流程；当智能体需要从多个位置和来源检索数据和上下文时。到目前为止，最好的应用场景是支持、运营、研究、销售和财务工作流程，在这些场景中，智能体否则会一遍又一遍地重新加载相同的账户/工作流程/历史上下文。 为什么我认为这现在很重要： Pylon 的 AI 成本帖子促使我们思考： 由于智能体不断寻找相同的上下文，公司付出了多少成本？这是一种记忆可以解决的隐性成本吗？ 我们构建 Parcle 是为了让智能体能够记住。令人惊讶的是，记忆不仅让智能体更有用。它还减少了消耗的 token。用于弄清楚事物位置的 token 更少，用于实际生产性工作的时间更多。 - Anthropic 表示，智能体消耗的 token 是聊天的 4 倍。我们认为这低估了。 - OpenAI 和 Anthropic 都拥有提示缓存，因为重复的提示上下文成本很高，但缓存主要在可重用内容足够稳定以命中缓存时才有效。但这并没有解决提示缓存会在 5-15 分钟不活动后失效的事实。 - “Lost in the Middle” 和 Chroma 的 “context rot” 工作都指向同一个问题：更多的上下文并不等于可用的记忆。 - 上下文工程领域似乎正在趋同于这一点：最困难的部分是决定模型在每个步骤应该看到什么。 Parcle 是我们尝试将此付诸实践的尝试：模型外部的记忆，仅在有用时才选择到上下文中。 我很想听听那些在生产环境中运行真实智能体的人的反馈： 1. 你的 token 实际花在了哪里：重复的输入上下文、工具跟踪、重试、输出、评估，还是其他方面？ 2. 提示缓存和模型路由是否足够了？ 3. 你需要什么才能信任智能体循环中的外部记忆层？