本页要回答 · 多数公司不知道自己的 AI 是好是坏——这个问题怎么破?
怎么知道在变好:评测与治理(EOS)
行业现状(LangChain 2026-06 调查,1,340 团队):约 89% 已做可观测,约 52% 有评测集,几乎无人有完整治理门禁。能观测 ≠ 能证明在变好;能证明 ≠ 有权让它放手干。EOS(评测与优化体系)是 GYOS 对这两道缺口的回答。
核心思想:万物皆对象,对象都有生命周期
系统里一切会进化的东西——Agent 岗、技能、知识卡、本体规则、管线工序、产品、站点、内容——都按同一模型管理:
对象卡定义/指标/评测集/权限/预算
→
五道门构建→评测→治理→晋升→运行
→
按对象回流运行数据回写对象卡
→
下一版本升级或收缩
铁律:无评测不升级、无评测不交付、无评测不立项。
五道门(Agent/代码/内容/产品同一套)
| 门 | 问什么 | 说明 |
|---|---|---|
| ① 构建 | 编译得过吗?定义合法吗? | 最基础的合法性检查 |
| ② 评测 | 输出质量达标吗? | 跑评测集(golden set:来自真实历史的已知答案),不靠感觉 |
| ③ 治理预检 | 它有权限做将要做的事吗?预算封顶了吗? | 业界最常缺失的一道:评测好 ≠ 允许动生产数据 |
| ④ 环境晋升 | 测试环境的策略,生产环境真生效了吗? | 防止「测试放行、生产裸奔」 |
| ⑤ 运行监控 | 上线后实际表现、成本、错误率如何? | 记录 ≠ 治理;数据要回流到下一版评测 |
评测集 = 历史的影子
每个对象类型的评测集来自真实历史(做过的任务、发过的内容、踩过的坑、验证过的规则)。每次升级/换模型/改规则,先跑「影子」再上线——评测分低于阈值的改动不允许发布。
例:生产系统每次变更先做「基线重放零差异」验证——这正是评测思维的一种形态,GYOS 把同一纪律推广到 Agent、内容与产品。
对外交付:mini-EOS
企业 AI 交付(L4 及以上)不只是「建个 Agent」,而是给企业装一套可评估、可治理、可优化的 mini-EOS:试点带评测集与验收清单,交付带治理与运行观测。这样客户不再问「这 AI 到底行不行」,而是看评测分与回流记录。
费曼测试