HT1072 Knowledge System
decision.ht1072.top

Decision Trace Hub｜决策档案库

保留方案、指标、验证、复盘和治理判断，让结论能够追溯。

118记录
8分类
8主题
2026-07-10更新
共 118 项结果
2026-07-10

小墨模型评测详情：grok-4.5

grok-4.5 本轮得分 150 / 160，达到强主模型候选线。最突出的能力是工具验证闭环、Git 远端事实分层和漂移判断；规划与知识治理也稳定，但少数方案仍偏通用模板化，命令口径偶有环境细节瑕疵。

查看 →
2026-07-10

小墨模型评测详情：gpt-5.6-luna

gpt-5.6-luna 本轮得分 141 / 160，达到主模型候选观察线。规划、分组、回归判断和 wiki 收口稳定，表达克制；主要问题是 T4 没有真实工具调用和可审计命令输出，工具执行闭环不合格。

查看 →
2026-07-10

小墨模型评测详情：gpt-5.6-terra

gpt-5.6-terra 本轮得分 146 / 160，达到主模型候选线。规划收口、commit 分组、focused regression 与知识治理稳定；主要短板是 T1 未基于真实 diff 给具体清单，T4 未形成可复核的远端状态证据链。

查看 →
2026-07-10

小墨模型评测详情：gpt-5.6-sol

gpt-5.6-sol 本轮得分 157 / 160，明显超过当前 gpt-5.5 基线，属于强主模型候选。它最有价值的提升不是“答得更满”，而是 T1/T4 能先定位真实对象再给结论：commit 归因、远端分支/commit 可达性判断都比旧基线更硬。

查看 →
2026-06-29

OpenBiliClaw 项目调研与吸收评估

OpenBiliClaw 值得按 Partial Absorb / L3 局部能力吸收 处理：吸收它的“跨平台内容发现供给架构”和“浏览器扩展登录态任务桥”，不要整项目并入，也不要替代我们现有 B站管线、小红书 skill、AutoCLI/OpenClaw/Hermes 搜索路由。

查看 →
2026-06-25

结论：不建议整包替换 baileyh8/hermes-feishu-streaming-card，我已经按“部分吸收 + 本地原生巩固”把 P0 落下来了。

不建议整包替换 baileyh8/hermes-feishu-streaming-card，我已经按“部分吸收 + 本地原生巩固”把 P0 落下来了。 外部项目最值得吸收的是 streaming 状态机、final 优先级、footer 信息密度、doctor/smoke 体系；我们自己的主链更强的是现有 Feishu 路由、Card V2 builder、native table、长决策 guard、completion receipt 和飞书实际兼容经验。 已完成 - 扩展 gateway/runtime…

查看 →
2026-06-25

Feishu Card v3 吸收方案：稳定、美观与升级省事

本方案建议以 Partial Absorb + Native Consolidation 方式吸收 baileyh8/hermes-feishu-streaming-card：不整包替换本机 Feishu card 体系，不引入它的 installer patcher 作为生产主链；重点吸收它的 流式事件协议、会话状态机、终态优先、footer 信息密度、doctor/status 诊断与升级 smoke 流程。

查看 →
2026-06-25

hermes-feishu-streaming-card 与本机 Feishu Card 主链对比评估

baileyh8/hermes-feishu-streaming-card 不是一个单纯 card renderer，而是围绕 Hermes Gateway 的 Feishu 出口做的 streaming card sidecar + hook installer + 诊断运维层。它最强的部分是“运行时流式状态机”：把 started / thinking / answer / tool / completed 等生命周期事件汇聚到同一张飞书卡片，并用 sidecar 负责发送、更新、合并、重试、健康检查和多 bot/profile 路由。

查看 →
2026-06-20

Headroom 从吸收到使用的完整方案

Headroom 在本机体系中的最佳定位不是“替代 Hermes / CPA / Hindsight 的新主系统”，而是一个可回退的 input context compression sidecar：只接入压缩能力，吸收 ContentRouter、SmartCrusher、CCR、exclude tools、CacheAligner 等方法；不吸收 memory、learn、dashboard、agent wrap 和 Copilot OAuth 壳。

查看 →
2026-06-19

Hindsight Reflect 使用规范与下一步规划

Hindsight 的 reflect 不是"定时反思"，而是 query-driven 的 agentic RAG。本机已完整打通 directives + mental_models + reflect 三层，配 5 个 query 模板和 4 个长效 mental_model，实测命中后 token 省 12 倍、耗时省 8 倍。短期不上 cron，长期等周复盘稳定后可考虑。

查看 →
2026-06-18

cftunnel 对 HTML 发布能力的吸收评估

这个项目主要补的是“公网暴露入口层”的缺口；和现有体系的关系是局部补强，不是替代；最值得吸收的是“本地预览临时外链”这个 sidecar 用位；不值得吸收的是 relay 壳、整套 tunnel 管理壳以及任何试图替代正式 HTML 发布主链的用法；因此建议按 L2 处理，最终决策归类为 Sidecar。

查看 →
2026-06-17

Bili Tech Pipeline 发现链路重构与脚本归档

把 bili-tech-pipeline 的发现链路从 7 个并列的 run_actual_task 脚本收口到统一入口 python -m src.scripts.run --strategy <name>，按 broad_sample / stable_sample / keyword_only 三个 DiscoveryStrategy 实现切分；同步把 UP 池评分、健康检查、目标选择、ROI 跟踪从老脚本里抽到 src.domain.up_pool 模块。Review Console 切到新入口后通过完整链路验证：API 触发后真实抓取并写入审核库与飞书去重命中。归档阶段把 23 个一次性历史脚本下沉到 src/scripts/legacy/，12 个探针脚本下沉到 src/scripts/probes/，旧 run_actual_task_*.py 全部退化为带 DeprecationWarning 的薄壳转发。13 个测试全部通过，回滚通道保留 BRC_USE_LEGACY_BROAD_SAMPLE feature flag 与备份 tarball。当前发现链路是单一权威路径，老路径仅用于兼容观察。

查看 →
2026-06-17

小墨模型评测详情：glm-5.2

glm-5.2 本轮得分 145 / 160，达到主模型候选线。它在主线保持、规划收口、工具验证和 wiki 治理上都比较稳；相对 gpt-5.5，已经接近可替换候选，但表达略偏长，commit grouping 的层级判断还可以再克制一些。

查看 →
2026-06-15

小墨模型评测详情：MC-4.8（2026-06-15 164052）

MC-4.8 本轮小墨模型评测得分 133 / 160，属于“主模型可用，但需要看偏科项”的区间。它适合做文档治理 worker、规划/同步收口 worker，也可以作为轻量主线候选试用；但不建议无约束替代 gpt-5.5 承担强工具闭环、远端验证、发布裁决等高风险执行任务。

查看 →
2026-06-15

小墨模型评测详情：glm-5.2

glm-5.2 本轮小墨模型评测得分 131 / 160，属于“主模型可用但有明显偏科”的区间。它适合作为文档治理 worker / planning worker / 轻量技术判断草案生成模型；不建议直接作为小墨主模型，也不适合独立承担需要真实工具验证闭环的代码、发布或 GitHub 同步最终裁决。

查看 →
2026-06-15

小墨模型评测详情：sj-3.5（2026-06-15 160032）

sj-3.5 本轮评测 126 / 160，属于“限定场景 worker 可用，但不建议主线”的档位。它的结构化表达、规划整理、wiki 大纲和 drift triage 都能用；核心短板是 T4 工具验证题没有真实查证，只停在命令方案层，还写入未证实的具体仓库/分支占位。因此它适合做文档治理 worker / 规划整理 worker，不适合承担小墨主模型、code worker 或高风险运行态裁决。

查看 →
2026-06-15

小墨模型评测详情：sj-4.6（2026-06-15 154615）

sj-4.6 本轮评测 125 / 160，属于“主模型可用线以下的稳定 worker”。它在轻量规划、回归范围判断、升级 worth-it 与 drift triage 上可用，适合做文档治理 worker / 轻量规划 worker / 受控 code triage；但 T1 对 ca8f4abdb 的三层拆解没有事实锚定，T4 只给了验证清单、没有真实工具调用，因此不建议作为小墨主模型承担长链执行或最终裁决。

查看 →
2026-06-15

Claude Code Provider 指纹调整复盘：JUN 8335 恢复与 x666 8334 边界

JUN 8335 的 channel:client_restricted 不是单纯 User-Agent 问题，而是缺少 Claude Code / Stainless 客户端指纹；补齐 x-stainless-*、收敛 anthropic-beta、固定 Accept: application/json 后，non-stream、stream、tool_calls 均恢复 200。x666 8334 即使本地 adapter 补齐同样指纹仍返回 Go-http-client/1.1，说明被拦的是 x666 服务端出站 client，不是本机请求。

查看 →
2026-06-14

小墨模型评测详情：claude-opus-4-8-cc（010250）

claude-opus-4-8-cc 本轮评测 136 / 160，属于“主模型可用但不稳”。它在规划、回归判断、升级收益判断、wiki 收口和 drift triage 上表现稳定，适合做文档治理 worker / 规划收口 worker；但这次 T1 对 ca8f4abdb 的三层拆解明显偏模板化，T4 只给了验证流程、没有真正完成实查闭环，因此不建议直接承担需要强工具验证的主线最终裁决。

查看 →
2026-06-14

小墨模型评测详情：claude-opus-4-8-cc

claude-opus-4-8-cc 本轮评测 148 / 160，是强主模型候选。主线保持、规划收口、Git/GitHub 漂移判断、focused regression 和升级收益判断都很稳；T4 对 upstream、远端分支、commit 可达性的陷阱覆盖完整，是本轮明显加分项。主要短板是少数题在缺少真实 diff / 真实仓库路径时偏模板化，T4 没有输出具体仓库的最终 yes/no 结论，因此真实执行场景里要继续给明确目标对象并要求最终状态回执。

查看 →
2026-06-04

Hermes WebUI 8787 cpa-codex 模型目录错位复盘

本轮调整尚未真正收口。已修复的是 custom:cpa-codex 的默认模型/provider 粘连与同名模型 provider 丢失问题，但模型目录展示仍有策略错误：WebUI 当前把 CPA live aliases 与 config.yaml 中的静态 configured models 当成互斥来源处理，导致 gpt-5.4 / gpt-5.3-codex / gpt-5.2 等静态模型没有显示，同时动态 alias 又未按预期与静态列表做并集。

查看 →
2026-06-02

Hindsight 0.6.2 到 0.7.2 生产升级复盘

Hindsight 生产 API 已从 0.6.2 成功切到 0.7.2，当前 http://127.0.0.1:8889 运行健康，PostgreSQL migration 已升级到 Alembic head c1d2e3f4a5b6，retain / recall / consolidate 全链路验收通过。

查看 →
2026-06-02

SharedChat Adapter Tool Bridge 与 systemd 托管修复记录

SharedChat Codex Adapter 已从“纯文本 Chat→Responses 转换器”升级为可支持 Hermes agent 工具调用的 bridge；SC-GPT-5.5(high) 已可通过 Hermes → CPA 8317 → SharedChat Adapter 8329 → SharedChat Responses 完成 tool_calls 发起与工具结果回灌。

查看 →
2026-06-01

Hermes Skill 治理与月度审计链路收口复盘

本次治理没有把“退役 skill”当主目标，而是把月度 skill 审计从模型自由判断改为确定性事实采集与轻量策略评估：先保证事实口径可复现，再对缺字段、坏引用、同名误伤和保护项冲突做最小治理。

查看 →
2026-05-30

小墨模型评测详情：gpt-5.4-mini-high

gpt-5.4-mini-high 当前最好分 138/160，最新分 138/160，处于 B｜高可用 worker / 可受控主用。建议角色：research worker / 文档治理 worker / 受控 code-review worker；不建议直接作为唯一主模型.

查看 →
2026-05-29

SharedChat Codex 公益站接入 Hermes：Chat→Responses Adapter + CPA 反代

SharedChat Codex 公益站不是普通 OpenAI Chat Completions provider，而是 Responses-only Codex API。直接挂 Hermes 或 CPA openai-compatibility 容易因 /v1/chat/completions / /v1/models 不存在而失败。最终采用一层极薄本地 adapter，把 OpenAI Chat Completions 请求转成 /v1/responses，再挂到 CPA，Hermes 通过 custom:cpa-codex 使用唯一 alias SC-GPT-5.5。

查看 →
2026-05-29

Hermes 5.28 / 5.29 升级评估与方法复盘

这轮升级已经完成并通过最终验收：当前 live Hermes 为 Hermes Agent v0.15.1 (2026.5.29)。5.28 对应 0.15.0 大版本，5.29 是同日 hotfix 0.15.1；实际升级选择直接落到 5.29 是正确路线。

查看 →
2026-05-24

两台 Hermes 共享记忆方案

结论：两台不同电脑上的 Hermes 可以共享长记忆，但不应该靠同步本地 MEMORY.md / USER.md 或 state.db 实现。推荐使用同一个外部 memory provider，例如 Hindsight 共享 bank；Honcho 适合共享用户画像和多 AI peer；Supermemory / Mem0 是轻量云端语义记忆备选。

查看 →
2026-05-24

飞书长回复阈值验证

结论：飞书长回复不应该继续直接承载完整分析。当前采用“短飞书入口 + rich HTML + wiki Markdown + Hindsight retain pointer”的四层策略，并设置 700 中文字 / 约 1200 字符的飞书回复阈值。

查看 →
2026-05-23

2026-05-23-genericagent-vs-hermes-lcm-prompt-compaction

GenericAgent 的 agent_loop.py 和 llmcore.compress_history_tags 不是 Hermes LCM 的替代物。它们更像一套轻量运行时压缩纪律：靠最小循环、单轮消息重建、标签级截断、周期性压旧历史，减少上下文噪音。

查看 →
2026-05-23

2026-05-23-genericagent-absorption-eval

GenericAgent 不适合作为 Hermes 的替代主框架，也不建议整包合并；最值得吸收的是它的 context information density maximization 思路：极简原子工具、分层按需记忆、任务后 skill/SOP 晶化、长程执行中的压缩/截断纪律。

查看 →
没有匹配内容。