管线-Agent-数据库：知产代理系统的三层架构
五条规律，一套框架：管线负责"发现"，Agent负责"判断"，数据库负责"关联"。技术替代工作，留下责任和创造力给人。
为什么要分层
知产代理系统跑了一段时间后，你会发现一个现象：有些代码天天改，有些代码半年不动，有些数据每天都在涨。
如果把它们混在一起——绝限计算逻辑和核销匹配逻辑写在同一段代码里——改一动全身，测一遍全链路。这是所有系统维护噩梦的根源。
分层不是技术炫技，是按变化频率把代码隔离开。
📐 打开交互式架构图 →（暗/亮主题切换，可导出）
规律一：管线负责"发现"，Agent 负责"判断"，数据库负责"关联"
感知-决策-记忆 三层架构
这是认知科学里"感知→决策→记忆"三层模型在业务系统中的工程化映射。
| 层 | 类比 | 做什么 |
|---|---|---|
| 管线 | 「眼睛」感知 | 扫描收件箱、定时导入、绝限预警 |
| Agent | 「大脑」判断 | OCR判向、核销匹配、异常升级 |
| 数据库 | 「海马体」记忆 | 记录每张发票、每条流水、每个案件 |
规律二：数据库是 Agent 之间的共享语言
12个 Agent，一张日志表
专利 Agent 做完 OA 答复，财务 Agent 需要知道该案件是不是已经收费了——它们不能直接对话，它们通过数据库对话。
这就是 agent_audit_log 统一日志表的价值：每个 Agent 写入自己的操作记录，其他 Agent 查询这段共享记忆。不需要 API 调用，不需要消息队列，数据库本身就是通信协议。
规律三：管线的价值取决于数据库的完整度
管线跑不动，通常是数据库没喂饱
管线扫描收件箱 → 找到发票 → 提取客户名 → 查 CNPTES → 找不到案件 → 管线失效。
这不是管线的错。是数据库里客户档案不全、合同-案件关联缺失。管线的上限，是数据库的完整度。
规律四：按"稳定性"划分边界
三层三频
| 层 | 稳定性 | 变化频率 | 适合放什么 |
|---|---|---|---|
| 管线 | 高 | 低频（规则固定后很少改） | 文件分类、定时导入、绝限提醒 |
| Agent | 中 | 中频（随业务学习调整） | OCR判向、核销匹配、异常处理 |
| 数据库 | 低 | 高频（每天增长） | 发票/流水/分录/案件 |
核心原则：管线写死规则（dzfp_ → 发票类），Agent 做规则之外的判断（销售方税号判向），数据库记录一切。用管线管"确定的事"，用 Agent 管"不确定的事"，用数据库让两者有共同的"记忆"。
规律五：技术替代工作，留下责任和创造力
"技术替代工作"的工程化
- 管线替代"发现"——不用人盯着收件箱看有没有新发票
- Agent 替代"核对"——不用人逐张发票看销售方税号判归属
- 数据库替代"记忆"——不用人翻文件夹找"上次给智荟元真开票多少钱"
- 留给人的是"责任"——到款没找到，标记待跟进，你决定催款还是查银行
- 留给人的是"创造力"——从数据中发现"门头沟管委会客户在增长"这种业务洞察
一张图看清全部
我们把这个架构做成了交互式图表——三层清晰分层，暗/亮主题切换，每个节点对应实际系统组件：
落地清单
| 优先级 | 动作 | 效果 |
|---|---|---|
| 🔴 | 补 failed_queue 异常队列 | 入库失败不再停，自动重试 |
| 🔴 | 建 agent_audit_log 表 | 12个Agent有共同日志 |
| 🔴 | 客户档案补全 | 管线匹配不再落空 |
| 🟡 | 绝限计算沉到管线 | 不用人盯通知书截止日 |
| 🟡 | 合规扫描定时Cron | 合伙人/年检自动预警 |