从GitHub动态工作流理解确定性编排与Agent判断边界
内容提要
GitHub 动态工作流采用“确定性骨架+概率性节点”模式：用代码固定步骤、依赖、数据格式与审批点，仅将需判断的局部交给 Agent。该模式可重复执行、可观测、可控成本，并支持版本对比与测试。设计时需区分确定性工具、概率性判断和副作用节点，分别处理重试、超时与审批，适用于发布检查、事故研判等重复且失败代价高的任务。
延伸解读
确定性编排与Agent判断的边界划分
文章强调，确定性编排是用代码显式规定节点、依赖、并发、输入输出契约和失败处理，而Agent节点只负责需要理解与判断的局部。核心不是把每个推理写死，而是把不能由模型猜的规则写死。设计时需区分三类节点：确定性工具（如读取日志、运行测试）、概率性判断（如归纳根因候选，必须限定输出结构）、副作用（如发布、写库，需幂等键和审批）。这种分类有助于明确每类的重试、超时和回收策略。
可观测性不等于有日志
文章指出，一个容易被忽略的误区是把“有日志”等同于“可观测”。真正可观测的工作流至少要能按任务ID还原节点输入摘要、输出版本、耗时、错误类型、费用和审批人，同时不把密钥与隐私文本原样记入日志。否则问题发生时，团队仍只能靠猜。这要求在设计工作流时，不仅记录日志，还要确保关键元数据可追溯，并注意日志脱敏。
适用场景与判断准则
文章认为，确定性编排适合发布检查、批量PR审查、事故研判和可能运行很久的调查。单次简单改文案、一次性查询，或本来就没有多阶段约束的任务，普通对话更直接。涉及付款、删除、发布和对外发送时，即使有动态工作流，也应保留服务端权限检查与明确确认。判断是否值得编排的简单准则是：该任务是否会重复，失败是否有明确代价，以及事后是否必须解释。三者中有两项为真，就值得把关键步骤从自由对话提升为代码化流程。
Q&A
GitHub动态工作流的核心设计模式是什么？
核心设计模式是“确定性骨架+概率性节点”：用代码固定步骤、依赖、数据格式与审批点，仅将需要判断的局部交给Agent。
为什么要把工作流写成程序而不是让Agent自由规划？
写成程序可以换来重复执行、可观测和费用边界，并能回答为什么启动子任务、哪个输出被采用、升级后是否执行同样检查、谁批准了有副作用的步骤等问题，支持版本对比和自动测试。
设计工作流时，节点可以分为哪几类？各自如何处理？
分为三类：确定性工具（如读取日志、运行测试、校验JSON，相同输入应有相同语义）；概率性判断（如归纳根因候选，必须限定输出结构）；副作用（如发布、写库、发消息，需要幂等键和审批）。分类后需分别写清重试、超时和回收策略。
使用动态工作流时有哪些常见误区？
常见误区包括：认为用代码编排就不需要Agent；认为并行越多越快；只要两个Agent同意就当成真；以为暂停点自然可恢复；把“有日志”等同于“可观测”。
动态工作流适合和不适合哪些场景？
适合发布检查、批量PR审查、事故研判和可能运行很久的调查。不适合单次简单改文案、一次性查询或本来就没有多阶段约束的任务。涉及付款、删除、发布和对外发送时，即使有动态工作流，也应保留服务端权限检查与明确确认。
如何判断一个任务是否值得用动态工作流编排？
简单准则是：该任务是否会重复，失败是否有明确代价，以及事后是否必须解释。三者中有两项为真，就值得把关键步骤从自由对话提升为代码化流程。
