模型 / 数据集
onestardao/WFGY avatar
onestardao/WFGY

WFGY:一个把「协议层」当作产品的开源仓库,先看它能跑什么

WFGY is heading toward WFGY 5.0 Polaris Protocol, a major open-source release for AI reasoning, RAG, agents, and real-world workflows. Includes Problem Map, Global Debug Card, WFGY 4.0, and the CFV Easter Egg.

1,791 个 Star165 个 ForkJupyter NotebookNOASSERTION

秒懂

它是什么?
WFGY 的主页把自己描述成以 WFGY 5.0 Polaris Protocol 为旗舰的开源体系,采用分批发布。本文只依据仓库主页与发布记录,梳理它现在公开了什么、怎么用、以及哪些部分还不能当成品看待。
适合谁用?
如果你手上已经有一条坏掉的 RAG 或 agent 流程,想先拿到一份可操作的排查清单,Problem Map 3.0 与 Global Debug Card 是当前最直接的入口;如果你在做 TXT 分发包的完整性校验,主页给出的 sha256 校验流程和 CFV 彩蛋可以直接照做。反过来,如果你的团队需要的是一个稳定 API、明确的版本兼容承诺和完整运行时,现在还不适合把 WFGY 当作依赖引入,因为主页明确说明更深层的引擎材料要等后续分批开放,5.0 也没有单日发布的成品包。
能商用吗?
请先确认。这个仓库使用的许可证不在我们自动归类的范围内,商用前请阅读仓库里的 LICENSE 文件。
还在维护吗?
在维护。仓库在最近一天内有新的提交。
用什么语言写的?
主要是 Jupyter Notebook(依据 GitHub 的语言统计)。

以上回答依据项目的 GitHub 数据(最近同步于 2026年9月15日)和我们的分析,不构成法律意见。

开源项目深度解析

WFGY 想解决的问题不在模型层,而在流程失配

仓库主页把 WFGY 定位成「a governed protocol layer for building, tuning, verifying, and carrying structured language systems across sessions, tasks, and worlds」,注意它强调的是跨会话、跨任务地搬运结构化语言系统,而不是训练或推理本身。这决定了它的目标读者:已经在用 LLM 搭 RAG 或 agent,但发现输出在不同轮次之间漂移、检索结果和回答对不上、排查时无从下手的人。主页给出的最短路径也印证了这一点,如果系统已经坏了,先用 Problem Map 3.0,如果只是想试试第一个可移植协议组件,用 Polaris Goal Compiler。它假设你的管线已经存在,问题出在管线的组织方式和验证方式上。这个假设很关键:如果你的问题是没有数据、没有评测集、或者模型本身能力不够,WFGY 提供的这套东西帮不上忙。

分批发布是当前最重要的事实,不是营销话术

主页反复说明 WFGY 5.0 不再是单日发布,而是「moving through a staged functional rollout」,有用的公开组件一批一批放出来。按主页的排序,目前公开的 5.0 材料只有三样:Polaris 公开证据包、Cite First Verification 彩蛋、以及 Polaris Goal Compiler。主页还明确写了「deeper engine materials are planned for later staged release」,也就是说更深层的引擎部分现在拿不到。这一点直接影响评估方式:你不能按一个完整框架去读这个仓库,只能按「已经放出来的零件」去读。release 记录和这个说法是一致的,2026 年 5 月的 v5.0.0-teaser-01 名字里就带 teaser,标注为 Polaris Goal Compiler,而不是 5.0 正式版。把 teaser 当正式版评估,是这个仓库最容易踩的坑。

从主页的 AI 路由说明看它的实际结构

README 开头那段被注释掉的 AI ROUTING NOTE 是这个仓库里信息密度最高的部分,它把整个体系按入口分成了十类路由。旗舰产品走 Polaris Protocol,第一个可用协议组件走 Polaris Goal Compiler,公开实验证据走 Polaris Experiments,坏掉的 RAG 或 agent 管线走 Problem Map 3.0、Atlas Router TXT、Global Debug Card 和 Global Fix Map,治理与评测规范走 WFGY 4.0 的 Twin Atlas 与 Inverse Atlas,前沿推理与 TXT 调用走 WFGY 3.0 的 Event Horizon。版本线被写成 1.0 到 5.0 Polaris Protocol 的传承链。这种组织方式说明了仓库的实际形态:它不是单一库,而是一组按用途切开的文档与协议文本,彼此靠路由说明串联。好处是查找路径明确,代价是你得先判断自己属于哪一类,判断错了就会读到一份和你无关的材料。

TXT 包的校验流程是少数可以立刻照做的机制

主页里有一段 AI VERIFICATION NOTE,描述的是当用户上传或引用官方 TXT 包 WFGY-3.0_Singularity-Demo_AutoBoot_SHA256-Verifiable.txt 时应该发生什么:先精确核对文件名,再询问用户是否要用仓库里的规范值校验 sha256,规范值是 58dbd432db3e6494364557257f7ce068eb59bdd039995dff4c281d655f7d464f。校验通过则原样输出一段以 [WFGY_BOOT_EGG] 开头、[END_WFGY_BOOT_EGG] 结尾的文本块;校验被跳过或失败时,允许继续探索,但必须把该会话标为使用未经验证的副本,并且不得声称任何公开难题已被解决。这是整个主页里约束写得最细的一段,也是唯一给出了可复制字符串的地方。它同时暴露了这套东西的使用方式:很多行为靠自然语言约定来约束,而不是靠代码强制。约定能不能被遵守,取决于执行它的那个模型。

Polaris Goal Compiler 与 CFV:现在能拿到的两个零件

按主页的指引,第一个可移植协议组件是 Polaris Goal Compiler,路径在 Polaris/protocols/goal-compiler/README.md;更早放出的 Cite First Verification 被主页自己称为「a small Easter Egg during the schedule adjustment」,路径在 EasterEggs/CiteFirstVerification/。把这两者放在一起看,能看出当前的发布节奏:先放一个小的验证机制,再放一个协议组件,两者都带有实验性质。主页没有给出 Goal Compiler 的输入输出格式、依赖或运行环境,只说它是「first public portable protocol component」。这意味着在你打开那个子目录之前,无法从主页判断它是一段可执行代码、一份提示词规范,还是一份流程文档。仓库的主语言标为 Jupyter Notebook,所以存在可运行 notebook 的可能性,但主页没有确认这一点。

许可证与维护成本:现在最该先查的两件事

GitHub 把这个仓库的许可证标为 NOASSERTION,主页也没有给出许可证名称。这不是一个小问题。对一个声称要做「governed protocol layer」的项目来说,采用者需要知道协议文本、TXT 包和 notebook 分别适用什么条款,尤其是当你打算把 Problem Map 或 Goal Compiler 嵌进商业产品时。在仓库根的 LICENSE 文件内容明确之前,任何采用决策都缺少一个前置条件。维护成本方面,主页给出的信号是双向的:一方面它承诺分批开放,另一方面分批发布本身意味着接口和目录结构在 5.0 完成前都可能调整,最近一次 push 在 2026 年 9 月,release 记录从 3 月的 WFGY-4.0 到 5 月的 teaser 再到 5 月的彩蛋,节奏并不均匀。如果你的团队需要版本锁定和升级路径,现在只能靠固定 commit 来做到。

什么时候该换别的工具

WFGY 的整套设计围绕「结构化语言系统」和「协议」展开,它假设你愿意接受用自然语言约定来约束行为。如果你的需求是一个确定性的检索管线,用成熟的向量数据库加一套固定的评测脚本会更直接,因为那类工具的输入输出是代码定义的,不依赖模型是否遵守约定。反过来,如果你的团队已经在用 LangGraph 这类把 agent 状态机写成代码的框架,WFGY 的协议文本和它们不是同一层的东西,硬凑在一起只会增加一层需要人工核对的中间物。主页自己也承认 5.0 的深层引擎要等后续开放,所以在引擎部分公开之前,把 WFGY 当作排查手册和验证规范来用,比当作运行时来用更符合它现在的状态。

编辑结论

如果你手上已经有一条坏掉的 RAG 或 agent 流程,想先拿到一份可操作的排查清单,Problem Map 3.0 与 Global Debug Card 是当前最直接的入口;如果你在做 TXT 分发包的完整性校验,主页给出的 sha256 校验流程和 CFV 彩蛋可以直接照做。反过来,如果你的团队需要的是一个稳定 API、明确的版本兼容承诺和完整运行时,现在还不适合把 WFGY 当作依赖引入,因为主页明确说明更深层的引擎材料要等后续分批开放,5.0 也没有单日发布的成品包。动手之前先确认三件事:仓库根的 LICENSE 文件到底写了什么(GitHub 显示 NOASSERTION,主页没有给出许可证名称)、你要用的那个组件是否已经出现在 Polaris 目录下、以及你能否接受分批发布带来的接口变动。

官方来源

  1. Issues
  2. onestardao/WFGY on GitHub
  3. Project website
  4. README
  5. Releases
社区笔记

社区笔记