feat(security): 插件按工具声明内容策略 + 目录名统一

## 一、插件声明层(用户裁定)

> 「敏感词策略也应该是插件声明啊,每个插件声明自己轮次以及自己工具的
>   敏感词策略」

SecurityProfile 新增两个字段:

  ToolSensitiveWords map[string][]string  // key=工具名模式(尾 *),value=词表
  DetectInjection    bool                 // 开启内核内置注入迹象识别

语义是**追加不覆盖**:整轮 SensitiveWords 仍然生效。
取宽不取窄的理由:当前处置是 B 档(标记+警示,不阻断),
多标一条只是多一句警示,漏标则是安全缺口。

## 二、修掉我自己造的「莲藕式分层」

前一版把 *security.Round 从 runInputTask 一路搬到工具链
(prepareInputTask(evt, round) → TaskFrame.SecRound →
executeToolCallOutcomeWithRound),并在 rtchild 里另补一条。

那是把**分层策略实现成跨层传参**:每多一条工具执行路径就要求调用方
多传一次句柄。profileActivator 的设计注释早就写明了正路:

> 工具调用发生在 LLM 决定之后,此时插件已不在调用栈上。
> 唯一可靠的传递方式是**内核在输入进来时记住**,在该轮的工具判定里使用。

改为 security 自取:

  Runtime.ScanContentForAgent(agentID, isChild, ins, text)
    → ForAgent(agentID, isChild)   // per-agent 视图,天然不串档
    → EffectiveProfile()           // session > longtime
    → 合并 全局词表 + 档位词表 + 工具词表 + DetectInjection

core 只递交**事实**(我是谁 / 哪个工具 / 什么文本),不认识 Round。
与 CheckToolForAgent 同一套身份推断,不引入第二个入口语义。
TaskFrame.SecRound / executeToolCallOutcomeWithRound 全部撤除。

## 三、目录名统一

third_party/homeagent-sdk → third_party/hologramagentsdk

module 与远端仓早已是 hologramagentsdk,只剩物理目录是遗留名。
同步改了 go.mod replace、构建/打包/部署脚本、5 处测试里的分段路径。
注意:这里改的是**主仓 vendored 的 SDK 源码路径**,example/ 由 SDK
独立仓自己跟踪,主仓不涉及。

## 判据

TestToolSensitiveWordsAppendOnlyForThatTool   词表只对目标工具生效 + 追加语义
TestToolSensitiveWordsUseAgentScope           security 按 agent scope 自取生效
(变异验证:删掉 ForAgent 查询 → 红)

## 验证

	go build ./...                 → 0
	go vet ./...                   → 0
	go test ./... -count=1 -race   → 62 ok / 0 FAIL / 0 DATA RACE
	gofmt -l internal/             → 干净
This commit is contained in:
JianFeeeee
2026-11-03 09:51:11 +08:00
parent 9ab19f7493
commit 81a0f5f598
53 changed files with 201 additions and 78 deletions

View File

@ -0,0 +1,37 @@
package sdk
// KernelControlAPI:插件请求**内核本身**重启或关机。
//
// ## 为什么需要它
//
// 有些状态变更只能靠重启内核生效(典型:改了 LLM 源、换了主密钥、
// 升级了要重新装配的配置)。没有这条通道时,用户只能自己去 ssh 上敲
// systemctl —— 而 WebUI 是大多数人唯一会用的界面。
//
// ## 语义边界(重要,别指望它做更多)
//
// 这两个方法都是**异步**的:它们只把请求投递给内核,立刻返回。
// 调用方(WebUI)应当先给用户一个明确回应("正在重启,页面稍后自动重连"),
// 而不是等待返回 —— 内核真的会在这几秒内消失。
//
// 进程会怎么走:
//
// RequestKernelRestart ⇒ 内核清理(停插件、flush、CloseAll)→ exit 42
// → guard 用**当前二进制**重拉,不经过 systemd、
// 不计失败轮次(这就是"热更新"那条路)
// RequestKernelShutdown ⇒ 内核清理 → 通知 guard 主动停机 → systemd 不再拉起
//
// ★ 关机为什么不能用"guard 退出"实现:systemd 是 Restart=always,
//
// guard 退出会被它无条件重新拉起。必须显式 `systemctl stop`)
//
// ## 失败语义
//
// 返回错误只表示**请求没被接受**(例如内核未装配控制通道、或该功能被禁用),
// 不表示"没重启成功"——成功投递后本进程就会退出,返回值本身没有后续。
type KernelControlAPI interface {
// RequestKernelRestart 请求重启内核(热重启,guard 重拉)。
RequestKernelRestart(reason string) error
// RequestKernelShutdown 请求关闭内核(systemd 不再拉起)。
RequestKernelShutdown(reason string) error
}