【S3W3 交叉评测】潜审 AuditAgent：工程闭环、交付证据与可复现性建议 #4

New issue

Open

opened 2026-08-06 15:57:26 +08:00 by visionary · 1 comment

visionary commented

2026-08-06 15:57:26 +08:00

项目理解

我理解“潜审 AuditAgent”希望把审计人员现有的工作底稿包和可选账套作为输入，通过 Agent、确定性 Tool 和人工门禁协作，覆盖底稿版式理解、语义层合成、审计调整、大额科目确认、五类盘点待办、附注生成以及修正后底稿导出。

项目并不是让大模型直接“做审计结论”，而是让模型承担理解、编排和草拟，让金额计算、勾稽校验、状态转换由确定性工具完成，最终签认保留给审计人员。
项目亮点

业务建模深度较强，围绕底稿、调整单、盘点待办、证据引用和交付物建立了较完整的领域模型，而不是只做一个通用聊天页面。
仓库中不仅有设计文档，也存在 Fast API 路由、React 前端、Agent、Tool、Memory、SQLite 数据层、OCR 适配、测试样例和 Excel fixture，工程覆盖面较完整。
“LLM 不做算术”“数字必须通过 Evidence Ref 溯源”“人工签认不可由 Agent 替代”等原则与审计场景的高风险特征匹配。
-调整单、盘点待办、附注章节和归档门禁均采用状态机设计，有利于避免模型绕过业务流程直接产生最终交付物。
-对模型调用成本、Prompt 版本、降级路径、审计日志和评测集已有较系统的规划，体现了从 Demo 向工程系统演进的意识。

当前问题

README 内容非常长，主体更接近完整架构设计书。W3 评审很难在几分钟内区分“已经实现”“可以演示”“规划中”三类状态。
README 引用了 ”潜审_AuditAgent_UP设计文档_v1.1_底稿主路径.md“、"PROJECT_HANDBOOK.md"、"AGENT_ARCHITECTURE_GUIDE.md" 等文件，但当前公开仓库中未找到这些文件，影响文档溯源和复现。
公开代码体量较大，但缺少一份短小、稳定的一键复现路径和已通过的测试结果摘要。审计场景不能仅凭设计完整度证明实际正确性。
"pyproject.toml" 当前显式配置 "packages = ["app"]"，建议检查安装构建后 "app.agents"、"app.api"、"app.tools" 等子包是否会被完整打包，避免源码目录运行正常、安装包运行缺模块。
各专业 Agent 类本身较轻，核心能力大量集中在 BaseAgent、Routes 和 Tools 中。需要进一步展示不同 Agent 的业务差异、Prompt 差异以及实际协作证据。
当前评测指标主要以计划形式呈现。对于金额、勾稽、OCR 和底稿写回，应补充真实运行结果、错误样例和导出前后对拍证据。

建议

在 README 最前面增加“一页式 W3 导航”：项目价值、3 分钟演示步骤、当前已实现能力、尚未实现能力、启动命令、测试结果和证据链接。
补齐被引用的 v1.1 与历史设计文件，或者删除失效引用，并明确唯一有效的设计基线。
提供至少一套完全脱敏的黄金样例，展示“导入底稿包 → 识别版式 → 形成调整或盘点待办 → 人工确认 → 导出底稿与附注”的完整链路。
发布实际测试摘要，包括通过用例数、失败用例、金额勾稽一致率、OCR 行准确率、底稿结构保持结果和平均处理耗时。
使用干净环境执行一次安装包验证，确认 Python 子包、前端构建产物、OCR 可选依赖和模板资源都被正确打包。
对高风险结论增加可视化证据入口，让评审可以从结论直接定位到工作簿、Sheet、单元格、公式或原始凭证，而不是只看到文本引用编号。

综合评价
```
这是一个专业领域建模和工程规划都比较深入的项目，优势在于没有把大模型包装成“自动审计师”，而是强调确定性计算、证据溯源和人工责任边界。
```
当前最需要补强的不是继续扩展设计范围，而是压缩评审入口、修复文档引用、展示真实黄金样例和量化运行证据。只要能够证明底稿写回、金额勾稽和人工门禁在真实样例中稳定成立，项目可信度会明显提升。

1. 项目理解我理解“潜审 AuditAgent”希望把审计人员现有的工作底稿包和可选账套作为输入，通过 Agent、确定性 Tool 和人工门禁协作，覆盖底稿版式理解、语义层合成、审计调整、大额科目确认、五类盘点待办、附注生成以及修正后底稿导出。项目并不是让大模型直接“做审计结论”，而是让模型承担理解、编排和草拟，让金额计算、勾稽校验、状态转换由确定性工具完成，最终签认保留给审计人员。 2. 项目亮点 - 业务建模深度较强，围绕底稿、调整单、盘点待办、证据引用和交付物建立了较完整的领域模型，而不是只做一个通用聊天页面。 - 仓库中不仅有设计文档，也存在 Fast API 路由、React 前端、Agent、Tool、Memory、SQLite 数据层、OCR 适配、测试样例和 Excel fixture，工程覆盖面较完整。 - “LLM 不做算术”“数字必须通过 Evidence Ref 溯源”“人工签认不可由 Agent 替代”等原则与审计场景的高风险特征匹配。 -调整单、盘点待办、附注章节和归档门禁均采用状态机设计，有利于避免模型绕过业务流程直接产生最终交付物。 -对模型调用成本、Prompt 版本、降级路径、审计日志和评测集已有较系统的规划，体现了从 Demo 向工程系统演进的意识。 3. 当前问题 - README 内容非常长，主体更接近完整架构设计书。W3 评审很难在几分钟内区分“已经实现”“可以演示”“规划中”三类状态。 - README 引用了 ”潜审_AuditAgent_UP设计文档_v1.1_底稿主路径.md“、"PROJECT_HANDBOOK.md"、"AGENT_ARCHITECTURE_GUIDE.md" 等文件，但当前公开仓库中未找到这些文件，影响文档溯源和复现。 - 公开代码体量较大，但缺少一份短小、稳定的一键复现路径和已通过的测试结果摘要。审计场景不能仅凭设计完整度证明实际正确性。 - "pyproject.toml" 当前显式配置 "packages = ["app"]"，建议检查安装构建后 "app.agents"、"app.api"、"app.tools" 等子包是否会被完整打包，避免源码目录运行正常、安装包运行缺模块。 - 各专业 Agent 类本身较轻，核心能力大量集中在 BaseAgent、Routes 和 Tools 中。需要进一步展示不同 Agent 的业务差异、Prompt 差异以及实际协作证据。 - 当前评测指标主要以计划形式呈现。对于金额、勾稽、OCR 和底稿写回，应补充真实运行结果、错误样例和导出前后对拍证据。 4. 建议 - 在 README 最前面增加“一页式 W3 导航”：项目价值、3 分钟演示步骤、当前已实现能力、尚未实现能力、启动命令、测试结果和证据链接。 - 补齐被引用的 v1.1 与历史设计文件，或者删除失效引用，并明确唯一有效的设计基线。 - 提供至少一套完全脱敏的黄金样例，展示“导入底稿包 → 识别版式 → 形成调整或盘点待办 → 人工确认 → 导出底稿与附注”的完整链路。 - 发布实际测试摘要，包括通过用例数、失败用例、金额勾稽一致率、OCR 行准确率、底稿结构保持结果和平均处理耗时。 - 使用干净环境执行一次安装包验证，确认 Python 子包、前端构建产物、OCR 可选依赖和模板资源都被正确打包。 - 对高风险结论增加可视化证据入口，让评审可以从结论直接定位到工作簿、Sheet、单元格、公式或原始凭证，而不是只看到文本引用编号。 5. 综合评价这是一个专业领域建模和工程规划都比较深入的项目，优势在于没有把大模型包装成“自动审计师”，而是强调确定性计算、证据溯源和人工责任边界。当前最需要补强的不是继续扩展设计范围，而是压缩评审入口、修复文档引用、展示真实黄金样例和量化运行证据。只要能够证明底稿写回、金额勾稽和人工门禁在真实样例中稳定成立，项目可信度会明显提升。

LIGHTNINGWHALE commented

2026-08-06 21:01:33 +08:00

Owner

感谢评审。对项目目标与责任边界的理解是准确的：潜审并非让大模型直接作出审计结论，而是由 Agent 负责理解、编排与草拟，由确定性 Tool 完成金额计算、勾稽与状态转换，最终签认保留给审计人员。

关于已实现能力与验证入口
底稿版式理解、语义层合成、调整审核、大额确认、五类盘点、附注与修正底稿导出等主路径，以当前代码（app/agents/、app/tools/、FastAPI 路由、React 前端）、docs/CONTRACTS.md、仓库测试与夹具，以及公开 Demo / Windows 试用版为准：
https://www.divesee.com/divemind/

领域模型、状态机门禁、Evidence Ref、LLM 不做算术、人工签认不可替代等原则，已体现在实现与测试中，而非仅停留在设计叙述。

关于评审导航与文档基线
公开材料同时包含产品叙事与工程细节。W3 快速评审建议优先走试用版 3 分钟主路径；实现约束与接口基线以 docs/CONTRACTS.md 与代码为准。如评测需要一页式导航（价值、演示步骤、能力清单、启动与测试入口），我们可按评审口径另行提供。

关于复现与量化证据
仓库已包含脱敏 Excel fixture、自动化测试与冒烟脚本，覆盖账套解析、调整、盘点、OCR、底稿与交付物等模块。黄金样例链路与测试摘要（通过数、勾稽/OCR/写回结果）可按评审需要整理输出；完整作业体验建议直接试用 Windows 版验证。

关于工程结构与 Agent 差异
各专业 Agent 基于统一 ReAct 基座，差异主要体现在 Prompt、可用 Tool 集与业务门禁上；协作过程通过模型调用、工具动作与观察结果入库留痕。安装与打包方面，产品侧以试用版分发为主路径；源码安装以仓库可运行状态为准，相关打包清单可按需要复核。

综合评价中对「确定性计算 + 证据溯源 + 人工责任边界」的判断，与我们的产品原则一致。欢迎基于试用版具体操作路径继续反馈。

感谢评审。对项目目标与责任边界的理解是准确的：潜审并非让大模型直接作出审计结论，而是由 Agent 负责理解、编排与草拟，由确定性 Tool 完成金额计算、勾稽与状态转换，最终签认保留给审计人员。 **关于已实现能力与验证入口** 底稿版式理解、语义层合成、调整审核、大额确认、五类盘点、附注与修正底稿导出等主路径，以当前代码（app/agents/、app/tools/、FastAPI 路由、React 前端）、docs/CONTRACTS.md、仓库测试与夹具，以及公开 Demo / Windows 试用版为准： https://www.divesee.com/divemind/ 领域模型、状态机门禁、Evidence Ref、LLM 不做算术、人工签认不可替代等原则，已体现在实现与测试中，而非仅停留在设计叙述。 **关于评审导航与文档基线** 公开材料同时包含产品叙事与工程细节。W3 快速评审建议优先走试用版 3 分钟主路径；实现约束与接口基线以 docs/CONTRACTS.md 与代码为准。如评测需要一页式导航（价值、演示步骤、能力清单、启动与测试入口），我们可按评审口径另行提供。 **关于复现与量化证据** 仓库已包含脱敏 Excel fixture、自动化测试与冒烟脚本，覆盖账套解析、调整、盘点、OCR、底稿与交付物等模块。黄金样例链路与测试摘要（通过数、勾稽/OCR/写回结果）可按评审需要整理输出；完整作业体验建议直接试用 Windows 版验证。 **关于工程结构与 Agent 差异** 各专业 Agent 基于统一 ReAct 基座，差异主要体现在 Prompt、可用 Tool 集与业务门禁上；协作过程通过模型调用、工具动作与观察结果入库留痕。安装与打包方面，产品侧以试用版分发为主路径；源码安装以仓库可运行状态为准，相关打包清单可按需要复核。综合评价中对「确定性计算 + 证据溯源 + 人工责任边界」的判断，与我们的产品原则一致。欢迎基于试用版具体操作路径继续反馈。

No labels

No milestone

No project

No assignees

2 participants

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

LIGHTNINGWHALE/DiveMind#4

No description provided.

Rows
Columns