如何把 DeerFlow 代理绑定到 GitHub issue 与 PR 的 Webhook 事件【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow如果你希望 DeerFlow 中的自定义代理custom agent在 GitHub 仓库的 issue、issue 评论、PR 或 PR 评审评论事件发生时自动被触发需要完成一次 Webhook 集成在代理的config.yaml中声明github:绑定块让 DeerFlow Gateway 的POST /api/webhooks/github路由接收并验签 GitHub 推送再把事件分发给匹配的代理。GitHub 是一个webhook-push通道没有长轮询 worker每条 GitHub App / 仓库级 delivery 都会落在该路由上经过 HMAC 验签后为每个匹配绑定各发布一条InboundMessage再经由与 Feishu/Slack/Telegram 相同的ChannelManager进入 DeerFlow。以下是文档 GITHUB_AGENTS.md 给出的架构与 Gateway 路由约定见 gateway/AGENTS.md下的完整配置路径。准备条件开始前确认以下几点均来自项目文档DeerFlow Gateway 已运行且可以访问到一个可用的自定义代理绑定是按代理声明的不是全局的。有一个 GitHub App并已拿到该 App 对目标仓库的installation_id。文档中 GH token 生命周期一节说明代理使用GITHUB_APP_IDPRIVATE_KEY换取per-call installation token不是继承的环境变量因此部署 DeerFlow 的进程需要配置这两个凭据。一个 Webhook 签名密钥用于 Gateway 侧的GITHUB_WEBHOOK_SECRET环境变量。路由挂载规则是 fail-closed 的/api/webhooks/github仅在设置了GITHUB_WEBHOOK_SECRET时挂载开发环境也可以显式设置DEER_FLOW_ALLOW_UNVERIFIED_GITHUB_WEBHOOKS1跳过验签见 gateway/AGENTS.md 中 GitHub Webhooks 一节。全局配置channels.github全局config.yaml中的channels.github块刻意保持最小——只有两项enabled操作员级别的 kill-switchdefault_mention_login跨代理的默认 mention 登录名。哪个代理处理哪个仓库的所有信息都放在代理自己的配置里不放在全局配置中GITHUB_AGENTS.md → Overview。代理配置声明 github: 绑定块在代理的配置文件中声明github:块路径为users/{owner_user_id}/agents/{agent_name}/config.yaml{owner_user_id}、{agent_name}替换为你的实际 owner 与代理名。块的形状参考 GITHUB_AGENTS.md 的架构说明与测试夹具 test_github_agents_config.py示例如下数值取自仓库测试夹具需替换为你自己的 installation_id 与仓库name: coding-llm-gateway github: installation_id: 123456 # GitHub App 对目标仓库的 installation id bot_login: coding-llm-gateway-bot # 代理的 App 身份登录名 bindings: - repo: zhfeng/llm-gateway # owner/name 形式 triggers: pull_request: actions: [opened, reopened] issue_comment: require_mention: true allow_authors: [zhfeng] mention_login: coding-llm-gateway-bot关键语义均以文档为准绑定通过triggers:声明该代理关心的事件没出现在triggers:里的事件不会投递给该代理dispatcher 根本不会为它们加载这个代理。DEFAULT_TRIGGERS只为已声明事件提供字段级默认值例如require_mention: true不再是启用列表。代理配置中不存在github:块时github字段为None所有既有代理加载行为不变测试test_github_field_defaults_to_none验证了这一点。每个 agent 绑定还会列出bot_login参与下文 mention 优先级链。在 GitHub App 中配置 Webhook在 GitHub App 侧把 Webhook 指向 DeerFlow Gateway 的POST /api/webhooks/github并做两件事设置 Webhook secret其值必须与 Gateway 进程的环境变量GITHUB_WEBHOOK_SECRET完全一致。每条 delivery 会携带X-Hub-Signature-256头Gateway 用hmac.compare_digest对 sha256 签名做常数时间比较。订阅事件类型。路由识别的事件为ping、issues、issue_comment、pull_request、pull_request_review、pull_request_review_comment不认识的事件返回 200 且响应中带handledfalse。验证绑定是否生效文档给出的可核对行为如下响应语义正常投递返回 200响应中的dispatch字段汇总 matched / fired / skipped 的代理gateway/AGENTS.md。失败语义fan-out 运行时失败返回 503delivery 会被记录为 failed——注意GitHub 不会自动重试任何失败的 delivery包括 5xx需要手动 / API / 脚本方式重发。而channels.github.enabled: false、未知事件、payload 非法或通道服务不可用这类永久性条件返回 200 并带 skipped/handled 响应不会进入重试。线程确定性resolve_thread_id(repo, issue_or_pr_number, agent_name)用uuid5(GITHUB_THREAD_NAMESPACE, {repo}#{number}:{agent})生成确定性的 LangGraph thread id同一个(repo, PR/issue 编号)总是落到同一线程——即使 store 被清空、即使跨 Gateway 副本。注意agent_name是 seed 的一部分同一 PR 上的两个代理例如 coder reviewer会刻意获得不同的线程 id跨代理协作通过 GitHub 评论进行。mention 触发声明了require_mention: true的事件触发用的 mention 登录名按以下优先级解析trigger.mention_login每事件覆盖→github.bot_login代理的 App 身份→channels.github.default_mention_login操作员默认→agent.name兜底。每一级的纯空白值都视为未设置链会自然落到下一级。代理如何回写 GitHub出站是 log-only这是一个容易误解的点务必确认预期DeerFlow 不会把代理的最终回复自动发到 GitHub。GitHubChannel.send()是 log-only 的——最终 assistant 消息只以 INFO 级别写入 gateway 日志不自动发帖。回写由代理在沙箱内自行通过ghCLI 完成gh issue comment、gh pr comment、gh pr create等因为多个代理可以绑定同一事件自动发帖会产生一次 mention 两条回复的问题代理经常需要发中间更新比如链接 PR 的 issue 评论只自动发最终消息的契约无法表达这一点dispatcher 的_is_self_event门控已经保证代理通过gh发的评论不会把 Webhook 回环成同一代理的新 run。对应的凭据链路bus 消费端用installation_id换取 per-call installation token绑定为run_context[github_token]再以GH_TOKEN和GITHUB_TOKEN两个环境变量注入代理的沙箱命令per-callextra_env不修改os.environ不跨仓库泄漏。已知限制installation token 有效期约 1 小时长 run高recursion_limit下数小时的编码任务在接近到期时的git push/gh pr create可能遇到 401自动续期被有意推迟见 GITHUB_AGENTS.md → GH Token Lifecycle。若 mint 失败App id 错误、installation_id 不对、缺私钥代理仍会以只读方式运行——只读好过没响应。边界与已知限制配置完成后需要了解的边界全部来自文档线程创建竞态同一(repo, number)的两条 delivery 在毫秒级内竞争threads.create(thread_idpreferred_thread_id)时第二个写入方收到 409ConflictError恢复逻辑只处理这一种情况随后threads.get复核通过才复用确定性 id 并缓存映射其他失败DB 抖动、5xx会向上抛出让 delivery 失败/重试避免把从未创建的线程 id 永久缓存进 store。忙时后续缓冲已有 run 在跑时新评论到达runs.create()也会抛ConflictError此时后续消息按 delivery_id 去重后进入每线程最多 20 条的缓冲run 结束一次 drain 最多合并 10 条为followups-while-busy输入。该行为由ChannelRunPolicy.buffer_followups_on_busy门控默认FalseGitHub 通道在自己的run_policy.py中显式开启。已知限制缓冲与 watcher 活在单个ChannelManager进程的内存里——GATEWAY_WORKERS1或多 pod 部署下被路由到不同 worker 的后续评论看不到别的 worker 的缓冲单进程/单 pod 部署不受影响。重发责任在操作员503 的 delivery 不会被 GitHub 自动重试需要手动重发。参考backend/docs/GITHUB_AGENTS.md — 完整管道架构fan-out 时序、mention 优先级、token 生命周期、竞态恢复、忙时缓冲backend/app/gateway/AGENTS.md —/api/webhooks/github路由的挂载条件、事件清单与响应语义backend/tests/test_github_agents_config.py —github:块的解析与 YAML 往返测试可作为绑定形状的对照backend/app/gateway/routers/github_webhooks.py — HMAC 验签与路由挂载谓词【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考