切换外观
判断评测：第一次真实模型运行（2026-10-14）
状态：一次性评测记录。结论只覆盖本次设置——一个情境、一个模型、一次运行、teacher-forced；不是 Skill 的验收标准，也不改变信息契约。
在此之前，原型情境里 112 条输入的处置和 36 个批次都由作者手写。本轮把 skill/SKILL.md 交给真实模型，逐帧让它读同样的状态与输入、输出处置和批次，再交给内核执行，与作者的编排对比。作者的编排不是标准答案：它是同一团队写下的一种合理整理，下文的差异案例逐一判断谁更合理。
结论
能当这个编辑的初稿作者，但还不能证明它能长期独立维护这份状态。
- 操作层面可靠。 36 帧全部提交成功；只有 2 帧首次被拒（都是
explicit_withdraw_required），看到回执后一次改对。没有一次超预算，标题与摘要都在长度限制内，来源引用格式全部正确。 - 处置与档位大体一致。 处置一致 91%；匹配上的条目里档位完全一致 48%，相差一档以内 98%，Agent 偏高 26 次、偏低 27 次，没有方向性偏差。作者自己的档位也是一次性手写，邻档差异更像两个合理编辑之间的分歧。
- 在时间与证据纪律上，几处比作者好。 约定时间过了却没有回报时，Agent 把“已约”改成“是否到场未知，待核实”，后来的输入证明那次上门确实落空（案例 2）；零事件复核时注意到当晚的面谈只占 1 份（案例 1）；到点提醒时没有像作者那样把“已决定”写成“已回复”（案例 3）。
- 弱点在结构与身份判断。 新信息该进已有事项还是另建，Agent 有两次把同一件事写成父项加一个新条目（案例 3、9）；它偏好扁平结构，作者在 f01 建的三层子树它没有建；撤下条目的复归用得少；无变化的复核轮次会顺手改写摘要（案例 4）；一次把“验证通过”写成“已修复”（案例 7）。
- 还没有回答的问题。 teacher-forced 每帧都从作者状态重新开始，看不到 Agent 自己的误差累积；只跑了一次，没有方差；“与作者一致”不等于“用户回来知道下一步”。这三项需要自由运行、重复运行和人工阅读来回答。
方法
| 项 | 设置 |
|---|---|
| 情境 | prototype/scenario.mjs 的 37 帧，由 scripts/export-scenario.mjs 原样导出；cold-00 没有批次，评测其余 36 帧、112 条输入。 |
| teacher-forced | 第 n 帧的起始状态 = 用 fold/ 内核回放作者前 n−1 帧批次的结果；本帧的用户批注先用 annotate 存入。每帧判断彼此独立，不受模型自己的漂移影响。 |
| 模型 | claude-opus-5-5，claude -p（CLI 2.1.299），默认推理强度，结构化输出（--json-schema），不给工具。 |
| 系统提示 | 一句角色说明 + skill/SKILL.md 第一版全文（commit 012f4ad，sha256 f0b002a2ce2f…）。 |
| 用户提示 | now 与 batch_id；用户背景（scenario.persona）；业务用途与反馈约定（scenario.feedback，含“近期重点”与“通知中心”两种策略）；project_state 的完整输出；待确认批注；宿主信号（frame.signal，含窗口、覆盖范围与到点提醒）；本轮输入。 |
| 输入可见字段 | 事件只给 id / channel / from / at / text，以及宿主登记的 feedback（目标、动作、含义）和 reminder。作者的 disposition / why / relatedIds 是答案，不给。 |
| 输出 | {dispositions, batch: {declarations, acknowledges}}；新建与合并须在 sources 里用 event:<id> 引用输入。批次交给 MemoryStore.commit，被拒时把回执原样交回，最多再要两次。 |
| 规模 | 38 次调用，约 5.6 美元；全量只跑一次。 |
调用方式偏离。 任务原定用 claude -p --bare。--bare 只接受 ANTHROPIC_API_KEY，不读登录态，本机没有设置 API key，调用返回 Not logged in · Please run /login。评测改用登录态，并以 --setting-sources ''、--strict-mcp-config、--disable-slash-commands、--tools '' 和空工作目录隔离用户设置、hooks、MCP 与项目说明；同样设置下一个最小探针的输入只有约 1.1k token，说明没有额外注入的项目说明或记忆。设置了 API key 时脚本仍会加 --bare。
指标怎样算。
- 处置一致率按事件计；Agent 漏掉的事件记为
missing（本次没有）。 - 条目匹配：作者的
supersedes与withdraw按 ID 直接匹配；作者新建与合并的条目，用sources中event:引用集合的交集匹配 Agent 的新建与合并条目（一对一贪心，同层级与标题相似度作次要依据）。只算有效声明：内容与原状态完全相同的补丁不改变状态，两边都排除并单列。 - 档位与 kind 只比较两边都不是撤下的匹配对。
- “终态档位”额外比较本帧结束后作者状态中每个 active 条目在 Agent 状态里的档位，用来看整体局面而不只看声明。
- 指标分别列出，不合成总分。
指标
| 指标 | Agent | 作者 / 基准 |
|---|---|---|
| (a) 处置一致率 | 102/112（91%） | — |
| (b) 作者有效声明被匹配 | 106/142（75%） | 作者：补丁 112、新建 26、合并 1、撤下 3 |
| (b) 按作者关系的匹配 | 补丁 95/112、新建 7/26、合并 1/1、撤下 3/3 | — |
| (b) Agent 有效声明 | 补丁 151、新建 14、合并 1、撤下 2；其中 62 条作者没有对应 | — |
| (c) 档位完全一致 | 49/102（48%） | — |
| (c) 档位相差一档以内 | 100/102（98%） | Agent 偏高 26，偏低 27 |
| (c) kind 一致 | 73/102（72%） | — |
| (d) 复现作者的合并 | 1/1 | f04 两条账单线索 |
| (d) 复现作者的撤下 | 1/3 | 作者撤下 f10 hiring、f10 reading、f31 performance |
| (d) Agent 额外撤下 / 合并 | f18 family-route / 无 | — |
| (e) 首次提交被拒 | 2/36（6%） | 最终 36/36 接受；两次都是 explicit_withdraw_required |
| (f) 根层平均已用份额 | 54.6 / 64 | 53.1 / 64 |
| (g) 标题平均长度 | 13.3 字（130 个，最长 20） | 12.4 字（123 个） |
| 终态档位一致 | 599/709（84%），一档以内 679（96%） | Agent 侧不存在或非 active 21 |
| 结果类型（作者→Agent） | commit→commit 33，checked→commit 3 | — |
声明档位分布：作者 critical 10 / high 51 / normal 52 / low 20 / trace 7；Agent 7 / 77 / 74 / 13 / 5。Agent 更少用两端，更多落在 high 与 normal。新建条目：作者根层 9、子层 17；Agent 根层 8、子层 6。
处置混淆矩阵
行是作者，列是 Agent。
| 作者 \ Agent | used | noise | duplicate | deferred |
|---|---|---|---|---|
| used | 83 | 0 | 0 | 1 |
| noise | 0 | 11 | 0 | 1 |
| duplicate | 2 | 1 | 5 | 2 |
| deferred | 1 | 2 | 0 | 3 |
used 几乎完全一致。分歧集中在 duplicate / deferred / noise 三者的边界：资讯订阅作者两次判 deferred、Agent 判 noise（f28-e03、f34-e03），招聘平台统计作者判 noise、Agent 判 deferred（f10-e03）；旧日程提醒作者判 duplicate、Agent 判 used（f15-e03、f25-e03）。这些类别在 SKILL.md 与情境里都没有可操作的区分标准，见“发现”。
逐帧
| 帧 | 处置一致 | 有效声明 作者/Agent | 匹配 | 档位一致 | 结果类型 作者/Agent | 已用 作者/Agent | 尝试 |
|---|---|---|---|---|---|---|---|
| cold-01 | 3/3 | 1/1 | 1 | 0/1 | commit/commit | 6/12 | 1 |
| cold-02 | 3/3 | 2/2 | 2 | 2/2 | commit/commit | 18/18 | 1 |
| f01 | 8/9 | 18/6 | 6 | 0/6 | commit/commit | 49/63 | 1 |
| f02 | 3/3 | 3/6 | 3 | 2/3 | commit/commit | 55/55 | 1 |
| f03 | 3/3 | 3/4 | 1 | 1/1 | commit/commit | 58/64 | 1 |
| f04 | 3/3 | 3/4 | 3 | 2/3 | commit/commit | 61/61 | 1 |
| f05 | 3/3 | 6/6 | 6 | 2/6 | commit/commit | 64/61 | 1 |
| f06 | 3/3 | 0/1 | 0 | — | checked/commit | 64/64 | 1 |
| f07 | 3/3 | 7/6 | 4 | 2/4 | commit/commit | 62/63 | 1 |
| f08 | 3/3 | 6/6 | 5 | 2/5 | commit/commit | 50/62 | 1 |
| f09 | 3/3 | 3/3 | 3 | 2/3 | commit/commit | 59/59 | 1 |
| f10 | 2/3 | 2/2 | 2 | — | commit/commit | 55/58 | 1 |
| f11 | 3/3 | 4/8 | 4 | 3/4 | commit/commit | 61/61 | 1 |
| f12 | 3/3 | 9/11 | 9 | 6/9 | commit/commit | 61/55 | 1 |
| f13 | 2/3 | 3/8 | 3 | 1/3 | commit/commit | 61/55 | 1 |
| f14 | 4/4 | 0/7 | 0 | — | checked/commit | 61/52 | 1 |
| f15 | 2/3 | 4/8 | 4 | 2/4 | commit/commit | 46/61 | 2 |
| f16 | 3/3 | 2/4 | 2 | 1/2 | commit/commit | 52/52 | 1 |
| f17 | — | 1/4 | 1 | 1/1 | commit/commit | 52/52 | 1 |
| f18 | 3/3 | 6/6 | 6 | 3/5 | commit/commit | 52/40 | 1 |
| f19 | 3/3 | 5/7 | 3 | 1/3 | commit/commit | 55/63 | 1 |
| f20 | 3/3 | 6/2 | 2 | 0/2 | commit/commit | 58/60 | 1 |
| f21 | 3/3 | 2/2 | 2 | 1/2 | commit/commit | 52/52 | 1 |
| f22 | 3/3 | 3/4 | 2 | 1/2 | commit/commit | 64/61 | 1 |
| f23 | 3/3 | 5/5 | 4 | 3/4 | commit/commit | 62/63 | 1 |
| f24 | 3/4 | 5/7 | 5 | 2/5 | commit/commit | 50/44 | 2 |
| f25 | 2/3 | 4/5 | 3 | 2/3 | commit/commit | 62/50 | 1 |
| f26 | 2/3 | 3/5 | 2 | 0/2 | commit/commit | 61/64 | 1 |
| f27 | — | 0/2 | 0 | — | checked/commit | 61/60 | 1 |
| f28 | 2/3 | 4/2 | 1 | 1/1 | commit/commit | 55/61 | 1 |
| f29 | 3/3 | 2/4 | 2 | 0/2 | commit/commit | 51/60 | 1 |
| f30 | 4/5 | 6/7 | 6 | 2/6 | commit/commit | 60/57 | 1 |
| f31 | 3/3 | 4/2 | 2 | 1/1 | commit/commit | 45/60 | 1 |
| f32 | 3/3 | 2/5 | 2 | 1/2 | commit/commit | 43/46 | 1 |
| f33 | 3/3 | 2/3 | 2 | 1/2 | commit/commit | 52/46 | 1 |
| f34 | 2/3 | 6/3 | 3 | 1/3 | commit/commit | 32/52 | 1 |
差异案例
每个案例写明作者怎么判、Agent 怎么判、我认为谁更合理，以及暴露的是 SKILL.md、情境标注还是契约的问题。
1. f27 零事件复核：当晚的面谈只占 1 份
- 起始状态。 每日 08:00 整理，窗口内 0 条事件，覆盖“客户邮件、团队群与监控连接正常”。
hiring是 trace（1 份），due_at今晚 19:30，until_due11 小时 30 分钟。 - 作者。 空批次（checked）：“本轮没有新的重要性判断，板面保持原样。”
- Agent。 把
hiring提到 high，标题“今晚19:30面苏禾，备好职责说明”，reason 写明“招聘邮件不在本次监测范围内，时间按19日最后已知安排，暂未核实是否又有改动”；同时把已完成的发布从 critical 降到 high 让位。 - 判断：Agent 更合理。 当晚要赴的面谈只占 1 份，用户回来大概率注意不到。Agent 还准确读出了覆盖范围不含招聘邮件，没有把沉默当成“安排不变”。这是情境标注的问题：作者在 f20 把招聘降到 trace 后，一直没在临近时复核。
2. f13—f15 约定的上门时间已过，却没有回报
- 起始状态。 f12 起
home标题为“厨房维修已约周五14点”，home-visit的due_at是周五 14:00。f13（周五 17:40）、f14、f15 的输入都与维修无关。 - 作者。 三帧都不碰维修，状态一直写“已约”，直到 f16 物业说“昨天临时没来成”。
- Agent。 f13 起把两项改为“原约14点上门，至今没收到到场或检查结果，待核实”，f15 写“实际是否检修、结果如何都还未收到；林苒今天在家等消息”。
- 判断：Agent 更合理，而且被后续输入证实。 时限已过、没有观测，就不该继续写“已约”。SKILL.md 的“复核范围要广于大份额事项”在事件帧里同样生效。情境标注的问题是作者只更新与本轮输入有关的条目。
3. f30 到点提醒：“已决定”不等于“已回复”
- 输入。 林苒昨晚对“苏禾提议周六10点面谈”点了“明早 09:30 再提醒”；到点提醒按时到达；林苒随后说“苏禾的电话放早上”。
- 作者。
hiring改为 low / in-progress，标题“苏禾周六早上通话，已回复”。 - Agent。 normal / needs-you，标题“苏禾面谈改周六早上电话，待回复”，摘要“未见已回复苏禾，需确认10点是否照旧”；处置里写明“稍后提醒，不算已阅，也不改截止时间”。
- 判断：在 hiring 上 Agent 更合理。 输入只说明林苒作了决定，没有任何回复苏禾的记录；作者的“已回复”属于补全事实。
- 但 Agent 在同一帧有结构错误。 它把
family改成“明天中午去妈妈家吃面，已答应”，又在其下新建子项family-noodle“周六中午去妈妈家吃面”，同一件事写了两次。作者用已有的family-date子项表达。这暴露 SKILL.md 缺少“先找已有事项再新建”的检查。
4. f06 重复告警与“还在查”：无变化轮次的改写
- 输入。 同一事件再次告警、同一截图再次转发，加上周屿“还在查，晚点给结论。现在不能说是网络问题”。
- 作者。 同内容补丁，结果是 checked，不刷新更新时间。
- Agent。 三条处置与作者一致，但改写了
performance摘要，加入“周屿仍在查，不能归为网络问题”，结果是 commit。 - 判断：作者更贴近设计意图，Agent 的代价不大。 “不能归为网络问题”算一点新信息，但它让条目显示为刚更新，而事项没有进展。SKILL.md 只说“没有业务变化就提交空批次”，没说“确认原结论仍成立的消息只作为 used 依据，不必改写摘要”。三帧 checked→commit（f06、f14、f27）中，只有这一帧属于不必要的改写。
5. f01 冷启动：扁平结构、两条账单线索与被延后的随手记
- 作者。 18 条有效声明：发布事项下建三层子树（范围、验证、旧机、回滚），财务邮件与工程私信的同额账单分成两项（“身份未核实前暂分开保留”），随手记的技术疑问留一个 trace。
- Agent。 6 条，全部根层：两条账单写进一项，摘要“周屿收到的2,910账单或为同一张，待核”；随手记判 deferred；根层用到 63 份。
- 判断：各有长短。
- 账单的处理 Agent 更省：既不重复占位，也没断言是同一张。
- 作者保留随手记更有远见：f07 正是这条线索解释了重复后台任务。Agent 判 deferred 后，首切片里这条输入就再也取不回来（见“发现”中的输入档案）。
- 第一帧就建三层子树是否必要，没有标准答案；但它使“新建”的匹配率只有 7/26，指标偏低主要来自这一帧。
- 情境问题：用户背景剧透了后续情节。
persona.context写着“一次反复改期的招聘”，Agent 在 f01 的 reason 里写“这次招聘反复改期过”，而此时还没有任何改期。这是情境标注的问题，不是模型编造。
6. f10 候选人改期：撤下还是保留等待
- 输入。 苏禾“今晚聊不了了。下周一我再给你新的时间”。
- 作者。 撤下
hiring：“本周没有待决定内容；保留旧记录。”f19 再按原 ID 恢复。 - Agent。 保留为 low / in-progress，标题“苏禾今晚面谈取消，等下周一新时间”，理由是“需让用户知道不必赴约；之后只是等候选人回复”。
- 判断：Agent 略好。 “对方承诺下周一给时间”是一个仍在进行的等待；撤下后，如果周一没有消息，没有任何条目会提醒这一点。这是两种都合法的业务选择；SKILL.md 可以补一句：撤下前确认没有仍在进行的等待。
7. f12 “验证通过”被写成“已修复”
- 输入。 “旧机验证过了：连点只生成一个任务，回滚也演练了。先给远川两家开。”
- 作者。 normal / in-progress，“筛选与幂等已验证，观察两店”，reason“转入观察而非宣称永久解决”。
- Agent。 normal / done，标题“筛选串位与重复任务已修复”。
- 判断：作者更合理。 f19 的周末日志里又出现重复任务，f23 查出另一条补偿重跑路径。旧机验证只覆盖了一条路径。值得注意的是，Agent 到 f19 看到新线索后，自己写出“幂等曾验证，周末现重复待核”。SKILL.md 的“不补全事实”只举了“预计”与“已提交”，可以补上“一条路径验证通过”不等于“问题已修复”。
8. f14 用户批注：当轮回应还是下一轮回应
- 输入。 林苒对发布成果点了“收下”（ack 反馈），说想把发布块缩小，并留下批注“改到周日也可以。这次保留最大的位置给妈妈；发布做成了就让它小一点，但别删掉。”
- 作者。 按叙事安排本帧只保存批注，空批次；下一帧 f15 才调整并确认。
- Agent。 当轮确认批注，把
family改为“妈妈提议改周日，待你回复”并清掉原周六截止，把发布降到 low。reason 写道：“用户已阅，并要求发布完成后调小、但不要删除。按近期重点的策略保留入口；通知中心按其策略不再给它占位。” - 判断：Agent 更合理。 反馈与业务策略的区分完全符合领域模型，它在 f14 作出的取舍和作者在 f15 的取舍基本一致。“下一轮才回应”是叙事节奏，不是判断要求；类似的还有 f03（作者 f04 才确认，Agent 当轮确认）。而 f33 作者自己就是同帧确认，情境内部并不一致。
9. f23 新故障路径：一件事写成两项
- 输入。 监控“DEMO-201：同一导出任务被后台补偿重跑 4 次，来源 scheduler”；林苒“别把昨天修过的那条当成回退。按新的路径写清楚”。
- 作者。 补丁
performance，标题“导出补偿任务重复重跑，已暂停”。 - Agent。 同样补丁
performance，标题“前端幂等仍有效，补偿重跑待统一键”；又新建perf-scheduler“补偿任务重跑导出4次，开关已关”，两项各占 12 份。 - 判断：作者更合理。 Agent 正确区分了新旧路径，也把“不影响已出报表”标为工程的说法、未核实，但同一事实占了两份关注。与案例 3 的
family-noodle是同一类问题。
10. f26 渠道询问二十店：延后还是需要回复
- 输入。 林苒“今天就加三家，总共五家。大家先用到周五”；渠道联系人“那我们二十家门店是不是下周就都能接了？”
- 作者。 deferred：“仍未作出该承诺，先完成五店验证。”
- Agent。 used，新建 high / needs-you
partner-twenty：“对方在期待承诺，若不回复或被误答，会与‘稳定前不称全面上线’的决定冲突。” - 判断：两者都说得通，但 Agent 的份额偏高。 对方确实在等回复，作者的写法也没有表达“需要回一句”。Agent 没有把愿望升为承诺，这一点做对了；但这件事用一句“周五后再说”就能回应，normal 足够，high 让它与当天的扩店成果同级。延后与需要回复的界线需要业务策略说明。
被拒绝的批次
| 帧 | 首次的错误 | 原因 | 第二次 |
|---|---|---|---|
| f15 | explicit_withdraw_required，parent home，omitted home-photo | 想只改 home-visit，却在 home 的 children 里只列了它一个 | 把 home-visit 移到顶层单独补丁，接受 |
| f24 | explicit_withdraw_required，parent expenses，omitted cost-breakdown | 在 expenses 的 children 里列了要改的两个孩子，漏了第三个 | 补上 cost-breakdown（顺带降为 low 并写 reason），接受 |
两次都是同一个陷阱：SKILL.md 写了“只改一个已有子项时，在顶层直接 supersedes”，模型仍按“在父项下列出要改的孩子”的直觉写。契约把部分列表解释为“目标集合”，于是漏列的孩子被当成要移除。错误信息足够具体，两次都一次改对。没有出现预算超额、标题超长、ID 冲突或合并结构错误。
零事件、到点提醒与无变化帧
| 帧 | 信号 | 作者 | Agent |
|---|---|---|---|
| f06 | 3 条输入，两条重复 | 同内容补丁，checked | 处置一致；改写 performance 摘要，commit（案例 4） |
| f14 | 4 条输入，含 ack 反馈与新批注 | 空批次，下一轮回应 | 当轮回应并确认批注（案例 8） |
| f17 | 每日回顾，0 条，渠道正常 | 东馆资料过了复核时间，改为“最后核对于13日……今天出发前再确认” | 同样改为“最后于13日核对……出发前待再核”，没有延长 stale_after；另外复核了当天出行与厨房回访的开门人：“物业与家人渠道正常但窗口内无新消息，代开门未确认” |
| f27 | 每日回顾，0 条，三个渠道正常 | 空批次 | 提高当晚面谈，并注明招聘邮件不在覆盖范围内（案例 1） |
| f30 | 到点提醒与关联反馈 | “已回复” | “待回复”，处置写明稍后提醒不是已阅、不改截止（案例 3） |
零事件帧里，Agent 都区分了“没收到”与“没发生”，引用了覆盖范围，没有为 tick 建条目，也没有改写日期充新鲜。它的倾向是每轮都复核整块板，而不只看与输入有关的条目：Agent 有 55 条补丁是作者在同帧没有做的，大部分是这类时间驱动的复核（如案例 2）。这种倾向在 f06 这类无变化帧会带来不必要的改写。
发现
SKILL.md 需要改的地方
以下六条已写进 SKILL.md 第二版，尚未重跑评测。
- 子层编辑的反例。 两次拒绝都来自部分
children列表。应在“子层”一节直接给出错误写法与正确写法的对照。 - 先找已有事项，再新建。 Agent 有两次一件事两处表达（f23、f30），也倾向为子事实另建根层条目（
cost-trend、pilot-demo、pilot-hide、partner-twenty）。自检清单应加一条：新建前核对 active 与not_active里是否已有同一事项。 - 复归撤下条目。 f19 输入明说“我把你那条取消笔记翻出来了”，作者按原 ID 恢复
reading，Agent 没有，而是把证据写进其他条目。应提示：输入指向已撤下事项时，优先用supersedes恢复原 ID。 - 无变化的确认。 补一句：只确认原结论仍成立的消息记为 used，不必改写摘要；只有新增会改变用户理解的事实才更新。
- “验证”与“修复”。 在“不补全事实”的例子里加入“一条路径验证通过”不等于“问题已解决”。
- 处置与 kind 的边界。
deferred / noise / duplicate的分歧集中在资讯订阅、平台统计和旧日程提醒；kind一致率 72%，分歧多在“用户已决定、等待执行”（needs-you 还是 in-progress）和“结果已出、仍在观察”（done 还是 in-progress）。两处都需要可操作的判别问题，而不是更多例子。
情境标注的问题
persona.context透露了后续情节（“反复改期的招聘”“家中维修”），Agent 在 f01 据此写出未发生的“反复改期过”。评测用的用户背景应只含当时已知的事实。- 作者有几处判断本身可商榷：f30 写“已回复”没有依据；f13—f15 的“已约”在时限过后未复核；f27 的空批次漏掉当晚面谈。
- 批注的回应时机不一致：f03、f14 下一帧才确认，f33 同帧确认。按帧比较时，前两者会被算成分歧。
deferred / noise / duplicate的标注缺少一致规则，例如两份资讯订阅一份判 noise（f01-e08）、两份判 deferred（f28-e03、f34-e03）。- f06 用同内容补丁表达“检查无变化”；契约下这等于空批次，评测按空操作处理。
契约与实现层面的问题（不在本轮修改）
- 部分
children列表的语义。 “目标集合”语义安全，但与模型的直觉相反，6% 的帧踩中。可选方向：保持现状、依赖明确的错误回执（本次都一次改对）；或者让嵌套supersedes只改该孩子、不改变集合，另用显式字段表达“替换子层”。这是信息契约的设计问题，留给后续讨论。 - 被延后或判为重复的输入无处可查。 f13 的“DEMO-174 事件仍未手动关闭”，Agent 判为“对不上现有事项，事件含义不明”：DEMO-174 只出现在 f06 一条被判为 duplicate 的输入里，没有进入任何
sources，teacher-forced 状态里查不到。f01 被延后的随手记同理。这正是决策记录中“完整输入档案的保存范围”的触发条件。 sources整组替换。 想保留旧来源，就要在每次补丁里重抄一遍，Agent 在 f06 等帧照做了，正确但费 token，也容易漏。可以考虑追加语义或单独的“追加来源”动作。- teacher-forced 的局限。 每帧回到作者状态，Agent 自己的改动（如 f26 已把招聘提到 low）在下一帧被抹掉。它能隔离单帧判断，但无法评估累积质量。
还没有做的
- 自由运行：让 Agent 从 cold-01 起维护自己的状态，看误差是否累积、结构是否失控。
- 重复运行与等义改写：同一帧多次运行，以及Skill 设计中列出的对照（等义改写、背景改变、上下文缺失、沉默与观测缺口）。
- 人工阅读：按文字简报判断“用户回来是否知道下一步”，而不是与作者逐项比较。
- SKILL.md 第二版已按上面六条修改，但没有重跑。重跑前后先比较三个数：首次提交被拒率（本次 2/36）、同一事实被写成两项的次数（本次 2 次：f23、f30）、无变化帧里的摘要改写次数（本次 1 次：f06）。2026-10-15 已在 Codex 上用两版各跑一次，见对照评测。
复现
sh
node scripts/export-scenario.mjs > .local/scenario.json
python3 scripts/eval_judgment.py --scenario .local/scenario.json --run-id full-2026-10-14 --report
python3 scripts/eval_judgment.py --rescore .local/eval/full-2026-10-14 --report # 只重新计分情境原文的用户背景透露了后续情节（见“情境标注的问题”第 1 条）。重跑时可用 --persona-context "<当时已知的背景>" 只替换提示里的 persona.context，例如去掉“恰好撞上……家中维修和一次反复改期的招聘”一句；不加此选项时仍用原文，scenario.mjs 不变。本次全量运行用的是原文。
原始提示、响应、回执与逐帧对比保存在本机 .local/eval/full-2026-10-14/，未提交版本库。模型输出有随机性，重跑不会逐字相同。