GitHub Agentic Workflows可以把Markdown描述的仓库任务放进GitHub Actions执行。对于第一次尝试，Issue分诊是一个容易检查边界的场景：读报告、整理证据、给出分类建议，再由维护者决定是否回复、打标签或修改代码。
本文用四条原创虚构Issue演示完整分诊方法，并提供可下载练习。这里交付的是任务设计与审核工作表，没有在真实仓库启动Agent，也不把人工填写的示例说成模型运行结果。
正式版发布后，先核对当前文档
10月28日官方公告确认GitHub Agentic Workflows正式可用。搜索结果里仍可能看到早期原型和预览说明，具体实现应查当前文档，避免混用不同时期的配置。
需要分清三个产物：Markdown任务描述、编译后供Actions使用的工作流，以及某次运行留下的结果。第一份描述写得清楚，不代表每次分类都准确；一次回答正确，也不能证明它在重复事件、缺资料或异常工具下仍然可靠。
先把目标压缩成“准备分诊建议”，会比直接要求“把所有Issue处理完”更容易验收。输出建议与发布建议，是两件应该分别检查的事。
写清楚输入、输出和停止条件
假设仓库是一个小型图形编辑器。维护者只需要五项结果：主要分类、支持证据、缺失信息、下一步建议，以及可供审核的回复草稿。不允许自行推断浏览器版本，不把用户语气当紧急程度，也不能虚构复现过程。
可以这样写任务约定：
根据给定Issue和指定仓库说明，整理分类、原文证据、待补信息及建议回复。证据不足时明确标记“需要信息”。只准备提案，由维护者决定是否公开回复或修改仓库状态。
这是原创任务简报，不是可直接执行的YAML。需要自动发评论、打标签或提PR时，应另画输出步骤，注明允许动作、复核人和触发条件。
另一个容易忽略的细节是“何时停下来”。缺资料、工具失败、预算达到上限，都应允许返回一个诚实的不完整结果：已经确认什么、还不知道什么、需要谁补充什么。不要让“继续调查”成为没有终点的回路。
四条Issue怎样分诊
下载分诊练习和填写表。以下问题都是作者编写的练习材料。
| 编号 | 已给信息 | 建议分类 | 下一步 |
|---|---|---|---|
| A：导出按钮像是没反应 | 只写浏览器，没有文档和操作步骤 | 需要信息 | 索取最小文档和准确步骤 |
| B：复制流程时保留分支标签 | 给出期待行为和现有绕行办法 | 功能请求 | 核对标签需要怎样关联 |
| C：怎么移动一组图形 | 明确是使用提问 | 使用问题 | 提供相关操作说明 |
| D：一个很小的文件导入失败 | 有最小样例与准确报错 | 缺陷候选 | 在隔离环境复现 |
A不能直接写成“已确认导出回归”。按钮被禁用、下载被拦截、特定文档损坏，都是待核查的可能性。回复应当提问，而不是把问题列表改写成结论。
D虽然证据更完整，也只适合进入复现阶段。确认原因、评估修复范围、检查其他导入路径之后，才有资格讨论代码修改。C则不应因为Agent会改代码，就被升级为开发任务。
把建议和写入仓库的动作画开
主线可以画成：接收事件→读取Issue→检查证据→分类→准备建议→维护者审核。证据不足单独分到补资料；回复、标签、代码修改都放在审核之后，作为不同动作。
打开Agentic工作流架构模板，把通用节点换成上述步骤，补上维护者角色和结束条件。特别保留“准备回复”和“发布回复”两个节点，这样任何人看图都能找到仓库写操作。
作者示例：先核对关系，再按自己的任务修改模板。
这个入口只帮助你修改任务结构，不连接GitHub、不运行工作流。若还不清楚失败分支怎么设计，可先看Agentic Workflow完整案例，其中把同一个资料任务走过成功、缺输入、工具失败和预算停止四条路径。
从流程图进入配置实现
实施时从当前官方入门文档开始，按实际安装版本选择支持的引擎、权限和输出方式。查看编译生成文件时，应像审核其他构建产物一样核对变更：事件会在什么时候触发、读取什么、允许输出什么、由谁负责。
先填一份实现工作表：
触发：练习仓库中选定的Issue事件
输入：标题、正文和明确指定的仓库指导
读取：收集证据，不修改仓库
判断：分类与缺信息原因
输出：可审核分诊提案
复核：仓库维护者
停止：提案完成、输入缺失、工具失败或预算达到上限
不要把这段工作表当作Actions配置粘贴执行。真正运行还需要官方Schema、编译检查、凭据设置和行为验收。本文没有进行这些步骤，也没有提供“已经验证可运行”的配置。
适合第一次实作的环境，是只放练习材料的可丢弃测试仓库。编译通过只能说明配置兼容，不能证明分类正确，更不能替代对实际副作用的检查。
分开检查判断质量和动作边界
四条Issue每条可检查四项：分类是否有依据、证据有没有写错、下一步是否合适、是否遵守只提案的范围。这构成16项检查，不是已经测得的模型分数。
例如，A的回答即使礼貌地询问更多信息，只要同时写了“确认是下载故障”，证据项仍不通过。C如果顺手修改代码，即使改动看起来合理，动作边界也不通过。把这些项分开，才不会被一段流畅回复掩盖问题。
以后做真实运行，应保留输入、任务版本、配置差异、输出和实际仓库变化。只读最终回复不够：它可能写得很谨慎，却已经改了标签。还要测试同一事件重复到达时，是否产生两条公开回复；用Issue编号、事件版本或其他合适键识别重复工作，需要在实现阶段明确设计。
容易踩的四个坑
把Issue正文当指令。 用户贴来的内容可能要求忽略规则或泄露信息，它仍是待分析材料，不会自动成为工作流权限。图上和简报里都要分清“任务规则来自哪里”和“证据来自哪里”。
觉得标签没有副作用。 标签可能触发其他自动化，或改变哪些维护者会看到问题。允许自动打标签前，要查清下游行为，不能只看当前一步。
把编译成功等同于可以上线。 配置检查、行为检查、成本边界和责任人是不同验收项。分别记录，避免一句“已验证”造成误解。
不允许返回未完成。 缺证据时诚实停止，比为了交差编出原因更有用。让输出包含阻碍、已经尝试的步骤和后续需要的信息。
为一条建议留下决定记录
以B为例，把期待行为与当前绕行办法分别保留。现有绕行不说明有多少人需要功能；还要问复制后的标签应关联新分支、原分支还是都不关联，这会改变验收条件。
记录建议分类、维护者接受分类、分歧理由、后续负责人和是否发布。分类变化时保留新旧值，不悄悄重写原建议。私有工作表、公开评论和标签面向不同读者，准备对外回复时只问缺的信息，不把内部评分表整段发给提问者。
换成自己的仓库场景
把四条练习换成公开或已授权的问题，先独立写预期判断，再与运行结果比较。给分类分歧安排负责复核的人；新增输出能力时同步修改流程图。
进一步可读Claude Skills、工具与MCP的区别和上下文工程资料筛选案例。前者帮助组织可复用规则，后者帮助判断一次具体任务该拿到哪些证据。
