1. 金融内网 AI 助理落地的核心矛盾与破局思路
金融行业对 AI 助理的态度一直很微妙。业务部门想要效率，一行代码不想写就想让 AI 帮忙查数据、写报告、跑分析；安全部门看到的是另一幅画面——一个能读文件、能执行命令、能联网的智能体，放在内网里简直就是一颗定时炸弹。我在几家金融机构做内网智能化改造时，最常听到的一句话就是：“这东西能不能跑，先不说；它跑起来之后干了什么，我得能查得到。”
这个矛盾的本质，是能力边界和安全边界的冲突。AI 助理要干活，就得给它工具权限；给了权限，它就可能越界。传统的做法是“一刀切”——要么不给用，要么给一个阉割到只能聊天的版本。但业务不买账，安全也不放心，最后项目就卡在那里。
PolarDB Agent Express 这套方案之所以在金融圈被反复提起，核心就在于它把“沙箱隔离”和“审计”这两件事做成了默认能力，而不是事后补丁。Agent Express 本身是一个面向数据库场景的智能体运行框架，它允许 AI 助理直接对接 PolarDB 做查询、分析、甚至写操作，但所有的执行都跑在一个受控的沙箱环境里，每一步动作都有审计日志留痕。对于金融企业来说，这意味着你可以放心地把 AI 助理放进内网，因为它跑不出那个圈，跑出去了也有记录。
这篇文章适合三类人看：一是正在做内网 AI 平台选型的技术负责人，二是被安全合规卡住的项目经理，三是想搞清楚“沙箱隔离到底怎么落地”的一线工程师。我会从整体设计思路讲到具体配置，再到踩过的坑，尽量把每个决策背后的“为什么”说清楚。你不需要是 PolarDB 专家，但最好对 Linux 权限模型和容器隔离有基本概念，这样读起来会更顺。
提示：本文讨论的部署方案基于常见金融内网环境（物理隔离或严格防火墙策略），所有操作均在合规授权范围内进行。涉及具体参数时，我会给出计算逻辑，你可以根据自己环境的实际情况调整。
2. 为什么是沙箱隔离加审计，而不是别的方案
2.1 金融内网 AI 助理的三种典型风险场景
在讲方案之前，先看清楚敌人是谁。金融内网里跑 AI 助理，风险主要来自三个方向。
第一是数据泄露。AI 助理为了回答一个问题，可能会去读它本不该读的表。比如一个负责客服的助理，理论上只该看工单表，但它如果有了数据库的宽泛权限，就可能把客户资产表也扫一遍。更麻烦的是，如果它把查询结果缓存到了本地或者写进了日志文件，这些数据就脱离了数据库的访问控制体系。
第二是越权操作。这是最吓人的。AI 助理如果拿到了写权限，一个错误的 SQL 就可能改掉关键配置或者删掉数据。我见过一个测试环境里，助理被要求“清理过期数据”，结果它把一张还在用的表给 truncate 了。虽然是在测试环境，但足以说明问题——你不能指望 AI 每次都理解你的业务语义。
第三是行为不可追溯。出了事之后，安全部门要查“谁在什么时候干了什么”。如果 AI 助理的操作没有独立审计，日志里只有数据库连接池的记录，你根本分不清是人干的还是机器干的。金融行业的监管要求，往往需要精确到“某个智能体实例在某个时间点执行了某条语句”。
这三种风险，靠“信任 AI”是解决不了的。你必须假设它会犯错，然后设计一套机制，让它的错误可控、可查、可回滚。
2.2 沙箱隔离的三种实现路径对比
市面上做隔离的思路大致分三档，我列个表对比一下，你就知道为什么 Agent Express 选的是第三条路。
| 隔离层级 | 实现方式 | 隔离强度 | 性能损耗 | 适用场景 |
|---|---|---|---|---|
| 进程级 | 独立系统用户 + 文件权限 | 低 | 几乎无 | 内部工具，信任度高 |
| 容器级 | Docker/Namespace + Cgroup | 中 | 5%-15% | 多租户，中等安全要求 |
| 沙箱级 | 微虚拟机/gVisor + 系统调用过滤 | 高 | 15%-30% | 金融、政务，强合规 |
进程级隔离说白了就是“换个用户跑”，AI 助理以ai_agent用户身份运行，数据库连接用单独的账号，文件系统权限收紧。这能防住一些低级错误，但防不住提权攻击，也防不住 AI 通过合法接口去访问不该访问的资源。
容器级隔离是目前的主流，Docker 把文件系统、网络、进程空间都隔开了。但容器共享内核，如果 AI 助理能触发内核漏洞，或者通过/proc之类的接口窥探宿主机，隔离就破了。而且容器的网络策略如果配得粗，它照样能扫内网。
沙箱级隔离是金融场景的答案。Agent Express 底层用的是基于微虚拟机或者 gVisor 的沙箱运行时，每个 AI 助理实例跑在一个独立的轻量级虚拟机里，系统调用被拦截和过滤。它看到的文件系统是只读的镜像层，网络出口被限制在特定的数据库代理端口，想扫内网？系统调用直接返回错误。性能确实有损耗，但金融内网对延迟的容忍度比互联网高得多，用 15% 的性能换 90% 的安全，这笔账划得来。
2.3 审计为什么必须独立于业务日志
很多团队一开始会把 AI 助理的操作日志和业务日志混在一起，觉得“反正都在 ELK 里，查的时候过滤一下就行”。这个想法很危险。
业务日志是给开发看的，格式自由，可能包含敏感数据，保留周期短。审计日志是给合规和安全看的，格式必须固定，内容必须脱敏，保留周期往往要求半年以上，而且不能被业务系统修改。两者混在一起，第一个问题是权限混乱——开发能改业务日志，就能改审计日志；第二个问题是数据污染——业务日志里的调试信息可能把审计字段冲掉。
Agent Express 的做法是审计日志走独立通道，直接写到不可篡改的存储里（比如 WORM 存储或者独立的审计数据库）。每条记录包含：时间戳、智能体实例 ID、会话 ID、执行的 SQL 语句（脱敏后）、影响行数、执行结果状态、沙箱资源消耗。这个记录是异步写的，不阻塞主流程，但保证最终一致。
注意：审计日志的脱敏规则要提前定义好。比如客户身份证号、银行卡号、金额字段，在写入审计日志前就要做掩码处理。不要等到事后分析时才发现日志里全是敏感信息，那时候已经晚了。
3. Agent Express 沙箱环境的核心配置与实操
3.1 沙箱运行时的选型与资源规划
Agent Express 支持多种沙箱运行时，金融场景我推荐用 gVisor 或者 Kata Containers。gVisor 的优势是启动快、资源占用小，它实现了一个用户态的内核，AI 助理的系统调用先经过 gVisor 的拦截，再决定是否放行到宿主机。Kata Containers 则是轻量级虚拟机，隔离更彻底，但启动慢一些，内存开销也大一点。
选哪个取决于你的并发量。如果同时跑的 AI 助理实例在 50 个以内，Kata Containers 没问题，每个实例给 512MB 内存、1 个 vCPU 就够了。如果并发上百，gVisor 更合适，单实例内存可以压到 256MB。
资源规划有个简单的计算公式：
总内存 = 实例数 × 单实例内存 × 1.5（预留缓冲） 总 CPU = 实例数 × 单实例 vCPU × 1.2（超卖系数）比如 100 个并发实例，单实例 256MB 内存、0.5 个 vCPU，那么总内存需要 100 × 256MB × 1.5 = 38.4GB，总 CPU 需要 100 × 0.5 × 1.2 = 60 核。实际部署时，建议用 Kubernetes 来调度，把沙箱实例当成 Pod 来管理，这样扩缩容和故障迁移都方便。
3.2 网络隔离策略的具体配置
沙箱的网络隔离是重中之重。Agent Express 的默认策略是“默认拒绝，按需放行”。具体来说，沙箱实例启动时，网络命名空间是空的，没有任何路由。你需要显式地给它配置出口规则。
对于金融内网，我建议只放行三个方向：
- PolarDB 代理地址：通常是内网的 VIP 或者域名，端口固定。不要直接连数据库实例，走代理层可以做额外的鉴权和限流。
- 审计日志收集端：如果审计日志是推模式，需要放行到日志网关的端口。
- 内部制品库：如果 AI 助理需要拉取模型文件或者配置文件，放行到内部 OSS 或制品库。
其他所有出口一律拒绝，包括 DNS。DNS 请求也走内部解析器，不要用公共 DNS。配置示例（以 Kubernetes NetworkPolicy 为例）：
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: agent-sandbox-policy spec: podSelector: matchLabels: app: agent-express-sandbox policyTypes: - Egress egress: - to: - ipBlock: cidr: 10.0.1.100/32 ports: - protocol: TCP port: 3306 - to: - ipBlock: cidr: 10.0.2.50/32 ports: - protocol: TCP port: 9200这个策略的意思是：只允许沙箱访问10.0.1.100的 3306 端口（PolarDB 代理）和10.0.2.50的 9200 端口（审计日志收集）。其他所有出口流量默认丢弃。
提示：配置完 NetworkPolicy 后，一定要在沙箱里跑一次
curl或者nc测试，确认目标端口通、其他端口不通。我见过有人配了策略但没生效，原因是 CNI 插件不支持 NetworkPolicy，白忙一场。
3.3 文件系统与权限的最小化设计
沙箱里的文件系统应该是只读的，除了少数几个临时目录。Agent Express 的镜像里，/是只读层，/tmp和/var/run/agent是可写层，但这两个目录在实例销毁时会被清空。
AI 助理如果需要写中间结果，只能写到/tmp，而且有大小限制（默认 100MB）。超过限制会触发告警，防止它把沙箱撑爆。这个限制可以在配置里调整，但金融场景我建议不要调大，100MB 足够处理绝大多数查询结果了。
权限方面，沙箱内的进程以非 root 用户运行，UID 固定为 10001。这个用户对/没有写权限，对/tmp有读写权限，对 PolarDB 的连接凭证是通过环境变量注入的，不落盘。环境变量在实例启动时从 Secret 挂载，实例销毁后 Secret 自动回收。
这里有个细节：AI 助理可能会尝试读/proc或者/sys来获取系统信息。gVisor 会拦截这些访问，返回伪造的数据或者直接拒绝。Kata Containers 因为是真的虚拟机，/proc里只有虚拟机内部的信息，看不到宿主机。两种方案都能满足要求。
3.4 审计日志的字段设计与采集链路
审计日志的字段设计要兼顾合规和排查效率。我通常建议包含以下字段：
| 字段名 | 类型 | 说明 |
|---|---|---|
| event_id | string | 全局唯一事件 ID，UUID |
| timestamp | int64 | 毫秒级时间戳 |
| agent_id | string | 智能体实例标识 |
| session_id | string | 会话标识，关联多轮对话 |
| user_id | string | 触发该会话的内部用户 ID |
| action_type | string | 操作类型：query/execute/connect |
| sql_text | string | 脱敏后的 SQL 语句 |
| affected_rows | int | 影响行数 |
| status | string | success/failed/denied |
| sandbox_id | string | 沙箱实例 ID |
| resource_usage | json | CPU/内存/网络消耗快照 |
采集链路是这样的：沙箱内的 Agent Express 运行时在每次数据库操作前后打点，生成审计事件，通过本地 Unix Socket 发给沙箱外的审计代理（audit agent），审计代理做脱敏和格式化，然后批量推送到审计存储。这个设计的好处是，即使沙箱被攻破，攻击者也只能影响沙箱内的运行时，审计代理在沙箱外，日志已经发出去了。
脱敏规则在审计代理里配置，支持正则和字段名匹配。比如匹配到id_card字段，就把值替换成***。SQL 语句的脱敏稍微复杂一点，需要解析 SQL 语法树，把字面量替换掉。Agent Express 内置了一个轻量级的 SQL 解析器，能处理常见的 SELECT/INSERT/UPDATE/DELETE。
4. 从零搭建一套可运行的沙箱审计环境
4.1 基础环境准备与依赖安装
假设你有一台内网的 Linux 服务器，配置是 16 核 64GB，准备用来跑 Agent Express 的沙箱节点。操作系统建议用 Ubuntu 22.04 或者 Rocky Linux 9，内核版本 5.15 以上。
第一步是安装容器运行时和沙箱运行时。如果选 gVisor：
# 安装 gVisor 的 runsc wget https://storage.googleapis.com/gvisor/releases/release/latest/x86_64/runsc chmod +x runsc sudo mv runsc /usr/local/bin/ # 配置 Docker 使用 runsc sudo tee /etc/docker/daemon.json <<EOF { "runtimes": { "runsc": { "path": "/usr/local/bin/runsc" } } } EOF sudo systemctl restart docker如果选 Kata Containers，安装方式略有不同，需要先装 QEMU 和 Kata 的运行时组件。这里不展开，官方文档写得很清楚。
第二步是准备 PolarDB 的连接。你需要一个专用的数据库账号，只授予必要的权限。比如 AI 助理只需要读sales库的orders表和customers表，那就只给这两张表的 SELECT 权限，不要给*.*。
CREATE USER 'ai_agent'@'%' IDENTIFIED BY '强密码'; GRANT SELECT ON sales.orders TO 'ai_agent'@'%'; GRANT SELECT ON sales.customers TO 'ai_agent'@'%'; FLUSH PRIVILEGES;第三步是部署审计存储。可以用 Elasticsearch 或者专用的审计数据库。金融场景我建议用独立的 PolarDB 实例来存审计日志，和业务库物理隔离。表结构按上一节的字段设计来建。
4.2 Agent Express 沙箱实例的启动配置
Agent Express 的沙箱实例通过一个配置文件来定义。核心配置项包括：
sandbox: runtime: runsc memory_limit: 256Mi cpu_limit: 0.5 read_only_root: true writable_dirs: - /tmp - /var/run/agent tmpfs_size: 100Mi database: host: 10.0.1.100 port: 3306 user: ai_agent password_env: POLARDB_PASSWORD max_connections: 5 query_timeout: 30s audit: enabled: true endpoint: unix:///var/run/audit/agent.sock batch_size: 100 flush_interval: 5s mask_fields: - id_card - bank_card - phone - amount这个配置的意思是：沙箱用 runsc 运行时，内存限制 256MB，CPU 限制 0.5 核，根文件系统只读，只有/tmp和/var/run/agent可写，/tmp是 tmpfs，最大 100MB。数据库连接走10.0.1.100:3306，用ai_agent账号，密码从环境变量读，最多 5 个连接，查询超时 30 秒。审计开启，通过 Unix Socket 发给审计代理，每 100 条或者 5 秒刷一次，脱敏字段包括身份证、银行卡、电话、金额。
启动实例的命令：
agent-express run --config /etc/agent/config.yaml --session-id sess_20250101_001启动后，你可以用agent-express status查看实例状态，用agent-express logs看运行日志。审计日志不在本地，在审计存储里查。
4.3 审计代理的部署与脱敏规则调试
审计代理是一个独立的进程，跑在沙箱宿主机上，监听 Unix Socket。它的职责是接收沙箱发来的审计事件，做脱敏，然后批量写入审计存储。
部署审计代理：
audit-agent --socket /var/run/audit/agent.sock --output elasticsearch://10.0.2.50:9200/audit-2025 --mask-config /etc/audit/mask.yaml脱敏配置mask.yaml示例：
rules: - field: id_card pattern: '\d{17}[\dXx]' replacement: '***' - field: bank_card pattern: '\d{16,19}' replacement: '****' - field: phone pattern: '1[3-9]\d{9}' replacement: '********' - sql_literal: enabled: true replacement: '?'调试脱敏规则时，可以先用audit-agent --dry-run模式，把脱敏后的事件打印到控制台，确认没问题再正式写入。我踩过的坑是：正则写得太宽，把正常数字也脱敏了，导致审计日志里全是***，排查问题时完全没用。所以规则要精确，宁可漏脱敏几个字段，也不要过度脱敏。
4.4 验证沙箱隔离效果的实操步骤
部署完之后，必须做隔离验证。我通常做四组测试：
第一组：网络隔离测试。在沙箱里执行curl http://10.0.1.1（假设这是内网网关），应该超时或者拒绝。执行curl http://10.0.1.100:3306，应该能建立 TCP 连接（但 MySQL 握手可能失败，因为 curl 不是 MySQL 客户端）。执行nslookup baidu.com，应该失败，因为 DNS 被禁了。
第二组：文件系统测试。在沙箱里执行touch /test.txt，应该报“Read-only file system”。执行touch /tmp/test.txt，应该成功。执行dd if=/dev/zero of=/tmp/bigfile bs=1M count=200，应该在 100MB 时失败，因为 tmpfs 满了。
第三组：权限测试。在沙箱里执行id，应该显示 UID 10001，不是 root。执行sudo su，应该失败，因为 sudo 没装或者没权限。
第四组：审计测试。在沙箱里执行一条 SQL 查询，然后去审计存储里查，应该能看到对应的审计事件，且敏感字段已脱敏。
这四组测试过了，基本可以确认沙箱隔离是有效的。
5. 常见问题与排查技巧实录
5.1 沙箱启动失败与资源不足的排查
沙箱启动失败最常见的原因是资源不足。gVisor 虽然轻量，但每个实例还是要占内存的。如果宿主机内存不够，实例会卡在Creating状态。排查步骤：
kubectl describe pod <sandbox-pod>看 Events，如果有OOMKilled或者Insufficient memory，就是内存不够。kubectl top node看节点资源使用率，如果内存超过 80%，就要考虑扩容或者减少并发实例数。- 检查
memory_limit配置是否合理。256MB 是下限，如果 AI 助理要处理大结果集，可能需要 512MB。
另一个常见原因是运行时配置错误。比如 Docker 的daemon.json里 runsc 路径写错了，或者 runsc 版本和内核不兼容。看docker info里的 Runtimes 列表，确认 runsc 已注册。然后docker run --runtime=runsc hello-world测试一下，能跑通说明运行时没问题。
5.2 审计日志丢失或延迟的处理
审计日志丢失通常有三个原因。
一是 Socket 连接断了。沙箱内的 Agent Express 和审计代理之间是 Unix Socket，如果审计代理重启，Socket 文件可能被删了，沙箱内的进程就连不上了。解决办法是审计代理启动时先创建 Socket 文件，并且用systemd的Restart=always保证它挂了能自动拉起。沙箱内的 Agent Express 要有重连逻辑，连不上时把审计事件暂存到本地磁盘（/tmp下），等连上了再补发。
二是批量刷新的间隔太长。默认 5 秒刷一次，如果审计代理在刷新前挂了，最多丢 5 秒的数据。金融场景可以把这个间隔调到 1 秒，代价是写入压力大一点。或者改成“每条都刷”，但那样性能损耗明显。折中方案是：普通查询 5 秒刷，涉及写操作或者敏感表的查询 1 秒刷。
三是脱敏规则报错导致事件被丢弃。如果正则写错了，脱敏时抛异常，审计代理可能会跳过这条事件。解决办法是在脱敏逻辑里加 try-catch，出错时记录原始事件到死信队列，不要直接丢。死信队列定期人工处理。
5.3 AI 助理行为异常的快速定位方法
AI 助理行为异常，比如突然查了不该查的表，或者执行了预期外的 SQL，定位思路是“先看审计，再看沙箱”。
第一步，在审计存储里按agent_id和session_id过滤，看最近的操作序列。重点看action_type和sql_text，找出异常操作的时间点。
第二步，看沙箱的资源使用快照。如果异常操作时 CPU 或内存飙升，可能是 AI 助理陷入了循环或者处理了超大结果集。
第三步，如果审计日志显示 SQL 本身没问题，但结果不对，那可能是 AI 助理的推理逻辑有问题。这时候要看它的对话历史，Agent Express 会记录每轮对话的输入输出（也需要脱敏）。分析它是怎么从用户问题推导到那条 SQL 的。
我遇到过一个案例：用户问“上个月销售额是多少”，AI 助理生成的 SQL 里带了WHERE month = '2025-01'，但数据库里存的是202501格式，导致查不到数据。AI 助理发现查不到，就自作主张去查了information_schema想找表结构，结果触发了审计告警。这个问题的根因是 AI 助理对数据格式的理解有偏差，解决办法是在系统提示词里明确告诉它字段格式，或者在数据库层面加一个视图做格式转换。
5.4 性能调优与并发控制的经验参数
Agent Express 沙箱的性能瓶颈通常在数据库连接和审计写入这两块。
数据库连接方面，每个沙箱实例默认最多 5 个连接。如果并发实例多，PolarDB 的连接数可能不够。假设 100 个实例，每个 5 个连接，就是 500 个连接。PolarDB 默认最大连接数可能只有 1000，还要留给其他业务。所以要么减少单实例连接数（比如改成 2），要么用连接池代理（比如 PolarDB 自带的 Proxy）来复用连接。
审计写入方面，如果每条事件都同步写 Elasticsearch，延迟会很高。批量写是必须的，但批量大小要调。我实测下来，batch_size=100、flush_interval=5s是个比较平衡的值。如果审计存储是 PolarDB，可以用INSERT ... VALUES (...), (...)批量插入，比单条插入快 10 倍以上。
并发控制方面，建议给每个 AI 助理实例设置max_concurrent_queries=2，防止它同时发多条 SQL 把数据库打爆。这个参数在 Agent Express 的配置里可以调。
| 问题现象 | 可能原因 | 排查命令 | 解决措施 |
|---|---|---|---|
| 沙箱启动卡住 | 内存不足 | kubectl describe pod | 扩容或减少并发 |
| 审计日志缺失 | Socket 断开 | ls -l /var/run/audit/ | 重启审计代理，加自动重连 |
| SQL 执行超时 | 查询太复杂 | 审计日志看sql_text | 加索引或限制查询范围 |
| 脱敏过度 | 正则太宽 | audit-agent --dry-run | 收紧正则，精确匹配 |
| 连接数不够 | 并发太高 | SHOW PROCESSLIST | 用连接池或减少实例数 |
提示：金融内网的环境往往有各种限制，比如不能装 Docker、不能用 Kubernetes。这种情况下，可以用 Podman 或者直接跑 gVisor 的 runsc 命令行。核心思路是一样的：隔离运行时、限制网络、独立审计。工具可以换，原则不能丢。
6. 几个容易被忽略的细节与个人体会
6.1 时间同步与审计时序问题
审计日志的时间戳必须准确，否则排查问题时会对不上。沙箱宿主机和 PolarDB 服务器的时间要同步，建议都用内网的 NTP 服务。如果时间不同步，审计日志里显示 SQL 在 10:00:00 执行，但数据库慢查询日志里显示 10:00:05，你就很难判断是网络延迟还是执行慢。
Agent Express 的审计事件时间戳用的是沙箱内的系统时间，而沙箱时间继承自宿主机。所以只要宿主机时间准，审计时间就准。但要注意，如果沙箱实例被迁移到另一台宿主机，时间可能跳变。建议在审计事件里同时记录sandbox_host字段，方便追溯。
6.2 凭证轮换与沙箱生命周期的配合
数据库密码不能写死在配置里，要用环境变量或者 Secret 注入。但 Secret 也有生命周期，需要定期轮换。轮换时，正在运行的沙箱实例怎么办？
我的做法是：沙箱实例设置最大存活时间（比如 24 小时），到期自动销毁重建。重建时拉取最新的 Secret。这样凭证轮换后，最多 24 小时所有实例都会用上新密码。对于长会话，可以在会话中途刷新凭证，但实现复杂，金融场景一般不需要。
另外，沙箱销毁时要确保临时文件被清理。gVisor 的 tmpfs 在实例销毁时自动清空，Kata Containers 的虚拟磁盘也会被删除。但如果是用宿主机目录挂载的，就要手动清理。我建议不要挂载宿主机目录，全部用 tmpfs。
6.3 从 OpenClaw 类工具迁移到 Agent Express 的注意事项
有些团队之前用 OpenClaw 之类的工具做内网自动化，现在想迁到 Agent Express。迁移时要注意几点：
第一，OpenClaw 的权限模型可能比较宽松，迁移后要重新梳理权限，按最小化原则配置。
第二，OpenClaw 的脚本可能直接调系统命令，Agent Express 的沙箱里没有那些命令，需要改成通过数据库接口或者内部 API 来实现。
第三，审计格式不同，迁移后要重新对接审计存储，历史审计日志可以归档保留，但新日志走新格式。
第四，OpenClaw 的配置文件格式和 Agent Express 不一样，需要重写。建议先在测试环境跑通一个简单场景，再逐步迁移复杂场景。
6.4 我个人在实际操作中的几点体会
做了这么多金融内网的 AI 助理项目，我最大的体会是：安全不是加出来的，是设计出来的。如果你先做一个功能完整的 AI 助理，再想办法给它加沙箱和审计，往往会发现很多地方改不动，最后只能妥协。正确的做法是一开始就把沙箱和审计作为基础能力，功能在上面长。
第二个体会是：审计日志的价值在于“查得到”，不在于“存得多”。我见过一些团队把审计日志存了好几年，但从来不查，真出事了发现日志格式混乱、字段缺失，根本没法用。审计日志要定期做“可查性测试”，模拟一个安全事件，看能不能在 10 分钟内定位到相关操作。做不到就优化。
第三个体会是：沙箱的性能损耗是值得的。15%-30% 的性能损失，换来的是安全部门敢签字、业务部门敢用。没有这个损耗，项目可能根本推不动。而且随着硬件升级和运行时优化，这个损耗在逐年降低。
最后分享一个小技巧：在沙箱里放一个“蜜罐”文件，比如/etc/secret_config，内容是一段标记字符串。如果 AI 助理尝试读这个文件，审计代理会收到告警。这个文件正常业务永远不会碰，一旦被读，说明 AI 助理的行为异常，可能是被恶意提示词注入了。这个技巧成本极低，但能提前发现很多问题。
这个方案后续还可以扩展的方向包括：多租户隔离（不同部门的 AI 助理跑在不同的沙箱集群）、审计日志的实时分析（用流处理引擎做异常检测）、以及和内部 SIEM 系统的对接。不过那是另一个话题了，先把基础跑通再说。
