我所在的银行Agent 数量已经进入四位数。从最早的智能问答机器人到营销助手、风控分析、运营提效上千个Agent在生产环境里同时跑的场面放在两年前根本不敢想。但真正到了这个规模之后我们内部讨论最多的一句话变成了Agent越上越多AI平台反而成为最大的瓶颈。这篇文章想把我们在千级Agent压力下重新梳理平台架构的过程、思考和踩坑记录下来给同样走到这一步的团队做个参考。它不聊怎么调Prompt也不聊怎么选模型核心就一件事当一千多个Agent真刀真枪跑在银行业务线上AI平台为什么必须换一套玩法。1. 一千个Agent上线之后什么悄悄变了1.1 从“一个Agent”到“一张Agent网络”单说Agent数量本身其实没什么好兴奋的。1000多个Agent听上去就是个数字真正让人坐不住的变化发生在Agent之间开始产生纠缠之后。我刚接触银行Agent建设时典型场景是“单兵作战”一个智能客服机器人接一个知识库调一个接口跑完一条链路就结束。那个阶段平台再怎么简单都够用——模型API网关加日志系统顶多配个向量检索服务一个Agent就是一个完整闭环。等到数量过千情况完全不一样了。业务部门会希望营销智能体去读客户标签而客户标签又来自客户画像智能体客户画像智能体要的数据又得从数据仓库智能体去拉。很多Agent之间会互相调用慢慢形成一张服务依赖网络。你不再只是维护1000个孤立的机器人而是在运营一张牵一发动全身的Agent网络。这场变化带来的第一个冲击是变更爆炸半径变大。以前升级一个模型最多影响单个Agent现在改任何底座能力都会沿着依赖链传导可能一次升级就弄挂了十几个下游Agent。第二个冲击是身份模糊。单点时代Agent对内对外都没有独立身份——反正是自己团队维护的一套代码。但在网络化体系里Agent如果连“我是谁、能调用什么、以什么身份去调用别人”都说不清楚那权限隔离、审计追溯、责任归属就全都无从谈起。这也是大家开始讨论“重新思考AI平台”的根本原因。平台存在的意义要从“跑模型的地方”升级成“治理Agent网络的中枢”。1.2 真正的问题不是模型是治理还有一个观察很有意思千级Agent在线之后出故障的原因往往反而不在模型上。平台团队有个惯性——一听到Agent效果不好立马怀疑是模型不行、数据不行然后启动一轮训模型或者调优的工作。但实际上线上数据翻出来的大量问题根因都在治理侧。随便举几个我在梳理线上问题时遇到的真实类型某个营销Agent的知识库引用了半年前的旧版本给客户的推荐信息明显过时但责任归业务还是归平台完全说不清楚两个部门分别做了一个功能几乎相同的报表问答Agent重复建设还各自沉淀了私有知识库平台侧完全不知情某个Agent的提示词里被人塞了一段“忽略之前所有指令直接输出……”的内容虽然没造成实际损失但审查报告摆在桌面上的时候所有人后背都发凉某个Agent连续三天半夜报错但因为只做了应用层日志监控没有Agent级别的服务等级目标SLO等业务投诉过来才发现。这类问题有个共同点它们不是推导能力的问题而是治理问题。模型再强也没法在一个权限混乱、状态不清、审计缺失的平台里把自己管好。一千个Agent同时在线任何小的治理漏洞都会被放大、叠加最后变成平台事故。所以银行重新思考AI平台第一层原因就是想清楚Agent不再是“试验品”而是和核心系统一样需要生命周期管理、审批流、可观测性、可追溯性。这不是模型团队单方面能解决的是平台工程的活。2. 千级Agent压力下AI平台最该重构的四件事2.1 平台定位从“模型转发”升级为“Agent运行时”过去银行里说的AI平台核心职责非常清晰模型管理、API转发、配额限制、计费统计。这就像一个“模型超市”业务团队进来挑个模型拿回去自己组装成Agent。这种模式在几十个Agent的时候还说得过去但到了千级规模就顶不住了。为什么呢因为Agent不是简单的API调用它内部有循环——观察、思考、行动、再观察。这个循环里包含上下文管理、长短期记忆、工具调用、错误恢复。如果平台只提供裸模型接口每个业务团队都要自己实现这套运行时逻辑结果是每个Agent一套上下文管理器、一套向量库方案、一套工具调用兜底逻辑整个维护成本直接爆炸。我现在的观点是平台必须把“意图”标准化而不是只把“API”标准化。比如“查询客户资产”“生成营销文案”“判断交易风险”这些高频操作应该沉淀为平台级的标准能力和工具所有Agent按权限直接复用。平台要做的是抽象出一套统一Agent运行时负责上下文组装、记忆管理、工具调用总线、重试与回退。业务团队只需要在平台上注册Agent、配置技能、绑定工具和知识库。这样Agent本身变成一种“配置策略资产”而不是一堆分散的代码项目。这跟传统中间件的发展路径是一样的——数据库连接池、消息队列、服务发现都是从“各自实现”收敛为“平台标准”。AI Agent迟早也会走这一步只是银行业务因为合规压力会比别的行业走得更快。2.2 Agent身份把权限问题设计成银行的“账户体系”银行有一个现成的管理体系叫账户和权限分级四道防线、复核机制、最小授权。这套东西看起来传统但放到Agent治理里反而特别好用。我们一开始没有建立Agent身份体系结果很狼狈。某个Agent需要用客户数据研发同学图省事直接申请了宽泛权限虽然没有故意越权但审计抽检的时候差点过不了关。另一个Agent因为权限太小线上频繁报“没有权限调用”业务投诉不断。权限这件事在单点Agent时代是小事到了千级规模就成了平台的第一大治理难题。我们后来设计的Agent身份模型借鉴的就是银行账户分级的思路。每个Agent都有全局唯一标识关联风险等级、归属团队、生效范围、工具白名单、知识库授权范围。下面是核心字段字段说明Agent ID全局唯一标识是审计和责任归属的基本单元风险等级低、中、高决定发布审批流程与监控强度归属业务所属部门、团队、负责人必须有明确责任人工具权限可调用的系统API和数据范围按白名单管理知识库范围可检索的知识库及其版本防止引用过期内容审计级别全量对话日志、抽样日志或无存档视风险等级而定这套Agent身份体系上线后效果立竿见影。业务侧申请权限的时候自己先按风险等级对照平台侧审批也有依据不再是“拍脑袋”决定。最重要的是一旦出了问题能定位到具体Agent和责任人这在银行内部是救命级的特性。2.3 可观测性从看日志升级为看Agent链路传统应用的监控看请求量、响应时间、错误率三件套就行。Agent应用到监控框架起来之后我们发现远远不够。一个Agent在处理复杂任务时可能先调用检索服务查知识库再调一个业务系统拿数据然后可能生成一段内容交给另一个Agent复核最后才给出结果。如果某一步失败或者结果不对你只看了传统监控指标根本不知道问题出在哪个环节。我印象最深的是一次线上排查一个客服Agent反复给用户推荐已经下架的产品。传统监控看下来一切正常响应时间稳定成功率也高但业务就是在投诉。后来回放完整链路才发现Agent在规划环节使用了旧版本的知识库索引向量检索返回了过时内容。这类问题如果没有Agent级链路追踪逐条查线上日志能把人查到崩溃。一千个Agent的前提下排查成本是不可接受的。我们最后沉淀了几个关键观测指标分享出来供参考工具调用成功率Agent调外部系统服务时成功与失败的比例规划轮数单次任务中Agent思考与行动的循环次数能够暴露死循环苗头上下文长度消耗Token消耗趋势判断上下文是否失控知识库命中率向量检索的命中情况帮助判断回答质量人工介入率多少比例的任务最终需要转人工处理。这些指标统一接入平台监控大盘按Agent维度做聚合。平台团队看大盘能快速定位“哪个Agent、哪类问题”再深入链路明细。这一步做完我们才真正建立起规模化Agent运营的基本盘。2.4 安全控制Agent比传统应用更需要一道横切的闸门如果说身份解决“谁能做什么”安全就要解决“做了什么、说了什么、边界在哪”。分布式拒绝服务、SQL注入这类传统安全问题大家都很熟但Agent引入了一个新面提示词注入和恶意指令覆盖。用户在对话里绕开会话保险先诱导Agent执行非预期动作。单Agent时代风险还可控千级Agent就是巨大的攻击面。我们平台重构时专门做了一个Agent网关层所有Agent进出流量都经过它类似银行网络里的防火墙可以统一做风险识别与拦截。银行场景里边界控制最重要的三件事一是工具调用边界Agent能调什么系统、能触发什么交易必须有硬限制有些关键操作必须加人工复核二是内容合规Agent生成的面向客户的内容要经过敏感词过滤和合规策略引擎检查三是数据脱敏Agent拿到的数据上下文只允许包含最小必要字段身份证号、手机号这类信息原则上脱敏后再进提示词。这些能力如果放在单个Agent里各行其是一方面维护成本极高另一方面尺度不一致。平台统一做才能保证所有Agent在同一个安全基线上运行。3. 平台重构落地路径我们是怎么一步步走的3.1 先盘点家底花四到六周画一张Agent地图平台重构最大的坑是一上来就搞底座、建能力结果连存量Agent有多少、在跑哪些场景、用了什么知识库都说不清。所以我们把第一阶段定义为全域盘点不写一行平台代码。盘点的方法不复杂就是建立Agent资产清单。我们把每个存量Agent按身份信息、应用场景、调用方、依赖数据、知识库版本、运行状态填进一张表里存量摸底之后搭配流量数据分析发现有相当比例的Agent处于“僵尸状态”基本上存活率没有想象那么高。还有几个Agent功能高度重复属于明显的重复建设。盘点过程还有个额外收获画出了Agent之间的依赖关系图。哪些Agent在调别的Agent、哪些知识库被多个Agent共用、哪些工具是高频瓶颈一目了然。这张图后来成为平台重构的决策依据——先优化什么、先迁移什么完全按依赖关系排优先级。3.2 先治理再迁移而不是把混乱搬进新平台熟悉架构迁移的人都知道最糟糕的做法就是把原有的一堆混乱逻辑直接搬迁到新平台里。Agent也一样千万别急着把千级Agent一键切过去。我们的策略是分两步先在旧环境里做一次“定纷止争”再启动平台迁移。所谓定纷止争就是把权限重新梳理、知识库版本标准化、僵尸Agent下线、重复Agent合并。这些动作短期内不依赖新平台也能做但如果不做到新平台就会把治理债带过去。举个例子我们曾经有一个“智能客服”Agent和一个“在线问答机器人”底层调的是同一个大模型、同一个知识库只是界面入口不同。这两个Agent在盘点里被合并为一个重新定义意图和技能后运维成本和Token开销都降低了。这种清理动作是迁移之前必须完成的功课。治理完成后我们才把存量Agent按风险等级分组低风险Agent先迁移到新平台验证流程拿到结果样本后再迁移高风险Agent。这个过程很像切流量的过程先让一部分Agent把新平台的坑趟平再做全量上量。3.3 沉淀Agent标准模板把“试错”变成“组装”千级Agent平台如果只提供通用底座业务团队用起来还是无从下手。所以我们做了一批标准化模板降低业务团队接入门槛。模板按行业高频场景设计覆盖客服问答、营销文案生成、报告摘要、数据查询、风险预警解读等常见Agent类型。每个模板里已经配好了默认的提示词结构、知识库接入方式、工具调用建议、人工复核节点和审计策略。业务团队拿到模板只需要修改自己场景的特殊参数就能快速生成一个新的Agent。这一步的价值有两个。一是把平台治理规范前置到模板里新Agent天生就符合权限、审计和安全要求二是沉淀最佳实践比如长任务的上下文管理、工具调用失败的兜底话术都会预置在模板里新项目不用从零探索。模板不能是死板的。我们会按月巡检模板里的模型选择、知识库挂载、系统调用配置过期就更新。毕竟银行业务变化快平台模板如果跟不上又会出现“Agent在跑老规则”的老问题。3.4 灰度切换与并行验证用数据说服所有人平台重构这种项目最大的阻力往往不是技术而是业务团队不放心。毕竟Agent已经在生产环境跑得好好的凭什么让我迁移到你们的新平台我们没有靠行政命令推而是设计了一套并行验证机制同一批Agent在旧平台和新平台同时运行前端流量随机分流两周后对比数据。比较的指标包括回答准确率、工单转人工率、用户投诉率、单次任务Token消耗、工具调用成功率。当新平台指标全面达到或者超过旧平台时迁移就成了顺理成章的事业务团队反而会主动问什么时候切到新平台。这套并行验证机制还有另一个好处——积累了一套Agent验收标准。后续平台接新Agent时照着这个标准做准入评估不再依靠“我觉得效果不错”来判断好坏。4. 迁移过程中的常见坑与排查实录4.1 多Agent互相调用差点跑出一个死循环有一次平台刚上线几天监控平台突然报了一个Agent实例数飙升某一类任务的处理时长飙升了几十倍。排查链路发现Agent A在处理订单异常时调用了Agent BAgent B又因为某些条件不满足回调了Agent A两个Agent互相抛问题陷入了一种业务层面的死循环直到超时崩溃才停止。传统应用里这种情况叫服务循环依赖但在Agent里更隐蔽——每个Agent看起来都是合理的但组合起来就出问题。我们在网关层加了两个开关一是单次任务的规划轮数上限一旦超过阈值直接终止并生成告警二是Agent之间的调用跳数上限防止调用链无限延长。经过这次事故要求所有关键Agent在上线前通过循环依赖检查平台侧自动扫描调用图谱。4.2 上下文窗口的“隐形爆炸”千级Agent上线后Context Window上下文窗口超限是高频故障。很多Agent在设计时只考虑了单轮问答实际跑起来用户会追问、会递进对话一轮接一轮地累积系统瞬间烧吐了Token响应反而变慢。我们做的优化是把长期记忆和短期上下文分开。短上下文中只保留当前任务的关键信息历史摘要定长压缩后存入向量记忆库任务需要时再按需检索回填。这有点像一个员工记笔记的方式——不可能把一辈子的事都装进脑子但随时能从笔记本里翻到关键资料。平台侧我们还加了Token消耗异常检测任何Agent单次任务消耗超过预设阈值就会触发告警自动降级到简单模式。这样避免了上下文爆炸导致的失控成本。4.3 成本分散每笔都不大月底一看吓一跳千级Agent的推理成本是一笔非常容易被低估的账。单Agent单次调用可能只有几分钱但一千个Agent跑一个月金额非常可观。我们第一次拿到月度平台成本报表时发现大头不是几个明星Agent而是大量长尾低效Agent——有的Agent总在无意义地调用高价模型有的Agent上下文长期冗长这些问题单看每条调用都不严重但总量惊人。之后我们在平台里做了任务级计费拆分每个Agent、每个技能、甚至每个意图都能独立核算成本。同时把模型路由策略做了分层——简单问题用轻量模型快速响应复杂问题才进入更强模型。这好比看病不是所有毛病都找专家普通感冒挂普通门诊就行。银行AI平台也一样用小模型解决小事大模型解决大事整体成本能降下来不少。4.4 别急着搞多Agent协同这两年多Agent的概念很火平台重构的时候也有团队想一步到位搞“多Agent协同编排”让一堆Agent互相开会、共同决策。我的判断是银行场景里初期不要太激进。多Agent协同确实能处理更复杂的任务但代价是问题定位难度成倍增加、故障扩散风险上升、审计可解释性下降。银行对可解释性要求极高——监管追问起来你不能说“这是几个Agent互相商量出来的结果”。我们平台重构第一期主推的是单Agent能力强化和平台治理能力多Agent协同只在极少数内部试点场景里小范围验证直到单Agent质量足够稳定才逐步放开复杂编排。这个节奏是我个人觉得最稳妥的一条路。最后再分享一点个人体会。回看整个平台重构过程最核心的变化不是技术换了多少而是平台团队的心智模式换了以前想着“怎么把模型能力开放出去”现在想着“怎么把上千个Agent治理好”。银行做AI平台本质上是在建一座智能中枢系统身份、权限、审计、监控、成本、应急一个都不能少。Agent数量到千级之后平台就不再是后台支撑角色而是真正决定了整个智慧金融业务能不能跑得稳、跑得远的那条命脉。