b850feaef2
feat: 段页式记忆流转、coldcontext 重命名与安全治理
...
记忆层：
- MemoryBlock 承载 FrameTS/PageSeq/PageKind/BlockRole/CallID
- coldcontext 归档与回填按完整页传递，工具调用参数和配对键不丢失
- 召回先估算总 token，超预算时按全局页相似度标记 inactive
- inactive 仅是 context 渲染期状态，不落盘、不进入 coldcontext，Prune 后重置
- Peek/确认/Remove 两阶段召回，失败保留冷上下文副本
- stablemem 记录 last_recalled_at，删块连带清理边
命名：
- internal/memory/document → internal/memory/coldcontext
- Doc/DocEvent/DocHit → ColdDoc/ColdEvent/ColdHit
- ContextToColdContext/RecentColdContexts/FindColdContexts
- 保留既有 JSON 标签、doc_ 文件前缀与 doc_count 状态键，兼容存量数据
安全治理：
- 工具策略门禁、安全配置、事件总线发布者身份与入站脱敏
- 声明式 SecurityAPI 与 QQ owner/guest profile
- 日志保留策略与相关 e2e/回归判据
验证：go build ./...、go vet ./...、go test ./...（62 包）；
生产副本 e2e：7013 块迁移后 ID/向量/指纹 0 变化、0 缺失。
2026-10-29 23:53:48 +08:00
ba281a855a
feat(update): 差分 OTA + 安装形态分派 + 事件总线统一受安全监控
...
三条主线，由 e2e 实测驱动。
## 一、差分 OTA（internal/update/delta.go）
实测：改一行逻辑，88MB 的二进制逐字节只差 80 字节，而 OTA 一直下整包。
用 rsync 族的滚动哈希块匹配（4KB 粒度），不是 bsdiff —— 后者需 17×N
峰值内存（88MB → 1.5GB），而升级恰可能发生在内存紧张时。
真实二进制实测：88,036,728 字节 → 补丁 77,316 字节（0.088%）。
三道闸：应用前验旧文件 sha256（错基线会静默产出垃圾）、应用后验结果
sha256、COPY/LITERAL 越界防护。任何失败**退回整包**，不向上抛 ——
差分是优化，不是可用性前提。
接入：Source.Resolve 优先试 delta；CheckRelease 按 -from-<commit8>.delta
匹配（不猜基线）；CLI 新增 -make-delta；打包脚本 build_delta（需
PREVIOUS_HOMED），delta 进 SHA256SUMS。
## 二、安装形态分派（internal/update/install.go + channel.go）
内核对「能不能自己升级」此前只有一个答案：直接替换二进制。而 deb/rpm
形态下那样做会让 dpkg/rpm 数据库与实际内容不一致（下次 apt upgrade
覆盖回旧版，或 dpkg 拒绝后续升级）。
新增探测：deb/rpm/tar/container/source 五类形态 + 变体（full/server/
client/toolchain）+ 目录写权限。判据全部来自可观测系统事实（dpkg 的
info 目录、容器标记文件），不做路径推断。
三端统一走 PlanUpgrade 分派；形态闸门放在**下载 880MB 之前**。
## 三、事件总线统一受安全监控（internal/events + security）
用户指正：「eventbus 上所有事件都要接受安全模块的监控」。
此前 EventPolicy 只被 internal/sdk/events.go 调用，而那是四条路径中的
一条。s.Publish / s.Subscribe / s.EventBus() 拿的是裸 *events.Bus，
任何插件都能绕过策略发任意事件（含伪造内核事件）。
现在闸门在 Bus.Publish/Subscribe 本体上（Guard 接口注入，避免 events
↔ security 成环），四条路径全部覆盖。sdk.EventBus() 改返回带身份的
BusHandle。内核身份免授权，但载荷照样过凭据闸门。
白名单按主体收窄：agent_output/stage/terminal_output 只允许承载者
（webui/cli/agentcli）发布 —— 它们是内核向外的输出面，谁都能发就等于
能伪造 agent 说的话。
## e2e 暴露并修掉的三个真实回归
[bus] subscribe denied: pluginmgr type=update_request
[bus] subscribe denied: skillmgr type=skill_detected
前两个让升级请求静默丢失、职责链交接断掉。内部协作事件必须可订阅
（安全边界在发布侧，订阅只是「听得到」）。
## 顺带的止血修复
- 回滚判据从 `--version` 改为 digest：旧内核（1.3.x 及以前）没有该
flag，而它恰是最常见的回滚目标 —— 原逻辑让「从旧版升级失败」永久
无法回滚。
- CopyFile 补 fsync（替换 homed 本体时掉电会留半截文件）。
- restore 完整还原才清 marker（原先先清再还原，还原失败就失去第二次
自愈机会）。
- 回滚时移除升级中新增的 depgraph（否则「旧 homed + 新 depgraph」
会因 digest 不匹配崩溃循环）。
- homed-upgrade 不再硬编码 systemctl restart（丢 guard 状态、unit 名
漂移）；改用内核已有的 restartCh → exit 42 语义。
- homed-upgrade 不再用 CGO_ENABLED=0 编却依赖 go-sqlite3（stub 下
静默失效，该路径从未工作过）；改用 internal/config。
- 服务单元补 User=hologramagent + 三条安装路径补建用户（此前发行物里
完全没有落实降权）。
- rpm 的 fpm 调用补 --after-install（此前 rpm 装完根本不建用户）。
## 判据
新增 30 条：差分 8（往返/压缩比/错基线/截断/篡改/边界）、通道 8、
执行器 6、事件闸门 8、按主体授权 8。全仓 go test ./... 0 失败。
2026-10-29 09:54:55 +08:00
55fa2685ae
feat(security,device): security 成为独立内核模块（闸门+策略+限式），device 接管内置工具路由
...
security（新模块 internal/kernelmod/security）
- 凭据闸门：出向拦截成 @{别名}、入向清洗、执行前回填（internal/security/{gate,runtime}.go）
- 工具黑白名单 + 沙箱（读写根、网络、.. 逃逸）：internal/security/policy.go
- 敏感词过滤 + 提示词注入预警（Finding 不带原文）：internal/security/content.go
- 按主体授权（hard-private 对非内部主体永久拒绝）：internal/security/principal.go
- 插件命名限式（可选档位，插件声明/内核执行，只能收窄）：internal/security/profile.go
- 启动装配从 cmd/homed 迁入模块；启动顺序判据改盯真实装配点
device（新模块）
- 正式内核模块，Provides FacDevice，KernelState.Device
- 内置工具路由表下沉到 internal/toolroute（避免 core↔kernelboot 环），
device 保留对外入口；agent 未挂载时退化本地 switch
- Agent 侧只留 api.ToolHost/DeviceSurface 适配层
SDK
- InjectOptions.SecurityProfile：插件按 inputch 声明本轮安全档位（可选）
- InjectOptions.TurnHint：插件注入**本轮事实**，内核以独立 system 消息注入，
不混进用户正文（人设负责怎么说话，TurnHint 只放这一轮成立的事实）
- FacilitySecurity / FacilityDevice
提示词
- 内核自带 prompt/skill/工具返回全面英文化（中文提示会让模型行为漂移）
- 机制解释下沉到 4 个内置 skill（memory/output/tool-order/plugins），
skill 描述压到 80 runes 内（原来 94–108 全被索引截断）
- 默认人格模板英文化；[Voice] 段删除，规则并入 persona 块（单一段落）
- 历史记忆工具改名 coldcontext_query/commit，图记忆语义改称 stable memory
修复
- tracker: exec mount → unix.Mount（降权运行 + AmbientCapabilities 下才能挂）、
区分 EPERM 与不支持；启动日志说明后果与恢复方式
- healthcheck_kernel 输出瘦身：status.Tools 只给摘要（原 98,989 tokens/151% 预算）
- plugin_list 描述讲清 auto_start（按需）与 alive（此刻是否在跑），
明确不能由 alive=false 推断能力不存在
- pluginmgr/webui 去掉写死的 /home/newqqagent 回退路径（env → pluginDir 反推 → 报错）
- lua: 盘上适配器与内置版本不一致且无基线时响亮告警（deepseek 流式丢失
tool_calls 导致'模型不调工具'的真因）
测试：go build ./... 通过；go test ./... 60 包全绿
2026-10-26 20:55:25 +08:00
817f6c59ae
fix(update): 重启交还 guard、OTA 支持 release/包两种来源、修三处真 bug
...
## 一、重启不再由 update 自己 systemctl（用户口径：应该通知 guard）
原 internal/update 直接 `systemctl restart homeagent`。三个问题：
① 杀掉整个 cgroup（unit 里 KillMode=control-group）⇒ **guard 跟着死**，
而 guard 存在的意义就是不让自己死。
② 丢失 exit 42 语义：guard 的 failures/failbackRound/failbackDone 全丢。
③ 自毁竞态：发命令的进程正是被重启杀掉的进程 ⇒ CombinedOutput 可能报错，
**一次成功的升级被误判失败而回滚**。
现在 internal/update 只到"产物就绪"：预检 → 备份 → 写 pending → 原子替换。
重启由调用方走**既有**通道（restartCh → exit 42 → guard 用新二进制重拉）：
· webui h.kernelCtl.RequestKernelRestart（本来就有，且是白名单内）
· pluginmgr p.sdk.KernelControl().RequestKernelRestart（见下面第三条）
· CLI 外部管理命令，restart unit 后按**版本自报**核对是否真生效
## 二、OTA 支持两种来源（release 自动更新 / 指定安装包）
新增 internal/update/source.go：
Source{Kind: FromPackage, Path} → 直接用本地包
Source{Kind: FromRelease} → 查最新 Release → 下载 → 校验 digest
ParseSource(pkg, release) 统一判空规则（pkg 优先），避免三端各写一套。
两条来源解析后进**同一条** Apply，不存在两份升级实现。
## 三、修三处已提交代码里的真 bug
① **HEAD 编译不过**：d17e261 提交了 kernelmod/update/mod.go（引用 ks.Update），
但 kernelboot/kernelstate.go 的字段改动从未提交。干净 worktree 实测
`ks.Update undefined` —— 推上去的仓库是坏的。本次补上。
② **kernelDataDir 算错一级**：Dir(Dir("/home/newqqagent/plugins")) = "/home"，
而第 0 层 update 模块从 ks.DataDir=/home/newqqagent 读 pending
⇒ **agent 发起的升级一旦启动失败就永不回滚**（静默失效）。改为 Dir 一次。
③ **pluginmgr 的 KernelControl 恒为 nil**：它不在 kernelControlAllowed 里，
于是 `if kc := p.sdk.KernelControl(); kc != nil` 永不成立 ⇒
换完二进制**从不重启** ⇒ pending 留着 ⇒ 下次重启被判"未确认"而回滚。
修法**不是**把 pluginmgr 加进完整白名单 —— 那等于让 LLM 能关机整个服务
（kernel_control_gate_test 明确拦这个）。而是拆出**仅重启**授权：
kernelControlAllowed = {webui} 完整（含关机）
kernelRestartAllowed = {pluginmgr} 仅重启（shutdown 直接报错）
两者的危险程度差一个量级：重启几秒后 guard 自己拉回来，关机不会自己回来。
## 四、EventBus：插件请求更新不必 import internal/update
新增 events.EventUpdateRequest，pluginmgr 订阅并受理：
scope=kernel → kernelUpdateApply；scope=plugin → pluginUpdate(apply)。
它在 internal/plugins/webui 的 SSE 守卫里显式登记为**内核内部控制事件**
（不该推给浏览器：前端要的是 update_progress/update_result，不是"谁发了请求"）。
## 五、顺手修掉的静默失败
· webui /kernel/update 原实现：**先**写 202 Accepted，**再**解析 body，
之后每个错误都直接 `return` —— 用户看到"已受理"然后什么都没发生。
改为同步 Apply（失败可如实报 HTTP 状态），成功后才请求重启。
· pluginmgr 拿不到控制通道时不再假装成功，而是回报 applied=true + 明确原因
（否则用户以为已升级，进程却还在跑旧镜像）。
· update 事件 publishResult 的 errMsg 原先是死代码（`_ = errMsg`），
按 payload 约定写回 error 字段。
2026-10-26 13:45:54 +08:00
5b759e80d7
feat(update): 更新进度走 EventBus + SSE（穿越进程重启的通知通道）
...
## 为什么必须走事件总线（用户口径：为什么不走 eventbus）
升级是**长耗时且会让进程消失**的动作。此前进度只往 log.Printf 写，
WebUI 要看得自己轮询 /kernel/update —— 而轮询在重启瞬间必然断线，
断线那一刻恰恰是用户最需要知道"升到哪一步/失败了/已回滚"的时刻。
EventBus 是内核既有的发布订阅机制（同步投递、handler panic 隔离），
用它不需要新造一条通知通道。
## 三个新事件类型
update_check 检查结果（只读，不改动）
update_progress 升级步骤：verify/backup/replace/restart/rollback/done/failed
update_result 最终结果（含回滚轨迹）
## ★ 顺序约束：先发事件，再动作
升级尾部几步（replace → restart）会让进程消失。顺序一反，最后几步的
事件永远发不出去。所以每个 publish* 都紧贴在其描述的动作**之前**。
## 直接 import events，不搞接口垫层
第一版我写了 EventPublisher 接口 + map[string]interface{} payload 想
"避免依赖"，那是自欺欺人：events 包**不依赖任何内部包**（已验证），
import 它不会成环；而垫层会把事件降级成无类型 map，丢掉编译期检查。
已回退该设计，改为直接传 *events.Bus。
## SDK 补 EventBus() getter
PluginSDK 原先只有 Publish/Subscribe，没有暴露总线对象。而长流程
（升级闭环）需要把总线本身传下去持续发事件 —— 只给 Publish 的话，
每个调用点都要手动转发一遍。
## SSE 通路（守卫判据逼出来的正确修法）
TestEveryPublishedEventHasAnOutwardPath 抓到三个新事件"有发布者但无对外
通路"——症状是「发了、没报错、客户端收不到」。修法不是加白名单豁免，
而是真的接进 SSE：三者都进 sseEventRing（不只是实时推送），
断线重连要能补到**最终结论**（update_result），否则用户重连后只看到
"开始升级"而没有结局。
## 调用点
· pluginmgr（kernel_update）：p.sdk.EventBus() → DoUpgradeBus
· webui（/kernel/update）：h.sdk.EventBus() → runKernelUpgrade(pkg, bus)
· CLI：bus=nil，退化成纯 printf（CLI 没有总线）
2026-10-26 09:23:58 +08:00
d65b742bd7
fix(plugin): 修两处持锁自死锁（CI 双红真因）+ tools_ready 事件声明
...
## 死锁（这是 CI 连续两次红的真因）
`StopAll` 与 `StopPlugin` 都在持有 `r.mu` **写锁**时调用
`RemoveBuiltinSkill` → `skillDirOf` → `r.mu.RLock()` ⇒ **自死锁**。
后果不是报错而是**卡死**：
- internal/plugins 卡 300s 超时（TestCapability_RestrictedPluginStillLoads）
- internal/plugin 卡 840s 超时（TestStopPluginDoesNotTouchPersistentState）
- CI 的 `go test ./...` 与 `go test -race` 双双红
修法：拆出**不加锁**的内部版本，持锁路径只走它：
- `skillDirFrom(dataDir, name)`（纯函数）
- `removeBuiltinSkillLocked(pluginName, p, dataDir)`（显式传 dataDir，
避免"看起来没取锁、一改就取锁"的隐患）
- `announceSkillRemovedLocked`（持锁下直读 r.evBus）
修后：internal/plugins 300s → 12s，internal/plugin 840s → 0.7s。
## 防回归判据
`TestStopAllAndStopPluginDoNotDeadlock`：死锁**不返回**，普通断言抓不到，
所以用**超时**当判据（5 秒未返回即失败），并指明应改用 Locked 版本。
## tools_ready 事件声明
新增的 tools_ready 触发 `TestEveryPublishedEventHasAnOutwardPath`
（该判据防"事件发了、客户端收不到"的静默失效）。
tools_ready 是**内核内部**就绪信号（plugin-host → seq 等订阅者），
不是对话流程事件，前端无需感知 ⇒ 在 allowed 里显式声明理由。
## 验证
go build ./... / go vet ./... / go test -p 1 ./... / -race 全通过。
2026-10-25 18:25:37 +08:00
9036db9321
feat(memory): 图数据库自报真实读写事件，取代「按工具名猜节点」
...
## 问题（生产实证）
星图的「跟随 agent 活动」此前靠**工具名词元猜节点**：把 `memory_recall`
拆成 [memory, recall] 去匹配实体名。而图谱里的实体名是**中文概念**
（小宅/对话/待命），工具名是英文 —— 两套命名空间永不交集。
实测（生产库）每个工具名命中 **0** 个节点：
hint=memory_recall → memory/recall → 0
hint=files_read → files/read → 0
hint=knowledge_search → knowledge/search → 0
匹配失败后走「补齐」分支，按 mention_count 取前 8 个 ⇒ **无论 agent 在干什么，
点亮的都是同一批无关节点**（小宅/对话/待命/投递/图片/文档/插件/老大）。
这就是「星图没有读写反馈」的真身。
## 改法：让图数据库在真正读写处上报
新增 `events.EventMemoryAccess` + `GraphDB.AccessHook`，在读写入口埋点上报
**真实块 ID**（不再猜）：
| 操作 | 埋点 | 上报 |
|---|---|---|
| 读 | RecallSorted | blocks |
| 写 | commit | blocks + **created**（真正新建的） |
| 删 | DeleteEntity | removed |
| 合 | MergeBlocks | merged(from→to) + removed |
三处关键设计：
1. **钩子用独立锁** `hookMu`。用 `g.mu` 会**自死锁** —— 埋点方法已持该锁，
而 Go 的 RWMutex 不可重入。
2. **上报在锁外**。拆 `commit`→`commitLocked` 两层解决 `defer Unlock` 的时序：
钩子内部可能要回调内存系统（如 SSE 订阅者补数据），持锁调用必死锁。
3. **区分「新建」与「更新」**（`putBlockTx` 返回 isNew）。用 SELECT 判存在性
而非 `RETURNING (xmax = 0)` —— 后者在**事务 + ON CONFLICT** 下报
`no such column: xmax`（实测：autocommit 可用、包进 tx 就不可用），
而本函数只在事务里被调用。重复提交同一事实不会重复播「生长」动画。
接线：`bootstrap.newMainAgent` 里 `memDB.SetAccessHook(...)` → `events.Bus`。
只在 `evBus != nil` 时接，把「内核进程」与「独立 CLI 工具」
（homed-graph-migrate / memgc 也用 NewGraphDB）区分开 —— 后者不该为一次
批量迁移向不存在的订阅者发几万条事件。
## 验证
- `access_hook_test.go`：钉住 commit/recall/delete 三类埋点真的触发、
且重复提交不误报新建
- `access_hook_race_test.go`：4 写 + 4 读 + 钩子热替换并发，`-race` 下无竞态、
无死锁；**断言事件数 > 0**（否则「钩子从未触发」也会假通过）
- 该测试起初是 flaky 的（读者可能在写者落库前查询 ⇒ 空结果不报事件 ⇒
断言随机失败）。修法是先播种确定数据再并发读，已连跑 3 次稳定
- 生产实例端到端：CLI 注入一句话 → SSE 收到 6 条 memory_access，
带真实块 ID 与 op/created
2026-10-08 10:41:07 +08:00
41f8510fc3
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
d973bf734a
feat(skillmgr): 原生技能管理器插件 + OpenClaw 兼容层职责分离
...
新增 internal/plugins/skillmgr（native skill 全生命周期 owner）：
- skill_list/info/load/unload/enable/disable/create/export/install
- skill_create 两步式：先生成骨架模板，LLM 补全后传 content 覆盖写入
（plugin.ValidateSKILLContent 校验）并自动加载生效
- .skm 分发包（tar.gz）：packSkill/unpackSkill 含 TarSlip 防护
（拒绝绝对路径/../逃逸、强制单根目录、校验包内 SKILL.md）
- skills 目录扫描：纯 SKILL.md/skill.json 条目归本插件；
sidecar(main.js/main.py)/OC plugin(openclaw.plugin.json) 留给兼容层
clawhubadapter 职责分离（OpenClaw 兼容层不再持有 native skill）：
- 删除 p.skills 字段与 default 分支 LoadSKILL 逻辑
- 发现纯 SKILL 条目改为发布 events.EventSkillDetected 移交事件，
由 skillmgr 订阅注册；启动时序 c<s 下全扫兜底，事件用于热新增
- claw_list/plugin_info 不再输出 SKILL 段，统一走 skill_list
方案B prompt 注入：
- agentCore 新增 SkillIndexProvider 接口 + SetSkillIndexProvider
- buildSystemPrompt 注入【可用技能】轻量索引（名称+版本+描述），
LLM 匹配场景时主动 skill_info 拉全文按文档执行
- main.go 在插件加载后将 skillmgr 实例接线到 agent
内核小修：
- extractDescription 跳过 YAML frontmatter 块（此前所有带 frontmatter
的 SKILL.md 描述都被误判为 '---'）
- extractField 剥离 YAML 成对引号（version: "1.0" 不再带尾引号）
- plugin.ValidateSKILLContent 导出供生成侧校验
2026-08-25 20:25:57 +08:00
fd8924319b
feat(agent): token-level streaming in core process loop
...
Replace the blocking Chat() call in process() with
chatStreamWithFallback: ChatStream first, accumulate chunks, fall back
to non-stream Chat on connect failure or empty-stream failure.
Why: the non-streaming path blocked for the ENTIRE LLM generation (up
to the 180s HTTP timeout). Reasoning models thinking 60-120s plus AUTO
chain failover regularly exceeded it -> context canceled -> full turn
wasted. With streaming the first chunk arrives in ~1-3s and any
flowing token keeps the connection alive; total generation time is no
longer bounded by an overall timeout.
Compatibility (external behavior unchanged):
- process() signature/return values unchanged
- Aggregated events (EventReasoning / EventAgentLLMChain) still fire
once per turn with full text after stream completion - existing
plugin subscribers see identical payloads as before
- New incremental events EventReasoningDelta / EventContentDelta are
additive; old subscribers ignore unknown event types
- Tool execution loop, memory pipeline, stage pipeline untouched
Streaming details:
- Tool call fragments accumulated per OpenAI streaming convention:
id/name arrive on the first fragment, arguments as raw JSON string
shards across fragments; merged and parsed once at stream end
- normalizeStreamToolCalls keeps nameless argument shards (the
non-stream normalizer drops them); ToolCall gains RawArguments to
carry shard text
- Interrupt mid-stream returns partial content instead of discarding
the whole generation
Verified end-to-end against llmsproxy: plain chat streams correctly;
curl confirms tool-call shard wire format ({" + command" + :"date"}
-> {"command":"date"}); unit tests cover shard merging and
content/reasoning accumulation.
2026-08-25 09:30:49 +08:00
8160bbf3e9
fix: LLM 工具循环 400、中断消息注入、ConPTY 终端支持
...
- agent: 工具轮请求尾部补 user 占位(zen 网关强制),tool 消息正确配对
- agent: 工具提醒/中断以 system 角色注入并带 [中断消息] 前缀,不进用户履历;系统提示词说明中断消息格式
- agentcli: 基于 ConPTY 的交互式终端(ptywin fork),terminal_create/read/write/resize/close/watch
- webui: server 输出通道适配器(保留 reasoning_content/disable_thinking)
- GUI: 沉浸式标题栏、icon 圆角重制、mascot 等打磨
2026-08-14 00:48:40 +08:00
9bee5295b8
feat: output channel redesign - per-channel output gates, LLM chain events, SDKConfig
...
- Output channels generate per-channel tools: output_send__{name} (type=output) + output_send__{name}_help
- content is JSON string transparently passed to plugin handler for routing
- EventAgentLLMChain: full LLM response forwarded after each turn for webui/logs
- sdk.New refactored to SDKConfig struct (no more 13 positional args)
- RegisterOutputChannel adds desc param for JSON format documentation
- channelDevice simplified (no Tools method), desc field added
- Child agent permission updated for output_send__ prefix
- System prompt: output gates, multi-call, long messages split
- WebUI: subscribes to EventAgentLLMChain in SSE, no output channel
- Tests updated for new naming convention
2026-07-16 12:11:16 +08:00
d6be15d165
fix: 模型思考模式配置 + Unicode 截断 + 审计修复 (13 files)
...
模型模式:
- 新增 LLMConfig/Source.ThinkingEnabled 配置，通过 ExtraBody
控制 DeepSeek thinking mode，默认关闭
- SeedDefaults/ToConfig 读写 core.llm.thinking_enabled
- deepseek.lua 移除硬编码 temperature=0
Unicode 截断:
- truncateStr 改按 rune 计数，修复中文截断乱码
审计修复 (Critical):
- graph.go: defer rows.Close 在 for 循环 → 显式 Close (连接池泄漏)
- cli/openclaw/plugin.go: bare type assertion → comma-ok (panic)
- channel.go: payload["type"].(string) → comma-ok (panic)
- webui/handler.go: .(string) → fmt.Sprint (panic)
- agent.go: 添加 nil provider 错误返回
审计修复 (High):
- events/bus.go: copy handler slice under RLock (data race)
- webui/handler.go: SSE 通过 channel 串行化写入 (data race)
- timer/plugin.go: time.Sleep → select with stopCh (Stop 阻塞)
- provider.go: stream ch <- 添加 select ctx.Done (goroutine 泄漏)
- main.go: outputCh goroutine 添加 ctx.Done 退出路径
2026-07-03 20:46:04 +08:00
d26041bee8
v4 architecture: pipeline stages, SDK, event bus, LLM-driven memory consolidation
...
- SDK PluginAPI (internal/plugin/sdk/): RegisterTool/RegisterStage/Subscribe/Publish
- EventBus (internal/events/): system-level pub/sub with wildcard support
- StageHost (internal/agent/core/stages.go): 7-stage message pipeline
- Agent core: on_input/pre_action/post_action/before_toolcall/after_toolcall/before_output/after_output
- Plugin Registry: SDK plugin registration and tool routing
- GraphDB.MergeEntities: entity consolidation with relation redirection
- memory_merge tool: allows LLM to merge similar entities
- Consolidation task: heartbeat detects conflicts, enqueues via IO for LLM decision
- _consolidation_ internal channel for system-level memory maintenance
- Comprehensive documentation: ARCHITECTURE.md, PLAN.md, DESIGN.md, README.md
- 54 tests across all packages, all passing
2026-07-03 08:04:39 +08:00
