核心用法
GridTRX 是一个专为 AI 代理设计的完整周期双式记账引擎，将银行 CSV、OFX、QBO 文件转换为平衡的、可审计的账簿。所有数据存储于单一本地 SQLite 文件，无需外部 API 或云服务。
三种交互接口
1. MCP Server（推荐）：19 个结构化 JSON 工具，类型安全、确定性输出
2. CLI：零依赖 Shell 命令，适合终端代理
3. 浏览器 UI：Flask 网页界面，支持 13 列对比报表、规则预览、暗色模式
标准工作流
1. 初始化：new 命令创建含 60+ 科目、5 份标准报表、永续留存收益链的账套
2. 导入银行数据：自动应用规则分类，未识别交易进入 EX.SUSP 待处理队列
3. 清理暂记科目：与用户确认每笔模糊交易，添加规则后重新导入
4. 验证与报告：试算平衡、资产负债表、损益表一键生成
5. 年末结转：rollforward 自动完成留存收益结转、锁期、财年推进
关键约束
- 绝不猜测分类："AMAZON" 可能是办公用品、存货或个人消费
- 尊重锁定期：无法修改已锁定期间的交易
- 工作区隔离：
GRIDTRX_WORKSPACE强制沙箱，外部路径被拒绝
---
显著优点
| 维度 | 表现 |
|------|------|
| **隐私安全** | 纯本地运行，零网络外联，数据不出设备 |
| **审计能力** | 试算平衡强制校验，每笔交易零和平衡，支持追踪至原始银行文件 |
| **AI 原生** | MCP 协议专为代理设计，结构化工具消除文本解析不确定性 |
| **零依赖** | CLI 仅需 Python 3.7+，嵌入式场景友好 |
| **完整周期** | 从日常记账到年末结转、报表生成、数据归档全覆盖 |
---
潜在局限
1. 规则学习成本：初始需人工定义大量分类规则，自动化程度依赖历史数据积累
2. 无实时银行连接：不支持 Plaid/Yodlee 等开放银行 API，需手动导出文件
3. 单用户架构：SQLite 文件锁机制不适合高并发团队场景
4. 无多币种支持：文档未提及外汇处理，假设单一本位币
5. 恢复机制简陋：无批量撤销，误操作需逐笔删除后重新导入
---
适合人群
- 自由职业者/微型企业：追求隐私、拒绝 SaaS 订阅的独立工作者
- 会计师/簿记代理：需要批量处理多个客户账套的自动化工作流
- AI 工作流构建者：通过 MCP 将财务能力集成至更大型代理系统
- 合规敏感行业：法律、医疗等数据本地化要求严格的领域
---
常规风险
- 数据完整性：直接修改
books.db文件将破坏校验链，必须通过 CLI/MCP 操作 - 规则冲突：优先级设置不当可能导致交易误分类，建议定期审计
EX.SUSP - 财年边界：超出
fy_end_date的交易被静默跳过，易造成数据遗漏 - 备份依赖：单文件架构虽便于备份，但缺乏内置版本控制，需外部 Git/快照方案