Weavable
Weavable 为AI智能体提供持久的工作上下文，连接企业工具数据，帮助企业开发者提升智能体推理准确性并降低Token消耗。
Maker 说
嘿 Product Hunt 👋 我是Abesh，That Works的联合创始人，今天我们正式发布Weavable。
问题所在
构建智能体工作流的团队手里握着大量工作上下文：决策、关系、管道数据和支持记录，但这些信息散落在他们使用的每一个工具里。要把这些上下文可靠地喂给智能体，难度远超想象。
大多数方案走的是两条歪路：
❌ 直接连接应用 - 原始API和MCP响应一股脑灌进模型，token成本飙升，智能体把上下文窗口全耗在搞清楚哪些信息有用上，而不是直接行动。
❌ 静态知识库或RAG - 上下文刚抓取就过时了。智能体基于上一个快照工作，自信满满地给出错误答案。
所以我们造了Weavable。
差异是可量化的：相比直接连接应用，token用量只有十分之一，在LLM-as-a-judge评估中输出被选中的概率高达85%。
Weavable有何不同 🔌
Weavable是AI智能体的上下文基础设施。它不把原始数据直接丢给模型，也不冻结快照，而是在你实际的工作工具之间维护一个持续更新的变更日志，让智能体推理所依赖的知识图谱始终保持映射、对齐和最新状态。
🔷 连接你的工具：一次OAuth流程覆盖HubSpot、Slack、Zendesk、Jira、GitHub、邮箱。限定范围访问，没有宽泛权限。
🔷 定义共享上下文：客户健康状况可能分布在HubSpot管道、Zendesk队列和Slack频道里。Weavable把这些整合成一个统一上下文，供你整个团队的智能体推理使用。没有每个智能体各自连接应用，没有重复授权，没有可见性盲区。
🔷 即插即用：一个MCP端点接入Claude、Cursor、n8n或你正在用的任何客户端。几分钟就能上线。
适合谁用？
如果你正在基于真实工作数据构建或运营智能体工作流，而且受够了静默失败、token爆炸和永远差一点就对的上下文——Weavable就是为你打造的。
🚀 今天就开始
免费试用30天，全部功能开放，无需绑定信用卡，访问weavable.ai
——Abesh & Varun
从我们构建Faindo的经验出发有个问题：我们连接了多个AI模型（ChatGPT、Perplexity、Gemini），一直遇到的一个挑战是，每个模型对相同上下文的解读方式不同，取决于它们的训练方式。Weavable会在上下文到达MCP端点之前做归一化处理，还是保持模型无关，让智能体自己处理解读？
恭喜发布，会持续关注进展。
我们构建这一切背后的核心信念是：工作不只是文档或记录。它是活动。是人和智能体随时间推移所做的事情。一笔续约泡汤，是因为CRM、支持和Slack里出现了三个信号，但没人把它们联系起来。一笔交易成交，是因为一个线程里的对话，而不是某个字段。
记录只是残留物。工作才是真正流动的东西。
大多数AI上下文工具要么把这一切压扁成一张快照，要么拼凑一堆MCP对平面记录做无休止的调用，污染上下文窗口，还搞不清什么变了、为什么变。我们认为这两种做法都错了。
所以我们用确定性引擎构建了Weavable，追踪信息如何变化，构建每次有意义更新的变更日志，再编织成活动图谱。你的智能体通过MCP端点查询的就是这个图谱。不是摘要，不是向量块。而是一幅结构化、有时间感知的、关于实际正在发生的事情的图景。而且因为你的智能体可以只查询它需要的特定信号，它不需要吞下整个工作空间来找到它们。上下文窗口更小，成本更低，答案更精准。
很希望听听其他尝试过不同解法的人的想法。我们认为活动图谱这条路是对的，但我们现在还处于早期，如果错了，我们愿意公开承认。
我们发现直接连接数据源不仅慢，而且token消耗大，Claude得先拉取一些数据，构建上下文，再拉取更多数据，然后从中判断还需要什么，这个过程会持续很久，尤其当部分数据通过MCP连接时。Weavable在这方面也有帮助吗？
好奇问一下：你们具体是怎么把 token 用量降低 90% 的？
关于智能体系统，我一直在想的一个问题是上下文治理。
大多数团队在数据、客户对话、董事会讨论、HR 问题、商业条款等方面，敏感度差异巨大。Weavable 如何处理权限和上下文边界，让智能体只基于特定用户或团队实际能看到的信息进行推理？