研究报告架构师知识图谱

架构师知识图谱：从支付系统到 AI Agent 平台

这篇是对个人 GitHub 仓库、简历和工作材料的一次知识补全：把十多年的项目经验整理成可以继续扩展的知识图谱入口。它不是完整简历，而是把经验抽象成几个长期可复用的工程主题——什么问题、什么约束、什么取舍、如何验证。

更细的拆分见：AI Agent 项目群、支付账务与订单架构、SaaS 与云原生平台架构、从超级个体到超级团队。

核心画像

我的知识结构可以分成两条主线，而它们在近两年正在交汇。

第一条是交易型系统，是十多年的底盘：金融前置、收单发卡、清结算、对账差错、资产池、钱包、订单账务、支付域抽象、跨境清算、电商订单与支付改造。这条线让我长期关注数据一致性、资金链路、幂等、对账、分布式故障、性能容量和生产稳定性。

第二条是 AI 应用工程，是近两年长出的第二曲线：Agent Runtime、Workflow、RAG、MCP、Model Gateway、Evals、AI 原生研发流程。这条线的重点不是提示词技巧，而是把生成式 AI 落到可观测、可回放、可评估、可协作的工程体系。

两条线看似跨度很大，但真正衔接它们的是同一批架构判断：怎么划领域边界、怎么让易变的部分和稳定的部分分层、怎么让一个系统的产出可以被另一个系统信任。这些判断单列在下面的方法论主线。

能力时间线

一条大致的演进线索，四个锚点，每一段都在为下一段做铺垫：

  1. 2012 起 · 金融与支付底座：C / Linux 时代的收单发卡、清结算与对账差错处理。做过银行前置与中间业务系统（一套引擎 + 报文模板 + 路由配置表适配多家银行前置通道）、收单系统的清算与自主差错处理模块，以及作为项目经理主导的南京道路停车收费系统千万级项目成功上线。这一段沉淀了「报文解析 → 交易流程编排 → 路由 → 风控校验 → 差错处理」的收单五段分层，和「批次 + 对账结果 + 异常队列」的对账三件套。
  2. 2016 起 · 平台化与高并发：在途牛参与金融基础系统从 0 到 1 建设（清结算、资产池、账户钱包、理财交易前台，2015 年理财 72 小时募集破 6 亿元），建设支付运营的实时监控与数据支撑（100+ 支付渠道实时监控，大促链路承压约 10K+ QPS，支付费率由 0.5% 降到 0.2%），并在跨境支付方向完成美国线上收款与清算。之后在千米做电商交易中台，把订单、支付、账务的边界重新梳理清楚；在一家水果批发电商平台把订单系统吞吐从百 TPS 提升到千 TPS、P99 < 150ms，且支付接口零变更完成升级。
  3. 2023 起 · 海外 FinTech 与云原生：在 Bite Investments 任技术总监，做投资人档案服务的 DDD 子域梳理、资源树加主体树的权限模型、微服务云原生演进与本地开发工作流治理，推行 trunk-based development。
  4. 2025 起 · AI Native：在 CosX AI 任技术合伙人、带一支约 10 人的研发团队，做通用 Agent 平台、法律 AI Workflow（单租户 200+ 文件同时 AI 分析、准确率 90%+、AI 填表 P99 5 秒/页面）与金融合规方向；并把这套工程判断进一步用到 AI 原生研发流程治理上，让 AI 编码的产出可被门禁信任。

交易系统与资金链路

从收单对账一路做到海外基金 FinTech，反复在回答同一个问题：信息流与资金流如何分层，账务与支付、订单如何解耦。几个稳定判断：

  • 支付单更接近信息流，收款单同时承载信息流和资金流；订单即应收、支付即实收，是订单域和账务域协作时最重要的边界。
  • 涉及资金的交易，无论是否真的发生资金流，信息流都应当完备。
  • 支付不做产品化（收银台），订单系统就会被迫吞进大量支付逻辑；账务缺「多次支付 / 退款」能力，业务系统就会臃肿。要把支付方式、结算方式、支付渠道、支付网关这几个混用的概念拆清楚，把散落的支付方式判断收敛进枚举语义（例如线下转账、现金、货到付款、线下收银、在线支付、POS、汇款、记账这几类），而不是散在一堆 ||/&& 里。
  • 清结算普遍采用应收应付分离核算；多渠道资金对账的通用模式是 D+1 文件与系统流水比对，按「平、多、少」三态处理——平帐结束，多帐走线下财务加技术核实，少帐靠明细主动查询接口补录。多家清算机构的文件格式各异，先统一抽象成「资金文件」模型，再做渠道适配。
  • 资产池在助贷场景表现为多资方资金与自有资金联合出资 / 放款，清结算引擎要区分有担保资方、渠道方、自营三种资金合作模式，应收应付分开核算。
  • 大促链路、支付渠道切换、跨境清算和差错处理，都要求系统具备实时监控、幂等保护和回滚策略。资金一致性靠幂等、分布式 ID、分布式锁保障：没有明确理由不要自定义锁的续期时间（否则看门狗续期会失效），锁 key 要按应用加前缀，解锁前校验持有线程。

这些经验对应到今天的架构判断，就是把核心交易链路看成一组有明确事实来源的状态机，而不是把所有变化塞进过程式服务方法里。更完整的展开见 支付账务与订单架构。

Java 微服务与领域建模

从途牛、千米到 Bite，材料反复指向同一个问题：微服务不是把代码拆成更多仓库，而是把业务边界、数据边界和交付边界梳理清楚。

  • 中台与业务拆分：中台订单与业务订单分层，更利于行业版应用的开发和部署；中台应遵循开闭原则、面向对象（SOLID）去组织，而不是纯按业务功能横向拆分——收益是稳定性、扩展性和更小的回归面。反对「无返回值构造方法」这类隐藏副作用的设计，反对 Context 对象滥用。
  • 状态机 / CQRS / 事件驱动：用状态机统一订单等流程，让前端发起、后台操作、定时任务复用同一套状态机；命令查询职责分离可以随并发压力逐级演进（从进程内命令总线，到基于 Disruptor 的高吞吐命令总线，再到分布式命令总线加分布式锁）。幂等分两路：普通场景用分布式锁，事件驱动场景用命令总线；缓存遵循「写失效、读更新」。没有银弹，但细分场景一定有最佳实践。
  • DDD 的一手教训（源自一次促销服务从传统 MVC 分层渐进重构到 DDD 四层的亲历，没有推倒重写）：持久化框架不决定「是不是 DDD」，仓储放在哪、按什么粒度存取才决定；把 Mapper 直接当仓储、用生成器 POJO 覆盖领域类，模型当天就会退化成贫血模型加事务脚本。用只追加的事件日志代替聚合状态去守不变量，一遇到「撤销」就会出错——归属人和状态必须收回到聚合上。没有测试守护的模型，在交付压力下最先被丢掉；规则引擎要等真有「业务方配置规则」的需求才引入。
  • 投资人档案的领域梳理：一个横跨多个库、实体关系错综成「蜘蛛网状」的服务，复杂度根因在于历史模型把「人 / 机构」「档案资料」「认购档案」混在一套 ER 里迭代。处理办法是先用 DDD 子域做认知分层（人与机构、文档、档案三块），再决定是否合并 / 泛化表结构——后来把几张分散的文档表泛化成了统一的文档实体。
  • 工程栈的历史取舍：Spring Boot、Spring Cloud、Dubbo、MQ、JPA、MyBatis 在不同阶段各有权衡。JPA 用继承映射多态，MyBatis 常退回类型码——选框架其实连带决定了多态放在哪一层。

这部分经验的支付和订单方向已整理到 支付账务与订单架构。

遗留系统与绞杀式重构

一个跨越多家公司复用的判断：不做 Big Bang 重写。这来自我 2018 年的一次技术分享《支付平台的微服务化思考与实践》：

  • 先「hold 住新需求」（已经掉坑里就别再挖了），再做前后端分离，最后逐步抽出服务；哪一步先做是随场景权衡的开放问题，不是固定顺序。
  • 微服务的本质是围绕业务组织团队、关注产品而非项目（you build it, you run it）、强服务个体加弱通信（REST/RPC 加消息总线）、去中心化治理与注册发现、业务数据独立（服务间不以共享数据方式集成），而基础设施自动化（DevOps / CI/CD）是前提。
  • 遗留系统下线最难的地方往往是数据库耦合：老逻辑还在产生数据，对外接口甚至直接接受 SQL。

同一思路一路延续：电商订单中台的渐进重构、海外遗留财务系统的适配下线、老系统向新平台的分阶段迁移，都是「用新平台把老系统一点点绞杀掉」而不是一次性替换。

AI Agent 与可执行工作流

近两年的 GitHub 仓库显示出明显的 AI Native 工程方向：

  • sure：Cloudflare Worker 上的中文保险顾问写作 Agent，涉及 D1、R2、Queues、Durable Objects、Workflows、Sandbox 和 Agent SDK runner。
  • sac-agent：教学向 Python 软件工程 Agent，强调仓库检查、命令风险分类、审批边界和 patch 应用。
  • sac-agent4j：手写 Java SWE Agent，用一个极小核心循环理解上下文构建、工具执行、测试反馈和轨迹记录。
  • agent-lab：Coding Agent 与可观测性平台的实验环境，用来做技能评估、对照实验和回放验证。
  • ddia-skill：把 DDIA 风格的数据密集型系统设计判断固化为 Codex skill。

工作中的 Agent 平台落地则沉淀了几条判断：

  • Skill 即业务线：每条业务线用一个声明式配置（系统提示词加可选的工具 / 提示词 / 资产）接入，运行时热加载，新增业务线只加配置、不改平台代码。会话链路做成「按会话串行队列 → 并行组装记忆和摘要并做 token 预算 → 封装 Agent SDK → 后处理」。
  • Workflow 的能力边界：在法律 Workflow 上明确让工作流状态机拥有流程状态，让工具层成为 Agent 与系统能力之间唯一的业务边界（Read / Suggest / Write 分级），边缘适配层只做适配、不承载业务编排。
  • Agent 不是聊天框，而是带状态、工具、权限、评估、日志和回放能力的执行系统；真正有价值的 Agent 平台应该先能被工程团队验证，再谈规模化。

关于 Agent 运行环境本身怎么搭，见 Harness Engineering 和 AI Native 工作的第一性原理；项目群的拆解见 AI Agent 项目群。

RAG、知识库与评估

RAG 相关经验不应该只停留在「向量库加大模型」。从法律 AI Workflow 的实践看，RAG 系统至少需要覆盖：

  • 拆分职责：把「证据 RAG」（用户材料）与「知识 RAG」（权威知识）分开——后者必须带引用来源、按辖区 / 类型 / 版本过滤，规则的唯一事实源是知识库而不是模型。RAG 只负责引用，不能作为必填字段的唯一事实来源。
  • 知识注入分层：内置知识 → Prompt 注入（高频规则先注入，约 15–20K tokens）→ 按需检索 → 向量库 RAG。先上前两层解决高频规则，超出 context 预算再上后面。
  • 宁可显式失败也不静默降级：检索基础设施不可用时应显式失败（把这次运行标记为 blocked、不编造结论），而不是悄悄退化成关键词匹配。
  • 评估要防「跑分被误读」：报告带真实度字段，公开摘要不冒充完整专业卷宗；用合成守护样本测抗误判，用留出集防过拟合；发布级建议双人盲审。Model Gateway 用统一网关做多供应商接入，换来集中限流、Key 轮换、成本追踪和按 Response ID 的可观测性。

这部分可以和 MCP 心智模型、Prompt 工程框架、深入理解 LlamaIndex：上下文工程框架 以及 AI Eval Harness 连接起来，形成「知识库 - 工具 - 评估 - 工作流」的闭环。

云原生与平台工程

海外 FinTech 与 AI 平台阶段共同覆盖了几类平台工程能力，最核心的一条是：本地开发体验是云原生落地的最大摩擦点。

  • 用分层容器构建（只重建变更层）加自动化本地构建 - 推送 - 部署，让本地环境去掉对注册中心的依赖、改用集群原生 Service 做服务端负载均衡，更贴近生产拓扑；同一套「降低本地复现成本」的方法论，在 Kubernetes 和 docker-compose 两种栈下都复用过。
  • 服务发现在注册中心、集群原生 Service、Consul 之间的选型，服从既有平台的历史包袱，不教条化统一；分布式事务这类高风险依赖，宁可暂缓也不轻易全局引入。
  • 平台按职责解耦：网关（BFF、路由、鉴权）、身份（纯认证）、工作区（租户与权限）、Agent Runtime、领域业务后端彼此独立。
  • Cloudflare Workers、Durable Objects、Queues、Workflows、R2、D1、Vectorize 等边缘能力，在法律 Agent 场景里退成边缘适配加绑定网关，业务编排回到 Agent Runtime。
  • 分支治理：release 分支与 main 对齐、hotfix 与相关团队二次确认，推行 trunk-based development。

平台方向已整理到 SaaS 与云原生平台架构。

认证与授权分层

从海外 FinTech 到 AI 平台，一条一脉相承的判断：认证（你是谁）与授权（你能做什么）解耦。

  • 网关做无状态 JWT 校验加撤销名单缓存同步，权限计算下沉，不在每个下游服务各自实现。
  • 一套资源树加主体树的权限模型：操作权限分级加有效期，支持继承、合并（取更严格值）和链式校验（父级任一无权限即整体无权限）。
  • 到 AI 平台阶段落地为三层分离：身份层（OAuth 2.1 加 MFA / Passkey）、网关层（BFF 加令牌黑名单加粗粒度 RBAC）、工作区层（租户内权限），并用自定义的 Share-Code 授权解决访客 / 共享访问，与「按有效期收回权限」同源。
  • SaaS 多租户用框架内置过滤加 AOP 做零侵入的租户隔离，显著减少手写租户条件；跨租户共享数据（如分销代销）要在隔离规则之外单独建模「可见性授权」，不能靠加宽隔离边界解决。

方法论主线（贯穿全程）

把两条能力主线上反复出现的判断连成线——这些是「换了赛道仍带走」的判断，也是这张图谱真正想沉淀的东西：

  1. 支付 / 账务领域边界：信息流与资金流分层、账务与支付订单解耦，贯穿收单对账、清结算、支付域抽象到投资认购。
  2. 中台按开闭原则拆、而非按功能横向拆：面向对象组织中台代码，换来稳定性、扩展性和更小的回归面。
  3. 用状态机 / CQRS / 事件驱动承载流程：多入口复用同一套状态机，幂等按场景分路。
  4. 绞杀式下线遗留系统：hold 新需求 → 前后端分离 → 逐步抽服务，不做大爆炸重写。
  5. 分层配置承载易变、稳定运行时承载编排：用可插拔的声明式配置承载易变的业务规则，用少量稳定的运行时承载不变的编排。「Skill 即业务线」和 AI 原生研发的「规则 / 事实 / 执行」三层，都是这一条的体现。
  6. AI 产出不能自证有效：这是我原创并落地试点的一条判断。把「结论」（执行方给的判定，必须附证据信号指针）和「机器可重算的证据」分离成两个签名——执行方签 status，脚本机械复签 countersign，脚本每次运行整体撕掉旧签重算，杜绝预填造假；校验退出码用 0/1/2/3 表达「全通过 / 有失败 / 清单缺失或非法 / 脚本内部错误」四态，供阶段锁、夜间循环、CI 服务端复核、人工抽查四方消费；判不了的语义项走「具结加人工抽查」，不冒充硬门禁。裁判权从 AI 手里转移给确定性脚本；有证据的阻塞是合法结果，红灯说明机制在正常工作。展开见 用 AI 做测试 与 AI Eval Harness。
  7. 本地开发体验是云原生落地的最大摩擦点：见上一节。
  8. 认证与授权分层：见上一节。

其中第 4、6 条也可以升维成通用模式——绞杀式重构适用于任何遗留系统下线；「证据分级 + 双签 + 防伪 + 分级降级」适用于任何「AI 产出需要被另一个自动化系统信任」的场景，不限于测试验证。

团队与工程治理

除了架构，材料里也沉淀了一套带团队和治理研发流程的方法（不点名任何公司）：

  • 代码 Review 作为独立质量关卡：把转测前的代码 Review 从功能测试里单拎出来；持续跟踪单测覆盖率，把它作为风险证据而不是硬指标。
  • 管理洞察：项目制和业务守护者责任制冲突时会出现责任真空；人员流失会形成「技术死亡螺旋」，用培养跨领域全流程的「胶水型人才」来对冲。
  • 反馈与目标：用 BAR 结构做建设性反馈、用「描述行为 → 表达后果 → 征求意见 → 着眼未来」做绩效面谈、用 SMART 配合季度 KPI 加重点任务做目标管理。
  • 新人培养：1–3 个月的转正路径——先讲业务、再搭环境、第一周就加入一个小版本；转正要求至少一次技术分享，并通过发布考核和答辩。

这条线的完整展开见 从超级个体到超级团队。

知识图谱补全方向

接下来可以把知识图谱沿三层继续补全：

  1. 项目层：把 Sure、SAC Agent、Agent Lab、DDIA Skill、法律 Workflow、教育 Agent、投资档案与权限、电商交易中台、早期金融与支付拆成独立项目卡片。
  2. 能力层：把 Agent Runtime、Workflow、RAG、Model Gateway、Evals、Java 微服务、支付账务、SaaS 多租户、云原生、认证授权和可观测性作为核心概念。
  3. 方法层：把上面八条方法论主线，连同架构评审、测试优先、生产复盘、AI Coding 协作、知识沉淀和技能评估，整理成可复用方法。

这张图谱的目标不是展示经历多，而是让每个项目都能回到一个可解释的工程能力：什么问题、什么约束、什么取舍、如何验证。

素材来源

  • 个人架构师简历：AI 应用架构、Java 微服务架构、支付账务、团队治理和工作履历。
  • GitHub 仓库：sure、sac-agent、sac-agent4j、agent-lab、ddia-skill 等个人开源项目。
  • 工作材料（脱敏后）：早期金融与途牛支付、千米订单与财务重构、Bite 的 SaaS / SSO / 权限与云原生、CosX 的 Agent 平台与法律 AI Workflow，以及 AI 原生研发流程的一手实践。