让 Agent「照章办事」：金融监管里的 Harness 实践值得谁抄作业？
一个反直觉的命题
当整个行业都在追逐「更聪明的 Agent」时，中软融鑫总工程师于浩军在 AICon 深圳站给出的答案恰恰相反：在金融监管报送这个场景里，Agent 越聪明越危险。这句话听起来像反技术，但如果把场景约束摆上桌——零容错、强追溯、口径必须受控——它其实是一个工程必然。真正值得讨论的不是「该不该约束」，而是「约束住之后，Agent 还剩下什么价值」。
我的判断是：这篇访谈是近阶段少见的、有真实生产重量的分享，但它的锋利之处和中空之处同样明显。
背景与议题
金融监管报送的四个特征构成了整个方案的地基：口径复杂且在组织内被各自理解（信贷、财务、统计三个部门对同一笔贷款可能给出三个答案）；频度高（月、旬、周多节奏）；零容错（97% 在这个场景里只是「初步概念」）；强追溯（一笔违规放贷必须能定位到具体环节）。
三项叠加，产生了一个尖锐矛盾：大模型的自由推理正是它的能力来源，也正是监管场景的风险来源。而实践中积累的三个痛点——口径漂移、幻觉、不可解释——在这篇文章里被归因于同一个根源：Agent 的自由发挥与监管所需的确定性之间的结构性冲突。这个归因很干净，也是全文最有价值的一句话。
核心观点：新在哪里
观点一：把「不知道」当成一项功能，而不是缺陷。这是全文最硬的一条。方案要求大模型在口径缺失时明确输出「不知道」，禁止自行拼接。访谈里还坦承了落地初期的尴尬：第一批项目里「不知道」太多，用户觉得不合理；经过口径治理后，「不知道」逐渐减少，系统才达到可上生产的状态。这个细节的分量远大于任何架构图——它说明确定性不是靠提示词换来的，是靠治理换来的。相比业界普遍把「拒答率」当负面指标的思路，这里把一个看似体验缺陷的现象当成了系统健康度的读数，这是真正的视角转换。
观点二：Harness 不是「给 Agent 加护栏」，而是「重新划分人机分工」。于浩军把大模型的职责切成两层：允许做意图识别、任务分解、槽位抽取、Skill 路由、异常文本识别；禁止做数据计算、汇总、口径判别、弱化校验、生成引用。确定性工作全部下推到固化的 Python/Java/SQL。配合五段式受控状态机（计划—保护—执行—检核—过程维度检查）、动作白名单、Schema 契约、步数与 Token 预算上限、失败即停，这已经不是在优化 Prompt，而是在做运行时管控。业界谈 Agent 可靠性多停留在「检索增强 + 评估集」层面，这里则把确定性约束落实到了状态机的每一个跃迁条件上，工程颗粒度明显更细。
观点三：治理与智能是互为前提，而非先后顺序。这条观点有现实语用价值。很多企业卡在「数据还没治理好，所以不能上 AI」的循环里。这里的解法是双向的：用 AI 补知识资产与数据资产的缺口，补的过程需人工确认，再用治理成果反过来抬高 Agent 的稳定性。这是一个正反馈设计，而不是单行道。
观点四：知识库不靠单一向量检索。「拿一个非常大的知识库丢给 Agent，它基本就废了」——这句话是对当下 RAG 主流做法的一次直接质疑。方案选择向量 + 精确数据 + 图库 + 语义本体组合，并按特定 Agent 做知识切片；口径只允许引用、不允许理解，且硬绑定知识条目与语义版本。配套五个健康度指标（覆盖率、鲜度、冲突、过期项、引用命中率），其中覆盖率被要求 100%。这比「建个向量库就能问答」的思路，更接近生产系统该有的样子。
可信度分析
受访者的立场：于浩军来自中软融鑫，一家做金融监管报送的厂商，方案是其自研 Harness 架构。这决定了文章天然带有产品宣讲属性——痛点描述、方案结构、上线闸门都指向一个已经存在的商业产品。文中也确实出现了「我们做的一个实际演练」「第一批金融机构项目」这类表述，但没有任何量化结果：错报率下降多少、人工复核耗时减少多少、灰度期发现多少真实缺陷，全部缺失。这不是疏忽，而是厂商分享的典型信息结构。
干货 vs 场面话：干货密度相当高。五段式状态机、Skill 的结构化规格（口径引用必填、输入输出契约化与枚举约束、硬绑语义版本、记录血缘与计算引擎）、三重上线闸门（红线机制、历史 5–10 期回归、灰度双轨并行 3–5 个月）、大模型能力白名单与黑名单，这些都是可以直接对照实施的具体设计，不是抽象口号。相对「场面话」的部分集中在结尾：「治理与智能互为前提」「下一步做 Skill 资产化」属于正确的废话，缺乏可验证的机制描述。
提问质量：这是本文的短板。文章是单方面演讲实录，没有 Q&A 环节，因此缺失了最关键的对抗性检验。于浩军自己提到，有人质疑「给大模型嫁接过多约束、限制了大模型的能力，算不上好的实践」，但他只用一句「我的看法恰恰相反」带过，没有正面回应这个质疑背后的具体批评。一个真正站得住的技术主张，应当经得起「那你怎么证明约束后的收益大于损失」的追问，而文中没有这个证明。
该问未问、未展开的问题
第一，「不知道」的执行力在哪。系统要求模型输出「不知道」，但大模型本身并不具备可靠的自我认知边界。它如何分辨「我不知道」和「我知道但不想说」？是否有独立于模型之外的置信度判定？文中只说了要让它说不知道，没说怎么保证它在该说的时候真的会说。
第二，受控状态机与规则引擎的边界。这套设计的实质是把开放循环压成封闭动作空间，但当动作空间已经封闭、计算已经固化、校验已经枚举，那么哪里还需要大模型？如果只剩意图识别和槽位抽取，这是典型的 NLU 任务，用轻量模型甚至规则 + 分类器可能更稳、更便宜、更可测。文章没有回答「为什么非要用大模型承担编排」这个成本效益问题，而这恰恰是质疑者最想问的。
第三，中间过程的可信度量。于浩军自己承认「中间过程的度量和评估还有欠缺」，这是全文唯一一处主动示弱，也是最有价值的自陈。但这个欠缺恰恰是整套方案的命门：如果无法度量中间状态的可信度，那么「失败即停」的触发条件就是主观的，上线闸门也只能依赖历史回测这种粗粒度手段。
第四，口径年变动 30% 带来的运维成本。知识版本、数据版本、Skill 版本三者并存，回溯历史数据必须匹配历史版本。这套版本体系在长期运行中的维护成本、版本错配的检测机制，文中均未展开。
总结
这篇文章的真正贡献，不是提出了 Harness 这个名词，而是用生产场景逼出了一个被行业普遍回避的事实：在许多高价值场景里，Agent 的可靠性不来自模型能力，而来自对模型能力的主动剥夺。于浩军的方案把「让模型不做什么」当成核心设计，这套思路对金融、医疗、审计、合规等强追溯领域有直接借鉴价值。
但也要看清它的适用边界。方案成立的前提是：业务口径可以被提前结构化、核心算法可以被固化、历史数据可以被回测。一旦场景里的口径本来就无法穷尽定义，或者需要在开放信息中做判断，这套「封闭动作空间」就会迅速退化成一个昂贵的规则引擎。访谈没有讨论这个边界之外的情况，这是它最大的留白。
可继续追问的三个问题
- 当计算、校验、口径判定全部固化后，大模型在这条链路里的边际贡献，相比轻量 NLU + 规则编排究竟体现在哪？是否有做过 A/B 对照的成本与准确率对比？
- 「不知道」的判定是由模型自身输出，还是有独立的置信度门控？如何度量这个门控的漏检率与误报率？
- 在口径本身就难以结构化的领域（例如新兴业务、跨境场景），这套受控状态机的退化边界在哪？有没有可观测的预警信号？