jianf/HomeAgent
1
0
Fork 0
mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-21 09:28:14 +00:00
Code Issues Packages Projects Releases Wiki Activity
424 Commits 6 Branches 27 Tags
f2ec46480ec83dbfe1442e35bffeb3ade6150a29
Commit Graph

12 Commits

Author SHA1 Message Date
JianFeeeee
f2ec46480e refactor(core)!: N0 无状态化 —— 删除 Agent.currentOutputChannel，通道只跟输入事件/帧走 
驻留式子 agent 设计（docs/zh/resident-subagent-design.md）的里程碑 N0。

## 问题

`a.currentOutputChannel` 是 **agent 级可变字段**，只在 prepare 段写入，而被打断任务
恢复时**不重新 prepare**（resumeTask 只 rebase 前缀）。于是中断任务 prepare 时把它
覆盖成自己的通道，被恢复的任务再把回复发到**中断任务的通道**上——两个任务串台。

后果不只是标签错：工具提示词里那句"当前输入来源通道是 X，对应输出门工具是
output_send__X"会诱导模型**把回复主动发到错误的通道**。

## 两处一起改（用户指出的两件事）

1. **内核不应持有"当前通道"**：通道是随输入事件带进来的，路由发生在**进内核之前**，
   输出是 agent 的**主动调用**。删除该字段，改为一律从输入事件推导
   （`outputChannelOf(evt)`）或读本任务的帧（`f.OutputChannel`）。
2. **提示词不应预设 outputch**：删掉"当前输入来源通道是 X → 用 output_send__X"那两行，
   改为"不要假设当前通道是固定值；先看消息本身与上下文的来源信息，不确定时先调
   output_list_channels"。

## 改动面（把通道一路显式传下去，而不是读共享状态）

- `agent.go`：删字段
- `task.go`：新增 `outputChannelOf` / `isCriticalChannel`；帧记录通道；
  安全点与 setCritical 用帧/事件推导；步骤内事件标签改用 `f.OutputChannel`；
  `executeToolCall(f.CurTool, f.OutputChannel)`；`callLLMWithFallback(..., f.OutputChannel)`
- `process.go`：`chatStreamWithFallback` / `accumulateStream` 增加 channel 参数
  （增量事件的 channel 标签由此而来）
- `stage.go`：`runStage` 从 `ctx.Extra["output_channel"]` 读（发起方写入）
- `eventloop.go`：`emitResponse` 用 `outputChannelOf(evt)`；stageCtx 带上通道
- `spawn.go` / `toolcall.go`：`executeSpawnChild` 的 parentChannel 由调用方（帧）传入
  （子任务完成通知要回到**发起这次 spawn 的那个任务**的通道）
- `distill.go`：删掉 consolidation 路径里的赋值
- `tooldefs.go`：删掉提示词里的通道预设

## 验收

- `scheduler_channel_routing_test.go`（N0 守卫）：中断任务跑过之后，被恢复任务的
  输出通道仍是它自己的（改前实测为 cli，期望 qq）
- `TestCriticalSection_ConsolidationMarked`：补上推导链
  「输入事件 → 通道 → isCriticalChannel → scheduler.critical」的集成断言
- 全仓 `go test ./...` 37 包 ok / 0 FAIL；`-race ./internal/agent/...` 干净
- 残留 `currentOutputChannel` 引用为 0（只剩描述历史的注释）
 2026-09-13 08:59:15 +08:00
JianFeeeee
158395bfdf test(scheduler): 优先级压力测试（100 排队 + 100 中断各级混合、嵌套到 4 帧上限） 
按需造一个固定内容的 fakeprovider，做两件事：

E4：混合载荷（用户指定的形状）
  100 条排队输入 + 100 条中断（L1/L2/L3/L4 各 25）混合打入。每条中断都等到
  “该被它打断的受害者正在跑”时才注入——调度器是单线程的，闭着眼睛猛灌只会
  让绝大多数中断退化成排队，压力就压不到抢占/挂起路径上。
  判据：200 个任务全部到达终态、Rejected=0、各级登记数=25、**各级抢占数都>0**、
  排空后 Suspended==Resumed、每次“取消流式段”都换来一次挂起。

E5：嵌套到结构上限
  排队任务运行中依次注入 L1→L2→L3→L4（每级都等上一级在跑）。判据：栈深峰值
  恰好 4（= 结构上限，此时 canSuspend()=false），恢复顺序严格 LIFO
  [L3,L2,L1,排队]，Suspended==Resumed==4。

顺带修掉两处：
- **Resumed 双计**：nextRef 弹栈与 resumeTask 各计一次，使“排空后
  Suspended==Resumed”这条不变量失真。现在只在 resumeTask 计（nextRef 只负责选出）。
- 新增分级可观测：SchedulerStats.InterruptsByLevel[1..4] / PreemptsByLevel[1..4]。
  只看总数会掩盖“总数一样但级别分布完全不同”，按级别验收才是这套调度器的判据。
  注意 PreemptsByLevel 是“判定可抢占并进入 immediate”的次数，与 Suspended 不等价：
  受害者可能在让位生效前就自行结束，此时抢占者只是“下一个运行”，没有挂起发生。

教训：provider 必须感知 ctx 取消。第一版没做，结果 LLM完成==任务数、挂起≈0——
抢占全落在“步骤之间”，流式段（真正需要保存/恢复现场的地方）一次都没压到。

验收：go test ./... 37 包 ok 0 FAIL；-race 全绿；压力连跑 3 次稳定；
新内核 go build 通过并真实启动冒烟 OK。
 2026-09-13 07:31:32 +08:00
JianFeeeee
f3232000f4 feat(scheduler): L4 也归内核级插件 —— WebUI 终止按钮可用“立即打断” 
上一提交把 L4 写成“内核独占（panic / selfip）”，漏了内核级插件这类来源。
用户澄清：**内核级插件应当能声明 L4，用于实现中断能力**，例如 WebUI 的终止按钮。

判据（两道闸，纵深防御）：
  1. proc 桥（外部进程唯一入口）一律把 L4 夹到 L3。在这里夹而不是只按 source 判，
     是因为 source 是插件自报字段、可以冒名；本函数所在位置能确知“来自外部进程”。
  2. core：isKernelLevelSource(source) 查 pluginReg.IsBuiltinPlugin，只有编译期内置
     插件（init() 自注册的工厂）才承认 L4。
source 约定 `插件名` 或 `插件名/实例`（webui/<deviceID>），判据取第一段——
否则带设备身份的 WebUI 来源会被误判成外部插件而拿不到 L4。

改动：
- core: interruptLevel(evt, privileged bool)；新增 isKernelLevelSource；
  requestPreempt 不再夹取（级别已由 interruptLevel 解析，否则内核级插件的 L4 被削掉）。
- eventloop: 传入 a.isKernelLevelSource(evt.Source)。
- proc 桥: 新增 clampExternalPriority，pubSdkInjectOpts 一律夹取。
- internal/sdk: 再导出 PriorityL1..L4（内置插件用 sdk.PriorityL4）。
- webui handleChatInterrupt（终止按钮）声明 PriorityL4。
- timer 声明 PriorityL3：定时器是“时钟那种实时工作”，比 QQ 那类可无限等待的
  异步消息高（L1）——这是对用户“它不是时钟那种实时工作”的直接推论，可改。
- 测试: L4 特权矩阵（非特权夹取 / 特权承认）、source 判据（内置、内置/实例、
  外部、空、前缀不误匹配）、内核级插件 L4 一路到达调度器、proc 夹取两条。
- 设计稿 §2/§3.2/§11.1/§14/§15 按“L4 = 内核 + 内核级插件”更正。

验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿（含 webui/timer）。
 2026-09-13 07:18:03 +08:00
JianFeeeee
cb32032f76 feat(scheduler)!: 中断/排队两类别模型 + 插件声明 L1-L3、L4 内核独占 
用户澄清推翻了早期设计的三处前提，本提交按新模型重做调度核心（行为有意变化）：

1) 类别由注入 API 决定，与通道名无关
   - InjectInterrupt*                      -> TaskInterrupt（带级别，可被严格更高级中断打断）
   - InjectText*/InjectInputSync*/内核自循环 -> TaskQueued（无级别，可被任何中断打断）
   - 删除按通道名推断的 taskLevel()：qq 走 InjectInterruptTextOpts，本就是中断

2) 级别只属于中断
   - 插件在 InjectOptions.Priority 声明 L1-L3（空/非法降级 L1，声明 L4 夹到 L3）
   - L4 内核独占：新增 raiseKernelInterrupt（panic / selfip）；requestKernelPreempt 不夹取
   - panic 现在产生一条带 kernel 标记的 L4 中断；L4 自身 panic 不再产生新 L4（防自我放大）

3) 选择结构：四容器固定次序，删除统一比较器
   - immediate（抢占者立即运行）-> 中断队列 L4..L1 -> 栈顶(与队头比级别) -> 排队 FIFO
   - 删除 pickTaskIndex/taskBefore 与“同级 pending 优先”补丁（根因是抢占者进了队列）
   - 中断栈上界改为结构推论 = 4（= 中断级数）；删除“超限转 pendingInterrupts”降级

公开 SDK（feature 分支有意新增，纯追加）：InjectOptions.Priority + PriorityL1/2/3；
内核 io / proc 桥 / 插件模板同步透传。

设计稿 §2/§3/§4.1/§6.3/§9/§11/§12/§13/§15 按新模型重写。

验收：go build/vet 干净；go test ./... 37 包 ok 0 FAIL；-race 全绿；
e2e（抢占-挂起-恢复）+ 压力（200 排队 + 50 中断，L1/L2/L3 轮转）通过。
 2026-09-13 07:00:51 +08:00
JianFeeeee
86a702b3b0 fix(scheduler)!: 中断栈语义（嵌套抢占 LIFO），并修掉抢占空转 
用户指正：存在**中断被中断**的场景，所以被打断的现场要进**中断栈**。
我此前把 suspendPool 明确写成“不是栈、按优先级取”，是错的。

改动：
- suspendPool 改名 suspendStack，恢复纪律改为**严格 LIFO（只比栈顶）**；
  栈内不做优先级重排——嵌套抢占天然使栈自底向上基础级递增，
  且“后被打断的先恢复”才是栈语义。取出即弹栈。
- 修掉一个由此暴露的真 bug（抢占空转）：一次抢占生效后，被挂起的原任务
  会因饥饿防护提升有效级，与抢占者同级；此时若按“先到先服务”，原任务
  （入队更早）会被立刻选回，抢占者永远排不到 —— 抢占等于没发生。
  现在**同级时 pendingInterrupts 优先于其它两类**，保证抢占必然生效。
- 状态 DTO：SuspendPool/suspend_pool → SuspendStack/suspend_stack
- 设计稿：§2 用语更正（它**就是**中断栈）、§4.1 选择函数（候选只含栈顶 +
  pending 同级优先，并说明为何必需）、§6.2/§6.3/§9/§11 用例同步

测试新增 scheduler_stack_test.go 3 项：
- 嵌套 L1→L2→L3，恢复严格 LIFO（B 先于 A）
- 只比栈顶：人为构造“栈底 L3、栈顶 L2”，必须取栈顶（区分两种实现）
- 嵌套下的深度上限

验收：agent 全量 + -race；全仓 build/vet 通过
 2026-09-13 06:30:23 +08:00
JianFeeeee
d4764e3682 fix(scheduler)!: D1 更正为「中断从上一个任务之前的完整状态开始」，并实现现场合回 
用户明确语义（我此前对 D1 的解析就是错的——当时回答里的“A”指的是 git 选项，
D1 实际要的是方案 B）：

  中断打断时，上个任务到达以来的所有上下文现场被保护（含 toolcall），
  然后中断在「上个任务前的那个完整状态」上开始运行；
  中断结束后再把被挂起的任务与其上下文现场加载回中断任务之上，并继续运行。

实现：
- 删除 SeedMsgs 与 D1=A 的“只读前缀”机制：中断任务不再继承被打断任务的任何内容，
  它就是普通新任务，正常走完整 prepare（system prompt + timeline + 自己的输入）
- TaskFrame 新增 PrefixLen（基础前缀长度）与 InputBlocks；
  stepPrepare 在 buildMessages 之后记录 PrefixLen
- 新增 rebaseFramePrefix：恢复时重建基础前缀（中断已提交进 a.context，
  重建的 timeline 含中断效果＝“加载回中断之上”），再把本任务自己的尾部
  （Stage 上下文 + 工具轮产物 + 占位）接回；并补回 IsInterrupt 标记与多模态块
- resumeTask 在 runTaskSteps 之前调用 rebaseFramePrefix
- 设计稿 §5.3 改写为「已定：D1=B」并写明实现对应；§6.2 补“重建前缀→接回尾部”；
  §12 的 D1 行更新

测试：
- TestPreempt_HigherPreemptsAndResumes 改为断言「中断不继承、恢复后看得见中断内容」
- 新增 TestPreempt_ResumeRebaseRestoresTailDecorations（前缀重建后尾部装饰补回）
- 原 TestPreempt_SeedPathDoesNotLeakInterruptFlag 随之删除（机制已不存在）

验收：agent 全量 + -race；全仓 build/vet 通过
 2026-09-13 06:24:20 +08:00
JianFeeeee
8372f5bd8f fix(scheduler)!: 撤掉“优先级=可配置策略表”的错误设计，回归内核内部属性 
用户指正：**优先级是内核内部属性**，不是配置项，更不该由插件声明。
我此前把它建模成“策略表 + 字符串解析”，甚至准备接配置中心
（core.agent.priority.<channel>）——方向性错误，故整体撤销。

撤销：
- 删除 ParseLevel（字符串解析只服务于“外部可配”这个错误前提）
- 删除 AgentConfig.PriorityLookup / Agent.priorityLookup 及 taskLevel 中的查表分支；
  taskLevel 回归为纯内核内部规则（cli/webui/http→L3，system/_consolidation_→L1，
  其余 L1），注释明确“不对外暴露、不做运维可调项”
- 设计稿 §3.2 改写为“内核内部属性，不做成配置项”，并删除 §15 里
  “ChannelDef.Priority / InjectOptions.Priority 进公开 SDK”这一方向（同属外化）
- 未触碰配置中心（registry.go/main.go 的优先级配置一行未加）

同时落地 D6（与本撤销无关、此前遗漏的承诺）：
- AgentConfig.MaxToolTurns + runTaskSteps 在发起新一轮 LLM 前按 f.Turn 收尾；
  0 = 不限；cmd/homed/main.go 从既有 core.agent.max_tool_turns 取值
- 新增 task_test.go 2 项：上限 3 时恰好跑 3 批工具/3 次 LLM 并收尾；
  0 = 不限（跑完脚本）

验收：agent 全量 + -race；全仓 build/vet 通过
 2026-09-13 06:17:49 +08:00
JianFeeeee
98d67559d1 fix(scheduler): 补齐 M3 与设计稿的两处语义偏离（发现即修） 
两处都不是风格差异，而是真的偏离设计语义（其一为回归），
已按“先写判据确认失败、再修”的方式处理，判据保留为回归测试。

1. 空闲时到达的中断永远不会被处理（设计 §5.1 ③ 未落地）
   调度器空闲时只阻塞在 select{InputChan, selfInputCh, ctx.Done}，
   而 pendingInterrupts 不是 channel——interceptLoop 把中断入队后
   没有任何东西唤醒调度器，中断要等“下一条输入”才被看到。
   修复：调度器加 wake channel，enqueueInterrupt 非阻塞 signalWake，
   空闲分支增加 wake 分支。

2. 临界区内只“不让位”却仍被“取消”（设计 §4.3/§5.2）
   requestPreempt 不判临界区，interceptLoop 照常 cancelLLM，
   于是正在流式的记忆整理被中断，stepLLM 以 error 提前结束——
   整理任务被砍掉一半，而设计要求的是“请求排队等它结束”。
   修复：scheduler 增加原子 critical 标志（帧仍只由调度器读写），
   runInputTask 在 prepare 后设置、结束（含挂起）时清除；
   requestPreempt 在临界区内不 arm、不取消，中断只入队。

- 新增 scheduler_regression_test.go 2 项（先失败后通过）
- 验收：agent 全量 + -race；全仓 vet 通过
 2026-09-13 06:10:44 +08:00
JianFeeeee
f11de37bf2 feat(scheduler): M7 可观测性 + 压力测试 + 端到端测试 
设计依据 docs/zh/input-scheduler-design.md §11.5（O1/O2）、§11.6（E1/E2）。

- 可观测性：KernelStatus 新增 Scheduler 段（running/三集合深度/计数/
  深度上限），由 GetKernelStatus 从 DumpScheduler 原子快照填充；
  新增 events.EventScheduler，挂起/恢复各发一条（action/task/level）
- TaskKind.String() 便于日志与状态输出
- 新增 scheduler_e2e_test.go 3 项：
  · 压力：200 排队输入 + 50 中断全部经真实 loop 执行，结束时三集合排空、
    LLM 调用数精确等于输入数、无 Rejected
  · 可观测性：挂起/恢复事件齐备，状态快照计数一致
  · 端到端：完整启动 schedulerLoop+interceptLoop，经真实 channel 投递
    L1 任务与 L4 中断，验证「LLM 流式中断 → 挂起 → 中断先完成 → 原任务恢复」
    整条链路（LLM 调用数 = 丢弃1+中断1+恢复1+常规1）
- 验收：agent 全量 + -race；全仓 build/vet 通过
 2026-09-13 00:45:28 +08:00
JianFeeeee
a971fc8877 feat(scheduler): M5 饥饿防护（抢占计数提升有效级 + 抢占冷却） 
设计依据 docs/zh/input-scheduler-design.md §9、§11.5（G1/G2）。

- Task 增加 PreemptCount / LastPreemptAt；effectiveLevel(t) =
  min(L4, Level + min(PreemptCount, 2))：被抢占越多越“值钱”，
  逐步追上抢占它的流，但封顶 L4 因而抢不过真正的紧急输入
- 选择函数 taskBefore 改用有效级；requestPreempt 与 preemptGrantedFor
  同样以有效级比较
- 抢占冷却 preemptCooldown=2s：刚被抢占的任务期内不再被抢占，
  避免同一任务被反复打断到永不完结
- 新增 scheduler_starvation_test.go 4 项：提升与封顶、冷却期内不得再抢占、
  提升后同级不得抢占而更高可、选择函数确实用有效级
- 验收：agent 全量 + -race；全仓 build/vet 通过
 2026-09-13 00:38:30 +08:00
JianFeeeee
c69a1f11af feat(scheduler): M3a+M3b 任务生命周期重构 + 四级优先级抢占 
设计依据 docs/zh/input-scheduler-design.md §3–§8、§14。

M3a（行为等价的所有权重构）：
- processInput 拆为 prepareInputTask / runTaskSteps / finishInputTask，
  帧覆盖 prepare→step…→finish；提交与回执只在 finish 段发生一次，
  为安全点挂起做准备（挂起不重复提交）
- process() 不再持 a.mu（挂起不能持锁），a.mu 字段随之移除
- TaskFrame 增加任务层现场（Evt/CleanInput/IsInterrupt/StartedAt/Terminal/
  Level/SeedMsgs）与 taskTerminal / outcomeSuspended
- 新增 task_lifecycle_test.go 5 项：正常恰好一次终态、去重 skipped、
  on_input 短路、错误终态、consolidation 路由

M3b（优先级与抢占）：
- interceptLoop 重写：只做「收中断 → 定级 → requestPreempt → 必要时取消
  LLM」，绝不触碰帧（不变量 I2）；三条降级路径与 interceptCh 兜底退场，
  改为统一的 pendingInterrupts
- scheduler：pendingInterrupts / suspendPool / 让位信号，nextRef 在三集合上
  按统一排序键取值；深度上限 4（canSuspend 在安全点拦下）
- 抢占判据 incoming.level > running.level；相等与更低只入队
- 安全点只在 step 之间；执行中的 step（工具 RPC/ONNX/CAS）天然不可抢占；
  _consolidation_ 整任务视为临界区
- 恢复走 resumeTask：从 frame.Step 继续，不重跑 prepare
- D1=A：suspend 把被打断任务的只读前缀交给抢占比它的中断任务（SeedMsgs）
- 新增 scheduler_preempt_test.go 5 项：抢占-挂起-恢复（含 R1/R5）、同级更低
  不抢占、深度上限、空闲中断不丢、seed 路径不污染标志位

验收：agent 全量 + -race 通过；全仓 build/vet 通过
 2026-09-13 00:25:52 +08:00
JianFeeeee
7082a50365 feat(scheduler): M2 调度器骨架（就绪队列 + 选择函数 + 快照 + 任务级 panic 隔离） 
设计依据 docs/zh/input-scheduler-design.md §14 M2。

- 新增 scheduler.go：四级 Level 常量（默认 L1，显式才是特权）、
  Task/TaskKind、scheduler（有界队列/running/统计）、纯函数 pickTaskIndex
  （排序键 -Level → EnqueuedAt → ID）、schedulerLoop/pumpInbox/executeTask、
  DumpScheduler 原子快照
- eventLoop 退场，职责由 schedulerLoop 承担；M2 全部任务为 L1，
  因而行为等价于原先的 channel FIFO
- 每任务 panic 隔离（不变量 I6）：panic 只失败该任务，调度器存活，
  取代原先「重启整个循环」
- Start() 改起 schedulerLoop；interceptLoop 暂不动（M3 重写）
- 新增 scheduler_test.go：Q1 排序 4 组、Q4 背压、生命周期、K1 panic 隔离、
  O1 快照一致性、Level 取值契约
- 验收：agent 全量 + -race 通过
 2026-09-12 23:49:55 +08:00