Add Git4Data Part 15 (Finale): Agent Self-Evolution — Reviewable, Reversible Behaviour (EN + ZH)

[dengn]

What

Adds Part 15 (Finale) — Agent Self-Evolution (EN + ZH). This closes the series.

Thesis: if an agent's behaviour lives in a table (prompts, tool policy, thresholds), then "the agent improving itself" — which sounds futuristic — collapses onto the pattern this series has used for fourteen parts:

propose → branch → evaluate → merge if it passes / drop if it doesn't → roll back if production disagrees

Content

• Behaviour as data, with changed_by / rationale so human and machine decisions stay distinguishable.
• Three candidates, each on a zero-copy branch — "the agent opened a pull request."
• A multi-dimensional gate written as a rule in the data, because a quality-only gate teaches the agent to buy score with resources. cand_c scores best (99%) and is still rejected for +57% cost — without that dimension it wins and the bill doubles with nobody able to say why.
• Promote the winner, drop the losers for free; then a runaway self-tuning incident (top_k=999) undone by RESTORE to a human-set baseline — a system that can change itself needs a fallback it cannot change.
• A closing table tracing all fifteen parts back to the same four questions: snapshot / diff / branch / merge-restore.

Verification

On MatrixOne 4.1.0, fully deterministic (15-agent-evolution/): candidate DIFFs 1 / 1 / 2; baseline 95.00%@1400; cand_a 98.00%@1550 (×1.107) PROMOTE; cand_b 95.00% REJECT; cand_c 99.00%@2200 (×1.571) REJECT; runaway top_k=999 → RESTORE → 5 / human; cfg_v7 and cfg_v8 both remain queryable. pnpm validate → 385/385 ok.

🤖 Generated with Claude Code

[gouhongshen]

Fact-check findings（按文章声明使用 MatrixOne v4.1.0 检查）：

1. 正文中的 gate SQL 不是可执行 SQL。 L130-L140 使用 FROM (...) c CROSS JOIN (...) b，我在 v4.1.0 执行该片段得到 1064。配套脚本使用的是完整子查询（L129-L139）。请把正文补成完整 SQL，或明确标注为伪代码/省略片段；当前文字称其为“可执行规则”。

2. “同一份冻结 2000 条 inputs”没有被 SQL 固化。 文章 L104-L120 使用了 frozen eval set 的事实语气，但配套脚本只是创建普通 eval_inputs 并用 generate_series 填充，L38-L43，没有 CREATE SNAPSHOT evalset_v1，评测结果也没有 {SNAPSHOT=...} 绑定。数据如果在 demo 中未被改动，可以得到同一组合成输入；但这不等于“冻结/可审计的 eval set”。请创建并记录 eval snapshot，或收窄为“固定生成的合成输入”。

3. 候选 C 的审计字段与正文叙述不一致。 表定义把 changed_by/rationale 作为变更审计字段（L39-L53），但正文 C 的两条 UPDATE L78-L89 只改 config_value。按正文片段执行后，C 的 changed_by/rationale 仍是初始的 human/baseline；配套脚本反而补了这两个字段（L78-L84）。请同步正文与脚本，否则 C 的“机器提案、可审计”结论不成立。

4. OUTPUT SUMMARY 只给计数，不能支持“改了什么”。 L95-L100 说 DIFF 能让“改了什么、改了几处”一目了然，但在 v4.1.0，DATA BRANCH DIFF ... OUTPUT SUMMARY 只返回 INSERTED/DELETED/UPDATED 数量；要看到 key/value 的具体变化，需要执行不带 OUTPUT SUMMARY 的 DIFF，或补充前后值查询。建议把“改了什么”改成“改了几处”，或展示完整 DIFF 输出。

5. RESTORE DATABASE 的作用域是整个数据库。 L205-L207 的语句不是只回滚 agent_config；v4.1.0 grammar 同时定义了 database/table 两种 restore（官方 grammar）。我实测 database restore 会删除 snapshot 之后创建的无关表；该 demo 中 eval_inputs/eval_results/promotion_gate 也属于 agent_eco，因此会被一起回滚。若目标是只恢复配置，应使用并说明 RESTORE TABLE agent_eco.agent_config {SNAPSHOT = cfg_v7}，或明确 agent_eco 是严格隔离的配置库。

6. “历史版本永远都还查得到”不成立，取决于 snapshot 生命周期。 配套脚本随后明确删除 cfg_v7/cfg_v8，L174-L176、L179-L184；我在 v4.1.0 验证 DROP SNAPSHOT 后同名 {SNAPSHOT=...} 查询失败。请将“永远”改为“在 snapshot 保留期间”，并说明删除/保留策略。

7. “输家的成本是零”过于绝对。 L164-L169 可准确表述为零数据拷贝/共享底层对象；但保留 snapshot/branch 不是无成本，前文 Git4Data 官方说明长期保留会持续占用底层对象存储，直到删除（Part 3 L85-L90）。建议改成“无需复制全量数据，淘汰分支可删除”，不要写成成本为零。

8. “human-set 且不能改变”的安全保证目前只是应用层约定。 L213-L217 的 SQL 没有权限或约束阻止同一执行者更新 changed_by、修改/删除 snapshot；L257-L259 应明确这是 Git4Data 使用流程/权限策略，而不是数据库本身的 guarantee。

另外，PR 69 正文链接的是未固定 revision 的 tutorial 路径；为满足“对应版本”复现，建议 pin 到本次实际检查的 commit 375babea601cfe4a6c297020751dd174664c7323（上面的链接已使用该 revision）。