配置与模式
模式和配置在羽忆里不是“顺手补的设置页”，而是系统可控性的组成部分。尤其是模式切换，它直接决定写入链路能否执行，以及自动能力能否介入。
三种运行模式
manual
手动模式是第一阶段默认模式。只有显式写入才会进入系统，适合刚开始建立信任、还不希望系统自动沉淀记忆的场景。
assistive
辅助模式允许系统在合适的时候建议写入或触发受控自动化，但前提仍然是用户可感知、可关闭、可回看。
temporary
临时模式用于敏感讨论或一次性任务。它的核心语义是：不留下长期痕迹。只要进入临时模式，写入链路就应该被明确阻断。
自动写入开关
auto_write 是独立于模式的控制项。即使当前模式允许某种自动化行为，用户仍然可以通过总开关彻底禁止自动写入。
这种拆分是必要的，因为“会不会建议”和“能不能自动落库”并不是同一个层面的控制。
屏蔽规则
用户可以通过屏蔽规则明确告诉系统哪些内容不该进入长期记忆，例如：
- 敏感关键词
- 某类临时状态
- 不可信的特定 Agent
这类规则直接参与 Judge 的前置判断，是显式控制优先原则在实现层的体现。
服务端配置重点
第一阶段部署时，最需要明确的配置包括：
- 管理员初始化账号与密码
- 浏览器跨域来源
- Token 默认有效期
- Embedding / LLM 主密钥
- 默认 provider 配置
- Judge 置信阈值
- 开发模式开关
这些配置之所以应该在文档里单独讲，是因为它们不是普通参数，而是直接影响认证、检索、Judge 和安全边界的关键开关。
Provider 选择优先级
Embedding Provider
当前推荐固定优先级为：
- 控制台中激活的 provider
- 环境变量默认 provider
- 两者都不可用时退化为纯词法检索
LLM Judge Provider
优先级同理：
- 控制台激活的 LLM provider
- 环境变量默认 provider
- 两者都不可用时退化为纯规则 Judge
这类优先级必须写清楚，否则同一套部署在不同环境下会很难解释“为什么今天走的是这个 provider”。
控制入口
模式与配置相关的能力应当通过多个入口一致暴露：
- Web Console
- CLI
- MCP / Adapter 控制命令
- 直接 API
只要这些入口最终都落到同一套 Control Plane 上，用户就不需要记忆“某个设置只能在某个客户端改”这种额外规则。