一个反直觉的命题当整个行业都在追逐「更聪明的 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 资产化」属于正确的废话缺乏可验证的机制描述。提问质量这是本文的短板。文章是单方面演讲实录没有 QA 环节因此缺失了最关键的对抗性检验。于浩军自己提到有人质疑「给大模型嫁接过多约束、限制了大模型的能力算不上好的实践」但他只用一句「我的看法恰恰相反」带过没有正面回应这个质疑背后的具体批评。一个真正站得住的技术主张应当经得起「那你怎么证明约束后的收益大于损失」的追问而文中没有这个证明。该问未问、未展开的问题第一「不知道」的执行力在哪。系统要求模型输出「不知道」但大模型本身并不具备可靠的自我认知边界。它如何分辨「我不知道」和「我知道但不想说」是否有独立于模型之外的置信度判定文中只说了要让它说不知道没说怎么保证它在该说的时候真的会说。第二受控状态机与规则引擎的边界。这套设计的实质是把开放循环压成封闭动作空间但当动作空间已经封闭、计算已经固化、校验已经枚举那么哪里还需要大模型如果只剩意图识别和槽位抽取这是典型的 NLU 任务用轻量模型甚至规则 分类器可能更稳、更便宜、更可测。文章没有回答「为什么非要用大模型承担编排」这个成本效益问题而这恰恰是质疑者最想问的。第三中间过程的可信度量。于浩军自己承认「中间过程的度量和评估还有欠缺」这是全文唯一一处主动示弱也是最有价值的自陈。但这个欠缺恰恰是整套方案的命门如果无法度量中间状态的可信度那么「失败即停」的触发条件就是主观的上线闸门也只能依赖历史回测这种粗粒度手段。第四口径年变动 30% 带来的运维成本。知识版本、数据版本、Skill 版本三者并存回溯历史数据必须匹配历史版本。这套版本体系在长期运行中的维护成本、版本错配的检测机制文中均未展开。总结这篇文章的真正贡献不是提出了 Harness 这个名词而是用生产场景逼出了一个被行业普遍回避的事实在许多高价值场景里Agent 的可靠性不来自模型能力而来自对模型能力的主动剥夺。于浩军的方案把「让模型不做什么」当成核心设计这套思路对金融、医疗、审计、合规等强追溯领域有直接借鉴价值。但也要看清它的适用边界。方案成立的前提是业务口径可以被提前结构化、核心算法可以被固化、历史数据可以被回测。一旦场景里的口径本来就无法穷尽定义或者需要在开放信息中做判断这套「封闭动作空间」就会迅速退化成一个昂贵的规则引擎。访谈没有讨论这个边界之外的情况这是它最大的留白。可继续追问的三个问题当计算、校验、口径判定全部固化后大模型在这条链路里的边际贡献相比轻量 NLU 规则编排究竟体现在哪是否有做过 A/B 对照的成本与准确率对比「不知道」的判定是由模型自身输出还是有独立的置信度门控如何度量这个门控的漏检率与误报率在口径本身就难以结构化的领域例如新兴业务、跨境场景这套受控状态机的退化边界在哪有没有可观测的预警信号