LangGraph Runtime Context:尽量别把运行配置塞进State
刚开始搞LangGraph时的确很容易把所有东西都无脑塞进State用户输入放State。中间结果放State。工具返回放State。模型配置、环境配置、用户身份。。。这些也顺手放State。是省事state里啥都有了节点想用什么就拿什么像点读笔哪里不会点哪里但其实同一张LangGraph图在不同运行场景下可能需要一些“外部配置”最好不要把他们都混进图的业务State里而应该通过Runtime Context注入到graph里。用一个CI/CD发布流水线的例子讲一下这个事的逻辑。先看一个demo发布流水线假设我们用LangGraph编排一个发布流程run_tests ↓ security_scan ↓ build_image ↓ deploy ↓ write_release_note这个流程里有两类信息。第一类是这次发布任务本身的进展和结果比如commit_sha这次发布哪个代码提交 test_result测试是否通过 security_scan_result安全扫描结果 image_tag构建出来的镜像 deploy_status部署状态 error_message失败原因 release_note发布摘要这些适合放State因为它们描述的是这次发布已经发生了啥流程中断后恢复也需要知道测试过没有、镜像构建到哪里、部署成功还是失败。第二类是这次运行时的外部配置比如可能会存在target_env发布到staging还是prod runner_id哪台CI runner在执行 docker_registry镜像推到哪个仓库 kube_context连哪个Kubernetes集群 current_operator谁触发或批准发布 dry_run是否只演练不真实部署而第二类的这些就是我上面说的“外部配置”了就是他们更适合放Runtime Context里State和Runtime Context有啥区别字段应该咋放原则1、State放记录任务事实的东西2、Runtime Context放提供运行条件的东西如果这个字段负责的是这次任务已经发生了什么那它大概率是State。如果这个字段负责的是这次运行应该在什么环境下怎么执行那它大概率是Runtime Context。而实际分类的时候哪些变量放state哪些放runtime context里还是要根据业务属性做具体判断无非是多调试几次的事代码里怎么写比如我们这个ci/cd的案例中State只放发布任务相关字段class DeployState(TypedDict, totalFalse): commit_sha: str change_summary: str test_result: Literal[passed, failed] security_scan_result: str image_tag: str deploy_status: Literal[pending, success, failed, skipped] error_message: str release_note: str audit_log: list[str]然后用一个Runtime Context单独声明下面这些class DeployContext(TypedDict): target_env: Literal[dev, staging, prod] runner_id: str docker_registry: str kube_context: str current_operator: str dry_run: bool创建图时要手动把Context结构声明给LangGraph就是context_schemaDeployContext这句graph_builder StateGraph( DeployState, context_schemaDeployContext, )调用图时State和Context分开传initial_state { commit_sha: abc123, change_summary: 修复登录接口超时并补充异常处理日志, deploy_status: pending, audit_log: [], } prod_context { target_env: prod, runner_id: github-runner-07, docker_registry: registry.company.local, kube_context: prod-cluster, current_operator: alice, dry_run: False, } result graph.invoke(initial_state, contextprod_context)然后context传进去了在哪里用答案是在需要运行配置的节点里通过runtime.context读取。Context到底在哪里被用到比如build_image节点def build_image(state: DeployState, runtime: Runtime[DeployContext]) - DeployState: context runtime.context image_tag f{context[docker_registry]}/demo-api:{state[commit_sha]} return { image_tag: image_tag, }1、先在build_image节点里通过runtime: Runtime[DeployContext]接收然后把runtime.context给变量context2、state[“commit_sha”]从state里取出我要发布哪个commit3、context[“docker_registry”]从context里取出这次运行要推到哪个镜像仓库4、image_tag构建节点产生的新结果写回State再比如deploy节点也用到了runtime contextdef deploy(state: DeployState, runtime: Runtime[DeployContext]) - DeployState: context runtime.context if context[dry_run]: return { deploy_status: skipped, error_message: dry_runtrue本次没有执行真实部署, } return { deploy_status: success, }这个节点主要用了Runtime Context里的dry_run决定是否发起真实的部署。如果传入的是staging dry-runstaging_context { target_env: staging, docker_registry: test-registry.company.local, kube_context: staging-cluster, dry_run: True, ... }最终状态会是image_tag: test-registry.company.local/demo-api:abc123 deploy_status: skipped error_message: dry_runtrue本次没有执行真实部署如果传入的是prodprod_context { target_env: prod, docker_registry: registry.company.local, kube_context: prod-cluster, dry_run: False, ... }最终状态会是image_tag: registry.company.local/demo-api:abc123 deploy_status: success到这里就会发现了同一个commit同一张图换了Runtime Context运行行为就变了下一步cicd真实发布系统怎么衔接上是不是LangGraph输出某个字段然后外部系统看到这个字段就自动部署必然不是真实部署大多不是由某个State字段自动触发的真正触发外部部署系统的依然是节点函数里的代码。也就是deploy节点里可以调用Kubernetes API、Argo CD API、Jenkins API、GitHub Actions API或者你们公司内部自研的发布平台API等等吧。这个是具体部署相关的这里主要讲下后续的大致逻辑细节不展开。具体实验内容GitHub 仓库 https://github.com/yauld/ai-forge 完整实验文章 labs/langgraph/foundations/23 | LangGraph Runtime Context不要把配置塞进 State.md 实验代码 labs/langgraph/foundations/experiments/22_runtime_context_cicd/学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】