Conductor 如何构建可治理的自适应图Durable Adaptive Graph【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor如果你要构建一个在运行时自己决定下一步的 AI 工作流直接让模型自由发挥会带来两个问题选择过程不可追溯副作用不受控。Conductor 的 Durable Adaptive Graph 模式对此的解法是让 agent 只从一组预先批准的选项中选择路径每次选择都被校验并持久化写入动作前必须经过人工审批。官方文档用一个完整示例演示该模式——受治理的 GitHub PR 审查器先做四轮持久化的证据收集再由人工批准最后才发布一条 PR 评论。本文按这个示例走一遍完整的构建与运行路径准备前置条件、注册并启动工作流、在审批门处放行或驳回最后核对输出。图结构与内置任务文档对该模式的定义adaptive agent 可以在运行时选择一条已批准的下一路径durable graph 让这个选择变成持久化、可检查、可治理的执行状态而不是一段留在单个进程内的临时控制流。示例图的整体流程摘自文档该图只使用 Conductor 内置任务LIST_MCP_TOOLS、CALL_MCP_TOOL、LLM_CHAT_COMPLETE、JSON_JQ_TRANSFORM、FORK_JOIN_DYNAMIC、JOIN、HUMAN、SWITCH、SET_VARIABLE、DO_WHILE。没有SIMPLE任务因此不需要注册任何自定义 worker。治理机制与任务原语的对应关系来自文档的 agent concern 映射表治理需求使用的原语运行时选择已批准的工具SWITCH 受保护的CALL_MCP_TOOL有界并行扇出FORK_JOIN_DYNAMIC跨迭代记忆SET_VARIABLE workflow variables人工审批门HUMANdurable pause跨重启存活迭代上限DO_WHILE的loopCondition失败补偿failureWorkflow运行前提Conductor 服务器与 CLI。用npm install -g conductor-oss/conductor-cli安装 CLIconductor --version验证本地开发可用conductor server start启动服务器。CLI 默认指向本地 OSS 服务器详见 CLI 文档。GitHub MCP 端点一个 HTTP 可访问、已完成认证的端点且暴露pull_request_read和add_issue_comment两个工具。pull_request_read可用方法包括get、get_files、get_check_runs、get_diff、get_reviews、get_review_comments。一个自己拥有的 fixture PR用于测试文档明确要求对 owned fixture PR 运行。凭据放在服务器侧示例把workflow.env.GH_TOKEN写入 MCP 的Authorization头。使用默认 environment-backed 配置时在 Conductor server 进程启动前设置CONDUCTOR_ENV_GH_TOKEN或配置等效的服务器端环境 provider。不要把 token 放进workflow.input.githubToken——workflow input 会随执行记录一起留存。需要更强隔离时使用 credential-injecting MCP gateway 或服务器端 secrets provider注意workflow.env的解析是 eager 的发生在任务调度时。注册并启动工作流完整可运行的定义在 ai/examples/35-governed-adaptive-agent.json工作流名governed_github_pr_reviewer版本 1工作流级超时timeoutSeconds: 1200即文档所说的 20 分钟上限超时策略TIME_OUT_WF。在仓库根目录注册定义conductor workflow create ai/examples/35-governed-adaptive-agent.json启动时输入以下参数。其中mcpServerUrl替换为你自己已认证的 GitHub MCP 端点owner/repo/pullNumber替换为你的 fixture PRllmProvider/model替换为你实际使用的 LLM 配置文档示例值为openaigpt-4o-miniconductor workflow start -w governed_github_pr_reviewer -i { mcpServerUrl: https://your-authenticated-github-mcp.example/mcp, owner: your-org, repo: pr-review-fixture, pullNumber: 42, llmProvider: openai, model: gpt-4o-mini }四轮证据收集前三轮固定第四轮自适应DO_WHILE循环固定跑 4 轮loopCondition为$.review_loop[iteration] 4每轮通过SWITCH按迭代号分派Pass 1pull_request_read的get读取 PR 上下文Pass 2get_filesperPage: 50读取变更文件面Pass 3get_check_runs读取 CI 检查Pass 4自适应LLM 只允许从固定的深读集合get_diff/get_reviews/get_review_comments中选一个或两个条目随后 JQ 守卫JSON_JQ_TRANSFORM对选择做校验、去重并截断到最多 2 项没有给出有效选择时回退到get_reviewsFORK_JOIN_DYNAMIC再用这份受控输入扇出CALL_MCP_TOOL任务做有界并行。前三轮是文档特意设为不可跳过的这让每次执行可比对也保证示例可见地完成四次迭代。每轮产出一个紧凑、经过校验的 assessment 写入 workflow 变量并追加到持久化证据账本evidence_ledger最终评论从这份 durable ledger 合成而不是来自无界的聊天历史。文档还强调PR 文本、评论和 diff 在每个 LLM prompt 中都是不可信证据绝不当作指令。人工审批门运行在第四轮之后停在HUMAN审批任务taskReferenceName为approve_pr_comment。这个暂停是持久的跨服务器重启和部署存活。先检查拟发布的评论和 durable ledger然后在 OSS Conductor 上完成该任务。workflow-id替换为你启动执行后得到的 workflow idconductor task update-execution \ --workflow-id workflow-id \ --task-ref-name approve_pr_comment \ --status COMPLETED \ --output {approved:true,reviewer:operatorexample.com,feedback:Approved after review}驳回则发送{approved:false,reviewer:operatorexample.com,feedback:Needs manual follow-up}。驳回会以一个持久化的决策记录完成工作流并且不会调用 GitHub。验证结果工作流的outputParameters暴露以下字段定义见 35-governed-adaptive-agent.jsonpassesCompleted循环完成的轮数evidenceLedger持久化证据账本riskLevel与review最终草稿的风险等级与完整评审结果approval审批决策publication发布状态。按审批路径图会先读取 PR 现有评论并检查标记!-- conductor-pr-review:workflowId --若标记已存在publication记为already_published不再重复发布否则通过add_issue_comment发布评论状态为published。驳回路径下状态为not_published原因字段为 Human approval was not granted.。治理边界文档给出的防护设计关注点示例中的防护缺少能力循环开始前工具发现步骤先验证两个必需的 GitHub MCP 工具缺失则以TERMINATE失败退出失控 agentDO_WHILE固定 4 次迭代深读扇出上限 2 次调用工作流 20 分钟超时上下文过大每个 MCP 结果虽持久保存但先裁剪为有界证据摘录再交给 LLM 评估模型输出非法非法 JSON 在 LLM 任务上失败并重试可解析但不符合契约的 assessment 通过 JQ 守卫变成显式的 unknown 结果非法的最终草稿在审批前 fail-close外部写入HUMAN任务必须返回approved: trueadd_issue_comment才可能执行重复评论生成的评论携带 workflow-ID 标记发布前检查 PR 现有评论中的该标记写入结果不明评论创建没有幂等键因此重试次数为 0对模糊失败按标记搜索对账不要盲目重试写入取消在批准写入之前终止不会产生评论写入进行中被取消时同样需要按标记对账文档还特别提醒这个 reviewer 刻意保留全部 4 轮迭代不要为它设置keepLastN——keepLastN会移除较早的循环输出和任务历史对短审计轨迹是错误取舍仅在可接受丢失历史时才对长循环使用它。恢复与运维基础设施恢复和普通任务级重试会保留已完成的下游任务失败的读取和 LLM 调用有有界重试策略各读取任务retryCount: 2指数或线性退避详见 task 定义文档 同级的 taskdef 配置说明。重试一个失败的DO_WHILE是另一回事它会重启该循环的迭代历史。设计更长的循环时应依赖已记录的证据账本和幂等的外部接口。可以从 UI 或 CLI 对执行做 pause、resume、inspect、terminate 操作。下一步Production Agent Architecture把这张受治理的图带入评估、部署、恢复与运维的完整参考架构含重试、内存、等待与补偿的展开说明。Failure Semantics任务重试、at-least-once 投递、等待与循环失败行为的准确契约。MCP Guide从工作流配置和调用 MCP 工具。JSON Code Native Workflow Orchestration快照、版本化与安全的运行时生成定义。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Conductor 如何构建可治理的自适应图（Durable Adaptive Graph）？
Conductor 如何构建可治理的自适应图Durable Adaptive Graph【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor如果你要构建一个在运行时自己决定下一步的 AI 工作流直接让模型自由发挥会带来两个问题选择过程不可追溯副作用不受控。Conductor 的 Durable Adaptive Graph 模式对此的解法是让 agent 只从一组预先批准的选项中选择路径每次选择都被校验并持久化写入动作前必须经过人工审批。官方文档用一个完整示例演示该模式——受治理的 GitHub PR 审查器先做四轮持久化的证据收集再由人工批准最后才发布一条 PR 评论。本文按这个示例走一遍完整的构建与运行路径准备前置条件、注册并启动工作流、在审批门处放行或驳回最后核对输出。图结构与内置任务文档对该模式的定义adaptive agent 可以在运行时选择一条已批准的下一路径durable graph 让这个选择变成持久化、可检查、可治理的执行状态而不是一段留在单个进程内的临时控制流。示例图的整体流程摘自文档该图只使用 Conductor 内置任务LIST_MCP_TOOLS、CALL_MCP_TOOL、LLM_CHAT_COMPLETE、JSON_JQ_TRANSFORM、FORK_JOIN_DYNAMIC、JOIN、HUMAN、SWITCH、SET_VARIABLE、DO_WHILE。没有SIMPLE任务因此不需要注册任何自定义 worker。治理机制与任务原语的对应关系来自文档的 agent concern 映射表治理需求使用的原语运行时选择已批准的工具SWITCH 受保护的CALL_MCP_TOOL有界并行扇出FORK_JOIN_DYNAMIC跨迭代记忆SET_VARIABLE workflow variables人工审批门HUMANdurable pause跨重启存活迭代上限DO_WHILE的loopCondition失败补偿failureWorkflow运行前提Conductor 服务器与 CLI。用npm install -g conductor-oss/conductor-cli安装 CLIconductor --version验证本地开发可用conductor server start启动服务器。CLI 默认指向本地 OSS 服务器详见 CLI 文档。GitHub MCP 端点一个 HTTP 可访问、已完成认证的端点且暴露pull_request_read和add_issue_comment两个工具。pull_request_read可用方法包括get、get_files、get_check_runs、get_diff、get_reviews、get_review_comments。一个自己拥有的 fixture PR用于测试文档明确要求对 owned fixture PR 运行。凭据放在服务器侧示例把workflow.env.GH_TOKEN写入 MCP 的Authorization头。使用默认 environment-backed 配置时在 Conductor server 进程启动前设置CONDUCTOR_ENV_GH_TOKEN或配置等效的服务器端环境 provider。不要把 token 放进workflow.input.githubToken——workflow input 会随执行记录一起留存。需要更强隔离时使用 credential-injecting MCP gateway 或服务器端 secrets provider注意workflow.env的解析是 eager 的发生在任务调度时。注册并启动工作流完整可运行的定义在 ai/examples/35-governed-adaptive-agent.json工作流名governed_github_pr_reviewer版本 1工作流级超时timeoutSeconds: 1200即文档所说的 20 分钟上限超时策略TIME_OUT_WF。在仓库根目录注册定义conductor workflow create ai/examples/35-governed-adaptive-agent.json启动时输入以下参数。其中mcpServerUrl替换为你自己已认证的 GitHub MCP 端点owner/repo/pullNumber替换为你的 fixture PRllmProvider/model替换为你实际使用的 LLM 配置文档示例值为openaigpt-4o-miniconductor workflow start -w governed_github_pr_reviewer -i { mcpServerUrl: https://your-authenticated-github-mcp.example/mcp, owner: your-org, repo: pr-review-fixture, pullNumber: 42, llmProvider: openai, model: gpt-4o-mini }四轮证据收集前三轮固定第四轮自适应DO_WHILE循环固定跑 4 轮loopCondition为$.review_loop[iteration] 4每轮通过SWITCH按迭代号分派Pass 1pull_request_read的get读取 PR 上下文Pass 2get_filesperPage: 50读取变更文件面Pass 3get_check_runs读取 CI 检查Pass 4自适应LLM 只允许从固定的深读集合get_diff/get_reviews/get_review_comments中选一个或两个条目随后 JQ 守卫JSON_JQ_TRANSFORM对选择做校验、去重并截断到最多 2 项没有给出有效选择时回退到get_reviewsFORK_JOIN_DYNAMIC再用这份受控输入扇出CALL_MCP_TOOL任务做有界并行。前三轮是文档特意设为不可跳过的这让每次执行可比对也保证示例可见地完成四次迭代。每轮产出一个紧凑、经过校验的 assessment 写入 workflow 变量并追加到持久化证据账本evidence_ledger最终评论从这份 durable ledger 合成而不是来自无界的聊天历史。文档还强调PR 文本、评论和 diff 在每个 LLM prompt 中都是不可信证据绝不当作指令。人工审批门运行在第四轮之后停在HUMAN审批任务taskReferenceName为approve_pr_comment。这个暂停是持久的跨服务器重启和部署存活。先检查拟发布的评论和 durable ledger然后在 OSS Conductor 上完成该任务。workflow-id替换为你启动执行后得到的 workflow idconductor task update-execution \ --workflow-id workflow-id \ --task-ref-name approve_pr_comment \ --status COMPLETED \ --output {approved:true,reviewer:operatorexample.com,feedback:Approved after review}驳回则发送{approved:false,reviewer:operatorexample.com,feedback:Needs manual follow-up}。驳回会以一个持久化的决策记录完成工作流并且不会调用 GitHub。验证结果工作流的outputParameters暴露以下字段定义见 35-governed-adaptive-agent.jsonpassesCompleted循环完成的轮数evidenceLedger持久化证据账本riskLevel与review最终草稿的风险等级与完整评审结果approval审批决策publication发布状态。按审批路径图会先读取 PR 现有评论并检查标记!-- conductor-pr-review:workflowId --若标记已存在publication记为already_published不再重复发布否则通过add_issue_comment发布评论状态为published。驳回路径下状态为not_published原因字段为 Human approval was not granted.。治理边界文档给出的防护设计关注点示例中的防护缺少能力循环开始前工具发现步骤先验证两个必需的 GitHub MCP 工具缺失则以TERMINATE失败退出失控 agentDO_WHILE固定 4 次迭代深读扇出上限 2 次调用工作流 20 分钟超时上下文过大每个 MCP 结果虽持久保存但先裁剪为有界证据摘录再交给 LLM 评估模型输出非法非法 JSON 在 LLM 任务上失败并重试可解析但不符合契约的 assessment 通过 JQ 守卫变成显式的 unknown 结果非法的最终草稿在审批前 fail-close外部写入HUMAN任务必须返回approved: trueadd_issue_comment才可能执行重复评论生成的评论携带 workflow-ID 标记发布前检查 PR 现有评论中的该标记写入结果不明评论创建没有幂等键因此重试次数为 0对模糊失败按标记搜索对账不要盲目重试写入取消在批准写入之前终止不会产生评论写入进行中被取消时同样需要按标记对账文档还特别提醒这个 reviewer 刻意保留全部 4 轮迭代不要为它设置keepLastN——keepLastN会移除较早的循环输出和任务历史对短审计轨迹是错误取舍仅在可接受丢失历史时才对长循环使用它。恢复与运维基础设施恢复和普通任务级重试会保留已完成的下游任务失败的读取和 LLM 调用有有界重试策略各读取任务retryCount: 2指数或线性退避详见 task 定义文档 同级的 taskdef 配置说明。重试一个失败的DO_WHILE是另一回事它会重启该循环的迭代历史。设计更长的循环时应依赖已记录的证据账本和幂等的外部接口。可以从 UI 或 CLI 对执行做 pause、resume、inspect、terminate 操作。下一步Production Agent Architecture把这张受治理的图带入评估、部署、恢复与运维的完整参考架构含重试、内存、等待与补偿的展开说明。Failure Semantics任务重试、at-least-once 投递、等待与循环失败行为的准确契约。MCP Guide从工作流配置和调用 MCP 工具。JSON Code Native Workflow Orchestration快照、版本化与安全的运行时生成定义。【免费下载链接】conductorConductor is an event driven agentic workflow engine providing durable and highly resilient execution engine for applications and AI Agents项目地址: https://gitcode.com/GitHub_Trending/co/conductor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考