AI 银行账单自动化
从 PDF 提取、脱敏并分析银行账单，支持问答与多种智能体框架。
按维度查看评分与理由
README说明了PDF提取、PII脱敏、向量存储、RAG、可选云端LLM、MLflow追踪和多个持久化服务，数据流具有一定透明度；测试也逐项检查电子邮件、电话和账户号的遮蔽，因此敏感数据处理有具体支持。扣分原因是未见权限最小化策略、操作前确认机制、保留期限、访问控制细节、外部提供商数据政策、回滚或恢复流程。PII测试仅覆盖少数正则模式，README还承认姓名和地址保护有待加强。依赖部分虽大量固定版本，却仍包含未固定及重复声明，且没有漏洞扫描、校验或更新策略证据。来源只通过仓库名称、技术链接和一句地域说明有限呈现，发布者身份及明确责任主体仍未知。
README、目录说明、依赖清单和测试在Deep Agents的PDF提取、PII脱敏、向量存储及查询流程上基本一致，并提供了无LLM路径。扣分原因是完整运行时代码、API测试和故障处理实现未提供，无法核对大量全栈与多框架声明；README同时把生产后端、Docker和Kubernetes写为现有能力与路线图事项，边界略显不一致。依赖清单混合精确固定、范围约束和无版本约束，并重复声明instructor，降低环境可解析性。可见失败信息主要是测试断言和文档中的排障提示，缺少面向最终用户的结构化错误、重试和降级证据。
材料明确覆盖个人财务、离线确定性流水线、本地LLM、云端模型、Notebook、API、前端及Docker沙箱等受众和场景，也说明模型大小、上下文、JSON输出、GPU和三个执行框架的差异。扣分原因是多框架被明确标为实验性且技能副本不会自动同步；本地模型质量和严格JSON存在已知约束。技能测试只验证五个技能文件具有名称和描述，并未提供实际描述或调度代码，因此无法充分评价触发条件、重叠消解和误触发控制。环境说明较丰富，但硬件与服务要求重，Windows仅有虚拟环境提示，跨平台适配证据不完整。
README拥有清晰的功能、技术栈、项目树、快速开始、配置、开发注意事项、路线图和许可证结构，信息架构完整。安装与示例覆盖CrewAI、Deep Agents和全栈Docker路径，并给出排障入口；但关键指南和源文件未随材料提供，无法静态确认步骤完整性。命名总体稳定，但CrewAI、Deep Agents、Hermes及多份技能副本增加漂移风险。已明确列出小模型、上下文、JSON、PII和实验性限制。仓库包含完整Apache-2.0文本，故许可证满分。未见发行版本、变更日志或迁移记录；维护责任仅能从仓库所有者名称和笼统升级建议推知，没有明确维护者、支持渠道或更新承诺。
项目定义了可直接使用的Markdown报告、结构化提取、RAG回答、API和前端等输出，并提供一条无需LLM的最短路径；结合布局检测、OCR、脱敏、检索与财务分析，相比手工处理具有合理的增量价值。扣分原因是未提供实际输出样例、质量指标或完整实现证据，且本地模型可能无法稳定生成严格JSON。部署需要Python、OCR/ML依赖、多个数据库和队列服务，完整配置还可能需要Docker、较新NVIDIA驱动及高参数量模型；README只给出笼统GPU构建时间说法，没有资源基准或成本比较，因此成本效益仅得到有限支持。
测试文件能够追溯部分具体主张，包括技能元数据存在、PDF可提取、常见PII可遮蔽以及向量存储查询往返；这些内容也与README和依赖清单相互印证。扣分原因是大部分全栈、安全、性能和多框架主张仅见于README，没有相应实现文件、测试结果、CI记录、基准或样例输出。测试会在示例PDF缺失时生成合成PDF，因此不能证明随仓库提供的真实样本表现。宣传性描述、当前能力和路线图之间没有始终清楚地区分，例如生产后端和Docker既被描述为现有功能又出现在路线图中。
- 银行流水包含高敏感财务与身份数据；在使用真实文件前，应核实所有LLM、追踪、向量库和日志路径，并确认数据不会被发送到未经批准的外部服务。
- 现有PII证据只覆盖电子邮件、电话和账户号模式；姓名、地址、交易备注及其他可识别组合可能仍会进入嵌入、日志或追踪系统。
- 完整部署会产生数据库、向量索引、上传文件和追踪记录，但材料未给出删除、回滚、备份恢复或保留期限流程。
- 依赖清单仍有无版本约束、范围约束和重复项；处理真实金融数据前应锁定依赖、执行漏洞扫描并审查容器镜像。
- 不要把财务分析输出视为准确的会计、信贷或投资建议；所给材料没有展示输出准确性或风险控制验证。
这个 Agent 能做什么，适合哪些场景？
这是一个面向银行账单的文档处理与个人财务分析项目。它以 PyMuPDF、YOLO、OCR 和 LLM 提取 PDF 内容及表格，并在写入 Qdrant 或 Chroma 前执行 PII 脱敏。项目同时提供 CrewAI、LangChain Deep Agents 和运行于 Docker 沙箱的 Hermes 三套实验性执行框架，也包含无需 LLM 的 Deep Agents 确定性流水线。完整应用由 FastAPI、PostgreSQL、Celery、Redis 和 React SPA 组成，通过 REST 认证、异步文档处理和智能体运行接口提供服务。模型调用由 LiteLLM 统一处理，可连接 LM Studio、Ollama、OpenAI、DeepSeek 等本地或云端提供方；CrewAI 路径还能通过 MLflow 跟踪调用与任务。它适合愿意自行部署和验证财务文档处理流程的技术团队，而不是即开即用的托管财务产品。
系统读取银行账单 PDF，使用 PyMuPDF、YOLO 布局检测和 OCR 获取文档内容，再借助 LLM 进行表格提取和结构化。领域技能覆盖 bank-statement-parsing、pii-handling、financial-analysis、rag-query-handling 和 output-format；PII 在向 Qdrant 或 Chroma 写入嵌入之前被脱敏。处理后的数据可用于收支分类、趋势分析和自然语言查询。CrewAI 通过 Jupyter notebook 运行；Deep Agents 可由 run_e2e.py 执行确定性 pipeline；Hermes 使用 CLI 并仅在 Docker 沙箱中运行。完整部署通过 FastAPI 暴露认证、LLM、文档和 agent_runs REST 端点，并由 Celery worker 异步执行任务、React SPA 提供界面。
- 个人财务工具开发者需要把银行账单 PDF 转成可查询、可分类的结构化数据。
- 处理敏感财务文档的团队希望在生成向量嵌入之前先删除 PII。
- 智能体工程师需要用同一银行账单流程比较 CrewAI、Deep Agents 与 Hermes 三种执行框架。
- 偏好本地推理的组织希望通过 LM Studio 或 Ollama 分析账单，减少对单一云模型提供商的依赖。
- 后端团队需要以 FastAPI、Celery、PostgreSQL 和 Qdrant 构建异步文档处理服务。
- 研究人员需要在 Jupyter 中实验 CrewAI，并用 MLflow 跟踪 LLM 调用和任务执行。
这个 Agent 有哪些优点和局限？
- 覆盖从 YOLO/OCR 提取、LLM 结构化、PII 脱敏到向量检索和财务分析的完整账单处理链路。
- 同一业务流程提供 CrewAI、Deep Agents 和 Hermes 三种框架，并保留无需 LLM 的确定性测试与 E2E 路径。
- LiteLLM 同时支持 LM Studio、Ollama 和多种云端提供方，且专门处理 reasoning_content 返回形式。
- 提供 FastAPI、Celery、PostgreSQL、Qdrant、React 以及 Docker Compose/Kubernetes 基础设施，而非只有实验 notebook。
- PII 在写入向量数据库前脱敏，安全边界比先嵌入再清理更明确。
- 三套执行框架被标注为实验性，并各自保存技能副本且不会自动同步，维护时容易出现行为漂移。
- 本地模型建议至少 9B、16K 上下文且最好 32K；较小模型会降低质量，算力和内存成本不可忽略。
- 本地模型经常无法稳定输出严格 JSON，需要第二次调用、instructor 或其他后处理。
- 完整部署涉及 PostgreSQL、Redis、Qdrant、Celery、前后端和密钥配置，运维成本明显高于单一脚本。
- 更强的姓名和地址 PII 处理、Deep Agents 的生产级嵌入及技能同步工具仍列在路线图中。
- GPU 部署依赖 NVIDIA 容器工具链和兼容驱动；Hermes 路径还限定使用 Docker 沙箱。
如何安装或部署这个 Agent？
基础 CrewAI 环境：
git clone https://github.com/johnsonhk88/AI-Bank-Statement-Document-Automation-By-LLM-And-Personal-Finanical-Analysis-Prediction.git
cd AI-Bank-Statement-Document-Automation-By-LLM-And-Personal-Finanical-Analysis-Prediction
python -m venv venv
source venv/bin/activate
pip install -r requirements.txt随后在 LM Studio 中加载建议为 9B 以上、上下文至少 16K 的模型，并在 http://localhost:1234 启动本地服务。示例 LiteLLM 配置使用 base_url="http://localhost:1234/v1"、api_key="lm-studio"。
完整应用需要 Docker 24+、BuildKit 和 Docker Compose v2+。执行：
cp infra/.env.example infra/.env
python -c "import secrets; print(secrets.token_urlsafe(32))"
python -c "import bcrypt; print(bcrypt.hashpw(b'your-password', bcrypt.gensalt()).decode())"把结果分别写入 infra/.env 的 JWT_SECRET 和 ADMIN_PASSWORD_HASH；bcrypt 哈希中的 $ 必须写成 $$。然后运行：
cd infra && DOCKER_BUILDKIT=1 docker compose --profile prod up -d --buildGPU 为可选项，但容器内 GPU 推理还需要 NVIDIA Container Toolkit 和兼容驱动。
如何使用这个 Agent？
CrewAI 路径的首次运行：
jupyter notebook backend/app/core/ai_agent_skills_dev.ipynb无需 LLM 的可验证路径：
cd agents/deep-agents
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
PYTHONPATH=. pytest tests/ -v
PYTHONPATH=. python run_e2e.py --pdf ../../data/bank-statement-document/Dummy-Bank-Statement.pdf --question "What amounts appear in the statement?" --mode pipeline完整生产配置启动后，在浏览器打开 http://localhost。开发模式可先在 infra 目录运行 docker compose up -d，再进入 web 执行 npm install && npm run dev，并通过 http://localhost:5173 使用前端。若直接调用 LiteLLM，可使用 acompletion，并提供 model、base_url、api_key 与 messages；云模型所需凭据取决于所选提供方。
这个 Agent 与同类方案有什么区别？
CrewAI 是 notebook 驱动的基线方案，并支持 MLflow 跟踪；Deep Agents 提供本地虚拟环境、测试、run_e2e.py 以及无需 LLM 的确定性 pipeline；Hermes 通过 CLI 运行并强制使用 Docker 沙箱。三者处理相同的银行账单场景，但技能副本彼此独立，不会自动同步。模型侧，LM Studio 和 Ollama 提供本地推理路径，LiteLLM 也可连接 OpenAI、DeepSeek 等云端服务；本地路径更利于自托管，但对模型大小、上下文长度和 JSON 稳定性有明确限制。