From d3f65609f0a85ac8c28cc7370e6420cf1a373ef8 Mon Sep 17 00:00:00 2001
From: Losita <2810873701@qq.com>
Date: Wed, 8 Apr 2026 00:00:11 +0800
Subject: [PATCH] =?UTF-8?q?Version:=200.9.7.dev.260408=20=E5=90=8E?=
 =?UTF-8?q?=E7=AB=AF=EF=BC=9A=201.=E9=87=8D=E5=86=99=E7=B2=97=E6=8E=92?=
 =?UTF-8?q?=E4=BF=AE=E5=A4=8D=E4=B8=8E=20Prompt=20=E9=87=8D=E6=9E=84=20han?=
 =?UTF-8?q?doff=20=E6=96=87=E6=A1=A3=20=20=20-=20=E6=9B=B4=E6=96=B0newAgen?=
 =?UTF-8?q?t/HANDOFF=5F=E7=B2=97=E6=8E=92=E4=BF=AE=E5=A4=8D=E4=B8=8EPrompt?=
 =?UTF-8?q?=E9=87=8D=E6=9E=84.md=EF=BC=9A=E8=A1=A5=E9=BD=90=E7=AC=AC1-2?=
 =?UTF-8?q?=E9=98=B6=E6=AE=B5=E5=B7=B2=E5=AE=8C=E6=88=90=E5=86=85=E5=AE=B9?=
 =?UTF-8?q?=E3=80=81=E7=9C=9F=E5=AE=9E=E9=93=BE=E8=B7=AF=E7=BB=93=E8=AE=BA?=
 =?UTF-8?q?=E3=80=81=E5=BD=93=E5=89=8D=E2=80=9C=E6=9C=AA=E5=81=9A=E4=B8=8A?=
 =?UTF-8?q?=E4=B8=8B=E6=96=87=E7=98=A6=E8=BA=AB=E4=BD=86=E5=B7=B2=E6=94=B9?=
 =?UTF-8?q?=E4=B8=8A=E4=B8=8B=E6=96=87=E5=8F=A3=E5=BE=84=E2=80=9D=E7=9A=84?=
 =?UTF-8?q?=E5=88=A4=E6=96=AD=EF=BC=8C=E4=BB=A5=E5=8F=8A=E7=AC=AC3-4?=
 =?UTF-8?q?=E9=98=B6=E6=AE=B5=E7=9A=84=E6=98=8E=E7=A1=AE=E5=AE=9E=E6=96=BD?=
 =?UTF-8?q?=E7=9B=AE=E6=A0=87=E4=B8=8E=E9=A1=BA=E5=BA=8F=20=E5=89=8D?=
 =?UTF-8?q?=E7=AB=AF=EF=BC=9A=E6=97=A0=20=E4=BB=93=E5=BA=93=EF=BC=9A?=
 =?UTF-8?q?=E6=97=A0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../newAgent/HANDOFF_粗排修复与Prompt重构.md  | 754 ++++++++++++------
 1 file changed, 531 insertions(+), 223 deletions(-)

diff --git a/backend/newAgent/HANDOFF_粗排修复与Prompt重构.md b/backend/newAgent/HANDOFF_粗排修复与Prompt重构.md
index 70d316c..416f800 100644
--- a/backend/newAgent/HANDOFF_粗排修复与Prompt重构.md
+++ b/backend/newAgent/HANDOFF_粗排修复与Prompt重构.md
@@ -2,321 +2,629 @@
 
 以下内容可直接交给下一位助理继续做。
 
-## 目标
+本文档更新时间：2026-04-07
 
-当前有两条主线要继续推进：
+## 0. 当前结论先说清
 
-1. 粗排算法修复与链路纠偏  
-目标：粗排完成后，不应该再把 LLM 引导到“手动一个个 `place` 补洞”。如果粗排后仍有 `pending`，按当前业务理解，这属于异常，应直接终止并报错，而不是继续优化或补排。
+当前可以明确分成两段看：
 
-2. `execute` 上下文瘦身 + 可插拔 prompt 重构  
-目标：把现在的“消息流水账堆砌”改成“结构化执行简报”，并且 prompt 不能写死成排程专用，要能复用于排程、加任务、学习计划等不同任务域。
+1. 第 1-2 阶段已经基本完成  
+   粗排链路已经打通，且“粗排异常 -> 正式 abort -> deliver 收口”这条后端协议已经补齐。
 
-## 用户已经明确确认的业务结论
+2. 第 3-4 阶段还没有做  
+   下游 `execute` 整体效果目前仍然很差，核心原因不是粗排本身，而是上下文过胖、提示词结构仍然混乱。  
+   所以现在**不能**用“整体排程效果”去评价第 1-2 阶段是否成功；必须先做第 3 阶段上下文瘦身，再看整体效果。
 
-- `always_execute`、后端是否自动放行、是否写库，这些是后端执行层语义，不应写进 prompt。
-- LLM 只需要按统一协议产出 `continue / confirm / ask_user / done / abort` 这类动作；后端怎么处理是后端自己的事。
-- 对排程场景，LLM 的主要职责是“粗排后的优化器”，不是“粗排补洞工”。
-- 如果“粗排完成后仍有 pending 任务”，这不是要让 LLM 手工 `place` 的正常状态，而是异常状态。
-- prompt 需要明显的文字引导，必须有编号和子编号，让 LLM 每轮都收到一份规范文本。
-- prompt 必须是可插拔的，不能写死成“排程优化”专用。
+一句话总结：
 
-## 已经完成的改动
+- 现在粗排已经能跑通；
+- 但下游本来就基本跑不通；
+- 下一步应该直接做“上下文瘦身 + prompt 结构重构”，不要再继续围绕粗排补边角。
 
-- 已修复“同一轮 user message 重复写入上下文”的问题。  
-实现位置：`backend/newAgent/node/chat.go`  
-改动点：`handleChatResume` 不再重复 `AppendHistory(schema.UserMessage(...))`，现在 user message 只在 service 层统一写入一次。
+---
 
-- 已经给 `execute` 节点加了完整上下文调试打点。  
-实现位置：`backend/newAgent/node/execute.go`  
-关键函数：`formatExecuteLLMMessagesForDebug`
+## 1. 用户已经明确确认的业务语义
 
-- 之前已经做过一轮粗排结果接入修复：`makeRoughBuildFunc` 改为使用 `HybridScheduleWithPlanMultiFunc` 的 `entries` 结果，而不是只看 `[]TaskClassItem`。  
-实现位置：`backend/service/agentsvc/agent_newagent.go`
+这些结论已经和用户对齐，后续不要再摇摆：
 
-## 当前上下文链路的真实现状
+1. 第一轮实现优先参考旧 agent 链路，不能闭门造车。
 
-`execute` 真正喂给 LLM 的消息来自：
+2. 对排程场景来说，LLM 的角色是“粗排后的优化器”，不是“粗排漏排后的人工补排器”。
 
-- `backend/newAgent/node/execute.go`
-- `backend/newAgent/prompt/execute.go`
-- `backend/newAgent/prompt/base.go`
+3. 如果粗排完成后仍有真实 `pending` 任务，这不是正常状态，而是异常状态。  
+   正确处理是：
+   - 直接终止本轮
+   - 明确报错
+   - 不再引导 LLM 去一个个 `place`
 
-当前拼装顺序是：
+4. `always_execute`、是否自动放行、是否写库，这些都是后端执行层语义，不应该写进 prompt 让 LLM 判断。
 
-- `system`：基础 persona + execute 阶段规则
-- `system`：工具摘要
-- `history`：完整历史消息
-- `system`：pinned blocks
-- `user`：运行时执行提示词
+5. prompt 必须可插拔，不能写死成“排程专用 prompt”。
 
-这套链路的核心问题不是“少了什么”，而是“保留了太多不该保留的东西”。
+6. prompt 必须保留明确编号结构，例如 `1. / 1.1 / 2.1`，不能写成一坨说明文。
 
-## 已确认的上下文膨胀问题
+7. prompt 里要保留最小可用 JSON 示例，否则 LLM 很容易输出跑偏。
 
-基于用户提供的第 13 轮上下文样本，当前冗余主要有这些：
+---
 
-- 大型 `tool result` 长期保留。  
-典型是 `get_overview`、`list_tasks`、`find_free` 的超长结果被反复塞进 history。
+## 2. 第 1 阶段：粗排链路修复，已完成
 
-- 同工具同参数的重复查询长期保留。  
-例如 `find_free(duration=2)` 连续多次查询，主体内容几乎相同；`list_tasks(all)` 与 `get_overview` 也重复大量信息。
+### 2.1 已完成的核心修复
 
-- 大量 assistant 过程性话术进入 history。  
-例如“我先查一下”“我需要先获取”“我将安排……请确认”这类文本，对后续决策价值很低，却持续吃 token。
+#### A. 粗排结果来源修正
 
-- 失败回合被原样保留。  
-例如 `place` 缺 `task_id`、`find_free` 缺 `duration` 的失败记录，不需要完整原文链路，只需要摘要化保留“最近失败模式”。
+位置：
 
-- 指令层重复。  
-`renderStateSummary`、pinned blocks、运行时 user prompt 存在明显重叠。
+- `backend/service/agentsvc/agent_newagent.go`
 
-- `newAgent` 目前没有接旧链路那套历史 token budget 裁剪。  
-对照位置：
-  - 新链路：`backend/service/agentsvc/agent_newagent.go`
-  - 旧链路：`backend/service/agentsvc/agent.go`
-  - token budget 工具：`backend/pkg/token_budget.go`
+已做：
 
-## 当前排程链路里最需要纠偏的错误引导
+- `makeRoughBuildFunc()` 不再只看 `[]TaskClassItem`
+- 改为使用 `HybridScheduleWithPlanMulti()` 返回的 `[]HybridScheduleEntry`
+- 只提取 `status="suggested"` 且 `task_item_id>0` 的条目
 
-当前这段逻辑已经不符合用户现在确认的业务前提：
+意义：
+
+- 旧问题是：只会拿到有 `EmbeddedTime` 的一部分结果，普通 suggested 条目会丢
+- 现在粗排 placement 来源和旧 agent 主链路一致
+
+#### B. 作用域修正：只按本轮 `task_class_ids` 看 pending
+
+位置：
+
+- `backend/newAgent/tools/status.go`
+- `backend/newAgent/model/graph_run_state.go`
+- `backend/newAgent/node/rough_build.go`
+
+已做：
+
+- 新增按 `task_class_ids` 判断 task 是否属于本轮范围
+- `EnsureScheduleState()` 会对 `ScheduleState` / `OriginalScheduleState` 做域内裁剪
+- `countPendingTasks()` 只统计本轮任务类范围内的真实 pending
+
+意义：
+
+- 修掉“用户所有任务类的 pending 被误算进本轮粗排结果”的问题
+
+#### C. 窗口修正：ScheduleState 的 DayMapping 改为优先按本轮任务类加载
+
+位置：
+
+- `backend/newAgent/model/state_store.go`
+- `backend/newAgent/model/graph_run_state.go`
+- `backend/conv/schedule_provider.go`
+
+已做：
+
+- 新增可选接口 `ScopedScheduleStateProvider`
+- `AgentGraphState.EnsureScheduleState()` 首次加载时，若 provider 支持 scoped 加载，则优先走 `LoadScheduleStateForTaskClasses()`
+- `ScheduleProvider` 实现了按本轮 `task_class_ids` 精确加载 `ScheduleState`
+- `buildWindowFromTaskClasses()` 改成逐个任务类做日期转换，坏日期/超学期日期会被忽略，不再把整轮窗口拖坏
+
+这次修的是一个真实 bug：
+
+- 用户真实日志里曾出现：
+  - `placements=44`
+  - `pending_in_scope=44`
+- 这说明 placement 已经出来了，但一个都没写回 state
+- 根因不是粗排没算出来，而是 `DayMapping` 窗口被全量任务类脏日期污染，导致 `WeekDayToDay()` 映射失败
+
+现在这个问题已经修掉，用户已确认“粗排跑通了”。
+
+#### D. 粗排落位语义改成 `suggested`
+
+位置：
+
+- `backend/newAgent/node/rough_build.go`
+- `backend/newAgent/tools/read_tools.go`
+- `backend/newAgent/tools/read_helpers.go`
+- `backend/newAgent/tools/write_tools.go`
+- `backend/newAgent/tools/SCHEDULE_TOOLS.md`
+
+已做：
+
+- 粗排成功写回后，任务状态会从真实 pending 变成 `suggested`
+- 不再使用“pending + slots”的旧兼容语义作为主路径
+- 工具读写层已经统一支持 `existing / suggested / pending`
+
+意义：
+
+- 粗排结果是“建议落位”，后续应使用 `move / swap / unplace`
+- 不应该再让 LLM 把这些任务当作待补排任务来 `place`
+
+#### E. 粗排节点增加了可观测 debug
+
+位置：
 
 - `backend/newAgent/node/rough_build.go`
 
-这里现在会在粗排后写入一段 pinned 文本，大意是：
+现在会打这些日志：
 
-- 如果还有 `pending`，就让 LLM 去 `get_overview/find_free/place`
-- 重复 place，直到 pending 归零
+- `placements`
+- `applied`
+- `day_mapping_miss`
+- `task_item_match_miss`
+- `pending_in_scope`
+- `window_days`
+- 少量 miss 样本
 
-这段引导现在应视为错误业务语义。下一位助理需要重点改掉它。
+意义：
 
-## 粗排算法主线的交接意见
+- 下次如果粗排再挂，不需要再靠猜
+- 能直接区分是：
+  - DayMapping 没命中
+  - 还是 `task_item_id` 没命中
 
-下一位助理要继续查两件事：
+### 2.2 粗排阶段当前的真实状态
 
-- 粗排算法本体是否真的仍会漏排。  
-重点排查：
-  - `makeRoughBuildFunc`
-  - `RunRoughBuildNode`
-  - `placements` 写入 `ScheduleState` 后，是否所有目标任务都应有初始落位
+当前真实结论：
 
-- 如果业务上“粗排不应漏排”已经成立，那么链路要改成：
-  - 粗排完成且 `pending > 0`：直接异常结束
-  - 不再把 LLM 引导成“手工补排”
-  - 最好在执行层支持 `abort` 语义，而不是让模型继续乱试
+- 粗排已经能跑通
+- 用户已在真实链路确认这一点
 
-## prompt 重构主线的交接意见
+所以粗排这条线当前不是主矛盾了。
 
-用户已经认可的新方向是：把 prompt 改成“通用执行内核 + 可插拔领域模块 + 当前任务简报”。
+---
 
-推荐的 3-message 结构如下。
+## 3. 第 2 阶段：正式 abort/terminal 协议，已完成
 
-### 第一条消息：通用执行内核
+### 3.1 已完成的核心改动
 
-职责：
+#### A. CommonState 引入统一 terminal outcome
 
-- 定义 agent 身份
-- 定义通用规则
-- 定义通用动作协议
-- 提供最小必要的 JSON 示例
+位置：
 
-### 第二条消息：领域模块
+- `backend/newAgent/model/common_state.go`
 
-职责：
+已做：
 
-- 注入当前领域名称、职责边界、目标、非目标
-- 注入领域工具简表
-- 注入领域硬约束、软目标
-- 注入异常定义与完成判定
+- 新增：
+  - `FlowTerminalStatus`
+  - `FlowTerminalOutcome`
+- 新增方法：
+  - `Abort(...)`
+  - `Exhaust(...)`
+  - `HasTerminalOutcome()`
+  - `TerminalStatus()`
+  - `IsCompleted()`
+  - `IsAborted()`
+  - `IsExhaustedTerminal()`
+  - `ClearTerminalOutcome()`
 
-### 第三条消息：运行时任务简报
+意义：
 
-职责：
+- 后续 graph / execute / deliver 不再各自猜“当前算不算结束”
+- 统一围绕一份终止结果收口
 
-- 给出用户原始目标与最新补充
-- 给出当前实例级约束
-- 给出最新状态快照
-- 给出最近操作摘要
-- 给出上一次工具调用结果
-- 给出本轮目标
+#### B. execute contract 正式支持 `abort`
 
-## 用户已经认可的 prompt 设计原则
+位置：
 
-- 必须保留 JSON 示例，否则 LLM 容易不会按协议输出。
-- prompt 必须有显式编号和子编号，例如 `1. / 1.1 / 2.1`。
-- prompt 不能写死成排程专用。
-- 排程只是一个领域模块示例，不是通用内核的一部分。
-- 对排程领域来说，应明确：
-  - 这是“粗排后的优化器”
-  - 不是“补排器”
-  - `pending > 0` 是异常条件，不是待办事项
-- 对不同领域，应通过占位参数注入，不要把具体业务写进通用层。
+- `backend/newAgent/model/execute_contract.go`
+- `backend/newAgent/prompt/execute.go`
 
-## 已产出的可插拔 prompt 方案要点
+已做：
 
-建议最终落地成这三层：
+- 新增 `ExecuteActionAbort = "abort"`
+- `ExecuteDecision` 新增 `Abort *AbortIntent`
+- `Validate()` 已补齐互斥/必填规则
+- execute prompt / react prompt 都已加入 `abort` 契约和 JSON 示例
 
-### 通用执行内核
+#### C. rough_build 异常会正式 abort，而不是让 LLM 补排
 
-- 身份
-- 通用规则
+位置：
+
+- `backend/newAgent/node/rough_build.go`
+
+已做：
+
+- 若粗排后仍有真实 pending：
+  - 发失败状态
+  - `flowState.Abort(...)`
+  - 直接交给 deliver 收口
+
+这部分已经和用户确认过业务语义，是对的。
+
+#### D. execute 层接入 abort / exhausted 正式语义
+
+位置：
+
+- `backend/newAgent/node/execute.go`
+
+已做：
+
+- execute 轮次耗尽时，不再伪装成 `done`
+- 改为 `flowState.Exhaust(...)`
+- 新增 `handleExecuteActionAbort(...)`
+- `abort` 不在 execute 内直接最终答复，而是交给 deliver
+
+#### E. graph 路由改成看正式 terminal outcome
+
+位置：
+
+- `backend/newAgent/graph/common_graph.go`
+
+已做：
+
+- `RoughBuild -> Execute` 改为 branch
+- 粗排异常终止时可以直接 `RoughBuild -> Deliver`
+- `branchAfterExecute()` 不再因为“刚好最后一轮”就提前 deliver
+- 必须等 execute 正式写入终止结果
+
+#### F. deliver 收口统一按 terminal outcome 输出
+
+位置：
+
+- `backend/newAgent/node/deliver.go`
+- `backend/newAgent/node/agent_nodes.go`
+
+已做：
+
+- deliver 不再无脑 `Done()`
+- deliver summary 会优先看 terminal outcome
+- 新增：
+  - `buildAbortSummary`
+  - `buildExhaustedSummary`
+- 只有 `completed` 路径才写 schedule preview
+- `aborted / exhausted` 跳过 preview
+
+### 3.2 第 2 阶段的验证情况
+
+本地已跑通过：
+
+```bash
+go test ./conv ./newAgent/node ./newAgent/model ./newAgent/graph ./newAgent/tools ./service/agentsvc
+```
+
+注意：
+
+- 每次 `go test` 后都已清理根目录 `.gocache`
+- 过程中使用过临时 `*_test.go` 验证窗口问题和粗排写回问题，跑完后已全部删除
+
+---
+
+## 4. 非常重要：当前“上下文”到底改没改
+
+这个点后续助理很容易误判，这里单独写清楚。
+
+### 4.1 没做的事
+
+这轮**没有**做第 3 阶段那种“系统性的上下文瘦身”。
+
+也就是说，以下这些东西没有被系统重构：
+
+- `ConversationContext` 的整体装配框架
+- 历史恢复/回填主流程
+- 历史裁剪策略
+- token budget 接入
+- “把 history 从流水账改成摘要流”的体系化工程
+
+### 4.2 但确实改了会进入模型上下文的内容
+
+为了适配新的粗排/abort 语义，这轮确实改了“上下文内容本身”，主要包括：
+
+1. 粗排完成后的 pinned block 文案变了  
+   位置：
+   - `backend/newAgent/node/rough_build.go`
+
+2. execute 的提示词/输出契约变了  
+   位置：
+   - `backend/newAgent/prompt/execute.go`
+
+3. 工具层的状态语义从 `pending/existing` 扩成了 `pending/suggested/existing`  
+   位置：
+   - `backend/newAgent/tools/read_tools.go`
+   - `backend/newAgent/tools/write_tools.go`
+
+4. state summary 会展示 terminal outcome  
+   位置：
+   - `backend/newAgent/prompt/base.go`
+
+### 4.3 所以当前准确结论是
+
+可以这样理解：
+
+- **没有做上下文瘦身**
+- **但确实改了进入模型的上下文内容**
+
+所以如果下游 `execute` 现在表现依旧很差，不能简单说：
+
+- “是第 1-2 阶段没做好”
+
+更准确的说法是：
+
+- 第 1-2 阶段把粗排和终止语义打通了
+- 但下游本来就被上下文噪音淹着
+- 现在必须进入第 3 阶段，先瘦身，再评价整体效果
+
+---
+
+## 5. 当前主矛盾：不是粗排，而是 execute 上下文过胖
+
+用户已经明确表达：
+
+- “下游本来就基本跑不通”
+- “必须要瘦身上下文才能看出整体的效果”
+
+这意味着明天接手时不要再把精力放在：
+
+- 继续 patch 粗排小问题
+- 继续围绕 abort 收口补语义
+
+下一步的主任务必须切换为：
+
+- 第 3 阶段：上下文瘦身
+- 第 4 阶段：prompt 结构重构
+
+---
+
+## 6. 第 3 阶段：上下文瘦身，明天应该怎么做
+
+### 6.1 目标
+
+目标不是“再写一版更长的 prompt”，而是：
+
+- 让 execute 每轮看到的输入，变成“足够决策、但不淹没”的信息量
+
+换句话说，要把现在的：
+
+- `system + tool summary + 全量 history + pinned + runtime prompt`
+
+改造成更可控的：
+
+- 少量稳定规则
+- 少量当前必要状态
+- 少量最近真实有效观察
+
+### 6.2 第 3 阶段必须完成的事
+
+#### A. 历史去流水账
+
+重点文件：
+
+- `backend/service/agentsvc/agent_newagent.go`
+- `backend/newAgent/prompt/base.go`
+- `backend/newAgent/node/execute.go`
+
+要做：
+
+- 同工具同参数的重复查询，不保留多份原文
+- 旧结果改成摘要
+- 只保留最近一条原始结果
+
+典型对象：
+
+- `get_overview`
+- `list_tasks`
+- `find_free`
+
+#### B. assistant 过程废话不再进入后续模型历史
+
+要处理的典型文本：
+
+- “我先查一下”
+- “我接下来会……”
+- “我准备先获取……”
+
+这些文本对下一轮决策价值极低，但会稳定吃 token。
+
+#### C. 失败模式保留“摘要”，不要保留整段原始失败链路
+
+例如：
+
+- `place` 缺 `task_id`
+- `find_free` 缺 `duration`
+
+正确保留方式应该更像：
+
+- 最近失败模式：`place` 缺少 `task_id`
+
+而不是整段原始 tool call / tool result 全保留。
+
+#### D. 缩短 state summary / pinned / runtime prompt 的重叠信息
+
+目前这三层有明显重复：
+
+- `renderStateSummary`
+- pinned blocks
+- execute runtime user prompt
+
+第 3 阶段要先做减法，减少重复指令。
+
+#### E. 参考旧链路的 token budget
+
+重点参考：
+
+- `backend/service/agentsvc/agent.go`
+- `backend/pkg/token_budget.go`
+
+要求：
+
+- 不一定照搬
+- 但至少要借鉴旧链路“按预算裁历史”的思路
+
+### 6.3 第 3 阶段推荐顺序
+
+建议按这个顺序做：
+
+1. 先打印/抓取 `BuildExecuteMessages()` 的真实输入样本
+2. 再压 `history`
+3. 再压 `pinned/state summary/runtime prompt` 的重叠
+4. 最后再接 token budget
+
+原因：
+
+- 先把“到底胖在哪”看清楚
+- 避免直接上 budget 把有用信息也一起砍掉
+
+### 6.4 第 3 阶段完成标准
+
+至少要满足：
+
+1. execute 首轮 messages 显著变短
+2. 同类查询不会反复堆原始结果
+3. assistant 流水话大幅减少
+4. 最近失败模式还能被模型感知
+5. 不破坏第 1-2 阶段已经打通的粗排/abort 语义
+
+---
+
+## 7. 第 4 阶段：prompt 结构重构，明天应该怎么做
+
+### 7.1 目标
+
+把当前 execute prompt 从“堆规则 + 堆领域细节 + 堆运行时说明”的混合物，重构成：
+
+1. 通用执行内核
+2. 领域模块
+3. 运行时任务简报
+
+这是用户已经认可的方向。
+
+### 7.2 建议的三层结构
+
+#### 第一层：通用执行内核
+
+负责：
+
+- agent 身份
 - 通用动作协议
-- 输出字段定义
+- 通用输出字段
 - 最小 JSON 示例
 
-### 领域模块
+这里不要写死排程语义。
+
+#### 第二层：领域模块
+
+对排程领域来说，建议抽成单独模块，至少包含：
 
 - `domain_name`
-- `task_type`
 - `domain_primary_responsibility`
 - `domain_out_of_scope`
 - `domain_goals`
 - `domain_non_goals`
 - `tool_catalog_brief`
-- `tool_usage_rules`
-- `tool_required_args_rules`
-- `tool_common_failures`
 - `hard_constraints`
 - `soft_objectives`
 - `abort_conditions`
-- `abort_handling_rules`
 - `done_conditions`
-- `abort_output_conditions`
 
-### 运行时任务简报
+对“粗排后排程优化”这个领域，必须明确写清：
 
-- `original_user_goal`
-- `latest_user_instruction`
-- `current_effective_goal`
-- `current_phase`
-- `current_round`
-- `instance_constraints`
-- `latest_state_summary`
-- `latest_state_delta`
-- `latest_risks`
-- `recent_operation_summary`
-- `recent_failure_patterns`
-- `last_tool_name`
-- `last_tool_arguments_summary`
-- `last_tool_result_summary`
-- `last_tool_success`
-- `last_tool_state_change`
-- `last_tool_takeaway`
-- `current_round_goal`
-- `recommended_next_action`
+- 这是优化器，不是补排器
+- `pending > 0` 是异常，不是待办
 
-## 排程领域的具体模块语义
+#### 第三层：运行时任务简报
 
-如果当前领域是“粗排后的排程优化”，建议这样填：
+负责：
 
-- `domain_name = schedule_optimization`
-- `domain_primary_responsibility = 在粗排结果基础上优化排程质量`
-- `domain_out_of_scope = 手工补排粗排遗漏任务`
-- `domain_goals = 更均匀、更符合学习规律、更平衡每日负载`
-- `domain_non_goals = 把 pending 任务一个个 place 进去`
-- `abort_conditions = 粗排完成后仍有 pending 任务`
-- `abort_handling_rules = 不再继续优化，不再 place，直接 abort`
-- `done_conditions = 方案满足硬约束且整体分布合理`
+- 用户原始目标
+- 最新补充指令
+- 当前阶段
+- 当前轮次
+- 当前实例级约束
+- 最近状态变化
+- 最近失败摘要
+- 上一次工具结果摘要
+- 本轮目标
+- 推荐下一步动作
 
-## 代码层建议的实施顺序
+### 7.3 第 4 阶段不要做成什么样
 
-建议下一位助理按这个顺序做，风险最低：
+不要做成：
 
-1. 先改粗排后 pinned 引导  
-重点文件：`backend/newAgent/node/rough_build.go`  
-目标：删掉“pending 继续 place”的提示，换成“pending 是异常”的提示。
+- 换一版更长的 execute prompt
+- 继续把排程规则硬编码进通用层
+- 继续把运行时状态散落在多个 message 里重复讲
 
-2. 再补 `abort` 动作语义  
-重点文件：
-  - `backend/newAgent/node/execute.go`
-  - 相关 decision model 定义文件
-  - 可能涉及 deliver / graph 分支  
-目标：让 LLM 可以正规地终止异常流程，而不是只能 continue / done / ask_user / confirm。
+### 7.4 第 4 阶段推荐落地文件
 
-3. 再做 prompt 结构重构  
-重点文件：
-  - `backend/newAgent/prompt/base.go`
-  - `backend/newAgent/prompt/execute.go`
-  - 如有必要，可新增一个领域模块文件  
-目标：把目前“system/tool/history/pinned/runtime prompt”重组为“通用内核 + 领域模块 + 任务简报”。
+可以考虑在以下位置拆分：
 
-4. 最后再做历史瘦身  
-目标：
-  - 同工具同参数结果只保留最近一份原文
-  - 更早历史改摘要
-  - assistant 废话不入 history
-  - 失败模式摘要化
-  - 必要时接入 token budget
+- `backend/newAgent/prompt/base.go`
+- `backend/newAgent/prompt/execute.go`
 
-## 关于历史瘦身，已达成的结论
+如有必要，可以新增文件，例如：
 
-下一位助理可以直接照这个原则做：
+- `backend/newAgent/prompt/execute_core.go`
+- `backend/newAgent/prompt/execute_domain_schedule.go`
+- `backend/newAgent/prompt/execute_runtime_brief.go`
 
-- 不再把几十条 `assistant/tool` 原始流水账直接喂给模型
-- 把历史改成“状态快照 + 最近摘要 + 上一次结果 + 本轮目标”
-- `tool result` 只保留：
-  - 最新一条原文
-  - 更早的同类结果摘要
-- 重复查询要压缩：
-  - 同工具同参数只保留最新一条
-- assistant 过程话术要剔除：
-  - “我先查一下”“我将继续……”之类原则上不入模型历史
-- 保留最近失败模式：
-  - 例如 `place` 缺 `task_id`
-  - 例如 `find_free` 缺 `duration`
+### 7.5 第 4 阶段完成标准
 
-## 测试与验证注意事项
+至少要满足：
 
-- 运行 `go test` 后，必须清理项目根目录 `.gocache`。
-- 当前环境可能会因为网络限制导致 `go test` 拉依赖失败；之前已经出现过这种情况。
-- 项目要求：
-  - 注释、接口文案、说明、评审反馈都用中文
-  - 文件编码 UTF-8（无 BOM）
-  - 不要把 agent 改回写库逻辑；当前用户明确要求 agent 操作只写内存，不写数据库
-- 代码中若改动复杂逻辑，注释要同步更新，且注释必须用中文
+1. 通用执行协议不再写死排程业务
+2. 排程语义以领域模块方式注入
+3. 运行时信息有单独的结构化简报
+4. prompt 保留编号结构
+5. prompt 保留最小 JSON 示例
 
-## 关键文件清单
+---
 
-- 执行节点与上下文打点：`backend/newAgent/node/execute.go`
-- prompt 拼装基础：`backend/newAgent/prompt/base.go`
-- execute prompt：`backend/newAgent/prompt/execute.go`
-- 粗排节点：`backend/newAgent/node/rough_build.go`
-- graph 节点装配：`backend/newAgent/node/agent_nodes.go`
-- newAgent service 入口：`backend/service/agentsvc/agent_newagent.go`
-- 旧链路 token budget 参考：`backend/service/agentsvc/agent.go`
-- token budget 工具：`backend/pkg/token_budget.go`
+## 8. 明天接手时，最重要的判断标准
 
-## 一句话总结给下一位助理
+明天的助理接手后，不要先问：
 
-当前要做的，不是继续 patch 某个 prompt 文案，而是同时完成两件事：
+- “为什么微调效果还是差？”
 
-- 把“粗排后 pending 还让 LLM 手工补排”的错误业务语义彻底清掉
-- 把 `execute` 从“消息流水账喂模”重构成“通用执行内核 + 可插拔领域模块 + 运行时任务简报”的结构化 prompt
+而要先问：
 
-## TODO Checklist
+- “第 3 阶段有没有把上下文瘦下来？”
 
-### 粗排算法与异常语义
+只有在第 3 阶段做完之后，才适合重新评估：
 
-- [ ] 确认粗排算法本体是否真的会漏排
-- [ ] 确认 `placements` 写入 `ScheduleState` 后是否所有目标任务都已有初始落位
-- [ ] 删除 `rough_build` 节点里“pending 继续 place”的错误提示
-- [ ] 改成“粗排后 pending > 0 即异常”的提示语义
-- [ ] 在执行决策层补齐 `abort` 动作语义
+- execute 是否真正理解了粗排后的 suggested 语义
+- prompt 重构是否真的提升了整体表现
+- 端到端排程链路是否比之前更稳定
 
-### Prompt 重构
+---
 
-- [ ] 抽出通用执行内核 prompt
-- [ ] 抽出领域模块 prompt
-- [ ] 抽出运行时任务简报拼装逻辑
-- [ ] 保留最小必要 JSON 示例
-- [ ] 清除后端执行层语义对 LLM 的干扰
-- [ ] 让排程领域以模块方式接入，而不是写死在内核
+## 9. 关键文件清单
 
-### 历史瘦身
+### 第 1-2 阶段已改文件
 
-- [ ] 同工具同参数仅保留最新一条原文
-- [ ] 更早同类结果改为摘要
-- [ ] assistant 过程性废话不再进入模型历史
-- [ ] 最近失败模式摘要化保留
-- [ ] 必要时接入 token budget
+- `backend/conv/schedule_provider.go`
+- `backend/newAgent/model/state_store.go`
+- `backend/newAgent/model/graph_run_state.go`
+- `backend/newAgent/model/common_state.go`
+- `backend/newAgent/model/execute_contract.go`
+- `backend/newAgent/graph/common_graph.go`
+- `backend/newAgent/node/rough_build.go`
+- `backend/newAgent/node/execute.go`
+- `backend/newAgent/node/deliver.go`
+- `backend/newAgent/node/agent_nodes.go`
+- `backend/newAgent/prompt/base.go`
+- `backend/newAgent/prompt/execute.go`
+- `backend/newAgent/tools/read_helpers.go`
+- `backend/newAgent/tools/read_tools.go`
+- `backend/newAgent/tools/write_tools.go`
+- `backend/newAgent/tools/SCHEDULE_TOOLS.md`
+- `backend/service/agentsvc/agent_newagent.go`
 
+### 第 3-4 阶段重点关注文件
+
+- `backend/service/agentsvc/agent_newagent.go`
+- `backend/newAgent/prompt/base.go`
+- `backend/newAgent/prompt/execute.go`
+- `backend/newAgent/node/execute.go`
+- `backend/pkg/token_budget.go`
+- `backend/service/agentsvc/agent.go`
+
+---
+
+## 10. 测试与验证注意事项
+
+1. 跑 `go test` 后必须清理项目根目录 `.gocache`
+
+2. 如果为了验证临时补 `*_test.go`，跑完必须删除，不要长期保留
+
+3. 当前用户明确不希望这轮把 agent 写库逻辑接回去，仍然以“内存态运行”为主
+
+4. 所有说明、注释、文档都继续用中文
+
+---
+
+## 11. 一句话交给下一位助理
+
+第 1-2 阶段已经把“粗排接入”和“正式 abort 收口”打通了，粗排真实链路也已经跑通；现在不要再围绕粗排打补丁，直接进入第 3 阶段做 execute 上下文瘦身，再做第 4 阶段 prompt 三层重构，完成后再评估整体链路效果。