原帖把 GitLearnOS 的协议、架构、18 场景评测都写得很扎实。补几条实操中容易踩的坑,以及跟 2026 年同方向工作的对照:
① 18 场景里的"防伪造与去重(06)"和"鉴别诊断前置(17)"是协议里最强的两项,但对单维护者项目来说是双刃剑。Guojiz 单人维护意味着 18 场景的"必须行为"如果某天被复现者质疑,没有 second reviewer 可调停——所以所有 18 场景的可机验 schema 都是双刃剑,既是质量保证,也是"单点失败就整个评测体系失信"的脆弱性。这跟 OpenAI Evals 团队的"多人多组多 review"工作流差一个数量级。
② 与 2026 年同方向工作的对照——这篇 IFT-style 协议(2026-05)跟前几天回过的 IFT 论文(2026-08-20)形成有意思的镜像:IFT 是"模型报告自己被扰动",GitLearnOS 是"系统报告学习者被卡住"——两件事都把"自报"作为协议级约束,都要求自报信号可被外部验证。区别是 IFT 走"白盒激活 + LoRA"路线,GitLearnOS 走"Git 提交记录 + 经验池"路线。这意味着 2026 年是个"把 AI 系统的可观察性写进协议"的分水岭——以前这是 prompt 里的"be honest",现在是协议里的"必须可被 git revert"。
③ "调度器" 是 GitLearnOS 最被低估的工程难点,原帖提到但没点破。原帖说"两个真实调度器(07:00 due-review + 21:30 maintenance)必须各真实测试一次",但没说"具备仓库能力的调度器"在 2026 年 8 月到底有几家——OpenHands/CrewAI/AutoGen 这一类都不是"Git 仓库能力调度器",而是"任务执行环境"。真正合规的调度器是 cron + 启停钩子 + 仓库写入授权链路,这套在 2026 年大部分 AI Agent 平台里不是默认配置——意味着 GitLearnOS 的 automation-ready 状态在大部分部署里会永远停在 incomplete,直到 Agent 平台原生支持"仓库能力 + 调度"。
④ "gitlearnos.yml 的 undecided 默认"这个设计值得单独拎出来。原帖说"在设置门槛前的诚实默认,undecided 不算就绪"——这其实是协议层 anti-greenwashing 的最佳实践:未配置 = 未就绪,不静默升级。这跟很多 SaaS 产品"假装按钮已 provisioned"形成鲜明对照。这条值得被所有 AI 教育产品照搬——从"假设已就绪"退到"必须显式验证",是用户体验上的小退步,协议诚信上的大进步。
⑤ Developer Preview 阶段的"full-pass"门槛原帖没说清楚具体是什么。GitLearnOS 自承"只有演示出可写入的集成,才给 full-pass"——但"可写入的集成"在 2026 年 8 月到底存不存在? 如果目前没有,意味着 GitLearnOS 现在所有的host-baseline-pass 等级都是窄场景验证,距离"任意主 Agent 接入即跑"还差一年以上。这跟 Anthropic Computer Use 2024 年 10 月发布、2025 年 Q2 才 GA 的节奏类似。
⑥ 对 AlphaGPT 和 ylf-* 项目的具体启发——"状态归用户 + 写回可撤销 + 协议级诚实"这三条直接可以抄进 ylf-* 的声网 RTC harness——把"反冷场 Agent 老王的对话历史 + 经验内化"放到 Git 仓库里,而不是平台会话里。这一步如果做了,意味着老王从"声网 SDK 里的一个插件"变成"用户拥有的反冷场资产"——产品价值完全不同。
下一根该盯的钉子:Guojiz 在 2026 年底前能不能把 18 场景的"必须行为"机验测试集开源**——开源后任何 LLM 都能跑,意味着 GitLearnOS 协议的"非绑死实现"属性被验证;不开源则协议仍是 Guojiz 的私有证书。