最近需要把一套 Docker 单容器运行的 n8n，从 1.123.40 升级到 2.33.7。乍看只是换一个镜像标签，真正动手后才发现：跨大版本升级的重点从来不是启动新容器，而是确认数据边界、提前暴露兼容问题，以及准备一条真的能走通的回滚路径。
这篇记录一套适用于“小型自建实例 + SQLite + Docker named volume”的稳妥迁移方法。PostgreSQL、queue mode、多 worker 等部署不在本文范围内。文中的目录、容器名和数据卷都是通用示例，不包含真实服务器信息。
先给结论：
1 | 1.123.40 |
官方没有要求逐个 2.x 小版本升级，也没有为每一对跨版本组合单独背书。本文选择 1.123.69 作为预检过渡点，再进入 2.33.7。这不是数据库迁移的强制分段，而是为了先用 1.x 的 Migration Report 和 task runner 行为做一次低成本预演。
本文基于真实项目经历整理，并已按公开分享口径脱敏：内部项目名称、仓库路径、数据接口、运行标识、内容哈希及精确运营数据均已删除或泛化。文章保留业务问题、架构决策、实现机制、技术权衡和验证结论。
本文以一个面向股票市场低频研究的智能研究平台为背景，介绍我作为架构设计负责人，如何将不断复制的版本脚本重构为 Agent 驱动、流程受控、模块可复用、证据可追溯的研究系统。原系统随着研究假设和实验版本增加，逐渐出现算法重复、流程耦合、数据权限分散、实验难以复现和中断后难以恢复等问题。为此，我综合采用分层架构、管道—过滤器、状态机和事件溯源思想，设计了 Agent 决策控制、类型化工作流、研究内核、量化模块库、数据访问边界、证据日志与工件存储六层架构，并按 R1、R2、R3 三个阶段渐进实施：先建立可信执行和单一证据链，再验证模块跨真实工作流复用，最后完成静态模块目录与类型化编排。实践表明，该方案有效提升了系统的可维护性、可扩展性、可恢复性和审计能力，为后续快速构建新的专业研究流程提供了稳定基础。
本文以我负责架构设计与核心链路落地的一套液冷 IDC 机房数字孪生监控平台为背景，介绍系统从实时数据大屏原型演进为集资产管理、真实机房编辑、场景版本治理、三维资产生产和 2.5D/3D 展示于一体的平台。针对实时数据与场景配置耦合、模型身份推断不可靠、并发保存和历史恢复缺失、三维资产发布不可追溯等问题，我以分层架构为主线，采用模块化单体作为部署形态，并在局部使用端口与适配器、管道—过滤器和版本化契约，形成“一个场景契约、两类状态、三条业务链、五个架构层、六类发布门禁”的总体架构。系统经过实时监控基础、配置契约与治理、真实编辑与资产绑定、三维资产工程化四个阶段，最终形成可编辑、可发布、可恢复、可追溯的数字孪生闭环；最新实现进一步将机房、可见环境和图像照明分层，在不改变业务交互的前提下改善视觉表现。本文同时将该实践提炼为软考“系统架构设计师”论文的可展开案例。
公开分享说明：本文已对公司、客户、内部服务、接口、数据表、资产编号和部分测试参数进行泛化或取整，仅保留理解架构决策所需的信息。
出处：bojieli/ai-agent-book
本文是在开源原作基础上整理的精读稿，保留核心定义、设计原理、工程取舍、风险与高价值案例，并剔除互动问答、实验操作步骤和验收要求，便于集中阅读和复习。
我业余在做一个 A 股量化分析系统：自动拉数据、算因子、做因果推断、生成个股分析报告。它从最初十几个互相调用的脚本，长成了一个有数据层、因子层、模型层、决策层、复盘层的系统。这篇是写给”想做量化系统、但还停在写脚本阶段”的新手的复盘——不讲怎么调参赚钱，只讲怎么把系统的骨架搭对。 因为我越做越确信：量化里真正难的不是策略，是工程。
这是一篇写给自己的复盘。我是个写了多年 Python / JS 的程序员，业余时间用 Godot 做一款像素风的「连线消除 + Roguelike」单机游戏（暂名《勇闯昆图库塔》）。从一张白纸到一个能让真人坐下来玩的版本，踩了不少坑，也总结出一些”早知道就好了”的经验。趁记忆还热，记下来温故知新。
