gitea-publish
e5cdb1801e
样本 - openwork (different-ai/openwork) 23.2k★ 能力分发层，DCO + evals + worlds - orca (stablyai/orca) 58.8k★ 并行编排外壳，5000 issue 实为团队自开任务板 - maka (apache/maka) 4.4k★ 执行记录层，Apache 孵化但无正式 release 档案 - 三份五维档案填完，risk.claim_vs_reality 均已核实到证据 - ipollowork 象限坐标从占位 9/9/9/9 校准为 8/7/7/7（与新样本同一标尺） 文章 - 新增横评文《四个 Agent 工作台的路线分野：把「多引擎中立」拆开看》(emlog id=99) - 总纲文回填四项目矩阵 + 双视图象限图 (emlog id=98) 镜像 - gitinbox/maka 已推送（public，source-only 快照 12 MB） - openwork(291MB) / orca(671MB) 受 50KB/s 带宽约束，档案标 mode: pending 规则 - license-tiers.yaml 新增「目录切分许可」降级流程（OpenWork 判例： 排除 ee/ 后为纯 MIT → public，完整镜像 → private） - registry.yaml openwork 可见性改 public + mirror_excludes: ["ee/"] 脚本修复 - _common.py 新增 upsert_block：手工整块覆盖 ecosystem 删掉 metrics 时能自愈 - mirror_sync.sh：SOURCE_ONLY 未初始化（set -u 下偶发炸）； 浅仓推送被服务端拒绝 → 自动 --unshallow，失败降级快照； 量体积前先 repack（此前新 commit 全是 loose object，恒打印 0 MB） - build_matrix.py：成熟度长文本移出表格（新增 maturity_level 短标签）； 象限图标签靠右时翻转到左侧防溢出；SVG 加 max-width 防窄屏溢出； 文章索引改为自动生成（原先手抄，横评文发了索引里却没有） - publish_emlog.py：ID 回写按「有无同名档案」分流， 00-* 跨项目文章落到 articles/<id>.meta.yaml（此前 ID 无处可写）
agent-radar · 全球智能体开源应用追踪
持续追踪全球 AI Agent 开源应用，输出深度分析文章（发布在 blog.apescale.com 可巴蒂栏目），
并镜像源码到 gitinbox 组织做代码级跟踪。
设计原则：每新增一个项目，边际成本递减，横向对比能力自动增强。 所有项目共用同一套五维 schema，因此对比矩阵、赛道图、总纲索引都能由脚本自动生成， 人只需要做「研判与写作」这部分不可替代的工作。
收录标准
满足任一即可收录，但会标注不同 status：
| status | 含义 | 判定 |
|---|---|---|
active |
持续追踪 | 有实际影响力，或技术路线有代表性，值得长期跟进 |
watch |
观察中 | 早期项目，方向有意思但尚未验证 |
archived |
归档 | 停更 / 被收购 / 路线变更 |
不收录：纯模型权重、纯数据集、无公开代码的论文复现、营销型空壳仓库。
目录结构
agent-radar/
├── README.md # 本文件
├── schema/
│ ├── project.schema.yaml # 五维档案字段定义 + 枚举（也是脚本的骨架生成源）
│ └── license-tiers.yaml # 许可证成色分级 → 镜像可见性规则
├── data/
│ ├── registry.yaml # 收录总表，驱动批量抓取
│ ├── projects/<id>.yaml # 每项目一份五维档案
│ └── snapshots/<id>.jsonl # 指标时间序列（追加式，一行一天）
├── articles/
│ ├── 00-overview.md # 总纲文源文（含矩阵占位符，由脚本回填）
│ └── <id>.md # 项目深度文源文
├── templates/project-article.md # 文章固定章节模板
├── scripts/ # 抓取 / 生成 / 镜像 / 发布脚本
└── site/index.html # 静态总览页
五维档案
每个项目一份 data/projects/<id>.yaml，字段定义见 schema/project.schema.yaml：
| 维度 | 回答的问题 |
|---|---|
identity |
它是谁、谁在做 |
business |
它靠什么活着、为谁活着 |
scenario |
它在什么场合被用、产出什么 |
tech |
它怎么做到的、抽象在哪一层 |
ecosystem |
它的社区动能（多数由脚本自动刷新） |
risk |
它的坑在哪、宣称与实测的落差 |
risk.claim_vs_reality是最不该留空的字段。它逼着每篇分析去核实 「项目方宣称 vs 实际状态」，防止文章退化成 README 复读。
许可证分级 → 镜像可见性
新增项目时的第一判断项。 规则见 schema/license-tiers.yaml：
| 级 | 判定 | 成色 | 镜像可见性 |
|---|---|---|---|
| L1 | MIT / Apache-2.0 / BSD / ISC / GPL / MPL | 完全开源 | public |
| L2 | AGPL / SSPL / BUSL / Elastic-2.0 | 有限开源 | public（档案标注限制） |
| L3 | NOASSERTION + 自定义 source-available | 源码可得、非开源 | private |
| L4 | 无 LICENSE / proprietary | 不可得 | 不镜像，仅存链接 |
定错级的代价：L3 项目被公开镜像，等于替对方做了一次未经授权的公开分发。
新增一个项目的 SOP
# 1. 建档（自动抓许可证并定级 L1-L4）
python3 scripts/new_project.py --repo owner/name
# 2. 手工填档案五维度 —— 重点填 risk.claim_vs_reality
$EDITOR data/projects/<id>.yaml
# ⚠️ 补完时**不要整块覆盖**下面这三个块，它们由脚本回写：
# ecosystem.metrics（fetch_stats 写）
# mirror （mirror_sync 写）
# article （publish_emlog 写）
# 整块替换 ecosystem 会把 metrics 一起删掉，表现为矩阵里指标静默变空。
# 真踩了也别慌：fetch_stats 用 upsert_block 会自动把 metrics 长回来
# （python3 scripts/fetch_stats.py --id <id> --force）。
# 3. 刷新指标（放在填档之后，别反过来）
python3 scripts/fetch_stats.py --id <id>
# 4. 镜像源码（按许可证等级自动决定 private / public）
bash scripts/mirror_sync.sh --id <id>
# 5. 成文（套 templates/project-article.md）
$EDITOR articles/<id>.md
# 6. 发布到 emlog（可巴蒂 sid=17），emlog_id 会自动回写档案
python3 scripts/publish_emlog.py --article <id>
# 7. 回填总纲并更新总纲文
python3 scripts/build_matrix.py
python3 scripts/publish_emlog.py --article 00-overview
# 8. 入库
git add -A && git commit -m "track: <name>" && git push
⚠️ 更新总纲文时必读
emlog 的 update 接口不传 --content 就会清空正文。
保护点应该是「本地正文非空」，而不是「update 前先 detail 取回线上全文」——
本脚本的 content 永远来自本地 Markdown 源文件，不存在"忘了传"的情况；
反过来，emlog 的 detail 接口查不到草稿，如果把保护建立在 detail 上，
草稿就永远无法转正。所以 publish_emlog.py 的判据是：本地正文非空即放行，
detail 只作为可选的健全性检查。
如果你手工调 emlog 脚本更新总纲，记住同一件事：确保传了 --content。
两类文章，ID 落点不同
publish_emlog.py 按「有没有同名项目档案」自动分流，不需要手工指定：
| 文章类型 | 文件名 | ID 落点 |
|---|---|---|
| 项目深度文 | articles/<id>.md（有 data/projects/<id>.yaml） |
档案的 article 块 |
| 跨项目文章 | articles/00-*.md（总纲、横评、专题） |
articles/<id>.meta.yaml |
新增一篇 00- 开头的文章不用做任何额外配置，发完就有 meta。
反过来，如果某天需要给跨项目文章单独建档，只要 YAML 一出现，脚本会改走档案路径——
先按「是不是项目文」分流，再决定写哪儿。
文章索引不需要手工维护
总纲里 <!-- INDEX:BEGIN/END --> 之间的内容由 build_matrix.py 生成，
事实源是两处：项目档案的 article 块 + articles/*.meta.yaml。
这段原本是手抄的，结果横评文发了、索引里却没有它——手写的索引每发一篇文章就漂移一次。
现在只需要在发完文章后重跑 build_matrix.py，没深度文的项目会自动标注「待发布」并指向现有横评。
脚本一览
| 脚本 | 作用 | 降级行为 |
|---|---|---|
new_project.py |
建档 + 自动判许可证等级 | API 失败时生成未定级骨架，要求人工填 |
fetch_stats.py |
抓指标 + 累积时间序列快照 | 无 GITHUB_TOKEN 则匿名降级；当日缓存；失败沿用上次快照并标 stale |
build_matrix.py |
生成对比矩阵 + 赛道图 / 象限图 + 文章索引 | 项目 <4 个出分层图，≥4 个才出象限图；索引缺标记则跳过并警告 |
mirror_sync.sh |
源码镜像同步 | 大仓（>300MB）提示并支持 treeless clone 降级 |
publish_emlog.py |
emlog 发布 / 更新 | 本地正文为空时拒绝 update（防清空线上） |
已知约束
- GitHub API 限额：无
GITHUB_TOKEN时匿名限额 60 次/小时。 项目数超过约 20 个后批量刷新会受限，建议配置 token。 - GitHub 下载带宽：本机到 GitHub 实测约 50 KB/s（走沙箱代理 56 KB/s，
直连 27 KB/s 且 github.com 常被阻断）。591 MB 的仓全量镜像需要 3 小时以上。
大仓一律先
--depth 1，后续再用脚本的增量加深补齐。 - Gitea 推送上限：前置 nginx 的
client_max_body_size约 50 MB （实测 48 MB 放行、64 MB 拒绝）。超限会在传完所有对象后才收到 HTTP 413。 脚本内置体积闸门，超限自动降级为「源码快照」（剔除非源码素材，通常能减一半以上）。 彻底解法是在服务器 nginx 配置里放开该值。 - 浅仓不能直接推送：Git 服务端默认
receive.shallowUpdate = deny， 推浅仓会被拒。脚本在推送前自动--unshallow补齐历史； 若补齐失败则降级为快照（丢历史但保住代码）。 - 磁盘占用：源码镜像是全量裸仓。4 个项目已占约 800 MB。
大仓可用
--filter=blob:none做 treeless 镜像。 - 象限图阈值：样本 <4 个时象限图没有统计意义，此阶段只出赛道分层图。 4 个也只是示意，不构成统计结论。