用途：这是 Amplifier 的完整设计哲学，给出指导全部开发的原则、模式与决策框架。当需求不清晰时，可结合本文档与代码库做出正确且一致的决策。
核心原则：一、机制而非策略——内核提供能力与稳定契约，模块决定行为（选哪个 provider、如何编排、记录什么）；若两个团队可能想要不同行为，就应做成模块而非内核。二、极简——尽可能简单但不过度简化，每个抽象层都要证明存在价值，从最小开始按需生长。三、内核小、稳定、枯燥——内核很少改动且始终向后兼容，便于单一维护者理解，倾向删除而非堆叠，创新发生在其边缘（模块）。四、模块化设计（积木与凸点）——每个模块是自包含、职责清晰的积木，接口是允许独立再生成的凸点，优先重新生成而非编辑。五、事件优先的可观测性——重要的事就发出规范事件，不可观测即等于未发生，单一 JSONL 流是唯一事实来源，hooks 观察但不阻塞。六、文本优先、可检查——使用人类可读、可 diff、可版本化的表示与 JSON 校验 schema，无隐藏状态与魔法全局变量。
Linux 内核决策框架：内核（Ring 0）导出机制（mount、emit）而不含策略，保持小而枯燥；syscalls 对应会话操作，少而锋利且 ABI 稳定；可加载驱动对应模块（provider、工具、hook、编排器）；信号对应事件总线；/proc 对应统一 JSONL 日志；能力/LSM 对应审批与能力检查，默认拒绝；调度器对应编排器模块；内存管理对应上下文管理器。决策手册：选择、优化、格式化、路由、规划类工作都是模块（策略）；先在两处以上原型验证，≥2 个模块收敛后再提取进内核；保持契约稳定并优先重新生成；重要动作发规范事件；诊断统一输出 JSONL；更少活动部件优先。
内核职责：稳定契约、模块装载卸载、事件分发、能力检查、最小上下文串联；绝不选择 provider/模型、决定编排策略、选择工具行为、格式化输出或选择日志目的地。模块职责：provider 决定模型与参数，工具决定如何执行能力，编排器决定执行策略，hook 决定记录什么与脱敏，上下文决定压缩与摘要策略。
演进原则：以加法演进（可选能力协商、可选 schema 扩展字段、弃用窗口），新增内核能力需 ≥2 个独立模块的需求证明，向后兼容不可破坏。模块设计把软件当作乐高：先写契约（目的、输入、输出、副作用、依赖），模块内自带代码、测试、夹具，只通过接口暴露；需要改动就按规格整体重写并同步重新生成使用方；人类写规格与决策，AI 生成与测试。实现上先做垂直切片打通端到端路径，按 80/20 迭代，测试以集成与关键路径为主，不测读代码即可知的内容；错误要快速明显暴露，避免静默回退。安全、数据完整性、核心体验、错误可见性不吝啬复杂度，内部抽象、面向假设未来的通用代码、边缘情况、状态管理要激进简化。反模式包括内核中加入默认值与配置解析、文件 I/O、provider 选择与策略、私有日志、无迁移路径破坏兼容，以及模块依赖内核内部、自造事件名、私有日志、不上报事件、失败时拖垮内核。
内核变更门槛高、发布小而无趣；模块迭代快。若两个团队可能想要不同行为，就做成模块。
限制：本资料为设计哲学说明，未提供具体安装命令、版本、收费与性能数据。