Add Git4Data Part 14: Agent Traces — Logs Alone Won't Tell You Why (EN + ZH)

[dengn]

What

Adds Part 14 — Agent Traces: Logs Alone Won't Tell You Why (EN + ZH).

Deliberately the most restrained part in the series. A trace is an append-only log, so it neither needs nor suits row-level diff and merge — and the article says so outright. There is not a single DATA BRANCH MERGE in it, and that's the point. What needs versioning is what the trace depended on.

Two gaps it closes:

1. A v1-vs-v2 comparison is only valid if the eval set is frozen — otherwise you're comparing two different exams.
2. A trace can never explain why unless each run records the memory version it read — because that memory keeps changing (Part 13's whole subject).

Content

• A v1 → v2 regression walked from headline to root cause in three SQL statements, then a fourth that time-travels to reconstruct what the run knew.
• An explicit does / doesn't-do boundary table, so the capability isn't oversold.

Verification

On MatrixOne 4.1.0, fully deterministic (14-agent-trace/): 4,000 runs / 16,000 steps; v1 ok 97.5% vs v2 ok 72.5%; 500 regressed inputs, all in technical; search_kb failures 2.5% → 27.5%; replay reads plan_tier=basic at mem_r1. pnpm validate → 385/385 ok.

🤖 Generated with Claude Code

[gouhongshen]

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

1. 冻结 eval set 没有实际约束两组 run。 文章称两版回答同一份冻结输入集（正文 L206），但配套 SQL 的两次 INSERT INTO runs 都是 FROM generate_series(1, 2000)，L67-L81，没有从 eval_inputs {SNAPSHOT='evalset_v1'} 取数；后面的 snapshot 查询只是计数，L161-L162。这能说明 demo 使用了相同的合成 ID，但不能证明结果绑定到冻结问题集。请改为从冻结 snapshot 驱动两版 run，或把正文改成“固定合成输入 ID”的示意。

2. 配置版本无法按文中要求重放。 正文要求同时记录 memory/config version（L91、L200-L201），但配套 SQL 只有 runs.config_version 中的 cfg_7/cfg_8 字符串和 mem_r1 查询，L67-L81、L156-L159；没有 agent_config、config snapshot 或 config replay。当前 SQL 只能证明 memory 可重放，不能证明“memory + config”可精确重建。请补齐 config 的快照/读取链路，或收窄正文结论。

3. TTL 不是 MatrixOne v4.1.0 可直接执行的表级语法。 正文写“用 TTL 做保留策略”（L187）。在对应版本执行代表性语句 CREATE TABLE t (id INT, created_at TIMESTAMP) TTL = created_at + INTERVAL 30 DAY; 返回 1064；v4.1.0 的 SQL parser grammar 也没有该 table-TTL clause。若这里只是泛指外部清理策略，请明确不是 MatrixOne 4.1.0 SQL 能力，并给出实际支持的实现方式。

4. “几个月后依然可精确还原”缺少 snapshot 保留前提。 demo cleanup 会删除 evalset_v1 和 mem_r1，L168-L169；我在 v4.1.0 验证删除后再用 {SNAPSHOT='mem_r1'} 查询会失败。测试清理本身不是问题，但正文 L341 应明确：只有在命名 snapshot 一直保留、未被删除时才能重放。Git4Data 前文也说明 snapshot/branch 被删除前会持续保留底层对象，并非无条件永久可用（Part 3 官方文章 L85-L90）。

5. 第三方系统边界的表述过于绝对。 L147 将“保留期由套餐决定、跨 trace×业务分析只能导出或放弃”写成通则；官方资料显示 Langfuse 支持 self-hosted，LangSmith 支持 OpenTelemetry 导出/接入，W&B Weave 也支持 OTLP/自定义 endpoint：Langfuse、LangSmith、Weave。建议限定为“某些 SaaS 默认部署”，不要作为所有产品的共同边界。

其余 OTel GenAI semantic-conventions、Dapper/OpenTelemetry 及文中列举的产品能力，我已对照各自官方资料核过；上述是需要改正文或 SQL 的 findings。