OOOMETA/OS

诊断服务

你的执行日志里,八项技术项有几项的字段是空的

这是一次性诊断,不是平台授权,也不是咨询项目。你交一份脱敏的近 30 天执行日志,我们在 48 小时内交回一张八行表:八项技术项每项一行,每一格都带分子、分母和判据,缺的部分按「零 schema 变更就能补」到「必须改 schema 才能补」排序。

固定价 ¥8,000(前三单,之后 ¥15,000)· 48 小时交付 · 不签合规意见、不出证书

这件事在量什么

八项来自国家标准里的技术项:身份标识、系统权限调用、工具调用、数据收集使用、高风险操作人工介入、输入输出安全防护、日志留存与动态监测、异常阻断与紧急关停。我们要量的不是你的条款符不符合,而是一件更靠前的事:这几项要求写进日志的字段,你的运行账上到底有没有,有多少行真的带了值。

所以每一格都必须带两个数——分子和分母。分母只算这一格适用的行:输出摘要只在真的执行过的调用上要,审批回指只在升级到人工审核的行上要,关停动作只要发生过一次并落了账。把所有行都当分母,等于要求每一次普通调用都附一张审批单,那不是量实现,那是量需求。

一句「我们有完整记录」没法被复算,一个 686/778 可以。这张表值钱的地方就在这里:你不需要相信我们,你需要的是它在你自己的工程师手里能跑出同一个数。

我们自己那份表也不好看,如实放上来

第一次量的时候,我们的判据是错的:把永不适用的格子算进了分母,同一份库被判成 0 项。修正之后是 2 项。变的是尺子,不是账本,这两个数我们两个都留着。

然后是更难看的一段:同一份活库,隔一天再量,够的那项从 2 掉到 1。原因是输出摘要的覆盖率在这 5000 行的滚动窗口里掉到了 88%,低于我们自己定的 90% 阈值。我们没有为了把数救回去改阈值,也没有把这个窗口换掉。

快照时间账本有字段且够有字段不够无字段
2026-10-26 00:1x我方活库,最近 5000 行换了判据之后的第一版224
2026-10-27 00:1x同一库、同一窗口口径输出摘要覆盖率掉到 88%,第 3 项从够翻成不够134
2026-10-27 08:3x外来账本,300 行 CSV,列名与我们完全不同就是页底可下载的那份样例215

三行的日期、账本和命令都留在内部记录里。你自己手上那份账本跑出来是 1 项还是 6 项,都不影响我们收钱,影响的是补齐清单从哪一格开始。

你交什么

近 30 天的执行日志,200 行起、5 万行封顶。CSV、JSONL 或者任意 SQLite 都行,列名叫什么都不重要,我们会写一份映射契约把你的列名对到八项要求的逻辑字段上——对不上的就如实判「无字段」,不按列名相似度猜,也不用默认值填。

必须保留的列(名字可以完全不同)

  • 01时间 — 这一行是什么时候发生的
  • 02主体标识 — 哪个 Agent 做的,换成假名即可
  • 03工具或动作名 — 它调用了什么
  • 04输入摘要 — 进来的是什么,哈希或摘要,不要正文
  • 05输出摘要 — 出去的是什么,同上
  • 06判决结果 — 放行、拒绝、升级
  • 07拦截或报错标记 — 有没有被拦下、有没有失败

交之前请删掉

  • prompt 正文与模型回复正文
  • 用户原始数据
  • 密钥与访问凭据
  • 手机号、身份证号

主体标识换成你自己的假名(A1、A2……)就够,我们不需要真名。也请不要为了脱敏去做不可逆哈希—— 那样你自己也对不回来,后面的补齐和复算都会断。

48 小时内出什么

从收账到交表 48 小时。改期只在我们这边的账本跑不动时发生,而且提前说明。

01

八行表

八项每项一行,每格带分子、分母和判据。够与不够分开写,不用一个总分糊过去。

02

补齐清单

按「零 schema 变更就能补」到「必须改 schema 才能补」排序。先做不动库表的那几格,改动成本最低的排在前面。

03

复现命令与映射契约

你自己的工程师可以原样重跑,拿到同一个数。另含一次复算答疑,对不上就一起对。

价格

¥8,000 前三单

¥15,000 之后

这是决策价,不是市场调研价。前三单结束后按实际耗时重估。

不做什么

  • 不签合规意见
  • 不出证书
  • 不做渗透测试
  • 不出「符合某标准」的结论
  • 不接改造实施

改造可以另谈,但第一单不接——这是防止第一单变成项目的分界线。

数据怎么处置

原始账本在交付后 7 日内删除,只保留聚合后的八行表与映射契约。不训练、不转存、不用于其他客户。

这一条会写进你签的那份契约里,和下面那几条一样,不是页面上的口头承诺。

自助试跑:先看样例,再决定要不要交账

不用先联系我们。下面四份文件可以直接下载:一份 300 行的合成账本、把它的列名对到八项上的映射契约、这份账本跑出来的八行表、以及一张写清每项要哪些字段的契约表。看完你就知道自己那份日志缺哪几列。

runner 输出里的三个状态写作「有字段可出示 / 有字段出示不了 / 无字段」,对的就是上表的够、不够、无字段。

三条复现命令(我们跑这份样例时用的就是这三条)

① 八行表(给人看)

python3 scripts/evidence_ledger.py \
    --ledger ./agent_events-sample.csv \
    --adapter ./mapping-contract.json --markdown

② 每格分子与分母(给工程师复算)

python3 scripts/evidence_ledger.py \
    --ledger ./agent_events-sample.csv \
    --adapter ./mapping-contract.json --grid

③ 契约表(每项要哪些字段、缺失时判什么)

python3 scripts/evidence_ledger.py \
    --ledger ./agent_events-sample.csv \
    --adapter ./mapping-contract.json --contract

复现所需的只读 runner 随交付包一起给你,命令与上面这三条一致,只把路径换成你自己的账本。它在你的机器上跑,不联网、不写你的库。

跑完把你的八行表发我们

留言里写上「八项字段检查」,附上你日志的列名清单(不用附数据)。我们会先回一句话:按你这套列名,八项里哪几项现在就能算,哪几项必须先改写入端。

去留言