金融 harness 怎么设计与实施：从 FinanceHarness 的分层栈、时点契约与五条可迁移原则，到银行资产保全的落地次序

harness 是一阶杠杆：论文自报，同一个开源权重基座，只改专用 harness 设计，rubric 总分从 25.3% 升到 32.4%

但同一份材料也给出天花板：论文自报，即便配上最强模型，FinanceGym 得分仍低于 45%——该基准远未饱和

对银行真正可迁移的不是那 7.1 个百分点，而是三样东西：唯一硬规则、可溯源的数据流、能力声明与授权的分离

必须说清边界：该论文研究的是投研式金融深度研究，通篇不涉及资产保全、不良资产、清收或诉讼

因此本文全部银行映射均为本文分析；次序是——先定硬规则，再建检索层，最后才谈模型与规模

素材说明：来源仅 9 份已归档文本。来源 1、2 为 arXiv:2607.27853（预印本，2026-07-30，cs.CL／cs.AI／q-fin.CP，11 位作者，署名 Google Cloud AI Research 与 UCLA）：未经同行评议，其 25.3%→32.4%、Opus-5 低于 45%、82% 专家通过率、Qwen3.6-27B 等全部数字均为论文自身报告、未经独立复现。来源 3 为仓库 README（项目方自述）、4 为 GitHub API 元数据（179★／Apache-2.0／created 2026-08-03／pushed 2026-08-22，客观、时点快照）、5 为官方基准站（项目方站点）、6 为 Microsoft Learn（厂商文档）、7 为 AgentScope Java 博客（厂商／社区技术博客）、8 为 MCP 官方兴趣组章程（标准组织官方文档）、9 为腾讯云开发者社区文章（技术社区二手）——其中 52.8%→66.5%、30→5、"6.7% 到 68.3%" 等一律标明"该文称／据该文转述"，不作为既定事实。

>

⚠️ 最关键的一条边界：arXiv:2607.27853 研究的是金融深度研究（投研场景），通篇不涉及资产保全、不良资产、清收或诉讼。 凡本文把它的设计原则迁移到资产保全的内容（含全部框架、判据、落地顺序、银行映射），全部是本文分析／本文推论，不是论文的主张或结论——这一迁移是本文的推论，论文本身并未讨论资产保全。另需区分：本文锚点只是 FinanceHarness（arXiv:2607.27853），前作引用过 Harness-R1（arXiv:2608.02276）、Harness-Zero（arXiv:2609.24974）、Context Engineering（arXiv:2603.09619），本文对其只用此前已核实的结论并注明编号。

一、它是什么、要解决什么

论文起点是一句行业观察：deep research 已成为最广泛采用的 agentic 产品之一，但多数系统写的是"通用报告"，对金融深度研究不够用（arXiv:2607.27853，预印本）；理由是金融研究需要专业知识去分析历史模式并预测未来事件。论文的例子是半导体公司的股票分析师——要看历史财报、分析竞争格局、预判未来需求与宏观条件；没有金融工具与财报／经济事件专业知识的通用系统，可能定位不到这类分析所需的具体信息。

本文分析：缺口被定在能力类型上，而不是"检索得不够多"。论文并指出，既有基准多测"过去或当前"，而专业投研报告必须推理未来事件（post-cutoff reasoning），因此需要时点（point-in-time, PIT）评测防止未来信息泄漏。答案是两件配套的东西：一个分层 harness 驱动研究智能体，一个可验证的时点基准防止泄漏；PIT 被定义为逐题发布日期截止，而非"一个全局快照"。

二、最有说服力的一处证据

论文自报的固定基座消融如下，四行全部使用同一个 Qwen3.6-27B 基座（论文自身报告、未经独立复现）：

三条要点：其一，模型不变、得分可动——25.3%→32.4% 是 +7.1 个百分点；其中"朴素 harness"先贡献 +4.3pp，完整 harness 再加 +2.8pp；论文自报 GRPO 训练只再加 0.4 点，故论文自称其为"refinement 而非头条结果"。其二，论文另处报告"即便配对最前沿 LLM（如 Opus-5），FinanceGym 得分仍低于 45%"，说明该基准远未饱和。其三，本文核对到一处内部张力（本文分析）：论文贡献段与结论段写"每个系统得分都低于 40%"，而基准站排行榜列出 FinanceHarness · claude-opus-5 = 44.9%；本文以"低于 45%"为准，优先使用论文 Table 2 中不含 FinanceHarness 的基线分数，并建议以官方文本为准。

与系列前作的衔接：第一篇（《资产保全智能体：该微调基座还是只做 Harness 工程？》）据 Harness-R1（arXiv:2608.02276） 摘要论证了 harness 与微调是叠加而非替代——该文写明增益"在微调目标之前和之后都成立"，微调后叠加专用 harness 工程师仍从 59.2% 升到 64.2%（该论文自身报告、未经独立复现）。本文的 +7.1pp 与之同向。

三、架构：两套划分与对应关系

README 的架构图把栈写为五层：orchestration／capability／tools／runtime／model serving（项目方自述）。论文则把端到端能力写成三构件：environment and data construction／the agent execution loop／reward modeling，并强调三者共享同一份严格时点契约。

本文分析：该表把"harness"拆成可验收对象。论文写得很直接：runtime 层"不包含模型智能"，只强制跨层不变量——schema 一致性、工具结果串接、引用定稿、运行级预算上限；model serving 层对其余部分刻意不透明，换基座不需要改编排逻辑。本文推论：银行最该先建 runtime 与 tools 两层，它们才是"可被审计、可被回退"的部分。

四、五条可迁移的设计原则（本文分析，核心章节）

本节全部为本文分析／本文推论，每条按"来源事实 → 银行含义"展开。

① 时点契约当作硬规则，而不是打分项。 来源事实：基准站把它写成整站唯一红线——"唯一硬规则是检索的时点合规"，每次 /search 都必须携带 max_date = 该题 cutoff，"哪怕只有一次探索性查询漏掉，也会使整次运行的时点合规性作废"（项目方站点）；论文同向写明任何检测到的 PIT 泄漏使该次运行作废，而不是当作普通评分错误。银行含义（本文推论）：这是防止前视偏差／未来信息泄漏的机制化表达；关键是两类事实的物理分离——"当时可知"（截至某时点的押品状态、征信、流水、催收记录、诉讼进程）与"事后实际"（最终回收率、和解结果、处置价格）；红线必须落在工具侧而非提示词侧，写在接口里的 max_date 才机械可执行；合规性不是加权项，而是一票否决项。

② 引用式数据流，让每个数字都能追回来源。 来源事实：README 述 reference-chaining——工具输出按引用 prev:. 喂给下一个工具，"使价格序列变成相关性计算而无需重录"，以及 Grounded——每一个数字都能追回它来自的工具或来源；论文另述会组合带编号引用、在草稿漏掉引用工具时补挂引用，并做一次 grounding-review，要求软化或标注无法与已读来源挂钩的表述。银行含义（本文推论）：减少人工搬运错误与口径断链——资产保全大量日常动作是"从一个系统取数、手工粘贴进另一个表"，引用传递不落地文本，也就没有转录错误；可溯源在此是业务合规要求——数字可追回来源工具与时点后，"当时取的还是事后补的"就是可核查事实。

③ 渐进披露：能力多，不等于都要塞进提示。 来源事实：README 述 progressive disclosure——"核心循环留在提示里；其余等待在目录中，按需加载，所以广度在使用之前不花任何成本"；论文述工具面分层：常驻层只放核心循环动作，延迟工具经紧凑目录暴露，只有模型确认进入某工具族时才加载完整 schema。AgentScope 更直白："企业可以在 Registry 中注册大量能力，却只向当前模型披露少数相关能力。" 银行含义（本文推论）：这是上下文经济性，不是省钱技巧；"注册就全量披露"会同时抬高成本与出错率，应按任务阶段决定披露面。论文另有一条更值得抄的设计——模式只是提示变体，工具注册表在模式间保持一致，以免轨迹因模式切换后工具消失而搁浅。

④ 能力声明 ≠ 授权：意图必须携带身份与用途。 来源事实：AgentScope 原文——"模型输出的工具调用只是一项行动意图"，它没有自动获得当前用户身份，不等于企业策略允许执行，也不能证明远程系统已经产生预期结果；并点破："若'出现在 Tool Schema 中'就等价于'可以调用'，最小权限、用户委派和阶段性只读模式都无法成立。" 该文把不同表达统一为 Action Request（action_id/task_id/parent_event_id、参数与期望输出 schema、actor、purpose 与当前任务阶段、环境与资源范围、副作用／可逆性／风险分级、幂等键与超时、审批与审计要求），并要求能力名称、参数类型、影响范围与身份由确定性代码解析与校验。银行含义（本文推论）：权限、身份与用途必须随请求一起走。该文的例子极贴切："创建变更单"与"发布生产环境"不能被包装成一个模糊工具，因为二者身份、风险、可逆性、审批要求完全不同；映射到资产保全，"生成催收函草稿"与"对外发出催收函"、"测算诉讼可行性"与"实际提起立案"必须是两个 Action，塞进一个工具等于把不可逆动作的可逆性伪装掉。

⑤ 动作面与反馈面分离。 来源事实：AgentScope 把 harness 这部分统称行动与反馈系统：Action Plane 负责连接外部世界并限制影响范围；Feedback Plane 负责把执行进度、状态、结果和质量信号反馈给用户与下一个 Agent 版本；并强调 Trace 需具备因果性而非时间顺序，至少关联 Agent／Model／Harness 版本、Context Manifest、Action Request 与策略审批、工具／环境结果、Verifier 结果、业务结果与用户反馈。银行含义（本文推论）：留痕与"下一版 harness 的改进依据"是同一套机制——同一个 Trace 同时服务两类读者：内审／合规要"当时发生了什么、依据什么授权"，工程要"下一版该改哪里"；该文并给出 Patch 与根因对照（缺事实→改 Context；反复出错→修 Memory；方法不稳→改 Skill；工具误用→改 Schema 或权限；无进展→调 Loop／模型；环境不一致→修 Environment Contract；完成误判→强化 Verifier）。

五、评测与奖励怎么设计

来源事实：基准站给出四个数字——400 道公开题、2,464 条专家评分项、每题及其评分项平均 1.2 小时金融专家工时、0–4 分制归一化（项目方站点口径）。论文的沙盒建在自采的大规模网页语料上，用 htmldate 提取发布日期以强制 PIT、用 trafilatura 提取正文，规模1 亿篇以上，向量用 Qwen3-Embedding-4B、索引为 FAISS IVF-SQ8，由此抽实体关系三元组，得 574 万条原始边、过滤后 437 万条工作边、横跨 111 万实体、来自 120 万篇文章（论文自身报告、未经独立复现）。

题目与评分项怎么来：论文先做情境挖掘——跨类实体—事件链接、围绕高度数实体的时间叙事弧、以及"升级 vs 降级""超预期 vs 不及预期"这类两极分化，并用实体预算限制同一主体被反复采样，防止超大盘公司主导基准；每个候选情境按事件量、实体多样性、关系熵的 z-score 目标函数配一个截止日，再"无类别预热"地生成——提示中不提供主题、行业或推理分类——输出分析师式提问、参考投资论点（thesis）、两层 rubric：pre-cutoff 项测截止日前可查到的事实，post-cutoff 项测只有截止日后才能验证的结果。论文强调这一划分是 FinanceGym 的核心：它把证据检索与前瞻合成分开，同时让两侧都可审计。经质量门与 ILP 配平得 500 题子集交外部专家标注，411/500 达标，即 82% 的专业标注通过率，最终配平为 400 题、2,464 条评分项的发布版，跨 9 主题、11 行业（9 叶）、6 类推理、12 个月度截止日桶。

评分与防作弊：判分由 LLM judge 按 5 档 0–4 分逐项打（0 未涉及／1 提及／2 部分／3 实质／4 完全有据），judge 被定位为"一致的 rubric 施加者"而非新标准的来源；主指标是每题等权的 rubric 得分率。基准站明确写明 rubrics 保持不公开以防 rubric hacking，公开数据只含 task_id／question／cutoff 三字段，评分跑在私有全量 rubric 上。论文另有发布政策：不公开底层语料，只发布研究问题与报告提交代码；专家沿两轴复核——质量与隐私／来源（只"查询"信息，不嵌入、引用或泄漏语料内容）。

银行含义（本文推论）：其一，评测集必须专家建——1.2 小时／题说明专家工时是成本主体。其二，必须双轴——当时可知（过程与依据）／事后实际（结果）。其三，必须防对标准过拟合——"标准不公开"不是为保密，而是为了让分数不被当作可优化的目标；把评分标准当 KPI 下发到条线，等于亲手把评测集变成训练集。

六、三条最易踩的坑（本文分析）

坑一：工具分布迁移。 论文自述，微调过的开源权重深度研究模型是对着实时网页工具栈（如 Serper、Jina）训练的，本文却必须经由语料库等价工具（Search→FAISS+PIT、Visit→SQLite）评测，因此论文把这类模型的分数明确定义为"受控 PIT 接口下的迁移结果"，而非通用能力结论；为把三者分开，论文用固定 30 步 ReAct 包装器 + 1 个搜索工具 + 1 个终答工具 + 9 个可换基座，以分离 backbone capability／scaffold contribution／tool-distribution shift。论文报告的可观察后果是归因方式变了：agentic 搜索系统被明确提示要产出带来源归属的报告，而微调过的系统往往输出更干净的答案式散文、行内归属更弱——论文强调这不是缺乏知识或搜索能力，而是"学到的报告接口与长文、引用敏感的金融 rubric 不匹配"。

坑二：与 harness 共同训练造成的过拟合。 据腾讯云开发者社区文章转述，LangChain 发现当前 Agent 产品（如 Claude Code、Codex）是模型与 Harness 一起训练的，导致一种过拟合——换了工具逻辑后模型表现会变差；该文并举例称 Opus 在 Claude Code 的 Harness 下得分低于它在其他 Harness 中的得分（该文称／据该文转述，本文不作为既定事实）。本文分析：这与坑一指向同一个风险——harness 与模型必须一起版本化。本文推论：回扣第一篇的结论（据 Harness-R1，arXiv:2608.02276），harness 变更通常可回退，微调制品无法"未训练"回去；因此"模型 × harness"成为耦合变量时，发布单元就应该是这一对。

坑三：把脚手架的成绩记在模型头上。 若没有可分离的实验设计（固定包装器与工具只换基座；固定基座只换 harness），涨分究竟来自模型还是 harness 就无法判断。本文推论：这正是"该不该换更大的模型"最容易出错的地方——缺少分离设计时，换模型与改 harness 会同时发生，功劳与账单都会被错误归因。

七、金融特有的要求：来自标准组织的一条平行证据

来源事实：MCP 官方「金融服务兴趣组」（FSIG）章程写明，该组面向受监管金融机构的各方，识别 MCP 需要在哪些地方为 compliance／auditability／risk-controlled deployment 作出适配。章程列出的工作项包括：防篡改、可移植的工具调用记录——记录"一次工具调用做了什么、依据什么授权、符合哪条策略"，使 MCP 交互能够满足监管审计与事件复盘的义务；通过 MCP 暴露的数据的来源标注、引用与同意元数据；验证框架与密码学证明，使机构在依据响应行动之前，能对服务器身份、工具行为与响应完整性获得保证；以及工具使用与数据处理的声明式策略及其强制执行点，使机构能把监管与内控约束编码为机器可检查的规则。

本文分析：这是工具治理层面的行业动作，可与原则④⑤相互印证——原则④说"意图必须携带身份与用途"，章程说记录必须能回答"做了什么、依据什么授权、符合哪条策略"；原则⑤说动作面要限制影响范围、反馈面要回流质量信号，章程说策略要能编码成机器可检查的规则并明确执行点。本文推论：当标准组织把审计记录、来源标注与密码学证明写进章程时，"可审计"就从合规成本变成了接口要求；选型与自建时应优先看这套契约是否具备。

八、落地顺序（本文分析，银行版）

本节全部为本文分析／本文推论，不是论文主张，也不构成监管要求或技术标准。 前两篇分别回答"要不要微调"与"基座选多大"；本篇回答中间那一层——脚手架怎么搭；次序是把模型与规模选择放到最后。

三步最易被跳过的检查（本文推论）：①若写成"要求模型注意时点"，等于没写——必须由接口强制；③若一开始就把全部能力塞进提示，后面的成本与错误率都会被这一步锁死；⑤若在①—④之前就选模型，涨分无法归因。

九、明确点破两种极端

极端一："套个 harness 就万事大吉"。 不成立。论文自报的数字本身就是反证：即便配上最强模型，FinanceGym 得分仍低于 45%；而 pre-cutoff 与 post-cutoff 的巨大落差跨系统稳定——论文报告"约 12% 对 46%"，并据此指出金融深度研究不是单靠更好的检索就能解决：智能体必须把历史证据转成只有截止日后才能验证的前瞻判断（论文自身报告、未经独立复现）。本文推论：harness 能改善证据的获取、组织与归属，但不会自动带来前瞻判断能力。

极端二："harness 只是工程细节"。 同样不成立。同一基座 +7.1pp 就是证；论文另处称，在相同 PIT 语料下，在同一搜索工具包装器内更换基座带来的分差，大于围绕同一基座更换脚手架带来的分差，并据此说当前表现仍强烈受限于底层模型，而任务匹配的脚手架可以额外找回证据并更可靠地组织它。本文推论：两者都重要，但作用于不同环节——若只能先做一件，先做 harness，因为它的变更可回退、可审计、可归因，且其产出（被校验的轨迹）正是将来微调的语料（呼应 Harness-Zero，arXiv:2609.24974 的"harness 可蒸馏进模型"这一此前已核实的结论）。

十、行动清单

法务／合规线：① 把"时点合规"写成制度里的一票否决项，并明确其技术落点（接口强制而非提示词）；② 明确"当时可知"与"事后实际"两类材料的使用边界，防止事后信息倒灌进当时的决策依据；③ 明确 Agent 动作的授权链（以谁的身份、依据什么授权、符合哪条策略）；④ 对外发出类动作（催收函、诉讼文书、对外报送）必须单独审批，不得与草稿生成合并；⑤ 明确 Trace 的留存期限、导出与集中日志对接（"功能存在"不等于满足审计要求）。

信息科技线：⑥ 按五层栈盘点能力，优先补齐 runtime 与 tools；⑦ 建引用式数据流与数字级溯源；⑧ 建能力目录并实现按任务阶段的渐进披露；⑨ 把 harness 变更纳入既有变更管理与 SDLC，明确回滚预案与版本记录；⑩ 建 Trace 的因果关联与模型／harness／策略三元组；⑪ 建双轴评测集与基线，把评分标准与业务 KPI 分开。

资产保全业务条线：⑫ 做一次任务盘点，标出每类任务里哪些是可回退的准备工作、哪些是不可回退的对外动作；⑬ 优先落地流程／工具型任务（台账核对、时效监控、材料齐备性检查、外部信息归集）；⑭ 对文书／口径型任务，把"草稿生成"与"对外发出"拆成两个 Action；⑮ 对经验判断型任务（该不该诉、能否和解、以物抵债是否划算），定位为"harness 准备材料与选项、人做决策"；⑯ 为评测集投入专家工时，并不把评分标准下发为考核指标。

最应先动三项（本文推论）：①（硬规则决定合规底线）、⑧（披露面决定成本与错误率）、⑪（评测集决定后面所有决策有没有依据）。

FAQ

Q1：这篇论文讲的是资产保全吗？结论能直接用在不良资产清收上吗？

A1：不是。 arXiv:2607.27853 研究的是金融深度研究（投研场景），通篇不涉及资产保全、不良资产、清收或诉讼；本文中所有把它迁移到资产保全的内容全部是本文分析／本文推论，不是论文的主张。该论文是预印本、未经同行评议，其全部数字均为论文自身报告、未经独立复现。

Q2：25.3% 到 32.4% 这个提升，和第一篇说的微调是替代还是叠加？

A2：是叠加，不是替代，且两篇编号不同、不可混用。本文的 +7.1pp 来自 FinanceHarness（arXiv:2607.27853），是固定 Qwen3.6-27B 基座、只改 harness 的消融（论文自身报告、未经独立复现）；"叠加而非替代"来自第一篇所据的 Harness-R1（arXiv:2608.02276）——该文写明增益在微调目标之前和之后都成立，微调后叠加专用 harness 工程师仍从 59.2% 升到 64.2%。本文推论：两者作用于不同层，次序上先做 harness，因其变更可回退、产出可复用为语料。

Q3：harness 都能把分数从 25.3% 拉到 32.4% 了，还需要换更强的模型吗？

A3：按论文自己的数据，需要。 论文报告即便配上最强模型，FinanceGym 得分仍低于 45%，且跨系统稳定的 pre／post-cutoff 落差说明前瞻判断不是检索能解决的（论文自身报告、未经独立复现）；论文另处指出，同一包装器内更换基座的分差，大于围绕同一基座更换脚手架的分差。本文推论：两者都要，但先做 harness——没有可分离的实验设计，就无法判断涨分来自模型还是 harness。

Q4：这套评测集能直接拿来用吗？

A4：不能直接商用于业务。 基准站写明 FinanceGym 与 FinanceHarness 均以 CC BY-NC 4.0 发布，仅供学术与非商业研究评估；禁止商业使用，包括集成进商业金融顾问服务、或用生成输出去提供商业投资建议；公开数据仅含 task_id／question／cutoff 三字段，rubric 不公开以防 rubric hacking，用于发布结果的检索环境因许可原因不对外分发（项目方站点口径）。本文推论：可借鉴的是方法（专家建集、双轴划分、标准不公开、防对标准过拟合），不是数据本身。

事实来源

性质分层：一手学术——arXiv:2607.27853（预印本，未经同行评议，全部数字为论文自身报告、未经独立复现）；项目方口径——仓库 README、GitHub API 元数据（179★／Apache-2.0／created 2026-08-03／pushed 2026-08-22，客观时点快照）、FinanceGym 官方基准站（400 题／2,464 条评分项／每题均 1.2 小时专家工时／0–4 分制／"唯一硬规则是检索的时点合规"／rubric 不公开以防 rubric hacking／截止日跨度 2024-12-31 至 2025-11-10／CC BY-NC 4.0 且禁止商业使用／排行榜 23 个系统）；厂商文档——Microsoft Learn《Agent Harness》（"运行期脚手架"，组合既有构建块，多数能力默认开启、文件访问与 Shell 等为可选，作用域不匹配按失败关闭）；厂商／社区技术博客——AgentScope Java《如何构建 Agent Harness（四）》（行动意图与授权之分、Action Plane／Feedback Plane、统一 Action Request、渐进披露、Trace 因果性、Patch 与根因对照，其主张为该文观点）；标准组织官方文档——MCP《Financial Services Charter》（面向受监管机构的 compliance／auditability／risk-controlled deployment，防篡改可移植的工具调用记录、来源标注与同意元数据、验证框架与密码学证明、声明式策略及执行点）；技术社区二手——腾讯云开发者社区《6.7% 到 68.3%：Harness Engineering 六大支柱》（该文称 LangChain 在 Terminal Bench 2.0 上只改运行环境、模型不变，排名 30 → 5、得分 52.8% → 66.5%；该文转述 LangChain 发现 Claude Code、Codex 等产品模型与 Harness 一起训练、换工具逻辑后表现变差，并举例称 Opus 在 Claude Code 的 Harness 下得分低于其他 Harness——上述数字与名次均系该文称／该文转述，未经本文独立验证，不作为既定事实）。

本文推论部分：全部"银行含义"与"本文分析"；第三节对应表；第四节对原则①④⑤的引申；第五、七节银行含义；第六节三条坑的归纳与"发布单元应为模型×harness 一对"；第八节落地次序与检查项；第九节两种极端的表述方式；第十节清单与"最应先动三项"；FAQ 中标为本文分析的部分。本文不构成监管要求、合规意见、法律意见或技术标准。 来源标题、链接与性质另见 front matter 的 references。

（内容由AI生成，仅供参考）