潜入数据，析出洞见。

Python 65%
TypeScript 28.9%
CSS 4.5%
Jinja 1.6%

Find a file

LIGHTNINGWHALE 794f4a360c 更新 README.md		2026-08-06 15:21:01 +08:00
app	Initial commit	2026-08-05 23:51:38 +08:00
design-system/auditagent	Initial commit	2026-08-05 23:51:38 +08:00
docs	上传文件至 docs	2026-08-06 00:17:51 +08:00
prompts	Initial commit	2026-08-05 23:51:38 +08:00
scripts	Initial commit	2026-08-05 23:51:38 +08:00
tests	Initial commit	2026-08-05 23:51:38 +08:00
web	Initial commit	2026-08-05 23:51:38 +08:00
.gitignore	Initial commit	2026-08-05 23:51:38 +08:00
pyproject.toml	Initial commit	2026-08-05 23:51:38 +08:00
README.md	更新 README.md	2026-08-06 15:21:01 +08:00

README.md

潜审 AuditAgent — 审计作业 Agent 系统设计文档（UP 统一过程）

文档属性	内容
文档编号	QS-AA-UP-001
文档版本	v1.0（v1.1 增量见 `潜审_AuditAgent_UP设计文档_v1.1_底稿主路径.md`）
过程规范	统一过程（Unified Process）：业务建模 → 需求 → 分析 → 设计 → 迭代计划
目标基线	潜审 AuditAgent v1.0.0-agent（全新设计，不沿用 DiveMind v0.1.0 实现代码）
文档状态	细化阶段（Elaboration）架构基线候选；v1.1 起主路径改为底稿包
更新日期	2026-08-05
参考文档	`PROJECT_HANDBOOK.md`、`AGENT_ARCHITECTURE_GUIDE.md`、`ARCHITECTURE_GAP_ANALYSIS.md`、`DiveMind_W2_Skills_设计与接口规范_v2.md`（仅继承其领域理解与安全原则，不继承其代码）
使用方式	https://www.divesee.com/divemind/

v1.1 变更摘要：主路径由「账套导入」改为「导出底稿包 ZIP → 合成语义层 → UC-02～08」；账套为可选补录。详见同目录 v1.1 变更说明。

第一部分引言

1. 编写目的

本文档按统一过程（UP）的制品体系，描述"潜审 AuditAgent"的系统设计：

从事务所导出的工作底稿包（主路径）及可选的财务软件账套补录出发，覆盖审计作业核心环节：底稿导入与语义合成、审计调整审核、大额科目确认、盘点待办管理（固定资产 / 无形资产 / 库存现金 / 在建工程 / 房屋及土地）、盘点表提交与核对、附注与导出；
回答核心设计问题：这些业务功能如何与 Agent 能力结合——哪些交给确定性规则（Tool），哪些交给 LLM 推理（Agent），哪些必须留给人工（门禁）；
给出可作为架构基线的分层架构、Agent 团队、Tool 清单、领域模型、状态机、数据与接口设计，以及 UP 四阶段迭代计划。

本文档是后续 Construction 阶段编码的直接依据（v1.1 底稿主路径以变更说明为准）。

2. 背景与范围

2.1 业务背景

年报审计中，审计人员通常已持有各科目工作底稿（审定表、抽凭、披露、监盘等），并可能另备财务软件导出的账套。需要完成一系列以"底稿与账"为中心的核查工作：

审计调整：发现错报后编制调整分录，经复核、客户确认后决定入账或列入未更正错报汇总；底稿审定表中已有调整列时应导入为可审阅调整单；
大额科目确认：基于重要性水平筛选金额重大的科目，确定重点审计范围并逐项确认程序执行结果；
监盘：对库存现金、固定资产、在建工程、房屋及土地、无形资产等实物/权属类资产执行盘点或实地察看，形成盘点表并与账面核对，差异须处理。

这些工作当前依赖人工在 Excel 间搬运、比对、签认，重复性高、易错、追溯难。

2.2 系统范围

范围内：

整包工作底稿的导入、版式理解、语义层合成（余额/序时/调整/盘点/披露）与科目映射（identity）；
账套（科目表、科目余额表、序时账/凭证等）的可选导入、格式理解与校验（补录）；
审计调整单的编制辅助、机器校验、复核流转、客户确认状态跟踪、未更正错报汇总；
重要性水平计算、大额科目筛选与范围确认；
五类盘点待办的生成、盘点表（应盘清单预填）生成、提交、账实核对、差异处理闭环；
最终交付物（双产物）：①修正后底稿（各科目"未审数→调整数→审定数"三栏联动，含逐项审计结论；优先原簿写回）；②财务报表附注（依据底稿与审计结论组装，全部数据与审定数勾稽，docx 定稿）；
全程审计轨迹、人工门禁、导出归档。

范围外（本期不做）：

函证的收发全流程（仅在大额科目确认中输出"函证候选清单"）；
存货监盘（存货计价复杂，单列后续迭代；监盘证据可入库但不新增第六类盘点待办）；
财务报表编制与审计报告出具；
多用户协同与企业级部署（沿用单机单用户假设）。

2.3 继承与废弃

来源（DiveMind v0.1.0 文档）	继承	废弃
`AGENT_ARCHITECTURE_GUIDE.md`	Agent 分层范式、ReAct Loop、Tool/Memory/Prompt/评测体系思路	其 Agent 划分（Doc/Voucher 等以文件为中心的划分），改为以审计业务对象为中心划分
`ARCHITECTURE_GAP_ANALYSIS.md`	"AI 是编排核心而非外挂""LLM 不做算术"等诊断结论	—
`DiveMind_W2_Skills_...v2.md`	安全原则（本地优先、脱敏、人工门禁、统一错误、证据引用）	12 个 Skills 的模块映射（其实现不可用）
`PROJECT_HANDBOOK.md`	技术栈基线、项目状态机/导出门控思想	硬编码 9 步 pipeline
`AGENT_ARCHITECTURE_GUIDE.md` 技术选型	ReAct Loop / Tool / Prompt / 评测体系思路	两处修正：向量库由 ChromaDB 改为 sqlite-vec + bge-small-zh（§19）；OCR 由 PaddleOCR 完整版改为 RapidOCR（ONNX）默认 + 可插拔 VLM 引擎（§16.4）

3. UP 制品索引

UP 规程	制品	本文档位置
业务建模	业务参与者/业务用例/目标业务流程	第二部分 §4–6
需求	用例模型（用例图、详述用例）、补充性规格说明	第三部分 §7–10
分析	领域模型、系统顺序图（SSD）、操作契约	第四部分 §11–13
设计	逻辑架构、Agent/Tool/Memory 设计、用例实现（交互）、状态机、数据设计、接口设计、安全与可观测	第五部分 §14–23
项目管理	迭代计划、风险清单	第六部分 §24–25

4. 术语表

术语	定义
WorkpaperPack	（v1.1）底稿包导入版本聚合根；见 v1.1 变更说明
WorkpaperLine	（v1.1）审定表明细行
DisclosureRow	（v1.1）披露表-标准行
语义账簿	（v1.1）底稿合成或 TB 解析得到的 LedgerRow；经 semantic_query 读取
workpaper_ready	（v1.1）底稿导入并合成完成的项目状态
账套（Account Set）	财务软件导出的一套核算数据：科目表 + 科目余额表 + 序时账/凭证 + 辅助核算 + 资产卡片
科目余额表 / 试算平衡表（TB）	各科目的期初余额、本期借贷发生额、期末余额汇总
审计调整分录（AE）	审计建议的更正分录；另有重分类分录（RJE）与滚调（上年未调事项的延续调整）
未更正错报汇总（SAD）	客户未采纳的调整汇总，需与重要性水平比较以评价对意见的影响
重要性水平（PM/TE）	报表整体重要性（PM）、实际执行重要性（TE，通常 PM 的 50%–75%）、明显微小错报临界值（SAD 阈值，通常 PM 的 3%–5%）
大额科目确认	对期末余额或发生额超过阈值的科目逐科确认审计范围与程序执行结论
监盘 / 盘点	审计人员现场监督被审计单位盘点并抽盘，形成盘点表；对现金通常采用突击盘点
双向盘点	账 → 实（验证存在性）+ 实 → 账（验证完整性）
现金倒轧	盘点日实点数 ± 盘点日至报表日收支 = 报表日应存数，再与账面核对
盘点待办（Count Todo）	系统生成的盘点任务单元，本系统固定五类：固定资产、无形资产、库存现金、在建工程、房屋及土地
证据引用（EvidenceRef）	指向源文件/工作表/单元格/页码 + SHA-256 的可追溯引用
人工门禁（Human Gate）	AI 产出仅为建议层，未经人工确认不得进入正式底稿、调整结论或导出
Agent / Tool / Memory	见 §14–§16：LLM 编排核心、确定性能力单元、三层记忆

5. 审计准则依据（知识库预置条目来源）

中国注册会计师审计准则第 1221 号——计划和执行审计工作时的重要性；
第 1251 号——评价审计过程中识别出的错报；
第 1301 号——审计证据；第 1312 号——函证；第 1313 号——分析程序；
第 1311 号——对存货、诉讼和索赔、分部信息等特定项目获取审计证据的具体考虑（监盘方法参照其原则）；
《企业会计准则》固定资产、无形资产、借款费用等相关条款。

第二部分业务建模（Business Modeling）

6. 业务参与者与业务用例

6.1 业务参与者（Business Actors）

参与者	说明
审计人员（现场）	执行审计程序：导入账套、盘点、编调整、录盘点表
复核人 / 项目经理	复核调整单、确认审计范围与盘点结论
被审计单位联系人	提供账套、确认调整、配合盘点并在盘点表上签认
潜审 Agent 系统	业务用例中的"自动化工作者"：理解账套、校验、生成清单与表、核对差异

6.2 业务用例图

flowchart LR
  A[审计人员] --> BUC1[取得并理解账套]
  A --> BUC2[编制审计调整]
  A --> BUC3[执行盘点]
  R[复核人/项目经理] --> BUC4[审核调整与范围]
  C[被审计单位联系人] --> BUC5[确认调整/配合盘点签认]
  AG[潜审 Agent 系统] --> BUC1
  AG --> BUC2
  AG --> BUC3
  AG --> BUC4
  BUC1 --> BUC2
  BUC1 --> BUC3
  BUC2 --> BUC4
  BUC3 --> BUC4
  BUC4 --> BUC5

7. 目标业务流程（TO-BE）

flowchart TB
  S0[导入账套文件<br/>Excel/CSV/ZIP/国标接口] --> S1{Agent 理解账套<br/>格式识别·表头定位·勾稽校验}
  S1 -->|校验失败/映射不确定| H1[人工确认科目映射]
  H1 --> S2
  S1 -->|通过| S2[项目账套就绪<br/>TB + 序时账 + 科目映射]
  S2 --> P1[计算重要性水平<br/>人工确认参数]
  P1 --> P2[Agent 生成大额科目候选清单<br/>阈值+波动+风险理由]
  P2 --> P3[人工逐科确认范围<br/>纳入/剔除须理由]
  S2 --> A1[编制/导入审计调整]
  A1 --> A2[Agent 初审<br/>借贷平衡·科目合法·勾稽·影响重算]
  A2 --> A3[复核人审核<br/>通过/驳回]
  A3 --> A4[客户确认状态登记<br/>入账 / 未更正错报汇总]
  S2 --> T1[生成五类盘点待办<br/>FA/IA/CASH/CIP/LAND]
  T1 --> T2[Agent 从账套提取应盘清单<br/>生成预填盘点表]
  T2 --> T3[现场盘点<br/>双向盘点·现金突击]
  T3 --> T4[提交盘点表<br/>电子填录或扫描件 OCR]
  T4 --> T5[Agent 账实核对<br/>现金倒轧·差异清单]
  T5 -->|有差异| T6[差异处理<br/>生成调整候选→回到 A1]
  T5 -->|无差异| T7[复核人签认归档]
  T6 --> T7
  P3 --> G{归档门禁}
  A4 --> G
  T7 --> G
  G -->|全部通过| W[渲染修正底稿<br/>交付物A]
  G -->|全部通过| N[附注组装与勾稽<br/>交付物B]
  W --> E[版本化导出归档]
  N --> E

流程要点：

账套是唯一事实来源：大额科目清单、应盘清单、调整影响重算全部从同一份已校验账套派生，杜绝多版本 Excel 漂移；
五个环节之间有两条关键数据流：盘点差异 → 调整候选；重要性水平 → 大额科目范围与盘点抽盘比例；
每个环节的 Agent 产出都汇入统一人工审核队列，门禁通过后方可归档。

8. 业务功能 → Agent 能力映射（核心设计决策）

审计行业原则：职业判断不可让渡给 AI。因此能力分配遵循：

确定性计算归 Tool（规则），语义理解与建议归 Agent（LLM），结论与签认归人工。LLM 永不做算术，算术一律调用 Tool。

业务功能	确定性规则（Tool）	Agent（LLM 推理）	人工（门禁）
账套导入	文件签名校验、SHA-256、格式探测、表/列解析、借贷平衡与"期初+发生=期末"勾稽校验	识别未知导出格式与方言（表头别名、多段表、合并单元格）、判断科目映射建议、解释勾稽失败根因	确认科目映射表；勾稽异常处置
审计调整审核	每笔分录借贷平衡、科目存在性/末级校验、调整后 TB 重算、SAD 汇总与重要性比较	调整理由摘要语义审查、重复/矛盾调整识别、调整对报表影响的解释、滚调延续性提示	复核人审批；客户确认结论登记
大额科目确认	重要性水平计算、阈值筛选、同比波动计算	结合科目性质与波动给出纳入理由/风险提示、识别"金额未超阈值但性质异常"的科目	逐科纳入/剔除决策（剔除须理由）
盘点待办（5 类）	应盘清单提取（资产卡片/现金日记账/在建明细/权证清单）、抽盘样本计算（按金额覆盖率）、盘点表生成	异常应盘项提示（闲置/负净值/临近交付在建工程等）、盘点表扫描件 OCR 语义校正	待办指派与计划确认
盘点表提交	账实核对计算、现金倒轧、差异清单生成、差异→调整候选的结构化转换	盘点表备注/签认信息的语义读取、差异归因建议（盘盈/盘亏/未入账/权属瑕疵）	盘点表复核签认；差异处理意见；归档批准
修正底稿生成（交付物A）	结构签名匹配、公式区校验（T/B 勾稽格）、受控写回（只写数据输入格与文本锚点格，公式区只读）、导出后深度校验	运行时理解每个工作簿的版式（列语义/公式模式/文本锚点/多表套件关系），生成结构档案并自我验证；起草三文本	首次确认新结构档案（或框选兜底）；逐科文本编辑与结论确认；签发导出
附注生成（交付物B）	审定数单一口径取数、账龄/变动表计算、附注↔底稿↔TB 逐格勾稽、docx 模板渲染	章节样板文字组装与政策参数化、披露充分性建议（联动意见类型与 SAD）	文字编辑与标红格处置；逐章签认；定稿导出

第三部分需求（Requirements）

9. 系统参与者（System Actors）

参与者	类型	与系统的交互
审计人员	主参与者	全部系统操作的发起者
复核人 / 项目经理	主参与者	审批调整、确认范围、签认盘点表（v1 单机下与审计人员共用会话，以角色名区分操作留痕）
被审计单位联系人	系统外参与者	不直接操作系统；其确认结果由审计人员代为登记（调整确认、盘点表签认扫描件）
LLM 提供商（本地/云）	辅助参与者	经 AI 网关被 Agent 调用，遵循脱敏门禁
财务软件	系统外参与者	仅作为账套文件来源，不做在线集成

10. 用例模型

10.1 用例图

flowchart LR
  subgraph 系统边界[潜审 AuditAgent]
    UC01[UC-01 导入并理解账套]
    UC02[UC-02 审核审计调整]
    UC03[UC-03 确认大额科目范围]
    UC04[UC-04 管理盘点待办]
    UC05[UC-05 提交并核对盘点表]
    UC06[UC-06 统一人工审核]
    UC07[UC-07 双交付物导出归档]
    UC08[UC-08 生成财务报表附注]
  end
  A[审计人员] --> UC01 & UC02 & UC03 & UC04 & UC05 & UC06 & UC07 & UC08
  R[复核人/项目经理] --> UC02 & UC03 & UC05 & UC06 & UC08
  UC02 -.include.-> UC06
  UC03 -.include.-> UC06
  UC05 -.include.-> UC06
  UC08 -.include.-> UC06
  UC05 -.差异转调整.-> UC02
  UC08 -.审定数取数.-> UC02
  UC07 -.门禁依赖.-> UC02 & UC03 & UC05 & UC08

10.2 用例清单与优先级

编号	用例	摘要	优先级	目标迭代
UC-01	导入并理解账套	账套文件导入、格式理解、勾稽校验、科目映射确认	P0	E2
UC-02	审核审计调整	调整单编制辅助、机器初审、复核流转、客户确认、SAD 汇总	P0	C1
UC-03	确认大额科目范围	重要性水平、大额候选清单、逐科范围决策	P0	C1
UC-04	管理盘点待办	五类待办生成、应盘清单提取、预填盘点表生成	P0	C2
UC-05	提交并核对盘点表	盘点表提交/解析、账实核对、现金倒轧、差异闭环	P0	C2
UC-06	统一人工审核	所有 AI 建议层的接受/编辑/驳回	P0	E2
UC-07	双交付物导出归档	修正底稿渲染、附注定稿、门禁校验、版本化导出、审计轨迹	P0	C3
UC-08	生成财务报表附注	章节模板组装、审定数取数填充、逐格勾稽、披露建议、逐章签认	P0	C3

11. 详述用例（Fully Dressed）

UC-01 导入并理解账套

项	内容
范围	潜审系统；级别：用户目标
主要参与者	审计人员
涉众与关注点	审计人员：快速、零手工整理地让账套可用；复核人：账套数据完整可信、来源留痕；被审计单位：原始文件不被修改
前置条件	项目已创建；已取得财务软件导出的账套文件（Excel/CSV/ZIP，或 GB/T 24589 国标接口文件）
成功保证	账套登记为只读原件并留 SHA-256；科目表、TB、序时账解析入库且勾稽校验通过；科目映射经人工确认；项目进入"账套就绪"状态
主成功场景	1. 审计人员上传账套文件并提交导入；2. 系统安全登记文件（只读副本、签名、哈希）；3. Agent 识别导出格式与方言，定位科目表/余额表/序时账的表与表头；4. 系统执行勾稽校验（借贷平衡、期初+发生=期末、上下级汇总一致）；5. Agent 给出科目映射建议（财务科目 → 审计科目体系）；6. 审计人员确认或修正映射；7. 系统标记账套就绪，触发大额科目候选与盘点待办的预生成
扩展	3a. 未知格式：Agent 逐 sheet 推断语义，给出候选解析方案供人工选择；3b. 多文件账套（余额表与序时账分离）：Agent 按文件名与内容指纹配对；4a. 勾稽失败：Agent 诊断根因（合并单元格/公式错误/符号方向/缺失期间），生成阻断异常并给出修复建议，人工处置后方可继续；5a. 新增科目无法映射：标记待审核，人工指定映射或新建审计科目
特殊需求	原始文件只读；解析全程不出本机（本地模式）；每个解析结论携带 EvidenceRef（文件/sheet/行列）
频率	每项目 1 次为主，可能因账套更新重导入（重导入须版本化，保留旧版对照）

UC-02 审核审计调整

项	内容
范围	潜审系统；级别：用户目标
主要参与者	审计人员（编制）、复核人（审批）
涉众与关注点	复核人：调整依据充分、借贷平衡、不重不漏；被审计单位：知悉并确认调整；项目经理：未更正错报汇总受控
前置条件	账套就绪（UC-01 完成）
成功保证	每笔调整经机器初审零缺陷、复核人审批；客户确认状态登记；调整后 TB 重算正确；未更正错报汇总（SAD）与重要性比较结果留痕
主成功场景	1. 审计人员编制调整单（手工录入/Excel 导入/盘点差异自动生成候选）；2. 系统机器初审：借贷平衡、科目存在且为末级、摘要非空、金额不超精度；3. Agent 语义初审：依据充分性、与既有调整的重叠/矛盾、对 TB 与报表项目的影响说明；4. 缺陷清零后调整单进入"待复核"；5. 复核人审批（通过/驳回）；6. 审计人员登记客户确认结果（入账/部分入账/不入账）；7. 系统重算调整后 TB，未入账部分进入 SAD 汇总并与重要性水平比较
扩展	2a/3a. 初审缺陷：逐项标注原因与证据，退回编制；5a. 驳回：附理由，回到编制状态，触发增量重审而非全量重跑；6a. 客户部分入账：系统拆分入账/未入账金额分别归集；滚调场景：导入上年 SAD，自动生成本年滚调候选，人工确认
特殊需求	调整单全程状态机留痕；任何金额修改须留旧值；Agent 影响说明不得替代复核人判断
频率	每项目数十至数百笔

UC-03 确认大额科目范围

项	内容
范围	潜审系统；级别：用户目标
主要参与者	复核人 / 项目经理
涉众与关注点	复核人：范围覆盖充分且不过度；监管质量要求：阈值依据与决策理由留痕
前置条件	账套就绪；重要性水平参数（基准、百分比）经人工确认
成功保证	大额科目清单每项含金额、波动、Agent 理由；每项有人工范围决策（纳入/剔除+理由）；往来与存款类大额对象输出函证候选清单
主成功场景	1. 系统按确认的基准计算 PM/TE/SAD 阈值；2. 系统筛选期末余额或发生额 ≥ TE 的科目为候选；3. Agent 逐科附理由（金额占比、同比波动、科目性质风险），并提示"未超阈值但性质异常"科目；4. 复核人逐科决策：纳入重点范围 / 剔除（须填理由）；5. 系统汇总形成范围底稿，对往来/货币资金类大额明细生成函证候选清单
扩展	1a. 基准参数调整：全量重算候选清单并保留前后版本差异；3a. Agent 提示的异常科目由人工决定是否补充纳入；4a. 未决科目数 > 0 时归档门禁不通过
特殊需求	计算全部由 Tool 完成；Agent 理由必须引用账套数据（EvidenceRef），禁止无依据表述
频率	每项目 1–3 轮（随账套更新或参数调整）

UC-04 管理盘点待办

项	内容
范围	潜审系统；级别：用户目标
主要参与者	审计人员
涉众与关注点	审计人员：待办自动生成、应盘清单准确；被审计单位：盘点表格式可打印可现场填写
前置条件	账套就绪
成功保证	五类盘点待办全部建立并指派；每类生成含应盘清单的预填盘点表（账 → 实方向）与空白实盘记录区（实 → 账方向）；现金类标记"突击盘点"且应盘金额由系统锁定封存
主成功场景	1. 系统按账套内容自动生成五类待办（固定资产/无形资产/库存现金/在建工程/房屋及土地），人工确认适用性（如被审计单位无在建工程则标注不适用并给理由）；2. 审计人员为每个待办指派盘点人、计划日期、地点；3. Agent 从账套提取应盘清单：固定资产卡片（名称/编号/规格/存放地/原值/累计折旧/净值）、在建工程明细（项目/预算/累计投入/形象进度记录）、现金日记账余额、房屋及土地权证清单、无形资产权证清单；4. 系统计算抽盘样本（金额覆盖率策略，默认覆盖净值 80% 且大额全抽）；5. 生成各类预填盘点表并锁定账面数
扩展	1a. 待办可人工增删（增：如存货后续迭代；删：须理由）；3a. 应盘清单缺字段（如无存放地）：标记数据质量审核项；4a. 抽盘比例人工可调整，调整留痕
特殊需求	现金应盘余额对盘点人在盘点开始前不可见（防突击失效），系统仅显示"已封存"；盘点表含签字区（盘点人/监盘人/被审计单位代表）；打印版盘点表携带版本二维码，扫描件上传时自动关联到正确的 sheet 版本，防止错配
频率	每项目每类 1 次，必要时复盘

UC-05 提交并核对盘点表

项	内容
范围	潜审系统；级别：用户目标
主要参与者	审计人员；复核人（签认）
涉众与关注点	复核人：账实核对计算正确、差异处理闭环；被审计单位：差异有申辩与处理通道
前置条件	对应盘点待办已生成盘点表；现场盘点已完成
成功保证	盘点表提交留痕（电子或扫描件 OCR 双通道）；账实核对与现金倒轧计算零差错；每项差异有处理结论（转调整/企业说明/复盘）；复核签认后待办关闭
主成功场景	1. 审计人员提交盘点表（在线填录实盘数，或上传签字扫描件由 Agent OCR 解析并逐项请人工确认）；2. 系统执行账实核对：逐项比对账面数与实盘数，生成差异清单；现金类执行倒轧：盘点日实点 ± 期间收支 = 报表日应存 vs 账面；3. Agent 对差异给出归因建议（盘盈/盘亏/已处置未销账/未入账新增/权属瑕疵/记录跨期）并引用证据；4. 审计人员逐项处理差异：转审计调整候选（进入 UC-02）/ 登记企业说明 / 申请复盘；5. 差异清零后提交复核人签认；6. 复核人签认，盘点表归档为证据，待办关闭
扩展	1a. OCR 置信度低的行整行转人工录数；2a. 实 → 账方向发现账外资产：生成"完整性差异"并提示检查未入账来源；2b. 现金倒轧涉及未入账收付凭证：列示所依据的凭证清单供人工核对；4a. 复盘：原盘点表封存，生成新版本并保留差异轨迹
特殊需求	所有核对计算由 Tool 完成；盘点表任何版本不得删除，只能封存新增
频率	每待办 1–2 次

UC-06 统一人工审核（摘要）

UC-06：所有 Agent 产出（映射建议、调整初审意见、大额理由、OCR 结果、差异归因、附注章节草稿）以统一审核队列呈现，操作仅三种：接受 / 编辑后接受 / 驳回（须理由）；审核结果回流为评测样本（数据飞轮）。

UC-07 双交付物导出归档（摘要）

归档导出门禁五条件——①盘点待办全部关闭或标注不适用；②无阻断异常与未解决高风险审核项；③大额科目范围决策与调整客户确认登记齐全；④附注全部章节签认且勾稽零差异；⑤底稿三文本区齐备、结论经确认且调整数勾稽一致。通过后导出双交付物：修正后底稿（数据区"未审→调整→重分类→审定"联动 + 审计说明 / 审计调整 / 审计结论三文本区，版式见附录 D）与财务报表附注（docx 定稿），打包为版本化导出包（另含盘点表、调整汇总、SAD、审计轨迹）。

UC-08 生成财务报表附注

项	内容
范围	潜审系统；级别：用户目标
主要参与者	审计人员；复核人（逐章签认）
涉众与关注点	复核人：附注数据与底稿审定数零差异；事务所质控：披露充分、格式合准则；被审计单位：报表批准日前定稿
前置条件	调整全部定版且 SAD 评价完成（UC-02）；已选定附注模板版本
成功保证	章节结构按模板生成（参照标准合并报表附注：公司基本情况/编制基础/会计政策/税项/合并项目注释/合并范围变更/关联方/权益/承诺或有/日后事项/母公司注释）；每个数据格有取数溯源与勾稽状态；勾稽零差异；逐章人工签认；渲染定稿 docx 纳入导出包
主成功场景	1. 系统按模板生成章节清单；2. 制度性章节由 Agent 组装样板文字并参数化（政策选择、坏账计提矩阵、折旧年限残值率等）；数据性章节由 Tool 经 `get_audited_figures` 单一口径取数填充（审定 TB、账龄组合、资产卡片变动、借款明细、盘点结论、担保清单）；3. 系统逐格勾稽：附注 ↔ 底稿审定数 ↔ 调整后 TB，表内合计复算，不一致格标红（`tie_failed`）；4. Agent 给出披露充分性建议（意见相关事项、期后事项提示、SAD 涉及科目的披露检查）；5. 审计人员编辑文字（留痕）并处置标红格；6. 复核人逐章签认；7. 全部签认后渲染定稿 docx
扩展	2a. 无数据源的章节（如资产负债表日后事项）标记"人工撰写"；3a. 勾稽失败只允许重跑取数或修正源头数据，禁止手改数据格；4a. 项目级意见类型（无保留/保留/否定/无法表示意见）由人工选择，Agent 依 SAD 与重大事项给建议并检查对应披露完整；5a. 文字编辑不改变数据格
特殊需求	数据格全部经 `get_audited_figures` 单一口径取数并留 EvidenceRef；模板版本化——首套模板以"四川远歌农业集团 2025 年度合并财务报表附注 4.29 定稿"为基准参数化；定稿 docx 保留模板原格式
频率	每项目 1–3 轮（随调整定版反复刷新重取数）

12. 补充性规格说明（非功能需求）

类别	需求
部署	Windows 10/11 单机；API 仅监听 127.0.0.1；无需 Docker/预装 Python；打包为 EXE 安装包，安装后一键运行；开发期 CLI 命令行管理（start/stop/status/logs），控制台实时日志（§23.4）
性能	5 万行序时账解析 ≤ 60s；账实核对 1 万条 ≤ 10s；Agent 单轮推理事件实时可见（SSE）
可靠性	服务重启后 Agent 作业可恢复；任何解析失败不得静默，必须转异常或审核项
安全	本地/混合云/全云三模式；混合云仅白名单结构化字段经脱敏出站；凭证密钥存 Windows Credential Manager；原始文件只读
可审计性	全部状态变更写不可变 AuditEvent；AI 每次调用记录 prompt 哈希/模型/token/延迟
质量门禁	归档前导出门禁（§UC-07）；AI 评测通过率 ≥ 85% 方可发布新版 Prompt
易用性	中文界面；盘点表可打印；关键阈值与决策理由全留痕

第四部分分析（Analysis）

13. 领域模型

以审计业务对象（而非文件）为中心建模。"账套"是聚合根之一，五个业务环节的实体都挂在项目之下：

classDiagram
  class Project {
    +id
    +name
    +fiscal_year
    +status
    +ai_mode
  }
  class AccountSet {
    +id
    +source_system
    +export_format
    +version
    +imported_at
  }
  class Account {
    +code
    +name
    +direction
    +level
    +parent_code
    +audit_subject_code
  }
  class TrialBalanceRow {
    +account_code
    +opening_dr
    +opening_cr
    +period_dr
    +period_cr
    +closing_dr
    +closing_cr
  }
  class JournalEntry {
    +date
    +voucher_no
    +summary
    +account_code
    +debit
    +credit
    +aux_tags
  }
  class AssetCard {
    +asset_no
    +name
    +spec
    +location
    +category
    +original_value
    +acc_depreciation
    +net_value
  }
  class MaterialitySetting {
    +basis
    +basis_amount
    +pm_pct
    +pm
    +te_pct
    +te
    +sad_pct
    +sad_threshold
    +confirmed_by
  }
  class LargeAccountItem {
    +account_code
    +closing_balance
    +fluctuation
    +agent_reason
    +scope_decision
    +decision_reason
  }
  class AdjustmentProposal {
    +id
    +type_AE_RJE_ROLL
    +reason
    +prepared_by
    +status
    +client_status
  }
  class AdjustmentLine {
    +proposal_id
    +account_code
    +debit
    +credit
    +summary
  }
  class CountTodo {
    +id
    +category
    +assignee
    +planned_date
    +location
    +status
    +na_reason
  }
  class CountSheet {
    +id
    +todo_id
    +version
    +count_date
    +sealed_book_amount
    +status
  }
  class CountItem {
    +sheet_id
    +ref_no
    +description
    +location
    +book_qty
    +book_amount
    +counted_qty
    +counted_amount
    +diff
    +diff_reason
    +resolution
  }
  class CountDifference {
    +item_id
    +direction
    +amount
    +attribution_suggestion
    +disposition
    +adjustment_id
  }
  class ReviewItem {
    +id
    +item_type
    +title
    +proposed_data
    +severity
    +status
    +decided_by
  }
  class ExceptionItem {
    +code
    +severity
    +blocking
    +status
  }
  class AuditEvent {
    +actor
    +action
    +object
    +old_value
    +new_value
    +at
  }
  class EvidenceRef {
    +artifact_id
    +sheet
    +cell
    +page
    +sha256
    +method
  }
  class WorkbookLayout {
    +signature
    +workbook_kind
    +semantic_map_json
    +formula_policy
    +text_anchors_json
    +suite_roles_json
    +source_hash
    +version
    +confirmed_by
    +status
  }
  class Workpaper {
    +account_code
    +index_no
    +unaudited
    +adjust_dr
    +adjust_cr
    +reclass_dr
    +reclass_cr
    +audited
    +note_text
    +adjustment_text
    +conclusion_text
    +prepared_by
    +reviewed_by
    +status
  }
  class NoteSection {
    +id
    +section_no
    +title
    +template_version
    +status
    +reviewed_by
  }
  class NoteFigure {
    +section_id
    +cell_ref
    +value
    +source_type
    +tie_status
  }

  Project "1" --> "1..*" AccountSet : 版本
  AccountSet "1" --> "*" Account
  AccountSet "1" --> "*" TrialBalanceRow
  AccountSet "1" --> "*" JournalEntry
  AccountSet "1" --> "0..*" AssetCard
  Project "1" --> "0..1" MaterialitySetting
  Project "1" --> "*" LargeAccountItem
  Project "1" --> "*" AdjustmentProposal
  AdjustmentProposal "1" --> "1..*" AdjustmentLine
  Project "1" --> "1..5" CountTodo : 五类待办
  CountTodo "1" --> "1..*" CountSheet : 版本化
  CountSheet "1" --> "*" CountItem
  CountItem "0..1" --> "0..1" CountDifference
  CountDifference --> "0..1" AdjustmentProposal : 差异转调整
  Project "1" --> "*" ReviewItem
  Project "1" --> "*" ExceptionItem
  Project "1" --> "*" AuditEvent
  ReviewItem ..> EvidenceRef : 引用
  LargeAccountItem ..> EvidenceRef
  CountItem ..> EvidenceRef
  Project "1" --> "*" NoteSection
  NoteSection "1" --> "*" NoteFigure
  NoteFigure ..> EvidenceRef : 取数溯源
  Project "1" --> "*" Workpaper
  Workpaper "*" <-- "0..*" AdjustmentProposal : 调整数来源
  Workpaper ..> EvidenceRef
  Workpaper "*" --> "1" WorkbookLayout : 版式档案

领域规则（不变式）：

DR-1 任一 TrialBalanceRow：期初(方向净额) + 本期发生(方向净额) = 期末(方向净额)，全表借贷合计各自平衡；
DR-2 AdjustmentLine 同一调整单内：Σ借方 = Σ贷方；
DR-3 LargeAccountItem.scope_decision ∈ {pending, included, excluded}，excluded 时 decision_reason 非空；归档前不得存在 pending；
DR-4 CountItem.diff = counted − book（数量与金额分别计算）；CountDifference 未清零时 CountTodo 不得关闭；
DR-5 现金类 CountSheet 必须存在倒轧记录：盘点日实点 + 报表日至盘点日支出 − 收入 = 报表日应存，与账面之差即差异；
DR-6 AdjustmentProposal 的 client_status 为 not_adopted/partial 的金额部分必须进入 SAD 汇总；
DR-7 五类 CountTodo 每类至多一个活动实例；标注 not_applicable 必须填 na_reason；
DR-8 NoteFigure.value 必须与其来源（审定 TB / 底稿审定数 / 序时账计算结果）勾稽一致；存在 tie_status = tie_failed 数据格时，所属 NoteSection 不得签认；数据格禁止人工直接改值，只能重取数；
DR-9 附注披露与 SAD / 重大事项 / 项目级意见类型一致：意见类型为非无保留或 SAD 超阈值时，相关章节必须包含对应披露，由 Reviewer 校验；
DR-10 底稿数据区：审定数 = 未审数 ± 调整数 ± 重分类调整（按科目方向），且调整数必须与已审批调整单按科目汇总一致；审计说明 / 审计调整 / 审计结论三文本区任一为空、或结论未经人工确认的科目底稿不得导出；
DR-11 任何工作簿写回之前，其版式必须有 confirmed 状态的 WorkbookLayout：结构签名命中已确认档案则直接复用，未命中须经 Agent 结构理解 + 自我验证 + 人工确认；写回严格限于档案声明的数据输入格与文本锚点格，公式区、合计行、勾稽校验格、隐藏列一律只读。

14. 系统顺序图（SSD）

14.1 账套导入与理解（UC-01）

sequenceDiagram
  actor U as 审计人员
  participant S as 系统(API薄层)
  participant O as Orchestrator
  participant L as LedgerIntake Agent
  participant T as Tools
  U->>S: importAccountSet(file)
  S->>T: register_evidence(只读/哈希/签名)
  S->>O: run(account_set_intake)
  O->>L: 任务: 理解账套
  loop ReAct 迭代
    L->>T: detect_ledger_format / parse_trial_balance / parse_journal
    T-->>L: 结构化结果 + EvidenceRef + limitations
  end
  L->>T: validate_trial_balance(勾稽)
  L->>T: suggest_account_mapping
  L-->>O: 映射建议 + 勾稽结果
  O-->>U: SSE 进度 / 待确认映射
  U->>S: confirmAccountMapping(mapping)
  S-->>U: 账套就绪

14.2 调整审核流转（UC-02）

sequenceDiagram
  actor P as 编制人
  actor R as 复核人
  participant S as 系统
  participant A as AdjustmentReview Agent
  participant T as Tools
  P->>S: submitAdjustment(proposal)
  S->>T: check_entry_balance / check_account_validity
  T-->>S: 机器初审结果
  S->>A: 语义初审任务
  A->>T: recompute_trial_balance / detect_duplicate_adjustment
  A-->>S: 初审意见 + 影响说明(建议层)
  S-->>R: 待复核(初审零缺陷)
  R->>S: reviewAdjustment(id, approve|reject)
  alt 通过
    P->>S: recordClientConfirmation(id, result)
    S->>T: recompute_trial_balance + 归集SAD
  else 驳回
    S-->>P: 退回编制(附理由)
  end

14.3 盘点提交与核对（UC-05）

sequenceDiagram
  actor U as 审计人员
  actor R as 复核人
  participant S as 系统
  participant C as Count Agent
  participant T as Tools
  U->>S: submitCountSheet(sheet 或扫描件)
  alt 扫描件
    S->>C: 解析盘点表
    C->>T: ocr_document / parse_count_sheet
    C-->>U: OCR 结果逐项人工确认
  end
  S->>T: reconcile_count(账实核对)
  alt 现金类
    S->>T: roll_forward_cash_balance(倒轧)
  end
  S->>C: 差异归因建议
  C-->>U: 差异清单 + 归因建议(建议层)
  U->>S: resolveCountDifference(itemId, disposition)
  S-->>S: 转调整候选/企业说明/复盘
  U->>S: submitForSignOff(sheetId)
  R->>S: signOffCountSheet(sheetId)
  S-->>U: 待办关闭·归档为证据

15. 操作契约（Operation Contracts）

CO-01 importAccountSet

前置：项目存在且状态允许导入；文件通过安全登记（签名/大小/路径）。
后置：创建 AccountSet 实例（version 递增）；文件登记为只读 Artifact 并留 SHA-256；创建 intake 作业；若重导入则旧版本封存保留对照。

CO-02 confirmAccountMapping

前置：intake 作业完成；映射建议已生成；无未处置的阻断型勾稽异常。
后置：Account.audit_subject_code 生效；项目状态 → ledger_ready；触发大额候选清单与五类盘点待办的预生成；写 AuditEvent。

CO-03 reviewAdjustment

前置：调整单 status = submitted；机器初审与 Agent 初审缺陷清零。
后置：approve → status = approved，进入客户确认登记；reject → status = rejected 附理由，回编制人；写 AuditEvent（含旧/新状态）。

CO-04 recordClientConfirmation

前置：status = approved。
后置：client_status 登记；未入账金额归集进 SAD 汇总；调整后 TB 重算并版本化；SAD 与 SAD 阈值比较结果留痕（超限 → 高风险审核项）。

CO-05 decideLargeAccountScope

前置：重要性水平已人工确认；候选清单已生成。
后置：每项 scope_decision 落定（excluded 须理由）；决策版本化；pending 数 > 0 时归档门禁保持不通过。

CO-06 createCountTodos

前置：项目 ledger_ready。
后置：五类 CountTodo 建立（DR-7）；每类应盘清单提取作业入队；现金类应盘余额封存；不适用标注须理由。

CO-07 submitCountSheet

前置：待办 status ∈ {sheet_issued, counting}；盘点表版本号正确。
后置：CountSheet 与 CountItem 落库；核对计算完成并生成 CountDifference；待办 status = reconciling；扫描件来源的 OCR 行保留人工确认状态。

CO-08 resolveCountDifference

前置：差异 disposition = pending。
后置：按处置类型分别——转调整：创建 AdjustmentProposal（type=AE，来源标记盘点差异）并建立关联；企业说明：留说明文本与附件；复盘：原表封存，生成新版本；全部差异清零后待办可提交签认。

CO-09 signOffCountSheet

前置：差异全部处置；盘点表含完整签认信息（盘点人/监盘人/单位代表）。
后置：CountSheet.status = archived（作为证据）；CountTodo.status = closed；写 AuditEvent。

CO-10 exportArchive

前置：导出门禁五条件全满足（§21.4）。
后置：生成版本化导出包，含双交付物——修正后底稿（三栏联动 + 审计结论）与财务报表附注（docx 定稿）；包内每份产物附证据索引与审计轨迹摘要；导出事件留痕。

CO-11 generateNoteSection

前置：调整后 TB 已定版（无 draft/submitted/under_review 状态调整单）；附注模板版本已选定。
后置：NoteSection 创建并填充 NoteFigure；每格记录取数来源（EvidenceRef + source_type）与 tie_status；表内合计复算与勾稽校验完成；存在不一致格时标 tie_failed 并生成审核项；章节 status = checked。

CO-12 approveNoteSection

前置：章节 status = checked 且无 tie_failed 数据格（DR-8）。
后置：status = approved，签认人留痕；全部章节 approved 后触发 render_note_docx 生成定稿；写 AuditEvent。

CO-13 confirmWorkbookLayout

前置：infer_semantic_layout 已产出候选档案且 verify_layout_by_formulas 全部通过（或未通过但人工框选修正完成）。
后置：WorkbookLayout.status = confirmed，记录确认人与来源文件哈希；同签名工作簿后续免理解直接写回；写 AuditEvent。

第五部分设计（Design）

16. 逻辑架构

16.1 分层视图

flowchart TB
  subgraph L1[UI 层 React]
    UI1["项目/账套视图"]
    UI2["调整审核台"]
    UI3["大额范围台"]
    UI4["盘点待办台"]
    UI5["统一审核中心"]
  end
  subgraph L2[API 薄层 FastAPI]
    API["REST + SSE · 认证 · 参数校验 · 不做编排"]
  end
  subgraph L3[Agent 编排层 Orchestration]
    ORCH["Orchestrator<br/>作业调度·事件总线·生命周期"]
    COORD["Coordinator Agent<br/>总调度"]
    REV["Reviewer Agent<br/>交叉验证·质量守门"]
    LI["LedgerIntake Agent"]
    ADJ["AdjustmentReview Agent"]
    SCOPE["Scope/Materiality Agent"]
    COUNT["Count Agent ×5类"]
  end
  subgraph L4[Tool 层 确定性能力]
    T1["ledger_tools"]
    T2["adjustment_tools"]
    T3["materiality_tools"]
    T4["count_tools"]
    T5["workflow_tools"]
    T6["knowledge_tools"]
    T7["file/ocr_tools"]
  end
  subgraph L5[Memory 层]
    M1["Working 项目事实"]
    M2["Episodic 历史经验"]
    M3["Semantic 准则知识"]
  end
  subgraph L6[基础设施 Core]
    C1["storage 只读证据"]
    C2["security 注入拦截"]
    C3["redaction 脱敏门禁"]
    C4["ai_gateway 模型路由"]
    C5["observability 追踪"]
    C6["exporter 受控导出"]
  end
  DB[("SQLite WAL")] ~~~ CH[("ChromaDB")]
  L1 --> L2 --> L3 --> L4 --> L6 --> DB
  L3 --> L5
  L5 --> CH
  L4 --> DB

依赖规则：

UI 只经 API 访问；API 只做认证、参数校验与转发，不含业务编排；
业务编排只存在于 Agent 层；Agent 之间不直接调用，经 Orchestrator 派发；
所有算术只在 Tool 层（解析、勾稽、阈值、核对、倒轧、重算）；LLM 只消费 Tool 返回的结构化结果做判断与建议；
Tool 不调用 LLM（OCR/分类等模型能力封装为 Tool，LLM 选择何时调用）；
人工门禁 Tool（mark_for_review 等）是 AI 产出进入正式结论的唯一通道；
Memory 层被 Agent 读写；Tool 不感知 Memory。

16.2 包结构（与代码无关的逻辑划分）

app/
  api/            # 薄层：router, sse, middleware, deps
  agents/         # base + 8 个业务 Agent + reviewer
  orchestration/  # orchestrator, scheduler, events
  tools/          # base/registry + 7 类 tool 模块
  memory/         # working(ORM) / episodic(sqlite-vec) / semantic(sqlite-vec)
  prompts/        # 每 Agent 一个目录: system.j2 + metadata.yaml
  evaluation/     # harness, metrics, datasets
  models/         # orm, schemas, agent_schemas
  core/           # storage/security/redaction/ai_gateway/observability/exporter/ocr_engines

16.3 技术选型总表

层	选择	说明
后端	Python 3.11 + FastAPI	异步原生，SSE 推送 Agent 事件
持久化	SQLite WAL + SQLAlchemy 2.0	单机；序时账 5 万行级对小库无压力
向量检索	sqlite-vec（SQLite 扩展，与主库同文件）+ bge-small-zh-v1.5 嵌入	替代 ChromaDB，理由见 §19
Agent 编排	自研 ReAct Loop	不引 LangChain/CrewAI：抽象层重、调试黑盒，Loop 自研仅数百行
LLM 调用	httpx 直连各家 API + tiktoken	OpenAI 兼容协议已覆盖 DeepSeek/通义/智谱
Excel 读	python-calamine（批量数据）+ openpyxl（结构/公式/合并单元格）	calamine 为 Rust 实现，5 万行序时账秒级
Excel 写	openpyxl（模板渲染盘点表）→ Excel COM（高保真导出）→ LibreOffice headless（兜底）	三级降级链；COM 强制禁宏
PDF	PyMuPDF 主力（文本层 + 页面渲染喂 OCR），pypdf 兜底	速度与提取质量优于 pypdf
docx 生成	python-docx + docxtpl 模板渲染	附注定稿：以事务所在用 docx 为模板，占位符/表格填充，保留原格式
OCR	可插拔引擎策略，见 §16.4
前端	React 19 + TS + AntD 5 + Univer（底稿预览）+ pdf.js（扫描件对照）	预览分类方案见 §16.5
Prompt	Jinja2 模板 + metadata.yaml 版本化
CLI	Typer	dev/prod 统一命令入口：进程管理、日志跟踪、DB 初始化、评测
打包分发	PyInstaller（one-folder）+ Inno Setup	产出 Setup.exe 安装包；数据目录外置，升级不丢数据

16.4 OCR 引擎策略（可插拔）

ocr_document / parse_count_sheet 的后端引擎抽象为统一接口，三种实现按部署条件选择：

引擎	定位	运行条件	优势	局限
RapidOCR（PP-OCRv5 ONNX）+ rapid-table（SLANet 表格结构）	默认引擎	纯 CPU，模型 ~200MB，pip 直接安装	中文印刷体 98%+；表格还原为"行×列→值"；Windows 分发友好	手写体弱
DeepSeek-OCR 2（3B VLM，代码 MIT）	可选高精度引擎	NVIDIA GPU ≥16GB 显存（4bit 量化可 8GB）、CUDA 11.8+；以 vLLM/transformers 推理服务形式部署（本机 GPU 或事务所共享推理节点）	版面理解强；表格转 Markdown 结构保真；坐标 grounding 可回溯单元格位置	手写体仍弱（印刷体强，连笔潦草偏差大）；无官方 Windows 原生路径与托管 API；模型加载慢、依赖重
云表格识别 API	可选云端引擎	混合云/全云显式选择	手写识别最强	L4 数据默认禁出站（§24）

决策规则：默认 RapidOCR；部署环境具备 GPU 时允许在设置中切换 DeepSeek-OCR 2；C2 迭代在盘点表扫描件评测集上对两引擎做对比评测（印刷行准确率、手写数字准确率单列、表格结构还原 F1、单页耗时），以数据决定默认引擎是否升级。手写数字对两引擎均不可直接采信，缓解措施不变：电子填录主通道、行级置信度门槛、金额列强制人工确认、确定性复算校验、版本二维码防错配。

16.5 表格预览与录入方案（按数据性质分类）

场景	方案
扁平大数据（序时账 / TB / 核对结果，万行级）	后端分页过滤 API + 前端虚拟滚动数据网格（AntD Table virtual 或 AG Grid Community），按科目/日期/金额区间查询，不做 Excel 式预览
格式化底稿（账套原表 / 生成的盘点表）	Univer 只读模式；自研 "xlsx → Univer snapshot" 转换子集（值/合并/基础样式——审计表格格式简单，可控；不依赖半停维护的 LuckyExcel 链路）
盘点表电子填录	受控可编辑表格（非通用 Excel 编辑器）：数字列数字校验、必填校验、差异自动计算
扫描件 / PDF	pdf.js 查看器 + 左图右表校对界面：左侧扫描件按行定位，右侧 OCR 结果可编辑确认

16.6 Agent 操作表格的原则（语义查询层）

Agent 从不直接读写文件字节。账套一次性解析入库后，Agent 面对的是语义查询接口：

读三铁律：

绝不整表进上下文——read_excel 只返回结构（表头/列映射/行数/样例行）；取数经 query_journal 有界查询（单次 ≤200 行 + 总数 + 分页游标）；
优先聚合后明细——SUM/占比由 Tool 计算返回；TB 全表可进上下文，序时账永不；
证据按引用不按内容——输出 (artifact_id, sheet, 单元格区域) 指针，前端点击跳转预览定位。

写两闸门：

Agent 唯一可写的是结构化数据（调整单/盘点结果/范围决策），且必经 mark_for_review 人工门禁落库；
文件产出由确定性生成器完成（按已确认结构档案受控写回 / 导出引擎 + 公式注入拦截 + 导出后校验）——Agent 决定内容，引擎负责落文件；未确认版式不得写回（DR-11）。

17. Agent 团队设计

以业务对象划分 Agent（区别于旧架构以文件类型划分）。每个 Agent 是一个"审计角色"：

Agent	审计角色	触发	输入	专属 Tools	产出（均为建议层）
Coordinator	项目协调员	用户动作（导入/提交/签认等）	项目上下文摘要	`get_project_context` `spawn_agent` `finish_task` `request_human_help`	作业计划、派发、汇总
LedgerIntake	账套理解专家	CO-01	账套文件清单	`detect_ledger_format` `read_excel` `parse_chart_of_accounts` `parse_trial_balance` `parse_journal_entries` `validate_trial_balance` `suggest_account_mapping` `mark_for_review` `mark_exception`	格式判定、勾稽报告、映射建议、数据质量审核项
AdjustmentReview	调整初审员	调整单提交/被驳回重提	调整单 + 账套快照	`check_entry_balance` `check_account_validity` `recompute_trial_balance` `detect_duplicate_adjustment` `search_knowledge` `mark_for_review`	初审意见、影响说明、矛盾提示
Scope	重要性范围分析师	账套就绪/参数变更	TB + 重要性参数	`compute_materiality` `select_large_accounts` `analyze_fluctuation` `draft_confirmation_candidates` `search_knowledge` `mark_for_review`	大额候选清单+理由、函证候选
Count ×5	盘点主办（固定资产/无形资产/库存现金/在建工程/房屋及土地各一实例，共享实现）	待办创建/盘点表提交	账套 + 待办 + 盘点表	`extract_count_population` `generate_count_sheet` `parse_count_sheet` `ocr_document` `reconcile_count` `roll_forward_cash_balance` `draft_difference_adjustment` `mark_for_review`	应盘清单、预填盘点表、OCR 结果、核对差异、归因建议
WorkbookLayout	底稿版式理解专家	导入底稿后 / 遇到未知签名版式时	工作簿结构（sheet 套件、合并、公式分布、隐藏列）	`inspect_workbook_structure` `infer_semantic_layout` `verify_layout_by_formulas` `match_layout` `register_layout` `mark_for_review`	结构档案（语义坐标 + 公式策略 + 文本锚点）、自我验证报告
NoteDrafting	附注起草员	调整定版后 / 归档前	审定 TB + 底稿结论 + 政策参数 + 模板	`get_audited_figures` `compute_aging` `draft_note_section` `check_note_consistency` `render_note_docx` `search_knowledge` `mark_for_review`	附注章节草稿、勾稽报告、披露建议
Reviewer	质量复核人	各 Agent 完成/归档前	全部 findings	`compare_findings` `check_gate_conditions` `search_knowledge`	矛盾清单、门禁核对报告

统一基类行为（继承自 agents/base.py）：ReAct Loop（think→act→observe）、max_iterations=20、停止条件（最终回复 / finish_task / request_human_help / 迭代上限 / 连续失败降级）、每轮写 llm_calls 追踪。

关键行为约束（写入各 Agent system prompt）：

任何金额、数量、比例必须来自 Tool 返回并引用 EvidenceRef，禁止凭训练知识编造数字；
发现 Tool 结果矛盾时标记矛盾并 request_human_help，不得自行取舍；
结论一律以 mark_for_review 提交，Agent 无"批准"能力；
现金类 Agent 在盘点提交前不得向对话输出封存的应盘余额。

18. Tool 设计

18.1 设计原则

单一职责：一个 Tool 做一件事，Agent 组合使用；
Pydantic 参数 schema：自动生成 function calling JSON Schema；
结构化返回：ToolResult{success, data, evidence[], limitations[], error, duration_ms}，返回 JSON 而非字符串；
写操作标 require_human_approval；
每个 Tool 必须在 limitations 声明自身局限；
读路径遵循 §16.6 读三铁律：查询类 Tool 一律有界（行数上限 + 总数 + 分页游标），聚合优先于明细；
所有计算只在 Tool 内完成（解析、勾稽、阈值、核对、倒轧、重算），LLM 不做算术。

18.2 Tool 清单（按业务分组）

ledger_tools（账套）

Tool	职责	关键参数	备注
`detect_ledger_format`	识别导出格式（用友/金蝶/国标GB24589/通用Excel 方言）	artifact_id	返回格式候选+置信度
`read_excel`	读取工作表结构与区域数据	artifact_id, sheet, range?	纯读
`parse_chart_of_accounts`	解析科目表	artifact_id, sheet, header_row?	输出口径统一的 Account[]
`parse_trial_balance`	解析科目余额表	artifact_id, sheet, period	方向/金额规范化
`parse_journal_entries`	解析序时账/凭证入库	artifact_id, sheet, date_range?	5 万行级分批，calamine 引擎
`query_journal`	序时账有界查询（科目/日期/金额区间/关键词）	account_set_id, filters, cursor?, limit≤200	返回命中行+总数+游标；Agent 取数主通道（§16.6）
`validate_trial_balance`	勾稽校验（DR-1）	account_set_id	输出违规行+可能根因分类
`suggest_account_mapping`	财务科目→审计科目映射建议	account_set_id	内部调 LLM 做语义匹配，结果仍需人工确认

adjustment_tools（调整）

Tool	职责	备注
`check_entry_balance`	调整单借贷平衡（DR-2）	零 LLM
`check_account_validity`	科目存在性/末级/方向合法	零 LLM
`recompute_trial_balance`	调整后 TB 重算（版本化）	入账口径与含未入账口径各一版
`detect_duplicate_adjustment`	与既有调整的科目/金额重叠检测	规则打分，LLM 仅作语义确认
`summarize_sad`	未更正错报汇总与阈值比较	引用 MaterialitySetting

materiality_tools（重要性/大额）

Tool	职责	备注
`compute_materiality`	PM/TE/SAD 阈值计算	参数须人工确认版本
`select_large_accounts`	阈值筛选候选科目	余额或发生额 ≥ TE
`analyze_fluctuation`	同比/环比波动计算	输出波动率与排名
`draft_confirmation_candidates`	往来/存款类大额明细 → 函证候选	仅输出清单，不发函

count_tools（盘点）

Tool	职责	备注
`extract_count_population`	按类别提取应盘清单（卡片/在建明细/现金余额/权证清单）	现金类结果加密封存
`compute_sample`	抽盘样本（金额覆盖率策略，默认净值 80% + 大额全抽）	参数留痕
`generate_count_sheet`	生成预填盘点表（账→实区 + 实→账空白区 + 签字区）	Excel 模板渲染
`parse_count_sheet`	解析回填的盘点表（电子）	与版本校验
`ocr_document`	扫描件 OCR	行级置信度；可插拔引擎（§16.4），默认 RapidOCR
`reconcile_count`	账实核对（DR-4）	输出差异清单
`roll_forward_cash_balance`	现金倒轧（DR-5）	依据凭证清单可溯
`draft_difference_adjustment`	差异 → 调整候选结构化转换	生成 draft，不直接建单

note_tools（附注与交付物）

Tool	职责	备注
`get_audited_figures`	审定数取数接口：按科目/维度返回"未审→调整→审定"三栏	附注与底稿唯一取数口径，禁止 LLM 自行取数
`compute_aging`	账龄/组合计算（依序时账与往来辅助核算）	计提矩阵参数化
`compute_movement_table`	资产变动表计算（期初→本期增减分类→期末：原值/折旧摊销/减值/净值）	固定资产/在建/无形资产/投资性房地产共用
`draft_note_section`	单章节草稿组装（样板文字 + 公司参数 + 数据格）	制度性文字与数据格分离
`check_note_consistency`	附注↔底稿↔审定 TB 逐格勾稽 + 表内合计复算	零 LLM；输出 tie_status
`draft_workpaper_texts`	起草单科目底稿三文本（审计说明/审计调整/审计结论），引用调整单与程序执行记录	建议层；人工编辑确认后生效
`render_workpaper`	按已确认结构档案受控写回原工作簿副本：只写数据输入格与文本锚点格，公式区/合计行/校验格只读	写后重算并校验 T/B 格与导出深度校验

layout_tools（工作簿版式理解）

Tool	职责	备注
`inspect_workbook_structure`	读取工作簿结构：sheet 清单与角色、合并单元格、公式分布、隐藏行列、校验格位置	纯读；产出结构签名
`match_layout`	按结构签名检索已确认档案	命中即复用，零 LLM
`infer_semantic_layout`	推断列语义（科目编码/名称/方向/账面/未审/调整借贷/重分类/审定/备注/索引）、行语义（表头层/明细行/合计行/报表数行/差异行）、文本锚点（审计说明/审计调整/审计结论）与多表套件角色（程序表/审定表/明细表/披露表/函证表）	Agent 调用；输出候选档案
`verify_layout_by_formulas`	用表内自带公式自我验证推断：按候选语义复算合计行与 T/B 勾稽校验格，全部吻合则档案可信	零 LLM；底稿自带校验公式是布局理解的天然验证器
`register_layout`	候选档案人工确认后入库（版本化）	同签名版式永久复用
`render_note_docx`	附注 docx 模板渲染（占位符与表格填充，保留原格式）	docxtpl；仅数据格经占位符写入

workflow_tools / knowledge_tools / file_tools：create_todo update_todo mark_for_review mark_exception finish_task request_human_help；search_knowledge（准则语义检索）search_past_project；register_evidence list_files read_file_text。

19. Memory 设计

层	实现	内容	读写时机
Working	SQLite `working_memory` 表	项目事实：已确认映射、重要性参数、已批准调整、盘点封存余额引用、未决假设	各 Agent 经 `get_project_context`/专用 Tool 读写，同项目共享
Episodic	sqlite-vec `episodic` 向量表	项目归档时的摘要：客户行业特征、曾踩的坑（如某格式账套表头变体）、人工驳回高频原因	归档自动嵌入；新 intake 时检索参考
Semantic	sqlite-vec `semantic` 向量表	§5 准则条目 + 企业会计准则条款 + 常见异常模式	首次部署预置嵌入；`search_knowledge` 只读检索

向量栈选型说明：准则条文与项目经验均为中文，ChromaDB 默认嵌入为英文 MiniLM，中文检索不可用，且 ChromaDB 依赖链重。改用 sqlite-vec（SQLite 扩展，与主库同文件、零额外服务）+ bge-small-zh-v1.5（约 100MB，ONNX 本地 CPU 推理）；混合云模式可切换云厂商 embedding API。向量表与业务表同库，归档导出可整体打包。

20. 用例实现（关键交互的协作要点）

UC-01 实现：SSD §14.1。LedgerIntake 的 Loop 典型 4–8 轮：探测格式 → 解析三表 → 勾稽 →（失败则诊断根因重试解析参数）→ 映射建议 → finish_task。勾稽失败不静默：分类根因（合并单元格/公式/符号/缺期间）各给修复建议，阻断异常留待人工。
UC-02 实现：SSD §14.2。驳回触发增量重审（仅该调整单相关 Agent 任务重跑），杜绝旧架构"驳回即全量 pipeline 重跑"的浪费。
UC-03 实现：Scope Agent 的候选清单与人工决策版本化成对保存；参数变更重算时保留前后版本差异对照视图。
UC-04/05 实现：SSD §14.3。Count Agent 以五实例并行（各自独立 Loop、共享 Tool 集），OCR 行级置信度 < 0.85 的行强制人工确认；复盘通过 CountSheet 版本链表达，禁删旧版。
交叉验证（Reviewer）：①盘点差异转调整的是否全部已审批；②大额范围内科目是否均有程序结论记录；③调整影响重算后 TB 与账套快照是否勾稽；④附注数据格与审定数零差异、意见相关披露完整（DR-9）；⑤双交付物之间（底稿审定数 ↔ 附注表格）一致；⑥底稿调整数与已审批调整单按科目汇总一致（DR-10）；矛盾一律进统一审核中心。

21. 状态机设计

21.1 项目状态机

created → importing → ledger_parsing → mapping_review → ledger_ready
ledger_ready → in_progress → archive_gating → archived
                ↑__(驳回/补料)__↓              ↘ blocked(阻断异常)

21.2 调整单状态机（DR-2/DR-6 约束）

stateDiagram-v2
  [*] --> draft
  draft --> submitted: 提交(机器初审)
  submitted --> under_review: 初审零缺陷
  submitted --> draft: 初审缺陷退回
  under_review --> approved: 复核通过
  under_review --> rejected: 驳回(理由)
  rejected --> draft: 修改重提
  approved --> client_confirmed: 客户入账
  approved --> client_partial: 部分入账
  approved --> client_rejected: 不入账→SAD
  client_confirmed --> posted
  client_partial --> posted: 入账部分
  client_partial --> sad_open: 未入账部分
  client_rejected --> sad_open
  sad_open --> sad_closed: SAD评价完成

21.3 盘点待办状态机（DR-4/DR-5/DR-7 约束）

stateDiagram-v2
  [*] --> todo
  todo --> not_applicable: 标注不适用(理由)
  todo --> population_ready: 应盘清单就绪
  population_ready --> sheet_issued: 盘点表生成(账面封存)
  sheet_issued --> counting: 现场盘点开始
  counting --> submitted: 盘点表提交
  submitted --> reconciling: 核对完成
  reconciling --> differences_open: 有差异
  reconciling --> pending_signoff: 无差异
  differences_open --> recounting: 复盘(新版本)
  recounting --> submitted
  differences_open --> pending_signoff: 差异清零
  pending_signoff --> closed: 复核签认归档

21.3a 附注章节状态机（DR-8/DR-9 约束）

stateDiagram-v2
  [*] --> draft
  draft --> data_filled: 取数填充(单一口径)
  data_filled --> checked: 勾稽校验通过
  data_filled --> tie_failed: 勾稽不一致(标红)
  tie_failed --> data_filled: 重取数/修正源头
  checked --> approved: 复核人签认
  approved --> rendered: 全部章节签认后渲染定稿
  approved --> data_filled: 源头数据变更需刷新

21.4 归档门禁（UC-07 五条件，Reviewer 复核）

全部 CountTodo ∈ {closed, not_applicable}；
无 blocking 异常、无高风险未决 ReviewItem、无 pending 的 LargeAccountItem；
调整单全部越过 under_review 且 client_status 已登记；SAD 评价完成；
附注全部章节 status = approved 且勾稽零差异（DR-8/DR-9）；
范围内科目底稿三文本区（审计说明/审计调整/审计结论）齐备且结论经人工确认、调整数勾稽一致（DR-10）；全部涉及工作簿的版式档案为 confirmed（DR-11）。

22. 数据设计（新增主要表，SQLite）

表	关键字段	说明
`account_sets`	id, project_id, version, source_system, export_format, status, imported_at	版本化账套
`accounts`	id, account_set_id, code, name, level, direction, parent_code, audit_subject_code, mapping_confidence	科目+映射
`trial_balance_rows`	account_set_id, account_code, opening_dr/cr, period_dr/cr, closing_dr/cr	TB
`journal_entries`	account_set_id, date, voucher_no, summary, account_code, debit, credit, aux_json	序时账
`asset_cards`	account_set_id, asset_no, name, category, location, original_value, acc_depreciation, net_value, extra_json	应盘来源之一
`materiality_settings`	project_id, basis, basis_amount, pm_pct, pm, te_pct, te, sad_pct, sad_threshold, version, confirmed_by, confirmed_at	版本化
`large_account_items`	project_id, version, account_code, closing_balance, fluctuation, agent_reason, evidence_json, scope_decision, decision_reason, decided_by	版本化成对
`adjustment_proposals`	id, project_id, type, reason, source(manual/import/count_diff), status, client_status, prepared_by, reviewed_by, version	调整单头
`adjustment_lines`	proposal_id, seq, account_code, debit, credit, summary	调整分录行
`adjusted_tb_versions`	project_id, proposal_set_hash, scope(posted/all), row_json, created_at	重算结果版本化
`count_todos`	id, project_id, category(FA/IA/CASH/CIP/LAND), assignee, planned_date, location, status, na_reason	五类待办
`count_sheets`	id, todo_id, version, count_date, sealed_book_amount, sealed_payload(enc), status, supersedes_id	版本链+封存
`count_items`	sheet_id, ref_no, description, location, book_qty, book_amount, counted_qty, counted_amount, diff, ocr_confidence, human_confirmed	明细
`count_differences`	item_id, direction, amount, attribution_suggestion, disposition, adjustment_id, resolved_by, resolved_at	差异闭环
`workpapers`	id, project_id, account_code, index_no, unaudited, adjust_dr/cr, reclass_dr/cr, audited, note_text, adjustment_text, conclusion_text, prepared_by, reviewed_by, status	交付物A底稿（数据区+三文本区，DR-10）
`workbook_layouts`	id, signature, workbook_kind, semantic_map_json, formula_policy, text_anchors_json, suite_roles_json, source_hash, version, status, confirmed_by, confirmed_at	版式结构档案（DR-11），跨项目复用
`note_sections`	id, project_id, section_no, title, template_version, status, content_ref, reviewed_by, reviewed_at	附注章节（draft→data_filled→checked→approved→rendered）
`note_figures`	section_id, cell_ref, value, source_type(tb/workpaper/journal/param), source_ref_json, tie_status	数据格溯源 + 勾稽状态（DR-8）
`review_items` / `exception_items` / `audit_events` / `agent_runs` / `llm_calls` / `working_memory`	—	沿用既有指南定义

索引：journal_entries(account_set_id, account_code)、(account_set_id, date)；count_items(sheet_id, ref_no)；adjustment_lines(proposal_id)。

23. 接口设计

23.1 内部 REST（API 薄层，全部前缀 `/api/v1`）

方法	路径	对应契约
POST	`/projects/{pid}/account-set` 导入；GET `.../account-set` 查询；POST `.../mapping/confirm`	CO-01/02
GET	`/projects/{pid}/trial-balance?version=` / `.../journal?account=&date_range=`	查询
POST	`/projects/{pid}/adjustments`；GET 列表/详情；POST `.../adjustments/{id}/submit`、`/review`、`/client-confirmation`；GET `.../sad-summary`	CO-03/04
POST	`/projects/{pid}/materiality`；GET/POST `.../large-accounts`、`.../large-accounts/decisions`；GET `.../confirmation-candidates`	CO-05
POST	`/projects/{pid}/count-todos`；GET 列表；POST `.../count-todos/{id}/issue-sheet`、`/na`；POST `.../count-todos/{id}/submit-sheet`（电子 JSON 或扫描件 multipart）；GET `.../differences`；POST `.../differences/{id}/resolve`；POST `.../sheets/{id}/signoff`	CO-06/07/08/09
GET/POST	`/projects/{pid}/workpapers`；POST `.../workpapers/{account}/draft-texts`、`/confirm`	DR-10 / 交付物A
GET/POST	`/workbook-layouts`（列表/详情）；POST `/workbook-layouts/{id}/confirm`、`/revise`（人工框选修正）	CO-13
GET/POST	`/projects/{pid}/notes/sections`；POST `.../notes/sections/{id}/generate`、`/check`、`/approve`；GET `.../notes/draft.docx`；GET `.../notes/figures?tie_status=`	CO-11/12
GET	`/projects/{pid}/review-queue`；POST `/review-items/{id}/decision`	UC-06
POST	`/projects/{pid}/export`；GET `.../exports`	CO-10
GET	`/projects/{pid}/events`（SSE，Agent 进度/思考步事件）	全部

23.2 Agent 事件（SSE 载荷类型）

job_started / agent_thinking(iteration) / tool_called(name,args摘要) / tool_result(摘要,evidence数) / review_item_created / exception_raised / waiting_human / job_finished / cost_update(tokens,cost)。

23.3 统一错误与证据

沿用既有规范的统一错误信封与 EvidenceRef 结构（artifact_id + sheet/cell/page + sha256 + method + confidence + limitations[]），扩展 method 枚举：ledger_parse | rule_check | ocr | llm_suggestion | human。

23.4 部署与运行设计（EXE 分发与 Dev CLI）

23.4.1 生产形态：EXE 安装包，一键运行

项	设计
构建管线	`scripts/build_exe.ps1`：前端 `npm run build` → PyInstaller（one-folder spec；collect-data：`web/dist`、`prompts/`、`profiles/`；hidden imports：uvicorn 子模块、sqlite-vec、onnxruntime、rapidocr；排除 torch/paddle 等重依赖）→ Inno Setup `installer.iss` → `DiveMindSetup-x.y.z.exe` + SHA-256 清单；版本号唯一来源 `app/version.py`
安装与启动	安装后桌面/开始菜单快捷方式，双击即运行 `divemind.exe start` 并自动打开 `http://127.0.0.1:8765`；控制台窗口实时滚动日志，关闭窗口即停止
进程模型	生产单进程：uvicorn 编程方式进程内运行，Agent 调度器与 SSE 事件总线作为 asyncio 任务同循环运行——规避 PyInstaller 多进程打包（freeze_support/子进程重复拉起）问题；OCR 等重计算仍走独立子进程池隔离
数据目录	外置 `%APPDATA%\DiveMind\`（db / logs / projects / secrets / vector / mapping）：安装、卸载、升级均不动数据；首次启动自动初始化（建库、嵌入语义知识、生成会话令牌）
签名与杀软	发布包做代码签名；未签名会触发 SmartScreen/杀软误报（PyInstaller 产物常见问题），发布说明中给出处置指引

23.4.2 开发形态：CLI 命令管理 + 控制台日志

统一 CLI（Typer），开发态 python -m app.cli <cmd>，打包态同一套命令 divemind.exe <cmd>：

命令	职责
`divemind dev start [--port 8765] [--reload] [--log-level DEBUG]`	启动 API + 调度器；`--reload` 热重载；日志直接输出到控制台
`divemind dev stop / restart / status`	PID 文件管理 + `/api/health` 探测（端口、运行时长、版本、AI 模式）
`divemind dev logs [-f] [--tail 200]`	查看/跟踪日志文件
`divemind web dev`	前端 Vite 开发服务器（子进程，代理到 API）
`divemind db init / backup`	建库初始化 / 数据目录打包备份
`divemind eval run --dataset <name>`	离线评测（§25）

23.4.3 日志设计

统一 logging 配置：Console Handler（开发默认 DEBUG、生产 INFO+，等级着色）+ RotatingFileHandler（logs/divemind-YYYYMMDD.log，10MB×5 滚动）；uvicorn access log 与 SQLAlchemy 日志接入同一配置；每次请求/Agent 作业生成 trace_id，贯通日志行与 SSE 事件，便于把控制台日志定位到具体 Agent 迭代与 LLM 调用。

24. 安全与合规设计

层面	设计
网络/会话	仅监听 127.0.0.1、启动期会话令牌、严格 Origin/CORS 白名单（沿用既有安全原则）
文件安全	账套原件只读登记 + SHA-256；ZIP 安全解压防路径穿越；盘点表扫描件同规则；公式注入拦截（`=` `+` `-` `@` 开头拒绝）
现金封存	`count_sheets.sealed_payload` 使用 Fernet 加密，盘点提交前任何 API 不返回明文应盘余额（含 Agent 对话，写入 Count Agent prompt 约束）
数据分级出站	本地模式不出机；混合云仅白名单结构化字段（科目编码/金额/比率）经脱敏 Token 化出站，序时账摘要、单位名称、盘点表明细默认 L4 严禁出站；出站/入站二次扫描
OCR/推理出站	默认 OCR 引擎（RapidOCR）全程本地；切换 DeepSeek-OCR 2 远程推理节点或云 OCR 视为混合云出站，受白名单、脱敏与显式选择约束，扫描件图像默认 L4
权限与留痕	单机下以"角色名+口令"区分编制/复核操作；全部状态变更写不可变 AuditEvent（actor/action/object/old/new/at）
责任边界	界面明示"AI 建议层"水印；签认操作必须人工点击且留痕，Agent 无签认能力

25. 可观测性与评测设计

追踪：每次 LLM 调用写 llm_calls（agent/prompt_hash/model/tokens/延迟/成本/迭代序号）；每次 Agent 运行写 agent_runs（含完整 trace JSON）；SSE 实时推送 cost_update。
评测（FDE）：为四类核心 AI 能力建标注数据集——账套格式识别（≥20 份各软件导出变体）、科目映射建议（≥200 科目）、调整初审意见（≥50 单）、盘点表 OCR 行解析（≥30 份扫描件）。指标：格式识别准确率、映射 Top-1 命中率、勾稽失败根因分类 F1、OCR 行准确率、幻觉率（断言可在 EvidenceRef 中溯源的比例）；附注数据格取数准确率与勾稽一致性（以四川远歌 4.29 附注定稿为首个黄金标准，逐格对拍）。
OCR 引擎对比评测：C2 迭代在盘点表扫描件评测集上对比 RapidOCR 与 DeepSeek-OCR 2——印刷行准确率、手写数字准确率单列、表格结构还原 F1、单页耗时与成本；评测结论决定默认引擎是否升级（§16.4）。
嵌入检索评测：中文准则条目的 search_knowledge Top-5 命中率，作为 bge-small-zh 与云 embedding 的切换依据。
数据飞轮：统一审核中心的接受/编辑/驳回自动采集为正/负样本；Prompt 版本化（prompts/<agent>/metadata.yaml），发布前在评测集回归，通过率 < 85% 门禁不发布。
降级：云超时 → 本地模型 → 纯规则 Tool + 全量人工，三级渐进降级，任何降级在 UI 明示。

第六部分 UP 迭代计划与风险

26. 阶段划分

UP 阶段	迭代	目标	主要交付物	出口标准（里程碑）
初始 Inception	I0（1 周）	愿景对齐、业务建模、风险识别	本文档 §1–§8、术语表	利益相关方确认范围与优先级
细化 Elaboration	E1（2 周）	架构骨架：Agent 基类/Tool 框架/统一审核/账套解析 Tool	`agents/base.py`、`tools/ledger_tools`、审核队列、`llm_calls`、`app/cli.py`（start/stop/status/logs）、账套格式样张库（用友 U8/NC、金蝶 K3/KIS/云星空各版本导出样张，每类 ≥2 份，持续收集）	UC-01 无 LLM 链路可跑通（规则解析+人工确认映射）
细化 Elaboration	E2（1 周）	LedgerIntake + Coordinator 接入 LLM，SSE 事件	Agent Loop、prompts v1、UC-06	UC-01 全链路（含 LLM 方言识别）通过样例账套；架构基线确立
构建 Construction	C1（2 周）	UC-02、UC-03	AdjustmentReview/Scope Agent、调整与重要性 Tools、状态机	调整全流程与 SAD 评价在黄金样例上闭环
构建 Construction	C2（2 周）	UC-04、UC-05	Count Agent×5、count_tools、封存机制、OCR 双引擎通道	五类盘点从待办到签认闭环；现金倒轧经人工复核零差错；OCR 引擎对比评测完成并定版默认引擎
构建 Construction	C3（2 周）	UC-07、UC-08、Reviewer、评测门禁	NoteDrafting Agent、note_tools、附注模板库（首套以远歌 4.29 定稿参数化）+ 底稿模板（ZB 系列审定表版式，附录 D）、双交付物导出、EvalHarness	门禁五条件可演示阻断/放行；附注全章节勾稽零差异并对拍黄金样例；评测 ≥85%
移交 Transition	T1（1 周）	用户验收、部署包、评测报告固化	EXE 安装包（build 管线固化）+ CLI 命令、操作手册、评测基线报告	两套黄金样例端到端 UAT 通过；干净 Windows 机器安装-启动-导入全流程验证

27. 风险清单

#	风险	等级	应对
R1	财务软件导出格式碎片化，账套理解准确率不足	高	E1 优先；格式方言评测集先行；未知格式走"候选解析方案+人工选择"保底路径，永不静默失败
R2	LLM 编造金额/理由（幻觉）污染审计证据	高	数字强制 EvidenceRef 溯源（写入 prompt 与 Reviewer 校验）；幻觉率纳入发布门禁
R3	盘点表扫描件 OCR 质量不稳定，手写数字为所有本地引擎的共性弱项	中	电子填录为主通道、OCR 为辅；行级置信度 <0.85 强制人工 + 金额列单独确认；确定性复算兜底（合计复算/数值校验/差异阈值标黄）；RapidOCR 与 DeepSeek-OCR 2 双引擎 C2 评测定版；打印表带版本二维码防错配
R4	现金封存余额经 Agent 对话泄漏	中	Tool 层加密 + prompt 约束 + Reviewer 出站检查三重防线
R5	重要性参数/抽盘比例被误当作 AI 决策	中	参数仅人工可改且版本化，UI 标注"人工决策项"
R6	单机性能（5 万行序时账 + 多 Agent 并行）	中	解析分批 + 索引设计（§22）；Count 实例并行上限 3，队列排队
R7	审核责任边界被用户误解为"AI 审定"	高	全程"建议层"水印、签认仅人工、操作手册明示准则责任归属
R8	底稿版式碎片化（科目间细微差别、各所格式不同），预定义坐标不可维护	高	不为任何科目写死模板：导入底稿即模板，Agent 运行时结构理解 + 公式自验证 + 人工首确，档案跨项目复用（DR-11）；理解失败的极端变体由人工框选兜底
R8a	Agent 版式理解错误导致写错单元格	高	三道防线：`verify_layout_by_formulas` 用底稿自带勾稽公式自验证；写回仅限档案声明格；导出后深度校验（公式/合并/隐藏/校验格逐项比对，不一致即阻断）
R9	附注数据格被人工手改导致勾稽失效	中	数据格禁止手改（DR-8），只能重取数；docx 定稿渲染后再做一遍导出后勾稽校验

附录

附录 A 盘点业务规则参数表（默认值，均可人工调整并留痕）

类别	应盘来源	抽盘策略	方向	特殊规则
固定资产 FA	固定资产卡片	净值覆盖率 ≥80%，单项净值 ≥TE 全抽	双向	记录使用状态（在用/闲置/毁损）；关注负净值、已提足仍在用
无形资产 IA	权证清单（专利/商标/土地使用权等）	全项检查权属	账→证	核对权利人、有效期、他项权利；摊销复核另列程序
库存现金 CASH	现金日记账余额（封存）	全额实点	实点+倒轧	突击盘点；倒轧依据凭证清单可溯；外币分别列示
在建工程 CIP	在建工程明细	投入额 ≥TE 全抽实地察看	账→实	记录形象进度；关注长期停工、利息资本化异常
房屋及土地 LAND	权证清单+房屋建筑物卡片	全项权证检查+抽点实地	双向	核对权属人/坐落/面积/他项权利（抵押查封）

附录 B 与既有文档对照

本文档	既有文档对应
§8 能力映射	`ARCHITECTURE_GAP_ANALYSIS.md` §2 诊断结论的业务化落地
§16–19 架构/Agent/Tool/Memory	`AGENT_ARCHITECTURE_GUIDE.md` §1/4/7 的继承；Agent 划分由文件中心改为业务对象中心
§24 安全	`DiveMind_W2_Skills_...v2.md` 安全边界的继承 + 现金封存新增
§21 状态机/门禁	`PROJECT_HANDBOOK.md` 项目状态机与导出门控思想的扩展（调整单、盘点待办两级新状态机）

附录 C 交付物模板结构

C.1 交付物 A：修正后底稿——"导入底稿即模板"

不从零创建任何表格模板。审计人员导入的底稿工作簿本身就是格式载体：系统从其中提取结构、在副本上受控写回（DR-11）。以实际样例 (6215)合同负债.xlsx 说明结构要素（各科目版式存在细微差别，均由 Agent 运行时理解，不写死）：

多表套件（8 sheet）：封稿目录 / 审计程序 / 审定表（主表）/ 明细表 / 函证汇总 / 披露表×2 / 凭证明细；套件角色由 suite_roles_json 记录——明细表喂审定表、审定表与披露表喂附注；
审定表数据区：双层表头 + 科目行 + 合计行 + 报表数行 + 差异行；列语义含科目编码/名称/借贷方向/期末账面/账表调整/未审/账项调整借贷/重分类借贷/审定/索引/上期对照/变动额率；
自带勾稽校验：合计行 SUMIF 按借贷方向求和，校验格 =IF(ABS(F7-F9)<0.01,"T/B","错")——底稿自带的公式体系是 Agent 验证版式理解的天然依据（verify_layout_by_formulas），也是写回后导出校验的判定标准；
文本锚点区：审计调整（A11 起）/ 审计说明（A13）/ 审计结论（A15），位置随行数浮动，由 text_anchors_json 记录；
表头签章区：被审计单位/索引号/页次/编制人/复核人+日期，导出时校验非空；
操作说明区：底稿固有的使用说明文字，只读保留。

写回分工：数据输入格 ← get_audited_figures（三栏口径，DR-10）；文本锚点格 ← draft_workpaper_texts（人工确认后）；公式区、合计行、校验格、隐藏列一律只读；审计程序表的"是否执行"列同属可写输入格（程序执行状态回写）。

C.1a 附注模板

附注 docx 同样"以事务所在用文档为模板"（首套以远歌 4.29 定稿参数化），章节级占位符，docxtpl 渲染；与底稿版式理解不同，附注格式按所相对稳定，模板库手工维护即可。

C.2 交付物 B：财务报表附注（十二章标准结构）

章节结构以远歌 4.29 定稿为基准：一、公司基本情况；二、编制基础；三、重要会计政策和会计估计；四、税项；五、合并财务报表主要项目注释；六、合并范围的变更；七、关联方及关联交易；八、在其他主体中的权益；九、承诺及或有事项；十、资产负债表日后事项；十一、其他；十二、母公司财务报表主要项目注释。制度性章节为"样板文字+公司参数"，数据性章节为"单一口径取数+逐格勾稽"（§UC-08）。

附录 D 待决问题（移交评审前需关闭）

五类盘点之外是否本期纳入"存货监盘"（建议 R2 迭代单独立项）；
函证候选清单是否对接电子函证平台（本期仅导出清单）；
复核人角色在单机下的认证强度（口令 vs Windows 凭据）；
重导入账套的版本差比对视图是否进 C1（当前排 C3 之后评估）；
DeepSeek-OCR 2 推理节点的部署形态（审计笔记本本机 GPU vs 事务所共享推理服务器），待 C2 对比评测后决定；
盘点表打印二维码的编码内容是否包含项目标识（涉及打印件遗失时的信息泄漏面），安全评审时确认；
生产运行是否需要托盘常驻 / Windows 服务形态（v1 默认控制台窗口，关窗即停）；代码签名证书的采购归属。

README.md Unescape Escape