我们开源了Claude Tag的替代方案，让普通用户和Codex玩家也能免费拥有自己的“AI同事”。
核心内容：
1. 开源项目MFS与Claude Tag的相似理念
2. 基于MFS快速复刻开源版Claude Tag（Open Tag）的演示
3. Open Tag的安装配置与多数据源接入能力

前两天，Anthropic 发布了 Claude Tag，可以把 Claude 变成你 Slack 里的常驻同事，不仅能以同事身份参与团队协作，支持多人共享同一会话线程，最重要的是，它还具备主动持续学习团队上下文的能力。也就是说，你可以在Slack频道里直接@Claude，然后它就会根据当前上下文的情况去执行工作中的操作，就像一个真实的同事一样。但是它的门槛不低：仅限Claude CodeEnterprise 和 Team 客户使用，个人用户没份，codex玩家更是只能干巴看着。但巧了不是，我们内部研发了快半年的项目MFS，和 Claude Tag想到一块去了。项目地址：https://github.com/zilliztech/mfs并且，基于我们的MFS项目，任何人都可以很快地复刻一个开源版本的Claude Tag，并做到普通Claude用户和Codex用户，都能免费使用。以下为我们基于MFS，两天天手搓的 zilliz 版本开源Claude Tag，我们管它叫Open Tag。它的使用体验和Claude Tag非常相似。Open Tag 示例：

https://github.com/zilliztech/mfs/tree/main/examples/open-tag-skill

举个例子，你可以在你的Slack频道里@OpenClaude，(用 Codex 就是 @OpenCodex)。然后扔给它你的需求，它就能先读懂当前线程在聊什么，再结合你授权给它的上下文（代码、文档、工单、聊天记录、数据库里的行），直接输出结果，最终把结果直接贴回 Slack。

01 

Zilliz 版Open Tag效果展示

话不多说，先看Open Tag的效果和安装使用教程，这里有几个简单的录屏。

第一步，自动化配置与安装

通过调用 open-tag-admin Skill，Agent 会引导你完成 Open Tag 的本地安装与环境配置：

第二步，真实工作流 review

配置好后，我建了OpenClaude这个Slackbot。然后我把它邀请进 Slack 频道后，直接 @OpenClaude，输入具体指令。例如，在研发场景中，我让其 Review 我的开源项目 memsearch 的最新 PR 和 Issue 并给出专业意见。可以看到它工作3分钟之后，就给出来了详细的回复和建议，我甚至可以继续让它进行PR合并之类的操作。这边只是演示一个接入GitHub的例子。除此之外，我们可以在设置的时候接入各种数据源，让它有更多的数据接入和控制能力。想看它具体怎么装、怎么跑，点击开源链接即可：
https://github.com/zilliztech/mfs/tree/main/examples/open-tag-skill_{注：由于目前展示的是在本地运行的 Demo，我们暂未对该示例实现严格的沙箱隔离与权限管理机制。在生产环境中部署前，建议务必理解其底层原理与安全边界。}

02

 解构 Claude Tag：构成三要素与核心瓶颈

看完了效果，我们来看看Claude Tag以及Open Tag，是怎么运行的。Claude Tag 说白了，就是把一个 agent 拆成三块拼起来：大脑负责策略、memory 负责记忆，tools 负责执行。一个大脑负责想，一份记忆让它记得住事，一双手脚让它够得到外面的工具和数据。

• 大脑：负责长期意图理解与策略规划，接入 Claude、Codex即可。
• memory ：负责持久化跟踪频道内的上下文，避免在每次交互时进行从零开始的 Prompt 灌输。
• tools +数据：触达外部系统的工具和数据源，完成具体的执行操作。

总结来说ClaudeTag = Brain (大脑)+ Memory (记忆) + Tools (工具/数据接口)对于 Open Tag 而言，还原大脑并不难，挂载 Claude Code 或 Codex exec 即可；还原 Slack 的消息外壳也不难，只需通过监听 app_mention 事件，读取线程上下文并实现收发适配器，几百行代码就能搞定。真正难点是另外两块，记忆和tools 。即如何让 Agent 能够实时跨越十几个相互孤立的系统，精准、低成本地检索并引用上下文。而Open Tag，我们可以理解它只是一个收发消息的轻量级适配器。其背后真正提供跨源数据对齐与上下文召回能力的，是我们的核心开源底座项目：MFS。

MFS 项目地址：https://github.com/zilliztech/mfs

03 

MFS 的技术实现

为了让 Agent 能够像人类工程师一样理解复杂的企业数据，MFS 在工程上做了两项重构：

1、统一的URI操作界面

目前业界的共识是，Agent 最天然、信息密度最高的交互接口是 CLI（命令行界面）。既然 Agent 天生对 Shell 命令有极高的泛化执行能力，MFS 索性将所有异构数据源，在底层全部抽象为统一的虚拟树结构。

• 一个 Postgres 表，被抽象为一棵可以 ls 进去的树，每一行记录就是一个可以 cat 的 JSON 对象。
• 一个 PDF、一个 S3 桶、一个 GitHub 仓库连同它的 issue，也全是树，甚至一个 Slack 聊天线程，都能映射为具备稳定 URI 的标准节点。

Agent 只需要使用一组标准的原子命令（tree、ls、cat、search、grep），就能以极低的 Token 成本遍历所有异构空间：（tree 摊开一个源的结构，ls 看某一层有什么，cat 把一个对象读出来。要快速定位，还有 search 做语义搜索、grep 做精确匹配。）

mfs tree github://acme/backend -L 1      # 摊开一个仓库的结构├── src/├── tests/└── README.mdmfs ls postgres://prod/public            # 看数据库里有哪些表tickets/   users/mfs cat jira://acme/PLAT/issues.jsonl --locator '{"id":"PLAT-491"}'# 把那条工单的原文读出来

在 CLI 之上，MFS 还将这些原子能力打包成了两个面向 Agent 的标准Skill：

• mfs-ingest：负责数据源的注册、配置生成、增量同步与索引构建，必要时排查为什么没有 ingest 成功
• mfs-find：负责跨源的搜索和浏览，在已经接入的源里 search / grep，再用 tree / ls / cat 一路定位到原文证据。

安装它们只需要一条命令。跑完以后，mfs-ingest 和 mfs-find 这两个 Skill 会自动装上；不管你用的是 Claude Code 还是 Codex，所有支持 Skill 的 agent 都能用：

npx skills add zilliztech/mfs --all -g

装完，打开你的 agent，连命令都不用记，直接用大白话说就行：

> 把我这个仓库 ingest 了，再帮我找找 webhook 重试的逻辑在哪

剩下的它自己会调对应的 mfs 命令搞定。

2、双轨制检索：搜索与浏览的两条腿走路

在 Agent 获取上下文的路径上，行业长期存在两大流派的争论：搜索派（RAG/索引）：强调先建向量索引，再做语义检索。传统 RAG、大型知识库，或者 Cursor 是其中代表浏览派（progressive disclosure）：代表性玩家是 Anthropic ，不一次性暴露所有数据，让 Agent 顺着 Skill 线索一层层渐进式披露，需要哪块看哪块。Skill 的按需发现机制也是这个路子。很多人把这两派看成二选一，但我们回想一下人类寻找信息的真实链路：搜索信息，我们会先通过 Google 搜索获取高召回的候选列表（搜索），再点击进入具体网页顺着目录精读（浏览）去图书馆找书也一样。你不会从头到尾一本一本翻，你会 1)先查索引、顺着它定位到某一排书架。 2)然后你走过去，抽出那本，翻到具体那一页。这两个例子都有一个很明显的特征，需要我们把搜索与浏览紧密结合。其中，搜索负责把范围缩小，浏览负责提供更精确的信息。MFS 的设计也是同理。先用 search、grep 在大范围里快速框出候选，再 tree、ls、cat 顺下去把它核实。一边提召回省 token，一边提精度保准确，这在 agent 的上下文定位和记忆召回里特别好使。在测试中，我们拿两千个文件的复杂代码库做了测试，纯原生 Shell 的 Agent 检索平均消耗962 tokens（命中率 22/24）；而采用 MFS 的“搜索+浏览”双轨制方案后，Token 消耗骤会降至460 tokens，同时命中率提升至 23/24。相关记录和详细结果都在代码仓库的报告里。

04 

异构数据源的统一与架构弹性

1、全源检索的实际价值

mfs的一大优势是，能通过一个 --all，检索你注册进来的全部源，代码、数据库、文档、网页、工单等等，并返回相同格式。比如我们同事想搞清楚，在 zilliz 内部，手头到底已经有哪些跟混合检索相关的研发资料，又散在哪儿了。只需要：

mfs search "我们现在到底已经有哪些跟混合检索相关的东西？" --all

postgres://prod/public/engineering_tickets/rows.jsonl   score=0.88   #482 hybrid retrieval flaky on long queries — dense recall drops near ...notion://workspace/design/retrieval-rfc.md              score=0.85   Hybrid search: combine dense + sparse, fuse with weighted RRF ...web://milvus-tutorials/hybrid-search                    score=0.81   Hybrid search runs an ANN search and a BM25 search, then reranks ...file://local/repo/src/milvus.py                         score=0.76   423  def hybrid_search(self, query: str, top_k: int = 10):github://your-org/bootcamp/notebooks                    score=0.69   bootcamp/hybrid_search.ipynb — end-to-end hybrid retrieval walkthrough

可以看到，一条命令，把工单里的反馈、设计文档里的方案、官方教程、你自己代码库里的实现、github 上的示例，本来散在五个毫不相干的系统里的内容，全都排在同一个结果列表里。在 agent 里它还会更进一步，把这几个源的命中综合成一段回答，最后做进一步分析。这个例子已经录制成以下的 GIF:目前 MFS 已经原生支持了 20 多种主流的数据源：过去这些业务含义不一样，连物理形态也不一样的数据源，很难直接用于搜索，但MFS 可以屏蔽了底层的物理形态差异，（通过文档转文本，图片转描述，表格行和消息线程整理成结构）让它们始终是同一套树、用同一套命令操作，直接服务于 agent的搜索、读取与引用。另外，MFS 还在底座层内置处理了增量同步、认证鉴权、文档切块（Chunking）、Embedding 复用、索引和元数据一致性、缓存、删改清理、任务中断恢复的系统级工程。值得一提的是增量同步，过去数据库看 updated_at，聊天靠消息游标，文件夹比内容哈希，发现变化的方式各不相同，但现在MFS 框架可以替你判断怎么同步，最后统一汇报成新增、改动、删除。这里先不展开这些繁琐细节，后面我会单开一篇讲它背后的工程设计。_{如果你想贡献新的 Connector，也不用重写一整条检索管线。框架已经把共性抽成了接口和父类，你只要把这个源里有什么、怎么读、怎么发现变化讲清楚，后面的转换、同步、embedding、索引、缓存和搜索，都由 MFS 接着往下走。}

2、架构的弹性：从本地单机到企业级生产

架构上，MFS 采用彻底的 Client/Server 分离架构，向量库、元数据库、缓存这些后端部件全部解耦，支持无缝的平滑扩容。从而让它既可以很快在本地跑起来，也可以快速 scale 到生产环境。具体来说

• 开发者本地快速 demo：后端默认进入 本地的轻量化模式。向量数据库采用 Milvus Lite，元数据采用 SQLite，Embedding 默认调用本地约 600MB 的 ONNX 模型。无需任何云端 API Key 和GPU，单机一分钟拉起。
• 企业级生产部署：当数据量与并发请求激增时，可将后端组件解耦替换。向量库无缝指向 Zilliz Cloud（高性能分布式托管），元数据切换至分布式 PostgreSQL，Server 端打包为标准容器镜像，通过 Kubernetes 进行弹性编排。

使用过程中，用户不用先纠结自己要本地还是生产。这些判断都写进 Skill 里了。只要把需求说清楚，顺手给个 server 地址（如果有的话），agent 就能接着往下走：想连什么数据源、怎么连、凭证怎么配，它都会一步步教你；想快速本地试玩，它带你跑通 quick start；想自己部署，它引导你搭起来。一句话起步，剩下的它接管。举例：1.  用 mfs-ingest 帮我把这个本地仓库先加进去，我只想最快跑通一个 demo。2.  帮我把 Slack 和 Jira 都接上，token 应该放在哪、哪些字段不能明文写，你一步步带我来。3.  我想按生产方式部署 MFS，向量库用 Zilliz Cloud，元数据用 Postgres，server 准备用 Docker Compose 跑。4.  帮我看看现在有哪些 connector 已经接好了，再用 mfs-find 搜一下有没有关于 webhook retry 的背景信息。

05 

基于MFS 创建自己的“Open Tag”

到这儿你可能觉得，MFS 就是个给自己用的搜索工具。不止。它同时是一个底座。Open Tag只是构建在 MFS 之上的一个轻量级示范性应用，你完全可以基于 MFS 提供出来的 CLI 和 SDK，构建自己上层的 Agent 应用/plugin/MCP/Skill。

写在最后

过去几年，随着大模型在推理能力跨过临界值，业界的关注点开始聚焦于 Agent Harness、持久化 Memory 以及Skill管理。而这些层出不穷的新概念，本质上都是在解决同一个问题：让模型真正、稳定地融入人类的生产流。这也是我们推出Vector Lakebase架构所秉承的初心——语义数据不应长成实时检索、交互探索、批量分析一个个互不相通的知识孤岛，而应当沉淀在一个统一的 Lake-native 基础设施上。MFS 则是这层基础设施面向 Agent 演进的产物。让 Agent 能够安全、高效、廉价地触达和组织真实世界里的上下文，让它搜索、能渐进式浏览，还能自主处理结构、更新和变化，让 agent 在需要时自己发现、核实、组织线索，减少对人工投喂的依赖，从而让Agent真正从工具进化为一个懂你、懂业务、有上下文的工作搭档。也欢迎大家体验、提 issue、加 connector：项目地址：https://github.com/zilliztech/mfsOpen Tag示例：https://github.com/zilliztech/mfs/tree/main/examples/open-tag-skill文档：https://zilliztech.github.io/mfs/Discord：https://discord.com/invite/FG6hMJStWu

作者介绍
张晨
Zilliz Algorithm Engineer

阅读推荐如何通过修改Segment 形态，让你的 Milvus 性能原地翻倍Agent时代，静态容量规划注定失败！聊聊 Zilliz Cloud 的AutoScale设计
官宣：Zilliz Vector Lakebase正式发布，作为向量数据库开创者，我们为何推出Vector Lakebase

观点|从Vector Database到Vector Lakebase，如何定义AI data infra的下一个十年为什么每个重复建设AI 数据pipeline的企业，都需要一个Vector Lakebase