接个 AI 做随机问答，谁都能做。
但如果你要做精准问答——每次输出必须证据可追溯、结论可复现、漏报误报可度量——这件事的难度立刻翻十倍。因为你面对的不再是"模型大概率对"，而是 "系统必须保证对"。
我们最近就在做这样一个事：流程文件检查智能体。
需求说起来简单：用户输入一份流程图的结构化文本，系统自动检查出里面的问题——结构硬伤、网关分支缺失、职责边界模糊、风险控制遗漏……然后输出一份可验证的结构化报告。
任何人的第一直觉都是：接 AI 大模型，写提示词，文本丢进去，直接返回结果。五分钟搞定。
然后你就撞墙了。撞得头破血流。
准确率不到 50%。幻觉满天飞。JSON 格式稀烂。最关键的是—— 你不知道哪一半是对的。当一个检查工具自己都在编造问题的时候，用户还敢用吗？
我们来还原一下典型的问题：
第一， 模型会凭空编造问题。你给它一个流程图，它可能说"缺少审批节点"，但那个节点明明就在流程图里。它没仔细看，或者它的注意力窗口跳过了那一行。
第二， 证据不可追溯。模型说"这里有问题"，你问它"哪个节点？哪条连线？"，它要么给个模糊的描述，要么干脆编一个不存在的节点编号。
第三， JSON 格式不稳定。提示词里写了"只输出 JSON"，但它可能给你一段 Markdown 解释，然后 JSON 藏在某个代码块里。更惨的是，它可能输出一个格式错误、无法解析的 JSON。你让一个用户面对一串红色的解析错误，这产品还怎么用？
第四， 覆盖率不可控。你让它检查"结构硬伤"，它可能只检查了节点，没检查连线；你让它检查"职责边界"，它可能只看了一个泳道。漏报的问题，用户不会知道，你也无从验证。
综合下来，直觉方案的实际准确率，我估计连 50% 都不到。而且最要命的是， 你不知道哪一半是对的。
换个思路：Agent = 模型 + Harness
Martin Fowler 团队在 2026 年 4 月发表了一篇文章，专门讲 Harness Engineering 这个概念。他们的定义很简洁：
Agent = Model + Harness
Harness 就是"除了模型之外的一切"——所有用来引导、约束、验证、纠正模型输出的工程手段。
他们把 Harness 分成两类：
Guides（前馈控制） ——在模型行动之前就引导它的方向，提高一次成功的概率。
Sensors（反馈控制） ——在模型行动之后检测问题，触发自我纠正。
每类又分两种执行方式：
Computational（确定性计算） ——CPU 跑，毫秒级，结果绝对可靠。比如语法检查、结构分析、正则匹配。
Inferential（推理判断） ——GPU 跑，秒级，结果概率性。比如语义分析、AI 代码审查。
这篇文章讲的 Harness 是针对 Coding Agent 的。但你看这个框架，它跟我们的流程检查场景简直完美对应。
我们把"一次性提示词"拆成了 7 个独立 Skill
第一刀，也是最关键的一刀： 不再让一个模型、一个提示词、一次调用搞定所有检查。
我们定义了一套架构：
具体来说，我们把流程检查拆成了 7 个独立的 Check Skill：
你注意看"执行方式"这一列。
前三个 Skill——来源覆盖、结构硬伤、网关控制—— 根本不调用 AI 模型。它们是用纯确定性的 Harness 规则引擎来跑的。
什么叫规则引擎？就是代码写的 if-else 逻辑。比如"检查是否有空来源连线"——直接遍历 edges 数组，看 source 是否为空。100% 准确，零幻觉，毫秒级完成。
后面几个 Skill——职责边界、风险控制、流程资料冲突——才调用模型。因为这些问题需要语义判断，比如"两个角色的职责边界是否模糊"，这不是简单的规则匹配能解决的。
这就是 Computational + Inferential 的双轨制。
每个 Skill 只看自己该看的数据
第二刀： 数据裁剪。
之前我们做了一件事，被验证是极其关键的架构决策—— EvidenceView。
每个 Skill 在启动之前，系统会从完整的流程数据中，为它裁剪出一份"证据视图"。比如：
GATEWAY_CONTROL（网关控制）Skill 的 EvidenceView 里， 只有网关列表和流转关系。它看不到泳道职责、看不到文件正文、看不到完整原文。
ROLE_RESPONSIBILITY（职责边界）Skill 的 EvidenceView 里， 只有泳道、节点、连线。看不到网关详情。
这不是在限制模型的能力，恰恰相反—— 这是在保护模型的专注力。
你给模型 5000 字的全文，它可能把注意力分散到无关内容上，或者被"知识库污染"——用它的训练数据里的常识来填补信息缺口，而不是依据你给的证据来做判断。
EvidenceView 的逻辑就是： 你只需要看跟你相关的那部分，多一个字都不给。
而且，每个 Skill 还有一个 forbiddenEvidence 黑名单，明确禁止引用 rawInput（原始输入）、fullDocumentText（完整文档）、globalKnowledgeBase（全局知识库）。彻底堵死了模型"自己发挥"的路径。
模型输出后还有四层校验
第三刀： 输出校验链。
模型 Skill 跑完之后，输出不是直接给用户的。它会经过一个验证管道：
第一层： JSON 格式验证。模型输出必须是合法的 JSON 对象。如果格式错误，系统会自动触发一次 JSON 修复循环——拿原始输出和错误信息，让模型重新生成一次。
第二层： 证据溯源校验。每个 issue 的 evidenceRefs 引用的节点、连线、网关、泳道，必须在证据账本中真实存在。不能引用一个不存在的节点 ID。
第三层： 分类和级别校验。categoryCode 和 severity 必须在预设的枚举值范围内。模型不能自己发明新的分类。
第四层： 去重。基于 issueKey + title 的指纹去重，同一个问题不会出现两次。
经过这四层，能漏出来的问题已经非常少了。
数据说话：50 个用例，100% 命中
我们建了一套合成评测集，50 个用例，覆盖了 20 种不同的缺陷模式——空来源、空去向、未定义节点、缺少结束状态、条件文字误作活动、网关单出口、退回条件不清、职责重复、评审节点断连、关联文件为空、图名目标不一致、文件销毁路径缺失……以及它们的组合场景。
每个用例都有明确标注的预期 issueKeys。然后用 Harness 方案跑一遍，对比预期和实际输出。
结果：
50 个用例，零阻塞，零格式错误，召回和精确双双超过 95%。
在这之前，我们拿 5 个真实流程文件做了金标复核评测——请流程专家逐条标注了预期问题。Harness 方案在这 5 个真实案例上的成绩是： 召回 ≥ 95%，精确率 ≥ 85%。
稳定性方面也做了压测：50 并发请求，321 QPS，100% 成功率。P50 延迟 103ms，P95 126ms。
对比一下直觉方案——直接让模型输出——在我们内部的测试中，同样这批用例，准确率大概在 40%～60%。而且格式稳定性极差，JSON 解析失败率高达 20%～30%。
为什么这个方法论可以迁移
你可能会想：这是个流程检查场景，如果我的场景是合同审查、代码审查、病历质检、招标文件检查……这个方法还能用吗？
完全能。
因为 Harness Engineering 的底层逻辑是通用的：
第一，能确定的就不要用模型。任何可以用规则、正则、结构分析解决的问题，用确定性计算。又快又准，零幻觉。模型只用来处理真正需要语义判断的部分。
第二，给模型的数据要极度克制。不是"信息越多越好"，而是"只给它需要看到的那部分"。信息过载是幻觉的主要来源之一。
第三，永远不要信任模型的输出格式。JSON 验证、字段校验、证据溯源、去重——这一套校验链必须做。模型输出不是终点，验证通过的输出才是。
第四，拆解比一体化更可靠。一个复杂任务拆成 N 个小任务，每个小任务独立执行、独立验证，出问题也只影响一个局部。而且你可以精确地知道哪个 Skill 在哪种场景下容易出错，针对性地优化。
第五，评测集要建，而且要持续更新。没有评测集，你说"准确率很高"是没有说服力的。评测集要覆盖：正常场景（无问题）、单缺陷场景、组合缺陷场景、边界场景。每次改模型或改提示词，跑一遍评测，马上知道有没有退化。
这套方法论，本质上就是在做一个事： 把 AI 的不确定性，用工程手段一步步压缩到可接受的范围内。
它不是魔法，它就是传统的软件工程质量控制思想，搬到了 AI 应用里。
我们这个项目还在持续迭代。Harness 规则引擎目前覆盖了大约 60% 的检查项，还有 40% 依赖模型。下一步的目标是把更多语义检查项逐步迁移到确定性规则里——因为越确定，越可靠。
如果你也在做类似的"AI 审查/检查/质检"类产品，希望这个实践能给你一些启发。至少，下次有人告诉你"这个场景接个 AI 就行了"，你可以跟他聊聊 Harness 了。