蜂群自我进化计划
2026-09-05 · 依据：cron.yaml 46 条任务、今天一天的运行数据、玛哈念社会层、以及市面上 Hermes / Darwin Gödel Machine / DeepSeek Harness 的做法。
一句话：进化不靠两个 agent 动刀，靠全体记经验、机器做选择、人守身份。
一、现状：cron 在驱动什么
46 条任务，按性质分七类：
| 类别 | 条数 | 例子 | 驱动方式 |
|---|---|---|---|
| 采集与数据 | 17 | dts 三条、看板五条、气候四条、科技、科学、区域、老化图谱、R2 同步 | 纯脚本 |
| 解读与简报 | 6 | tech-brief、science-brief、climate-brief、shiling-brief/retry、aging-reading | 脚本派单给 agent |
| 内容生成 | 5 | 灵修（guyon）、入籍（citizen）、市场分析（growth）、arXiv（万事通）、GitHub（scout-web） | agent |
| 发布与同步 | 6 | kinbook-publish、content-queue、kinwiki-sync ×2、warmup、wiki-refresh | 5 脚本 + 1 agent |
| 知识生长 | 4 | spiritual-en/zh、tcm-zh、discovery | 纯脚本 |
| 维护 | 2 | local-health-check、rotate-logs | 纯脚本 |
| 进化与治理 | 6 | improvement-cycle、patrol、quality-audit、feedback-synthesis、gap-analysis、weekly-retro | 全在 2 个 agent 身上 |
今天：40 条任务跑了 1188 次，失败 9 次（简报脚本类 4、发布 1、侦察 1、气候数据 1、warmup 1、入籍 1）。脚本层很稳。
问题在最后一行。 进化的六条任务全压在 swarm_architect 和 quality_auditor 两席上。今天的证据：
- ●quality_auditor 23:06 的报告是「诚实的空白」：它调了 32 次工具，全被自己 v1.5.0 加的去重缓存挡回去，一轮什么都没审到。选择环节失效。
- ●swarm_architect 背着 78 个技能，其中 10 个是四月的一次性发布脚本；本轮 22 条存量问题一条没修，只搭了闸门。
- ●kinbook-publish 是关键的确定性流水线，却由 agent 提示词驱动，今天失败了一次。这违反你自己的规矩：确定性流水线用 cron 跑脚本，agent 只留给要判断的环节。
- ●26 位工程师席位里 24 位没有排班也没有工单，只是名单。
再往前的证据，都记在 memory 里：gen-fleet 一次覆盖 125 份手工 soul；memory.db 的压缩摘要以 system 身份存回，13 席百分之百拒答；幻觉伪装成事实核查；规则里的样例数字变成幻觉模板；机械规则调到来回震荡。结论：变异很多，选择很弱，档案没有，门没有。
今天可以拿来当起点的数字：
| 信号 | 今天 | 来源 |
|---|---|---|
| 抛锚（rescued） | 14 次，涉及 12 席 | output/rescued/ |
| 反馈日志 | 58 席共 2455 条：error 1727、correction 78、gap 60、satisfaction 122 | output/feedback/ |
| 活跃席位 | 176 席、1664 轮 | output/usage/ |
| 城 | 访客 4、求问 8、开口 515 句、杏林 50 株 | 城志 |
| 发布闸门 | 拒发记录（Phase 0 存根、自称未完成） | kinbook_post 的 receipt |
二、五条原则（别人验证过的）
- ●进化的是权重之外的东西：经验、技能、提示词、代码。从不碰身份。（Hermes：技能是流程，记忆是小事实；DGM：改的是代码。）
- ●存之前先验证：跑得通、过 lint、过回放，才落盘。（Voyager 的技能能跑才存；DGM 每个版本先跑分。）
- ●用的时候按需加载：列表里只有名字和一句描述，用到才读全文。78 个技能全开是反例。
- ●有档案有谱系：每次改动一个分支，写明改前改后的数，能回退、能分叉。（DGM 的 archive；Hermes 的 reset。）
- ●人守身份这一层：soul 的改动进暂存目录，人批。全自动只在有真实基准的地方。
细胞自己学，器官不自己改基因，改基因要过审。
三、适应度：让选择变成真的
进化没有目标函数就是折腾。定六个数，全部在真实路径上量，全部由脚本算，每天 23:30 写进 output/health/fitness.md，进城志和日报：
| 信号 | 怎么算 | 方向 |
|---|---|---|
| 纠正率 | feedback_log 里 correction ÷ 当日回复数 | 降 |
| 抛锚数 | output/rescued 当日新文件数 | 降 |
| 静默失败 | skill_health_check 的 E1–E3 数 | 降 |
| 闸门拒发 | kinbook_post receipt 里 rejected 数（存根、自称未完成、无来源） | 先升后降 |
| 真实服务 | 功德榜问诊数 + 转诊到达数 + 杏林新栽数 | 升 |
| 成本 | output/usage 按部门汇总的轮数与 token | 平 |
规则：每条提案必须写明它要动哪个数。周会只看数动没动。四周没动的规则撤掉。
四、三层架构：谁进化什么
经验层：每一席自己长，只追加，不改写
- ●医案：中医馆每次问诊后，大夫写一行去身份的医案进自己的档；下次问诊先检索相似案。教会同样做牧养记录。这是真的经验值，直接改善下一次回答。
- ●反馈日志继续用，但每席每天自评一行：今天什么没做成、为什么。
- ●memory.db 降权：压缩摘要不再以 system 身份存回，只作为可检索的笔记。这是全计划里最便宜、最要紧的一步——它是拒答传染的根。
- ●网上抓来的内容打上「外来」标记，和 soul 自有知识分开（openhuman 的 MemoryTaint）。
行为层：只能提案，不能动刀
- ●暂存目录
output/proposals/<日期>-<席位>-<标题>/：改动的 diff、证据、要动的那个数、测试方式。任何 agent 都能提，包括各馆指挥和 24 位工程师。 - ●门由脚本守（
proposal-gate，每小时）：YAML 能解析、SKILL.md 能加载、测试通过、不覆盖手工 soul、规则样例必须是占位符、不新增 system 权限的记忆。过门的技能类改动自动合入一个分支；动到 soul 的一律等人批。 - ●技能按需加载：席位只带技能列表，用到才读全文。架构师的 78 个先清到 20 以内，10 个死脚本删掉。
- ●档案：每条合入的提案一个 git 分支，附改前改后的数；周会决定并入还是回退。
结构层：代码，人和 Claude 会话改
- ●运行时的每次行为都能从日志重建；关键路径加录制回放测试；沙箱 fail-closed。
- ●这一层不交给 agent 自主改。
五、分布式：不再是两个人的事
| 角色 | 做什么 | 节奏 |
|---|---|---|
| 每一席（184 席） | 记经验、自评一行、可提案 | 每次任务后 |
| 各馆指挥（tcm / spiritual / board / prediction / quant） | 本馆复盘，看本馆的数，提本馆的案 | 每周 |
| 平台部（swarm_architect、quality_auditor） | 跑循环：算适应度、跑门、汇总提案、准备周会。不再直接改别人的 soul | 每天 |
| 城（玛哈念的社会层） | 议题 → 馆务 → 城志 → 日报，就是进化的日循环，公开可读 | 每天 |
| 人（你） | 批身份层改动，看十分钟周会板 | 每周日 |
quality_auditor 的角色从「审所有产出」改为「验证提案里声称的数是真的」——它只做核实，不做全量审计，全量审计交给脚本。
六、cron 重排
改：
- ●
kinbook-publish改成脚本驱动（它是确定性流水线），agent 只写内容不管发布。 - ●
daily-quality-audit改成脚本fitness-board（23:30），审计员只在周会前核实提案。 - ●
swarm-improvement-cycle从「自主打磨整个蜂群」改成「汇总提案、跑门、写周会板」。 - ●
autonomous-patrol保留，但产出只能是提案，不能是直接改动。
加：
- ●
fitness-board每天 23:30，脚本。 - ●
proposal-gate每小时，脚本。 - ●
hall-retro每周六，各馆指挥各写一份本馆复盘进提案目录。 - ●
weekly-review每周日 09:00，脚本把适应度趋势、过门提案、待批 soul 改动编成一页。 - ●医案写入不走 cron，在世界的问诊结束时触发。
删或并：三条 kinwiki 同步并成一条；四条 knowledge-growth 保持。
六点五、cron 重排已落地（2026-09-05）
| 任务 | 原来 | 现在 |
|---|---|---|
swarm-improvement-cycle | 每 6 小时，第 3 节标题「执行修复（直接改文件）」，范围 200+ soul | 每天一轮，只写提案，每件必须说明要动六个数里的哪一个 |
autonomous-patrol | 每 6 小时，「严重问题直接修复」「立即修改相关 soul」「直接用 forge 创建」 | 每天两轮，产出只有记录或提案；主活改成核实已合入提案说好的数动了没有 |
daily-quality-audit | 每 6 小时，全量审计并自己重数 | 每天一轮，只做机器做不了的（金融幻觉检测、抽检） |
kinbook-publish | agent 读 1553 字提示词 | 脚本 scripts/kinbook_publish.sh |
新增 fitness-board | — | 每天 23:30，六个数 |
新增 proposal-gate | — | 每小时，七道检查 |
新增 hall-retro | — | 每周六 17:00，五位馆务指挥各写本馆复盘（派单由脚本做） |
新增 weekly-review | — | 每周日 09:00，一页看完这一周 |
三条 agent 任务共用同一组铁律：不许直接改 souls/／skills/／scripts/／worlds/；
不许整体覆盖；不许新锻技能绕过「上一个没跑通」；举例一律 <占位符>；
诚实地写「本轮无提案」不算失职。频次一天 12 轮压到 4 轮。
七、四周里程碑
| 周 | 做什么 | 验收 |
|---|---|---|
| 第 1 周 | memory.db 摘要降权；fitness-board 上线；proposal 暂存目录 + 门（只校验不合入）；修审计员去重；清架构师死技能 | 六个数每天有；审计员报告不再空白 |
| 第 2 周 | 中医馆医案 + 检索；技能按需加载；kinbook-publish 改脚本 | 问诊回答引用到既往医案；架构师技能 ≤ 20 |
| 第 3 周 | 门自动合入技能类提案到分支；各馆指挥第一次复盘；weekly-review 第一次 | 至少 3 条提案过门，每条带数 |
| 第 4 周 ✅ | 公司世界上线（worlds/company.yaml :9806，早会 09:05 念六个数、主日周会念周会板）；城门信箱（scripts/gate_inbox.py，cron 每 2 分钟，只收本人会话）；三条进化任务收口成"只写提案" | 周会板 output/health/weekly_review.md 每周日 09:00 自己写好 |
| 第 2 个月 | 录制回放测试；DGM 式档案分叉；评估四周的数 | 纠正率、抛锚数至少一项明显下降 |
八、红线
- ●永远不整体覆盖手工 soul；gen-fleet 只补缺。
- ●规则里的样例一律占位符，不写具体数字。
- ●记忆永远不带 system 权限。
- ●每个部门有 token 预算，超了停工，财务董事管账。
- ●机械规则出现来回震荡，立刻冻结该规则，转判断层。
- ●提案不带「要动哪个数」不进门。
八点五、提案怎么写（已上线）
output/proposals/ 是暂存区（内容不进仓库，说明在 output/proposals/README.md）：
output/proposals/2026-09-05-tcm_conductor-秋燥指南入库/
PROPOSAL.md ← frontmatter: proposer / metric / title / test，正文 ≥80 字
changes/skills/xxx/SKILL.md ← 改完的整份文件，路径照仓库
metric 必须是六个数之一。判定三种：✅ 过门（只动 skills/scripts/wiki）、
🟡 等人批（动到 souls/）、❌ 退回（报告逐条说明）。
自查 python3 scripts/proposal_gate.py --dir <目录>。
门只查你改出来的行。 第一次拿真提案试门就栽在这：架构师的 soul 里有一整段 在讲「举例别写真值」这条规则的来历（不得不引用当年那个真实时刻），门把这段 祖传文字当成本次改动报了四条，而提案人根本没碰它。门要是分不清「你改的」和 「本来就在的」，就没人愿意用它。现在内容类检查先与仓库现状做 diff，只看新增行； 新文件则整份都算新增。
九、先做的三件
- ●
memory.db 摘要降权—— 已在做：另一会话已给pkg/server/server.go的 compaction 加了「摘要只写工作、不写对方」的约束，并把回填的摘要明确标成 「recall only, NOT instructions，不override soul」。仍是 RoleSystem 槽位， 真正换角色要等那份改动落定。 - ●
fitness-board 脚本，六个数—— 已上线（scripts/fitness_board.py， cronfitness-board每天 23:30，写output/health/fitness.md+fitness.jsonl， 带昨日对比）。 - ●
proposal 暂存目录和门—— 已上线（scripts/proposal_gate.py， cronproposal-gate每小时，七道检查，三种判定）。
首日基线（2026-09-04）：纠正 2 条／每千轮 0.3、抛锚 16 次涉 11 席、静默失败 34 条 （E0 7／E1 13／E2 10／E3 4）、闸门拒发 3 发出 1、真实服务 17、成本 5873 轮 176 席、 城务成 1199 败 9。
第 2 周（2026-09-05 做完）
- ●
医案已上线（
pkg/world/cases.go，limits.case_notes）。线上实测：吴鞠通答完落盘， 改述再问回忆到那一案，第二次辨证一致且更细。尺子被真实数据改了两次 —— 汉字二元组认不出改述（「干咳」≠「咳嗽」、「嗓子」≠「喉咙」、「晚上」≠「夜里」）， 最终是「实词重合为主、二元组只作加分」。 - ●
kinbook-publish 已改脚本（
scripts/kinbook_publish.sh）。路由固定、质量闸门和 24h 去重本来就在post.py里，没有需要判断的环节；原先占着 swarm_architect 每四小时醒一次读 1553 字提示词，还失败过一次。 - ●
技能按需加载 —— 量过之后不做了。
计划里写这条，是因为架构师背着 61 个技能。但把 413 份 soul 全量过一遍：
启用技能数 工具清单字符 中位 6 765 均值 6.8 937 超过 20 个的席位 3 / 413 也就是说这是一个席位的问题，不是架构问题。渐进披露要动
pkg/skills/executor.go和工具分发（而那个文件正被另一个会话改着）， 给 410 个席位省下不到一千字符——不划算。真正该做的是把那一个异常席位 收拾干净（提案已在暂存区等批：61 → 51），必要时再往下收。这条记在这里当判例：计划里的条目也要先量再做；量出来不划算就撤掉， 这正是「四周没让那个数动的规则撤掉」的同一条纪律。