1. 金融行业AI Agent的落地现状与分类逻辑金融行业对AI Agent的态度这两年经历了一个非常明显的转折。前两年大家还在观望讨论“大模型能不能用在金融场景”到了2025年下半年几乎所有的券商、银行、保险科技团队都在问同一个问题怎么把Agent真正塞进业务流程里而不是停留在Demo阶段。我自己参与过几个金融Agent项目从智能投研助手到信贷审批辅助踩过的坑比想象中多得多。这篇文章想聊的不是“Agent有多厉害”而是一个更务实的问题金融行业的Agent到底该怎么分类以及如何用最小的目标组合快速验证价值。先说一个基本判断金融行业是所有行业里对AI Agent要求最苛刻的领域之一。原因很简单金融业务天然带有强合规、强审计、强准确性三重约束。一个在电商场景里能容忍90%准确率的Agent放到金融场景里可能连上线资格都没有。所以当我们讨论金融Agent分类时不能照搬通用Agent的分类框架必须结合金融业务的实际约束来重新切分。1.1 为什么通用Agent分类在金融场景会失效市面上常见的Agent分类方式大致有这么几种按交互形态分对话式、任务式、自主式按技术架构分ReAct、Plan-and-Execute、多Agent协作按部署方式分云端、本地、混合。这些分类在技术讨论时有用但一旦落到金融业务里就会出现一个尴尬的情况——同一个Agent在不同业务环节里的风险等级完全不同。举个例子一个用于“查询账户余额”的Agent和一个用于“执行转账”的Agent从技术架构上看可能都是ReAct模式但它们的合规要求、审计要求、容错要求差了十万八千里。前者出错顶多是用户体验问题后者出错就是资金安全问题。所以金融Agent的分类第一维度应该是业务风险等级而不是技术实现方式。我个人的经验是金融Agent的分类应该沿着两条轴来切一条是业务链路位置获客、风控、投研、运营、客服、合规另一条是决策自主度只读、建议、执行、自主决策。这两条轴交叉出来的格子才是真正有意义的分类单元。1.2 金融Agent的六类核心应用场景结合我实际接触过的项目和行业公开案例金融行业的Agent应用大致可以归为六类类别典型场景决策自主度风险等级信息检索类研报问答、法规查询、产品对比只读低分析建议类投研辅助、风险评估、客户画像建议中流程自动化类报表生成、数据录入、对账执行中客户交互类智能客服、投顾对话、营销触达建议执行中高交易执行类下单、调仓、资金划转执行高合规审查类反洗钱、异常检测、合规检查建议高这个分类的价值在于它直接决定了你该用什么技术方案、什么验证标准、什么上线流程。比如信息检索类Agent用RAG加一个简单的ReAct循环就够了验证时重点看召回率和准确性而交易执行类Agent必须有多层确认机制、完整的审计日志、以及严格的权限隔离验证时要做大量的异常场景测试。1.3 最小目标组合的核心思路所谓“最小目标组合”我的理解是用最少的Agent数量和最简的技术栈覆盖一个完整的业务闭环。很多团队一上来就想做“全能金融Agent”结果做了半年还在调prompt。更务实的做法是先找到一个业务价值明确、风险可控、数据可得的场景用一到两个Agent跑通闭环再逐步扩展。这里有个关键原则最小目标组合不是功能最少而是验证路径最短。你要能在两周内让业务方看到效果一个月内拿到可量化的指标这样才能持续获得资源投入。我见过太多项目因为验证周期太长做到一半就被砍掉了。2. 核心技术点拆解Harness、Echo、Delta在金融Agent中的角色热词里反复出现的Harness、Echo、Delta其实指向了金融Agent工程化的三个关键层面。这三个词在不同语境下含义不同但在Agent工程领域它们分别对应测试验证框架、反馈回路机制、增量更新策略。下面逐个拆解。2.1 HarnessAgent的测试与验证框架Harness在软件工程里原本指“测试夹具”在Agent领域它指的是一套用于评估Agent行为是否符合预期的测试框架。金融场景对Harness的需求尤其强烈因为金融Agent的输出不能只看“像不像”还要看“对不对”、“合不合规”。一个完整的金融Agent Harness通常包含这几个部分测试用例集覆盖正常场景、边界场景、异常场景。比如一个投研Agent测试用例要包括标准查询、模糊查询、多条件组合查询、以及故意输入错误信息时的表现。评估指标准确性、召回率、响应时间、合规通过率。金融场景还要加上“拒答率”——该拒绝的时候能不能拒绝。回归测试机制每次修改prompt或更换模型后自动跑一遍全量测试用例确保没有退化。人工审核接口对于高风险场景Harness要能标记出需要人工复核的case。我自己的做法是用Python写一个轻量的Harness框架核心就是一个evaluate函数输入是Agent的调用接口和测试用例集输出是各项指标的汇总报告。这样每次迭代都能快速看到效果变化。# 简化的Harness评估框架示意 def evaluate_agent(agent_fn, test_cases, metrics): results [] for case in test_cases: output agent_fn(case[input]) score {} for metric_name, metric_fn in metrics.items(): score[metric_name] metric_fn(output, case[expected]) results.append({case: case[id], output: output, score: score}) return summarize(results)这个框架看起来简单但实际用起来非常有效。关键是要把测试用例设计好尤其是金融场景的边界case往往能暴露出Agent的致命问题。2.2 Echo反馈回路与状态同步机制Echo在Agent语境下我理解它指的是反馈回路——Agent执行动作后系统要把结果“回声”给Agent让它知道发生了什么从而调整后续行为。这在金融场景里特别重要因为金融业务往往是多步骤的每一步的结果都会影响下一步的决策。举个实际例子一个用于“客户风险评估”的Agent它的工作流程可能是读取客户资料 → 查询历史交易 → 计算风险指标 → 生成评估报告。如果中间某一步查询失败Agent需要知道这个失败并决定是重试、跳过还是终止。这就是Echo机制在起作用。实现Echo机制的关键点状态管理用一个显式的状态对象记录每一步的执行结果而不是依赖Agent的隐式记忆。错误传播错误信息要结构化地传递给Agent而不是简单的异常抛出。超时与重试金融数据接口经常有超时Agent要能区分“暂时失败”和“永久失败”。我在项目里通常会用LangGraph来管理这种状态流转它的StateGraph天然适合表达多步骤、有分支的金融业务流程。每个节点执行完后状态更新会自动“回声”到图中下一个节点就能看到最新的状态。2.3 Delta增量更新与差异计算Delta在金融Agent里有两个层面的含义。第一个层面是数据层面的增量更新——金融数据变化频繁Agent不能每次都全量拉取要能识别哪些数据变了只更新变化部分。第二个层面是模型层面的增量学习——Agent要根据新的反馈不断调整自己的行为策略。数据层面的Delta比较好理解就是维护一个“上次同步时间戳”每次只拉取增量数据。但金融场景有个坑很多金融数据是会修正的比如财报数据可能在发布后有小幅调整。所以Delta机制不能只看时间戳还要做内容比对识别出被修正的记录。模型层面的Delta更微妙。金融Agent的行为策略往往需要根据业务反馈微调比如某个类型的查询之前总是回答得太啰嗦业务方反馈后要调整。这种调整不一定要重新训练模型很多时候通过prompt的增量修改加few-shot示例的动态更新就能解决。我的做法是维护一个“反馈-调整”映射表每次收到反馈就更新对应的prompt片段或示例集。2.4 三者如何协同一个完整的金融Agent工程闭环把Harness、Echo、Delta串起来就形成了一个完整的工程闭环Harness负责定义“什么是好的行为”提供测试用例和评估指标。Echo负责在运行时收集“实际发生了什么”把执行结果反馈给Agent和开发者。Delta负责根据反馈“调整什么”增量更新数据、prompt或策略。这个闭环跑通后Agent的迭代速度会快很多。我自己的项目里从最初的两周一次迭代缩短到了两三天一次。关键就是这三个机制都自动化了不需要每次手动重新测试、手动分析日志、手动调整配置。3. 金融Agent最小目标组合的实操搭建理论讲完了接下来是实操部分。我会以一个具体的场景为例展示如何用最小的目标组合搭建一个金融Agent。这个场景是“上市公司财报问答助手”——业务价值明确、数据可得、风险可控非常适合作为金融Agent的入门项目。3.1 场景选择与目标定义为什么选财报问答三个理由第一财报数据是公开的获取成本低第二问答场景的交互简单不需要复杂的多轮规划第三效果容易量化准确率、召回率都能算清楚。目标定义要具体给定一份上市公司财报PDF用户用自然语言提问Agent能准确回答并标注信息来源页码。这个目标里包含了三个可验证的指标回答准确性、来源可追溯性、响应时间。我建议把目标再拆细一点基础目标能回答财报中的数值型问题营收、利润、增长率等准确率≥95%。进阶目标能回答比较型问题同比、环比、行业对比准确率≥85%。高级目标能回答分析型问题变化原因、趋势判断准确率≥70%。先做基础目标跑通了再做进阶。不要一上来就追求分析型问题那个难度是指数级上升的。3.2 技术栈选型与理由技术栈的选择要遵循“够用就好”的原则。我的推荐组合是框架LangChain LangGraph。LangChain负责工具调用和LLM交互LangGraph负责状态流转。两者配合能覆盖大部分金融Agent场景。向量库Chroma或Milvus。Chroma轻量适合快速验证Milvus性能好适合生产环境。LLM根据预算选。国内可选DeepSeek、通义千问国外可选GPT-4或Claude。金融场景建议用支持长上下文的模型因为财报往往很长。PDF解析PyMuPDF或pdfplumber。PyMuPDF速度快pdfplumber表格处理好。数据接口如果需要实时行情可以用Wind的Python接口或免费的AKShare。为什么不直接用扣子这类平台扣子确实上手快但金融场景往往需要深度定制比如自定义的合规检查、特殊的审计日志格式。用代码框架虽然前期慢一点但后期扩展性好很多。我自己的经验是先用扣子做原型验证确认价值后再用代码重构。3.3 核心模块实现从PDF解析到问答生成整个流程分四步PDF解析 → 文本切分与向量化 → 检索 → 生成回答。第一步PDF解析。财报PDF的难点是表格多、格式复杂。我的做法是用PyMuPDF提取文本用pdfplumber单独提取表格然后把两者合并。表格数据要保留结构信息不能简单转成文本。import fitz # PyMuPDF import pdfplumber def parse_financial_pdf(pdf_path): # 提取文本 doc fitz.open(pdf_path) text_blocks [] for page_num, page in enumerate(doc): blocks page.get_text(blocks) for block in blocks: text_blocks.append({ page: page_num 1, text: block[4], type: text }) # 提取表格 with pdfplumber.open(pdf_path) as pdf: for page_num, page in enumerate(pdf.pages): tables page.extract_tables() for table in tables: text_blocks.append({ page: page_num 1, text: table_to_markdown(table), type: table }) return text_blocks第二步文本切分与向量化。金融文本的切分不能简单按字数切要按语义单元切。我的做法是先按章节切再按段落切表格单独作为一个单元。每个单元保留页码信息方便后续溯源。第三步检索。用混合检索——向量检索加关键词检索。金融场景里数值和专有名词的精确匹配很重要纯向量检索容易漏掉。我的做法是先用向量检索召回Top 20再用BM25做关键词过滤最后合并去重。第四步生成回答。Prompt的设计是关键。我的模板大致是这样的你是一个金融财报分析助手。请根据以下财报内容回答问题。 要求 1. 只使用提供的财报内容回答不要编造数据。 2. 如果财报中没有相关信息明确说“财报中未找到相关信息”。 3. 回答中标注信息来源的页码。 4. 数值型回答要注明单位。 财报内容 {context} 问题{question}这个模板看起来简单但每一条要求都是踩过坑之后加的。比如“不要编造数据”这条是因为早期版本经常把不同公司的数据混在一起“标注页码”这条是因为业务方要求可追溯。3.4 验证与迭代用Harness跑通第一轮测试搭好之后第一件事不是上线而是跑Harness。我通常会准备50到100个测试用例覆盖各种问题类型。测试用例的格式是这样的test_cases [ { id: q001, input: 2023年营业收入是多少, expected: {value: XXX亿元, page: 15}, type: 数值型 }, { id: q002, input: 净利润同比增长多少, expected: {value: XX%, page: 16}, type: 计算型 }, # ... ]跑完第一轮你大概率会发现准确率只有60%到70%。别慌这是正常的。重点看错误类型是检索没召回还是生成时理解错了还是PDF解析丢数据了。针对性地修通常两三轮就能到90%以上。我自己的经验是检索问题占错误的70%。所以优化重点应该放在检索环节而不是急着换更大的模型。检索优化包括调整切分粒度、增加关键词索引、优化向量模型选择。4. 常见问题与排查技巧实录这一部分是我在实际项目中积累的问题排查经验都是真金白银换来的。4.1 检索召回率低怎么办这是最常见的问题。表现是明明财报里有答案Agent却说“未找到”。排查思路先看切分是不是把关键信息切碎了比如一个表格被切成了好几段检索时只召回了半段。解决办法是表格不切分或者切分后保留表头信息。再看向量模型通用向量模型对金融术语的理解可能不够。可以试试用金融语料微调过的模型或者直接用关键词检索兜底。最后看查询改写用户的问题可能和财报的表述方式差异很大。比如用户问“赚了多少钱”财报写的是“归属于母公司股东的净利润”。加一个查询改写步骤用LLM把用户问题转成更接近财报表述的形式。4.2 数值计算容易出错金融问答里经常涉及计算比如“同比增长率”。LLM直接算数很容易出错。我的做法是不让LLM算让代码算。Agent识别出需要计算时调用一个计算工具把数值传进去返回结果。def calculate_growth(current, previous): if previous 0: return None return (current - previous) / previous * 100这个工具很简单但能避免大量计算错误。关键是Agent要能正确识别“什么时候需要计算”这需要在prompt里明确定义。4.3 多轮对话中的上下文丢失金融问答往往是多轮的比如用户先问“营收多少”再问“那利润呢”。如果Agent不保留上下文第二轮就不知道“那”指的是什么。解决办法是用LangGraph维护一个对话状态把历史问答对作为上下文传给LLM。但要注意控制上下文长度太长了会影响性能。我的做法是只保留最近三轮的问答对更早的做摘要压缩。这样既保留了上下文又不会让prompt过长。4.4 合规与审计要求怎么满足金融场景的合规要求不能忽视。我的做法是所有Agent的输出都记录日志包括输入、检索到的内容、生成的回答、使用的模型版本。高风险操作加人工确认。比如涉及具体投资建议的Agent只生成草稿由人工审核后发送。定期做合规审查。用Harness跑一批合规测试用例确保Agent不会输出违规内容。这里有个坑很多团队一开始不做日志等出了问题才想起来要查结果什么都查不到。所以日志要从第一天就做而且要结构化存储方便后续分析。4.5 常见问题速查表问题现象可能原因排查方向解决思路回答“未找到”检索召回失败检查切分粒度、向量模型调整切分、加关键词检索数值错误LLM计算不准检查是否调用了计算工具强制走代码计算答非所问Prompt理解偏差检查Prompt模板加few-shot示例响应太慢检索或生成耗时分阶段计时优化检索、换更快的模型上下文丢失状态管理缺失检查对话状态维护用LangGraph管理状态输出违规内容合规检查缺失检查输出过滤加合规过滤层4.6 几个容易被忽视的细节第一个细节是PDF解析的页码映射。很多PDF解析工具返回的页码和实际PDF页码不一致导致溯源时找不到。解决办法是解析时记录原始页码不要用解析后的索引。第二个细节是表格的跨页问题。财报里的大表格经常跨页解析时要能识别并合并。这个用pdfplumber的table设置可以解决但需要调参。第三个细节是单位统一。财报里有的地方用“万元”有的用“亿元”Agent回答时要统一单位否则用户会混淆。我的做法是在解析阶段就把所有数值统一转成“元”生成回答时再根据数值大小自动选择合适单位。第四个细节是时间范围。用户问“营收多少”时可能指的是最新一期也可能指特定年份。Agent要能根据上下文判断判断不了时要主动询问。这个在prompt里加一条“如果问题中的时间范围不明确请询问用户”就能解决。5. 从最小组合到规模化扩展的路径跑通最小目标组合后下一步是怎么扩展。我的建议是沿着“场景扩展”和“能力扩展”两条线走。场景扩展是指从财报问答扩展到公告问答、研报问答、法规问答。这些场景的技术架构类似主要是数据源和Prompt的调整。每扩展一个场景Harness的测试用例集就要相应扩充。能力扩展是指从单轮问答扩展到多轮对话、从只读扩展到建议、从单Agent扩展到多Agent协作。每扩展一层能力Echo和Delta机制就要相应加强。比如多Agent协作时状态管理会更复杂需要更精细的Echo机制。我自己的节奏是第一个月跑通单场景单Agent第二到三个月扩展到三到五个场景第四个月开始尝试多Agent协作。这个节奏不一定适合所有团队但大方向是“先纵向做深再横向做宽”。最后分享一个我在实际项目中的体会金融Agent的价值不在于技术多先进而在于能不能稳定地解决一个具体的业务问题。我见过太多团队追求最新的框架、最大的模型结果连最基本的问答准确率都保证不了。反而是那些老老实实做数据清洗、做测试用例、做日志记录的团队最后做出了真正能用的产品。技术是手段业务价值才是目的。