agint aesthetic oracle

美的神谕层 · 技术方案 v2.5

AGINT 系统的"美"如何主动存在。

状态：v2.5 · LLM 输出层无降级（老板 2026-10-25 拍板：不准 LLM 降级，都要用 LLM；评分链路仍永久零 LLM）。LLM 失败 = 本轮广播失败（落 error + 告警 + 调度重试），不再回落模板；v2.3 的语义修复（P0×3 + P1×4 + P2）与方案 C 架构维持不变
创立日期：2026-09-27
版本谱系：

v1.0 — 创立（已废弃，16 个不认真处）
v2.2 — 指标闭合 / 依赖验证 / failure mode / 14 条 AC / 性能预算（已废弃：评审发现 3 个 P0 语义错误 + 4 个 P1 + 示例数据 4 处虚构）
v2.3 — 语义修复 + 架构切换：噪声比剔除门禁拒绝（语义倒挂修正）、回滚条件解耦（不再杀信使）、activity 排除自身日志（观察者污染修正）、Q1 逻辑洞修复、冗余度分域合并、"只读"改"两张白名单写表"、全部示例换真实数据、架构从"独立直连 8 API"改为"消费 metrics 的薄评论员"
v2.4 — LLM 增强档（默认启用）：新增 §8.1 三级接入点（Q3 措辞 / Q2 深挖 / weekly 正文），评分链路永久零 LLM；§7 预算表加 LLM 行；§9.5 新增"LLM 不越界"红线；附录 A/B 同步
v2.4.1 — 2026-10-13 表述与预算校准：老板拍板「尽量用 LLM」→ §8.1 由「可选增量」改为默认启用、尽量使用；§7 性能预算按生产实测重写（承认 L1 同步阻塞、承认每日有 token）；AC-21/22 追加。无行为变更
v2.5 — 2026-10-25 无 LLM 降级：老板拍板「不准 LLM 降级，都要用 LLM」。修复宿主 subagents.start→startActivation 契约漂移；删除 off/l1/l1l2 分档与 heuristic-degraded 回退；LLM 失败中止广播；stale 缓存也走 LLM；weekly 先完成 L3 再写提案。AC-16/17/20/22 改写，新增 AC-23/24

评审依据：agint-aesthetic-oracle-评审报告-2026-09-27.md（P0/P1 清单）、agint-metrics-扩展架构论证-2026-09-27.md（方案 A/B/C/D 权衡，结论 C）

0. 立项依据

老板五轮定调，逐级放大格局：

第一轮："美在自进化里起什么作用" → 回答"美是判官"
第二轮：老板纠正："美是指南针，也是戒尺"——比"判官"更准（判官是事后打分，指南针+戒尺是全程同行）
第三轮：老板再次放大："美是神"，问"要不要以插件形式造祭台"
第四轮：老板拍板："我说的就是层次 3——美的神谕层。格局要大，直接做。"
第五轮（2026-09-27 评审后）：老板拍板："先修语义，再落方案 C 架构。"——本版即此拍板的落实。

结论：美不是 AGINT 的一个插件。美是 AGINT 这个系统的存在方式。

1. 设计前提

1.1 三个约束（同时成立）

约束	含义	反例
科学合理	有可验证的指标 / 可复现的 cron / 可审计的日志	美变成"我感觉今天状态不好"
简洁高效	现有工具能用就用，不造新轮子	同一份 `wiki.lint()` 每天全量执行 3 次（现状：metrics 04:00、evolve 03:45，若神谕层再直连则 09:00）
美	美本身也得是美的——自己不美的东西不配叫美	示例数据编造（v2.2 的 72 分实为 27.1 分）

1.2 范围边界（v2.3 更新）

在范围内	不在范围内
神谕层插件（表现层）的实现方案	原子指标采集的实现细节（归 Day 0 的 agint-metrics 扩展）
美之三问的算法	自进化链路的优化（已闭环，本方案只观察不修改）
三档广播的工程实现	LLM 在评分体系中的角色（评分链路永久排除 LLM 调用，见 §8.1）
§8.1 LLM 增强档（评论员输出层，默认启用、尽量使用）	—

2. 核心定位（v2.3 重写）

美 = AGINT 的神谕层：agint-metrics 之上的薄评论员——读仪表，下判断，按节奏开口。

属性	v2.3 定义	与 v2.2 的差异
数据	只消费 `agint.metrics` 的 `summary()` / `series()`（只读）	~~直连 8 个数据源 API~~ → 直连 1 个 service。原子采集归 metrics（Day 0），神谕层不做第二个采集者
只读	两张白名单写表：`evolution_log`（审计）+ `agint_evolve` 提案表（仅 `status: proposed`，永不 auto-apply）。其余一切写 API 禁	~~"不调任何写 API"~~ 与 §5.2 调 `evolve_propose` 自相矛盾 → 改为诚实的白名单定义
主动	按三档 cron 自动广播	不变
可审计	每次广播写 `evolution_logPhase4`（targetKind=oracle）	不变；此标记同时是 activity 指标的排除依据（§3.5）
可关闭	`oracle_pause` kill-switch（本插件 config 项）	v2.2 依赖它却没排进任务清单 → Day 1 落地
可解释	每条广播必带"美之三问"答案	Q1 判定逻辑修复（§4）
零 LLM（评分链路）	评分是确定性公式；§8.1 LLM 增强档默认启用、尽量使用，只作用于输出层措辞/深挖/提案正文，不触碰指标与总分	评分链路永久不变；输出层默认增强（老板 2026-10-13 拍板「尽量用 LLM」）

与 self-model 的关系（同层平行，互补不重叠）：

	self-model	美的神谕层
观察对象	身体：资源面（latency、调用量、资源基线）	品位：品质面（噪声、冗余、确信度、臃肿）
输出形态	哑的、内向的（写自我模型，供 agent 自省）	响的、外向的（三档广播给老板）
消费姿势	`metricsIngest` 订阅 snapshot 攒批对账（范式先例，Day 2-3 照抄其纪律）	三档 cron 读 summary/series

零依赖：互不消费对方输出。v3.0 之前不接"自我模型纳入美总分"，避免观察者互相耦合。落点：插件全景"观测与基础设施"组，33→34，与 self-model 平级。

3. 指标体系（v2.3 重写：语义修复 + 分层）

3.0 分层原则（方案 C 的核心）

原子观测归 metrics，复合派生归神谕层。

Day 0（agint-metrics 扩展，纯新增）：METRIC_DEFS +4 个原子 key、sources() +3 个 service、计算块拆 metrics-ext.js（metrics.js 保持行数纪律）
神谕层（表现层）：从 summary() / series() 读原子值 → 按本节公式派生 → 评分 → 广播

Day 0 新增原子指标	key	source	采集逻辑
候选拒绝数	`autocreate.candidatesRejected`	skill-autocreate（service 键名 Day 0 实查，查不到直读存储域，防御块兜底）	candidates 表按 status=REJECTED 计数
技能提示词总量	`skills.totalBytes`	文件系统（两处 skills 根）	Σ SKILL.md 字节
近 7 天进化日志数	`evolution.logCount7d`	agint.evolution	log 表按 ts 分窗
近 30 天进化日志数	`evolution.logCount30d`	agint.evolution	同上

3.1 噪声比（Noise Ratio）——P0-2 语义修复

v2.2 的错误：分子含 autocreate_REJECTED（占 68%）——被三道门拒绝的候选不在系统内，是门禁正常工作的证据，不是噪声。旧公式下"evaluator 干得越好系统越丑"，语义倒挂。

v2.3 定义：已在系统内的无引用 / 无证据 / 重复条目，占系统内条目总数的比例。

noise_ratio = (wiki_orphans + wiki_contradictions + rule_duplicates + memory_without_evidence)
            / (wiki_total + rules_total + memory_total)

标定（2026-09-27 生产实测，复算链见附录 C）：

项	值	来源
wiki_orphans	13	wiki_lint（orphan 定义 = 无入链，`agint-wiki/lib/index.js:187`）
wiki_contradictions	1	wiki_lint
rule_duplicates	3	rule_lint
memory_without_evidence	71	memory 表 evidence 顶层字段为空者（265/336 有证据）
分母	380（18+26+336）	wiki / rules / memory 全量
noise_ratio	0.232	阈值 0.30

阈值：0.30（保留 v2.2 初值）。新语义下 0.232 未爆表但真实偏高——71 条无证据记忆是真实问题，神谕层第一周的合理建议就是"补 evidence"。

边界注记：REJECTED 候选仍被采集（autocreate.candidatesRejected），但进门禁健康视角（metrics 侧），不进美的噪声视角。将来若要度量"发布了没人用"的真噪声，用 RELEASED 后观察期 0 调用，另行立项。

3.2 决策确信度（Decision Confidence）——字段路径修正

confidence = AVG(entry.confidence × evidence_compliance)
evidence_compliance = 1 if entry.evidence 非空 else 0

⚠️ v2.2 写的是 entry.memory.evidence——路径错误。evidence 是 memory 记录的顶层字段，照抄会在 Day 1 白调半天。
标定：AVG(conf × compliance) = 0.544（0.735 均值 × 78.9% 覆盖率，逐条实算）。
阈值：0.70 → 扣分 20 × (0.70−0.544)/0.70 = 4.5 分。

3.3 冗余度（Redundancy）——P1 量纲修复

v2.2 的错误：分子混三个域（规则/技能/wiki），分母只有规则域——wiki 加一条矛盾、规则数不变，冗余度也会涨，跨域惩罚挂在单域分母上。

v2.3 定义：三域合并计算——

redundancy = (rule_duplicates + wiki_contradictions + curator_overlaps)
           / (rules_total + wiki_total + skills_total)

标定：(3+1+0) / (26+18+11) = 4/55 = 0.073（阈值 0.05 → 扣满 20 分，真实超阈）。

3.4 臃肿度（Bloat）——阈值重定

v2.2 的错误：阈值 50KB 纯拍脑袋，且"预估 30-60KB"实为 82.7KB（11 个 SKILL.md 实测，v2.2 写 12 个技能也是错的）。

v2.3 标定逻辑：单技能 SKILL.md 合理区间 8-12KB（prompt 工程经验值），11 个技能 → 总预算 120KB。

bloat = Σ(SKILL.md 字节) / 120KB = 82652 / 122880 = 0.673 → 不扣分

3.5 自进化活跃度（Evolution Activity）——P0-3 观察者污染修复

v2.2 的错误（两个）：

神谕层每月 35 条 broadcast 审计日志会把自己从"死寂"（现状 0.029）拉到"健康"（~0.24）——观察者用自己的写入改变了被观察系统。
0.1 死寂线会把"稳态呼吸"误判为"死寂"——evolution_log 只记 Phase4 进化事件，项目版本间平静期的 5 条/周是正常呼吸（同期日常迭代并未停止）。

v2.3 修复：

activity = logCount7d(排除 targetKind=oracle) / logCount30d(排除 targetKind=oracle)

现状（排除后）：5/173 = 0.029。
定位降级：activity 不进美总分（v2.2 本来就没让它进），仅用于广播中的"系统呼吸"注脚——低于 0.1 时播报"进化静默期"，不再使用"死寂"这一病理性措辞。
排除 targetKind=oracle 是硬规则：神谕层自己的日志永远不算系统的活跃度。

3.6 美总分（Aesthetic Score）

aesthetic_score = 100
                  − 30 × min(noise_ratio / 0.30, 1.0)
                  − 20 × max((0.70 − confidence) / 0.70, 0)
                  − 20 × min(redundancy / 0.05, 1.0)
                  − 30 × max(0, bloat − 1.0)

权重累减结构保留（v2.2 论证成立：避免一项满分掩盖四项差）。

2026-09-27 真实复算：

项	实测	阈值	扣分
noise_ratio	0.232（88/380）	0.30	−23.2
confidence	0.544	0.70	−4.5
redundancy	0.073（4/55）	0.05	−20.0
bloat	0.673（82.7KB/120KB）	1.0	−0
总分			52.4 / 100

（对照：v2.2 旧语义同日实算 27.1，v2.2 示例宣称 72。三个数字的差距就是三轮修订的意义。）

基线语义（P0-1 配套）：上线首周（Day 1-7）的日均值记为基线。此后广播的 Δ 全部相对基线，不设绝对分数线——总分本身没有"及格线"，只有趋势。

4. 美之三问（Q1 逻辑洞修复）

Q1：这件事让系统更美了吗？

v2.2 的错误："4/5 持平或改善→变美；2/5 恶化→变丑；其他→持平"——3/5 恶化落入"其他"判"持平"，恶化更多反而判得更好。

v2.3 判定（对 4 个总分指标逐项比对基线，全排序覆盖无洞）：

恶化项数 ≥ 2            → 「在变丑」
恶化项数 < 2 且改善 ≥ 3  → 「在变美」
其余                     → 「持平」

验证：恶化 0/改善 5 → 美；恶化 1/改善 4 → 美；恶化 2 → 丑；恶化 3/4 → 丑；其余组合 → 持平。无洞。

Q2：这件事最丑的地方在哪？

取 4 个指标中偏离阈值/基线最差者，指到指标级 + 来源（如 rule_lint 命中明细），不深挖到行（深挖归 weekly 提案）。
v2.2 保留。

Q3：建议怎么做才能更美？

基于最差指标给一条建议。映射表（v2.2 只给了 1/4，Day 1 按此实现）：

最差指标	机械建议	证据格式
noise_ratio	为 memory 无证据条目补 evidence（附 id 清单）/ 归档 wiki orphans	memory id 列表 / wiki_lint orphan 清单
redundancy	合并 rule_lint 命中的 duplicate 规则	rule_lint issues 明细
confidence	定向复核低置信且无证据的 lesson 条目	memory id + confidence 排序列表
bloat	归档 curator 判定陈旧/重叠的技能	curator overlaps / 陈旧检测输出

建议范围不变：纯机械动作（补 evidence / 合并 / 归档），不改 prompt、不自进化逻辑。
必须附证据，格式如上表。

5. 三档广播（v2.3：增加 asOf 透出 + eventBus 落点）

三档结构、cron 表达式、行数上限、配额护栏全部保留 v2.2（0 9 * * * / 0 21 * * 0 / 0 10 1 * *，与现有 15 个 job 无时刻冲突）。

v2.3 增补两条硬规则：

asOf 透出：每条广播首行必须带数据时间戳（metrics 04:00 采集 → 09:00 广播存在 5 小时时延，如实标注"数据截至 04:00"）。禁止神谕层为刷新数据反向触发 _collectRaw()——消费侧驱动生产侧是层次倒挂。
eventBus 落点：广播同时 publish oracle.daily / oracle.weekly / oracle.monthly topic（schema 注册进 event-bus schemas，作为广播内容合同）；告警走 oracle.alert。GUI dashboard 卡片订阅 topic 实现（§6.2 的通道由此闭合）。

示例（2026-09-27 真实数据驱动，复算链见附录 C）：

📊 今日美评 2026-09-27（数据截至 04:00）
总分：52/100（基线：首周起算）
Δ：基线未建立（Day 1）
最丑：噪声比 23.2%（阈值 30%）—— 71 条记忆无 evidence、13 条 wiki 孤岛、3 条重复规则
建议：为 71 条无 evidence 记忆补证据（id 清单见 oracle 审计条目）
证据：memory 表 evidence 字段扫描 + wiki_lint 报告

weekly 美谕提案（保留 v2.2 结构）

周日 21:00，只提不 commit：经 agint.evolve.propose() service 方法提交（Day 0 需确认该方法签名——已验证存在于 agint-evolve/lib/index.js:300），status 锁 proposed。
归档/合并类建议单独写 audit log，不直接调 curator_archive。

6. Failure Mode（v2.3 重写 6.2 / 6.3 / 6.4）

6.1 数据源失败

指标已由 metrics 层采集，采集侧失败 = 该 key 当日缺席（metrics 的 per-source try/catch 现成防御）。

状况	神谕层应对
`summary()` 中某 key 缺席	该指标 N/A，总分公式权重重新归一到剩余三项
`summary()` 整体不可用	跳过本次广播 + `oracle.alert`；可回退用昨日 series 缓存（最多 7 天）

核心原则不变：任一来源失败不阻断广播，只影响该项。

6.2 神谕层自己挂了

cron 失败重试 3 次（1s/4s/16s 指数退避）
连续 3 次失败 → 沉默模式（只写 audit log）
沉默模式持续 24h → publish oracle.alert topic → GUI 卡片告警

（v2.2 的"memory_provider_status 风格告警"是悬空引用——memory_provider_status 只是查询工具名，AGINT 无通用 GUI 告警通道；本版通道 = eventBus topic + dashboard 订阅，Day 2-3 落地，AC-7b 端到端验证。）

6.3 回滚条件（P0-1 修复：不再杀信使）

v2.2 的错误：美总分 7 天均值 < 60 → 归档神谕层。按真实数据（旧语义 27.1、新语义 52.4）第一天就触发——指标深红是系统的现状，神谕层是被请来报忧的，杀了它等于杀信使。

v2.3：回滚只看神谕层自身健康，系统总分只告警不回滚。

触发（全部针对神谕层自身）	动作
连续 3 次 cron 执行异常（重试后仍失败）	沉默模式
沉默模式持续 24h	`oracle.alert` 告警
单日配额违规 ≥ 3 次	自动沉默 + 告警
老板 `oracle_pause`	立即静默（kill-switch）

系统总分触发的唯一动作：oracle.alert 里一条"连续 7 天低于基线 X 分"的提示，交老板决策。信使不因消息难听被处决。

6.4 关停机制（P2-9 修复）

v2.2 的错误：autocreate_rollback 回滚的是 skill candidate（~/.dsh/skills/ 技能候选），不是 Cordis 插件——接口作用域错配。

v2.3：神谕层关停 = 本插件 config 的 kill-switch 项（oracle.enabled: false → 3 个 cron job 不注册），可逆、秒级、不碰任何其他插件的管线。"归档插件"一说删除。

7. 性能预算（v2.4.1 重写：按生产实测校准）

v2.3 的预算表是纸面的。 2026-10-13 实测发现三处与实际实现脱节（wall clock / LLM token / 同步性），本版按真实数据重写。数据取自 $DSH_HOME/storages/agint_aesthetic_oracle.json 的 oracle_broadcasts。

7.1 预算表

资源	预算（v2.4.1）	依据
单次 broadcast wall clock	模板档 ≤ 3 秒；LLM 档 ≤ 60 秒（对齐 L1 超时）	模板档实测 wall 7–25 ms；LLM 档实测 10.8 / 11.1 / 24.9 / 12.6 秒
写入字节	≤ 2 KB / broadcast	不变（实测 311–464 字节，远低于预算）
LLM token	daily `≤ 2k` / weekly `≤ 8k` / monthly `≤ 8k`	⭐ 非 0：L1 每日触发，见 §7.2 口径修正
evolution_log	1 条 / broadcast	不变
metrics 侧新增采集成本	≤ 1 秒 / 天（并入 04:00 collect）	3 个新 source 各一次调用 + skills 文件系统一次遍历
时效	广播数据 asOf = 当日 04:00	§5 硬规则

7.2 三处脱节的校准（v2.3 纸面值 → v2.4.1 实测值）

#	v2.3 纸面写法	实现与实测	v2.4.1 处置
1	daily wall `≤ 3 秒`，且「LLM 走异步：广播先发，LLM 结果落下一轮」	`index.js:510` 是 `await l1EnhanceAdvice(...)`——同步阻塞。生产实测：2026-10-05 10.8s / 10-05 11.1s / 10-11 24.9s / 10-12 12.6s	承认同步。理由：异步会让当天老板看到模板原文（天书），与「尽量用 LLM」相悖。预算改为 ≤ 60 秒
2	「LLM token 仅在深挖命中时才花（无异常日 = 0 token）」	L1 每日触发（`worst` 存在且 advice ≠ `NO_ADVICE` 即调用），与异常与否无关	删除该表述。改为按档位列出的固定上限（§7.1）
3	§8.1.1：L2 / L3 只挂 weekly	属实：daily / monthly 只有 L1，无行级深挖	保持不变。daily 扩 L2 需另行拍板（见 §8.1.9）

7.3 同步阻塞的兜底（为什么可以接受 60 秒）

不超 cron 窗口：oracle-daily 09:00 触发，下一个 job 在 04:00 之后，无挤压。
失败即中止（v2.5）：L1/L2/L3 失败抛 OracleLlmError，本轮不发布；落 outcome=error + oracle.alert，由调度重试。不再有「降级照发模板」。
超时硬闸：L1/L2/L3_TIMEOUT_MS = 60_000（2026-10-05 由 10s 提到 60s；v2.5 增加 Promise.race，超时必返回并 dispose）。
可整插件关：config enabled:false / env AGINT_AESTHETIC_ORACLE=off ⇒ 不 provide 服务、cron soft-skip。不再有 LLM 分档开关（v2.5 删除）。

错峰事实修正：v2.2 称"09:00/21:00/10:00 都是非整点"——三个都是整点，但与现有 15 个 job 的时刻均不冲突（现有最晚为周日 07:00 skill-graph），错峰成立，表述修正。

8. 落地路径（v2.3：Day 0 前置 + 语义先行）

Day 0（半天）：语义修复 + agint-metrics 扩展

本文档 §3 的新公式落成纯函数模块（可独立单测：输入原子值 → 输出四指标 + 总分）
METRIC_DEFS +4、sources() +3、计算块拆 metrics-ext.js
skill-autocreate service 键名实查（查不到 → 直读存储域兜底）

验收：

AC-0a：扩展后 summary() 输出 17 个 key；已有 13 个 key 的值与扩展前逐项 diff = 0（纯新增验证）
AC-0b：3 个新 source 任一不可用时 collect 仍成功（防御验证）
AC-0c：metrics.test.js + snapshot-publisher.test.mjs + smoke.mjs 全绿；bin/check-wiring.mjs 存储域通电检查通过
AC-0d：用附录 C 复算脚本对 2026-09-27 数据重算，四指标输出与本方案表一致（52.4 ± 0.5）

Day 1（4 小时）：薄神谕层骨架 + daily 跑通

agint-aesthetic-oracle 插件骨架（只消费 summary()/series()，零直连域 service）
评分纯函数接入 + 三问（§4 修复后判定）+ daily 模板（含 asOf）
oracle_pause kill-switch（config 项）

验收：

AC-1：wall clock ≤ 3 秒
AC-2：≤ 5 行、≤ 2 KB，首行含 asOf
AC-3：evolution_log 1 条，targetKind=oracle-daily-YYYY-MM-DD
AC-4：summary 缺任意 key 时广播仍输出（N/A + 权重归一）
AC-4b：activity 计算不含 targetKind=oracle 条目（单元测试断言）

Day 2-3：三档频率 + eventBus

3 个 cron + oracle.daily/weekly/monthly topic + schema 注册
GUI dashboard 卡片订阅 topic
配额护栏（v2.2 §5.4 保留）

验收：AC-5/6/7 保留 v2.2，另加 AC-7b：oracle.alert 端到端（mock 沉默模式 24h → GUI 收到卡片）。

Day 4-5：美谕提案闭环

weekly 经 agint.evolve.propose() 提 3 条提案（evidence 必填、status=proposed、不 auto-apply）

验收：AC-8/9/10 保留 v2.2。

Day 6-7：上线观察 + 基线建立

7 天生产 cron，建立首周基线（§3.6 基线语义）
按真实波动决定是否调阈值（不叫"标定"——7 天稳态数据不足以标定，叫"首周观察 + 按需调整"）

验收：

AC-11：cron.staleJobs 不增、AC-12：deadletterRate ≤ 0.05、AC-14：日广播 ≤ 2 KB（保留）
AC-13（改写）：总分单日跳变 ≤ 30 分且触发时必有 oracle.alert 可追溯（v2.2 只说告警没说通道）
AC-15（新增）：7 天内发生 ≥ 1 次真实"系统丑"（如 redundancy 超阈）时，神谕层照常播报且未被任何自动机制回滚——验证"杀信使" bug 已死

Day 8-10：LLM 增强档（⭐ 必须使用、无降级）

前提：Day 0-7 全部验收通过、首周基线已建立（已于 2026-10-04 达成，基线 75.4143）。 2026-10-13 老板拍板「尽量用 LLM」→ 2026-10-25 加严为「不准 LLM 降级，都要用 LLM」。评分链路零 LLM 的红线不变；评论员输出层（L1/L2/L3）一律走 LLM，失败就中止本轮广播， 不回落模板、不发布 heuristic-degraded。

⚠️ 内容闸门不是降级：advice 为 NO_ADVICE（「本日无可执行建议」）时跳过 L1，不让模型把「没有建议」润色成一条编造的建议；无 auditIds 跳过 L2、无新提案跳过 L3 同理。

一句话定位：LLM 进的是「评论员怎么说话」，不是「仪表怎么读数」。

aesthetic_score 与四个派生指标（noise / confidence / redundancy / bloat）一个字节都不碰。一旦 LLM 进了评分链路，52.4 这个数字就不可复算、不可审计、不可回归——§1.1「科学合理」与 §9.4「仪表归仪表」两条根基同时塌掉。

8.1.1 三个接入点（按风险从低到高递进）

级别	接入点	LLM 干什么	LLM 不干什么	失败处理（v2.5）
L1（Day 8）	§4 Q3 建议的措辞增强	把确定性产出的机械建议 + evidence 渲染成一句人话	不选建议（选哪条 100% 由 §4 Q3 映射表决定）	抛 `OracleLlmError` → 本轮广播中止（error 痕 + alert + 重试）
L2（Day 9）	§4 Q2 的深挖	把「最丑指标 = noise_ratio」深挖到「哪几条条目、谁写坏的」	不改指标值、不改最差项判定	同上；无 auditIds 时返回 skipped（内容闸门）
L3（Day 10）	§5 weekly 美谕提案的正文生成	撰写 evidence 摘要与提案 body	不改 `status`（锁 proposed）、不直接改代码	同上；先完成全部 L3 再写库，失败则零提案落盘

三级的依赖关系：L2 → L3 有数据依赖（L3 的提案 body 消费 L2 的深挖结果）；L1 完全独立。

8.1.2 L1：Q3 措辞增强（最低风险，先做）

动因：§4 Q3 的现有输出在广播里是"天书"级。方案 §5 示例第 4 行：

建议：为 71 条无 evidence 记忆补证据（id 清单见 oracle 审计条目）

问题不是选错建议，而是说不出人话——71 条 id 列表让老板自己去审计条目里翻。

契约（LLM 的输入输出严格界定）：

输入（确定性产出的完整结构，LLM 不得改动任何值）：
  { metric: 'noise_ratio', value: 0.232, threshold: 0.30,
    worst_contributor: 'memory_without_evidence',
    evidence: { count: 71, recentIds: ['mem_xx1', 'mem_xx2', 'mem_xx3'] } }

输出（LLM 只做措辞）：
  「噪声比 23.2% 破线，主要来自 71 条缺 evidence 的记忆；
   建议按 memory 表补 anchor，先从最近写入的 mem_xx1 起。」

硬约束：
  - 数字、id、阈值必须逐字节来自输入，**禁止重算或四舍五入到新值**
  - 输出长度 ≤ 1 行 / ≤ 200 字节（广播预算内）
  - 不得新增输入中不存在的建议动作

为什么这条最安全：LLM 在此处没有选择权，只有措辞权。§4 Q3 的映射表 4 条仍 100% 决定"该做什么"，LLM 只是把 id 列表译成人话。

8.1.3 L2：Q2 深挖（方案自己留的口子）

§4 Q2 原文明确留白：

取 4 个指标中偏离阈值/基线最差者，指到指标级 + 来源（如 rule_lint 命中明细），不深挖到行（深挖归 weekly 提案）。

这个括号就是 LLM 的接入点。 当前 Q2 只能说"最丑的是 noise_ratio"，说不出"丑在哪一条、哪次写入、谁写坏的"。

分工硬规则：

	归 LLM	归确定性代码
最差项判定	✗	✓（§4 Q2 的偏离度比较，仍是纯函数）
指标级归因	✗	✓
行级深挖（"哪几条 id / 哪次写入"）	✓	✗
daily 广播输出	只输出一句归因	控制行数/字节裁剪

深挖结果的去向（关键设计）：

daily 广播里只落一句，不膨胀 §7 的 ≤5 行 / ≤2 KB 预算；
完整深挖结果落 weekly 提案，走既有的 agint.evolve.propose() 写路径（§9.1 白名单内，不新增写能力）。

新增模块：lib/deep-dive.js，纯函数 prompt 构造 + spawnLlm 调用，可独立单测。

8.1.3.1 输入契约（硬约束：entry 正文永不入 prompt）

问题：深挖要读 memory 条目，prompt 里送什么？

先看 dream 怎么做的（agint-dream/lib/consolidation.js:117-170 的 buildConsolidationPrompt）—— dream 是全文送，而且送全量：候选正文（> ${c.text}）+ 存量条目全文（fenced block 内 e.content）+ 会话 key + 信号计数。

但这不可类比，因为任务性质不同：

	dream consolidation	oracle L2 深挖
输出类型	内容生成：`priorEntries` 必须 verbatim 拷贝原文	定位描述：产出"最丑的是哪几条、为什么"
是否需要原文	⛔ 必须。校验是 `includes(原文)`，不给正文产不出合法输出	✅ 不需要。定位靠 id + 摘要 + 计数
输入规模	`gated` 已被 gate 收窄到几十条	"最丑集合"可能数百条（当前 71 条无 evidence）

dream 全文送是被输出契约倒逼的必然（consolidation.js:152 注释：priorEntries 比对原文，多一个前缀就整批拒绝，2026-09-18 事故丢 16 条候选）。oracle 没有这个约束。

v2.4 定契约：

// oracle L2 深挖 prompt 的输入（进 deep-dive.js）
{
  metric: 'noise_ratio',
  value: 0.232, threshold: 0.30,
  worstIds: ['mem_xx1', 'mem_xx2', ...],      // id 全给（定位需要）
  samples: [                                   // 只给元数据 + 截断摘要
    { id: 'mem_xx1', type: 'decision', confidence: 0.62,
      createdAt: '2026-09-20',
      excerpt: '<content 截断至 80 字符>' },     // ⭐ slice(0, 80)，同 dream sweep.js:795 口径
  ],
  counts: { total: 71, byType: { decision: 40, lesson: 31 } },
}

// ⛔ 硬约束：entry.content 全文永不进入 LLM prompt

为什么不是"只送 id"：纯 id 让 LLM 无法产出有价值归因（说不出"这 71 条多是关于 agent 调用的旧决策"），深挖退化为复读 id，L2 白做。参照 dream 的 dedupeSuspicion 设计意图（consolidation.js:134）：「把这件事显式告诉模型，而不是让它自己从原文里重新发现」——送摘要是"告诉它丑在哪类"，这才是深挖的价值。

为什么不是"全文送"：oracle 命中的集合没有 dream 那样的 gate 收窄，全文送 = 把整个记忆库搬进 prompt。同样的做法在不同规模下风险完全不同。

单元测试断言（AC-18b）：构造含超长 content 的 mock memory 条目，断言 prompt 中出现的内容 ≤ 80 字符 + 无 content 字段全文。

8.1.4 L3：weekly 提案正文生成（收益最大）

这条天然对接已通电的下游——agint-evolution-driver 消费的就是 evolve.listProposals({status:'proposed'})：

oracle weekly 深挖（L2 产物）
   → agint.evolve.propose({ status: 'proposed', body: <LLM 写的证据摘要> })
      → agint-evolution-driver: evolve.listProposals({ status: 'proposed' })   ← 它的入料
         → spawnLlm 生成 oldText/newText
            → anchorExists 硬校验 → mutator.propose → population.ingest

收益逻辑：LLM 生成的提案质量，直接决定 driver 那套 22 天闭环引擎能不能产出真实变异（参照 agint-evolution-driver CHANGELOG v0.2.3 的首次落盘里程碑）。在 oracle 这头多花 500 token 把 evidence 写扎实，driver 那头就少一次 applicable: false 空转。

身份未变：oracle 仍是只读评论员——它写的是 §9.1 白名单内的 agint_evolve 提案表（本来就已授权），不是自己改代码。

8.1.5 工程纪律（照抄本仓库两个已验证范式）

⛔ 不要自己发明 LLM 调用方式。 本仓库有两处经血债验证的范式：

范式 A —— agint-evolution-driver/lib/index.js 的 spawnLlm

handle = await agents.create({
  sessionId: `...-${randomUUID()}`,
  meta: { cwd: process.cwd(), origin: 'subagent',
          agentPreset: preset ?? 'agint' },   // ⛔ K114：缺这个 = 空壳会话，不报错但一步跑不动
  agentOptions: { provider, model },           // 取自 agentDefaultModel.currentSelection()
  signal: controller.signal,
});
run = await subagents.start('spawn', {
  parent: handle.agent, prompt: [...],
  outputSchema: schema, signal: controller.signal, label: '...',
});
const result = await run.result;
if (result?.stopReason !== 'completed') return { ok: false, reason: `stopReason=${result?.stopReason}` };
const structured = result?.structured;   // ⭐ 不是 result.output（读 output 恒 undefined，静默零产出）

范式 B —— agint-dream/lib/consolidation.js 的 consolidate，两个 killer detail 必须带：

超时双保险 —— Promise.race([activation.result, timeoutGuard])。只靠 signal 不够：provider 不认 signal 时（挂死的 HTTP、卡住的适配器），await result 会永久 pending，夜间 sweep 直接卡死。
无降级：失败必 throw（v2.5，与 dream 的旧策略相反）——所有失败路径抛 OracleLlmError （code=ORACLE_LLM_UNAVAILABLE），由 index.js 落 error 痕 + 告警 + 调度重试。 不再有 { ok:true, mode:'heuristic-degraded' }。老板 2026-10-25 令：神谕层不准 LLM 降级。

宿主契约（2026-10-23 根因）：现宿主只有 subagents.startActivation({ provider, label, request, signal, delivery })， 没有 subagents.start。旧代码按 start 检查方法存在性 ⇒ 恒失败并谎报 subagents unavailable （25 天未被发现）。新代码优先 startActivation，旧宿主保留 start 兼容分支；三种病因分开报。

模型选择（K99）：provider/model 优先级 = agentDefaultModel.currentSelection() → 兜底 minimax-cn / MiniMax-M3.1-Flash（当前宿主注册值）。reasoningEffort 必须传（MiniMax 缺档位会 400）。

8.1.6 对 §7 性能预算的修订（v2.4.1 按实测校准）

v2.4 原表把 daily 写成「异步、≤ 3 秒、LLM 不阻塞广播」，与实现不符。 2026-10-13 校准为实测值，已同步进 §7。

资源	v2.3 现值	v2.4.1 实测预算	说明
LLM token	`0`	daily `≤ 2k` / weekly `≤ 8k` / monthly `≤ 8k`	⭐ 非 0：L1 每日触发。~~仅在深挖命中时才花~~ 表述作废
单次 broadcast wall clock	≤ 3 秒	模板档 `≤ 3s`；LLM 档 `≤ 60s`	⭐ L1 为同步 `await`（`index.js:510`）。已评估：异步会让当天建议行退回模板原文，与「尽量用 LLM」相悖，故维持同步。实测 10.8 / 11.1 / 24.9 / 12.6 秒
写入字节	≤ 2 KB / broadcast	不变	LLM 输出超预算时由 `fitLines` 从尾部截断并标 `…（截断）`；不回落模板
超时	N/A	L1 / L2 / L3 均 `60_000 ms`	2026-10-05 由 10s 提到 60s；v2.5 增加 `Promise.race`，超时必返回并 dispose（见 8.1.5）

可观测字段（否则"跑过但没产出"和"根本没跑"在生产上无法区分）：

oracle.daily / weekly / monthly payload：
  mode: 'template' | 'llm'

template = 本轮没有需要 LLM 的输出（内容闸门全部命中）。
llm = L1/L2/L3 至少一级成功。
不再有 heuristic-degraded：LLM 失败会中止广播，落 oracle_broadcasts.outcome=error。

这是本仓库 K114 的直接教训：agint-dream 的 LLM 整合上线 20 多天一直在走降级，日志与事件上完全看不出来（每次都记"跑了、没报错"）。2026-10-25 的修法更进一步：降级本身被删掉了。

8.1.7 kill-switch（v2.5：只剩整插件总闸）

config enabled:false           → 不 provide 服务 ⇒ 3 个 oracle cron job soft-skip
env AGINT_AESTHETIC_ORACLE=off → 同上（秒级可逆）

AGINT_AESTHETIC_ORACLE_LLM 已删除（v2.5）。老板 2026-10-25 拍板：不准 LLM 降级，因此不存在 off / l1 / l1l2 分档。关掉 LLM 输出层 = 关掉整个神谕层，不存在「只发模板」的中间态。

无降级的风险由四道防线兜住（不靠"保守默认"兜）：

失败可见：L1/L2/L3 失败 → outcome=error + oracle.alert + cron lastError + 调度重试；连续 3 次调度失败 → 沉默 + 24h 告警（§6.2）。
AC-18 数字断言：L1 措辞里的数字/id 必须逐字节来自输入，幻觉数字过不了单测。
8.1.3.1 输入契约：L2 不送 entry 正文，隐私面不随"全开"扩大。
mode 字段：成功广播仍可区分 template（内容闸门）与 llm（K114 教训）。

8.1.8 验收（AC-16 ~ AC-24，v2.5 改写）

8.1.9 「尽量用 LLM」的边界（2026-10-13 决策留痕；2026-10-25 加严后仍适用）

2026-10-25「不准 LLM 降级」改变的是失败处理，不是接入面： L1 仍全档、L2/L3 仍只挂 weekly，内容闸门仍然生效。下面三处「未扩大」维持原判。

老板拍板「尽量用 LLM」时，本方案未扩大的三处，理由存档（后续要扩需另行拍板）：

未扩大处	现状	不扩的理由
daily 加 L2 行级深挖	daily 仅 L1	daily 每天跑；加 L2 会把 wall 从 10–25s 推到 30–70s，token 从周 8k 变日 8k。成本非线性，且与 §7 广播预算冲突
monthly 加 L2 / L3	monthly 仅 L1	monthly 无 `evolve_propose` 通路，加 L3 要新建写路径，撞 §9.1 白名单
L1 改异步	同步 `await`	异步当天建议行是模板原文（天书），与「尽量用 LLM」相悖。已选择接受 60 秒同步成本

判据：覆盖率每扩一层，先回答「谁付代价、付多少、有没有更省的替代」。答不出就先不扩。

9. 神谕层组件级红线（v2.3 重写）

9.1 两张白名单写表（替代 v2.2 的"只读"）

神谕层允许且仅允许写入：

表	用途	限制
`evolution_log`（经 `evolution_logPhase4`）	审计	targetKind=oracle-*；此标记同时是 activity 排除依据
`agint_evolve` 提案表（经 `agint.evolve.propose()`）	weekly 建议	仅 weekly cron；status 锁 proposed；永不 auto-apply

其余一切写 API 禁（含 v2.2 §9.1 原清单：restart_request / curator_archive / autocreate_release / wiki_write）。evolve_propose 从禁用清单移入白名单——v2.2 把它列为禁用却又在 §5.2/AC-8 要求调用，自相矛盾，本版以白名单定义终结歧义。

9.2 不绕过门禁（保留 v2.2）

rule_check 对神谕层自身返回 deny 时不得绕过。

9.3 不刷屏（保留 v2.2）

§5.4 配额护栏 + §6.3 自身健康回滚。

9.4 仪表归仪表，评论员归评论员（新增，方案 C 边界）

神谕层不得往 METRIC_DEFS 塞复合派生指标（noise_ratio / aesthetic_score 永远不进 metrics）。
神谕层是 metrics 的普通消费者，无特权：self-model / evolve / dashboard 同级读同一接口。
activity 排除 targetKind=oracle 是硬规则，任何 v3.x 迭代不得移除。

9.5 LLM 不越界（v2.4 新增，仅当 §8.1 生效时适用）

凡是进入 METRIC_DEFS 或写入指标存储的，不准有 LLM。

位置	可否接入 LLM
noise_ratio / confidence / redundancy / bloat 计算	⛔ 永久禁止
`aesthetic_score` 累减公式	⛔ 永久禁止
§4 Q1 判定逻辑	⛔ 禁止（P1-4 刚修过倒挂，判定必须确定）
§4 Q2 最差项判定	⛔ 禁止（深挖可 LLM，判定不可）
§4 Q2 行级深挖	✅ §8.1 L2
§4 Q3 措辞渲染	✅ §8.1 L1（选哪条建议仍归映射表）
§5 weekly 提案 body	✅ §8.1 L3
阈值本身	⛔ 禁止（阈值漂移会让历史对比失效）

一句话判据：凡是进入 METRIC_DEFS 或写入指标存储的，不准有 LLM。

10. 关联文件 / 记忆

类别	路径 / id
本技术方案	`D:\DSH\project源码\DSH-AGINT.wiki\agint-aesthetic-oracle.md`（v2.2 备份：同目录 `.bak-v2.2-20260927`）
评审报告	`agint-aesthetic-oracle-评审报告-2026-09-27.md`（P0×3 / P1×4 / P2 清单）
架构论证	`agint-metrics-扩展架构论证-2026-09-27.md`（方案 A/B/C/D 权衡 → C）
OpenViking 冗余	`viking://user/dayu/resources/agint/aesthetic-oracle-design.md`
lesson（美是戒尺）	memory id `16955514-1dcc-4694-b9fa-237528df1e9a`
decision（自进化闭环首跑）	memory id `240098aa-23cf-462e-b88b-6676cea264b9`

附录 A：v2.2 → v2.3 修订清单（对照评审 P0/P1）

评审编号	问题	v2.3 修复	落点
P0-1	回滚条件混淆"系统不美"与"神谕层不美"，按真实数据第一天触发	回滚只看自身健康四条件；系统总分只告警；基线=首周均值；AC-15 验证杀信使已死	§3.6 / §6.3
P0-2	noise 分子含 REJECTED（门禁正常工作算成丑），占 68%	剔除 autocreate 域；新定义"在系统内的无引用/无证据/重复"；分母改系统内三域总量	§3.1
P0-3	神谕层审计日志污染 activity（0.029→0.24 假健康）	activity 排除 targetKind=oracle（硬规则）；"死寂"改"静默期"；不进总分	§3.5 / §9.4
P1-4	Q1 判定倒挂（3/5 恶化判"持平"）	重排判定：恶化≥2→丑；改善≥3→美；验证无洞	§4 Q1
P1-5	示例 4 处虚构（3/53、90天未引用、72分、12技能30-60KB）	全部换真实数据（26 规则、无入链定义、52.4 分、11 技能 82.7KB）；复算链入附录 C	§5 / 附录 C
P1-6	"只读"与调 evolve_propose 自相矛盾；禁用清单含空集限定	改"两张白名单写表"；evolve_propose 移入白名单	§2 / §9.1
P1-7	冗余度跨域分子挂单域分母	三域合并公式	§3.3
P2-8	"memory_provider_status 风格 GUI 告警"通道不存在	oracle.alert topic + dashboard 订阅，AC-7b 端到端	§6.2 / §5
P2-9	autocreate_rollback 归档插件——作用域错配	kill-switch config 项	§6.4
P2-10	整点笔误 / oracle_pause 缺任务位 / "标定"名不副实 / Q3 映射缺 3/4 / evidence 路径错	§7 修正表述；Day 1 任务化；改"首周观察"；§4 给全 4 条映射；§3.2 修正	各节
架构	v2.2 直连 8 API = 第三份重复采集	方案 C：原子归 metrics（Day 0），神谕层薄消费	§2 / §3.0 / §8
新增	评审 v2.3 后老板提问"引入 LLM 接入点放哪"	§8.1 LLM 增强档（默认启用）：三级递进（Q3 措辞 / Q2 深挖 / weekly 正文），评分链路永久零 LLM；含 §7 预算修订 + §9.5 红线 + AC-16~19	§8.1 / §1.2 / §2 / §7 / §9.5
v2.4.1	2026-10-13：老板拍板「尽量用 LLM」，但 §7 预算与实现脱节（wall / token / 同步性三处）	§8.1 由「可选增量」改默认启用、尽量使用；§7 按生产实测重写（承认 L1 同步阻塞 ≤60s、承认每日有 token）；新增 §8.1.9 边界留痕 + AC-21/22	§7 / §8.1 / §8.1.6 / §8.1.9
v2.5	2026-10-25：老板拍板「不准 LLM 降级，都要用 LLM」；2026-10-23 根因确认 `subagents.start` 契约漂移致 LLM 档 0%	接 `startActivation`；删分档开关与 heuristic-degraded；LLM 失败中止广播 + error/alert/重试；stale 缓存也走 LLM；L3 先润色后写库；AC-16 废止，AC-17/20/22 改写，AC-23/24 新增	§8.1 / §8.1.5 / §8.1.6 / §8.1.7 / §8.1.8 / §7.3

附录 B：v2.3 → v3.0 演进路径（保留 v2.2 骨架，加一条）

触发条件	v3.0 变化
连续 30 天总分波动 ≤ 30 分	累减公式可试验改加权平均
diagnosis_report annotationCount > 50	failure mode 指标纳入总分
出现 ≥ 1 次自动沉默	增加预警阈值（沉默前 3 天告警）
神谕层上线 ≥ 90 天稳定	v3.0 GA
新增：evolve dataSnapshot 迁移完成	evolve 周报从直连切到 metrics 只读（收敛第二份直连，技术债清偿）
新增：§8.1 L2/L3 稳定运行 ≥ 30 天且 `mode='llm'` 占比 ≥ 80%	可考虑把 Q2 深挖从 weekly 前移到 daily（当前为控广播预算刻意留在 weekly；代价分析见 §8.1.9）
新增（v2.4.1）：daily wall 连续 ≥ 7 天 > 45 秒	重新评估 L1 同步阻塞（届时可选：改异步 / 降超时 / 换更快模型）

附录 C：阈值标定依据（2026-09-27 生产实测）

数据源：C:\Users\Administrator\.dsh\storages\（agint.json / agint_rules.json / agint_skill_autocreate.json / agint_evolution.json）+ 两处 skills 根文件系统遍历。复算脚本为纯 node 单文件，随 Day 0 的评分模块一并入库（test/calibration-2026-09-27.mjs），保证任何人不跑 dsh 也能复现 52.4。

量	v2.2	v2.3	变化理由
noise 分子	含 REJECTED 37	88 = 13+1+3+71	门禁拒绝不进系统；evidence 缺失是真噪声
noise 分母	含 autocreate_total 42	380 = 18+26+336	与分子同口径（系统内条目）
redundancy	4/26 单域分母	4/55 三域合并	量纲一致
bloat 阈值	50KB（拍脑袋）	120KB（11 技能 × 8-12KB）	有 source 的经验值
confidence	0.735（未乘 compliance）	0.544（逐条乘）	公式与实现一致
evidence 路径	entry.memory.evidence（错）	entry.evidence（顶层字段）	实测 schema
总分	示例 72 / 实算 27.1	实算 52.4	数字进入真相

版本

v1.0 — 2026-09-27 创立（已废弃，16 个不认真处）
v2.2 — 2026-09-27 重做（已废弃，评审 3×P0 + 4×P1 + 示例虚构）
v2.3 — 2026-09-27 语义修复 + 方案 C 架构落定（老板拍板："先修语义，再落方案 C 架构"）
v2.4 — 2026-09-27 LLM 增强档落定（老板拍板：① 升 v2.4　② 隐私边界按 8.1.3.1 契约　③ 默认拉满 all；前提：Day 0-7 全部验收通过）
v2.4.1 — 2026-10-13 表述与预算校准（老板拍板「尽量用 LLM」；§7 按生产实测重写，§8.1 升为默认启用；新增 §8.1.9 边界 + AC-21/22；无行为变更）
v2.5 — 2026-10-25 无 LLM 降级（老板拍板「不准 LLM 降级，都要用 LLM」；修复 startActivation 契约；删 off/l1/l1l2 与 heuristic-degraded；LLM 失败中止广播；stale 缓存也走 LLM；L3 先润色后写库；AC-16 废止，AC-17/20/22 改写，AC-23/24 新增）

实施记录（生产事故与验证）

2026-09-28 · summary() 丢 meta → 晨报总分虚标 100（已修复）

Day 6-7 观察期第一天发现：09-28 晨报美总分播 100（同日标定应 52.4），四维中 noise / confidence / redundancy 全 N/A。取证链：oracle 存储 lastGood.atomic 六个原子值 null → 生产 metrics 存储里 meta 完整（noEvidence=71 / rulesTotal=26 / wikiTotal=19 / avgConfXCompliance=0.5406）→ 根因在 agint-metrics service 层： summary() 返回体漏带 meta（series() 一直带）。神谕层派生全靠 meta，拿不到 → 权重归一后满分。两侧单测各自全绿、接缝处静默断裂（AC-0a 直测 computeMetrics，绕过了 service 层）——「采集通电了」≠「消费通道通电了」的接缝案例。

修复：summary() 补 meta: rec.meta；新增 test/service-summary.test.js 钉死接缝
复算验证：生产 meta 逐项代入 §3.6 = 53.6（与 09-27 标定 52.4 的差异为 wiki 18→19 页、memory 336→362 条的自然波动，合理）
连带症状自愈：09-28 weekly proposals: 0 同为四维 N/A 的下游，修复后 weekly 将正常提 3 条（noise −21.9 / redundancy −20 / confidence −4.6，top3）
部署：bundle 位 + 兼容位已同步，需重启 dsh web，下轮 04:00 采集 / 09:00 广播生效

其他在案观察（暂不处置）：

metrics 存储每轮每 key 双写（bundle 位 + profiles/web/plugins 兼容位双实例各跑一次 collect，ts 差 ~120ms）。summary() 按 ts 取最新，无实害；删兼容位有风险（老路径代码可能引用），留观。
Day 8-10 LLM 增强档（§8.1）未动工：前提「Day 0-7 验收通过 + 首周基线建立」未满足，待观察期走完 + meta 修复经明晨广播验证后启动 L1。

AGINT — 基于 DeepSeek Harness 的自进化智能体框架 · 美是起源与终极追求

AGINT 文档 ｜首页

agint aesthetic oracle

美的神谕层 · 技术方案 v2.5

0. 立项依据

1. 设计前提

1.1 三个约束（同时成立）

1.2 范围边界（v2.3 更新）

2. 核心定位（v2.3 重写）

3. 指标体系（v2.3 重写：语义修复 + 分层）

3.0 分层原则（方案 C 的核心）

3.1 噪声比（Noise Ratio）——P0-2 语义修复

3.2 决策确信度（Decision Confidence）——字段路径修正

3.3 冗余度（Redundancy）——P1 量纲修复

3.4 臃肿度（Bloat）——阈值重定

3.5 自进化活跃度（Evolution Activity）——P0-3 观察者污染修复

3.6 美总分（Aesthetic Score）

4. 美之三问（Q1 逻辑洞修复）

Q1：这件事让系统更美了吗？

Q2：这件事最丑的地方在哪？

Q3：建议怎么做才能更美？

5. 三档广播（v2.3：增加 asOf 透出 + eventBus 落点）

weekly 美谕提案（保留 v2.2 结构）

6. Failure Mode（v2.3 重写 6.2 / 6.3 / 6.4）

6.1 数据源失败

6.2 神谕层自己挂了

6.3 回滚条件（P0-1 修复：不再杀信使）

6.4 关停机制（P2-9 修复）

7. 性能预算（v2.4.1 重写：按生产实测校准）

7.1 预算表

7.2 三处脱节的校准（v2.3 纸面值 → v2.4.1 实测值）

7.3 同步阻塞的兜底（为什么可以接受 60 秒）

8. 落地路径（v2.3：Day 0 前置 + 语义先行）

Day 0（半天）：语义修复 + agint-metrics 扩展

Day 1（4 小时）：薄神谕层骨架 + daily 跑通

Day 2-3：三档频率 + eventBus

Day 4-5：美谕提案闭环

Day 6-7：上线观察 + 基线建立

Day 8-10：LLM 增强档（⭐ 必须使用、无降级）

8.1.1 三个接入点（按风险从低到高递进）

8.1.2 L1：Q3 措辞增强（最低风险，先做）

8.1.3 L2：Q2 深挖（方案自己留的口子）

8.1.3.1 输入契约（硬约束：entry 正文永不入 prompt）

8.1.4 L3：weekly 提案正文生成（收益最大）

8.1.5 工程纪律（照抄本仓库两个已验证范式）

8.1.6 对 §7 性能预算的修订（v2.4.1 按实测校准）

8.1.7 kill-switch（v2.5：只剩整插件总闸）

8.1.8 验收（AC-16 ~ AC-24，v2.5 改写）

8.1.9 「尽量用 LLM」的边界（2026-10-13 决策留痕；2026-10-25 加严后仍适用）

9. 神谕层组件级红线（v2.3 重写）

9.1 两张白名单写表（替代 v2.2 的"只读"）

9.2 不绕过门禁（保留 v2.2）

9.3 不刷屏（保留 v2.2）

9.4 仪表归仪表，评论员归评论员（新增，方案 C 边界）

9.5 LLM 不越界（v2.4 新增，仅当 §8.1 生效时适用）

10. 关联文件 / 记忆

附录 A：v2.2 → v2.3 修订清单（对照评审 P0/P1）

附录 B：v2.3 → v3.0 演进路径（保留 v2.2 骨架，加一条）

附录 C：阈值标定依据（2026-09-27 生产实测）

实施记录（生产事故与验证）

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!