WorkBuddy与DSH组合：企业级AI Agent落地新范式
2026/10/2 22:57:46
> 上一篇：26-3《VQF v2 布局再回首：加密 + 签名如何共存》｜ 下一篇：27-2《出证帧规范：body_sha 与输出文本的字节绑定》
> **源码精读篇**：本文为源码/方法论精读，无独立实测；文中数字均引述仓库 docs 的板端实测记录
> **一句话导读**：三问三防：权重、记录、出处——把可信边界从权重文件延伸到跑出来的回答，讲推理引擎为每次完成的响应打设备签名数字凭证、三道防线为何正交，以及验证方只凭请求原文、输出文本与公钥就能离线验签的落点。
> **关键词**：手搓推理引擎、大模型推理、三问三防、权重记录出处、可验证推理、attestation
Day 23–26 一直在护**权重**：加密防"拷走"、签名防"掉包"。但推理系统的可信不止于权重——**跑出来的回答**同样可以被改、出处可以被赖。Day 27 进可验证推理：引擎给每一次完成的响应打一张 SM2 签名的"数字凭证"，验证方只需保留请求原文、输出文本与设备公钥，就能离线复算验签。这篇先立框架：三问三防各是什么、三道防线怎么正交、为什么"验证方"不需要任何引擎代码。
摘要：本文围绕大模型推理系统的可信边界展开，提出"三问三防"框架：权重文件加密防拷走、模型签名防掉包、输出记录出证防抵赖。重点讲解三道防线如何正交、设备私钥签名的信任方向为何与供应链签名相反，以及验证方只需请求原文、输出文本与公钥即可离线验签的落点。
1. 知识点：三问三防，与"验证"和"证明"的分工
把推理系统会被审计的资产与威胁列成三问：
| 问 | 威胁 | 防线 | 机制 |
|---|---|---|---|
| 权重文件被拷走能读懂吗？ | 离线破解 | A 存储态加密 | SM4-CTR 密文落盘 + HMAC-SM3 |
| 模型被掉包/投毒认得出吗？ | 伪模型以假乱真 | B 供应链签名 | SM2 对明文摘要签名 + 设备公钥验签 |
| 输出记录可信吗、赖得掉吗？ | 归档被改/伪造/抵赖 | C 推理出证 | SM3 转录摘要 + SM2 设备签名，逐请求发凭证 |
一句话：加密保密、签名保真、出证保实。关键在"谁持有哪把钥匙"：
| 防线 | 签名/加密用谁的钥匙 | 谁验证 |
|---|---|---|
| A | 口令（对称，转换时定） | 设备自己（解锁才能加载） |
| B | 发布方私钥（离线） | 设备（持发布方公钥） |
| C | 设备私钥（本机生成，0600） | 任意验证方（持设备公钥） |
注意 C 的信任方向反了：B 是"设备信发布方"，C 是"外部信设备"。一台边缘设备对自己的输出签名背书，验证方（审计方、第三方）拿公钥离线验——验证方不需要引擎、不需要 tokenizer、不需要模型文件，只要请求原文 + 输出文本 + 凭证 + 公钥四个字节流。这正是出证与"日志自证"的本质区别：密钥在设备上、验证在外部独立完成。
三道防线正交：B 签明文摘要，与口令/加密无关（A 失效不连坐 B）；C 的model_fp锚定目录/config 层，若模型是签名 VQF（B 开启），则形成"来源签名 → 响应背书"完整链；A 是保密层不参与 C 语义。任何一层失守不自动导致其余层失效。
2. 对应代码：vllm_attest.h 的信任链注释与 API 面
vllm_attest.h24–35 行把信任链写死成三条：
/* 信任链（诚实边界）： * 1. 权重锚点：若模型目录含签名 VQF（VLLM_VQF_VERIFY=1），权重级信任根 * 由 VQF 的 SM2 供应链签名提供；本模块的 model_fp 锚定目录/配置层。 * 2. 设备背书：设备侧保存的 SM2 私钥对响应摘要签名；验证方持公钥 * （vllm_attest.pub）即可离线验证（SM2 ID = "VLLM-ATTEST-1"）。 * 3. 防伪范围：请求原文、输出文本、模型指纹、参数、计数、finish、ts * 任一字段被事后改写都会导致验签失败。 */API 面（37–85 行）只有 6 个函数：vatt_init（启动一次，VLLM_ATTEST=1 才启用）、vatt_model_ready（模型加载后固化指纹）、vatt_body_digest（请求体 SM3）、vatt_active（可否出证）、vatt_seal_json（对一次转录出证）、vatt_selftest（自检门）。设备密钥对：VLLM_ATTEST_DIR（默认 "."）下vllm_attest.priv（64 hex，0600）/vllm_attest.pub（128 hex），缺失自动生成——私钥带 0600 权限，只给本机进程读。
默认关闭：VLLM_ATTEST=1才开启，去掉环境变量即恢复原状（A-B-C-D 回退）。开启后的成本：请求结束各一次 SM3（请求体 + 转录）+ 一次 SM2 签名——毫秒级、相对 TTFT 可忽略。
3. 改动后果：从"引擎日志"到"外部可验证凭证"的跃迁
对比引擎自己记日志（谁能保证日志没被改？）与 C 防线：
| 能力 | 引擎内部日志 | attest 凭证（schema=3；旧 2 仍可验） |
|---|---|---|
| 谁写 | 引擎进程 | 引擎（设备私钥签名） |
| 谁验 | 只能信引擎 | 任何人（持公钥离线验） |
| 防引擎被黑后改日志？ | 不能 | 不能（私钥在设备上，被攻破即失效——诚实边界） |
| 防归档侧改记录？ | 不能 | 能（改一字 → 验签失败） |
推演改动后果：若有人把vatt_seal_json里的摘要字段从"字节精确"改成"截断/转义后的文本"，凭证将不再绑定真实输出——所以帧规范要较真：摘要里每一个字段用什么字节序列喂进去，验证方就必须逐字节复算同一序列。凭证的强度 = 帧规范的严格度。
4. 学员调试任务
- A 档（动手）：读方案文档 §0 的"发布方 / 设备 / 验证方"三方图，自己画一遍并标注：哪一步用发布方私钥、哪一步用设备私钥、哪一步用谁的公钥。
- B 档（纯读源码）：读
vllm_attest.h24–85，回答：① 为什么设备密钥要 0600 且只在VLLM_ATTEST_DIR？若把.priv打成 0644 会怎样？（提示：同机其他用户可读 → 可代签任何输出）② C 的model_fp锚定"目录/配置"层，与 B 的"签名 VQF 验签"是什么关系？若模型不是签名 VQF，C 还能出证吗？（能，但权重可信度回落到目录指纹层——诚实边界）③ "验证方不需要 tokenizer/聊天模板"这句为什么成立？（提示：摘要绑定的是字节，不是语义）
预期输出：三方图 + 三问三防对照表，能讲清"B 信发布方、C 信设备、验证在外部"的信任拓扑。
收尾
本篇源码点名：vllm_attest.h（信任链 24–35、API 37–85）、方案文档（§0 三防线与正交性）。
下篇预告：凭证到底"证"了什么？27-2 拆vatt_seal_json的帧规范：F(x)=len‖x的逐字段字节绑定、body_sha怎么把"收到什么就证明什么"钉死——以及"响应改一个字"为什么必然验签失败。