Contexer：面向 coding agents 的工程决策层

Contexer：面向 coding agents 的工程决策层

核心判断

Contexer 值得深度入库，因为它聚焦 Context Engineering 中最容易被低估的一层：团队和项目已经做出的工程决策如何跨 session、跨工具、跨成员稳定抵达 coding agent。它不是又一个长规则文件，而是把“为什么这样做”的决策、理由和版本历史变成 agent 启动前可注入的 decision layer。

机制 / 一阶原理

Contexer 的基本机制是捕获并维护工程决策，例如“分页必须用 (created_at, id) cursor，因为 offset 在 1000 万行后崩过”，然后在 Claude Code、Cursor、Codex、Gemini CLI 等工具启动或相关任务发生时提供给 agent。它针对的是规则文件的衰减问题：CLAUDE.md、AGENTS.md、.cursor/rules 一旦没人同步，就会变成陈旧上下文；而决策层应在决策产生和变化时被更新。

一阶原理是：coding agent 缺的往往不是语法知识，而是本项目的选择历史、约束原因和不应重走的坑。把这些知识作为“settled answer first”提供，可以减少重复推理、减少 token 消耗，并防止 agent 用训练先验覆盖本地事实。

对 Hermes / llm-wiki 的启发

llm-wiki 已经承担了跨主题长期知识沉淀，但 Contexer 提醒我们还需要区分全局知识库与 repo-local decision layer：llm-wiki 适合沉淀 AI/工程方法论、来源、比较和长期概念；具体项目中的数据库分页、mock 策略、架构取舍、事故教训，更适合进入 repo-local knowledge bundle 或 AGENTS.md/decision store，并通过 wikilink 与全局方法论相连。

对 Hermes 来说，ConversationSpec 与 memory 也应遵循同一边界：稳定偏好进入 memory，任务状态进入 spec，项目决策进入 repo-local context，外部来源进入 wiki/raw。混在一起会导致上下文污染和迁移错误。

失败模式与边界

Contexer 的 README 强调人类批准、versioned history 和 review，但此类工具的风险是把过时决策继续注入，或者把局部决策错误推广到所有工具。决策层必须支持 supersedes、scope、owner、reason、evidence 和失效条件；否则它会把“少解释一次”的便利变成长期错误的放大器。

相关页面

• Context-Engineering
• Knowledge-as-Code
• LLM-Wiki

写入记录

• 2026-07-31 09:01 CST：新增对 Contexer 工程决策层、跨 coding-agent 决策注入、repo-local 与 global wiki 边界的分析。