从通用Agent到招标文件合规引擎：基于 openJiuwen Skills 的工程化落地实践
过去一年，Agent 这个概念被反复提起。几乎所有技术文章都在讨论 ReAct、多 Agent 协作、Workflow、Tool Calling、MCP、Function Calling——看上去，智能体已经无所不能。
但当这些能力真正被带到招标合规审查的业务现场时，一个很现实的问题摆在了面前：
在招标文件审查场景里，我们面对的从来不是“问答”那么简单，而是更棘手的业务难题——是否存在实质性排他条款？潜在废标风险在哪？资格条件是否构成了限制性门槛？技术参数暗含品牌指向吗？评分办法有没有明显倾向性？
这些问题背后，站着的是风险、责任，甚至法律后果。
如果一个 Agent 只是“分析文本并给出建议”，那它确实是个聪明的助手。但如果希望它成为一套真正可交付的“合规审查引擎”，那它必须具备三样东西：可追溯的规则体系，可执行的受控操作能力，以及可复现的审查流程链路。
换句话说，我们需要的不是一个会聊天的模型，而是一套能落地的能力工程。
企业真正需要的，从来不是“更聪明的模型”，而是更可控、更稳定、更可审计的智能系统。接下来会完整拆解：openJiuwen 的 Skills 机制如何成为合规能力的载体，如何设计招标文件合规审查的 Skills 目录体系，如何构建规则引擎与受控执行链路，以及如何让 Agent 生成可归档的审查报告。
如果你也在思考：如何把 Agent 从 Demo 变成生产能力？如何让大模型真正承担业务流程的一部分？如何构建可版本化的企业级能力体系？那么接下来的内容，或许能带来一些新的视角。
第一章｜为什么选择 openJiuwen 作为合规审查智能体的基座
说起构建一个真正能干活、可控、可审计的合规审查系统，大家第一反应往往是“接个大模型，写个 Prompt，再调个 API”。在实验场景里，这种做法确实挺好用。
可一到真实工程现场，马上就会碰到三类大坑。
第一个坑：模型的执行边界不清晰。模型可以生成文本，但它不应该随意访问文件系统、执行命令，更不该无约束地操作生产环境。
第二个坑：规则很难版本化，审计难度高。如果规则只写在 Prompt 里，改一次就要重发 Prompt，无法形成“可落盘、可比较”的规则体系。
第三个坑：流程不可复现。每次审查都依赖温度、上下文、生成机制，结果不可复现、不确定性高。
openJiuwen 是一个开源的 Agent 平台，核心目标是提供一个既能让大模型发挥能力，又能约束执行行为的工程化智能体框架。它不只是一个聊天机器人，而是一个具备事件驱动的多 Agent 控制机制、高可靠的执行引擎、以及自动优化的提示词机制的完整框架。简单来说，它要解决一个问题：让智能体不仅会说，还会“按规则做事”。
在这一点上，openJiuwen 提供了两套非常关键的机制：Skills 和 SysOperation。
Skills：把能力做成“可管理的资产”
很多智能体项目都停留在把知识写在 Prompt 的阶段。Skills 不只是 Prompt 的替代品，它是一个能力工程资产。你的“招标规则”不再是人脑里的 tacit knowledge，而是一个落盘、可升级的能力单元。这对合规审查系统的可靠性至关重要。
Agent Skills 本质上是一个模块化的 Markdown 文件，能教会 AI 工具执行特定任务，且支持自动触发、团队共享与工程化管理，彻底告别重复的提示词输入。核心形式就是一个文件夹，里面必须有一个 SKILL.md 文件，可选其他资源文件。这相当于给 AI 发放了一本专业手册，AI 不会每次都从零学习，而是根据任务自动调用手册中的知识。过去我们用提示词教 AI 做事，现在用 Agent Skills 可以把提示词和资源打包成可复用、可共享的技能包。
my-skill/
└── SKILL.md （唯一必需）
SKILL.md 基本模板：
---
name: pdf-processing
description: 从 PDF 中提取文本和表格，填写表单，并合并文档
---
# PDF 处理
## 使用场景
当需要对 PDF 文件进行操作时使用，例如：
- 提取 PDF 文本或表格数据
- 填写 PDF 表单
- 合并多个 PDF 文件
## 提取文本
- 使用 `pdfplumber` 提取文本型 PDF 内容
- 扫描版 PDF 需配合 OCR 工具
## 填写表单
- 读取 PDF 表单字段
- 按输入数据填充并生成新文件
最小必填示例：
---
name: skill-name
description: 说明该 Skill 的功能以及适用场景
---
SysOperation：安全可控的执行接口
在很多智能体架构里，模型一旦接了工具，就可能放开访问文件系统、运行代码、执行命令。openJiuwen 通过 SysOperation 屏蔽了这种风险。SysOperation 是一个系统操作抽象层，统一封装了文件系统、代码执行和命令行三类能力，并通过一致的接口支持在 Local 与 Sandbox 模式之间无缝切换。
SysOperation 提供的是受控的文件系统访问、受控的代码执行环境和受控的 Shell 命令执行能力。这些不是直接暴露给模型，而是通过一个统一的、受控的接口层来调度执行。
这样做的好处显而易见：执行权限可审计，越权操作可被禁止，每次命令调用都有日志留痕。对合规审查这类“要操作真实文件、要执行脚本、要做文件解析”的场景来说，这是个刚需。
总的来说，openJiuwen 不是让模型更聪明，而是让模型的输出和行为都“有据可查、有法可依、有控可管”。这正是构建“招标文件自身合规审查系统”时最需要的基础能力。
第二章｜构建合规审查智能体的核心能力：Skills & SysOperation
上一章提到一个工程现实：通用 Agent 在真实场景中难以直接交付。那怎么才能让一个智能体在真实工程场景中完成文件解析、规则执行、报告生成、流程串联这样的工作？答案是把能力边界化和执行可控化。而 openJiuwen 提供的核心机制，就分别解决了这两个问题：Skills 负责业务能力边界化，SysOperation 负责可控执行能力。
2.1 Skills 是什么？不是 Prompt，是工程级“能力资产”
回顾许多智能体应用失败的原因：
| 问题 | 产生根源 |
|---|---|
| 规则写死在 Prompt 里 | Prompt 难以版本控制、审计 |
| 修改规则只能改 Prompt | 不同 Skill 之间难共享 |
| 决策逻辑很难追踪 | 模型行为不可解释 |
这暴露了一个核心问题：业务能力没有被实体化定义。
Skills 的核心思想是：把能力实体化为一个可管理的工程资产。这与过去把 Prompt 当规则库的做法本质不同。一个 Skill 在工程目录中代表一块“业务能力包”：
skills_root/
├─ 文件解析/
│ ├─ Skill.md
│ ├─ examples/
│ └─ scripts/
├─ 实质性条款识别/
│ ├─ Skill.md
│ └─ rules/
…
每个技能目录中必须包含一个 Skill.md，这个文件并不是普通说明文档，它将在 Agent 的提示词中被注入，告诉模型这是什么能力、能处理什么类型的输入、能产出什么结构化结果、是否有示例供调用参考。模型在推理过程中不仅“理解文本”，还能“根据 Skill 描述选择能力”。
2.2 Skills 在合规审查系统中的具体模块划分
为了让招标文件审查能力可复用、可组合、可演进，我们把业务能力拆成以下几个 Skills：
| 技能模块 | 主要职责 | 典型输出 |
|---|---|---|
| 文件接入与结构化 | 文件解析 | 结构化 JSON / 文本 |
| 实质性条款识别 | 抽取废标/否决条款 | 条款列表 |
| 资格条件审查 | 检查主体资格与资质 | 审核清单 |
| 技术参数合规 | 参数是否明确与限制 | 偏离提示 |
| 合同条款风险评估 | 指定风险条款库扫描 | 风险条目 |
| 审查结果输出 | 生成审查报告模板 | Markdown/JSON 报告 |
这种拆分策略本质上是一种领域分解，让每个 Skill 只专注一块业务能力。
2.3 一个规范的 Skill.md 通常包含如下模块
---
name: 技能名称
description: 该技能的能力描述和使用场景
---
## 输入定义
说明 Skill 需要的输入是什么
## 判定逻辑
说明规则如何执行、如何判定状态
## 输出格式
说明返回结果的结构和字段含义
## 典型示例
给出一个或多个输入 → 输出示例对照
注意这里的要点：输出是结构化的，而不是自然语言；示例不仅说明能力，还让 Agent 理解“如何匹配”。
2.4 SysOperation：让 Agent“可执行”，而不是“空xue来风”
在传统的智能体架构里，模型的能力停留在“推理和语言理解”层面，不能真正执行外部系统操作。如果让模型不受约束地访问操作系统，结果无法追踪审计而且有安全风险。openJiuwen 的解决方案是：通过 SysOperation 抽象层把可执行操作封装起来，并只暴露必要的受控能力给 Agent 使用。
SysOperation 把系统能力抽象成三个主要操作类：
| 操作类型 | 内部调用 | 用途 |
|---|---|---|
| sys_op.fs() | 受控文件读写 | 读取、写入、遍历目录 |
| sys_op.code() | 受控代码执行 | 执行规则引擎代码、调用 Python 脚本 |
| sys_op.shell() | 受控命令执行 | 解压、OCR、第三方工具执行 |
它不是简单给模型执行系统命令，而是通过一个受控层来调度，这也符合企业生产规范要求。
2.5 为什么受控执行能力对合规审查至关重要？
在合规审查场景中，智能体会遇到诸如：抽取 PDF 文本、遍历附件目录、运行 PDF 结构化脚本、调用 OCR 处理扫描件、执行规则引擎生成 JSON、组合审查结果并输出 Markdown 报告等。这些都不是大模型单纯的语言输出，而是对操作系统与文件系统的具体操作。
把上下两块拼接起来就能看到完整的运行逻辑：Skill 负责业务知识与能力描述，SysOperation 负责受控操作执行层。这让 Agent 不再是“会说话的模型”，而是真正具备可验证、可追踪的业务执行能力。
第三章｜从通用 Agent 到招标文件合规审查 Skill 工程模板
本章节给出一套“可直接落盘”的招标文件合规审查 Skills 工程模板。以 openJiuwen 的 Skills/SysOperation 思路为基座，围绕“文件接入→结构化→规则匹配→报告生成”形成可复现链路。模板包含：完整 skills_root/ 工程结构、7 个 Skill 的 Skill.md、YAML 规则规范与业务规则示例、最小可运行 Python 规则引擎、Agent 挂载与调用链，以及报告模板与端到端测试步骤。
3.1 执行环境与前提
| 项 | 建议/约定 | 备注 |
|---|---|---|
| 操作系统 | Windows/Linux | openJiuwen Core 兼容 Windows/Linux/macOS。 |
| openJiuwen Core 版本 | 建议：openjiuwen==0.1.7 | PyPI 显示 0.1.7 发布于 2026-02-14。 |
| Python 版本 | 建议：3.11.4 | PyPI 约束：>=3.11，<3.14。 |
| LLM Provider/API | 自由选择 | openJiuwen Core 支持通过环境变量配置模型调用。 |
| Runner 运行方式 | 建议本地开发用 local；生产用 sandbox | openJiuwen 强项是“高可靠执行 + 状态管理 + 可恢复”。 |
| sys_operation_id | 约定：default_sys_op | 若工程中已注册其他 id，请替换。 |
| 工作目录约定 | 约定： | 所有文件读写、解析产物、报告输出都落在这里。 |
| 文件命名约定 | tender.pdf（招标文件主文档）+ 可选 clarification.pdf + attachments/ | 能覆盖 80% 实战场景。 |
| FS 白名单 | 仅允许访问 | 禁止访问上级目录与系统盘根。 |
| Shell 白名单 | 建议仅允许：ls/dir, cat/type, python, unzip, 7z, pdftotext | 避免 curl/wget, rm -rf 等风险命令。 |
| Python 执行限制 | 超时、内存限制、禁网 | 建议在 sandbox 或 runner 层实现。 |
3.2 Skills 工程目录结构
Agent 行为链：
3.3 完整 skills_root/ 目录结构表
| 子目录 | 目的 | 必备文件 |
|---|---|---|
| tender_intake/ | 项目接入、文件校验、生成 manifest、审计元数据 | Skill.md、scripts/intake_check.py、templates/project_manifest.schema.json |
| tender_structure_parse/ | PDF/附件解析成结构化 tender.json | Skill.md、scripts/parse_tender_pdf.py |
| compliance_mandatory_items/ | 扫描废标/否决/必须响应等强规则 | Skill.md、rules/disqualify_rules.yml、scripts/run_rules_engine.py |
| qualification_check/ | 扫描资格条件限制 | Skill.md、rules/qualification_rules.yml |
| technical_spec_match/ | 扫描技术参数公平性/可比性风险 | Skill.md、rules/technical_rules.yml |
| contract_terms_risk/ | 扫描合同条款风险 | Skill.md、rules/contract_risk_rules.yml |
| report_generator/ | 合并 issue 清单并渲染最终 Markdown 报告 | Skill.md、templates/compliance_report.md.j2、scripts/render_report.py |
3.4 项目具体 Skill.md
每个 Skill 的 Skill.md 都包含 front-matter、目标、输入/输出、判定逻辑、示例以及 rules 引用说明。可按行业逐步替换规则库。
3.5 规则体系与最小规则引擎实现
规则文件基于 YAML，建议坚持以下字段：
| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
| rule_key | str | 是 | 全局唯一键，建议全大写+下划线 |
| severity | str | 是 | HIGH/MEDIUM/LOW |
| category | str | 是 | 输出分类 |
| match_type | str | 是 | keyword/regex/struct_field |
| pattern | str 或 dict | 是 | 匹配模式 |
| explanation | str | 是 | 命中含义 |
| suggestion | str | 是 | 建议动作 |
3.6 业务规则示例
下面给出 disqualify_rules.yml 中的部分规则示例，聚焦“招标文件自身合规审查”常见高风险点：
- BRAND_SPECIFIED_ONLY（HIGH）：技术要求出现品牌指向性表述，应评估是否需改为性能/指标描述或提供“或同等”机制
- MODEL_LOCK_IN（HIGH）：出现疑似型号锁定，易构成排他性技术条款
- SOLE_SUPPLIER_HINT（HIGH）：文本出现“唯一供应商”等表述，提示可能存在单一来源倾向
- LOCAL_VENDOR_RESTRICTION（HIGH）：存在地域/本地化限制的文字信号，可能构成不合理门槛
- REGISTERED_CAPITAL_THRESHOLD（MEDIUM）：注册资本门槛可能造成中小企业排除
- ORIGINAL_MANUFACTURER_AUTH_REQUIRED（HIGH）：强制原厂授权可能形成排他性门槛
- SEAL_SIGNATURE_MANDATORY（HIGH）：盖章/签字与否决后果绑定，属于典型强制响应项
- AMBIGUOUS_EVALUATION_LANGUAGE（MEDIUM）：评分语言过于自由裁量，可能导致可解释性不足
3.7 最小可运行 Python 规则引擎脚本
文件路径建议：skills_root/compliance_mandatory_items/scripts/run_rules_engine.py
功能要求：读取 tender_json、加载 rules.yml、匹配规则、生成 issue_list.json，支持 CLI 运行，也便于被 execute_python_code 调用。
第四章｜openJiuwen 集成代码与 Agent 行为链
4.1 在 openJiuwen 中注册 skills 并挂载到 Agent
openJiuwen Core 包含多类 Agent（包括 ReActAgent/WorkflowAgent），工具调用与执行引擎能力。需要注意把 session_id 做成 project_id__operator__timestamp 格式，审计时能从日志一眼定位“谁、在什么项目、什么时候做的审查”。
4.2 Agent 行为链与 sys_op 调用参数
Agent 调用工具时的常见参数形态包括：run_command 解压附件、execute_python_code 运行解析脚本、view_file 查看产物。
4.3 报告生成
规则引擎输出的 json 顶层含 issues 字段，报告生成脚本会读取 payload["issues"]，通过 Jinja2 模板渲染为最终报告。
4.4 安全与审计建议
openJiuwen 的目标是“生产级 Agent”，做招标合规审查这种高责任场景，安全边界是重中之重。工作目录白名单只允许项目目录内的操作，所有产物目录固定为 artifacts/（结构化中间结果）、audit/（日志与 manifest）、output/（最终交付报告）。Shell 命令白名单仅允许 ls、cat、python、unzip 等安全命令，禁止 curl、rm -rf、sudo 等风险操作。
4.5 测试与验证步骤
建议准备一个 sample_project/，哪怕里面最开始没有真实 PDF，也能先跑通规则引擎与报告生成。端到端命令序列包括跑规则引擎生成 issue_list.json 和渲染最终报告两个步骤。
第五章｜结尾总结
当这套系统第一次在真实项目里完整跑通的时候，并没有太多兴奋感。更多的是一种很冷静的确认。以前做 LLM 应用的时候，模型像一个非常聪明但不稳定的同事。它能理解上下文，能总结条款，能提出疑点，但你始终没办法真正把它纳入业务流程。它的判断依赖当前的提示词状态，依赖当次推理上下文，依赖概率。改一句 Prompt，结果就变了；多给一个示例，输出风格又漂移了。它很聪明，但它不属于你的系统。
而当把招标文件合规审查这件事拆开，落到 Skills 目录、规则文件、执行链路、日志打印、报告生成这些具体工程节点上，整个感觉就变了。规则不再藏在 Prompt 里，而是清清楚楚写在 Skill.md 里；每一条合规判定都能回溯到对应规则文件；每一次执行都有 traceId；每一步都有耗时和输出摘要；每一个风险点都有证据、有条款依据、有整改建议。你不再是在“问模型怎么看”，而是在“运行一套系统”。
所谓“从通用 Agent 到合规引擎”，并不是把模型能力堆上去，而是把边界收紧。模型不再决定一切，它只是规则体系中的一个增强器。真正决定行为的是规则文件、执行流程、系统接口、输出结构。这种变化很微妙，但影响是本质性的。因为当你把一个系统变成“可审计、可复现、可版本管理”的形态时，它才具备进入生产环境的资格。
在招标合规这种场景里，这一点尤其重要。处理的不是普通文本，而是会带来责任的文件。一个模糊的建议和一个可归档的风险条款清单，在工程上是完全不同的东西。前者是辅助参考，后者是交付成果。
如果你也在做智能体落地，不妨问自己一个问题：你的 Agent，是不是已经脱离了 Prompt 依赖，变成了一套可管理的能力工程？如果答案还是否定的，那么你离真正的企业级落地，还差一个“规则与执行边界”的重构。工程从来不是一蹴而就，而是一层一层往上叠。
