动态工作流推导:基于 agent-skill-stack 为每个请求定制 Skill 组合流程

发布时间:2026/9/12 15:39:52
动态工作流推导:基于 agent-skill-stack 为每个请求定制 Skill 组合流程 动态工作流推导基于 agent-skill-stack 为每个请求定制 Skill 组合流程【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot导读本文讲解 awesome-copilot 仓库中 agent-skill-stack 技能的核心方法——动态工作流推导Dynamic workflow derivation。它解决的核心问题是面对学一个平台发布一次内容每周运营账号给创作者做工具这类表面相似、本质各异的请求如何摒弃固定模板从用户的最终结果出发逐级反向推导出最小可用流程。读完本文你将掌握反向推导、形状识别、步骤拆分与停止规则、内部能力卡capability card以及充分性检查这五套可落地的方法论并能将它与仓库内的索引、路由、安全安装脚本串联成完整闭环。为什么不能用领域生命周期当模板文档在 workflow-model.md 开篇就给出了反模板规则Anti-template rule不要从research - create - publish - analyze这类领域生命周期起步而应从用户的最终结果和当前起点出发只添加这个结果真正需要的中间条件。这条规则背后的直接原因是领域词具有强误导性。两个都包含 publish 的请求一个是手动发布一次文章另一个是每周定时自动发布它们的访问边界、权限、频率、审批点完全不同。把二者归入同一套模板要么流程冗余要么遗漏关键审批。仓库的 skill_index.py 从检索侧印证了同样的设计哲学搜索匹配按input - operation - output的能力签名打分direct_tokens用户原话中的词权重是扩展词的四倍且明确声明检索分数只是召回提示不是质量或安装分数。也就是说同一领域词在不同上下文里应被路由到不同的能力而不是落到同一个模板上。反向推导、正向验证五步提问法文档给出了推导的具体操作——在内部连续自问五个问题什么可观察的结果会让用户说这件事做完了在这个结果出现之前必须成立的条件是什么什么输入、决策、权限或转换使该条件成为可能重复第 3 步直到回到用户已经拥有或可以提供的东西。正向走一遍确认每个步骤的输出恰好是下一步的输入。关键约束是不要向用户问每一个内部问题。只有当不同答案会改变技术栈、成本、权限或交付物时才值得提问。这与 SKILL.md 第 2 步的规定一致——只问那些会实质改变结果、访问边界、成本或技能栈的问题。在仓库实现中这个反向到起点、正向验证的模型体现在 project_profile.py 的路由解析上路由被强制写成intentprimary[,helper]的形式主技能和辅助技能都必须从--skill声明的活跃集合中显式选取否则直接报错。这从代码层面保证了每个意图都有唯一主技能、辅助技能只在特定交接点出现防止推导出无法落地的流程。识别形状而非挑选模板文档要求对请求独立推断七个属性而不是套用现成阶段列表一次性 or 周期性one-off / recurring创建、决策、转换、协调 or 监控仅本地、外部读取 or 外部写入人主导、Agent 辅助 or 全自动单系统 or 多系统可回滚 or 难以撤销出错后果低 or 高。这些属性直接决定分解粒度。例如外部写入 难以撤销意味着必须插入审批步骤而仅本地读取 可回滚则不需要。有趣的是仓库中 inventory_skills.py 的RISK_PATTERNS正是这七个属性的自动化镜像它对每个 Skill 扫描destructive-command如rm -rf、shutil.rmtree、credential-or-secret-access如.ssh、api_key、network-or-download、external-mutation-languagepublish/send/upload/delete及中文发布/发送/上传/删除等八类风险模式。你推导出的访问边界在落地审查阶段会由这些正则逐条核对形成从设计到验证的闭环。拆分与停止规则需要拆分一个步骤的触发条件包含两个可独立替换的动作同时包含读取和外部写入涉及不同账号或权限既有审批决策又有审批后的动作输出对应不同的成功条件高风险动作与安全动作混在一起。停止拆分的标准一个非技术用户能理解的单一动作一个主要结果一个访问或副作用边界一个可观察的成功条件。停止规则的代码级印证见 stage_install.py它把安装强制拆为预览与执行两个不可合并的阶段——--apply与--record-existing互斥任何已存在的目标路径都会直接终止refusing to overwrite existing destinations并用临时 staging 目录先拷贝校验、再原子替换。这正是审批决策与审批后的动作分离高风险动作与安全动作分离两条拆分规则的工程实例。内部能力卡一个步骤一张卡每个推导出的步骤在内部表示为一张能力卡goal: user-visible result # 用户可见的结果 input: what is available before the step # 步骤开始前已有什么 operation: one normalized action # 一个规范化动作 output: what the step produces # 步骤产生什么 constraints: [] # 约束 frequency: one-off|recurring|event-driven # 频率 access: local|read-external|write-external # 访问边界 approval: none|before-access|before-spend|before-external-write # 审批点 success: observable pass condition # 可观察的通过条件 fallback: alternative when unavailable # 不可用时的替代方案 predecessors: [] # 前驱步骤 successors: [] # 后继步骤卡中的approval字段与文档的提问纪律严格对应——只有before-access访问前、before-spend花钱前、before-external-write外部写入前三种审批点值得暴露给用户。对新手用户同一张卡只呈现为一句白话例如先用已有资料确认需求再生成可审核的结果只有你确认后才会写入外部系统。仓库中 discovery-ranking.md 的Internal trust record是这张能力卡在候选验证阶段的延伸二者字段一一呼应identity、capability、external_actions、approval语义完全对齐。能力卡管流程设计信任记录管候选筛选中间由input - operation - output签名对接。横切需求只考虑真正相关的辅助能力对每个推导出的步骤只考虑下面表格中实际相关的横切需求而不是全部套用需求内部自问可能的能力术语质量/风格结果是否需要特定语气或润色humanizer、brand voice、proofreading准确性未经核实的事实或数字会造成伤害吗fact check、grounded research、citation verification合规性是否适用平台、版权、广告或行业规则compliance、policy audit、copyright隐私/安全是否涉及私有数据、Cookie、密钥或账号secret handling、PII redaction、permission audit本地化语言、术语或文化是否需要适配localization、translation QA数据质量记录会重复或格式不一致吗dedupe、validation、schema mapping协调是否需要交接、排期、重试或审批workflow、scheduler、human approval可见性失败或结果是否需要被观测logging、analytics、monitoring文档强调按能力签名匹配辅助工具一个把粗糙草稿改写成自然行文的 Skill可以支持任何写作类结果即使它的名字里完全没有用户的领域词。这正是 skill_index.py 中QUERY_EXPANSIONS的设计动机——用户说去ai味/自然一点索引自动扩展出humanizer/writing/rewrite/tone等能力词用户说合规/版权扩展出compliance/policy/legal。检索绕过了表层领域词直接命中底层操作类型。充分性检查流程何时算够细文档给出的终止判据当每个必需步骤都同时满足以下五点流程即为充分有明确结果至少有一个有意义的搜索表述有访问与审批分类有是/否形式的成功条件有明确理由选择使用已有 Skill / 新建 Skill / 其他工具 / 无需额外能力。此外还有一条自我防御规则如果推导出的流程与某个先例可疑地相似丢弃它从当前结果重新推导。这防止了反模板规则被绕过——模板会以经验复刻的形式悄悄回流。这条检查在仓库里有双重呼应一是 local-index-and-profiles.md 要求改配置后重建本地索引并重跑召回检查二是 SKILL.md 第 10 步定义的召回检查recall check——用直接说法、自然改写、辅助性说法三种表述各测一次确认主技能与辅助技能被正确选中、无关技能不被误召入最终只对用户报告一句3/3 种说法都能正确识别。完整闭环推导只是第一步动态工作流推导并非孤立的方法论它是 agent-skill-stack 十步流程的第 2 步。推导出的步骤随后依次进入本地索引检索skill_index.py 的build/search子命令索引只存元数据、不执行 Skill、不存使用历史四透镜搜索与加权排名discovery-ranking.md社区采用度占 25% 权重冲突分析与安全审查security-installation.md 的八类冲突模型与十步分级安装分阶段安装stage_install.py 先预览后--apply项目级路由固化project_profile.py 写入project/.codex/skill-stack.json召回检查收尾。整套工具链的定位是给一个端到端的自然语言目标装配最小兼容的 Skill 集合。而这一切的起点就是本文讲解的动态工作流推导——从结果反推条件、按形状而非模板分解、用能力卡约束边界、以充分性检查收口。掌握了它你就掌握了为每个请求定制流程而不是为流程套用请求的核心能力。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询