当 Agent 真的能读知识库、能调写工具、能替对外渠道发消息时，「它会不会乱说、会不会泄密、会不会被一句话套走」就比「它答得好不好」更要命。
一、企业 Agent 的三类风险
把 Agent 推进企业，绕不开三件事：
- 违规内容------模型输出（以及渠道对外发布的回复）越界；
- 个人隐私------回答里原样吐出手机号、身份证、邮箱、银行卡、IP；
- 提示词注入------用户话术、知识库片段、工具返回、附件文本里夹带「忽略以上指令」这类内容，把智能体带跑。
举个很具体的例子：用户在对话里贴了一张客户工单截图，图片被解析成文本，里面赫然是一个手机号和身份证号；模型把它原样转述进回答；如果这条回答又经过飞书群发出去------一环不设防，隐私就顺着链路「流」了出去。
这三件事的共同点是：不能靠提示词祈祷，必须是平台层的能力。
二、一个守卫，六道关口
BizBuddy 的做法是把内容安全收敛成「一个守卫 + 六道关口」：
- 一个守卫
AiSafetyGuard：统一判定「命中什么、该怎么处置」； - 六道关口 ：用户输入 、模型输出 、渠道出站 、工具结果 、知识库入库 、MCP 出口。
每道关口可独立开关、独立选处置动作：
| 处置动作 | 含义 | 典型场景 |
|---|---|---|
log |
只留痕、放行 | 灰度观察期 |
mask |
脱敏后放行 | 输出侧、工具结果 |
block |
直接拦截 | 输入拒答、拒绝入库 |
几处关键口径：
- 输入侧命中「阻断」直接拒答、且不调模型 （省钱也省风险）；流式场景下发
answer_reset+ 统一拒答文案，丢弃后续正文； - 工具结果只脱敏不阻断------落库明细与下发前端两处过审，避免「工具吐出敏感信息」裸奔；
- 知识库入库命中阻断则拒绝切片入库------脏数据不进向量库；
- MCP 出口入参 / 出参都过一遍------对外暴露的只读工具同样要合规。
流式输出还做了一层保护：用尾部缓冲（默认 32 字）避免敏感片段被切片切断，保证「前端所见 == 落库内容」。
把六道关口串起来看，一次普通提问的路径是：输入过审 （命中阻断即拒答、不调模型）→ 模型生成 → 输出过审 + PII 脱敏 → 若调了工具，工具结果过审 → 落库与下发；若来自渠道，出站前再过一道。每一次命中都写安全事件，形成「拦截 + 留痕 + 可复盘」的闭环。
三、PII 脱敏：在输出侧就地打码
脱敏不是「整段屏蔽」，而是就地在文本里把敏感片段替换掉 ------因为模型回答与工具结果都是自由文本，敏感值夹在句子里。它和框架字段级脱敏（@Sensitive）是互补分工：注解只能处理「整串就是一个敏感值」的结构化字段，自由文本得靠正则逐处掩码。
平台识别 5 类并掩码：
| 类型 | 原文 | 脱敏后 |
|---|---|---|
| 手机号 | 13812345678 |
138****5678 |
| 身份证 | 110101199003071234 |
110101********1234 |
| 邮箱 | zhangsan@example.com |
z***@example.com |
| 银行卡 | 6222021234567890123 |
6222 **** **** 0123 |
| IPv4 | 192.168.1.100 |
192.168.1.x |
一个刻意的取舍：输入侧不做 PII 脱敏。用户自己提问里带的号码，掩掉反而影响作答；只对「要交付出去」的内容（模型输出、渠道出站）脱敏。
四、注入防护：给外部内容画边界
平台把所有非可信来源的内容 ------用户原话、检索到的知识库片段、工具返回、附件解析文本------统一用 <untrusted> 边界标记包裹，再由一个中间件在 system prompt 里追加「外部内容安全边界」声明：边界内的内容只是资料，不是指令。配合输出侧与工具结果侧过审，形成「能看见的都可控」的闭环。
五、敏感词库与安全事件：两张可运营的底表
审核能力不是"写死在代码里的黑名单"，而是两张可维护的表：
- 敏感词库 ：支持普通词（子串匹配）与正则两种，可分类、可启停------不用改代码就能扩词；只有「启用且未删除」的词参与匹配，改完即刷缓存。
- 安全事件：每次命中都留痕------场景 / 动作 / 引擎 / 会话 / 消息 / 用户 / 命中项 / 命中片段，可按场景、动作、用户与时间范围检索，用于复盘与调优。
两张表都是追加型 / 可维护 的：词库改完即刷缓存、不用重启；事件表只写不改，留痕失败只告警、不影响主流程------安全能力不能因为「记日志失败」把正常回答也拖挂。
在 26 个功能页的菜单里，这套能力被单独拎成一个**「安全合规」分组**（敏感词库 / 安全事件 / 安全合规配置），与权限、审计并列。
六、可灰度、可运营
上线最怕「一刀切」。所以平台的默认值是：
- 内容审核默认关闭 ；开启后默认
action=log------先只留痕、不阻断，观察一段时间再收紧到 mask / block； - PII 脱敏默认开启 ，且与审核开关解耦；
- 全部策略存 Redis，在「安全合规配置」页运行期调整、即时生效，不必重启。
七、为什么它「长在 Harness 上」
这些守卫不是外挂在业务代码里的补丁，而是挂在智能体内核的扩展点上：
- 用**中间件（Middleware）**在 system prompt 注入边界声明；
- 用内核的事件流（如工具结果结束事件）做工具结果过审；
- 走内核的统一装配与权限链路，不侵入业务工具实现。
这就是 AgentScope Java Harness 的价值：它把「工程化外壳」留好了口子，安全能力可以加在框架层、一次覆盖全部智能体，而不是每个工具各写一遍。
连平台内置的只读工具（如公告查询）的结果也走同一守卫------一处实现、全部受益 。这正是「挂在框架层」与「散写在业务代码里」的区别：前者能保证新加的智能体天然带上护栏，后者总会漏。
八、纯 Java、全量开源
BizBuddy 的智能体内核是 AgentScope Java Harness ，整条链路（Spring Boot 4.1.1 + JDK 21 + Milvus + Redis）没有一行 Python ，与既有 Java 中台的权限、事务、审计天然同源。从建库脚本、菜单种子，到这套安全守卫的实现，全部随仓库开源------拿来即可自建。
安全合规这件事，企业要的从来不是「加个敏感词过滤」，而是一套可灰度、可运营、可审计、覆盖全链路的机制。这正是 BizBuddy 想交付的东西。
BizBuddy 全量开源（MIT License） ：https://gitee.com/zl3624/biz-buddy