做一个金融行业的AI Agent项目业务方催得再急也不如安全合规那一关来得硬核。我们团队从去年底开始推进AI Agent在内部场景的落地先后试过不少方案最后稳定跑在生产环境里的是一套以PolarDB为数据底座、以VM沙箱隔离为核心边界、贯穿“数据不出域”原则的部署架构。这套组合被我们内部称为Agent Express模式写这篇文章就是想把整个设计思路、选型理由、落地过程以及踩过的坑都摊开来讲给正在被同样问题卡住的朋友一个参考。先介绍下背景。我们面对的场景是金融企业内部的智能数据分析助手——让Agent能够根据业务人员的自然语言提问自动生成SQL去查询PolarDB中的业务数据再做汇总、生成报表、输出结论。听起来不复杂但金融行业有两条红线第一业务数据绝对不能出域尤其是客户维度数据第二Agent的行为必须可审计、可追溯、可干预。这两条红线叠加在一起直接把很多“先跑起来再补安全”的敏捷玩法否掉了。如果你所在的团队也正在评估AI Agent在合规敏感场景下的部署方式这篇文章里讲的隔离设计思路、数据链路管控方法、权限与审计落地方案应该能帮你省掉不少试错成本。1. 金融场景下AI Agent的真实挑战1.1 为什么Agent在金融行业推进这么难先说一个最直接的感受传统软件的需求是确定的逻辑是写死的上线之前就能把行为边界穷举清楚。但AI Agent不一样它是模型驱动、目标导向的你给它一个“帮我分析一下上个月各分公司的业绩波动原因”它自己会规划步骤、选择工具、编写查询、甚至自我纠错重试。每一步动作都是动态推理出来的不是预先写好的代码路径。这个特性放在互联网行业无所谓顶多就是效果不稳定。但在金融行业直接撞上审计要求——合规部门要的是“确定性”这个系统能做什么、不能做什么、什么情况下会做什么必须能提前说清楚。一个推理出来的动作序列怎么提前穷举这成了推进AI Agent落地的第一道坎。第二道坎更实际Agent要干活就得有数据访问权限但数据不出域又是硬性要求。如果把Agent放在一个能自由出入内外网的服务器上它一边访问PolarDB里的业务数据一边还能调用公网API、访问外部知识库、上传文件到外部服务那风险就完全失控了。我们内部安全团队当时的一句话我印象很深“我们不怕模型笨就怕模型太聪明聪明到会自己找路。”这句话基本概括了AI Agent在金融体系里最核心的矛盾能力越强越要把它的活动半径控制住。1.2 合规要求倒逼架构升级传统做法里系统隔离靠网络分区、防火墙规则、数据库权限、堡垒机审计这些手段对人和固定程序是有效的。但Agent是一个“自主决策者”它会在边界内自己变换路径甚至可能因为提示词注入被诱导去做偏离本意的事。所以必须把隔离理念从“网络层面隔离”升级为“行为层面隔离”。这也是我们为什么会最终走上“VM沙箱隔离数据不出域”路线的原因。核心理念可以总结成几句话让Agent活在虚拟机里虚拟机之外的世界它默认看不见让数据只走内网链路Agent再聪明也接触不到公网让每一次数据库操作都过一道权限与审计闸门任何异常行为在发生的瞬间就被记录和拦截。这套架构不是某个单一产品能搞定的需要数据库、沙箱、网络、模型服务、Agent框架、审计系统多方配合。下面我从架构设计的角度把整条链路拆开讲。2. 沙箱隔离与数据不出域的架构设计2.1 为什么选VM而不是容器现在很多AI Agent的demo都是跑在Docker容器里的容器轻、启动快、资源利用率高。但金融生产环境里我们对隔离强度的要求远高于部署便利性。容器共享宿主机内核虽然Docker提供了namespace和cgroup做隔离但历史上出现过不少容器逃逸漏洞。安全团队一听“逃逸”两个字直接皱眉因为一旦从容器逃逸出来就是宿主机权限那等于整个数据面暴露了。而VM虚拟机自带独立内核虚拟化层Hypervisor把Guest OS和宿主机隔得干干净净攻击面要小得多。即便有人从Agent应用层打穿了操作系统也还要再突破一层Hypervisor才能碰到宿主机和其他虚拟机——这在金融合规语境下是一个决定性的安全感差异。还有一个审计算法上的优势VM有明确的边界一台沙箱VM就是一个独立的审计单元所有进出流量、进程行为、文件变更以VM为粒度做日志记录逻辑非常清晰。容器如果要做到同样粒度需要额外引入复杂的标签和追踪机制审计链路拉得很长。当然VM的代价是资源开销和启动速度。但这个问题可以通过镜像预置和模板化启动来缓解我们后续落地时用的是预置好依赖的Agent Express黄金镜像冷启动也就一分钟左右对内部场景完全能接受。2.2 沙箱内部的分层隔离设计VM解决了“外部打不进来”的问题但“里面不乱跑”同样重要。我们参照零信任的思路在沙箱内部又做了四层控制。第一层是网络隔离。每个沙箱VM只分配内网IP默认路由不指向公网网关。Agent进程所在的网络命名空间里除了与PolarDB内网域名、内部模型网关、内部知识库之间的通信其他所有目的地一律不通。也就是把“出域”定义成非法行为从路由层面直接宣告死亡。第二层是文件系统隔离。Agent运行在专门划分的只读系统盘上代码和依赖全部打包进镜像。如果Agent需要临时写文件只能写入挂载的临时卷这个卷同时被配置成不落盘或加密落盘。这样就算Agent被诱导去读取或篡改本地配置它也碰不到系统关键文件。第三层是工具执行权限隔离。Agent不是直接调用操作系统命令而是通过工具集来操作。我们在沙箱里只预置了白名单工具——查PolarDB、调模型接口、做简单的数据加工、生成报表。任何不在白名单里的命令即便Agent生成了对应的执行意图也会被沙箱的执行代理拒绝并记录日志。第四层是资源配额隔离。给每个沙箱VM分配CPU、内存、磁盘IO的硬上限防止Agent写了个死循环SQL或者出现异常递归调用时把整个宿主机资源耗尽。这在并发了多个Agent实例的生产环境里非常重要我们后面还专门优化过这一块。2.3 数据不出域的技术闭环“数据不出域”不是靠一句口号实现的它必须是一个技术闭环。我们的理解是数据在整个生命周期里从数据库到模型推理的输入输出再到Agent生成的中间结果最后到用户端展示都不能穿越到不受信的域外环境。具体落地有五个关键控制点。第一数据库访问必须走内网。PolarDB实例放在独立的VPC里沙箱VM与数据库之间通过VPC内网互通白名单只放行沙箱网段从源头保证除了沙箱里的Agent谁都不能直连数据库。第二模型推理不依赖外部API。Agent调用的底层大模型必须部署在内部推理网关后面不能说因为业务方想用某个公网模型服务就让数据往外送。金融场景里这个原则没有妥协空间。我们自建的推理网关基于开源模型做了私有化部署虽然初期成本高一些但换来的是数据不出域这条底线从未被触碰。第三外部知识获取默认拒绝。Agent如果需要知识库增强只能使用预热后的内部知识库快照不能实时去爬外部网页或调外部搜索API。这一点平时看起来保守但实际能避开很多提示词注入和数据泄露的坑。第四所有Agent出域请求都要经过出域控制面审核。什么叫出域控制面就是在沙箱外层单独布一个网络代理Agent发出的所有非内网请求会被代理接管按“域名/IP/端口”三级白名单匹配匹配不了的直接丢弃同时触发安全告警。我们一开始以为Agent不会主动往外连结果部署后第一天就有尝试连代码托管平台的动作被控制面拦了个正着。第五输出面也要管住。Agent生成的报表、文字、图表只能通过统一的应用网关返回给终端用户不能自己找通道外发。应用网关上再有内容过滤、敏感词校验、脱敏检查相当于给输出再做一道合规体检。这一整套组合下来结论很清晰Agent不是不能跑而是必须在划定好的笼子里跑。笼子本身就应该是系统架构的一部分而不是事后再用安全设备去“围堵”。3. PolarDB Agent Express落地方案3.1 它解决了什么问题整个方案里把“Agent要查询的数据”和“Agent自身运行时”串起来的那根线是PolarDB。我们选PolarDB不是随手拍的而是基于几个很现实的需求。首先是兼容性。团队里很多人本来就会MySQL语法PolarDB对MySQL高度兼容Agent生成的SQL基本不需要做方言适配迁移和学习成本都很低。其次是高可用和弹性。金融业务对数据库的可用性要求非常高PolarDB自带多副本同步、自动故障切换能力不用我们自己在应用层再折腾一套主从方案。另外Agent场景有一个特点白天业务人员集中提问数据库负载呈脉冲式上升PolarDB的弹性扩展能力正好匹配这种节奏。再次是安全与审计能力。PolarDB支持细粒度的权限控制、SSL加密传输、SQL审计和慢查询分析。Agent在数据库里干了什么全部在审计日志里这对满足“行为可审计”的要求是刚需。再说Agent Express。它不是什么神秘的黑科技我更愿意把它理解为一种“面向AI Agent场景的数据库交付形态”——把Agent连接数据库所需要的预配置能力打包好只读账号模板、权限最小化配置、连接池参数、SQL执行超时设置、一键开启审计这些原本要DBA手动配置半天的东西用Agent Express模板能几分钟就拉起来。它让“给Agent开一个库”这个动作从高风险手工操作变成了可重复的标准化流程。3.2 数据链路与权限管控的细节这里放一段我们实际在用的权限配置思路可以给读者当一个模板参考。第一步创建Agent专用账号。不要用DBA账号给Agent连库一台沙箱VM对应一个独立账号账号命名带沙箱标识方便后续审计定位。-- 创建Agent沙箱专用只读账号 CREATE USER agent_sandbox_001% IDENTIFIED BY [强密码]; -- 只授予业务库的只读权限 GRANT SELECT ON biz_db.* TO agent_sandbox_001%; -- 禁止查看元数据库 REVOKE ALL ON information_schema.* FROM agent_sandbox_001%; REVOKE ALL ON mysql.* FROM agent_sandbox_001%; -- 设置单次查询最大返回行数限制 ALTER USER agent_sandbox_001% WITH MAX_QUERIES_PER_HOUR 1200;第二步权限最小化约束。Agent很多时候会“好奇”地去查一些表结构。如果给了information_schema的查询权限它就能扫描整个库的元数据这等于把数据库的地图全暴露给了一个可能被诱导的自主体。所以我们把Agent的数据库权限压到几乎只剩SELECT而且只允许访问业务库中明确授权的表范围。第三步敏感字段脱敏。对客户手机号、身份证号这类敏感字段在数据库视图层做脱敏Agent查到的直接就是“138****1234”这种格式。这一点特别重要因为Agent会把这些数据放进推理上下文如果库里是明文那模型服务等于变相成了数据的第二存储点审计口径会变得非常复杂。第四步连接池与超时控制。Agent和PolarDB之间用专用的连接池限制最大连接数防止某个Agent失控查询时把数据库连接耗尽。同时给SQL执行设置硬超时比如单条查询超过30秒直接终止并记录到慢查询日志。3.3 沙箱与数据库之间的链路安全沙箱VM和PolarDB之间的链路也不能裸奔。我们用了几道保险链路层开启SSL/TLS加密防止数据在VPC内部被旁路监听数据库白名单只放行沙箱网段其他来源一律拒绝数据库侧再配合审计日志记录每条SQL的来源IP、用户、执行时间和内容和沙箱VM侧的Agent行为日志相互印证。这里要说一句经验两边日志必须有共同关联键。我们最初沙箱侧日志和数据库审计日志各记各的出了状况很难对上号。后来统一采用“沙箱ID Agent运行实例ID 会话ID”作为关联维度两边日志都打上这个组合标排查问题的时候效率提高了几倍。4. 从验证到生产落地实操复盘4.1 如何快速拉起一套安全环境很多团队做类似项目卡在第一步“我想试试但不知道怎么开始”。这里分享一套我们总结出来的最小化落地路径从零到出第一个结果大约需要半天。第一步准备好PolarDB实例创建业务库和测试数据创建低权限Agent专用账号。第二步建一个标准化的沙箱VM黄金镜像。镜像里装好Python运行时、Agent框架比如LangGraph或自研的简单编排器、PolarDB连接驱动、内部模型网关SDK、运行监控Agent。这一步是一次性投入之后每开一个新沙箱从这个镜像复制即可。第三步配置沙箱网络。按上文说的把默认路由指向内网只放行PolarDB内网地址、模型网关地址、内部知识库地址到白名单其余出网请求全部交由出域控制面处理。第四步配置工具集白名单。给Agent暴露的工具就几个query_db查询PolarDB、call_model调用内部模型、generate_report生成报表。工具的参数也做强约束比如query_db最多返回500行call_model的输入长度有上限。第五步跑通一个最简用例。让Agent回答“上个月销售额最高的五个城市分别是什么同比变化如何”看它能否自动生成SQL、查库、整理结果。这个用例跑通整个技术闭环就算打通了。我把这套操作整理成了一份内部用的Checklist内容比上面更细但核心就是这五步。团队照着走基本没有空转。4.2 沙箱配置的实操要点沙箱这层配置是最容易“看起来安全、实际有洞”的地方。举几个我们实践过的关键点。第一务必关闭沙箱VM的SSH公网访问。Agent本身跑在沙箱里如果运维习惯性开着公网SSH等于给攻击者留了一扇门。我们要求所有沙箱VM仅允许通过堡垒机、从内网跳板机登录公网SSH端口在全网段封禁。第二注意临时文件的处置。Agent在执行数据分析任务时经常会写中间结果到本地。如果这个本地目录恰好是共享存储其他沙箱也挂载了就会形成沙箱间的数据串扰。我们后来规定每个沙箱的临时目录默认不共享任务结束后由审计模块统一清理。第三要对Agent的递归调用行为做限制。有的Agent框架支持子Agent或者多步递归优化这个特性在沙箱里很容易演化成资源黑洞——一个Agent派生十个子Agent十个子Agent每个再去查一轮数据库。我们在沙箱配置层面直接限制最大并发子任务数超过将被拒绝。下面是一个简化版的沙箱资源配置示意实际生产环境里参数值会随着业务量调整但结构基本一致sandbox: name: agent-sbx-001 cpu_limit: 4 mem_limit: 8Gi disk: root: read-only tmp: 20Gi, encrypted network: default_route: reject allow_domains: - polaradb-internal.example.com - model-gateway.internal.example.com - knox.internal.example.com tool_whitelist: - query_db - call_model - generate_report max_concurrent_subtasks: 2 audit: enable: true log_destination: kafka-audit.internal4.3 从POC到生产环境要补的课POC阶段跑通不等于可以直接上线。我们在从POC到生产的过渡中补了三门课。第一门课是压测与配额规范化。POC阶段我们只给了一个沙箱实例生产上要同时支撑几十个业务账号并发提问。这里做了两件事一是给每个Agent实例单独配额防止个别极端任务消耗掉公共资源二是做了数据库连接数和水位的压测搞清楚PolarDB在Agent高频查询模式下的真实承载能力再按业务量规划沙箱实例数量。第二门课是异常行为基线化。Agent的正常行为和异常行为需要一个基线来界定。我们跑了一周影子模式——Agent照常执行但结果只落在测试库不进入真实生产数据。把Agent在这期间产生的行为数据收集起来分析出正常行为分布再依据这个分布配置告警阈值。比如正常Agent每天查库次数在某个范围如果某天某个实例超过标准差的数倍就自动触发复核。第三门课是应急预案。安全团队问了一个问题如果发现Agent正在试图向外部投递数据你怎么在最短时间内终止一切行为我们设计了三级应急开关一级是沙箱网络断网一键切断该沙箱所有对外连接二级是Agent进程冻结让运行中的任务直接挂起三级是数据库侧即时吊销该Agent账号权限。三级联动可以在30秒内把风险面压到最小。5. 上线后踩过的坑与排查实录5.1 出域告警排查的真实案例第一个坑出现在上线初期。安全平台报了一条出域告警某个沙箱VM里的Agent进程尝试连接一个外部Git仓库域名。我们的第一反应是“Agent被攻破了”但排查下来发现真相很朴素——Agent框架在初始化时默认会检查GitHub上的插件更新清单这和业务本身无关。这个案例很有代表性框架默认行为和安全策略的冲突往往比恶意攻击更常见。解决办法是把Agent框架的自动更新、遥测上报、甚至版本检查相关功能全部显式关闭并在镜像构建时统一写死配置。不要指望框架的默认配置能满足金融级合规要求必须自己过一遍黑名单。5.2 数据库连接池被“Agent风暴”打满第二个坑更隐蔽。有一天上午PolarDB的活跃连接数突然飙到上限业务侧查询直接超时。查了审计日志发现源自某个新增Agent实例的并发查询特别高而且每一条查询的执行计划都很差——原来这个Agent在处理一个多维度筛选问题时选择了一条全表扫描的SQL方案还拆成了几十个子查询并发执行。这个问题的根源在于模型生成的SQL不会自动走索引也不能保证执行效率。我们的解决办法有几层在工具层给Agent配置了SQL预检器生成后的SQL先经过执行计划分析凡是预估扫描行数超过阈值的一律拒绝并提示改写再叠加单实例并发控制让一个Agent最多同时运行三个数据库查询超出部分排队等待。经过这两层优化类似问题基本没有再出现过。5.3 Agent幻觉引发的数据访问误判还有一个任何做Agent落地的人都躲不过去的问题大模型幻觉导致Agent查询了不存在的表。Agent在生成SQL时偶尔会“创造”出一些听起来合理的表名或字段名。PolarDB会直接报错但Agent收到报错后会尝试反复重试——有几次甚至把不同的报错SQL换着花样来回查浪费了不少资源。我们后来在Agent的数据库工具里加了一层“元数据提示”在做查询之前先把数据库的真实表结构和字段列表注入到提示上下文里让模型基于真实元数据生成SQL而不是凭“想象”去猜测。这个改动同时提升了SQL正确率减少了报错重试属于性价比极高的优化项。5.4 常见问题速查表我把上线以来遇到的典型问题整理成了一张表后续排查时可以按图索骥。现象可能原因排查方法解决建议沙箱内Agent无法访问PolarDB数据库白名单未加沙箱网段检查PolarDB白名单配置将沙箱网段加入数据库白名单Agent生成SQL报表不存在模型幻觉元数据缺失查看模型调用日志的提示内容向提示中注入真实表结构信息出域控制面频繁告警框架自动检查更新/遥测提取目标域名确认是否为框架默认行为在配置中显式关闭自动检查、遥测多个Agent并发导致数据库连接打满连接池配置不足或SQL质量差查看PolarDB连接数和慢查询日志增加SQL预检、限制单Agent并发查询数沙箱内Agent写入异常数据临时目录读写权限过宽检查挂载卷权限与落盘策略加密临时卷任务结束后自动清理审计日志两边对不上缺少统一关联标识检查沙箱日志与数据库审计日志的关联键统一使用沙箱ID实例ID会话ID5.5 生产环境维护的几条心得最后一个部分说几条维护层面的体会。这套架构上线运行了小半年稳定性基本在可接受范围内但维护工作量和传统系统完全不同——你不仅要维护“系统本身”还要维护“系统的行为预期”。第一Agent相关配置变更必须走版本管理。环境变量、工具权限、模型参数每一项改动都可能导致Agent行为出现意料外的变化。我们把所有配置纳入了Git管理每次变更都有评审记录出问题可以快速回滚。第二日志水位要留足余量。Agent比传统程序话多得多每执行一个工具、每调用一次模型、每做一次重试都是日志。如果日志系统磁盘规划不足三天就能爆盘而审计数据恰恰是不能丢的。我们目前的做法是日志七日热存加长期归档冷存双份备份确保合规追溯随时可用。第三沙箱镜像要定期重建不要“一台跑一年”。长期运行的沙箱VM会有累积性的环境漂移软件包升级、临时文件残留、配置被误改这些都是风险。我们现在每个月都会基于最新黄金镜像重建业务沙箱把“漂移”消灭在摇篮里。另外要特别提醒一件事Agent的合规审查不能只看技术和系统模型本身的输出同样要纳入管理。我们内部对Agent生成内容做了抽样质检每周抽一定比例的任务由业务专家复核结果是否准确、是否有越权表述、是否符合业务规范。这项“人工陪跑”机制看似老派但在金融场景下恰恰是不可或缺的最后防线。说句实在话做这个项目最大的收获不是跑通了技术方案而是让业务、研发、安全和合规几方找到了一个协作模式业务提需求研发建能力安全划边界合规做验收。AI Agent这件事在金融行业能走多远最终不取决于模型参数有多强而取决于你给它的笼子搭得有多专业、多可靠。我们这套VM沙箱隔离数据不出域的方案就是在这个思路下长出来的。希望这篇文章能给同在路上的人一点参考。