本文基于真实项目经历整理，并已按公开分享口径脱敏：内部项目名称、仓库路径、数据接口、运行标识、内容哈希及精确运营数据均已删除或泛化。文章保留业务问题、架构决策、实现机制、技术权衡和验证结论。
摘要
本文以一个面向股票市场低频研究的智能研究平台为背景，介绍我作为架构设计负责人，如何将不断复制的版本脚本重构为 Agent 驱动、流程受控、模块可复用、证据可追溯的研究系统。原系统随着研究假设和实验版本增加，逐渐出现算法重复、流程耦合、数据权限分散、实验难以复现和中断后难以恢复等问题。为此，我综合采用分层架构、管道—过滤器、状态机和事件溯源思想，设计了 Agent 决策控制、类型化工作流、研究内核、量化模块库、数据访问边界、证据日志与工件存储六层架构，并按 R1、R2、R3 三个阶段渐进实施：先建立可信执行和单一证据链，再验证模块跨真实工作流复用，最后完成静态模块目录与类型化编排。实践表明，该方案有效提升了系统的可维护性、可扩展性、可恢复性和审计能力，为后续快速构建新的专业研究流程提供了稳定基础。
一、项目背景
我参与建设的是一套智能量化研究平台。它的业务目标不是直接给出交易指令，而是把研究人员提出的假设，转换为一条可重复执行、可逐级停止、可事后复核的评估流程。
一项典型研究需要经历以下步骤：
1 | 提出假设 |
项目早期以独立 Python 脚本为主。一个新假设通常从复制旧版本开始，再修改数据字段、计算公式和判断阈值。这种方式适合快速探索，但随着版本增多，问题逐渐集中暴露。
首先，相同的覆盖率、集中度、事件窗口和样本配对逻辑在不同版本中重复实现，修复一个公式后很难确认是否同步到了全部流程。其次，数据访问、领域计算、流程推进和结果写入混在同一个脚本中，任何局部修改都可能影响整条链路。再次，运行进度散落在多个文件和日志里，长流程中断后只能依靠人工判断从哪里恢复。最后，如果让 Agent 直接操作参数、数据源和流程顺序，它虽然能够灵活决策，却也可能跳过 Gate、扩大权限或改变已经冻结的研究口径。
因此，项目的核心矛盾已经从“如何再实现一个指标”转变为“如何让大量研究能够长期、可信地迭代”。
二、需求分析与架构目标
结合业务特点，我将架构目标归纳为五项质量属性。
1. 可维护性
数据访问、量化计算、研究规则和流程编排必须解耦。一个公式的修改应有明确影响范围，新增流程不应继续复制大型脚本。
2. 可追溯性
每次正式运行都要绑定确定的样本、数据快照、模块版本、参数、流程和授权策略。任何结论都能反查输入、决策和执行过程。
3. 可恢复性
研究流程可能持续较长时间。进程异常退出后，系统应从最近一次已封存状态继续，并保证同一数据访问和同一节点不会被重复计入。
4. 可扩展性
新增量化能力应以标准模块进入能力库；新增研究方案应以工作流组合模块，而不是修改底层执行内核。
5. 安全性与证据可信度
Agent 可以做决策，但不能修改冻结规则、绕过必经 Gate、提升信息权限或提前读取历史答案。工程异常也不能被伪装成研究结论。
该平台主要运行在单机、离线的研究环境中，任务并发和用户规模有限。基于这一约束，我没有引入微服务、消息队列和分布式调度，而是选择本地事务、不可变工件和进程隔离。这样既能满足可靠性要求，也避免了为尚未出现的规模问题支付维护成本。
三、总体架构设计
系统以分层架构为主体，以管道—过滤器组织研究步骤，以状态机控制执行，以事件溯源思想保存权威证据。
1 | ┌─────────────────────────────────────────┐ |
控制请求自上而下传递，数据和证据自下而上返回。上层只依赖下层公开契约，量化模块不感知数据库，Agent 不直接写证据，工作流也不能绕过研究内核。
四、各层关键设计
1. Agent 决策控制层：让智能负责选择，而不是修改规则
业务希望 Agent 能根据当前证据选择下一步，但不能让它同时成为规则制定者和执行裁判。我的做法是把 Agent 限定为受约束的决策端口。
每次决策时，研究内核只向 Agent 提供当前状态摘要、允许动作、参数约束、剩余预算、信息上限和人工授权要求。Agent 返回选择后，内核再次验证状态是否过期、动作是否注册、参数是否越界。
因此，Agent 可以判断“下一步执行哪个已批准诊断”，却不能改变样本、阈值、数据快照和模块版本，也不能在正式停止后继续推进。该设计在灵活性和确定性之间建立了清晰边界。
2. 类型化工作流层：让流程关系可以在运行前检查
过去的流程关系隐藏在函数调用和条件分支中，只有运行到某一步才会发现输入不匹配。类型化工作流把这些隐式关系变成显式契约。
每个节点声明输入输出 Schema、上游来源、业务角色、信息等级、时间范围、可使用能力、是否为必经 Gate，以及时间和内存预算。编译器在运行前检查边是否兼容，执行器在运行时再次验证真实工件。
例如，一个用于历史窗口评估的工件不能被下游重新声明成另一时间范围；一个只获准读取“可用/不可用”状态的节点，也不能取得原始研究数值。这样既防止接口错配，也防止语义和权限被悄悄改变。
3. 研究内核层：用确定性状态机约束整个流程
研究内核是系统的执行核心。它负责校验不可变运行清单、记录 Agent 决策、生成稳定执行标识、推进节点、执行必经 Gate、提交首个终态并支持确定性恢复。
为了避免把所有失败都写成一个模糊的“停止”，我把状态拆成四个维度：
1 | 节点执行：成功或工程失败 |
这样，程序异常只能形成工程失败；数据覆盖不足可以形成节点成功后的研究停止；机制无效也有独立语义。准确分类失败，是保证研究结论可信的前提。
4. 量化模块层：只沉淀稳定数学能力
量化模块库保存可独立测试和复用的确定性计算，如加权覆盖、集中度、事件地标、稳健匹配和窗口对齐。
模块只接收不可变、类型化输入，不连接数据库、不访问网络、不写证据日志，也不感知具体工作流名称。每个模块通过模块标识、语义版本、输入输出 Schema、参数契约和实现摘要固定。
研究特有的样本角色、时间定义和缺失规则由适配器转换成公共输入。只有同一模块版本在至少两条真实流程中保持不变地运行，才认定为稳定共享能力。这样避免了“同一个文件里写两套分支”的假复用。
5. 数据访问层：只提供当前阶段真正需要的信息
数据访问层是所有研究数据的唯一入口。它负责冻结数据快照、统一字段和单位、验证业务键与血缘、批量读取，并按信息权限输出最小必要数据。
在早期 Gate 只需要判断数据是否齐全时，适配器可以瞬时校验原始数据，但交给模块的只有状态位图和计数，不包含原始数值。如果可用性已经达不到后续研究要求，系统可以在较低信息等级提前停止，既节省资源，也降低未来信息或历史答案泄漏的风险。
数据层禁止静默切换来源、自动补值或运行中漂移快照。任何数据口径变化都必须以新版本契约进入流程。
6. 证据与工件层：以单一事实源支持恢复和审计
我采用本地事务数据库保存运行清单、决策、执行、数据访问、事件链、工件引用和唯一终态，大对象则写入内容寻址存储。
数据读取前先提交唯一访问意图；计算完成后，先把不可变工件落盘，再在一个事务中提交引用、结果和 Seal。若进程在中间崩溃，恢复时可以重做相同物理查询，但复用原来的逻辑访问标识。
最终回执只是权威日志的紧凑投影，而不是第二份状态。即使回执丢失，也能依据日志和工件重建相同结果。这一设计消除了多份状态互相矛盾的问题。
五、R1、R2、R3 分阶段实施
为了降低重构风险，我没有一次性替换旧系统，而是选择已有正式结论的历史研究作为垂直切片。
| 阶段 | 主要问题 | 核心建设 | 阶段价值 |
|---|---|---|---|
| R1 | 运行不可追溯、恢复依赖人工 | 研究内核、证据日志、信息分级 | 建立可信执行基础 |
| R2 | 公式重复、复用停留在文件层 | 公共量化模块与真实双流程验证 | 证明稳定语义可复用 |
| R3 | 模块绑定和流程边仍然隐式 | 静态目录、类型化工作流与受控执行器 | 降低新增流程成本 |
1. R1：先建立可信运行基础
R1 首先实现研究内核、单一证据日志、内容寻址工件和信息分级，并选择一条只需要数据可用性信息的历史流程进行验证。
新流程在不读取旧核心数值的情况下，独立复现了原有的数据不足结论；正式终态封存后，才允许读取历史结果做兼容比较。首版在内存方面未达到预算，我又通过分批读取、并发只读和状态位图压缩完成优化。
最终，正式运行保持在分钟级，审计保持在秒级，内存控制在单机预算内，证据工件也从大规模数值材料缩小为轻量摘要。R1 证明了新内核具备可追溯、可恢复和低信息早停能力。
2. R2：用两条真实流程证明模块复用
R2 选择两条统计对象、时间窗口和角色定义均不同的历史流程，共用同一版本的加权可用性与集中度模块。
不同业务语义由适配器转换，公共模块中不允许出现针对流程名称的隐藏分支。两条流程都独立复现原有停止结论，并且保持相同的实现摘要、输入输出契约和参数定义。
这说明模块库不只是代码搬家，而是真正实现了“稳定数学语义一次实现、多个业务流程组合使用”。
3. R3：完成静态目录和类型化编排
R2 之后，模块虽然能够复用，但执行器、Codec、依赖闭包和工作流边仍有部分关系隐藏在组合代码中。R3 进一步引入静态模块目录、精确版本绑定、类型化线性工作流、受控执行器和实现依赖封存。
R3 还把新增模块和新增流程的开发步骤整理成项目 Skill：先定义契约，再实现纯模块，随后注册目录、编排工作流，最后执行权限、恢复、性能和兼容验收。
完成这一阶段后，新增研究流程主要变成“选择模块、编写业务适配器、声明节点和 Gate”，不再需要修改研究内核或复制大型版本脚本。
六、项目实施效果
三个阶段完成后，平台形成了较清晰的能力边界。
在可维护性方面，量化公式、数据访问、流程推进和证据封存实现解耦；公共公式只维护一份，版本影响范围可以通过模块绑定确认。
在可扩展性方面，新增流程不再从复制旧脚本开始，而是从业务契约和现有模块目录开始。只有缺少稳定能力时才新增模块，降低了重复开发。
在可靠性方面，运行进度由单一日志决定，恢复不再依赖人工查目录；相同节点和数据访问可以幂等重放，首个正式终态不能被覆盖。
在安全性方面，Agent、工作流、模块和数据层分别拥有最小权限。历史结果只能在正式终态后用于兼容审计，不能反向修改正式结论。
在性能方面，系统通过窄数据投影、状态位图、流式聚合和内容寻址存储，将正式运行控制在适合单机研究的分钟级，把重复审计压缩到秒级，并显著减少不必要的大工件读写。
需要强调的是，架构验收成功不等于研究策略有效。R 系列证明的是新架构能够在不提前读取答案的情况下，稳定复现既有研究结论；它不代表任何市场机制、业务效果或收益已经得到证明。
七、设计难点与解决方案
1. Agent 灵活性与确定性控制
如果完全限制 Agent，系统失去智能决策价值；如果让 Agent 直接控制一切，又无法保证协议稳定。我采用“Agent 提议、内核裁决”的方式，让 Agent 选择动作，让内核掌握权限、状态和 Gate。
2. 公共模块与业务语义
过度通用的模块会产生复杂参数，过度具体的模块又无法复用。我把稳定数学计算放入模块，把业务角色、时间窗口和研究阈值留在适配器与工作流中，在通用性和可理解性之间取得平衡。
3. 完整证据与运行性能
保存所有原始中间数据会增加存储和审计成本，只保存最终结果又无法复核。我采用“日志保存状态和引用、内容寻址存储保存必要工件、低信息阶段优先保存位图与摘要”的方式兼顾两者。
4. 架构扩展与过度设计
虽然动态 DAG、插件发现和分布式调度具有吸引力，但当前主要流程是单机线性研究链。我只实现已经被真实流程证明需要的能力，将更复杂的调度和服务化留到业务规模真正变化之后。
八、结论
本项目从真实研究业务中的脚本复制、流程耦合、恢复困难和证据分散问题出发，构建了 Agent 驱动、内核约束、模块与流程解耦、数据统一访问、证据完整留存的六层架构。
R1 先解决可信执行，R2 再证明真实复用，R3 最后提升编排能力。这一顺序体现了渐进式架构演进思想：先用最小闭环解决当前风险，再用真实业务验证抽象，最后才建设更高层工具。
通过该项目，我认识到，系统架构设计的核心不是采用多少新技术，而是围绕业务目标和质量属性合理分配职责、权限与依赖。对于研究型系统，最重要的不是保证每次研究都成功，而是让每一次成功或失败都真实、可解释、可复现，并能够成为下一轮迭代的可靠输入。
软考备考提炼
1. 可适配的论文题目
本案例可以用于以下方向：
- 论分层架构在信息系统中的应用；
- 论构件化设计与软件复用；
- 论软件系统的可维护性；
- 论可靠性设计与故障恢复；
- 论数据架构与统一访问；
- 论智能体系统架构；
- 论软件架构演化。
2. 我的项目角色
答题时可以明确写：
我担任系统架构设计负责人，负责梳理业务边界和质量属性，确定总体架构，设计核心契约与权限模型，组织分阶段迁移，并对性能、恢复和兼容性进行验收。
3. 论文展开主线
1 | 研究版本不断增加 |
考试时不必记忆类名和实现细节，但要保留“业务问题—质量属性—架构决策—技术机制—实施效果”的因果关系。
备考速记摘要
可用“一核、六层、三阶段、四保障”记忆全文：以可信智能研究为核心，面对脚本复制、流程耦合、权限失控和证据分散问题，建设 Agent 决策、工作流编排、研究内核、量化模块、数据访问、证据工件六层架构；R1 建可信执行，R2 验真实复用，R3 做类型化编排；通过不可变清单、最小权限、幂等恢复和终态后审计，保障系统可维护、可扩展、可恢复、可审计。
考场展开卡片
每个架构点按“问题—方案—机制—效果”扩写：
| 记忆点 | 问题 | 方案 | 机制 | 效果 |
|---|---|---|---|---|
| Agent | 决策可能越权 | Agent 只选择允许动作 | 动作白名单、参数和状态校验 | 灵活且可控 |
| Workflow | 流程隐藏在代码中 | 类型化编排 | Schema、角色、时间范围、Gate | 可检查、易扩展 |
| Kernel | 状态混乱、恢复困难 | 统一执行内核 | 状态机、稳定标识、首停 | 执行确定、失败可定位 |
| Module | 公式重复实现 | 纯量化模块库 | 版本、契约、实现绑定 | 高内聚、真实复用 |
| Data | 口径和权限分散 | 统一数据访问层 | 固定快照、批量读取、最小投影 | 数据一致、减少泄漏 |
| Evidence | 多份状态互相矛盾 | 单一证据日志 | 事件链、不可变工件、结果重建 | 可追溯、可恢复 |
遇到不同题目时，只需调整重点：
- 分层架构题：重点写六层职责、接口和依赖方向；
- 构件复用题：重点写纯模块、适配器和双流程验证；
- 可靠性题：重点写状态机、幂等恢复、唯一终态和结果重建；
- 数据架构题：重点写固定快照、数据血缘和最小投影；
- Agent 架构题：重点写 Agent 与确定性内核的权力分离；
- 架构演化题：重点写 R1、R2、R3 的渐进实施与技术取舍。
最后可用一句话收束：
我没有用复杂技术替代业务判断，而是通过分层、契约和证据链，把 Agent 的灵活决策约束在一个可复现、可恢复、可审计的智能研究平台中。