---
title: "金融 harness 怎么设计与实施：从 FinanceHarness 的分层栈、时点契约与五条可迁移原则，到银行资产保全的落地次序"
date: "2026-09-27"
description: "以预印本 arXiv:2607.27853《FinanceHarness》为主锚，配合代码仓库、GitHub 元数据、FinanceGym 官方基准站、Microsoft Learn、AgentScope 技术博客、MCP 金融服务兴趣组章程与一篇技术社区二手文章共 9 份归档来源，拆解金融深度研究 harness 的分层栈、端到端三构件与严格时点契约；据同一开源权重基座 25.3%→32.4% 的论文自报数据论证 harness 是一阶杠杆，再用五条可迁移原则与三条最易踩的坑，推出银行资产保全版落地次序。"
tags: ["金融科技", "AI治理", "大模型", "智能体", "Harness工程", "金融深度研究", "资产保全", "不良资产", "银行AI", "信息科技风险", "模型风险管理", "可审计性"]
schema_type: "Article"
references:
  - title: "FinanceHarness: Autonomous Financial Deep Research Framework（arXiv:2607.27853，预印本）"
    url: "https://arxiv.org/abs/2607.27853"
    source: "arXiv（预印本）"
  - title: "Yijia-Xiao/FinanceHarness（代码仓库，含元数据）"
    url: "https://github.com/Yijia-Xiao/FinanceHarness"
    source: "GitHub（项目方）"
  - title: "FinanceGym — point-in-time finance deep-research benchmark（官方基准站）"
    url: "https://financegym.github.io/"
    source: "项目方站点"
  - title: "Agent Harness（Microsoft Learn，Agent Framework 概念文档）"
    url: "https://learn.microsoft.com/en-us/agent-framework/concepts/harness"
    source: "厂商文档"
  - title: "如何构建 Agent Harness（四）：受控执行、验证反馈与交付准备（AgentScope Java）"
    url: "https://java.agentscope.io/v2/zh/blogs/how-to-build-agent-harness/04-controlled-execution"
    source: "厂商/社区技术博客"
  - title: "Financial Services Charter（Model Context Protocol 金融服务兴趣组章程）"
    url: "https://modelcontextprotocol.io/community/interest-groups/financial-services"
    source: "标准组织官方文档"
  - title: "6.7% 到 68.3%：Harness Engineering 六大支柱如何重塑 AI Agent 开发（腾讯云开发者社区）"
    url: "https://cloud.tencent.cn/developer/article/2660978"
    source: "技术社区（二手）"
# 注：本文件未写入 AIGC 隐式标识块。按现行标识要求，AIGC 元数据需包含 Label、ContentProducer、
#     ProduceID、PropagateID、ReservedCode1、ReservedCode2 等字段，其中 ProduceID / ReservedCode
#     须由标识服务平台逐篇签发，不能由作者或生成工具自行推定或编造。因此本文件暂留空位，须由作者
#     在取得平台签发的标识值后补充完整，方可发布。
---

**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 基座**（**论文自身报告、未经独立复现**）：

| 配置 | 总分 | 截止日前 | 截止日后 |
|---|---|---|---|
| Vanilla（只有搜索工具的模型） | **25.3%** | 36.1% | 8.7% |
| Naive harness（朴素 harness） | 29.6% | 41.8% | 10.7% |
| **Harness（完整 harness，主配置）** | **32.4%** | 45.7% | 11.8% |
| + RFT（GRPO 训练） | 32.8% | 46.2% | 12.1% |

**三条要点**：**其一，模型不变、得分可动**——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**，并强调三者**共享同一份严格时点契约**。

| 论文三构件 | 对应 README 五层（**本文整理**） | 职责（来源所述） |
|---|---|---|
| environment and data construction | **tools** + 环境侧 | PIT 搜索沙盒：语料、检索服务、时点访问控制 |
| the agent execution loop | **orchestration** + **runtime** + **capability** | 有界循环、解析与派发、schema 校验、分层加载、模式选择、恢复 |
| reward modeling | **model serving**（评分侧） | rubric 判分；同一契约同时用于评测与优化 |

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

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

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

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

**② 引用式数据流，让每个数字都能追回来源。** **来源事实**：README 述 **reference-chaining——工具输出按引用 `prev:<call_id>.<path>` 喂给下一个工具，"使价格序列变成相关性计算而无需重录"**，以及 **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 暴露的数据的来源标注、引用与同意元数据**；**验证框架与密码学证明**，使机构在依据响应行动之前，能对**服务器身份、工具行为与响应完整性**获得保证；以及**工具使用与数据处理的声明式策略及其强制执行点**，使机构**能把监管与内控约束编码为机器可检查的规则**。

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

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

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

| 序 | 动作 | 通过条件（本文推论） |
|---|---|---|
| ① | **先定"唯一硬规则"** | 写出哪一条是**一票否决**（**本文推论：检索与取数的时点合规**）；**落在工具侧可机械执行**，不落在提示词里 |
| ② | **再建可溯源的数据／检索层** | 每个数字**能追回来源工具与时点**；工具间**按引用传递**；"当时可知"与"事后实际"**物理分离** |
| ③ | **再定能力注册与披露** | 有**能力目录**（所有者、版本、作用域）；**同一 registry 在不同任务阶段只披露少数相关能力**；模式切换**不改变工具注册表** |
| ④ | **再建动作面／反馈面** | 统一 **Action Request**（含身份、用途、任务阶段、可逆性、审批要求）；**不可逆动作单独成 Action**；Trace **具因果关联**并含**模型／harness／策略**版本 |
| ⑤ | **先跑免微调基线，再谈模型与规模** | 有**双轴评测集**与**防对标准过拟合**机制；**错误已按类型分好**，才回到前两篇的判据 |

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

## 九、明确点破两种极端

**极端一："套个 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生成，仅供参考）*