实际上手之前我们都觉得，把大模型智能体接进金融交易流程，最难的应该是模型效果。结果等项目真正推下去才发现，模型本身的推理能力反而不是瓶颈，周围那圈工程才是真正决定生死的东西。这圈工程，在这个项目里我们内部叫它“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层只需要坐在模型与业务系统中间，负责任务接收、状态控制、工具路由、权限校验、日志审计和结果回推。这个定位在架构上非常轻，但在工程价值上极重。

我对比过两种方案的差异，做了个简单表格：

当然自研也付出了一些代价，比如初期开发和测试周期更长。但考虑到这个接入层将来会承载不止一个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校验。我们把每个工具的参数定义成结构化Schema，Agent传来的参数必须严格匹配。校验范围包括字段完整性、类型匹配、枚举约束、数值边界。这里有一个很值得说的细节：数值边界不是简单的最小最大值，而是结合业务语义做合理性检查。比如“可以接受的最大单券集中度”这个参数，语义上应该在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层工作流配置与延迟预算

工作流节点我们在前面状态机基础上做了业务化配置，一共六个节点：

配置这个工作流时我们特别注意了“提交类工具只在终态可用”这一点。Agent在决策分析阶段无论生成什么内容，都只能写“建议放行”或“建议拒绝”，无权调用终态提交。这是状态机设计中最关键的一层保护。

延迟预算按前面提到的5000毫秒进行硬编码。Harness层会在任务开始前检查当前系统负载，如果模型服务排队较长，直接返回“系统繁忙请稍后重试”，而不是让任务进入半执行状态。这种主动拒绝策略也减少了大量下游异常。

Prompt设计上我们没有让模型自由发挥，而是提供了严格的任务说明框架，包含角色定义、可用工具清单、输出JSON Schema和禁止事项四部分。禁止事项明确写出：不得提交终态、不得给出超出工具结果范围的判断、不得跳过数据准备阶段。

3.4 灰度切换与一键回滚机制

灰度我们分了三个阶段：影子模式、建议模式、闸门模式。

影子模式下，Agent的检查结果与人工结果并行输出，但任何结论都不影响业务动作。我们在这个阶段主要是验证链路稳定性和样本覆盖度，也顺便让业务慢慢习惯看Agent的结论。

建议模式下，Agent结果会推送给交易员和风控员作为检查参考，但系统不会因为Agent拒绝而卡住业务。如果人工判断与Agent结论不一致，系统会记录分歧数据，用于后续模型迭代。

闸门模式下，只有Agent检查通过且人工确认的请求才能继续流转。逻辑上是把Agent做成前置闸门，但不是唯一闸门。

回滚机制我们做成了“支路开关”模式。整个Agent链路在架构上作为业务主流程的旁路存在，核心交易链路完全依赖人工检查流程运行。所以回滚的动作很轻：在发布开关页面把当前场景的状态从“闸门模式”改成“关闭”，Agent链路立即不再接收新任务，线上业务自动回到纯人工模式。

这个设计在后来一次模型服务异常中派上了用场。当时模型服务因上游依赖故障出现连续超时，交易前检查队列肉眼可见地积压，我们直接在开关平台把Agent链路切到关闭，业务恢复顺畅，整个过程不到两分钟，也没有任何交易数据受到影响。

3.5 上线后的运行指标盘点

运行一段时间后，我们统计了这批核心指标：

其中人工采纳率是我最看重的指标。它反映的不是模型技术上有多强，而是这套含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 高频问题速查表

5. 这套接入工程思路的复用边界与个人总结

项目走到这里，我最大的感触是：大模型Agent在金融场景里的价值，不取决于模型本身有多“聪明”，而取决于外围工程有多“不智能地守住底线”。这句话听起来有点绕，但做过的团队应该能明白——模型幻觉、行为不可控根本不是新闻，重要的是系统能不能在失控之前拦住它，并且在失控之后说得清楚发生了什么。

目前这套Harness思路在我们内部已经沉淀成一个可复用的接入框架，新场景接入时只需要配置状态机节点、挂接工具白名单、定义输出Schema，大约一两周就能完成一个业务域的原型接入。如果你所在的团队也在评估类似项目，我建议优先选择规则清晰、数据集中、人工复核链路成熟的场景起步，把工程问题打透以后再拓展到更开放的场景。

还有一个经验值得分享：做这类项目时一定要拉上业务和风控同事深度参与，不是让他们验收结果，而是让他们从定义问题的第一天就进项目组。很多关键的风险边界和业务语义，只有他们能讲清楚。技术侧盲目自信地定义规则，最后大概率要在回放阶段大规模返工。

后续我们自己也在观察几个扩展方向：多Agent协作场景里接入层的权限模型怎么重新设计、模型迭代时如何做自动化回归测试、以及Harness层能否沉淀为跨团队共用的服务。这些方向现在都还是半成品，等有更完整的结论之后我再分享。