企业官网建设流程全解析

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，第一步把编排搞定了，第二步把记忆搞定了，到了第三步发现自己完全不知道线上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 六层架构，每一层都有明确边界

整体上，我习惯把它分成下面六层，从上到下依次是：

1. 接入与体验层：面向员工、客户、管理者的各类入口，包括手机App、网页端、企业微信、柜面系统里的对话界面、工单入口。
2. 智能体运行时层：Agent的注册、启停、编排、状态流转、任务调度，是整个平台的中枢。
3. 模型网关层：统一封装多个模型服务，做模型路由、负载均衡、私有化模型与公有云模型的桥接。
4. 工具与数据服务层：把银行内部的查询、录入、审批、报表等能力以标准API的方式暴露给Agent。
5. 知识中心层：非结构化文档、制度库、产品库、向量索引的统一管理和检索服务。
6. 治理与安全底座：横跨所有层的横向能力，包括鉴权、审计、监控、脱敏、评测、成本核算。

这里最关键的判断是：**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直接给贷款批不批的结论，而是把流程拆成四步：

1. 材料完整性核验：根据业务规则检查必备材料是否齐全。
2. 关键信息抽取：从财报、征信报告中提取营收、负债、逾期记录等结构化字段。
3. 初步风险标记：根据预设规则，标记出明显异常项，比如征信查询次数过多、短期负债激增。
4. 生成初审意见草稿：给人工复核岗提供一份初审报告草稿，包含依据和结论。

这四步里，真正需要"智能"的其实只有第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平台必须有专门的平台团队，负责四件事：

1. Agent健康度看板：成功率、延迟、成本、用户反馈评分一目了然。
2. 变更管理：prompt改动、工具配置改动也走版本管理和审批流程，不能有人私下改配置。
3. 评测集维护：每个Agent维护自己的评测集，业务侧和科技侧一起审核评测用例。
4. 模型与工具升级协同：模型版本更新、工具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的，从来都是后者。