实际上手之前我们都觉得把大模型智能体接进金融交易流程最难的应该是模型效果。结果等项目真正推下去才发现模型本身的推理能力反而不是瓶颈周围那圈工程才是真正决定生死的东西。这圈工程在这个项目里我们内部叫它“AI Agent Harness Engineering”我试着翻译成“智能体接入工程”或者“智能体约束工程”核心就一句话在不替换Agent大脑的前提下把模型智能体安全、可控、可观测地接入到交易与风控链路里。这篇文章把我们在某买方机构交易前检查场景里做的整轮实践拆开讲包含为什么金融场景必须多做一个“接入层”、状态机怎么限制Agent自由动作、工具网关如何做权限兜底、时延预算怎么算、上线后踩过的坑以及一套可以直接复用的排查思路。适合正在或准备把大模型Agent引入金融生产系统的工程团队、量化团队和风控系统开发的同学也适合想了解“模型接入后到底还有哪些事”的产品和技术负责人。1. 为什么金融交易与风控需要多做一个“Agent接入工程”先说清楚一个现状很多团队在Demo阶段跑通Agent时体验是很爽的。喂一段需求Agent自动规划步骤、调工具、出结论看起来什么都会。但我们遇到过不止一次这个“什么都会”恰恰是金融系统最不能接受的东西。因为交易和风控链路对行为边界、时延、审计和可回滚性有极其硬性的要求随便让模型自由发挥后果不是报错而是资金风险。1.1 从“能跑通”到“敢上线”之间的差距我们在最初评估时把问题拆成了三层能不能算对、能不能接上、能不能兜底。“能不能算对”是模型能力问题现在大模型在阅读理解、归纳推理这些维度上进展很快大部分检查规则给它足够上下文就能给出大致结论。但“大致结论”在交易场景里是不够的你需要的是一份可以被复核、被追溯、被量化评估的结论。“能不能接上”是系统集成问题Agent要读持仓、读行情、读舆情、读交易记录这些数据散落在不同系统权限模型也不一致还有大量接口有频控和超时限制。Agent天生是“动态规划路径”的但交易系统接口更希望调用方是“可预期的、稳定的、每次都按声明格式来”的。“能不能兜底”是运行问题模型会幻觉、会漏参数、会突然调用一个没人预期的工具甚至会在时延超标后重复提交指令。金融系统最怕的不是慢而是不确定。宁可这次不放行也不能因为Agent行为不确定产生一笔脏交易或一个漏检的集中度超标。我们把这三层差距放在一起看结论就清晰了真正要解决的不是“让Agent更聪明”而是“让Agent在固定的框架里变聪明”。这个框架就是Harness。1.2 Harness Engineering 到底解决哪几类问题在我看来Harness Engineering在金融场景里核心解决了四件事第一是约束行为边界。Agent不能想做啥就做啥它只能在预设状态机里流转每个状态能调用的工具是白名单。想跳过人工复核直接提交状态机直接拒绝。第二是保证可观测性。模型内部推理我们无法完全控制但外部行为必须全部留痕。每次工具调用、每个参数、每段推理摘要、每条告警原因都要有结构化日志出问题时能一帧一帧回放。第三是提供可回滚性。Agent系统应该像一个可以随时拉闸的支路而不是接在主电路上的负载。如果模型效果劣化或者上游改造导致异常一键切换到人工检查流程业务不中断。第四是守住数据边界。金融数据非常敏感Agent在推理过程中会接触大量客户信息、持仓信息和交易细节。接入层必须在模型入口和出口都做脱敏与权限校验不能让原始数据随意出现在外发链路或历史记录里。这里可以打一个比方Agent像一个刚拿到赛车驾照的新司机你不可能直接把一级方程式赛车钥匙扔给他。Harness工程做的不是教他开车而是给这台车装上强制限速器、围栏赛道和远端熄火开关让他只能在可控范围内练习撞了也不至于冲出赛道。1.3 方案选型为什么不直接外接通用Agent框架这个决定花了不少时间。团队里最初有分歧一派觉得直接用现成的LangChain、LangGraph这类编排框架把Agent串联起来就行另一派主张基于业务场景做一层更重的自研接入层。两种路线我们各自做了原型验证最终放弃了“编排框架直连”的路线。原因很现实现成框架偏向于“怎么组织Agent的思维链和工具调用”对“金融系统需要的权限矩阵、审批流、幂等控制、时延SLA”基本没有接口。框架的默认执行模型是线性或DAG编排但交易前检查流程里存在大量分支条件、跨系统复核和人工介入点框架很难表达这种带强制节点的流程。可观测性方面框架能记录调用了哪些工具但记录不了“为什么能在当前状态下调用这个工具”以及“这个调用是否被权限层批准”。自研接入层并不需要重写整个模型链路。LLM推理可以继续用相对通用的服务或者统一网关Harness层只需要坐在模型与业务系统中间负责任务接收、状态控制、工具路由、权限校验、日志审计和结果回推。这个定位在架构上非常轻但在工程价值上极重。我对比过两种方案的差异做了个简单表格对比维度编排框架直连自研Harness接入层状态流程控制依赖框架内置状态扩展需大量定制可精确建模业务状态机工具权限调用即直连权限较粗请求先过权限网关逐参校验审计留痕有调用记录但缺上下文快照每次执行生成完整决策快照回滚能力需改造框架本身旁路设计可一键切换人工流程时延控制框架层无法干预可设置超时、降级、并行上限维护成本跟随上游框架升级有兼容负担自研代码完全可控当然自研也付出了一些代价比如初期开发和测试周期更长。但考虑到这个接入层将来会承载不止一个Agent而是多个不同业务域的智能体这笔投入是值得的。2. 核心模块拆解Agent与交易风控的接驳层这一部分重点展开Harness层的具体设计。我们的系统按功能拆成了四个核心模块状态机与指令路由、工具网关、数据链路与低时延、监督审计与可解释性。四个模块各管一段合在一起构成了Agent和生产系统之间的完整缓冲带。2.1 状态机与指令路由不允许Agent自由发挥交易前检查场景里Agent从收到任务到给出结论至少要走完五个状态闲置、决策中、复核等待、已放行、已拒绝。我们把这五个状态定义成一个严格的有向图状态之间只能按预设路径迁移Agent不可越级。举例来说Agent在“决策中”状态完成了分析想直接把结果标记为“已放行”。这个动作在状态机里是非法迁移因为缺失“复核等待”节点。系统会直接拦截Agent的输出返回异常提示并把这次非法动作记入审计日志。人工复核时会看到“Agent尝试跳过复核节点被拦截”这样的记录这本身就是一个风险信号。指令路由方面Agent能使用的动作全部来自白名单且每个动作绑定到特定状态。设计白名单时我们遵循了三个原则只读优先、原子粒度和参数约束。只读优先是指Agent默认只能调用查询类工具包括持仓查询、行情快照、指标计算、舆情检索任何写操作单独审批严禁以通用工具的面目出现。原子粒度是指每个动作只做一件事。例如“查询债券持仓集中度”和“查询某只债券最近舆情”是分开的两个工具不提供“综合分析”这类重量级工具。这样做的原因是如果Agent在一个工具里同时完成多件事出问题时就很难定位到底是哪一步错了。参数约束是指工具入参与出参都要做schema校验包含字段类型、枚举值、最大值最小值。比如“查询偏离度”的“偏离阈值”参数如果Agent传入一个字符串或负值系统直接报错而不会把异常值带到后续计算里。很多接触过Agent开发的同事会问一个问题限制得这么死Agent的“智能”不就浪费了吗我的理解相反Agent的智能判断应该体现在怎么组合这些原子动作来回答问题面上而不是体现在发现系统“居然还能调这个接口”。开放的自由度挪到工具组合层反而让Agent的行为模式更接近一个有经验的分析师。2.2 工具网关给Agent的每次调用加上限位器状态机约束的是流程工具网关约束的是每一次调用的物理权限。这是最后一道闸不管Agent推理到什么程度只要请求到达工具网关就会被执行严格的四步检查。第一步身份与权限校验。每个Agent实例有独立的服务账号服务信息内嵌在请求Header里。网关先验证调用方是否有当前状态的访问权限再校验目标工具是否在白名单中。一个在“决策中”状态的Agent即使它试图调用“复核通过”工具权限校验这步就会被挡下来。第二步参数Schema校验。我们把每个工具的参数定义成结构化SchemaAgent传来的参数必须严格匹配。校验范围包括字段完整性、类型匹配、枚举约束、数值边界。这里有一个很值得说的细节数值边界不是简单的最小最大值而是结合业务语义做合理性检查。比如“可以接受的最大单券集中度”这个参数语义上应该在0到1之间但如果Agent传入了0.98即便数值合法我们也会告警提示“参数偏离业务常见区间”因为这往往意味着Agent在推理过程中出现了指标含义混淆。第三步数据脱敏与范围裁剪。网关在真正访问底层系统之前会先根据业务上下文进行数据裁剪。比如Agent负责A组合的交易前检查那么它查询B组合的底层持仓明细请求就会被自动降级只返回汇总值不返回明细。这是对数据最小化原则在模型侧的落地实现。第四步频控与限流。模型在生产环境里有时会出现异常循环也就是在几秒钟内反复调用同一个工具。网关按“每10秒内单个Agent的调用总次数”和“单工具每分钟调用上限”两个维度做限流。超过阈值直接熔断当前Agent实例并通知告警平台。这套网关做下来最大的收益不是拦截了多少恶意请求而是让下游系统终于敢把接口开放给Agent了。因为接口所有者看到的接入方不再是“一个行为不确定的模型”而是一个受到与普通内部系统相同甚至更严格约束的“规范客户端”。2.3 数据链路与低时延设计金融交易场景对时延的要求和推荐系统不一样它不要求毫秒级但要求确定性。也就是说可以接受这个决策链路耗时3秒但不能接受它今天1秒、明天10秒——因为后面的交易系统是以确定的SLA来约束资金流转的。我们借用了解耦思想把Agent的数据读取路径做了冷热分离。热路径上是持仓快照、估值、当日行情引用指标这类高频数据提前从数据仓库同步到内部缓存服务Agent读取时直接走缓存链路简单可控。冷路径上是历史交易流水、长期舆情事件这类低频但体量大的数据仍由Agent按需通过工具网关读取。时延预算我们按节点做了硬性分配。从任务进入到Agent返回结果总预算5000毫秒。其中模型推理分配2000毫秒工具调用预留2000毫秒余下1000毫秒作为Harness层的处理与网络缓冲。工具调用2000毫秒并不是一次调用而是Agent在单轮任务中的累计调用时长我们会在Harness层做时间片扣除剩余预算耗尽时强制Agent进入收尾状态。这个设计有一个很实际的考虑如果不做时间片扣减Agent可能会在第一次工具调用上花掉1500毫秒导致后两次调用完全没有时间余量。而交易前检查场景里Agent往往需要先查持仓再查舆情再算偏离度三次调用是串联依赖的。时间片机制保证了整体预算不会被某个环节提前透支。另外我们对并发度也做了约束。单Agent实例承载的并发任务数上限是配置化的初期设置成1也就是同一时刻只能处理一个交易前检查任务。原因是模型推理和工具调用都依赖复杂上下文一旦并发超过一定数量推理时延会显著抬升反而拖慢整体吞吐。后来经过压测才逐步放开到3这已经是在当前硬件条件下稳定性和时延之间比较好的折中。2.4 监督审计与可解释性整个过程每一步都有留痕金融风控场景无法接受“模型说过这句话但我们不知道为什么”。所以我们从第一天就要求Agent的每一步系统都要能回答“发生了什么、为什么发生、影响是什么”。每次任务触发后Harness层会生成一条全局唯一的TraceID后续所有日志、工具调用、模型输出、状态迁移都带这个ID。围绕TraceID我们落四类数据输入快照任务进来那一刻的关键上下文包括涉及的组合代码、证券代码、检查指标参数。推理摘要模型在关键节点输出的决策理由摘要不是完整思维链而是压缩后的、可审计的业务判断依据。工具调用记录含工具名、请求参数、响应摘要、时延、权限校验结果。状态迁移日志记录每个状态节点的进入时间、离开时间、触发源。这四类数据汇总后存入审计系统保留期限按业务要求配置。人工复核时只需要在界面上输入TraceID系统直接展示Agent的完整决策路径。可解释性方面我们在模型输出格式上也做了约束。Agent最终给出的检查结论不是自由文本而是一个预定义的结构化结果每一条风险发现都必须包含风险类型、涉及标的、风险等级、触发原因、建议动作和置信度。Harness层会对这份结构化输出做二次校验发现字段缺失或置信度过低时会把任务标记为“需要人工复核”。实际业务中很多一线风控同事一开始对Agent结论有天然不信任感但看到每次结论后面都带着可追溯的记录和人工复核入口之后态度明显缓和了。我认为这才是金融系统里AI应用的常态不是让模型做唯一决策者而是让模型做完备的辅助信息提供者人永远保留最终判断权。3. 实操落地一个债券交易前检查Agent的完整接入过程前面讲了不少设计思路这部分说说具体怎么落地的。我们选的第一个场景是债券交易前检查主要做三件事持仓集中度检查、信用债舆情风险提示、交易偏离度预审。之所以选这个场景是因为它的规则相对明确、数据源集中、人工复核流程成熟非常适合作为Harness层的验证场景。3.1 业务目标与范围界定启动前我们和业务团队把边界谈得很清楚。这个Agent在第一个版本里只做辅助检查不直接连接交易系统不自动发送指令最终放行与否仍然由交易员和风控确认。哪怕将来模型能力再强在这个场景里我们也坚持“人的最后一公里”。三个检查项的业务定义分别是持仓集中度单券持仓市值占组合净值的比率是否超过内部风控阈值。信用债舆情针对持仓或拟入库的信用债最近N日内是否存在重大负面舆情事件。交易偏离度成交收益率与近期中债估值收益率的偏离是否超过预设基点阈值。范围明确之后就稳住了Agent的所有工具调用和数据请求都围绕这三个检查项展开不会额外引入无关数据源。3.2 冷启动用历史数据回放摸清效果底数我们没有直接接线上流量而是选择先用过去6个月的交易记录做离线回放。具体做法是把历史交易快照和当时的舆情数据按时间顺序重新灌给Agent让它在模拟状态下完成检查再和当时人工复核的结论做对比。回放阶段最核心的产出是三个指标检出率也就是Agent发现问题里面人工结论同样发现问题的比例误报率也就是Agent标记为风险但人工复核认为不构成风险的比例漏检率也就是人工结论里发现过问题但Agent没有提示的比例。初次回放的结果不算好看Agent对集中度超标这类数值型规则检出率很高但舆情风险判断的误报率一度达到35%左右。原因很快定位到舆情检索工具返回了大量无关噪声比如一些中性新闻被模型误解为负面信号。我们后来在工具层加了情感倾向预筛选并对负面事件类型做枚举约束误报率明显下降。这里有一个经验可以分享冷启动回放阶段尽量别只看汇总准确率一定要把Agent输出和人工结论不一致的样本逐条拉出来分析。每条不一致样本背后往往都是一个规则边界问题或工具数据质量问题这类问题的修复价值远高于调几个Prompt。回放期我们积累了两千多组对比样本在数据量和异常多样性基本见底之后才开始进入灰度环境测试。3.3 Harness层工作流配置与延迟预算工作流节点我们在前面状态机基础上做了业务化配置一共六个节点节点编号节点名称节点动作允许调用工具1任务接收解析检查请求初始化TraceID配置读取2数据准备读取持仓快照和基础参数持仓查询、参数查询3决策分析Agent完成集中度、舆情、偏离度判断舆情检索、估值查询、指标计算4复核等待结构化结果进入人工复核队列无工具权限5终态放行人工确认后释放结果状态提交6终态拒绝拒绝并记录原因状态提交配置这个工作流时我们特别注意了“提交类工具只在终态可用”这一点。Agent在决策分析阶段无论生成什么内容都只能写“建议放行”或“建议拒绝”无权调用终态提交。这是状态机设计中最关键的一层保护。延迟预算按前面提到的5000毫秒进行硬编码。Harness层会在任务开始前检查当前系统负载如果模型服务排队较长直接返回“系统繁忙请稍后重试”而不是让任务进入半执行状态。这种主动拒绝策略也减少了大量下游异常。Prompt设计上我们没有让模型自由发挥而是提供了严格的任务说明框架包含角色定义、可用工具清单、输出JSON Schema和禁止事项四部分。禁止事项明确写出不得提交终态、不得给出超出工具结果范围的判断、不得跳过数据准备阶段。3.4 灰度切换与一键回滚机制灰度我们分了三个阶段影子模式、建议模式、闸门模式。影子模式下Agent的检查结果与人工结果并行输出但任何结论都不影响业务动作。我们在这个阶段主要是验证链路稳定性和样本覆盖度也顺便让业务慢慢习惯看Agent的结论。建议模式下Agent结果会推送给交易员和风控员作为检查参考但系统不会因为Agent拒绝而卡住业务。如果人工判断与Agent结论不一致系统会记录分歧数据用于后续模型迭代。闸门模式下只有Agent检查通过且人工确认的请求才能继续流转。逻辑上是把Agent做成前置闸门但不是唯一闸门。回滚机制我们做成了“支路开关”模式。整个Agent链路在架构上作为业务主流程的旁路存在核心交易链路完全依赖人工检查流程运行。所以回滚的动作很轻在发布开关页面把当前场景的状态从“闸门模式”改成“关闭”Agent链路立即不再接收新任务线上业务自动回到纯人工模式。这个设计在后来一次模型服务异常中派上了用场。当时模型服务因上游依赖故障出现连续超时交易前检查队列肉眼可见地积压我们直接在开关平台把Agent链路切到关闭业务恢复顺畅整个过程不到两分钟也没有任何交易数据受到影响。3.5 上线后的运行指标盘点运行一段时间后我们统计了这批核心指标指标名称数值说明平均决策时延2.3秒含模型推理与工具调用集中度检查检出率100%阈值类规则完全匹配舆情风险误报率7%经过舆情预筛选后显著下降交易偏离度提示准确率86%部分边界案例仍依赖人工人工采纳率81%交易员/风控接受Agent建议并据此操作的比例其中人工采纳率是我最看重的指标。它反映的不是模型技术上有多强而是这套含Harness层的系统在真实业务流程中是否被信任。81%的采纳率意味着业务团队已经把它当成一个有参考价值的工具而不是一个需要额外提防的黑盒。4. 常见问题与排查技巧实录Agent系统上线后真正花时间的地方在跑稳定性和排障上。我们遇到过几个比较典型的问题这里按“现象、排查过程、解决办法”的方式记录后面再整理成速查表。4.1 幻觉与错误调用的两类典型事故第一类事故发生在一次舆情风险检查中。单只债券关联的负面信息很少Agent在工具里没有检索到足够的负面新闻却依然给出“存在舆情风险”的高置信度结论理由描述是“基于近期市场情绪综合判断”。这种幻觉对风控场景来说很危险因为它会让信用债被误阻拦干扰交易执行。排查时打开TraceID回放我们发现问题根源在于Prompt里对舆情风险的定义过宽。模型把“无新闻”默认为“信息不对称风险”而业务方定义的是“有明确负面事件才算风险”。修复方案很直接把舆情风险判断规则改成严格枚举触发事件类型并增加“未检索到负面事件时默认无风险”的显式指令。第二类事故更有意思。Agent在一次集中度检查中正确识别出某组合单券集中度超过阈值但在后续偏离度检查时把“偏离50基点”这个数值错误地复述成了“偏离50%”。下游的指标计算工具收到参数后直接校验失败任务进入异常分支最终被标记为需要人工复核。这次事故没有造成脏数据但暴露了一个关键问题Agent在多步推理时容易出现中间数值错乱。我们随后在Harness层加了一个工具参数回填机制——Agent在调用工具时所有涉及业务阈值的参数都必须从上一步数据查询结果中显式引用不能由模型凭记忆输出。相当于给工具调用链做了一个参数血缘校验。4.2 超时与并发压垮链路的处理上线初期我们遇到过模型服务整体响应变慢的情况。现象是单个任务的推理时延从平均1秒飙到6秒触发Harness层超时熔断任务大量失败。排查后发现根因是下游某次批量数据刷新任务占用了与模型服务共享的底层存储IO资源导致模型推理服务也被连带影响。我们做了两件事第一是把模型服务的存储与业务数据存储进行物理隔离避免相互干扰。第二是在Harness层增加“服务健康度预检”逻辑。任务开始前先访问模型服务的健康检查接口如果响应时延超过阈值就直接拒单不让任务进入半执行状态。另外我们把单个Agent实例的并发上限严格限制住。之前并发数开到5时系统整体吞吐反而下降原因是模型推理需要大量内存和显存并发过多会导致排队和GC频繁。压测后最终定位在并发3是一个相对优解。如果你的场景与模型部署环境类似建议也做一轮并发压测别照搬默认参数。4.3 监控与审计盲区补齐初期审计系统有个盲区记录了Agent最终调用了哪些工具但没有记录“调用被权限校验模块拒绝”的日志。直到一次复盘时我们才发现Agent曾经在某个时间段内连续发出非法调用请求而日志里完全没有痕迹因为那些请求在权限校验阶段就被拦截了我们当时把这类请求静默丢弃了。修复方案是增加一条“拒绝审计流”所有被状态机或权限模块拦截的请求统一写到独立的拒绝日志并且按小时汇总触发告警。拒绝率高说明Agent在频繁尝试越权或误用工具这本身就需要重点观察。这个“拒绝审计流”在后续运维中帮我们发现了不少问题。有一次Agent版本升级后Prompt里工具描述没做同步更新导致模型反复用旧参数格式调用新工具拒绝日志半小时就刷了几百条。如果没有这条流这个Bug很可能到上线后才被发现。4.4 高频问题速查表现象可能原因排查方向解决参考Agent结论与业务判断不一致规则定义语义边界不清晰回放TraceID对比推理摘要与工具返回收紧Prompt定义或改规则为枚举触发工具调用频繁被拒工具Schema与模型预期不匹配查看拒绝审计日志同步更新工具描述或放宽参数约束任务平均时延升高底层数据源变慢或模型排队检查存储IO、模型服务健康度资源隔离、调低并发数舆情误报率偏高数据源噪声大或情感预判不足抽样回放舆情检索原文增加情感预筛选和类型枚举模型重复调用同一工具Agent陷入循环看限流日志和状态机停留时长启动调用频控熔断和状态超时结构化输出缺字段输出Schema约束不严查看模型原始输出与解析错误日志强化JSON Schema和重试解析机制5. 这套接入工程思路的复用边界与个人总结项目走到这里我最大的感触是大模型Agent在金融场景里的价值不取决于模型本身有多“聪明”而取决于外围工程有多“不智能地守住底线”。这句话听起来有点绕但做过的团队应该能明白——模型幻觉、行为不可控根本不是新闻重要的是系统能不能在失控之前拦住它并且在失控之后说得清楚发生了什么。目前这套Harness思路在我们内部已经沉淀成一个可复用的接入框架新场景接入时只需要配置状态机节点、挂接工具白名单、定义输出Schema大约一两周就能完成一个业务域的原型接入。如果你所在的团队也在评估类似项目我建议优先选择规则清晰、数据集中、人工复核链路成熟的场景起步把工程问题打透以后再拓展到更开放的场景。还有一个经验值得分享做这类项目时一定要拉上业务和风控同事深度参与不是让他们验收结果而是让他们从定义问题的第一天就进项目组。很多关键的风险边界和业务语义只有他们能讲清楚。技术侧盲目自信地定义规则最后大概率要在回放阶段大规模返工。后续我们自己也在观察几个扩展方向多Agent协作场景里接入层的权限模型怎么重新设计、模型迭代时如何做自动化回归测试、以及Harness层能否沉淀为跨团队共用的服务。这些方向现在都还是半成品等有更完整的结论之后我再分享。