1. 300个智能体的瓶颈从来不在模型参数里2025年这股Agent浪潮走到现在一个有意思的现象是大家从比模型智商开始转向比工程底盘。北京银行的300个智能体之所以值得拆解不是因为它用了什么惊天动地的模型而是它把这300个智能体真正跑到了生产环境里跑进了业务流程的毛细血管。市面上做个Agent Demo连半天都不用但让300个Agent各自守着一条业务线、每天稳定运行、出问题能追溯、换模型不被绑架——这才是真正的分水岭。我见过太多团队卡在这个阶段模型很强Agent也做得出来一上生产就露馅。上下文串了、工具乱调、token成本失控、回答不可复现、某个Agent一出错整条链路雪崩。这些问题的根子都在模型外面那层东西上——也就是Harness。Harness这个词最早从测试工程来意思是测试夹具把被测对象固定住、接上输入输出、加上监控仪器。放到Agent工程里我的理解是模型之外的一切工程机制。包括请求怎么路由、上下文怎么组装、工具怎么调用、记忆怎么存取、权限怎么卡控、日志怎么记录、效果怎么评估、模型怎么轮换。它不是Agent框架不是LangChain那种编排SDK更不只是prompt模板而是把模型这颗发动机装进业务这辆车里的整套底盘、传动和仪表盘。1.1 模型的智力只决定上限Harness决定能不能规模化先摆一个反直觉的结论模型的推理能力只决定Agent的天花板Harness决定Agent能不能稳定地摸到那层天花板。我做个类比你就能理解。发动机马力决定一辆车的极限速度但决定你能不能每天安全通勤的是底盘调校、刹车系统、转向手感和电子稳定程序。你不可能因为换了台一千马力的发动机就不管刹车和悬挂了。Agent也一样模型再强如果外部没有一套稳定的控制机制它在单次对话里表现再好扔到生产环境里跑一个月就会原形毕露。规模化场景里模型暴露出来的问题从来不是不够聪明而是不够稳定。同一个问题上午答和下午答可能不一样同样的流程换了个输入格式就崩模型偶尔会自作主张调用不该调的工具遇到超出上下文的内容它会一本正经地编答案。这些都不是换更强模型能解决的必须在模型外面加约束、加缓冲、加兜底。回头看北京银行这类金融机构为什么要自研一套Agent平台而不是简单地采购大模型API然后让各业务部门各自为战核心原因就是**没有统一Harness的Agent本质上是300个不可控的黑盒。**放在金融场景里这意味着不可审计、不可回滚、不可评估监管和风控这一关就过不去。1.2 三百个智能体到底在跑什么业务顺着这个话题我们先还原一下这300个Agent大概率分布在哪些场景。基于银行业公开分享里常见的智能体应用大致能看到这么几个类别。客户服务类智能客服、投诉工单分类、客户意图识别、营销话术生成这类Agent量大、并发高、对响应时间敏感。运营支持类内部制度问答、费用报销审核、合同条款比对、文档自动归档这类Agent处理的是内部员工的高频重复劳动。风控合规类信贷材料初审、反洗钱可疑交易报告草拟、风险舆情监控、监管报送字段核验这类Agent直接触碰业务底线对准确性和留痕要求极高。数据分析类经营报表解读、客户画像生成、指标异常归因这类Agent通常要接数据库和数据平台涉及复杂的工具调用。300这个数字单看没什么感觉但放在银行语境里意味着它几乎覆盖了前中后台所有条线。真正的难点在于这些业务场景差异极大有的要毫秒级响应有的可以容忍分钟级延迟有的必须私有化部署有的可以走公有云有的事务逻辑极其严格有的偏开放式问答。这一堆互相冲突的需求靠每个场景单独接模型、单独写代码是死路一条。唯一的解就是建一个统一平台把公共能力沉淀下来让每个Agent变成平台上可配置、可治理、可观测的一等公民。这就是Harness工程的起点。2. Harness到底管什么别和Agent框架混为一谈热词里能同时看到Agent框架、Agent架构、Harness、Harness Engineering这几个词说明行业里大家对边界其实还没完全对齐。我先把自己的定义讲清楚后面所有讨论都基于这个定义。Agent框架解决的是怎么把Agent写出来的问题比如LangChain、Semantic Kernel、MetaGPT、AutoGen这些它们提供的是多Agent协作的编程模型和编排原语。Harness解决的是Agent写好之后怎么在组织里活下来的问题它是框架外面那层承载了组织治理诉求的运行时和配套体系。2.1 Harness的四个核心职责我做了这么多年平台类项目习惯把Agent的Harness按职责拆成四块职责域核心解决什么关键能力接入与控制Agent的入口、鉴权、限流、降级统一API网关、租户隔离、灰度发布编排与执行多步任务的推进、工具调度、状态持久化状态机、任务队列、工具注册中心、子Agent调度记忆与上下文让模型带着正确的信息工作上下文组装、向量检索、短期/长期记忆、缓存治理与观测可审计、可评估、可回滚、可优化全链路追踪、日志留痕、评测集、成本计量、安全护栏这四块里最容易被人忽略的是治理与观测。很多团队做Agent第一步把编排搞定了第二步把记忆搞定了到了第三步发现自己完全不知道线上Agent在干什么。Prompt改了之后效果是变好还是变坏工具的调用成功率是多少哪个Agent吃掉的token最离谱这些问题答不上来Agent就永远停留在实验品阶段没有scale的资格。2.2 为什么Harness比模型更值得投入拿热词里的deepseek harness和codex harness来说这两类东西的走红本身就是信号。以DeepSeek为代表的国产开源模型出来之后很多企业都在私有化部署但模型部署完并不能直接用。你要做上下文模板、要做工具调用协议、要做限流和缓存、要接企业内部的统一身份认证。这些围绕模型的适配工作汇聚成了事实上的harness层。Codex harness走的路子也类似——把编程Agent放进一个受控的容器里外面罩上编译验证、沙箱执行、代码审查机制模型只是一个写作引擎。业界常说一句话**模型是易耗品Harness是资产。**大模型一年一换代今天你选的旗舰模型明年可能就是入门款。但Harness里沉淀的上下文策略、工具协议、评测集、安全基线都是跟着业务走的换模型不换Harness资产就一直在。我自己做项目的经验是团队开始把Harness当成独立于模型的技术栈来规划了才算真正想明白了Agent规模化这件事。否则就会出现一个特别尴尬的局面——模型一升级所有Agent跟着返工。这正是模型主导思维的坑。3. 一套能容纳300个Agent的架构长什么样接下来进入正题基于大型金融机构Agent平台建设的常见实践我把这套支撑300个智能体的架构按层次拆开。这套分层不是北京银行内部代码的逐行复刻但代表了同类大型组织里经过验证的主流打法。3.1 六层架构每一层都有明确边界整体上我习惯把它分成下面六层从上到下依次是接入与体验层面向员工、客户、管理者的各类入口包括手机App、网页端、企业微信、柜面系统里的对话界面、工单入口。智能体运行时层Agent的注册、启停、编排、状态流转、任务调度是整个平台的中枢。模型网关层统一封装多个模型服务做模型路由、负载均衡、私有化模型与公有云模型的桥接。工具与数据服务层把银行内部的查询、录入、审批、报表等能力以标准API的方式暴露给Agent。知识中心层非结构化文档、制度库、产品库、向量索引的统一管理和检索服务。治理与安全底座横跨所有层的横向能力包括鉴权、审计、监控、脱敏、评测、成本核算。这里最关键的判断是**2、3、4、5层必须以平台的方式建设而不是以项目的方式建设。**什么意思很多企业的现状是客服团队建了一套Agent用的工具API信贷团队又建了一套两边老死不相往来。等到300个Agent的时候同一个银行流水查询接口可能被二十个Agent各接了一遍每个的鉴权方式都不一样。工具服务层不统一上层再怎么编排都是空中楼阁。3.2 智能体运行时300个Agent的共同底盘智能体运行时是这套架构里最有技术含量的部分。它要解决的第一个问题就是300个Agent怎么住在同一个平台上而不互相干扰。我的建议是给运行时引入三个基础设计第一任务模板化。不要把Agent当成一个永远在线的长连接服务而是把它建模成任务处理器。每个Agent定义好自己的输入Schema、输出Schema、允许调用的工具集合、上下文窗口策略。来一个用户请求运行时按模板实例化一个任务跑完就销毁。这样天然支持高并发也方便做限流和降级。第二状态机驱动。业务型Agent很少是一问一答的更多是搜集材料→核验信息→调用规则引擎→输出结论→等待人工确认这种流程。用状态机来表达流程每一步都有明确的状态、输入、输出和异常转移。好处有三出错了能定位到具体环节卡住了能人工干预流程变更了不用改模型改配置就行。第三Agent间通信走消息。300个Agent之间一定会有协作场景比如信贷审批Agent需要调用反欺诈Agent的结果。不要让Agent之间直接用函数调用硬编码而是通过消息总线或共享任务队列解耦。这样每个Agent的变更都是独立的不会牵一发动全身。3.3 模型网关统一路由和模型轮换的转接头模型网关这一层在银行场景里非常关键。一方面出于数据合规要求大量推理要走私有化部署的模型另一方面又不可能完全放弃外部模型的创新能力。网关的使命就是让上层Agent感知不到这种差异。具体来说模型网关要做几件事模型路由按业务场景和任务复杂度动态选择模型。简单意图识别、实体抽取走小模型复杂推理、长文档分析走大模型。一个Agent内部不同环节都可以配置不同的模型策略。统一调用协议屏蔽各家模型API的差异让Agent开发者和模型解耦。输入输出过滤在模型之前和之后各加一道过滤前置过滤做数据脱敏和敏感信息的遮罩后置过滤做合规校验比如不让模型输出任何投资建议类的违规话术。缓存与限流对高频相同请求做语义缓存降token成本对每个Agent设置配额防止某个Agent失控打爆模型服务。很多人问模型网关是不是多此一举直接在主流程里调OpenAI/DeepSeek的SDK不就行了做过生产系统的人都知道一旦Agent数量上百模型API的稳定性就成了最大变量之一。模型服务抖动、限流、版本升级如果每个Agent都自己去适配运维就是地狱。网关统一兜住上层Agent才睡得着觉。4. 单个Agent的Harness怎么设计一个信贷初审Agent的完整拆解平台架构是骨架具体到单个Agent的Harness设计才是血肉。我拿一个很典型的场景——信贷业务材料初审Agent——来拆一遍。为什么拿这个场景举例因为它的特点几乎代表了金融机构Agent化的理想切入点流程相对固定、有明确的规则依据、文档量大、结果必须可追溯。它不是金融业务里最聪明的Agent却是最能体现Harness价值的Agent。4.1 场景定义这个Agent到底在干什么信贷初审传统上是客户经理把借款人的营业执照、财报、征信报告、抵押物材料收齐然后初审岗人工核对材料完整性、真实性并做初步的风险判断。这个岗位重复性高、流动性也高正好是Agent能替代的典型场景。但注意这里说的替代不是让Agent直接给贷款批不批的结论而是把流程拆成四步材料完整性核验根据业务规则检查必备材料是否齐全。关键信息抽取从财报、征信报告中提取营收、负债、逾期记录等结构化字段。初步风险标记根据预设规则标记出明显异常项比如征信查询次数过多、短期负债激增。生成初审意见草稿给人工复核岗提供一份初审报告草稿包含依据和结论。这四步里真正需要智能的其实只有第2步和第3步的小部分其他都是确定性的流程和规则。最大的坑在于很多团队做这个Agent一上来就想着让模型读懂财报然后给出结论结果模型幻觉、依据无法追溯业务部门根本不敢用。4.2 Harness设计边界、状态机与上下文组装正确的做法是把Agent的边界划清楚。我给这个Agent设计的Harness包括状态机定义状态1等待材料上传状态2材料格式校验触发工具文件解析服务状态3完整性核验触发规则引擎不依赖模型状态4信息抽取触发模型OCR服务结构化信息状态5风险规则匹配触发规则引擎状态6生成报告草稿触发模型输入是前几步的输出状态7人工复核进入银行审批工作流异常状态材料缺失、识别失败、模型超时、规则冲突全部走人工兜底为什么一定要状态机因为这个Agent一旦在生产环境跑每一步都对应着审计留痕的需求。审核人员后续需要能够回答这笔业务Agent当时为什么认为材料缺失没有状态机这个为什么无从查起。上下文组装策略上下文是Agent Harness里最容易翻车的地方。很多Agent效果差不是模型笨是喂进去的上下文太乱。我的原则是能不进prompt的就不进能用结构化数据的就不用自然语言。具体到这个信贷初审Agent财报数据不要直接把PDF文本塞给模型而是先用OCR信息抽取工具把营业收入1.2亿净利润300万这类字段抽出来再以结构化JSON的形式放进上下文。征信报告同理把它转成近六个月查询次数12次逾期记录2笔的字段。模型只负责基于这些字段做规则提取和文本润色而不是在几千页原始材料里找答案。这样设计之后模型的幻觉空间被压缩到极小。因为所有事实性信息都是工具提供的结构化结果模型要做的是总结和解释不是回忆和猜测。工具调用规范一个信贷初审Agent会涉及文件解析、OCR识别、征信查询、财报解析、规则引擎、工作流写入等五六个工具。每个工具都要在Agent平台上注册写清楚三样东西入参Schema、出参Schema、权限范围。运行时统一负责参数校验、超时控制、失败重试Agent本身不直接跟工具端点打交道。这里有一个安全细节容易被忽略工具返回的内容不可信。征信报告里可能有一行文本是查询原因贷后管理如果模型把它当作指令来执行就是潜在的提示注入。所以Harness里要对工具返回内容做类型校验和标签化处理把数据和指令隔离开。4.3 金融级护栏可审计、不可篡改、人工兜底最后说三个金融机构Agent绕不开的护栏。全程可审计。一个Agent的每次运行从用户请求、状态流转、模型输入输出、工具调用参数到最终结论全部落日志保留完整链路。这既是监管要求也是后续效果优化的数据基础。结果可追溯。生成报告草稿时模型输出的每一个风险判断都要引用对应的证据片段。Harness层强制要求没有证据支撑的结论模型不能写进报告。做法是在prompt里把抽取到的结构化字段编号模型引用时只能引用编号对应的内容。人工留痕确认。关键业务决策必须人工确认Agent只提供草稿和参考意见。这不仅是合规要求也是业务侧愿意接受Agent的前提——先给人一个确认权人才会信任这个系统。5. 300个Agent一起跑起来之后真正的硬骨头才出现如果说前面几节解决的是怎么造出300个Agent这一节聊的是300个Agent上线之后怎么长期活下来。按照我自己的经验90%的Agent项目死在第二阶段而不是第一阶段。原因很简单Demo阶段你看单个Agent的效果生产阶段你看的是整个系统的稳定性、成本和可维护性。5.1 可观测性你得能回答Agent刚才为什么那么干传统应用的可观测性三板斧——日志、指标、链路追踪——放到Agent场景里远远不够。Agent的运行轨迹是非线性的它有思考、有工具调用、有分支判断、有上下文截断还可能嵌套子Agent。必须设计一套Agent专用追踪格式把下面这些信息串成一条完整的trace用户的原始输入和Agent的最终输出每一步的状态迁移及触发原因每次模型调用的输入token数、输出token数、延时、模型版本每次工具调用的参数、返回结果、时长、错误信息上下文窗口的使用率和截断情况每一段关键prompt的模板版本有了这套trace你才能回答业务方最常问的三个问题这笔业务为什么被拒了这个月的token成本为什么涨了30%昨天部署的新prompt到底有没有让效果变差我在实际项目里还有一个体会Agent的可观测性要跟评测联动。光有trace还不够你得有一套评测集——几百条覆盖典型场景的测试用例每次prompt或工具配置变更先在评测集上跑一遍回归比较成功率、准确率和输出格式合规率。没有评测集的Agent平台上线一次改版就像闭眼开车。5.2 成本治理token是新的服务器开销300个Agent跑起来之后成本的冲击比很多人预想的要猛。模型调用是按token计费的而Agent的调用链通常比传统API长得多。一次简单的客户问询可能要经历一次意图识别、一次关键词提取、一次答案生成甚至还要检索知识库再拼上下文算下来单次对话消耗的token可能轻松破万。成本治理要从这几个方向下手模型分级路由简单任务走小模型复杂任务走大模型别让所有Agent都挤在最贵的模型上。语义缓存高频问题命中缓存直接返回连模型都不用调。在客服场景里这可以省掉30%-50%的重复计算。上下文瘦身严格控制每次送入模型的上下文大小不相关的历史消息、过长的知识片段该截断就截断。按Agent核算成本把token消耗、模型调用量、工具调用量按Agent维度计量让业务方能看到自己那个Agent的支出。看不到成本就没有人关心优化。我见过最夸张的案例一个内部问答Agent因为prompt里塞了全文知识库单次调用烧掉了好几万token。最后查出来是开发图省事把检索结果全量拼进了上下文。所以我在设计Harness时有一条铁律上下文要有预算每个Agent都要设输出格式约束和长度上限。5.3 安全与权限Agent权限要最小化永远对工具说不Agent时代的攻击面比传统系统大得多因为Agent能拿着大模型这把刀去调用各种工具。原来的安全模型是人操作系统的权限现在突然多了一种可能攻击者通过聊天输入往Agent里注入指令让Agent去调高危工具。这就是Prompt注入攻击。防Prompt注入没有一劳永逸的办法但Harness可以把风险压到可控范围。具体做法工具权限最小化每个Agent的工具权限单独授权信贷Agent只能查信贷相关接口内部制度问答Agent根本不给写权限。双通道隔离用户输入的非可信内容和系统注入的可信指令分离让模型能区分哪些是用户说的话、哪些是系统规则。敏感操作二次确认凡是写操作比如发送通知、提交工单、修改数据一律经过人工确认或双因素验证。数据脱敏模型输入输出都要过一遍脱敏手机号、身份证号等敏感信息用掩码替代防止Agent把敏感数据拼进回复里。5.4 运营与迭代Agent不是上线就完事的最后聊组织。300个Agent上线之后最容易被低估的是持续的运营投入。传统软件的迭代是需求、开发、测试、发版节奏按月算。Agent的迭代是prompt调整、工具配置、评测回归、灰度上线节奏可能按周、按天算。我建议Agent平台必须有专门的平台团队负责四件事Agent健康度看板成功率、延迟、成本、用户反馈评分一目了然。变更管理prompt改动、工具配置改动也走版本管理和审批流程不能有人私下改配置。评测集维护每个Agent维护自己的评测集业务侧和科技侧一起审核评测用例。模型与工具升级协同模型版本更新、工具API变更平台团队统一评估影响并灰度切换。没有这套运营机制Agent项目规模越大熵增越厉害。三个月后你再看300个Agent的运行效果大概率已经参差不齐——有的常年没人管有的prompt被改了十几版没人review。到那时候再想治理成本比从第一天建立运营机制高出一个数量级。6. 从10个到300个的路线图哪些阶段必须经过最后给那些正准备把Agent规模化、但还在起点的团队一些路线建议。北京银行300个智能体代表的不是一下子建了300个Agent的堆量式扩张而是走了一条从试点到平台再到规模的典型路径。第一阶段挑3-5个高价值、低风险的场景做试点。这个阶段的核心目的不是追求效果惊艳而是验证Harness的基本盘状态机设计能不能跑通、模型网关稳不稳定、评测集建立流程顺不顺。我强烈建议第一个Agent选一个流程导向、容错率高的场景比如内部制度问答而不是直接上核心业务风控。第二阶段把试点中的公共能力抽象成平台能力。跑完三五个Agent你手上就有了第一手的共性清单哪些是每个Agent都要用的哪些是场景特有的。把前者沉淀到平台里——统一鉴权、统一日志、统一评测、统一模型接入。这个阶段的标志性事件是新上一个Agent的边际成本显著下降从几周缩到几天。第三阶段放开场景数量同时收紧治理。从几十个扩到几百个的阶段拼的完全是治理能力。每一个新Agent上线前都要过三关安全评审、评测集通过、成本预算确认。平台团队的角色从建设者变成守门人。同时开始建设Agent市场或目录让业务部门能自助浏览和申请已有的Agent能力避免重复建设。第四阶段让业务侧参与Agent的持续优化。300个Agent不可能全靠科技团队维护。到这一阶段要提供低代码的Agent配置界面让业务专家能在既定保护区里调整话术模板、优化提示词、维护知识库而平台团队专注于底层稳定性和模型效果。回到这篇博文的标题核心不是模型是Harness——这句话的真正意思是模型是商品Harness是手艺。商品会不断更新换代手艺才是一个组织真正的时间复利。我自己在这些年的Agent平台建设里踩过的最大的坑就是前期把过多注意力放在选哪个模型上后期才回头补Harness的课。如果让我重新来一遍我会在项目第一天就把Harness作为主体架构来规划把模型当成Harness里一个可以随时替换的组件。沿着这个思路走Agent规模化就不是一件碰运气的事而是一套可以设计、可以复制、可以持续优化的工程体系。模型负责聪明Harness负责靠谱而组织最终能scale的从来都是后者。