把业务经验变成机器能够执行的判断：搭建智能体时，规则引擎究竟在解决什么

设想这样一个场景。

一位熟悉合同审查的业务人员，拿出公司的管理制度、合同模板和历年积累的审查要点，交给开发者：“这些就是我们的规则，你把它们做进智能体里。”

开发者把材料整理好，接入知识库，再给模型写一段提示词：你是一名经验丰富的合同审查专家，请严格依据公司制度识别风险，逐条列明依据并提出修改建议。

系统很快就能工作。上传合同，等待片刻，一份措辞专业、结构完整、引用充分的报告就出现在屏幕上。付款条件、违约责任、争议解决，各个方面似乎都考虑到了。

问题往往出现在后续使用中。

同样一种付款安排，换一种说法，系统可能不再提示；某个条款单独看没有问题，与另一条组合起来却明显不利，系统没有发现；合同没有附上审批材料，系统直接判断“未经审批”；某项企业内部要求，被写成了适用于所有合同的普遍标准。

业务人员说：“规则已经给你了，为什么还会判断错？”

开发者也很困惑：“这些要求有些靠关键词，有些要提取金额，有些必须理解上下文，还有些需要知道你们公司的实际情况。到底应该怎么做？”

双方都觉得自己已经表达清楚。真正没有被表达出来的，是从业务材料到具体结论之间的判断过程。

这也是许多智能体建设中容易被低估的一项工作：把业务人员脑中的理解、经验、取舍和例外，整理成系统可以识别、执行、检查和维护的决策逻辑。

AI 编程工具让更多人能够搭建自己的应用。这件事非常有价值。业务人员可以直接描述需求，看到原型，修改界面，连接模型和工具。但生成代码越容易，一个问题就越突出：我们是否已经足够准确地描述了希望系统执行的业务？

一套系统可以在技术上顺利运行，同时在业务上持续执行一种未经确认的理解。

讨论规则引擎，最终需要回到这里。

“规则”这个词，首先就值得拆开理解。

在实际交流中，人们经常用同一个词指代不同的东西。

“合同应当明确付款条件”，可能是一项管理要求。

“重点检查付款时间、付款比例和付款前提”，是一份检查清单。

“识别对我方不利的付款安排”，是一项任务指令。

“预付款比例超过企业设定的上限时，触发专项审批”，更接近一项业务决策规则。

“从合同中识别预付款金额，并除以适用的合同总金额”，则涉及事实提取和计算。

这些东西彼此相关，却不能直接相互替代。

一份检查清单告诉系统“看哪里”，但未必告诉系统“怎样判断”。一项制度要求说明“应当满足什么”，但未必定义了所有适用条件。一句提示词可以让模型开展分析，却不自动构成一个边界清楚、行为可预测的决策程序。

技术领域中的规则引擎，通常负责按照明确表达的规则，对输入事实进行匹配、计算或推导，再产生结论或触发动作。以 Drools 为例，其官方文档区分事实、规则和执行调度：事实进入系统后，满足条件的规则具备执行资格；多条规则同时满足时，还需要处理执行次序和相互影响。Drools 规则引擎文档

这类机制说明了一件事：规则引擎关心的不只是“保存了哪些规则文本”，还包括这些规则怎样作用于事实。

与此同时，业务意义上的规则，可以先以自然语言存在。它不必一开始就是代码，也不必因为尚未形式化就被视为“假规则”。需要区分的是：它目前属于业务要求、待澄清的判断标准，还是已经能够被特定系统执行的逻辑。

这个区分能减少很多争论。

“系统里已经有五百条规则”，可能意味着收集了五百条制度摘录，也可能意味着建立了五百个经过验证的决策单元。数字相同，能力差异可以很大。

知识库提供依据，规则执行还需要明确的判断过程。

把法规、制度、操作手册接入 AI，是有价值的。

典型的检索增强生成，也就是 RAG，会先从外部资料中检索相关内容，再把这些内容提供给模型，用于生成答案。提出 RAG 的代表性研究，讨论的正是如何将模型自身的参数化知识与外部可检索的信息结合起来。Lewis 等：Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

因此，面对“公司对预付款有什么要求”这样的问题，RAG 可以帮助系统找到相关制度，说明要求，标注出处。

但是，从“找到要求”到“判断这份合同是否符合要求”，还需要处理合同类型、交易角色、金额口径、例外条件、材料完整性等问题。

这里也需要避免把技术边界说得过于绝对。RAG 系统可以结合结构化查询、计算工具和验证程序，形成复杂的业务系统；模型也可以在得到相关制度后作出相当有用的判断。只是，检索这一机制本身，不保证业务判断已经被完整定义，也不保证所有必须执行的检查都已经执行。

另一方面，直接把全部制度放进提示词，未必发生了检索，严格说也就不一定属于 RAG。它仍然可能只是向模型提供了更多上下文。

判断一个产品有没有形成可执行的规则能力，更有用的问题是：

给定一组明确的业务事实，系统依据哪一版标准，经过哪些条件判断，为什么得出这个结论？换一个关键条件，结论应当怎样变化？信息缺失时，又应当怎样处理？

这些问题能把讨论从“模型看过什么材料”，推进到“系统究竟执行了什么判断”。

用一个付款条款，就能看见隐藏在业务经验里的复杂性。

以下案例和企业标准均为解释机制而构造，不对应某家企业的实际制度。

假设我方是一家提供设备及安装服务的公司，合同中写着：

甲方在项目最终验收通过，并收到业主相应款项后，三十日内向乙方支付剩余合同价款。

初学者可能觉得，这个条款已经明确了付款时间：三十日。

有经验的业务人员则可能停下来，继续寻找几件事：谁负责组织验收？验收有没有期限？如果甲方迟迟不组织验收怎么办？“收到业主相应款项”是不是付款的必要条件？业主一直不付款，我方是否只能等待？其他条款有没有独立的最迟付款期限？

同一句话，不同的人看到了不同层次的信息。

“三十日内”只是条件满足以后的付款期限。它并没有自动解决条件何时能够满足的问题。

可以把这个安排理解为一扇门：门打开以后，三十日内付款。但门什么时候打开，谁掌握钥匙，是否存在另一条通道，仍然需要检查。

业务人员所谓的“付款风险”，可能就藏在这里。

如果开发者把这项经验写成“出现‘收到业主款项后’就提示风险”，系统能够识别一部分情况。但遇到下面的条款，又会怎样？

甲方收到业主相应款项后支付，但无论业主是否付款，均应于设备交付满九十日之日前付清相应价款。

这一次，文本中仍然出现了对第三方付款的引用，却增加了一个独立的最迟付款安排。它可能改变我们对“付款无限期悬而未决”这一特定问题的判断。

当然，这并不意味着整个条款已经没有其他风险。九十日是否符合企业要求、设备交付日如何确认、是否另有延期约定，还需要分别检查。

再看第三种情况：

付款条件按照附件三执行。

如果附件三没有提供，系统能否直接判断“合同未约定付款条件”？

不能。系统目前掌握的事实是：正文引用了付款附件，而当前材料中缺少该附件。

这几种情况说明，一项看似简单的审查经验，至少包含了适用立场、条件识别、关系理解、例外检查和证据判断。

把它写成一句“检查付款风险”，这些工作就全部留给了模型临场完成。把它写成一个关键词，又会丢掉其中的大部分含义。

设计规则时，需要把“取得事实”和“评价事实”分开。

在智能体开发中，数据提取、关键词匹配、语义分析、数值计算，经常被并列称为几类规则。这种分类有助于介绍技术手段，却不足以完整描述业务决策。

因为它们处理的问题并不处于同一层。

从合同中找出金额，属于取得事实；判断金额是否超过上限，属于执行标准。从文本中理解谁承担责任，属于语义识别；判断这种责任分配是否符合企业要求，则还需要业务立场和评价依据。

以前面的付款案例为例，可以把系统需要完成的工作分成五个环节：

这张表是一种解释和设计方法，不意味着系统必须拆成五个服务，也不要求调用五次模型。一个很小的程序，也可以清楚地保留这些职责。

这样拆分的价值，在于问题发生时能够定位原因。

如果系统没有找到付款条款，应当检查文档解析、检索或提取。

如果条款找到了，却把“同时满足”理解成“任一满足”，应当检查关系识别。

如果事实理解正确，但适用了付款方的标准，应当检查业务范围。

如果判断正确，却未经许可自动修改合同，应当检查处置和权限。

把这些问题全部归结为“模型不够聪明”，会让改进失去方向。

所谓确定性，必须说明是哪个环节的确定性。

假设一家企业设定：某类采购合同的预付款比例超过 30%，需要专项审批。

当预付款金额、合同金额和适用口径都已经确定时，计算比例并比较阈值，可以交给普通程序完成。系统没有必要每次都请模型重新思考“三十五是否大于三十”。

但如果模型把进度款识别成了预付款，或者把不含税金额与含税金额混在一起，程序仍然会准确地算出一个错误口径下的结果。

这时，执行是稳定的，业务结论却不可靠。

因此，至少应当分别检查三件事：输入事实是否可靠，判断标准是否清楚，执行过程是否符合标准。

进一步说，可复现也有条件。规则版本、输入事实、适用日期、外部数据、金额精度、时间口径等因素需要固定。对于会修改状态或触发外部动作的规则，还需要约束执行顺序及副作用。

“使用了规则引擎”并不会让这些条件自动成立。

关键词匹配也有同样的问题。它可以非常稳定地找到“提供担保”四个字，却无法仅凭这四个字区分“乙方应提供担保”和“乙方无需提供担保”。

稳定地匹配到了文字，只能证明匹配操作按预期执行。

语义模型在这里有自己的价值。它能够帮助识别否定、条件、角色、指代和跨句关系，将不同表述转化成可供后续处理的事实候选。

但事实候选应当带着证据进入系统。例如：

“付款依赖第三方回款”，对应合同中的哪句话？“存在独立最迟期限”，由哪一条支持？如果两条约定发生冲突，系统是否保留了冲突，而不是悄悄选择其中一条？

结构化输出可以让这些信息更容易处理，却不能单独保证内容正确。一个格式完全合法的 JSON，也可以装着提取错误的金额和并不存在的条款含义。

业务与技术之间，首先需要一套共同理解的词汇。

“付款期限”看起来是一个简单字段。

业务人员可能把它理解为“我方最迟何时能收到钱”；开发者可能把它实现成“文本中出现的付款天数”；模型则可能提取出“验收后三十日”。

三个人都认为自己在谈同一个字段，实际含义却不一样。

这样的偏差不会通过增加提示词长度自然消失。需要有人明确：我们到底要描述哪个事实？

在付款案例中，至少可以区分“条件满足后的支付期限”“触发条件本身的完成期限”和“不依赖该条件的最迟付款日期”。

这三个概念是否需要分别建字段，取决于当前业务需求。但在讨论判断标准时，必须知道它们不同。

业务词汇的明确化，是长期存在的工程问题。OMG 的 SBVR 标准专门讨论业务词汇和业务规则的语义表达，说明业务概念的定义本身就是连接业务与技术的重要工作。OMG：SBVR 规范

对刚开始搭建智能体的人来说，不必先学习整套标准。可以从一个简单动作开始：每当一个词影响判断，就为它写下定义和例子。

什么叫“预付款”？合同名称叫“预付款”的款项一定算吗？虽然叫“首期款”，但在交付前支付，是否也应纳入？如果企业内部有特定统计口径，以哪一版为准？

什么叫“已经审批”？有一张截图是否足够？审批人是否具备权限？批准的是哪份合同、哪个金额、哪项偏离？旧版本合同的审批能否覆盖修改后的条款？

词汇一旦展开，很多被误认为是“技术细节”的问题，就会显露出业务决策的性质。

开发者可以帮助发现这些问题，AI 也可以生成待确认清单。但它们不能替企业默默决定这些口径。

业务人员主导梳理规则，需要一种能够把经验问出来的方法。

让一位资深审查人员“把你知道的规则全部写下来”，很容易得到一份覆盖面很广、表达却相当抽象的清单。

付款条件应当明确，责任分配应当合理，履约保障应当充分，争议解决应当有利于我方。

这些表述并非没有价值。它们总结了关注方向。但是，真正体现经验的部分，往往存在于具体情境中：为什么这份合同要改，另一份却可以接受？为什么这个条件单独看无所谓，和另一条件同时出现就需要警惕？

认知任务分析研究长期关注这类问题。Militello 与 Hutton 提出的应用认知任务分析方法，就通过任务梳理、知识访谈和情境讨论，帮助理解熟练工作所依赖的认知要求。它为“怎样把专家经验说出来”提供了可以借鉴的思路。Militello 与 Hutton：Applied Cognitive Task Analysis

把这个思路用于智能体建设，可以从一次具体的审查开始。

拿出一份业务人员认为有问题的合同，请他指出第一次引起注意的地方。先不要求总结通用规则，而是沿着当时的判断继续追问：

“你看到哪句话时，开始觉得需要进一步检查？”

“为了确认这个问题，你又看了哪些条款？”

“如果没有后面那项约定，你的结论会不会变化？”

“这个判断有没有用到合同以外的信息？”

“什么情况下，即使出现这句话，你仍然会接受？”

“缺少什么材料时，你会暂时不下结论？”

这些问题分别在寻找线索、依赖、边界、外部事实、例外和停止条件。

尤其有用的是改变单一条件。

保留第三方回款前提，增加一个独立最迟付款日期，判断如何变化？保留付款安排，把我方从收款方换成付款方，原来的关注点是否仍然适用？保留所有合同文字，只是缺少被引用的附件，系统应该输出什么？

每一次这样的对比，都在帮助双方找到结论变化的原因。

当然，专家对自己判断过程的解释也需要验证。事后解释可能遗漏细节，不同人员可能使用不同标准。同一份合同，法务、财务、采购和业务负责人也可能关心不同问题。

这时，出现分歧本身就是重要发现。

有的分歧来自信息不同，可以通过补充材料解决；有的来自术语不一致，需要统一定义；还有的来自风险偏好和管理权限，需要由组织明确标准。

如果某项判断尚未形成共识，就应当保留为待确认标准或专业复核事项。让模型从几种意见里挑一个，并不会自动形成企业共识。

经验被提取出来以后，还需要确认它具有什么效力。

“我们以前一直这样做”，可以是一条有价值的线索。

但它可能代表个人习惯、团队惯例、某个客户的特殊要求，也可能确实来自正式制度。这几种来源，需要区别对待。

假设一位业务人员说：“尾款超过 10%，我们一般都要求改。”

继续追问，可能发现：这是特定产品线的经验，因为售后阶段容易出现回款争议；也可能只是某位负责人偏好的谈判起点，并非不可突破的底线。

如果系统将它固化为所有合同的硬性拦截规则，经验的适用范围就被扩大了。

因此，规则的形成应当包含两个问题：这项判断是否有用，以及它被授权适用于哪些场景。

类似地，外部规范、企业制度、交易惯例和商业偏好，也不宜在输出中混成一种结论。“触发企业内部审批要求”“存在需要关注的商业风险”“需要进一步核实外部规范的适用性”，表达的是不同性质的判断。

给每条规则记录来源和适用范围，有助于避免这种混淆。但来源字段本身还不够，必要时还要保留版本、有效时间、解释责任人和例外权限。

这里的核心责任仍然在业务侧。

技术人员可以组织讨论、设计表示方式、发现矛盾；AI 可以整理材料、提出候选规则、生成反例。最终，“这是不是我们希望系统执行的标准”，需要由有权确认该标准的人回答。

业务人员主导，意味着对判断标准及其边界负责；它不要求业务人员独自完成所有技术表达。

双方可以用一张“规则说明卡”建立共同的工作对象。

围绕抽象词汇反复讨论，容易各说各话。把判断写成一份短而具体的说明，再配上案例，会更容易发现遗漏。

以前面的付款问题为例，可以形成这样一张说明卡：

这张卡仍然是业务说明，不是可以直接投入生产的完整算法。其中“我方难以推动”“独立最迟付款安排”等概念，还需要根据真实需求继续澄清。

它的价值在于把不清楚的地方摆到桌面上。

开发者不必猜测：找到风险以后，是直接禁止提交，还是提示负责人确认？

业务人员也能发现：自己原本以为十分明确的“付款有期限”，其实存在几种完全不同的含义。

当条件已经足够清楚时，可以进一步写成决策表。OMG 的 DMN 标准就是围绕业务决策及其依赖关系展开建模，并支持使用明确的决策表表达逻辑。OMG：Decision Model and Notation

例如，针对某一个已被企业确认的关注点，可以先整理出如下分支：

这里的“本项不触发”，只针对这一项检查，不能扩展成“合同没有风险”。

这张表也不是完整的 DMN 可执行模型。真正落地时，还需要定义输入字段的含义、分支是否互斥，以及边界情况如何处理。

但对于业务与技术协作而言，这种中间表达通常比“你再优化一下提示词”更能推进工作。

一项业务判断，可以由多种技术共同完成。

到这里，再讨论技术选型，就有了具体依据。

关键词适合快速定位明显线索。例如，“以……为前提”“收到……后”“另行协商”等表达，可以作为扩大检索范围的入口。不过，命中后仍然可能需要检查否定、例外、指代和条款关系。

数值计算适合处理已经明确口径的金额、比例、日期和期限。它的重点在于先定义字段和单位，再交给程序计算。

结构化提取适合把合同中的角色、金额、事件、条件等转成便于处理的信息。提取结果应当保留出处，并允许未知或冲突状态。

语义分析适合识别不同表达是否具有相近含义，理解条件之间的关系，判断某段文字是否支持一个具体命题。

合同研究中就有这样的任务设计。ContractNLI 将合同理解表述为：给定一个命题，判断合同支持它、与它矛盾，还是没有提及，并找出支持判断的证据片段。这种任务划分说明，“理解合同”可以被拆成比“给一份综合意见”更具体的能力。Koreeda 与 Manning：ContractNLI

但语义识别完成后，仍然需要企业自己的评价标准。“合同支持这个命题”，与“这个安排符合我方要求”，不是同一个判断。

在实践中，可以让模型帮助回答较窄的问题：付款是否以第三方回款为必要前提？某个期限是否独立于该前提？特别条款是否修改了通用条款中的条件？

随后，由明确的业务逻辑组合这些结果。

对于暂时无法清楚形式化、又需要专业判断的问题，也可以保留模型辅助分析和人工复核。关键是把它的性质标明，避免让一个开放式评价冒充严格确定的检查结果。

这里不存在一个普遍有效的比例，例如“八成必须写成规则，两成交给模型”。合理分工取决于任务、材料、后果和实际验证结果。

模型能力变强，可能让事实识别和语义判断做得更好；它不会自动决定企业愿意承受多大的风险，也不会自动取得改变企业政策的权限。

“没有找到”与“确认不存在”，是审查系统必须认真区分的两件事。

假设系统检索了五个相关片段，没有找到最迟付款期限。

现在能说什么？

可以说，在这些片段中没有找到。

如果系统已经覆盖正文、附表和相关附件，并检查了付款条款引用的定义及特别约定，才有更充分的依据对当前材料作出范围明确的缺失判断。即便如此，语义识别仍可能发生遗漏，因此结论还应与系统经过验证的能力相匹配。

这个问题在智能体中尤其常见，因为很多流程依赖检索。检索最相关的几段文本，适合寻找支持信息，但“没有检索到”通常不足以证明整份材料不存在某项内容。

存在性和缺失性判断，需要不同的证据要求。

发现某个条款，可以用该条款作为证据；声称合同没有某项约定，则需要说明检查过的范围，以及是否存在未解析页面、缺失附件或未展开的引用。

因此，一个实用的系统不应只有“通过”和“不通过”。

至少应当在设计中区分：适用且触发、适用但未触发、不适用、事实不足，以及执行失败。实际项目可以选择适合自己的状态名称，但不能把这些情况全部压成一个布尔值。

OCR 失败不意味着条款缺失。模型调用超时不意味着没有风险。审批材料未提供不意味着没有审批。没有触发某项规则，也不意味着合同整体可接受。

这种区分会直接影响产品行为。

事实不足时，可以请求补充材料；执行失败时，可以重试或告知该项检查未完成；确认触发风险时，才进入对应的处理流程。

用户看到一片绿色之前，应当知道那片绿色表示“已经完成哪些检查”，而不是仅仅“程序没有输出红色提示”。

规则之间的组合，也属于业务设计。

一份合同可能同时触发很多条件。

预付款比例偏高，但提供了某种履约保障；付款期限较长，但价格条件更有利；某个责任条款偏离模板，却经过了特定权限的批准。

这些条件怎样共同影响结论，需要明确的业务安排。

最简单的做法是分别输出各项发现，交给业务人员综合判断。只要适合当前任务，这就是一种合理设计。

如果希望系统进一步给出综合处置，则需要定义条件之间的关系：全部满足才触发，任一满足就触发，满足若干项后升级，还是某项条件会改变另一项规则的适用性？

不要把不同关注点随意相加成一个看似精确的总分。能否相互抵消、权重应当是多少、分数与处置怎样对应，都需要业务依据和验证。

审批例外也需要拆开理解。某项偏离被批准，可以改变流程上的处置，但相关商业风险未必因此消失。系统可以同时记录“触发风险条件”和“已取得相应例外批准”。

同样，多条规则同时匹配时，采用什么结果也需要说明。DMN 决策表中的命中策略，就区分只允许一条匹配、按顺序取第一条，以及收集多条结果等不同方式。Drools：DMN 决策表命中策略

这些机制提供表达能力，具体选择仍然属于业务设计。列表中恰好排在前面的规则，不应在没有约定的情况下自动成为企业政策上的优先规则。

还有一种容易忽视的组合关系，来自条款之间的引用。

正文说按附件执行，附件引用验收标准，特别条款又修改了验收后的付款安排。如果系统只看某一段文字，就可能遗漏决定结论的条件。

不一定每个项目都需要知识图谱或复杂推理框架，但至少需要在当前任务范围内处理真正影响判断的引用和覆盖关系。先把最重要的关系做好，通常比引入一套难以验证的宏大架构更实际。

让智能体寻找信息，同时为必须执行的检查保留明确责任。

智能体可以根据中间结果继续检索、调用工具、读取附件或请求补充材料。这种灵活性很适合处理路径不完全固定的工作。

但是，如果某些检查属于明确要求，就需要知道它们是否实际执行。

例如，一家公司规定所有特定采购合同都要检查付款比例、收款账户和签署主体。若系统每次只通过语义检索选出“看起来最相关的规则”，某项必要检查可能根本没有进入执行过程。

一个可行的设计是：通过明确的适用条件确定必须执行的检查集合，同时允许智能体补充探索其他可能的问题。最后记录每项检查的状态，区分已完成、待材料和执行失败。

这也是工作流与智能体可以共同发挥作用的地方。Anthropic 在其工程文章中区分了预定义路径的工作流和由模型动态决定执行路径的智能体，并建议从能够满足需求的简单方案开始，再按实际需要增加复杂度。Anthropic：Building Effective Agents

应用到合同场景，可以让系统明确安排必要检查，让模型灵活寻找事实，让普通程序处理明确计算，再把专业裁量交给适当的人。

这样的系统可能没有一个“全知全能的审查代理”，却能够清楚回答用户最关心的问题：这次检查做到了哪里，还有哪些地方没有完成。

最能打通业务与技术壁垒的，往往是一组共同确认的案例。

业务人员说“这个判断不对”，开发者需要知道预期结果是什么，以及为什么。

开发者说“测试已经通过”，业务人员需要知道测试覆盖了哪些真实情形。

双方可以共同维护一组小而具体的案例。每个案例至少包括输入材料、预期结果，以及决定该结果的关键理由。

以前面的付款问题为例：

这些案例一方面是测试，另一方面也是业务说明。很多抽象概念，在看到对照案例以后会变得清楚。

NLP 研究中的 CheckList 提倡从具体行为出发测试模型，包括最小功能测试、应当保持结果不变的变化，以及应当让结果按特定方向变化的情况。这为上述测试设计提供了方法上的参考。Ribeiro 等：Beyond Accuracy

还需要把规则逻辑和语言理解分开验证。

可以先给决策程序一组人工确认的结构化事实，检查它是否按标准执行；再把真实合同交给提取和语义模块，检查它能否得到相应事实；最后运行完整流程，检查实际输出和处置。

如果只测试最终报告，就难以知道错误发生在哪一步。

如果只测试提取字段，也不能证明业务结论正确。

在重要情形下，还应检查多次运行的稳定性，以及更换模型、提示词或文档解析方式以后是否出现退步。AI 可以帮助生成测试变体，但关键案例的预期结果仍需业务确认，否则容易出现模型提出标准、模型实现标准、模型又自行宣布通过的循环。

评价指标也需要与任务对应。

在一个假设的数据集中，如果一百个案例里只有五个真正需要提示，系统全部回答“未发现问题”，表面准确率仍然可以达到 95%。这个数字对风险发现能力几乎没有帮助。

因此，需要分别观察该发现的问题发现了多少、提示出来的问题有多少成立、证据定位是否正确，以及多少任务因为材料或能力限制尚未完成。

还应当关注人工复核负担。过多误报会迫使用户逐项排查，而把大量困难案例全部转交人工，虽然可能降低自动误判，却也限制了系统实际完成的工作。

对于模型自行给出的“置信度”，同样需要谨慎解释。一个输出为 0.95 的分数，并不会天然意味着在相似业务案例中有 95% 的正确率。关于语言模型置信度校准的研究，也专门讨论如何让表达出来的概率与实际正确性更好对应。Calibrating Verbalized Probabilities for Large Language Models

在具体系统里，这类分数可以作为经过验证的辅助信号，不能替代证据、业务标准和案例测试。

从一个完整的小判断开始，比先收集几百条规则更容易形成可靠能力。

对于通过 AI 工具开发自己的智能体的人，最实用的起点通常是一个范围明确、价值清楚、能够验证的问题。

例如，先完成某类合同中的预付款比例检查，或者先完成某一种付款前提的识别与提示。

选定问题以后，先确认业务目的和适用范围，再收集少量有代表性的案例。围绕这些案例定义所需事实、触发条件、例外、未知状态和预期输出，然后再让 AI 帮忙实现。

第一版完全可以只是几个字段、一段判断逻辑、一张表和一组测试。业务判断足够简单时，普通函数就是合适的执行方式。规则数量增加、维护频繁，或者需要复杂匹配与组合后，再考虑引入专门引擎。

工具选择应当服务于已经确认的问题。

一个判断清楚、案例充分的小功能，可以帮助你建立后续工作的模式：怎样提问，怎样记录规则，怎样处理证据，怎样判断完成。

相反，如果一开始就让 AI “根据这些资料生成五百条规则并搭建完整审查平台”，它可能很快生成可观的内容，却把大量尚未解决的业务问题一起固化下来。后续每增加一条规则，都可能增加重叠、矛盾和维护负担。

规则复用也应当围绕事实和判断关系展开。同一项付款事实，可能服务于期限检查、资金占用评估和审批判断。如果每条规则都独立让模型重新提取一遍，不同结果就可能在系统里并存。

在适合的范围内共享已确认事实、记录来源、明确更新后哪些判断需要重新计算，可以减少这种不一致。

这里仍然应当保持克制。当前只有几个简单检查，就不必为未来假想的规模搭建复杂平台。先让每一项能力的输入、输出和边界清楚，再逐步扩展。

一项判断投入使用以后，还需要能够解释它是怎样产生的。

用户收到一条风险提示，通常会问：你依据哪段合同，使用哪项标准，为什么认为适用，有没有考虑那个例外？

系统最好能够直接展示这些信息。

这类解释可以来自执行记录：合同原文位置、提取出的事实、规则版本、命中的条件、未满足的例外，以及仍然缺失的材料。

它与让模型事后编写一段听起来合理的解释，有不同的证据基础。即使使用模型改善表达，内容也应当受到已记录事实和判断结果的约束。

政策执行系统中已有类似实践。例如，Open Policy Agent 的决策日志可以记录被查询的政策、输入以及相关版本元数据，支持审计和离线调试。具体项目不一定需要使用 OPA，但这种记录思路值得借鉴。Open Policy Agent：Decision Logs

规则也会变化。

企业调整风险偏好，合同模板发生修改，原本少见的交易方式变得普遍。此时需要知道：改动影响哪些场景，旧案例的预期结果是否应当变化，过去的结论依据的是哪个版本。

评估的作用因此不止于上线验收。它还帮助团队在规则、模型和工具变化时保持可比较的质量。Anthropic 关于智能体评估的文章也强调，应当根据任务结合程序检查、模型评价和人工判断，并关注实际完成的结果，而不仅是代理声称自己完成了什么。Anthropic：Demystifying Evals for AI Agents

对初学者而言，不必把这些工作理解为一套沉重的管理体系。开始时，保存规则版本、代表案例和必要的执行记录，就已经能解决许多实际问题。

重要的是，当系统行为变化时，你能够找到变化发生在哪里。

搭建业务智能体，会迫使团队重新认识自己的业务。

在人工工作中，很多缺口由经验补齐。

制度写得宽泛，熟悉业务的人知道怎样理解；材料不完整，审查人员知道应该追问；出现特殊交易，团队可以通过讨论作出处理。这些能力存在于日常协作中，未必被完整写下来。

当工作交给系统以后，这些原本由人随时补充的部分，需要以某种形式出现：成为输入要求、适用条件、判断逻辑、例外处理，或者明确保留的人工作业。

因此，业务人员与技术人员之间的壁垒，往往需要通过共同建模逐步打通。

业务人员贡献目的、经验、判断边界和可接受的处置；技术人员把这些内容组织成可执行、可观察和可测试的机制；AI 帮助双方整理材料、暴露歧义、产生候选表达，并承担适合语言理解的工作。

这个过程也会反过来改善业务本身。团队可能发现同一个术语一直存在两种解释，一项所谓底线实际上允许多种例外，或者某条习惯从未被认真讨论过适用范围。

智能体建设由此提供了一次机会：把原本分散在不同人员、文档和案例中的判断，变成可以共同检查、持续修正的组织知识。

规则引擎在其中承担的，是执行已经表达清楚的那部分逻辑。知识库帮助找到依据，语义模型帮助理解材料，工作流安排行动，人工判断处理需要裁量或尚未解决的问题。它们共同决定系统能够完成什么。

回到最开始那句“这些就是我们的规则，你把它们做进智能体里”。

更有效的协作，可以从一份具体合同开始。业务人员指出一处他认为值得警惕的付款安排，开发者问清判断所依赖的事实，双方一起修改一个条件，看看结论是否应该变化，再把这组差异写成系统需要通过的案例。

当他们能够共同解释“为什么这份需要提示，那份可以接受，还有一份目前不能判断”时，一项真正可实现的业务能力就开始形成了。

对正在用 AI 搭建自己工具的人而言，这也是最值得亲自掌握的能力：把业务判断讲清楚，确认它应当在什么条件下成立，并用具体案例检查系统是否确实按这个意思工作。代码可以由工具协助生成，判断标准的形成与确认，仍然需要理解业务、承担相应责任的人参与。