用GitHub议题分流串起Agent落地

一句提示词能把 GitHub issue 分对类，离上线还差多少？这篇文章用 issue 分流助手串起了完整路径：先验证单次模型调用，再接工具、加权限限制，最后补上评估、日志和部署。它的核心判断是：自主性应该排在最后。

对想把 AI 编程脚本做成团队工具的开发者，这份清单值得看。但它提供的是架构入门路线，没有真实上线数据；示例循环也只是草图，不能直接复制进生产项目。

先证明提示词有效，再考虑自主执行

作者把 Agent 拆成三个部分：模型、指令和工具。真正需要分清的，是工作流（Workflow）与 Agent 的区别。

工作流由代码预先规定路径，模型只处理其中某些步骤。Agent 则让模型决定下一步做什么、调用哪个工具。比如，固定执行「读取 issue、生成分类、保存回复草稿」就可以是一条工作流，并不一定需要模型自己规划。

能用固定流程解决的任务，先用固定流程。

文章给出的判断条件有三个：任务需要复杂判断，规则已经纠缠到难以维护，或者输入包含大量非结构化信息。Issue 分流符合其中的复杂判断和自由文本输入：用户描述不统一，同样提到页面卡顿，可能是 bug，也可能只是使用问题。

即便如此，第一步仍然不用工具。作者建议先让模型读取粘贴的 issue，输出 JSON，包含：

• labels：最多 3 个，只能从 bug、feature、docs、question、duplicate、good-first-issue 中选择。
• priority：只能是 low、medium、high。
• draft_reply：简短、友好的首次回复，信息不足时指出缺失内容。

然后拿 20 条历史 issue 人工检查。这是作者建议的起步方法，原文没有报告实际准确率。它解决的是一个很基础的问题：模型到底能不能做好分类？单次调用都不稳定，加上循环只会增加排查难度。

工具循环很短，但每一次执行都需要边界

示例助手有三个工具：get_open_issues 读取 issue，add_labels 添加标签，save_draft_reply 保存回复草稿。

模型提出工具调用，程序执行，再把结果送回模型，如此循环。这段代码展示了这个过程：

def run_agent(client, system_prompt, task, tools, max_steps=10):
    messages = [
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": task},
    ]
    for _ in range(max_steps):
        response = client.chat(messages, tools=tool_schemas)
        if response.tool_calls:
            for call in response.tool_calls:
                result = tools[call.name](**call.arguments)
                messages.append(tool_message(call, result))
        else:
            return response.text  # Agent 判断任务已经完成
    raise RuntimeError("hit max_steps without finishing")

要看住的是 max_steps=10：模型没有正常结束，程序也必须停止。不过，它限制的是循环轮数；每轮可能执行多个工具调用，因此不能把它当成完整的费用上限。

这段代码还有明确的使用边界：tool_schemas、tool_message 没有定义，也没有展示如何把模型返回的工具调用消息加入历史。它说明了控制流程，没有交付可运行的 SDK 实现。

真正接入仓库之前，作者建议先给只读权限，回复只保存草稿，由维护者在队列里批准。add_labels 属于写操作，也应该放进权限逐步开放的范围。原文没有给出何时允许自动打标签的具体标准。

限制也不能只有最大轮数，还要有单次费用上限、超时，以及输入分类、工具风险评级、规则拦截和输出校验。通俗地讲，就是在输入、执行和结果几个位置分别检查，避免把所有可靠性都押在提示词上。

上线的难点，是让错误能被发现和复盘

作者用「循环占 10%，生产工作占另外 90%」强调工程投入。这是经验性表达，没有工时统计支撑，但后面的清单很实用。

首先是评估（Evals）。整理一批带正确标签的历史 issue，每次修改提示词都重新运行，并像代码一样管理提示词版本。前面的 20 条人工检查适合试水，持续评估则用来发现修改后的退步。

其次是调用轨迹（Traces）。每次模型调用和工具结果都要记录。凌晨 3 点出现错误分类时，只有最终标签，很难判断问题来自提示词、上下文还是工具返回值。

费用和延迟也要提前设预算。原文举例，单次分流花 40 美分，服务一个仓库或许可以接受，扩到 400 个仓库就得重新算账。这里同样没有真实账单，重点是提醒读者考虑规模。

部署链路则是 Webhook → queue → worker，结果持久化后等待审核。不要把整段 Agent 执行放在 Web 请求里：模型响应时间会占用请求窗口，容易触发超时。对于 Node 服务，这直接对应入口接收事件、后台 worker 处理任务的拆分。

我的判断

文章最有价值的地方，是把「模型能完成一次」和「系统能长期运行」分开了。权限、停止条件、回归评估和调用记录，都应该进入最初的实现范围。

但它没有证明这个例子需要自主 Agent。Issue 输入虽然复杂，处理路径却可能很固定。确定性代码负责读取和保存，模型只负责分类与起草，也是合理方案。原文没有给出它与自主循环在准确率、费用、延迟上的对照数据，所以「应该采用哪一种」仍需自己验证。

它也没有展开队列重试、重复事件处理、工具失败恢复等问题。因此，这是一份起步清单，距离完整的生产方案还有空白。

可以接受模型参与判断，但执行权限应由代码明确控制。

能拿来做什么

• 给仓库做分流助手时，先用 20 条历史 issue 检查 JSON 输出，尤其核对标签白名单、优先级枚举和信息不足时的回复，再决定是否接入工具。
• 用 Node 接收 GitHub Webhook 时，把模型任务交给队列和 worker，保存分类结果与回复草稿，提供维护者审核入口。
• 把提示词纳入版本管理，并保留模型调用与工具结果；每次改动都运行同一批历史样本，让分类退步能够被发现。
• 在引入自主循环前，先做一版固定工作流，比较两者的分类质量、费用和延迟，再决定额外的自主性是否值得保留。