Ruflo
Ruflo 检索与 Hook 安全：启用、标记和真正执行的限制
检查检索防护开关、严格模式与字符串长度，区分尽力而为的 Hook 记录和可强制执行的权限边界。
你将学会
- 检查调用者，而不只看防护类
- 标记与丢弃是不同策略
- 不要把尽力而为 Hook 当成安全关卡
开始前需要
- 基础 Node.js、Git 与命令行知识
- 自有仓库及明确任务和权限边界
解释本章实现，复现有限检查，不把辅助函数当完整运行环境。
先看结论
- 所查后端仍要求精确启用开关。
- 标记保留不等于严格拦截，字符串长度不等于 UTF-8 字节。
- 尽力而为 Hook 成功不证明持久化或授权。
检查调用者，而不只看防护类
AgentDbRetrievalGuard 能标记不安全或过大结果，也可以移除。所查 AgentDBBackend 在 HNSW 或暴力检索后调用 applyRetrievalGuard；如果防护对象不存在、启用值不是精确字符串 true，或结果为空，就直接返回原结果。显式提供防护配置也不会绕过调用处的开关。
附近注释暗示显式配置能在无开关时扫描，但可执行条件仍要求该开关。隔离探针用模拟接收者确认了两条分支，没有构建数据库、验证所有查询路径，也没有执行真实提示注入检测器。源码注释需要对照实际行为核查。
标记与丢弃是不同策略
默认过滤保留可疑条目并添加注释；严格 blockOnSuspicion 会移除。过大分支不执行扫描。设置名虽然是 maxPayloadBytes，字符串判断却使用 content.length，单位是 UTF-16 码元而非 UTF-8 字节。五个汉字长度为五，占十五个 UTF-8 字节，在上限八时不会命中过大分支。
探针中的内容扫描器是注入的模拟实现，因此验证的是包装策略与大小计算，不是检测效果。独立的 safeJsonParse 在解析时递归移除 __proto__、constructor 和 prototype 键。这项针对性处理不会认证记忆作者、授权转移，或使检索文字成为可信指令。
不要把尽力而为 Hook 当成安全关卡
核心 Hook 中间脚本把许多操作视为尽力而为的记录：抑制子进程输出，使用有超时的同步调用，CLI 失败时仍成功退出而不阻塞当前任务。预工具分支还根据检测到的宿主调整输出。因此零退出码不能证明学习已持久化，也不能证明工具动作通过了安全审查。
真正允许哪些工具、数据访问和外部写入，应在宿主独立执行限制。检查实际后端与检索路径、是否需要严格策略，以及测试是否覆盖多语言载荷和失败 hooks。本篇是有限实现审查，不是渗透测试，也不认证任何已部署 Ruflo 环境。
实施步骤
- 1
确定活跃后端和真实检索调用链。
- 2
分别测试关闭、启用与严格策略。
- 3
加入多字节文本和失败 Hook 样例。
- 4
在建议性文字之外落实宿主权限。
可复制示例
{"guardEnabledValue":"true","strictModeIsSeparate":true,"sizeCheckUnit":"UTF-16 code units","realSecurityScannerExecuted":false,"hookExitZeroMeansPolicyApproved":false,"deployedSecurityVerified":false}常见问题
创建有配置的防护对象就强制扫描所有检索吗？
所查调用处不会，它还要求精确启用开关；其他路径也需要分别检查。
Hook 返回零表示学习成功了吗？
不表示。核心中间脚本刻意采用尽力而为策略，可能隐藏子命令失败。
资料来源
- plugins/ruflo-core/hooks/hooks.json来源核查 2026-09-08
- plugins/ruflo-core/scripts/ruflo-hook.cjs来源核查 2026-09-08
- v3/@claude-flow/memory/src/agentdb-retrieval-guard.ts来源核查 2026-09-08
- v3/@claude-flow/memory/src/agentdb-backend.ts来源核查 2026-09-08
- v3/@claude-flow/memory/src/json-security.ts来源核查 2026-09-08