work-ally 0.2.0-alpha.1

package/docs/planning/ally-next.md

@@ -0,0 +1,1278 @@
+# ally-next
+
+更新时间：2026-03-11
+
+这份文档是 `work-ally` 的下一阶段 feature spec。
+
+用途不是记录零散想法，而是为后续派工提供**可执行的产品规格基线**。
+
+参考背景：
+
+- 灯塔文档：`work-ally/docs/architecture/codex-feishu-bridge-proposal.md`
+- 实施文档：`work-ally/docs/implementation/work-ally-implementation-guide.md`
+- 当前实现：`work-ally/`
+- 参考样例：`/Users/allenfeng/Development/Repositories/third/nanobot-main`
+
+---
+
+## 总体原则
+
+在所有 feature 之前，先固定六条全局原则：
+
+1. **先把一个主 Agent 跑顺**
+   - 先让单 Agent 稳定承接日常事务，再考虑扩编。
+2. **用户视角简单，系统边界清楚**
+   - 用户看到的是自然、简单的产品概念；系统内部要把会话、路由、执行上下文严格拆开。
+3. **产品应统一安装，工作空间只保留资产**
+   - 产品本体不应复制到每个工程里；工程里保留的应是资产、状态和映射，而不是一份份产品副本。
+4. **优先做明确 feature，暂不做大而全平台**
+   - 已经明确的 feature 进入实施。
+   - 不明确、依赖未来官方能力成熟的方向，标记为“暂不开始”。
+5. **战略防锁定，战术单押 Codex**
+   - 当前阶段继续以 Codex 作为唯一主引擎，不做多引擎平台化。
+   - 但产品语义、数据模型和路由设计不能写死成 Codex 私有概念。
+6. **只补产品缝隙，不重造 Agent 平台**
+   - 只有飞书、工程工作区、异步调度、官方 Agent 之间的缝隙，才值得自己做。
+   - 能直接复用官方能力的地方，不自己重建第二套平台。
+
+## 产品边界（派工前必读）
+
+这一节不是 feature，而是所有 feature 的架构边界。后续派工时，应先检查是否越界。
+
+### 这是什么
+
+`work-ally` 当前应被定义为：
+
+> **面向飞书的、按工程隔离的 Agent 编排层。**
+
+它不是：
+
+- 通用 Agent OS
+- 多模型统一管理平台
+- 自建 prompt / role / workflow 大平台
+- 重型多 Agent 组织系统
+
+### 必须自己做
+
+以下是产品核心缝隙，应该由自己掌握：
+
+- 飞书消息收发与结果回送
+- 工程级身份、规则、工作空间映射
+- 定时任务注册、调度与异线程执行
+- 会话目标路由与最小恢复入口
+- 统一安装、按当前工程生效的 CLI 包装
+- 一层很薄的执行引擎适配边界
+
+### 优先复用官方，不自己重做
+
+以下能力优先借助官方 Agent / CLI 能力完成，不自己重造：
+
+- 原生 thread / session 运行语义
+- review lane / reviewer 能力
+- reasoning effort / mode 的底层调参面
+- prompt 注入体系与个人级配置体系
+- automations 之外的大规模工作流平台能力
+
+### 引擎策略
+
+关于底层是否未来可替换，这里的口径固定如下：
+
+- **战略上防锁定，战术上单押 Codex**
+- 当前不做“多引擎统一平台”
+- 但产品核心概念必须保持中立，只认：会话、定时任务、投递目标、模式、评审
+- 不把 `thread`、`slash command`、厂商专有 automation 概念直接升格为产品主协议
+
+### 架构要求
+
+为未来可能的引擎替换留空间，但只留“薄边界”，不要提前平台化：
+
+- 产品自己持有主 ID：`conversation_id`、`task_id`、`delivery_target_id`
+- 厂商运行时只作为挂接：`engine`、`engine_session_id`
+- 同引擎续聊可以直接 resume
+- 跨引擎接棒不承诺原生续聊，只允许“基于摘要或冻结 brief 新开执行”
+
+### 明确不做什么
+
+当前阶段明确不做以下事情：
+
+- 为假想的第二引擎提前造一整套中立 prompt / soul 平台
+- 自建完整 thread OS 或 session 平台
+- 自建复杂多 Agent 编制、总线、组织架构
+- 为管理感而过早建设重型 dashboard / workflow engine
+
+判断一个新 feature 是否应进入主线，只问一句：
+
+> **它是不是在弥合飞书、工程工作区、异步编排、官方 Agent 之间的缝隙？**
+
+如果不是，大概率就是在造轮子。
+
+---
+
+# Feature 1：定时任务
+
+**优先级：P0 / 立即开始**
+
+这是当前最明确、最值得开始做的 feature。
+
+## 1.1 背景
+
+当前 `work-ally` 已经有 `routine / scheduler` 的工程能力，但产品层仍然偏工程化：
+
+- 任务定义主要来自工作空间中的 routine 文件
+- 调度是 bridge 内部的 scheduler 逻辑
+- 更像“实现仓库的主动能力”，而不是“用户可在聊天里自然使用的产品能力”
+
+但从真实使用场景看，用户需要的是一种非常自然的能力：
+
+- 在飞书里说一句话
+- 系统理解后自动注册一个未来要做的事情
+- 到点后自动执行
+- 执行完把结果发回来
+
+这件事的重要性非常高，因为它直接决定系统能否从“被动聊天”走向“主动代办”。
+
+另外，这个 feature 和上下文污染问题强相关：
+
+- 定时任务执行时，不能污染用户当前正在进行的对话 thread
+- 但执行结果又必须能回到用户可见的飞书对话里
+
+因此，定时任务不是一个附属小功能，而是产品架构中的关键 feature。
+
+## 1.2 目标与目的
+
+### 目标
+
+把“定时”统一收敛成一个用户可理解、模型可注册、系统可调度的 feature：**定时任务**。
+
+### 目的
+
+让用户可以通过自然语言直接创建长期任务，并让系统在未来某个时间点自动完成它，而不污染当前聊天上下文。
+
+### 产品定义
+
+> **定时任务 = 由模型注册、由产品调度、以冻结任务说明为输入、在独立新会话中执行、结果回送目标飞书对话且不污染当前 thread 的长期任务。**
+
+### 目标结果
+
+定时任务 feature 做完后，用户应该能够这样使用：
+
+- “每天 9 点提醒我喝水”
+- “每天晚上 6 点根据今天的工作记录给我生成一个表格化日报”
+- “每周一早上帮我整理上周项目进展并发给我”
+
+而系统应该做到：
+
+- 模型负责理解并注册
+- 产品负责调度和投递
+- 到点后新开独立执行会话
+- 结果发回飞书
+- 不影响用户当前正在聊的主会话
+
+## 1.3 策略
+
+### 策略 A：用户面只保留一个概念
+
+对用户只保留一个概念：**定时任务**。
+
+当前阶段**不要**再拆成：
+
+- 提醒类
+- 任务类
+- heartbeat 类
+- cron 类
+
+这些可以是内部实现细节，但不应成为用户需要理解的产品概念。
+
+### 策略 B：注册由模型通过工具完成
+
+注册入口在聊天里。
+
+模型通过一个统一工具去注册定时任务。
+
+这意味着：
+
+- 用户不需要自己回工作区写配置
+- 用户不需要理解 scheduler / cron / YAML
+- 模型只需要把定时任务理解成一个明确的工具调用能力
+
+### 策略 C：注册时冻结执行 brief
+
+必须把下面这条写入 skill / 提示词：
+
+> **注册时想清楚，执行时不思旧账。**
+
+也就是说，模型在注册任务时，必须把任务“编译”成一份冻结后的执行 brief。
+
+未来新开的执行会话，拿到的就是这份 brief，而不是当前聊天上下文。
+
+注册时至少必须固定清楚：
+
+- 什么时候触发
+- 要做什么
+- 基于什么输入做
+- 输出长什么样
+- 结果发回哪里
+- 如果信息不足，执行时如何报阻塞
+
+如果信息不足，模型应先澄清，而不是草率注册。
+
+### 策略 D：执行时永远新开会话
+
+定时任务的执行默认固定为：**新会话**。
+
+当前阶段不要把 `reuse/new` 暴露给用户，也不要让定时任务复用用户当前会话。
+
+原因：
+
+- 定时任务是为了全心做一件独立的事
+- 它的结果不应污染当前对话上下文
+- 如果允许复用当前 thread，上下文污染会重新出现
+
+### 策略 E：按“对话级路由”回送结果
+
+这里要明确区分三个概念：
+
+1. **飞书对话目标**
+   - 结果最终发到哪里
+2. **定时任务本身**
+   - 什么时候跑、跑什么
+3. **执行 thread**
+   - 到点后在哪个独立上下文里跑
+
+系统不能按 bot 路由，也不能按当前 thread 路由。
+
+必须按**飞书对话**路由。
+
+这条很重要，因为未来一定会出现：
+
+- 私聊
+- 群
+- 总指挥官与多个项目负责人 Agent 协同
+
+所以现在不能把结果投递模型写死成“默认私聊”。
+
+### 策略 F：V1 默认使用来源对话作为投递目标
+
+虽然数据模型必须支持“对话级路由”，但 V1 的策略可以先简单：
+
+- 如果用户在某个飞书对话里注册任务
+- 默认就把该对话记录为任务的投递目标
+- 以后执行完，也默认发回这个对话
+
+这意味着：
+
+- V1 不需要复杂的多目标投递系统
+- 但底层抽象已经为群和多 Agent 协同留好了空间
+
+### 策略 G：同窗回送，异线程执行
+
+这是本 feature 的硬口径：
+
+> **同窗回送，异线程执行。**
+
+也就是说：
+
+- 用户可以在同一个飞书聊天里看到定时任务结果
+- 但系统内部必须保证：执行 thread 与当前主会话 thread 隔离
+
+### 策略 H：保留最小管理面
+
+虽然产品概念统一成“定时任务”，但系统不能没有管理面。
+
+至少必须支持：
+
+- 查看已有任务
+- 取消 / 停用任务
+- 查看最近一次执行结果或状态
+
+否则定时任务一多，系统就会失控。
+
+## 1.4 非目标
+
+当前阶段，这个 feature 明确**不以**下列目标为交付标准：
+
+- 不做复杂的 cron / rule 表达式产品教育
+- 不做用户手写配置驱动的定时体系
+- 不做复用当前主会话上下文的定时执行
+- 不做一步到位的任务中台 / 任务运营平台
+
+## 1.5 暂不开始
+
+以下内容和定时任务相关，但当前阶段**暂不开始**：
+
+- 复杂的多目标投递策略
+- 非来源对话的高级路由配置
+- 定时任务的多级权限体系
+- 大规模任务面板 / 管理后台
+- 定时任务与多 Agent 团队协同的深度联动
+
+---
+
+# Feature 2：产品包装与统一安装
+
+**优先级：P0 / 明确要开始**
+
+这是一个非常重要的产品包装 feature。
+
+## 2.1 背景
+
+当前如果把 `work-ally` 理解成“每个工程里都放一份脚本或产品副本”，会带来明显问题：
+
+- 一台电脑上可能有很多工程
+- 每个工程都对应一个助理
+- 如果每个工程都复制一份产品入口或实现，更新会变成灾难
+- 用户也会误以为这是“要拷贝进工程里的脚本”，而不是一个真正的产品
+
+从产品视角看，这不是好包装。
+
+更合理的直觉应该像 Codex CLI 一样：
+
+- 产品被统一安装一次
+- 命令注册在系统可执行路径里
+- 我在哪个工程目录下执行，就控制哪个工程对应的助理
+
+这更像一个产品，而不是一份散落在各工程里的脚本。
+
+## 2.2 目标与目的
+
+### 目标
+
+把 `work-ally` 定义成一个**统一安装、按当前工程生效**的产品，而不是“拷贝进每个工程里”的脚本集合。
+
+### 目的
+
+解决下面几个问题：
+
+- 降低多工程使用成本
+- 降低更新成本
+- 让产品包装更接近真正的 CLI / 可执行工具
+- 保持“一个工程 = 一个助理”的边界，但不把产品本体复制进每个工程
+
+### 产品定义
+
+> **产品统一安装一次；工程只保存资产与状态；用户在某个工程目录执行命令时，命令自动作用于该工程对应的助理。**
+
+### 目标结果
+
+用户应能获得如下体验：
+
+- `ally setup`
+- `ally start`
+- `ally stop`
+- `ally status`
+- `ally update`
+
+并且：
+
+- 在哪个工程目录下执行，就作用于哪个工程
+- 更新产品只更新一处
+- 不需要在每个工程里维护一份产品脚本副本
+
+## 2.3 策略
+
+### 当前先落地的切片
+
+在正式安装器 / Homebrew 之前，先必须落地一个开发态统一入口：
+
+- 允许直接把实现仓库里的 `ally.sh` 暴露成 shell 命令
+- 从任意 workspace 根目录执行时，按**当前目录**生效
+- 已初始化 workspace 下再从子目录执行时，按**最近一个工作空间根目录**生效
+- 绝不能再把“脚本文件所在目录”误判成被控制的 workspace
+
+### 策略 A：产品本体统一安装
+
+产品本体应作为：
+
+- 一个二进制
+- 或一个注册到 PATH 的统一命令
+- 或一个统一安装的脚本入口
+
+总之，它应是**系统级安装**，而不是每个工程各自复制一份。
+
+### 策略 B：工作空间只保留资产，不保留产品副本
+
+工程目录中应该保留的是：
+
+- `AGENTS.md`
+- memory / knowledge / routines
+- `.work-ally/` 运行态
+- 工作空间映射或配置文件
+
+而不是产品实现本体的一份副本。
+
+### 策略 C：命令按当前工程生效
+
+命令运行时应以：
+
+- 当前工作目录
+- 或显式指定的 workspace 路径
+
+来决定控制哪个工程。
+
+也就是说，命令的基本语义应该是：
+
+- **我在哪个工程目录下执行，就控制哪个工程。**
+
+### 策略 D：统一更新路径
+
+更新产品时，应更新全局安装的一处，而不是在多个工程里分别更新。
+
+这样才能避免：
+
+- 多个工程版本漂移
+- 每个工程都要手动跑更新
+- 用户分不清“更新产品”和“更新工程资产”
+
+### 策略 E：保留工程边界，不做全局混合人格
+
+虽然产品统一安装，但不能把所有工程的身份和上下文混到全局产品目录里。
+
+必须坚持：
+
+- 产品是全局安装的
+- 但助理身份、项目规则、长期资产仍然在工程侧
+
+也就是说：
+
+- **安装统一**
+- **身份按工程隔离**
+
+### 策略 F：本 feature 会改写当前“每工程一个 facade 脚本”的主包装思路
+
+当前实现与文档里，对消费侧入口仍偏向一个项目内的 facade 概念。
+
+这条 feature 明确意味着：
+
+- 后续应把“每工程复制一份入口脚本”从主包装思路中降级
+- 主包装应改成“统一安装的 ally 命令”
+- 如果未来还保留本地 shim，也只能是兼容层，而不是主路径
+
+## 2.4 非目标
+
+当前阶段，这个 feature 明确**不以**下列目标为交付标准：
+
+- 不做完整的安装器产品矩阵
+- 不做面向所有语言和所有系统的一步到位发布体系
+- 不做全局人格、全局记忆、全局项目混合视图
+- 不做与工程目录彻底脱钩的远程控制平台
+
+## 2.5 暂不开始
+
+以下和安装包装相关，但当前阶段**暂不开始**：
+
+- 多版本并存管理
+- 插件市场式安装体系
+- 企业级安装器 / GUI 安装器
+- 跨机器自动分发产品升级
+- 重型全局控制中心
+
+---
+
+# Feature 3：会话 mobility
+
+**优先级：P0 / 应尽快开始**
+
+## 3.1 背景
+
+`work-ally` 的核心价值之一，是让用户可以在不同场景下接续同一个工作空间里的工作：
+
+- 在电脑前用官方 Codex 工作
+- 出门时从飞书继续
+- 回来后再接着做
+
+当前实现已经有一部分基础：
+
+- 会话状态是文件化的
+- 普通消息会默认复用当前绑定 thread
+- `/new` 可以切换到新 thread
+
+但从产品层看，会话的可见性和可管理性还不够。
+
+## 3.2 目标与目的
+
+### 目标
+
+把当前隐性的 thread 复用，提升为显性的“会话接力能力”。
+
+### 目的
+
+让用户真正获得：
+
+> **我可以随时接上工作。**
+
+### 目标结果
+
+用户应该能够：
+
+- 查看最近会话
+- 恢复会话
+- 分叉会话
+- 归档会话
+- 明确知道当前会话状态
+
+## 3.3 策略
+
+### 策略 A：前台统一使用“会话”概念
+
+不要让飞书用户理解 `thread`。
+
+对外统一用：
+
+- 会话
+- 当前会话
+- 新会话
+- 恢复会话
+- 会话列表
+
+### 策略 B：继续基于官方 thread 能力实现
+
+底层仍然用官方 `thread/list/read/resume/fork/archive` 能力。
+
+不要自造协议，也不要把“恢复会话”错误理解成“恢复某个运行进程”。
+
+### 策略 C：会话是连续性产品面，不是技术调试面
+
+重点不是暴露 `threadId`，而是暴露：
+
+- 当前会话是否活跃
+- 最近有没有结果
+- 有没有待审批 / 待输入
+- 哪条会话是当前默认会话
+
+## 3.4 非目标
+
+当前阶段，这个 feature 明确**不以**下列目标为交付标准：
+
+- 不做完整聊天产品意义上的会话管理器
+- 不做复杂 thread 调试工具或底层 ID 暴露面板
+- 不做跨引擎原生无损续聊承诺
+- 不做跨多个 workspace 的统一会话中枢
+
+## 3.5 暂不开始
+
+- 多维度会话检索
+- 复杂会话标签系统
+- 会话知识图谱
+- 跨多个 workspace 的会话统一检索
+
+---
+
+# Feature 4：记忆系统
+
+**优先级：P0 / 应尽快开始**
+
+这是当前产品主线里非常关键、但还没有真正产品化收口的 feature。
+
+## 4.1 背景
+
+从产品视角看，记忆不是“可有可无的增强项”，而是长期陪伴式 Agent 能否成立的基础能力。
+
+用户和 Agent 的关系不是一次性问答，而是持续合作：
+
+- 今天交代的偏好，明天还应该记得
+- 今天纠正过的误区，以后不应该重复犯
+- 用户长期工作方式、协作边界、关系结构，不应每次重讲
+
+当前 `work-ally` 其实已经有了不错的地基：
+
+- `memory/archive/` 已经在落原始黑匣子归档
+- `.work-ally/sessions/`、`.work-ally/runs/` 已经在落会话与运行台账
+- `nightly-memory-digest` 已经能把原材料提炼到 `memory/daily/` 与 `memory/long-term/`
+
+但从产品定义上看，它还没有完全收口成真正可依赖的“记忆系统”。
+
+主要缺口在于：
+
+- 原始对话记录、记忆、知识这三层概念还没有被明确拉开
+- 当前更像“已有 digest 产物”，还不是“每次对话都可靠带入的重要记忆”
+- 记忆的可审阅、可纠错、可删除边界还不够明确
+- 还不能完全保证未来对话一定稳定吃到记忆，而不是依赖模型临场去读文件
+
+因此，这个 feature 的本质不是“再加一个 memory 目录”，而是把“黑匣子 → 提炼 → 加载 → 纠错”这条链路定成产品能力。
+
+### 行业参考口径
+
+对外部产品和框架的调查，给了三个很清晰的启发：
+
+- ChatGPT 产品里的 memory 明确区分了 **saved memories** 与 **chat history**，说明“记忆”和“历史对话”本来就不是一回事。
+- Claude Code 把 `CLAUDE.md` 这类**指令文件**，和自动积累的 **auto memory** 分开，说明“规则 / 指令”和“从互动中长出来的记忆”也不是一回事。
+- LangGraph 这类 agent 框架则把 memory 分成 **thread 内短期记忆** 与 **跨会话长期记忆**，并明确承认记忆既可以走热路径，也可以走后台异步路径。
+
+这些行业做法并不要求我们照搬实现，但它们共同说明：
+
+- 分层是必要的
+- 后台异步提炼是合理的
+- 记忆必须与原始历史分离
+- 记忆不能只靠一份主指令文件硬扛
+
+## 4.2 目标与目的
+
+### 目标
+
+建立一个**轻量、可审阅、持续增长**的记忆系统，让 Agent 能从长期互动中沉淀真正有用的记忆，而不是每次都从零开始。
+
+### 目的
+
+实现下面四件事：
+
+1. **先有米**
+   - 先稳定拿到高质量原始材料，而不是一上来讨论高阶记忆算法。
+2. **把原始对话和记忆分开**
+   - 原始流水是黑匣子；记忆是提炼结果，不能混成一层。
+3. **让记忆异步成长**
+   - 通过日终 digest 等后台机制，持续把对话中的高价值信息沉淀下来。
+4. **让未来对话可靠带上记忆**
+   - 重要记忆必须是产品层可靠加载，而不是靠模型“碰运气想起来”。
+
+### 产品定义
+
+> **记忆系统 = 先完整保存黑匣子原材料，再通过异步 digest 提炼出可审阅、可删除、可加载的长期记忆，并在后续对话中稳定带入，而不是把原始对话直接当记忆。**
+
+### 目标结果
+
+记忆 feature 做完后，系统应做到：
+
+- 每一轮关键交互都有原始留档
+- 每天结束前，系统能自动读当天原材料并提炼
+- 长期记忆会逐步增长，但不会无限发散
+- 后续对话默认能带上重要记忆
+- 用户可以查看、修正、删除记忆
+
+## 4.3 策略
+
+### 策略 A：黑匣子归档先行，先把“米”攒够
+
+第一优先级不是“记忆写得多聪明”，而是“原材料留得够不够完整”。
+
+因此，黑匣子归档应被视为一等公民。
+
+至少应稳定保留：
+
+- 用户输入
+- 用户可见的模型输出
+- 关键 system event
+- 关键审批 / 阻塞 / 运行结果
+
+归档维度应优先便于人工检查与机器消费：
+
+- 按日期分桶
+- 按会话 / 对话目标区分
+- 保持标准化、可 grep、可回放
+
+### 策略 B：明确区分三层资产
+
+这件事必须明确分成三层：
+
+1. **对话记录 / 黑匣子 archive**
+   - 原始事件流水，是事实原材料。
+2. **记忆 memory**
+   - 从 archive 中提炼出的高价值、可复用信息。
+3. **知识 knowledge**
+   - 来自文档、代码、外部资料、项目材料的事实知识。
+
+这三者不能混写在一个桶里。
+
+尤其要强调：
+
+- archive 不是 memory
+- memory 不是 knowledge
+- memory 的可信度来自可回溯到 archive，而不是“看起来像总结”
+
+### 策略 C：V1 以“后台 digest”作为主更新路径
+
+当前阶段，记忆更新的主路径应固定为：**异步 digest**。
+
+也就是：
+
+- 平时先保存原材料
+- 到固定时间点再新开独立执行会话
+- 读取当天 archive 与当前记忆快照
+- 产出新的 daily memory 与 long-term memory
+
+这样做的原因是：
+
+- 更稳定
+- 更容易审阅
+- 不污染当前对话链路
+- 不会让每轮交互都承担“要不要记住这个”的额外负担
+
+当前阶段不要把“每轮实时自动写记忆”当作主路径。
+
+### 策略 D：记忆输出分成“当日记忆”和“长期记忆”两层
+
+V1 应固定只产出两层结果：
+
+1. **当日记忆 `memory/daily/YYYY-MM-DD.md`**
+   - 记录今天发生了什么、今天学到了什么、今天形成了哪些重要结论。
+2. **长期记忆 `memory/long-term/MEMORY.md`**
+   - 只保留长期稳定有效的事实和约束。
+
+这样做的好处是：
+
+- 避免所有信息都堆进一份总记忆里
+- 让“今日上下文”与“长期稳定规则”分开
+- 便于未来控制加载量
+
+### 策略 E：记忆加载必须由产品层兜底，不能靠模型自觉
+
+这是本 feature 最关键的一条产品判断。
+
+当前官方 Codex 能稳定自动发现的是 `AGENTS.md` 指令链，而不是你的 `memory/long-term/MEMORY.md` 或 `memory/daily/*.md` 本身。
+
+因此，产品不能把“未来对话会不会读到记忆”寄托在：
+
+- 模型自己想起来去读
+- 用户手动提醒它去看
+- 把所有记忆硬塞进根 `AGENTS.md`
+
+V1 必须建立**明确的记忆加载合同**。
+
+也就是说，产品层要负责保证：
+
+- 长期记忆在新会话或关键 turn 中能稳定带入
+- 必要时追加最近的日记忆
+- 带入的是经过压缩和筛选的记忆，而不是原始 archive
+
+### 策略 F：长期记忆只收“稳定、可复用、高价值”的东西
+
+并不是所有对话都值得变成长期记忆。
+
+V1 应只允许以下内容进入长期记忆：
+
+- 用户稳定偏好
+- 长期有效的协作约束
+- 项目内反复出现的重要规则
+- 用户多次纠正出来的高价值事实
+- 持续有效的人物关系、职责边界、项目背景
+
+明确不应进入长期记忆的内容包括：
+
+- 寒暄
+- 单次失败
+- 一次性报错
+- thread / turn / message id
+- routine 运行元数据
+- 临时情绪表达
+- 已过期的短期状态
+
+### 策略 G：记忆必须可审阅、可纠错、可删除
+
+如果记忆会自动增长，它就必须可控。
+
+否则系统会出现两个问题：
+
+- 错误记忆被不断固化
+- 用户对系统失去信任
+
+因此，V1 至少要具备最小管理面：
+
+- 看当前长期记忆
+- 看最近日记忆
+- 删除或修正错误记忆
+- 明确知道“系统记住了什么”
+
+### 策略 H：敏感信息宁缺毋滥
+
+不是所有信息都应该自动升格为记忆。
+
+当前阶段应坚持：
+
+- 对高敏感信息保守处理
+- 不因为“技术上能记”就默认去记
+- 不把用户隐私、一次性个人状态、模糊推断自动固化为长期记忆
+
+如无明确必要，应偏向不记，而不是多记。
+
+### 策略 I：不要一上来做向量库优先的重型记忆平台
+
+从业界看，长期记忆常见会和向量检索、文件搜索、嵌入检索结合，但这不代表你现在就应该先做重型 memory platform。
+
+当前阶段更合理的路线是：
+
+- 先把文件化、可审阅、可回溯的记忆闭环做稳
+- 先解决 archive、digest、load、delete 这四件核心问题
+- 以后在规模真的上来时，再考虑向量化检索增强
+
+不要因为“业界有人做 memory retrieval”就提前把自己带进复杂基础设施。
+
+### 策略 J：坚持文件优先，并把原材料格式尽早冻结
+
+这里必须再加一条硬边界：**记忆系统以文本文件为导向，不引入向量库、数据库或黑盒存储作为主路径。**
+
+原因不是“数据库一定不好”，而是当前阶段最重要的是：
+
+- 可审阅
+- 可迁移
+- 可版本化
+- 可回溯
+- 可长期稳定
+
+因此，V1 的文件合同建议固定为：
+
+1. **黑匣子 archive：NDJSON**
+   - 适合逐条追加
+   - 适合长期保留原始事件
+   - 适合后续用脚本、grep、jq 一类工具处理
+2. **记忆 memory：Markdown**
+   - 适合人读、人改、人审阅
+   - 适合作为长期工作空间资产进入版本管理
+3. **内部运行态 / 元数据：JSON**
+   - 只用于状态、索引、调度元信息，不把它当作用户记忆正文
+
+这里的判断应尽量固定，不要反复切换。
+
+尤其要强调：
+
+- 原材料格式一旦定下来，应把它当作长期合同
+- 后续可以升级的是 digest / 压缩 / 提炼逻辑
+- 不应频繁改写 archive 的底层存储格式
+
+### 策略 K：把“原材料”和“原材料加工”彻底拆开
+
+工作流上必须明确区分两条线：
+
+1. **原材料层**
+   - 负责保存事实，不负责解释事实
+2. **加工层**
+   - 负责提炼、压缩、归纳、索引、合并、纠错
+
+这两层不能混在一起。
+
+也就是说：
+
+- archive 保存后，原则上不再回写改造
+- 新版本的记忆算法，应重新读取旧 archive 再产出新 memory
+- 原材料应该尽可能保持稳定、忠实、可回放
+- 加工逻辑可以随着产品迭代不断优化
+
+这条边界非常关键，因为它决定系统是不是具备“未来可重放、可重建”的能力。
+
+### 策略 L：`AGENTS.md` 是宪法，memory 是被注入的工作记忆
+
+这里必须把文件本质想清楚。
+
+对 Codex 来说，`AGENTS.md` 的语义更接近：
+
+- 唤醒时优先读取的工作区主指令
+- 主身份说明 / 宪法 / 长期规则
+- 告诉模型“你是谁、边界是什么、怎么工作”
+
+而 memory 不应扮演这个角色。
+
+更合理的分工应该是：
+
+- **`AGENTS.md`**：短、稳、长期有效；定义身份、规则、边界、记忆使用原则
+- **`memory/long-term/MEMORY.md`**：长期工作记忆正文
+- **`memory/daily/*.md`**：短期 / 近日记忆
+- **archive NDJSON**：原始黑匣子事实来源
+
+也就是说：
+
+- `AGENTS.md` 不等于 memory
+- memory 也不应膨胀成第二份 `AGENTS.md`
+- `AGENTS.md` 应只说明“记忆系统存在、记忆在哪、如何使用”，而不是承载全部记忆正文
+
+### 策略 M：记忆必须有明确的注入合同，而不是靠模型自己去找
+
+由于 Codex 会自动发现并加载 `AGENTS.md` 指令链，但不会自动把 `memory/long-term/MEMORY.md` 当成天然首屏上下文，因此必须建立记忆注入合同。
+
+V1 更合理的口径是：
+
+- `AGENTS.md` 负责声明记忆原则和位置
+- 产品层负责在**新会话 / 关键 turn / 定时执行**前，把必要的 memory 以紧凑形式带入上下文
+- ongoing thread 继续依赖 thread 自身上下文，不必每轮都全量重灌 memory
+
+因此，memory 的本质可以理解为：
+
+> **它不是天然“第一个被加载的文件”，而是产品需要稳定注入到模型上下文里的工作记忆。**
+
+这个判断很重要，因为它避免了两个误区：
+
+- 误以为只要文件存在，模型就一定会读到
+- 误以为把所有 memory 塞进 `AGENTS.md` 就等于解决了加载问题
+
+### 策略 N：记忆采用“核心正文 + 渐进式披露”结构
+
+为了避免 memory 爆炸，V1 不应只有一份无限变长的总记忆。
+
+更合理的结构是：
+
+- `MEMORY.md` 保留高密度、必须常驻的核心记忆
+- 对某些较长、但仍然重要的专题，允许拆成主题文件
+- `MEMORY.md` 中只保留必要摘要与指向关系，按需再展开
+
+但这里要把握分寸：
+
+- 不能把 `MEMORY.md` 做成纯索引目录
+- 也不能把所有细节都塞回 `MEMORY.md`
+
+更合理的原则是：
+
+- **核心事实常驻正文**
+- **次级细节按主题渐进披露**
+
+这和 skill 的思路很像：不是把一切都预先塞满上下文，而是把真正需要常驻的内容留下，把其余内容做成可按需展开的工作资产。
+
+## 4.4 非目标
+
+当前阶段，这个 feature 明确**不以**下列目标为交付标准：
+
+- 不做全量实时自动记忆系统
+- 不做向量库优先的重型记忆平台
+- 不做不可审阅的黑盒记忆数据库
+- 不做“把全部聊天记录都自动当长期记忆”
+- 不做把记忆硬塞进根 `AGENTS.md` 的粗暴方案
+- 不做频繁变更的 archive 底层存储格式
+
+## 4.5 暂不开始
+
+以下和记忆相关，但当前阶段**暂不开始**：
+
+- 记忆的复杂语义检索 / 向量召回体系
+- 多层级 memory scope（个人 / 工程 / 组织）的复杂治理
+- 每条记忆的独立审批工作流
+- 自动敏感信息分类与精细权限系统
+- 基于记忆的复杂推荐 / 主动推断系统
+
+---
+
+# Feature 5：模式与推理深度
+
+**优先级：P1 / 明确要做**
+
+## 5.1 背景
+
+很多“一个 Agent 好像不够用”的感受，不一定来自缺少角色，而可能来自：
+
+- 思考深度不对
+- 输出风格不对
+- 当前任务模式不对
+
+官方已经提供了 reasoning effort / summary / personality / profile 等能力，因此这是一条清晰、可落地的增强路线。
+
+## 5.2 目标与目的
+
+### 目标
+
+让用户可以根据任务类型切换工作模式，而不是强迫所有任务都用同一种工作方式。
+
+### 目的
+
+先通过模式能力吸收复杂度，而不是过早引入团队系统。
+
+### 目标结果
+
+用户至少应能切换：
+
+- `fast`
+- `balanced`
+- `deep`
+
+后续再考虑：
+
+- `reviewer`
+- `planner`
+- `builder`
+
+## 5.3 策略
+
+### 策略 A：先做产品级抽象，不暴露底层细节
+
+不要一开始就暴露：
+
+- effort
+- summary
+- verbosity
+- personality 的所有原子选项
+
+先做 mode 层，让用户用简单的词完成切换。
+
+### 策略 B：优先做会话级 mode
+
+mode 最有价值的落点是：**会话级默认值**。
+
+而不是只有 env 默认值。
+
+### 策略 C：角色模式先做成 mode，不做成团队
+
+如果要先试“第二角色感”，优先落成：
+
+- reviewer mode
+- planner mode
+- builder mode
+
+而不是一开始就变成多常驻 Agent。
+
+## 5.4 暂不开始
+
+- 全量暴露底层模型调参面板
+- 每轮 turn 都高度可编程的复杂模式矩阵
+- 为每个 mode 配一个平级主身份文件
+
+---
+
+# Feature 6：Reviewer / 交叉评审
+
+**优先级：P1 / 明确要做**
+
+## 6.1 背景
+
+“自己做自己审”天然有盲区。
+
+如果未来只优先做一个“第二角色”，最值得先做的是 reviewer，而不是 planner。
+
+因为 reviewer：
+
+- 价值稳定
+- 风险较低
+- 更符合官方 review lane 的思路
+
+## 6.2 目标与目的
+
+### 目标
+
+提供一个稳定的“交叉评审”能力。
+
+### 目的
+
+用最小代价引入第二视角，降低“自己审自己”的问题。
+
+### 目标结果
+
+用户应能触发一种 reviewer 形态，对当前工作进行独立复核，并得到结构化反馈。
+
+## 6.3 策略
+
+### 策略 A：优先做 reviewer mode / review lane
+
+优先落成：
+
+- reviewer mode
+- detached review lane
+- review digest / summary
+
+### 策略 B：不做常驻 reviewer 人设
+
+当前阶段不要做：
+
+- 常驻 reviewer ally
+- reviewer 团队注册系统
+
+先把 reviewer 作为能力，不要先做成编制。
+
+## 6.4 暂不开始
+
+- 多 reviewer 并发协作
+- reviewer 组织架构
+- reviewer 专属长期会话体系
+
+---
+
+# Feature 7：汇报与把关
+
+**优先级：P2 / 后续增强**
+
+## 7.1 背景
+
+当基础工作流跑顺以后，下一步要解决的是：
+
+- 让用户更像经理
+- 减少手工搬运上下文
+- 减少反复追问状态
+
+## 7.2 目标与目的
+
+### 目标
+
+建立阶段性汇报、digest、summary 这类“管理感”能力。
+
+### 目的
+
+让系统不仅会做事，还会主动、清楚、稳定地汇报。
+
+## 7.3 策略
+
+### 策略 A：优先做 digest 和阶段性总结
+
+先做：
+
+- nightly digest
+- reviewer summary
+- 风险与阻塞提炼
+- 任务阶段性回报
+
+### 策略 B：建立在前置 feature 稳定之上
+
+汇报能力必须建立在：
+
+- 会话 continuity 稳定
+- mode 稳定
+- 定时任务稳定
+- 记忆系统稳定
+
+否则汇报会变成对不稳定系统的包装。
+
+## 7.4 暂不开始
+
+- 复杂 BI 面板
+- 多层级审批工作流
+- 重型管理后台
+
+---
+
+# Feature 8：多工程状态感知
+
+**优先级：P2 / 后续增强**
+
+## 8.1 背景
+
+未来你一定不会只管一个工程。
+
+但多工程总览建立在单工程工作流已经稳定的基础之上。
+
+## 8.2 目标与目的
+
+### 目标
+
+让用户逐渐获得跨工程的管理视角。
+
+### 目的
+
+知道：
+
+- 哪个工程在忙
+- 哪个工程卡住了
+- 哪个工程在等审批
+
+## 8.3 策略
+
+### 策略 A：先做轻量状态感知，不做重面板
+
+先做统一状态总览、摘要、阻塞提示。
+
+### 策略 B：建立在单工程 feature 跑顺后
+
+如果单工程都还没稳，多工程聚合只会放大噪音。
+
+## 8.4 暂不开始
+
+- 复杂多工程控制台
+- 跨工程自动任务编排
+- 多项目统一资源调度系统
+
+---
+
+# Feature 9：工程内团队角色 / 多 Agent 协同
+
+**优先级：P3 / 暂不开始 / 进入预研**
+
+## 9.1 背景
+
+这个痛点是真实存在的：
+
+- 术业有专攻
+- 需要交叉评审
+- 主线程会过载
+- 你本人需要分发和把关
+
+但它同时也是最容易把产品带向“第二套 agent 平台”的方向。
+
+## 9.2 目标与目的
+
+### 目标
+
+明确：这件事未来可能做，但当前不进入实现主线。
+
+### 目的
+
+避免在基础主线尚未稳定时，过早进入复杂团队系统。
+
+## 9.3 策略
+
+### 策略 A：先验证单 Agent + reviewer + mode 是否足够
+
+在真正进入团队模式前，先看这些能力能否吸收大部分复杂度：
+
+- 单 Agent
+- mode / profile
+- detached review
+- digest / 汇报
+- 定时任务
+- 记忆系统
+
+### 策略 B：未来优先复用官方能力
+
+如果未来要做：
+
+- multi-agent
+- collaboration mode
+- 独立 review lane
+
+优先复用官方成熟能力，不自己造一套重体系。
+
+### 策略 C：只有满足触发条件才进入实施
+
+触发条件至少包括：
+
+- 单 Agent 已稳定承接大多数日常事务
+- reviewer / digest / mode 仍无法吸收新增复杂度
+- 第二角色需求持续、重复、明确
+- 官方相关 surface 已更成熟
+
+## 9.4 暂不开始
+
+当前明确不进入主线：
+
+- 多常驻 ally
+- 复杂角色注册中心
+- ally 间长期互通总线
+- 群体组织架构系统
+- 一个工程里多个平级主 AGENTS
+
+---
+
+## 当前派工建议
+
+### 第一批：立即开始
+
+- Feature 1：定时任务
+- Feature 2：产品包装与统一安装
+- Feature 3：会话 mobility
+- Feature 4：记忆系统
+
+### 第二批：随后开始
+
+- Feature 5：模式与推理深度
+- Feature 6：Reviewer / 交叉评审
+
+### 第三批：后续增强
+
+- Feature 7：汇报与把关
+- Feature 8：多工程状态感知
+
+### 暂不开始
+
+- Feature 9：工程内团队角色 / 多 Agent 协同
+
+---
+
+## 最终结论
+
+当前最明确、最应该开始做的 feature 仍然是：
+
+> **Feature 1：定时任务**
+
+而当前最应该补齐、否则“长期伙伴感”很难成立的 feature 是：
+
+> **Feature 4：记忆系统**
+
+它的重要性在于：
+
+- 没有黑匣子原材料，就没有真正可持续的记忆
+- 没有记忆提炼，就只能反复重讲上下文
+- 没有稳定加载，记忆文件就只是摆设
+- 没有纠错与删除，记忆会逐渐变成污染源
+
+而当前阶段最重要的总体路线仍然是：
+
+> **先把一个主 Agent 跑顺，先把日常工作接住。**