* feat(commondev): 主管式多仓库开发流水线 + sidecar 后端抽象(pi/zcode)
## 是什么
agent 统筹开发流程的插件:登记项目 → 开工程线(每条线一个隔离工作目录 +
一个 sidecar 子进程 + 一对通道)→ 投递任务 → 同会话续投 → 评审/合入。
38 个工具:project_*/branch_*/workdir_*/job_*/review_*/test_*/
endpoint_*/agent_*/pi_*/conflict_check。
## sidecar 后端抽象(本轮核心)
传输层(local/ssh)与后端(pi/zcode/自定义)**正交**,四个自由组合:
driver.json 描述一个后端:script / cliPath / env / args / llmConfig
三级查找:插件数据目录 → **随包 rawfile** → 内置 pi 描述
占位符:{workdir} {dataDir} {pluginDir} {rawfile} {sessionId}
★ 内置 pi 回退**与默认后端解耦**(2026-10-17 修):原实现写
`if cli == defaultAgentCLI { return builtinPiDriver() }`,把"给谁兜底"
和"默认选谁"耦合到同一常量 —— 一旦有人改默认,pi 当场失去兜底,
显式 cli="pi" 开始报「驱动不存在」。现在判断字面 "pi"。
默认后端保持 **pi**(我们本地主用);交付方用 zcode 走两种局部开关:
· 单线:commondev_branch_open(cli="zcode")
· 按机器:commondev_endpoint_set(host=..., cli="zcode")
## zcode 接入(三条真机判据,全部要求真改工程文件)
· TestZcodeFullPipeline(29-34s):随包 driver + 真实 ZCode CLI
· TestZcodeOverSSH(39s):真 ssh + scp,远端 node 跑 zcode
· TestZcodeOverSSHWithPerHostEndpoints(68s):两个 host 别名配不同
cli_path,走端点表而不是全局 settings
★ 会话库必须隔离到工作区(sidecar.mjs 的 ensureWorkspaceSessionStore):
实测 ZCode 的会话库路径**硬编码 homedir()**,`ZCODE_DATA_BASE_DIR` 对它
完全无效(26 个会话全落全局库)。但 `<workdir>/.zcode/config.json` 的
`storage.sessionDbPath` **确实生效**。所以启动前写一份工作区配置,
一举解决:多线不共用历史 / 不污染全局 ~/.zcode / 删线不留孤儿会话。
只在不存在时写 —— 用户手工放的要尊重。
## 其他
· rawfile:项目根 rawfile/ 默认全收,解到 <插件目录>/rawfile/,绝对路径拒绝
· 凭证:命名引用 + ${ENV_VAR},独立 0600 文件,绝不进 config.db(0644)
· secretshell:给不受信 agent 用的安全 shell(ackey + safeshell)
· 冲突检查 / 评审判据 / 镜像 / 每条线独立 workdir(hash 命名,合并后删除)
判据 30+ 条,含 4 条「判据本身的判据」(防止判据假绿)。
* fix(sdk): 协议通道纪律 + hmapdev 模板升级 + 示例插件 stdout 污染
## 核心缺陷:插件往 stdout 打日志 = 污染 JSON-RPC 协议通道
子进程插件与内核用 stdout 传 NDJSON 帧,stderr 才是日志通道。
脚手架模板(及 4 个示例插件)用 `fmt.Printf` 打日志 ⇒ 内核收到非 JSON 文本:
[proc] weather 收到非法 JSON 帧(21 字节): invalid character 'i'
**生产实测 1038 条**(huawei_smarthome 720 / weather 113 / rss 103 / calendar 102)。
后果不只是日志噪音:那一行日志被**丢弃**,插件看起来"没启动"。
修法:
- hmapdev 模板 `fmt.Printf` → `log.Printf`(9 处)
- 示例插件 4 个 14 处:ai_image(2) calendar(5) rss(4) weather(3)
+ 补 "log" import
- 内核侧(主仓)同步让报错可定位:内容摘要 + 可能原因 + 修法
判别法:`package main` = 子进程(协议通道,禁用 stdout 打日志);
普通库包 = 进程内插件(编译进内核,写真实终端,**不是**缺陷)——
`internal/plugins/cli` 的 `fmt.Println` 属后者。
## hmapdev
- `cmd_build.go` +136:平台产物精确匹配(`--target` 是**append** 语义,
原脚本 `ls dist/*.hmap | head -1` 会按字典序抓到 amd64,
**导致 arm64 包里装的是 x86-64 二进制**,且退出码 0、校验和通过)
- `cmd_init.go` +46:脚手架 stdio 纪律
- `templates/proc_main.go.tmpl`:补齐 mgrStop/mgrStart/mgrIsRuntimeStopped
三态能力(插件管理器运行态停启)
- `templates/plg.json.tmpl` 删除(合并进 cmd_init)
## 判据
- `scaffold_stdout_test.go`(3 条):扫模板生成的代码不得写 stdout。
★ 判据自身先假红过一次:**模板的注释里就写了 `fmt.Printf`** ⇒
必须 `stripTemplateComments()` 之后才判
- `example_stdout_test.go`(2 条):扫全部 20 个子进程示例插件,
报错给**文件:行号**;变异咬住并给出准确行号
- `package_examples_test.go`(2 条):**执行真实打包脚本**
(第一版测的是 hmapdev 而不是脚本 ⇒ 变异不咬)
- `cmd_build` / `cmd_init` 新判据
## 其他
- sdk/settings.go +15(三态能力透传)
- `docs/versions.md` +§示例插件协议通道纪律(含生产 1038 条实测表格)
- `skills/homeagent-plugin-dev/SKILL.md` +§协议通道纪律(正误代码对比)
* fix(examples): 恢复 go.mod 相对路径 + 移除 plg.json 的 sdk 固定(修 CI 红)
CI 上 `Examples (linux/amd64)` 与 `(darwin/arm64)` 双红,只有两个失败:
✗ commondev 构建失败
✗ editdoc 构建失败
error: 项目声明 sdk=1.4.0,但本地 SDK 存储里没有这个版本
其余 20 个示例全部成功 —— 说明不是通用问题,而是这两个被改坏了。
## 根因(两个叠加)
**① go.mod 被本机绝对路径污染**
我在上一个提交里用 `git add -A`,把本机 `go build` **自动改写**过的
go.mod 一并提交了:
require github.com/JianFeeeee/homeagentsdk v1.4.0
replace github.com/JianFeeeee/homeagentsdk => /root/.homeagent/hmapdev/sdk/v1.4.0
基线(origin/main)是:
require github.com/JianFeeeee/homeagentsdk v0.0.0
replace github.com/JianFeeeee/homeagentsdk => ../../
本机那个目录真的存在 ⇒ 本地全绿;CI 没有 ⇒ 必红。
**② plg.json 声明了 `"sdk": "1.4.0"`**
一声明版本,hmapdev 就去**本地 SDK store** 找它,找不到直接拒绝构建。
全仓 20+ 示例**都不声明**,只有我改过的这两个声明了。
示例的正确依赖表达是 go.mod 的 `v0.0.0` + `replace ../../`。
## 修法
两个文件都恢复到与其余示例一致的写法。
## 判据(3 条,都是新加的)
· `TestExampleGoModHasNoAbsoluteReplace`:任何示例 go.mod 不得含
`/root/`、`/home/`、`/Users/`、`C:\`
· `TestExampleGoModUsesRelativeSDKReplace`:replace 必须是相对路径 `../../`
· `TestExamplePlgJsonDoesNotPinSDKVersion`:plg.json 不得声明 sdk
变异 2/2 咬住(重新引入绝对路径 / 重新声明 sdk,都准确报出文件路径)。
## 本地验证(模拟 CI 干净环境)
用干净 HOME 跑 `package/build-examples.sh`:
· 修复前:成功 18 / 失败 4(commondev, editdoc, browser, rss)
· 修复后:成功 20 / 失败 2(browser, rss —— **本机代理不通**,
`proxy.golang.org` 超时;用本地 modcache 验证这两个可正常构建)
即 22/22 源码都能构建,CI 有网络不受影响。
## 教训
`git add -A` 会把「构建工具自动改写的文件」一起提交。
提交前必须 `git status` 逐个看,尤其 go.mod / go.sum。
---------
Co-authored-by: JianFeeeee <JianFeeeee@users.noreply.gitcode.com>
qq · QQ 消息桥接
通过 NapCat 把 QQ 接成 HomeAgent 的一个 IO 通道: 让 agent 收发 QQ 消息、读群/好友信息、传文件。
⚠️ 这是安全敏感插件:它让外部 QQ 用户能触达 agent 的工具。 本文档的「权限模型」一节请务必读完。
通道与钩子
| 类型 | 名称 | 说明 |
|---|---|---|
| 出站 | qq |
CapText + CapFile + CapImage + CapAudio;发消息/文件给 QQ |
| 入站 | qq |
NoMemory: true + Cleaner + RecallPolicy: None |
四个阶段钩子(全部 StageScopeGlobal):
| 钩子 | 作用 |
|---|---|
on_input |
把本轮 QQ 身份绑到帧上 |
before_toolcall |
权限门:逐个工具判断是否放行 |
post_action |
清掉被拒绝时模型已经吐出的废话 |
after_output |
收尾时清理插件全局身份 |
工具(20 个)
| 工具 | 说明 |
|---|---|
qq_get_message |
按 message_id 取消息正文、发送者、附件 |
qq_get_history |
取群/私聊最近历史消息 |
qq_list_chats |
会话列表(按最新消息排序,带未读数与摘要) |
qq_mark_read |
把某会话未读数清零 |
qq_send_file |
发文件/图片(私聊或群聊) |
qq_get_groups |
群列表,可按关键词搜 |
qq_get_friends |
好友列表,可按昵称/备注搜 |
qq_get_recent_contacts |
最近有消息的联系人与群 |
qq_resolve_name / qq_resolve_nickname |
名字 ↔ QQ 号互查 |
qq_get_group_member_info |
群成员信息 |
qq_group_manage |
群综合管理(见下) |
qq_friend_action |
好友操作 |
qq_get_group_files |
群文件列表 |
qq_download_file / qq_upload_group_file / qq_get_download_tasks |
文件传输与任务 |
qq_read_document |
读 QQ 传来的文档 |
qq_video_download |
下载视频 |
qq_send_like |
点赞 |
qq_group_manage 一个工具承载多种操作(command 参数):
leave 退群、kick 踢人、ban/unban 禁言解禁、rename 改名、mute-all 全员禁言、
set-card 设名片、set-admin 设管理、set-title 设头衔、member-list、group-info、
msg-history、recall 撤回、pin-msg 精华、list-files、pending-requests、folder-create 等。
破坏性操作(leave/kick/ban/unban/rename/mute-all/set-card/set-admin/
set-title/recall/pin-msg/folder-create)必须显式传 confirm: true。
权限模型
这是本插件最重要的部分。
身份分级
| 身份 | 权限 |
|---|---|
| owner(Bot 所有者) | 私聊或群聊均完整放行 |
| 普通 QQ 用户 | 只放行白名单内的工具 |
身份必须「绑帧」,不能只存插件全局
源码注释记录了两个真实故障,这就是绑帧的原因:
- 中断抢占后身份丢失:中断会抢占当前轮、把现场压栈。中断轮收尾时
after_output会清空插件全局身份;随后外层被恢复(resumeTask复用同一帧、 不重跑on_input)。若身份只存全局,恢复后的外层就是"无身份",before_toolcall在!auth.active处直接返回 —— 整个权限门失效。 - 运行中到达的消息改写身份:新消息会调
activateAuthContext改写全局身份, 把正在跑的那一轮换成另一方的身份(换高=越权,换低=误拒)。
帧上的 Extra 随帧一起压栈/恢复,正好是"这一轮的身份"。
合并取最小权限
多来源被内核合并到同一推理时,权限取交集而非并集:
p.auth.owner = p.auth.owner && next.owner
防的是"非所有者请求 + 随后所有者消息"意外把前一个请求提权。
硬私有工具
非所有者一律拒绝(不看白名单),按前缀拦截:
calendar_、email_、mail_、agentmail_、memory_、knowledge_、device_、
devicectl_、terminal_、shell_、command_、exec_、filesystem_、agentfs_、
config_、settings_、plugin_、plugins_,
外加 read_file、write_file、edit_file、delete_file、list_files、run_command、
homeagent_config、homeagent_restart、output_send__email、output_send__mail。
参数与会话一致性校验
光看工具名不够,还要检查参数指向的会话与当前身份一致,否则可以拿别人的
message_id 去读别处内容:
- 带
message_id的工具:该 ID 必须属于当前 QQ 会话(lookupMsgRef校验 peer 与群/私聊类型)。 get_group_member_info/get_group_files:group_id必须是当前群。
频率与重复控制
| 键 | 作用 |
|---|---|
max_qq_tool_calls |
单轮工具调用上限 |
max_qq_output_calls |
单轮输出调用上限 |
max_duplicate_qq_send |
重复发送上限,防刷屏 |
batch_window_ms / batch_max_ms |
消息合批窗口 |
被拒时只允许发一次权鉴说明,之后锁止本轮剩余工具调用
(clearDeniedResponse 再把模型已写出的内容清掉,避免输出里带一堆"我不能…")。
配置项
连接
| 键 | 默认 | 说明 |
|---|---|---|
napcat_url |
— | NapCat 服务地址 |
listen |
— | 本插件 HTTP 监听地址 |
webhook_token |
— | webhook 校验令牌 |
身份与准入
| 键 | 默认 | 说明 |
|---|---|---|
owner |
空 | Bot 所有者 QQ 列表(逗号分隔),拥有完整权限 |
admin |
空 | 旧配置名,owner 为空时作为所有者列表(兼容用) |
dm_policy |
open |
私聊策略:open / allowlist / disabled |
allow_from |
空 | 私聊白名单(QQ 号,逗号分隔) |
group_policy |
open |
群聊策略:open / allowlist / disabled |
group_allow_from |
空 | 群白名单 |
private_tool_allowlist |
空 | 私聊下非所有者可用的工具 |
group_tool_allowlists |
空 | 按群配置的工具白名单 |
文件与转发
| 键 | 说明 |
|---|---|
files_dir |
本地文件目录 |
remote_dir |
供 NapCat 容器访问的目录(发文件前先复制到这里) |
agentfs_dir |
agent 文件系统目录 |
forward_rules |
JSON 数组,每项 {group_id,host,port,password,template}:匹配的群消息经 RCON 转发到 Minecraft;template 支持 {nickname} / {message} 占位 |
部署前提
需要自行部署 NapCat(本插件不含 QQ 协议实现,只是 NapCat 的客户端)。
发文件前会先把文件复制到 remote_dir,因为 NapCat 通常在容器里,看不到宿主任意路径。
测试
go test -count=1 -race ./...
含权限门与绑帧的回归测试。改动权限相关代码后务必跑 -race。
构建
hmapdev build