LIGHTNINGWHALE/DiveMind

Fork 0

【S3W3 交叉评测】潜审 DiveMind：审计 Agent 的工程一致性、安全边界与可验证性建议 #2

New issue

Open

opened 2026-08-06 11:01:28 +08:00 by chozzc · 2 comments

chozzc commented

2026-08-06 11:01:28 +08:00

1. 项目理解

DiveMind 是一个面向审计业务的本地化 Agent 工作台，核心流程不是简单的问答，而是：

账套或底稿导入 → 文件解析与列映射 → 试算平衡与规则检查 → 调整建议 → 人工审核队列 → 审计底稿、附注及交付物导出。

项目采用 FastAPI + SQLAlchemy + SQLite 作为后端，React + TypeScript + Vite 作为前端，并通过 ReAct 循环组织 Agent 的思考、工具调用和结果观察。项目 README

当前代码中的 Agent 已扩展为 coordinator、ledger_intake、adjustment_review、scope、count、workbook_layout、note_drafting、reviewer 等多个角色，分别负责账套导入、调整审核、重要性水平、盘点、底稿版式、附注和复核等任务。Agent 工厂

项目的主要设计思想是：LLM 负责选择工具和解释结果，金额计算、余额校验、调整建议和数据落库由确定性工具完成；Agent 的建议需要进入人工审核队列，不直接完成最终签认。Agent 基类、项目契约

整体来看，DiveMind 更接近“审计业务流程 Agent 系统原型”，而不是普通的 AI 聊天页面或 Prompt 包装项目。

2. 项目亮点

2.1 业务场景具体，Agent 不停留在对话层

项目围绕审计中真实存在的账套、试算平衡、调整分录、底稿、盘点和附注等对象建立了数据模型和流程，Agent 能够调用试算平衡、波动识别、调整建议、审核队列等领域工具。

这比泛化的“让大模型分析 Excel”更接近真实业务系统，也更容易体现 Agent 的任务执行能力。

2.2 确定性工具与 LLM 推理分工合理

项目明确限制 LLM 不直接进行金额计算，而是通过工具完成计算与校验。工具注册表也为每个工具定义了名称、描述和参数结构。工具注册表

这种设计可以降低模型进行金额计算时的幻觉风险，并且方便后续替换模型。

2.3 人工审核闭环设计比较完整

Agent 的建议不会直接成为最终审计结论，而是写入 ReviewItem 审核队列，再由人工批准或驳回。同时项目还记录 AuditEvent、Agent 迭代过程和 LLM 调用记录。

这种“Agent 建议—人工审核—留痕”的模式适合审计场景，也符合高风险业务中人机协同的基本要求。

2.4 底稿导入和导出考虑到了真实数据结构

底稿导入支持 ZIP 文件、Excel 工作簿和 PDF 证据文件，并对 ZIP 路径穿越进行了防护。系统还会对工作簿进行版式识别、审定表解析和语义层合成。底稿导入工具

交付物导出前还存在一定的门禁检查，例如未完成的盘点事项、未审核的调整、未确认的底稿或附注内容可能阻止导出。交付物接口

2.5 Mock 模式和测试夹具对开发比较友好

项目提供 Mock LLM Gateway 和测试夹具，可以在不调用真实模型的情况下测试 Agent 流程。README 声称当前有 57 个测试用例，仓库中也包含账套、Agent、审核、OCR、内存检索和底稿导入等多类测试文件。测试目录

这说明项目作者已经考虑到 Agent 系统难以稳定测试的问题。

3. 当前存在的问题

3.1 重要：AI 模式的文档说明与实际代码不一致

这是我认为当前最值得优先修复的问题。

设置接口允许选择：

openai
mock
local
hybrid

前端也提供了“混合模式”等选项。但是当前 get_gateway() 的实际逻辑是：只有 ai_mode == "mock" 时使用 Mock Gateway，其他模式全部使用 OpenAI 兼容接口。LLM 网关、设置接口

也就是说，目前 local 和 hybrid 并没有真正对应的本地模型或白名单字段出站逻辑，而是仍然会进入 OpenAI 兼容远程接口。

这与 README 中“本地模式不出机”“混合云仅发送白名单字段”等安全设计说明存在明显差距。README 安全设计

对于审计系统来说，这不仅是功能问题，也涉及财务数据是否会被发送到云端。

建议：

为 local、hybrid 实现明确的 Gateway；
如果本地模型不可用，应该直接报错，而不是静默切换到远程模型；
在发送 LLM 前增加字段分级和脱敏策略；
增加测试，确保 local 模式不会发起远程 HTTP 请求；
在界面明确显示本次调用是否出站、发送了哪些字段。

3.2 重要：完整 Prompt 和模型响应会直接落库

BaseAgent 会将完整的 messages 写入 LLMCall.prompt_text，同时保存完整的 response_text。Agent 基类、数据模型

审计 Prompt 可能包含：

企业名称；
科目余额；
财务金额；
凭证摘要；
底稿内容；
盘点信息；
人员或客户资料。

如果这些内容全部以明文存入 SQLite，那么即使模型调用本身受控，本地数据库和备份文件仍可能暴露敏感信息。

另外，项目的 API Key 存储在本机 JSON 设置文件中，当前代码没有看到操作系统级密钥保护。本地设置存储

建议：

默认只保存 Prompt 哈希、模型、Token 数量、延迟和摘要；
完整 Prompt/Response 改为用户主动开启的调试选项；
对企业名称、账号、金额和人员信息进行脱敏；
为 LLM 记录设置保留期限和删除机制；
Windows 环境优先使用 DPAPI 或系统凭据存储保护 API Key；
日志中也应统一增加敏感字段脱敏。

3.3 重要：会话令牌目前没有形成真正的 API 鉴权

项目会生成 session_token，README 也提到本机会话令牌和角色切换。但当前路由依赖主要是数据库和配置依赖，没有看到所有业务接口统一校验该令牌的中间件或鉴权依赖。

项目默认监听 127.0.0.1，因此在默认本地运行场景下风险有限。但如果用户把服务绑定到 0.0.0.0、局域网地址或反向代理之后，其他请求方可能直接访问项目、设置、导入和 Agent 接口。

建议：

默认拒绝非回环地址监听，除非用户显式开启；
为所有 API 统一增加会话令牌校验；
对编制、复核角色分别增加接口权限；
复核、批准、导出等操作不能仅依靠前端按钮控制；
增加“开放局域网访问前的安全警告”。

3.4 Agent 迭代次数和输入大小缺少严格限制

AgentRunRequest.max_iterations 是普通整数，没有看到明确的最大值限制。Agent 请求模型

同时，目标文本和上下文数据也缺少明显的大小上限。

这可能带来：

过多 LLM 请求；
过度消耗 API 额度；
产生大量数据库记录；
长时间占用后台任务；
恶意或错误输入导致服务不可用。

另外，工具注册表中的 JSON Schema 当前主要用于展示给模型，实际执行时并没有统一进行 JSON Schema 校验。工具注册表

建议：

max_iterations 增加明确上限，例如 1–12；
限制 goal、context、mock_plan 和单次工具参数大小；
增加单任务超时、Token 预算和取消机制；
在工具真正执行前验证参数类型、范围和必填字段；
对会修改数据库的工具增加服务端权限和状态检查；
将异常工具调用与任务失败区分开，避免 Agent 无限重试。

3.5 “语义嵌入检索”目前实际上会降级为 FTS

app/memory/embed.py 中虽然探测了 BGE ONNX 模型，但代码明确写着 tokenizer 只是占位，当前不会真正进行向量推理，最终会返回 None 并回退到 FTS 检索。Embedding 实现

因此，当前版本的知识检索更准确地说是“关键词/全文检索优先，向量检索预留”，而不是已经完成的中文语义嵌入检索。

建议：

如果当前只打算支持 FTS，应在界面和 README 中明确标注；
如果要宣传 BGE 语义检索，则应补齐 tokenizer、模型推理和向量持久化；
增加中英文、同义词、会计术语和错误写法的 Top-K 命中率测试；
对 FTS 与 embedding 的实际效果进行对比评测。

3.6 全新用户按照 README 操作，可能无法直接启动完整界面

README 的快速开始中使用了：

cd Restructured

但当前仓库根目录本身就是项目代码，没有看到名为 Restructured 的子目录。

同时，后端只有在 web/dist 存在时才会挂载前端 SPA，而 README 的基础启动步骤没有明确要求先执行：

cd web
npm ci
npm run build

前端的 package.json 只提供 dev、build 和 preview，没有根目录统一启动脚本。前端配置

建议补充一条从干净环境开始的完整流程：

git clone ...
cd DiveMind

python -m venv .venv
安装后端依赖

cd web
npm ci
npm run build

回到项目根目录
设置 DIVEMIND_AI_MODE=mock
启动 divemind

另外，README 引用的设计文档文件名与实际 docs 目录中的文件名也存在差异，建议统一文件名并检查链接。

3.7 测试和发布证据仍然不够完整

当前主要看到 Python 后端测试。前端 package.json 没有测试和 lint 脚本，仓库页面也没有明显的 CI 配置或构建状态。

因此，目前还不能从公开仓库快速确认：

前端 TypeScript 构建是否稳定；
前端页面交互是否覆盖；
后端与前端是否能在干净环境下完整联调；
Agent 运行链路是否有真实的端到端报告；
README 中列出的 57 个测试是否全部通过。

建议增加：

GitHub/Forgejo CI；
后端测试、前端构建、类型检查和 lint；
测试通过数量和运行时间；
一份脱敏的端到端示例；
一份“Mock 模式无需 API Key 的评审路径”；
一份真实模型调用的成本、延迟和错误率统计。

3.8 SSE 事件总线更适合单机演示，不适合多进程部署

当前 SSE 使用进程内事件总线，队列容量为 200，队列满时会直接丢弃事件。事件总线

这在单机演示中可以接受，但存在以下限制：

浏览器断线后无法补发历史事件；
服务重启后无法恢复正在运行的 Agent；
多进程或多实例部署时事件不会共享；
重要事件不能只依赖 SSE，因为 SSE 本身不是持久化日志。

建议将 SSE 定位为实时展示层，真正的进度和审计事件从数据库读取；重连时根据最后一个事件序号补发，或者明确声明项目只支持单进程本地部署。

4. 建议的改进优先级

建议优先处理以下事项：

修复 local/hybrid 与实际 Gateway 行为不一致的问题，确保敏感数据不会未经控制发送到远端。
处理 API Key、完整 Prompt、模型响应和日志中的敏感数据。
对外部访问、角色权限、Agent 迭代次数和工具参数增加服务端限制。
修复 README 启动命令、设计文档链接和前端构建说明。
明确当前语义检索是 FTS 还是完整 embedding。
增加 CI、前端构建检查和脱敏端到端演示。
将 SSE 和后台任务的单进程限制写入部署说明。

对于比赛演示，建议提供一条无需 API Key 的完整路径：

导入测试账套 → 自动列映射 → 试算平衡 → 波动/调整规则建议 → 创建审核项 → 人工批准或驳回 → 查看审计事件 → 导出交付物。

真实模型能力则可以作为第二条演示路径，并使用脱敏样例数据。

5. 综合评价

DiveMind 的优点不是“接入了一个大模型”，而是尝试把 Agent 放进了一个具有真实业务约束的审计流程中。项目已经具备：

明确的审计业务对象；
领域化确定性工具；
ReAct Agent 循环；
人工审核队列；
审计事件留痕；
底稿和交付物导出；
Mock 模式与测试夹具；
一定的文件安全和流程门禁设计。

因此，它不是简单的 Prompt 包装项目，具备较清晰的 Agent 系统雏形。

但当前公开版本仍然存在较明显的“设计文档领先于实际实现”的情况，尤其是：

local/hybrid AI 模式没有真正实现；
数据出站边界没有在 Gateway 层落实；
API Key 和完整模型上下文的本地保护不足；
REST API 的会话令牌没有形成统一鉴权；
Agent 资源和工具参数限制不够；
embedding 目前实际上仍然回退到 FTS；
全新环境启动步骤不够可靠。

综合来看，这是一个业务方向明确、Agent 架构有价值、工程基础较好的审计智能化项目，但目前更适合定位为“可运行的本地化 Agent 原型/早期系统”，距离可信的生产级审计辅助工具还需要完成安全边界、可复现部署和效果评测的补强。

## 1. 项目理解 DiveMind 是一个面向审计业务的本地化 Agent 工作台，核心流程不是简单的问答，而是：账套或底稿导入 → 文件解析与列映射 → 试算平衡与规则检查 → 调整建议 → 人工审核队列 → 审计底稿、附注及交付物导出。项目采用 FastAPI + SQLAlchemy + SQLite 作为后端，React + TypeScript + Vite 作为前端，并通过 ReAct 循环组织 Agent 的思考、工具调用和结果观察。[项目 README](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/README.md) 当前代码中的 Agent 已扩展为 `coordinator`、`ledger_intake`、`adjustment_review`、`scope`、`count`、`workbook_layout`、`note_drafting`、`reviewer` 等多个角色，分别负责账套导入、调整审核、重要性水平、盘点、底稿版式、附注和复核等任务。[Agent 工厂](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/agents/factory.py) 项目的主要设计思想是：LLM 负责选择工具和解释结果，金额计算、余额校验、调整建议和数据落库由确定性工具完成；Agent 的建议需要进入人工审核队列，不直接完成最终签认。[Agent 基类](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/agents/base.py)、[项目契约](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/docs/CONTRACTS.md) 整体来看，DiveMind 更接近“审计业务流程 Agent 系统原型”，而不是普通的 AI 聊天页面或 Prompt 包装项目。 ## 2. 项目亮点 ### 2.1 业务场景具体，Agent 不停留在对话层项目围绕审计中真实存在的账套、试算平衡、调整分录、底稿、盘点和附注等对象建立了数据模型和流程，Agent 能够调用试算平衡、波动识别、调整建议、审核队列等领域工具。这比泛化的“让大模型分析 Excel”更接近真实业务系统，也更容易体现 Agent 的任务执行能力。 ### 2.2 确定性工具与 LLM 推理分工合理项目明确限制 LLM 不直接进行金额计算，而是通过工具完成计算与校验。工具注册表也为每个工具定义了名称、描述和参数结构。[工具注册表](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/tools/registry.py) 这种设计可以降低模型进行金额计算时的幻觉风险，并且方便后续替换模型。 ### 2.3 人工审核闭环设计比较完整 Agent 的建议不会直接成为最终审计结论，而是写入 `ReviewItem` 审核队列，再由人工批准或驳回。同时项目还记录 `AuditEvent`、Agent 迭代过程和 LLM 调用记录。这种“Agent 建议—人工审核—留痕”的模式适合审计场景，也符合高风险业务中人机协同的基本要求。 ### 2.4 底稿导入和导出考虑到了真实数据结构底稿导入支持 ZIP 文件、Excel 工作簿和 PDF 证据文件，并对 ZIP 路径穿越进行了防护。系统还会对工作簿进行版式识别、审定表解析和语义层合成。[底稿导入工具](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/tools/workpaper_pack_tools.py) 交付物导出前还存在一定的门禁检查，例如未完成的盘点事项、未审核的调整、未确认的底稿或附注内容可能阻止导出。[交付物接口](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/api/routes_deliverables.py) ### 2.5 Mock 模式和测试夹具对开发比较友好项目提供 Mock LLM Gateway 和测试夹具，可以在不调用真实模型的情况下测试 Agent 流程。README 声称当前有 57 个测试用例，仓库中也包含账套、Agent、审核、OCR、内存检索和底稿导入等多类测试文件。[测试目录](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/tests) 这说明项目作者已经考虑到 Agent 系统难以稳定测试的问题。 ## 3. 当前存在的问题 ### 3.1 重要：AI 模式的文档说明与实际代码不一致这是我认为当前最值得优先修复的问题。设置接口允许选择： - `openai` - `mock` - `local` - `hybrid` 前端也提供了“混合模式”等选项。但是当前 `get_gateway()` 的实际逻辑是：只有 `ai_mode == "mock"` 时使用 Mock Gateway，其他模式全部使用 OpenAI 兼容接口。[LLM 网关](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/agents/llm.py)、[设置接口](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/api/routes_settings.py) 也就是说，目前 `local` 和 `hybrid` 并没有真正对应的本地模型或白名单字段出站逻辑，而是仍然会进入 OpenAI 兼容远程接口。这与 README 中“本地模式不出机”“混合云仅发送白名单字段”等安全设计说明存在明显差距。[README 安全设计](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/README.md) 对于审计系统来说，这不仅是功能问题，也涉及财务数据是否会被发送到云端。建议： - 为 `local`、`hybrid` 实现明确的 Gateway； - 如果本地模型不可用，应该直接报错，而不是静默切换到远程模型； - 在发送 LLM 前增加字段分级和脱敏策略； - 增加测试，确保 `local` 模式不会发起远程 HTTP 请求； - 在界面明确显示本次调用是否出站、发送了哪些字段。 ### 3.2 重要：完整 Prompt 和模型响应会直接落库 `BaseAgent` 会将完整的 `messages` 写入 `LLMCall.prompt_text`，同时保存完整的 `response_text`。[Agent 基类](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/agents/base.py)、[数据模型](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/models.py) 审计 Prompt 可能包含： - 企业名称； - 科目余额； - 财务金额； - 凭证摘要； - 底稿内容； - 盘点信息； - 人员或客户资料。如果这些内容全部以明文存入 SQLite，那么即使模型调用本身受控，本地数据库和备份文件仍可能暴露敏感信息。另外，项目的 API Key 存储在本机 JSON 设置文件中，当前代码没有看到操作系统级密钥保护。[本地设置存储](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/core/local_store.py) 建议： - 默认只保存 Prompt 哈希、模型、Token 数量、延迟和摘要； - 完整 Prompt/Response 改为用户主动开启的调试选项； - 对企业名称、账号、金额和人员信息进行脱敏； - 为 LLM 记录设置保留期限和删除机制； - Windows 环境优先使用 DPAPI 或系统凭据存储保护 API Key； - 日志中也应统一增加敏感字段脱敏。 ### 3.3 重要：会话令牌目前没有形成真正的 API 鉴权项目会生成 `session_token`，README 也提到本机会话令牌和角色切换。但当前路由依赖主要是数据库和配置依赖，没有看到所有业务接口统一校验该令牌的中间件或鉴权依赖。项目默认监听 `127.0.0.1`，因此在默认本地运行场景下风险有限。但如果用户把服务绑定到 `0.0.0.0`、局域网地址或反向代理之后，其他请求方可能直接访问项目、设置、导入和 Agent 接口。建议： - 默认拒绝非回环地址监听，除非用户显式开启； - 为所有 API 统一增加会话令牌校验； - 对编制、复核角色分别增加接口权限； - 复核、批准、导出等操作不能仅依靠前端按钮控制； - 增加“开放局域网访问前的安全警告”。 ### 3.4 Agent 迭代次数和输入大小缺少严格限制 `AgentRunRequest.max_iterations` 是普通整数，没有看到明确的最大值限制。[Agent 请求模型](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/schemas.py) 同时，目标文本和上下文数据也缺少明显的大小上限。这可能带来： - 过多 LLM 请求； - 过度消耗 API 额度； - 产生大量数据库记录； - 长时间占用后台任务； - 恶意或错误输入导致服务不可用。另外，工具注册表中的 JSON Schema 当前主要用于展示给模型，实际执行时并没有统一进行 JSON Schema 校验。[工具注册表](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/tools/registry.py) 建议： - `max_iterations` 增加明确上限，例如 1–12； - 限制 goal、context、mock_plan 和单次工具参数大小； - 增加单任务超时、Token 预算和取消机制； - 在工具真正执行前验证参数类型、范围和必填字段； - 对会修改数据库的工具增加服务端权限和状态检查； - 将异常工具调用与任务失败区分开，避免 Agent 无限重试。 ### 3.5 “语义嵌入检索”目前实际上会降级为 FTS `app/memory/embed.py` 中虽然探测了 BGE ONNX 模型，但代码明确写着 tokenizer 只是占位，当前不会真正进行向量推理，最终会返回 `None` 并回退到 FTS 检索。[Embedding 实现](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/memory/embed.py) 因此，当前版本的知识检索更准确地说是“关键词/全文检索优先，向量检索预留”，而不是已经完成的中文语义嵌入检索。建议： - 如果当前只打算支持 FTS，应在界面和 README 中明确标注； - 如果要宣传 BGE 语义检索，则应补齐 tokenizer、模型推理和向量持久化； - 增加中英文、同义词、会计术语和错误写法的 Top-K 命中率测试； - 对 FTS 与 embedding 的实际效果进行对比评测。 ### 3.6 全新用户按照 README 操作，可能无法直接启动完整界面 README 的快速开始中使用了： ```text cd Restructured ``` 但当前仓库根目录本身就是项目代码，没有看到名为 `Restructured` 的子目录。同时，后端只有在 `web/dist` 存在时才会挂载前端 SPA，而 README 的基础启动步骤没有明确要求先执行： ```text cd web npm ci npm run build ``` 前端的 `package.json` 只提供 `dev`、`build` 和 `preview`，没有根目录统一启动脚本。[前端配置](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/web/package.json) 建议补充一条从干净环境开始的完整流程： ```text git clone ... cd DiveMind python -m venv .venv 安装后端依赖 cd web npm ci npm run build 回到项目根目录设置 DIVEMIND_AI_MODE=mock 启动 divemind ``` 另外，README 引用的设计文档文件名与实际 `docs` 目录中的文件名也存在差异，建议统一文件名并检查链接。 ### 3.7 测试和发布证据仍然不够完整当前主要看到 Python 后端测试。前端 `package.json` 没有测试和 lint 脚本，仓库页面也没有明显的 CI 配置或构建状态。因此，目前还不能从公开仓库快速确认： - 前端 TypeScript 构建是否稳定； - 前端页面交互是否覆盖； - 后端与前端是否能在干净环境下完整联调； - Agent 运行链路是否有真实的端到端报告； - README 中列出的 57 个测试是否全部通过。建议增加： - GitHub/Forgejo CI； - 后端测试、前端构建、类型检查和 lint； - 测试通过数量和运行时间； - 一份脱敏的端到端示例； - 一份“Mock 模式无需 API Key 的评审路径”； - 一份真实模型调用的成本、延迟和错误率统计。 ### 3.8 SSE 事件总线更适合单机演示，不适合多进程部署当前 SSE 使用进程内事件总线，队列容量为 200，队列满时会直接丢弃事件。[事件总线](https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/src/branch/master/app/events.py) 这在单机演示中可以接受，但存在以下限制： - 浏览器断线后无法补发历史事件； - 服务重启后无法恢复正在运行的 Agent； - 多进程或多实例部署时事件不会共享； - 重要事件不能只依赖 SSE，因为 SSE 本身不是持久化日志。建议将 SSE 定位为实时展示层，真正的进度和审计事件从数据库读取；重连时根据最后一个事件序号补发，或者明确声明项目只支持单进程本地部署。 ## 4. 建议的改进优先级建议优先处理以下事项： 1. 修复 `local/hybrid` 与实际 Gateway 行为不一致的问题，确保敏感数据不会未经控制发送到远端。 2. 处理 API Key、完整 Prompt、模型响应和日志中的敏感数据。 3. 对外部访问、角色权限、Agent 迭代次数和工具参数增加服务端限制。 4. 修复 README 启动命令、设计文档链接和前端构建说明。 5. 明确当前语义检索是 FTS 还是完整 embedding。 6. 增加 CI、前端构建检查和脱敏端到端演示。 7. 将 SSE 和后台任务的单进程限制写入部署说明。对于比赛演示，建议提供一条无需 API Key 的完整路径：导入测试账套 → 自动列映射 → 试算平衡 → 波动/调整规则建议 → 创建审核项 → 人工批准或驳回 → 查看审计事件 → 导出交付物。真实模型能力则可以作为第二条演示路径，并使用脱敏样例数据。 ## 5. 综合评价 DiveMind 的优点不是“接入了一个大模型”，而是尝试把 Agent 放进了一个具有真实业务约束的审计流程中。项目已经具备： - 明确的审计业务对象； - 领域化确定性工具； - ReAct Agent 循环； - 人工审核队列； - 审计事件留痕； - 底稿和交付物导出； - Mock 模式与测试夹具； - 一定的文件安全和流程门禁设计。因此，它不是简单的 Prompt 包装项目，具备较清晰的 Agent 系统雏形。但当前公开版本仍然存在较明显的“设计文档领先于实际实现”的情况，尤其是： - `local/hybrid` AI 模式没有真正实现； - 数据出站边界没有在 Gateway 层落实； - API Key 和完整模型上下文的本地保护不足； - REST API 的会话令牌没有形成统一鉴权； - Agent 资源和工具参数限制不够； - embedding 目前实际上仍然回退到 FTS； - 全新环境启动步骤不够可靠。综合来看，这是一个业务方向明确、Agent 架构有价值、工程基础较好的审计智能化项目，但目前更适合定位为“可运行的本地化 Agent 原型/早期系统”，距离可信的生产级审计辅助工具还需要完成安全边界、可复现部署和效果评测的补强。

LIGHTNINGWHALE commented

2026-08-06 11:50:43 +08:00

Owner

朋友，这个是 https://www.divesee.com/divemind/ 潜析 DiveMind 项目并不是 https://www.divesee.com/diveread/ Diveread潜读项目

chozzc changed title from ~~【S3W3 交叉评测】潜析 DiveMind 的阅读忠实性、效果证据与内容安全建议~~ to 【S3W3 交叉评测】潜审 DiveMind：审计 Agent 的工程一致性、安全边界与可验证性建议

2026-08-07 00:22:42 +08:00

chozzc commented

2026-08-07 00:23:51 +08:00

Author

@LIGHTNINGWHALE wrote in #2 (comment):

朋友，这个是 https://www.divesee.com/divemind/ 潜析 DiveMind 项目并不是 https://www.divesee.com/diveread/ Diveread潜读项目
感谢指正。前一版评审确实错误地混淆了 DiveMind「潜审」与 DiveRead「潜读」，这是我的失误。
现已重新基于本次比赛官方仓库中修改为针对潜审 DiveMind 审计 Agent 系统的评审。

@LIGHTNINGWHALE wrote in https://www.synnovator.com/LIGHTNINGWHALE/DiveMind/issues/2#issuecomment-442: > 朋友，这个是 https://www.divesee.com/divemind/ 潜析 DiveMind 项目并不是 https://www.divesee.com/diveread/ Diveread潜读项目感谢指正。前一版评审确实错误地混淆了 DiveMind「潜审」与 DiveRead「潜读」，这是我的失误。现已重新基于本次比赛官方仓库中修改为针对潜审 DiveMind 审计 Agent 系统的评审。

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#2

No description provided.

Rows
Columns