【免费下载链接】FinSight-AIAI equity research agent with resilient workflows, evidence-grounded RAG, versioned reports, and automated quality evaluation.项目地址https://gitcode.com/gh_mirrors/fi/FinSight-AI点击查看免费下载FinSight-AI 是一个开源的 AI 股票研究 Agent 项目它把一次完整的股票研究数据入库 → 指标计算 → 文档索引 → 知识构建 → AI 分析建模为一个长时间运行的工作流。本文带你深度剖析这套AI 工作流状态机如何做到三点核心能力可恢复任务卡住能自动救活、可重试失败任务安全重试、可观察每个阶段的健康度一目了然。即使你是第一次接触工作流编排读完后也能看懂它的状态流转与并发控制设计。为什么 AI 研究任务需要工作流状态机一个普通的请求-响应接口很难承载 AI 研究任务因为这类任务有几个天然痛点⏳耗时长抓取财报、计算几十个财务指标、构建向量索引、调用大模型整条链路动辄数分钟成本高重复执行一次 AI 分析意味着重复烧钱重复索引则是白白浪费算力易失败网络超时、模型限流、索引中断……任何一环都可能挂掉️难排查传统同步接口一旦超时连卡在哪一步都不知道。FinSight-AI 的解法是把长任务拆成多个显式阶段每个阶段落库、可幂等执行、可独立重试。设计目标在 docs/design-agent-workflow.md 中写得很清楚让每一个昂贵阶段都是幂等的idempotent、可恢复的recoverable、可观察的observable并且与证据evidence绑定。整体架构还可以参考 docs/architecture.md 中的 Agent Workflow 章节。Status 与 Stage 双轨设计一个管生命周期一个管流水线位置打开 WorkflowTask.java你会发现任务模型里同时存了status和stage两个字段——这是整个状态机最值得品味的设计决策。WorkflowStatus生命周期状态回答这个任务现在整体处于什么状态共 7 个值定义在 WorkflowStatus.javaStatus含义CREATED已创建等待执行RUNNING正在执行RETRYING准备重试SUCCEEDED执行成功终态FAILED执行失败可重试COMPENSATING补偿处理中DEAD_LETTER死信重试次数耗尽AgentWorkflowStage流水线阶段回答Agent 现在做到研究流水线的哪一步共 11 个值定义在 AgentWorkflowStage.java。为什么一定要分开因为任务失败了和任务卡在索引阶段是两个维度的信息Status 驱动重试与恢复逻辑Stage 驱动告警与排查。一个任务可以是FAILED状态但停在AI_ANALYZING阶段恢复调度器就能精确告诉你是 AI 分析这一步挂了前面四步的产物都可以复用。此外任务还携带idempotencyKey幂等键、attempts尝试次数、leaseOwner租约持有者、fencingToken围栏令牌等字段为后文的高并发防护打下基础。五段式研究流水线从数据入库到 AI 分析自动接力状态机驱动的研究流水线由 5 个任务类型首尾相接组成调度逻辑在 WorkflowOrchestrator.java 的publishNext方法中阶段任务类型做什么1️⃣ 数据入库FINANCIAL_DATA_INGESTION抓取公司文档、公告与财务报表2️⃣ 指标计算FINANCIAL_METRIC_RECALCULATION计算财务指标与风险信号3️⃣ 文档索引DOCUMENT_INDEX_BUILD文档切块、构建检索证据4️⃣ 情报构建COMPANY_INTELLIGENCE_BUILD生成公司事件与知识图谱关系5️⃣ AI 分析STOCK_AI_ANALYSIS生成有证据来源支撑的研究报告每个任务成功后会自动创建或复用下一个任务并发布执行整条链路无人值守。最终用户在产品页面看到的就是这条流水线的完整产出——公司研究页的价格走势与关键指标值得注意的是每个阶段的产物都会独立持久化第 3 阶段构建的检索证据就是产品里证据来源页面的数据底座你可以按股票代码直接核验 AI 结论背后的原始公告与财报这种每阶段落库的拆分正是可恢复性的前提——重试时不需要从头再来。幂等提交 Redis 单飞租约防止重复执行烧钱并发场景下最容易出的事故是两个实例同时发现这个任务还没人做于是同时开跑AI 分析费用翻倍、索引建两遍。FinSight-AI 用三层防线解决幂等提交任务创建走仓库层的createIfAbsent见 JdbcWorkflowTaskRepository.java由 PostgreSQL 对idempotencyKey的唯一约束兜底——两个实例撞车时后到者直接拿到已存在的任务而不是再插一条。Redis Lua 单飞租约真正执行前要先抢到租约。抢租约的过程封装在一个原子 Lua 脚本里RedisBackedWorkflowLeaseService.java检查租约键是否存在 → 递增 fencing 计数器 → 写入owner:fencingToken并设置 TTL → 返回令牌。Lua 脚本在 Redis 中原子执行天然杜绝了检查-写入之间的竞态窗口。Fencing Token 围栏令牌每次状态流转都是带条件的 CAS 更新WHERE id ? AND status ? AND fencing_token IS NOT DISTINCT FROM ?见 JdbcWorkflowTaskRepository.java。哪怕某个过期的 worker 恢复过来想写库只要令牌对不上写入就会被拒绝——陈旧执行者无法覆盖更新的恢复结果。另外执行期间还会以 TTL/3 的间隔做租约心跳续约WorkflowOrchestrator.java续约失败则计数ownership_lost指标并安全退出。本地开发没有 Redis 时租约服务会降级为进程内单飞 Map而生产环境通过finsight.workflow.allow-local-lease-fallbackfalse关闭降级、失败即报错确保 Redis 故障时不会静默丢失跨实例互斥。超时自动恢复卡住的 AI 任务如何被救活就算租约、幂等全都做到位进程被杀、机器宕机依然会让任务永远停在RUNNING。这时由 WorkflowRecoveryScheduler.java 定时扫描默认每60 秒扫描一次找出超过finsight.workflow.running-timeout默认10 分钟没有更新的任务按尝试次数分流attempts 3→ 标记为FAILED并立即转RETRYING重新发布attempts 3→ 直接进入DEAD_LETTER死信分流逻辑见 WorkflowTask.java每次恢复都会打一条带taskType和stage标签的finsight.workflow.recovery.total指标卡住的 Job 从此可见且可恢复而不是静默地烂在库里。在 RabbitMQ 模式下消费端 RabbitWorkflowListener.java 捕获异常后也会把FAILED任务转为RETRYING重新入队两种部署模式共用同一套恢复语义。可观察性与手动重试随时掌握任务健康度工作流的可观察体现在三个层面指标层Micrometer 埋点覆盖finsight.workflow.task.duration分任务类型/结果的耗时、finsight.workflow.task.total计数、finsight.workflow.recovery.total恢复次数、finsight.workflow.lease.renewal.total租约续约结果可直接接监控大盘告警API 层WorkflowController.java 提供GET /api/workflows任务列表、GET /api/workflows/summary按 Status / Stage 双维度聚合的汇总统计、GET /api/workflows/{taskId}单任务详情️人工兜底POST /api/workflows/{taskId}/retry允许手动重试FAILED或DEAD_LETTER任务且重试本身也是 CAS 操作——若任务在重试请求的瞬间被其他节点改动会返回 409 Conflict 而不是产生脏状态。调试时也可以直接查库确认状态流转docs/development.md 中给出了完整命令SELECT id, status, stage, fencing_token FROM workflow_tasks ORDER BY updated_at DESC;生产与本地配置本地宽松、生产严格工作流相关的配置项集中在 application.ymlfinsight: workflow: allow-local-lease-fallback: true # 生产环境置为 false running-timeout: PT10M # RUNNING 超时阈值 recovery-delay-ms: 60000 # 恢复扫描间隔这个本地宽松、生产严格的取舍很实用本地单实例开发不需要额外起 Redis代码路径保持一致生产环境则强制 fail-closed杜绝静默降级带来的隐患。写在最后回看 FinSight-AI 的工作流状态机它并没有引入重型工作流引擎而是用几样朴素的组件拼出了生产级的可靠性Status / Stage 双轨——让生命周期与流水线位置各自独立演进幂等键 Lua 原子租约 fencing token——三层防线保证昂贵阶段单飞执行超时恢复调度 死信分级——让卡死任务自动浮现、自动重投全链路指标 汇总 API 手动重试——出了问题 10 分钟内能定位到具体阶段。这套模式对任何需要跑长任务、调 LLM 的系统都有参考价值。想继续深入可以从 WorkflowOrchestratorIT.java 和 RedisBackedWorkflowLeaseServiceIT.java 两个集成测试入手它们覆盖了租约竞争、超时恢复等关键并发场景的完整行为。赞分享【免费下载链接】FinSight-AIAI equity research agent with resilient workflows, evidence-grounded RAG, versioned reports, and automated quality evaluation.项目地址https://gitcode.com/gh_mirrors/fi/FinSight-AI点击查看免费下载相关推荐OpenClaw OpenProse 文件系统状态管理实战解析用 .prose 目录支撑可检查、可恢复、可长时间运行的 AI 工作流OpenClaw OpenProse 文件系统状态管理实战解析用 .prose 目录支撑可检查、可恢复、可长时间运行的 AI 工作流 导读 本文以 OpenC人工智能大模型LLM 网关AI Agent即时通讯WebCodex 长任务Job管理教程如何让 AI 跑测试、跑构建时不丢任务随时观察与恢复WebCodex 长任务Job管理教程如何让 AI 跑测试、跑构建时不丢任务随时观察与恢复 WebCodex 是一个让云端 AI Agent 安全连接本TechSpar 长任务如何做到可恢复、可取消持久化任务状态机实现原理TechSpar 长任务如何做到可恢复、可取消持久化任务状态机实现原理 TechSpar 是一个持续进化的 AI 面试训练系统。在生成面试复盘、AI 出题、C创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考