不上前十不改名前阵子我们团队把跑通的Agent Demo，用开源框架openJiuwen加Skills机制，改造成了一个真正能审招标文件的合规引擎。业务部门说得直白：他们不要一个什么都能聊的百事通，要的是一个能在十分钟内把几百页招标文件翻完、把风险条款标出来、并且敢对结论负责的东西。这个问题背后，其实是所有做Agent落地的人都绕不开的一道坎——通用Agent再强，一旦放进生产场景，尤其是招标文件合规审查这种必须可解释、可追溯、低误报的活，直接拿通用方案硬上，大概率会被业务方当场劝退。我们走通的路线，算不上炫技，但把从思路到实现的关键环节都摸了一遍，这篇文章不聊空概念，只讲我们怎么拆模块、怎么封Skill、怎么压误报、怎么上线。
如果你正在做垂直场景的Agent工程化，或者准备把一个大模型Demo变成业务系统里真正被使用的工具，这篇内容应该能给你省掉几周的试错时间。
1. 为什么通用Agent改不动：问题诊断比技术选型更关键
1.1 Demo很美好，生产环境全是意外
通用Agent在Demo阶段的表现是很唬人的。拿几份排版规范的示例PDF丢进去，问“这份招标文件里有没有注册资金要求”，它能对答如流，引用的段落也很像那么回事。这也是为什么很多团队一开始都想直接拿通用Agent套业务。但一旦进入真实招标文件，问题就成片地冒出来：扫描件歪歪扭扭、目录页码对不上、表格跨页断行、附件里的技术规范书比正文还厚、同样一个资质要求在不同章节里表述还不一样。
更深层的问题是范式不匹配。对话式Agent的设计逻辑是“人问它答，答完结束”，而招标文件合规审查是一个标准的“任务执行”过程：给定一组文件，按既定流程逐项核查，输出结构化的风险报告。它不是回答一个问题，而是要完成一遍完整的审查。让一个聊天机器人去完成审查任务，就好比让一个能说会道的顾问去顶替一个按SOP操作的质检员——前者能讲出很多道理，但后者才能给出能归档的结论。
1.2 业务真正要的不是对话，是受控的任务流
我们最开始和业务部门对齐需求时，对方只提了三个要求：风险结论要准、每条结论都要有依据、覆盖率要能量化。这三个要求本质上就把“通用问答”这条路堵死了。准，意味着不能靠模型自由发挥；有依据，意味着每一条判断都要能引到文件原文；量化覆盖率，意味着引擎必须知道自己查了哪些条款、漏了哪些条款。
所以我们在设计之初就做了一个关键决定：把自由问答降级为受控执行。模型不能随心所欲地表态，它只能在配置好的规则框架内做抽取、比对和解释。这个决定听起来保守，但正是它能上生产环境的原因。业务系统不需要一个创新发言者，它需要一个稳定、可审计、可复现的审查工具。
1.3 为什么选择openJiuwen做底座，而不是自己造框架
选型时我们对比过自研编排器和几个主流的开源Agent框架。自研编排器的坑我们很清楚：第一版看着简单，后面补任务状态管理、补上下文隔离、补日志链路，越补越像个半吊子框架，而且还要花人力长期维护。openJiuwen打动我们的点，是它把Agent的“能力扩展”做成了标准机制——Skill。Skill有清晰的元信息描述、加载生命周期、输入输出约束，还有任务级别的上下文隔离。这些能力恰恰是合规引擎最需要的：每个文件审查是一个独立任务，任务之间不能串状态；每个能力包可以单独升级，不影响整体流程；框架自带可观测日志，方便定位是哪一步出了问题。
当然它不是万能的，后面我们也在上面补了不少胶水代码，但作为底座，它让我们把精力集中在业务规则和审查流程上，而不是反复造Agent框架的轮子。
1.4 把Agent收敛成引擎：整体架构怎么切
整个合规引擎从逻辑上分成四层。最下面是文档接入与解析层，负责把PDF、Word、扫描件变成可检索的结构化文本；往上是规则表达层，把招标文件里的各种要求抽象成可配置的规则项；中间是Agent执行层，由openJiuwen编排多个Skill协作完成任务，这里面基座模型只扮演“阅读理解器”的角色，负责从文本中抽取关键信息，不做最终裁判；最上层是人工复核与集成层，输出带证据链的报告，接收业务方的复核反馈。
这个分层不是拍脑袋定的，而是顺着业务方的验收逻辑倒推出来的：要能审计、能定位、能回滚。每一层的产出都要有记录，每一步的判定都要有依据。下面各章就按这个分层逐个展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 招标文件合规审查的业务拆解与规则建模
2.1 先拆清楚审查范围：四类高风险条款
想要让引擎真的具备业务价值，第一步不是写代码，而是把“合规审查”这个宽泛概念拆成具体可执行的检查项。我们和业务侧的资深评审聊了几轮，把招标文件里高频出现风险、且适合自动化核查的内容归成了四类。
第一类是资格门槛条款，比如投标人须具备某类资质证书、注册资金不低于某个数额、近三年有同类项目业绩。这类条款大多出现在“投标人须知”或“资格要求”章节，特征是硬性条件多，通常可以直接和投标文件里的资质文件做比对。第二类是实质性技术参数，往往藏在“采购需求”或“技术规格表”里，常见表述是“设备必须支持某某协议”“系统响应时间不超过X秒”，投标响应文件里的对应内容是“投标参数响应表”或技术方案。第三类是商务商务条款，比如付款方式、质保期、交付进度、培训要求，这类条款的判断不算难，但散落位置很乱，经常被漏查。第四类是废标风险项，比如投标文件未按要求签字盖章、未提供法定代表人授权书、报价超过预算控制价，这类一旦命中基本直接否决，是合规引擎优先级最高的检查项。
分类的目的是为了给规则建模划定边界。每一类条款的判定逻辑差异很大，资格门槛偏字段比对，技术参数偏语义分析，商务条款偏数值提取，废标项偏关键要素存在性判断。统一用一种方式处理，结果必然粗糙。
2.2 规则不是几个关键词，而是三层逻辑
很多团队做类似系统时，犯的第一个错误就是把规则简单理解成“关键词匹配”。比如定义“注册资金”四个字，然后在投标文件里搜，搜到了就算满足。这个做法在示例文件上看着有效，一到真实场景就漏成筛子。因为招标文件里对同一件事的表述太发散了。
真实的审查规则需要分三层来建模。
第一层是硬性规则，对应明确的数值和条件。比如“注册资金不低于1000万元”，规则可以描述成：抽取投标文件中的注册资金数值，判断是否大于等于阈值。这类规则最可靠，适合做自动判定。
第二层是语义规则，对应“换说法但意思不变”的表述。比如“注册资金不低于1000万元”可能被写成“注册资本在人民币1000万元以上”“实缴资本至少1000万”。如果只做关键词匹配，这些变体会全部漏掉。这层需要基座模型做语义归一化，把不同表述映射到同一语义槽位上。
第三层是上下文规则，这类规则只靠一句正文根本看不出来。比如某个技术要求写在附件“技术规范书”里，正文的“采购需求”章节只字未提；或者某个资质要求被拆成“主体资格+人员资格”分散在前后两个章节。上下文规则的建模依赖文档结构的解析，也依赖规则配置时的触发范围设计。
三层规则不是互相替代的关系，而是互相兜底。硬性规则保证精度，语义规则扩大召回，上下文规则覆盖隐蔽场景。我们在落地时，把三层规则都配置成了独立的检查项，并且给每个检查项标注了优先级和判定级别。
2.3 “条款-检查项-判定逻辑”的三级可配置结构
为了让业务人员不依赖开发也能维护规则，我们把规则库设计成三级结构。第一级是“条款”，对应招标文件里的某一条原始要求；第二级是“检查项”，对应这个条款要验证的具体维度，比如一条资格条款可能要拆成“证书有效性”和“注册资金下限”两个检查项；第三级是“判定逻辑”，对应每个检查项的具体判断方式，包括需要抽取的数据字段、比较运算符、阈值、输出等级。
这套结构的直接好处是复用。同一家公司重复参加多个招标项目时，很多资格条款是相似的，只是数值或证书类型不同。通过调整判定逻辑里的参数，就可以批量生成新的检查项，不需要从零写规则。我们在实际项目里维护了大约两百条基础规则模板，覆盖了大部分常见招标场景，新文件的规则初始化时间从几天压缩到了几小时。
2.4 没有测试集就上线，准不准全靠运气
规则建多了以后，会面临一个尴尬的问题：怎么知道改动一条规则不会影响另外一百条规则的效果？如果每一次规则变更都靠肉眼抽查几份文件来验证，上线后迟早出事故。
所以我们一开始就搭了离线评估集。从过往已经完成评审的项目文件里，挑了几百份有代表性的样本，让资深评审逐份标出风险条款位置、类型、判定结论。标注过程确实花时间，但它是整个项目里性价比最高的投入。有了标注集之后，每次规则库改动或者模型提示词调整，都能在一个小时内跑出量化结果：条款级召回率、误报率、定位准确率。没有这套机制，后面所有优化都是在打盲枪。
我记得第一批评估集跑出来的数据很难看，硬性条款召回率只有六成多，误报率接近三成。但正因为有这个基线，后续每一次调整是变好还是变坏，一目了然。等到上线前，硬性条款的召回率已经压到96%以上，误报率控制在12%左右，这个水平谈不上完美，但对于辅助人工复核来说已经具备生产力了。
3. Skill机制怎么把审查规则封装进引擎
3.1 把Skill当成“给Agent发的一张上岗证”
openJiuwen里的Skill，我的理解是：一个可以被动态加载执行的能力单元。它不仅仅是一段提示词，而是把能力描述、触发条件、执行工具、输入输出约束、异常处理打包在一起的一个完整模块。你可以把它类比成给Agent发了一张上岗证——它证明这个Agent在特定场景下有做某件事的资质，并且只有在这个场景下它才会被激活。
这个设计对合规引擎的价值非常大。审查流程里的每个环节，文档解析和风险判定差别巨大，如果都塞给一个庞大的提示词去控制，结果就是互相干扰。拆成多个Skill之后，每个单元只干一件事，输入和输出都有明确约束，哪个环节出了问题，日志里一查便知。
3.2 合规引擎里的五个核心Skill
我们把整个审查流程拆成了五个Skill，分工如下。
| Skill名称 | 核心输入 | 核心输出 | 控制重点 |
|---|---|---|---|
| 文档解析Skill | 原始PDF/Word文件 | 结构化文本及正文分页标记 | 解析失败时快速失败，不往下游传脏数据 |
| 条款抽取Skill | 招标文件正文 | 按章节归类的条款候选集 | 不遗漏附件和“投标人须知”里的硬性条件 |
| 规则匹配Skill | 条款候选集 + 规则库 | 命中的规则ID及抽取到的关键字段 | 区分硬性规则和语义规则，避免模型越权判断 |
| 判定复核Skill | 规则ID + 抽取字段 + 投标响应文本 | 判定结论及证据链内容 | 把所有命中和未命中项都记录在案 |
| 报告生成Skill | 全部判定结果 | 合规审查报告（含定位和引用原文） | 确保每条结论都能对应到原文页码 |
每个Skill之间只通过标准化的数据结构通信。比如条款抽取Skill的输出是一个带有章节号、页码、原文内容的条款对象列表，规则匹配Skill只认这个结构，不关心上游是怎么实现的。这样带来的好处是，任何一个Skill内部升级，只要保持数据结构不变，就不会影响其他环节。
3.3 把判定权重从提示词里抽出来
这是我们在改造过程中最核心的一个决策：不让大模型直接给合规结论下最终判断。早期版本里，我们尝试过用一段很长的提示词让模型同时完成“抽取+判断+解释”，结果在上线测试时暴露了明显的问题——模型很容易被长文本干扰，偶尔会为了迎合上下文而给出错误的合规结论。更麻烦的是，提示词里的判定规则一旦写复杂，业务人员根本没法维护审查逻辑。
后来我们调整了策略：提示词只负责“理解文本，抽取关键信息”，所有“判定逻辑”全部外置到Skill的规则配置里。举个例子，一条注册资金门槛规则在配置里长这样：
yaml复制rule_id: RS-0034
rule_name: "注册资金门槛校验"
applies_to: "投标人资格"
trigger_keywords: ["注册资金", "注册资本", "实缴资本"]
logic:
extract_fields: ["registered_capital"]
operator: "gte"
threshold: 10000000
unit: "元"
pass_condition: "extracted_value >= threshold"
fail_level: "warning"
output:
reason_template: "招标文件要求注册资金不低于{threshold}元，投标文件未提供有效证明或未达到要求"
reference_required: true
基座模型在这个流程里的角色，变成了“从投标文件中找到注册资金对应数值并填到extract字段”，至于这个数值是否满足条件，由规则引擎按照operator和threshold来判定。这样一个环节出了问题可以精准定位：抽取错了，去优化提示词；判断错了，去检查规则配置。两者彻底解耦。
3.4 Skill组合的编排顺序与容错策略
五个Skill不是各跑各的，而是要串成一条受控流水线。我们在openJiuwen里定义了一个审查工作流，按照“解析 -> 抽取 -> 匹配 -> 判定 -> 报告”的顺序执行，并且给每个Skill配置了进入条件和失败退出策略。
进入条件解决的是“什么情况该跳过”的问题。比如文档解析Skill发现文件是一份纯图片扫描件，没有可抽取的文本层，那么后续的条款抽取Skill就没有意义，直接进入OCR补充流程，而不是硬着头皮往下跑。失败退出策略解决的是“什么情况该终止任务”的问题。比如规则匹配Skill发现文件内容结构和规则库完全不匹配，继续往下判定的结果只会是垃圾，我们选择让任务直接终止并标记为“需人工介入”，而不是生成一份看起来很完整但实际全错的报告。
这个容错设计是吃了几次亏以后才补上的。早期版本为了让流程不断，很多处理失败的文件被“硬判”了一遍，产出的一堆结论非但没有用，还误导了业务方的复核。后来我们把“放弃任务”和“标记需人工介入”也当成一种正常输出，整体准确率反而上来了。
4. 工程化落地：从文档解析到合规报告全链路
4.1 真实文件的解析要处理哪些问题
文档解析听起来是最没有技术含量的一步，实际上却是整个引擎出错率最高的环节。我们遇到的典型问题包括三种。第一种是真扫描件，整个文件就是一张张图片，没有任何文本层，这种情况必须走OCR流程，而且扫描件质量参差不齐，有倾斜、有阴影、有手写批注，OCR之前需要做图像预处理。第二种是表格跨页断裂，尤其是技术参数表，一页放不下就自动拆到下一页，表格的列对齐信息在文本抽取时会完全丢失，变成一串无意义的字符。第三种是目录和正文页码不一致，招标文件的目录通常是最后生成的，正文一旦调整过版式，目录页码就全部错位，直接按目录定位条款必然出错。
我们的处理方式是给文档解析Skill加了多条并行的解析路径。先探测文件是文本型还是扫描型，文本型优先解出内嵌文本，扫描型走OCR；表格部分单独用表格识别模型抽取成结构化数据，不用纯文本抽取方式；目录信息只作为辅助线索，最终定位以正文实际页码为准。
4.2 需求条款与响应条款对齐的三种手段
合规审查的核心动作，是把招标文件里的“需求条款”和投标文件里的“响应内容”放到一起比对。这个动作是自动化处理里最费劲的一环。因为投标文件里的响应内容未必按同样的条款顺序组织，很多投标方甚至刻意把关键响应藏在不显眼的位置。
我们最后用了三层对齐策略，层层递进。第一层，优先从“商务偏离表”和“技术偏离表”里取响应。绝大多数投标文件会有一张表，逐条列出“招标要求”和“投标响应”，这是最结构化的对齐来源，解析成功率也最高。第二层，如果偏离表里没有对应条目，则到全文做锚点检索，用需求条款里的关键词组合在投标文件里搜索“疑似响应”的段落，再用语义相似度过滤。第三层，如果上面两步都没有结果，就把这条需求标记为“未发现响应，需人工复核”，而不是默认判定不满足。
这套三层机制上线后，需求条款的对齐覆盖率从最初的不到六成提升到了九成以上。剩下约一成确实需要人工看，但业务方也觉得合理——本来正常评审也未必能百分之百覆盖，引擎能把九成条款直接亮出来，已经省了大部分时间。
4.3 结果怎么分层、证据链怎么给
审查结果如果只输出“符合/不符合”，业务方是不敢用的，因为没法验证。我们设计了一套三级判定等级和强制证据链输出的机制。
判定等级分三类：Fatal表示触及废标条件，比如未按要求签章；Warning表示存在偏离但不一定废标，比如某项资质证明缺失；Info表示信息提示，比如投标文件表述与招标文件不完全一致但不影响评审。每个等级的规则都会配置不同的后续动作，Fatal类会直接生成重点提示，Warning类进入人工复核队列，Info类只做记录。
证据链是硬性要求。每一条判定结果必须包含三个要素：原文的页码范围、引用的原文摘要、规则依据。我们专门在报告生成Skill里设了校验逻辑，如果某条结论缺失这三要素之一，这条结论就不被允许出现在正式报告里。这个设计直接影响到业务方对我们的信任度，因为评审专家拿到报告后，可以快速定位到原文逐条核对。
4.4 异步任务接口设计：把引擎嵌进业务系统
合规引擎不能做成一个只在本地跑脚本的工具，它要被现有业务流程调用。我们开放了一组异步任务接口，基本流程是：业务方先调用创建任务接口提交待审查文件，拿到一个任务ID；引擎在后台处理，业务方通过任务ID轮询状态；处理完成后，通过结果查询接口拉取合规报告；业务方复核完每条结论后，可以调用复核反馈接口，把人工修正结论回传回来。
接口没有做成同步的，是因为审查任务耗时不可控，一份简单文件可能几秒就结束，复杂的扫描件加大量附件可能要几分钟。同步接口容易导致调用方超时，异步任务模式更稳妥。我们在接口层还加了一个轻量级队列，限制同时处理的任务数量，防止大量文件涌入时把后端资源打爆。
复核反馈接口是当时特意要求加的。业务方复核修正后的结论，会成为后续规则优化的训练数据。这个闭环让引擎会越用越准，而不是上线后效果逐渐退化。
4.5 上线后的几个关键数字
整个系统上线跑了一个多月后，我们统计了几组数据。单份文件的平均处理时长控制在五分钟以内，复杂扫描件最长不超过二十分钟，而过去人工审查同样一份文件普遍要花三到四小时。硬性条款的召回率稳定在96%左右，语义条款的召回率在85%上下。最让业务方满意的是误报率压到了12%以内，也就是说自动标注的风险项里大部分确实有风险。
说实话，12%的误报率在一开始我们觉得还不够好，但业务方的反馈改变了我们的预期。他们说，只要系统不把真正有问题的条款漏过去，误报顶多让复核人员多看一眼。合规审查场景里，漏报的代价远大于误报，这个认知直接影响了我后续对规则优化的优先级排序。
5. 踩坑实录：上线前后我们反复踩过的坑
5.1 扫描PDF全变乱码
第一批测试文件里有一批扫描版招标文件，解析结果惨不忍睹，正文内容张冠李戴，表格拆得七零八落。后来排查发现，问题不在模型，而在OCR预处理阶段。原图分辨率不足，倾斜角度没有校正，直接喂给OCR引擎，识别出来的文字自然一堆错。
处理方式是在OCR前增加一个图像预处理管道：先检测页面是否有明显倾斜，做自动旋转校正；然后把图像统一缩放到合适分辨率，过亮过暗的做对比度增强；最后按版面顺序拼接识别结果。这套预处理管道看起来朴素，但对识别率的提升非常明显，尤其是双栏排版的页面，校正后的识别准确率提升了十几个百分点。
5.2 附件才是真正的重头戏
上线第一周，业务方反馈有一条重要技术规范被漏检了。我们排查后发现，这条规范根本没出现在招标文件正文里，而是在一个名为“附件三：技术规范书”的独立文件里。原以为只要处理主文件就行，结果漏了附件这个大头。
后来我们把“文件集”的概念引入引擎：一个审查任务可以包含多个文件，其中既有招标文件正文，也有采购需求清单、技术规范书、合同模板等附件。文档解析Skill会遍历所有附件，并识别附件之间的引用关系。业务方对这个改进的评价是“终于不用手动把附件单独丢进来审了”。
5.3 大模型过于敬业，把合规表述判成风险
有一段时间误报率高得异常，查了些案例发现，模型把很多“等效表述”误判为不满足要求。比如招标文件要求“提供7×24小时运维服务”，投标文件写的是“提供全天候运维支持”，模型因为没看到“7×24”这个数字，就判了一个Warning。这在语义上是等价的，硬抠字眼反而制造了噪声。
我们的解决办法是建立了一份“语义等价词表”，并且把常见的模糊表述固化到规则配置里。在判定复核Skill执行前，先对抽取到的文本做一次等义词归一化处理。这样模型就不需要在这种低层次问题上反复猜，误报率明显降了下来。
5.4 上下文污染：上一个任务的状态串场了
这个坑最隐蔽。早期版本中，多个审查任务并行跑的时候，偶尔会出现一份文件的报告里混着另一份文件的内容。查了很久才发现是Skill上下文回收机制的问题——上一个任务在某个Skill里留下的中间状态，在下一个任务开始时没有完全清空。
openJiuwen虽然设计了任务级上下文隔离，但我们当时没有在每个Skill的起始位置显式声明上下文的生命周期。修复方式也很直接：在每个Skill的入口强制初始化一个新的上下文容器，任务结束时显式释放。同时给每个任务加了一个唯一的traceId，日志里全程贯穿，排查问题的时候一眼就能看出哪条数据属于哪个任务。
5.5 规则库也要做版本管理，否则回不了头
规则库在持续迭代过程中，难免会出现改坏的情况。有一回我们更新了一条关于“业绩证明材料”的语义规则，上线后导致一批正常文件被误判为缺少证明材料。当时没做规则版本管理，只能靠人肉回忆上一个版本是怎么写的，花了大半天才把规则还原成改之前的配置。
现在我们用项目仓库管理整套规则配置，每次修改走提交流程并打标签，发布之前先拿评估集跑一遍回归。规则有了版本之后，生产环境出问题可以秒级回滚，评估流程也变成了一条强制纪律。这个改进不需要什么高深技术，纯粹是工程规范，但对这类要求稳定性的系统来说价值巨大。
这次改造给我的总体感受是，通用Agent落地到垂直业务，技术难点其实不在模型调度，而在规则治理和工程约束。大模型负责理解文本，规则系统负责决策，工程师负责把两者拧成一条可靠的生产链路。如果你想做类似的合规引擎，我的建议是先别急着上复杂编排，先把规则库、测试集、反馈闭环这三样东西搭好。这套框架一旦稳了，后面换文件类型、换审查领域，复用度会非常高。