第一章 项目概述
1.1 项目定位
OpenCourt 是一个面向法律场景的开源智能体框架，旨在为法院、原告、被告及其代理人提供中立、严谨的信息整理与逻辑推演辅助。项目的核心定位在于帮助用户梳理案件事实、识别证据盲区并进行基本逻辑推演，从而避免在诉讼或审判过程中遗漏关键信息。
OpenCourt 严格遵循“不引导”原则，其具体含义与边界如下：
– 不提供倾向性结论：系统绝不输出“建议起诉”、“大概率胜诉”或“应当调解”等带有主观判断或决策引导的结论。
– 不消解事实冲突：当多份材料对同一事实描述不一致时，系统不进行自动采信或圆场，而是并列展示冲突点，交由用户自行判断。
– 不补全缺失信息：若案件关键要件缺乏证据支撑，系统仅指出“无法判断”或列出“补证方向”，绝不通过模型幻觉填补事实空白。
– 不替代专业决策：人工智能仅作为辅助工具，最终的裁判权、诉讼策略制定权及调解决策权完全归属于人类法官、律师及当事人。
1.2 设计原则
OpenCourt 的架构与功能设计严格遵循以下核心原则：
- 内核中立，立场外置：底层核心能力不包含任何价值取向，所有的诉讼策略、抗辩思路或裁判辅助逻辑均通过外部 Profile（配置文件）按需加载。
- 事实状态驱动：系统不将文本视为绝对真理，而是基于“事实五态模型”对信息进行分级处理，推理过程严格受限于事实的当前状态。
- 代码仲裁优先于模型判断：涉及事实状态升级、法条有效性校验、引用溯源等关键环节，必须由确定性代码执行，大语言模型仅负责候选生成，无权做最终裁决。
- 默认离线安全：框架默认在完全离线环境下运行，数据不出域，遥测默认关闭，确保敏感法律数据的绝对安全。
- 插件化可扩展：法条库、类案库及底层模型均通过插件机制接入，以适应不同机构合法获取的数据源差异。
- 辅助定位不替代裁判：明确系统的辅助性质，裁判职权、法律解释权及最终责任由审判组织或执业律师行使。
1.3 用户角色
OpenCourt 支持四类用户角色，各类角色基于同一套框架代码，但各自独立部署、互不联网、数据物理隔离：
- 法院：使用“中立域+裁判域”。核心场景包括阅卷梳理、争议焦点归纳、类案参考检索及裁判文书校对。系统在此角色下禁用所有策略类插件，保持绝对中立。
- 原告/代理人：使用“原告域+中立域”。核心场景包括请求权基础拆解、举证清单生成、对方抗辩预演、胜算与成本评估（基于逻辑推演而非概率预测）。
- 被告/代理人：使用“被告域+中立域”。核心场景包括寻找对方证据链断点、程序抗辩审查、免责减责事由梳理及调解空间测算。
- 当事人本人：使用轻量视图。仅可查看案件进度、待补材料清单及基础风险提示，系统不向其开放任何策略推理过程或复杂逻辑推演结果。
1.4 项目边界
为确保合规与安全，OpenCourt 明确以下“不做”事项：
- 不预测判决结果：不进行概率推演，不输出胜诉率、判决概率或量刑预测。
- 不引导用户决策：不提供任何诉讼策略建议、调解建议或上诉建议。
- 不内置裁判文书数据：框架本身不包含任何法条或案例数据，所有数据由用户自行录入并负责合法性。
- 不替代律师和法官判断：系统输出的逻辑推演和事实梳理仅作为参考，不具备法律效力。
- 不恢复隐名信息：不得通过任何技术手段恢复公开文书中已被依法隐去的个人隐私或商业秘密信息。
第二章 系统架构总览
2.1 架构设计理念
OpenCourt 采用“一套内核加三个 Profile”的架构设计理念。该理念的核心思想是“内核中立，立场外置”。系统将法律智能体的能力拆解为底层通用能力与上层业务逻辑。底层内核负责文档解析、要素抽取、事实核验等无立场的客观工作；上层逻辑则通过 Profile 机制，根据用户身份（法院、原告、被告）动态加载不同的推理链路和工具集。这种设计确保了同一套代码在不同部署环境下的绝对中立性与安全性。
2.2 四层架构详解
系统自下而上分为四层：
- 内核层（Core Layer）：所有人共用，不含任何立场。包括文档接入（支持PDF、扫描件、图片等及OCR处理）、脱敏模块（强制脱敏与还原表管理）、要素抽取（主体、时间、金额等）、检索层（向量+关键词+重排）、引用校验（强制挂载卷宗页码与原文）、幻觉门禁（实体落地检查）及日志审计。
- 中立逻辑层（Neutral Logic Layer）：所有人共用同一套代码，但数据各自独立。包括阅卷集群（多原子Agent并行处理）、汇聚器（排时间线、标冲突）、核验器（原文定位与打回）、要件匹配器（事实与请求权基础逐条对照）、盲区生成器（输出无法判断的问题与补证方向）及程序守护（期限与节点预警）。
- 立场层（Profile Layer）：按 Profile 加载插件。法院 Profile 聚焦争议焦点与文书校对；原告 Profile 聚焦请求权拆解与抗辩预演；被告 Profile 聚焦证据链断点与程序抗辩；当事人轻量视图仅展示进度与待办。
- 对抗推演层（Adversary Layer）：三方均可开启，但输入不同。包括对方模拟Agent（基于本方可见材料推演对方主攻方向）、立场漂移检测、轨迹监控及角色切换一致性测试（防止自我镜像）。
2.3 插件化数据源
鉴于法院、律所及当事人合法获取的数据源不同，OpenCourt 将数据源设计为插件：
– law_source/：本地法规库适配插件，支持法条版本与废止状态管理。
– case_source/：本地类案库适配插件，支持裁判要旨提取。
– model/：本地模型适配插件，支持多模型交叉验证，确保推理的鲁棒性。
2.4 架构决策记录
| 决策项 | 决策内容 | 理由 |
| 数据隔离 | 三方用户各自独立部署，互不联网 | 法律数据高度敏感，物理隔离是保障数据安全的底线。 |
| 状态管理 | 事实状态升级由代码仲裁，模型仅做候选 | 防止大模型幻觉导致事实被错误采信，确保推理基础坚实。 |
| 冲突处理 | 冲突不自动消解，并列展示 | 尊重法律事实的复杂性，避免AI越权代替法官或律师进行证据采信。 |
| 数据源接入 | 法条与类案源插件化 | 适应不同机构的数据合规要求，框架不内置任何版权或敏感数据。 |
| 输出约束 | 强制带来源、状态和依赖假设 | 保证推演过程的可追溯性与透明度，便于人工复核与合规审计。 |
第三章 核心机制设计
3.1 事实五态模型
OpenCourt 将事实严格划分为五种状态，每种状态对应不同的处理规则：
| 状态 | 定义 | 处理规则 |
| 已溯源确认 | 本方卷宗有原文定位到页码和片段，且无内部矛盾 | 可直接用于推理，输出时必须带来源。 |
| 单源未补强 | 仅有一份材料支持 | 不能直接下结论，需提示补强方向。 |
| 对方主张未验证 | 来自对方文书或陈述，本方无法证实或证伪 | 显式标注“对方主张”，禁止出现在“事实”段落。 |
| 存在冲突 | 两份以上材料对同一事件说法不一致 | 不自动选择，并列列出并标出冲突点。 |
| 无依据 | 无任何材料支持 | 模型生成此类内容直接被门禁拦截。 |
3.2 状态机规则
为防止事实状态被错误升格，系统执行三条硬规则：
1. 证据驱动升级：状态只能靠证据升级，不能靠推理升级。从“对方主张未验证”变为“已溯源确认”，唯一路径是本方导入新材料且核验器能在原文定位。
2. 假设标签贯穿：基于假设的结论必须继承“基于假设”标签，假设被推翻时需能追溯所有受影响结论。
3. 冲突不自动消解：遇到冲突必须输出分支，分别说明采信A或采信B的后果。
3.3 证据准入协议
每份材料进入中立域前，必须经过准入协议： 1. 相关性计算：评估材料与当前案件的关联度。 2. 可信度评估：基于来源、形式等加权计算可信度。 3. 阈值判定：加权低于阈值不入库。 4. 入库标注：入库材料必须标注“三性完整”、“待补强”或“被反驳”。
3.4 上下文管理机制
- 上下文分区投影：按状态物理分区（已溯源确认、单源未补强、对方主张、存在冲突、本方假设），每块前写死使用规则。
- 按职责投影：不给智能体全量上下文。阅卷Agent仅需原文和要素，策略Agent才需假设块，文书Agent默认拿不到假设块。
- 状态升级交给代码：模型负责找相关候选，确定性代码做仲裁和过滤。
3.5 渐进式检索
辩论推进到哪一步，就针对当前争议焦点检索对应法条和类案。系统内置新颖性过滤机制，自动剔除已讨论过的重复内容，确保检索结果始终服务于当前推演阶段。
3.6 立场锚定与漂移检测
每轮发言前重新注入本方立场、价值排序和禁止行为。同时，使用独立的漂移检测Agent比对本轮发言与历史立场，若出现明显转向（如原告突然开始为被告辩护），立即触发报警。
3.7 辩论轨迹监控
系统记录每轮的结论变化。若轨迹剧烈抖动且缺乏新证据支撑，直接触发人工复核，防止模型在无依据情况下反复横跳。
3.8 利益冲突与保密检查
接案前自动比对当事人、关联方、对手方，避免同一律所代理冲突案件。所有对外输出前必须经过保密扫描，确保不泄露敏感信息。
3.9 程序合规守护
系统实时监控举证期限、上诉期限、送达、回避、鉴定申请等程序节点。一旦临近或超期，直接触发预警，防止因程序瑕疵导致实体权利丧失。
第四章 模块详细设计
4.1 文档接入模块
支持 PDF、扫描件、图片、Word 及压缩包格式。接入流程包括：格式解析、OCR 文字识别、表格结构化还原。对于扫描件和图片，强制经过 OCR 处理并生成可检索文本层。
4.2 脱敏模块
入库前强制执行脱敏。支持一致替换（如将“张三”统一替换为“[原告]”）和不可逆脱敏。提供还原表供授权用户在特定场景下还原信息。
4.3 要素抽取模块
从文档中抽取以下要素：主体信息、时间节点、金额数值、关键行为、合同条款、送达信息。抽取结果结构化存储，作为后续推演的基础。
4.4 检索层模块
采用“向量+关键词+重排”的混合检索策略。法条库带版本和废止状态管理，类案库带裁判要旨提取。检索结果必须经过重排，确保高相关性内容优先。
4.5 引用校验模块
每条结论必须挂载卷宗页码和原文片段。若无法在源文档中定位，直接拒绝输出。支持法条版本校验，已废止法条自动标红。
4.6 幻觉门禁模块
检查回复中的当事人、判例、年份、裁判要旨能否在源文档或图谱中落地。无法落地的内容一律拦截，确保输出内容的真实性。
4.7 日志审计模块
记录谁在什么时间查了什么、输出了什么。日志不可篡改，支持合规回溯，满足法律场景的审计要求。
4.8 阅卷集群
由多个原子 Agent 组成，各处理一类材料（如合同、聊天记录、庭审笔录）。支持任务分配与并行处理，输出结构化要素。
4.9 汇聚器
将阅卷集群的输出进行汇聚：编排时间线、标记内部矛盾、标记证据之间的冲突。汇聚结果作为后续推演的输入。
4.10 核验器
不看结论，只回原文。对汇聚器标记的要素进行原文定位，定位失败的直接打回，要求重新抽取或标记为“无依据”。
4.11 要件匹配器
将事实和请求权基础（或犯罪构成）逐条对照。缺哪条直接列出，不自动补全，不强行匹配。
4.12 盲区生成器
基于要件匹配结果，输出“无法判断”的问题清单和“补证方向”，帮助用户识别案件薄弱环节。
4.13 程序守护
内置程序节点监控引擎，支持自定义期限规则。超期预警通过系统消息或外部接口推送。
第五章 Profile 设计
5.1 Profile 配置机制
Profile 通过配置文件加载，指定启用的 Agent 集合、禁用的工具集及数据目录映射。启动时根据用户角色自动加载对应 Profile。
5.2 法院 Profile
- 启用能力：争议焦点归纳、采信与否理由草稿、裁判倾向分析（仅展示逻辑）、反转条件提示、文书校对。
- 禁用能力：所有策略类插件、胜算评估、抗辩预演。
- 输出规范：保持绝对中立，不给出倾向性结论，明确标注辅助性质。
5.3 原告 Profile
- 启用能力：请求权基础拆解、举证清单生成、对方抗辩预演、胜算和成本评估（逻辑推演）、调解区间测算。
- 禁用能力：裁判倾向分析、文书校对。
- 输出规范：所有结论必须带来源，概率性表述替换为逻辑条件表述。
5.4 被告 Profile
- 启用能力：证据链断点查找、三性质证、程序抗辩、免责减责事由、反诉可能性、调解空间。
- 禁用能力：裁判倾向分析、文书校对。
- 输出规范：质证意见必须引用具体证据编号，抗辩理由必须对应法条。
5.5 当事人轻量视图
- 能力边界：仅展示案件进度、待补材料、风险提示。
- 展示内容：不包含策略推理、证据分析、对方主张等敏感信息。
5.6 Profile 配置表示例
| Profile | 启用 Agent | 禁用工具 | 数据目录 |
| court | 阅卷、汇聚、核验、要件匹配、文书校对 | 策略推演、胜算评估 | /data/court |
| plaintiff | 阅卷、汇聚、核验、要件匹配、抗辩预演 | 文书校对、裁判分析 | /data/plaintiff |
| defendant | 阅卷、汇聚、核验、要件匹配、质证分析 | 文书校对、裁判分析 | /data/defendant |
| party | 进度查询、材料提醒 | 所有推演工具 | /data/party |
第六章 数据模型设计
6.1 事实表
| 字段名 | 类型 | 说明 | 约束 |
| fact_id | UUID | 事实编号 | 主键 |
| description | TEXT | 事实描述 | 非空 |
| state | ENUM | 状态（五态之一） | 非空 |
| source_file | VARCHAR | 来源文件 | 可空 |
| page_num | INT | 页码 | 可空 |
| original_text | TEXT | 原文片段 | 可空 |
| related_element | VARCHAR | 关联要件 | 可空 |
| conflict_id | UUID | 冲突编号 | 可空 |
| assumption_source | UUID | 假设来源 | 可空 |
| is_manual_confirmed | BOOLEAN | 是否人工确认 | 默认 false |
| updated_at | TIMESTAMP | 最后更新时间 | 自动更新 |
6.2 冲突表
| 字段名 | 类型 | 说明 | 约束 |
| conflict_id | UUID | 冲突编号 | 主键 |
| fact_ids | ARRAY[UUID] | 涉及事实编号 | 非空 |
| conflict_point | TEXT | 冲突点描述 | 非空 |
| resolution_method | TEXT | 可能解决方式 | 可空 |
| is_resolved | BOOLEAN | 是否已解决 | 默认 false |
6.3 假设表
| 字段名 | 类型 | 说明 | 约束 |
| assumption_id | UUID | 假设编号 | 主键 |
| content | TEXT | 假设内容 | 非空 |
| proposer | VARCHAR | 提出方 | 非空 |
| based_on | UUID | 基于哪个事实或主张 | 非空 |
| dependent_conclusions | ARRAY[UUID] | 依赖它的结论编号 | 可空 |
| affected_conclusions | ARRAY[UUID] | 被推翻后受影响的结论列表 | 可空 |
6.4 权限与可见性层
每条数据打可见范围标签：仅原告可见、仅被告可见、双方可见、仅法院可见。所有检索先过权限过滤再召回，确保数据隔离。
6.5 引用溯源层
每条结论挂到具体证据编号、卷宗页码、原文片段、法条版本。记录法条是否已废止、是否被修订。溯源数据不可篡改，支持审计。
6.6 案件状态层
记录当前处于咨询、起诉、一审、上诉还是二审。每个阶段产生的文书、庭审发言、新证据写回状态，支持状态流转与历史回溯。
6.7 案件交换包数据格式
跨部署桥接通过结构化案件交换包实现。交换包仅包含已依法提交给对方的材料，导入后系统自动比对双方对同一证据的表述差异，生成冲突清单。交换包格式为加密 JSON，包含证据哈希、双方表述、冲突标记等字段。不导入交换包不影响独立使用。
第七章 安全与合规设计
7.1 部署安全策略
OpenCourt 的安全设计遵循“默认拒绝、最小权限、完全隔离”的原则，确保法律数据不出域、不泄露。系统默认处于完全离线状态，所有网络通信需显式开启并记录审计日志。
| 安全策略项 | 配置项 | 默认值 | 说明 |
| 网络访问 | network_mode | none | 容器默认无网络，需联网时设为 bridge 并配置白名单 |
| 遥测开关 | telemetry_enabled | false | 默认关闭任何形式的数据上报，开启需二次确认 |
| 容器隔离 | privileged | false | 严禁使用特权模式，所有技能运行在独立容器 |
| 挂载权限 | read_only | true | 代码及核心配置目录只读，仅数据卷可写 |
| 进程能力 | cap_drop | ALL | 丢弃所有 Linux Capabilities，仅保留必要项 |
| 内存限制 | mem_limit | 4g | 防止单点 OOM 导致宿主机崩溃 |
7.2 数据合规框架
框架本身不包含任何裁判文书数据，数据合规责任完全由部署方承担。 1. 数据来源合法性：部署方必须确保录入系统的卷宗、法条、类案具有合法授权或属于公开信息。 2. 个人信息保护：遵循最小必要原则，系统仅在处理案件时临时加载敏感信息，处理完毕后应支持一键清理内存缓存。 3. 数据跨境限制：默认配置下，所有数据流转均在本地完成。若使用云端模型 API，必须在 plugins/model/ 中显式配置，且系统会强制在请求头添加“禁止用于模型训练”的标识。
7.3 脱敏策略
脱敏模块位于数据接入层（core/ingest），支持可逆与不可逆两种模式。
| 字段类型 | 脱敏方式 | 示例 | 还原机制 |
| 姓名 | 哈希/替换 | 张三 -> PERSON_001 | 依赖本地还原表 |
| 身份证号 | 掩码 | 110101… -> 110101****1234 | 不可逆 |
| 银行账号 | 掩码 | 6222… -> 6222****8888 | 不可逆 |
| 案号 | 保留 | (2024)京01民初1号 | 无需还原 |
| 地址 | 泛化 | 朝阳区xx路1号 -> 北京市朝阳区 | 不可逆 |
审计流程：所有脱敏操作均记录至 core/audit，包含原始哈希、脱敏规则ID、操作时间戳，确保脱敏过程可追溯。
7.4 输出安全机制
系统输出必须经过三层门禁： 1. 法条版本校验：检索层返回法条时，必须携带 effective_date 和 status。若法条已废止，输出端强制标红并提示“已废止”。 2. 引用溯源验证：core/verify 模块对生成的每一条事实陈述进行原文比对。若无法定位到具体卷宗页码或原文片段，直接替换为“[无法判断：缺乏原文依据]”。 3. 引导性内容检测：基于关键词和语义分析，拦截“建议起诉”、“大概率胜诉”、“应当调解”等倾向性表述，强制改写为中立的事实陈述。
7.5 许可证策略
- 内核与插件：采用 MIT 或 Apache-2.0 许可证，鼓励商用与二次分发。
- 第三方依赖：所有引入的依赖必须通过 license-checker 扫描，禁止引入 GPL 等传染性协议库。
- 免责声明：项目根目录必须包含 DISCLAIMER.md，明确 AI 辅助性质，强调裁判职权由审判组织行使，系统不对法律后果负责。
7.6 合规检查清单
| 检查项 | 检查方法 | 通过标准 |
| 离线验证 | 拔掉网线重启服务 | 核心功能正常运行，无报错 |
| 遥测验证 | 抓包分析出站流量 | 无任何非白名单 IP 的出站请求 |
| 溯源测试 | 注入虚假事实 | 系统拒绝输出或标记“无依据” |
| 脱敏测试 | 导入含敏感信息文档 | 导出/展示内容中敏感字段已处理 |
| 权限测试 | 尝试 docker exec 提权 | 操作被拒绝，无 root 权限 |
第八章 目录结构与代码组织
8.1 项目目录结构
| 目录/文件 | 职责描述 |
| core/ | 内核层：文档解析、脱敏、要素抽取、检索、引用校验、审计 |
| neutral/ | 中立逻辑层：阅卷Agent、汇聚器、核验器、要件匹配、盲区生成、程序守护 |
| profiles/ | 立场层：法院、原告、被告、当事人轻量视图的插件集合 |
| adversary/ | 对抗推演层：对方模拟、立场漂移检测、轨迹监控 |
| plugins/ | 数据源适配：法条源、类案源、模型适配接口 |
| deploy/ | 部署配置：Dockerfile、docker-compose、Nginx配置 |
| tests/ | 测试用例：单元测试、集成测试、合规测试 |
| docs/ | 项目文档：API文档、架构设计、用户手册 |
8.2 代码规范
- 语言与风格：Python 3.10+，遵循 PEP 8，使用 black 格式化，isort 排序导入。
- 命名约定：类名 PascalCase，函数/变量 snake_case，常量 UPPER_SNAKE_CASE。
- 类型注解：所有公开函数必须包含 Type Hints，复杂数据结构使用 dataclasses 或 pydantic。
- 注释规范：模块级 Docstring 说明职责；函数级 Docstring 包含 Args, Returns, Raises；关键逻辑行内注释。
- 审查标准：PR 必须包含测试用例，通过 CI 静态检查，无硬编码密钥，无引导性逻辑。
8.3 模块依赖关系
依赖流向严格单向： profiles/ & adversary/ -> neutral/ -> core/ plugins/ -> core/ (仅通过接口) 禁止 core/ 依赖 neutral/ 或 profiles/，确保内核中立性。
8.4 配置管理
- 配置文件：config/settings.yaml 为主配置，支持环境变量覆盖（前缀 OPENCOURT_）。
- 敏感信息：API Key、数据库密码严禁写入配置文件，必须通过 .env 或 Secret Manager 注入。
- 多环境：支持 dev, staging, prod 环境标识，prod 环境自动开启只读模式和审计日志。
第九章 部署指南
9.1 环境要求
| 资源类型 | 最低配置 | 推荐配置 | 说明 |
| CPU | 8 Cores | 16+ Cores | OCR 和向量检索为 CPU 密集型 |
| 内存 | 16 GB | 32+ GB | 需加载多个 Embedding 模型 |
| 磁盘 | 100 GB SSD | 500 GB NVMe SSD | 卷宗存储及向量索引 |
| GPU | 无 (CPU推理) | NVIDIA A10/A30 | 本地大模型推理必备 |
| OS | Ubuntu 22.04 | Ubuntu 22.04 LTS | 需支持 Docker 24.0+ |
| Python | 3.10 | 3.11 | 容器内预装 |
9.2 容器化部署
使用 docker-compose 进行编排，示例配置：
version: ‘3.8’
services:
opencourt-core:
image: opencourt/core:latest
container_name: oc-core
restart: always
network_mode: “none” # 默认离线
volumes:
– ./data/cases:/data/cases:ro
– ./data/db:/var/lib/opencourt
– ./logs:/var/log/opencourt
environment:
– OPENCOURT_ENV=prod
– OPENCOURT_TELEMETRY=false
deploy:
resources:
limits:
memory: 4G
cpus: ‘4.0’
reservations:
memory: 2G
opencourt-api:
image: opencourt/api:latest
container_name: oc-api
ports:
– “127.0.0.1:8000:8000” # 仅监听本地
depends_on:
– opencourt-core
networks:
– internal-net
networks:
internal-net:
driver: bridge
internal: true # 内部网络，无外网
9.3 配置文件说明
| 字段 | 类型 | 默认值 | 说明 |
| model.provider | string | local | 模型提供商：local, openai, azure |
| model.local_path | string | /models/qwen | 本地模型路径 |
| retrieve.vector_dim | int | 768 | 向量维度 |
| retrieve.top_k | int | 5 | 检索返回条数 |
| profile.active | string | court | 当前激活的 Profile |
| security.redact_level | string | high | 脱敏级别：low, medium, high |
9.4 模型适配
支持本地 Ollama/vLLM 及云端 API。多模型交叉配置示例：
models:
reasoning:
provider: local
model: qwen2.5-72b-instruct
embedding:
provider: local
model: bge-m3
verify:
provider: openai
model: gpt-4o-mini
# 仅用于幻觉校验，不处理案情
9.5 插件适配
- 法条源插件：实现 LawSourcePlugin 接口，提供 search_law, get_law_detail 方法。
- 类案源插件：实现 CaseSourcePlugin 接口，支持结构化数据或向量检索。
- 开发方式：在 plugins/ 下新建目录，编写 plugin.yaml 描述元数据，系统启动时自动扫描加载。
9.6 生产环境部署建议
- 监控：集成 Prometheus + Grafana，监控容器资源、API 延迟、幻觉拦截率。
- 日志：JSON 格式输出，接入 ELK/Loki，保留至少 180 天审计日志。
- 备份：每日增量备份 /data/db，每周全量备份，异地存储。
- 灾备：双活部署时，需确保数据同步延迟 < 1s，且具备手动切流能力。
第十章 跨部署通信设计
10.1 案件交换包设计
交换包为加密 ZIP 文件，包含 manifest.json 和 evidence/ 目录。
| 字段 | 类型 | 必填 | 说明 |
| package_id | UUID | 是 | 交换包唯一标识 |
| version | string | 是 | 协议版本，如 1.0.0 |
| exporter_role | string | 是 | 导出方角色：plaintiff, defendant |
| case_ref | string | 是 | 案件内部编号（脱敏后） |
| evidence_list | Array | 是 | 证据清单，含哈希、描述、页码范围 |
| timestamp | ISO8601 | 是 | 导出时间 |
10.2 冲突比对引擎
- 对齐逻辑：基于证据文件的 SHA256 哈希进行精确匹配，辅以文件名和页码模糊匹配。
- 差异检测：对同一证据的描述文本进行 Diff 计算，标记新增、删除、修改内容。
- 冲突清单：生成结构化报告，列出“对方主张但未提供原件”、“描述不一致”、“页码缺失”等条目。
10.3 交换包安全策略
- 加密：使用 AES-256-GCM 对称加密，密钥通过带外渠道（如线下U盘）交换。
- 签名：导出方使用私钥对 manifest.json 签名，导入方验签防篡改。
- 访问控制：导入操作需二次授权，且仅限特定案件空间。
10.4 版本兼容性
交换包遵循 Semantic Versioning。major 版本变更表示结构不兼容，需迁移工具；minor 和 patch 变更向后兼容，旧版系统可忽略新字段。
第十一章 开发路线图
11.1 阶段一：基础内核（MVP）
- 目标：验证“不编造、可溯源”的核心能力。
- 核心功能：文档解析、脱敏、要素抽取、向量检索、引用校验。
- 交付物：core/ 模块，基础 CLI 工具。
- 验收标准：在 100 份真实判决书测试集中，幻觉率 < 1%，溯源准确率 > 98%。
11.2 阶段二：中立逻辑层
- 目标：实现自动化阅卷与要件分析。
- 核心功能：阅卷Agent、时间线构建、要件匹配、盲区生成。
- 交付物：neutral/ 模块，API 接口。
- 验收标准：能正确还原法院未采信证据的理由，要件匹配无遗漏。
11.3 阶段三：立场层与对抗推演
- 目标：支持单方推演与对抗测试。
- 核心功能：原告/被告/法院 Profile，对方模拟，漂移检测。
- 交付物：profiles/, adversary/ 模块。
- 验收标准：三方立场输出互不干扰，对抗测试能发现逻辑漏洞。
11.4 阶段四：跨部署与完善
- 目标：实现离线对抗与生态完善。
- 核心功能：案件交换包，冲突比对，插件市场。
- 交付物：完整系统，文档，示例插件。
- 验收标准：跨部署比对准确，插件开发文档完善。
11.5 里程碑规划
| 阶段 | 预计时间 | 核心交付物 | 关键里程碑 |
| Phase 1 | M1-M3 | Core MVP | 通过“反幻觉”压力测试 |
| Phase 2 | M4-M6 | Neutral Logic | 真实案件阅卷报告可用 |
| Phase 3 | M7-M9 | Profiles & Adversary | 三方推演演示 |
| Phase 4 | M10-M12 | Cross-Deploy | 跨机构对抗测试成功 |
第十二章 贡献指南
12.1 开发环境搭建
- 克隆仓库：git clone https://github.com/opencourt/opencourt.git
- 安装依赖：poetry install
- 初始化配置：cp config/settings.example.yaml config/settings.yaml
- 运行测试：make test
- 启动服务：make dev
12.2 开发流程
- 分支策略：main 为稳定分支，develop 为开发分支，功能分支 feature/xxx，修复分支 fix/xxx。
- 提交规范：Conventional Commits，如 feat(core): add pdf parser。
- PR 流程：关联 Issue，描述变更，通过 CI，至少 1 个 Maintainer 审核。
- 审查标准：逻辑正确，测试覆盖，无安全漏洞，文档更新。
12.3 测试规范
- 单元测试：tests/unit/，覆盖率 > 80%。
- 集成测试：tests/integration/，验证模块间交互。
- 合规测试：tests/compliance/，验证脱敏、溯源、离线等安全约束。
- 运行方式：pytest tests/ -v –cov=core
12.4 文档规范
- 代码变更必须同步更新 docs/ 下对应文档。
- API 变更需更新 OpenAPI Spec。
- 文档使用 Markdown，中文撰写，术语统一。
12.5 问题反馈与讨论
- Issue：使用模板，提供复现步骤、环境信息、日志片段。
- 讨论区：功能提议、架构讨论、使用疑问。
- 安全漏洞：请通过 security@opencourt.dev 私下报告，勿公开。
12.6 行为准则
- 尊重多元，禁止歧视、骚扰、人身攻击。
- 聚焦技术，避免政治、宗教等无关争论。
- 遵守法律，不得利用项目进行非法活动。
- 违反者将被警告或移出社区。
Leave a Reply