我所在的银行，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 B，Agent 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数量到千级之后，平台就不再是后台支撑角色，而是真正决定了整个智慧金融业务能不能跑得稳、跑得远的那条命脉。
