自动化测试用例设计核心：从两层过滤法到Pytest+Playwright实践
2026/10/12 5:44:31
目录
1 理论依据：官方架构区分
2 对比表
3 Skill 的优势场景（正因为非强制）
4 什么时候必须用强制工作流
5 混合架构：实践中的主流答案
1 理论依据：官方架构区分
Anthropic《Building Effective Agents》（2024-12，页面现为 "Building Effective AI Agents"，顶部已加注工具环境变化提示）给出了本轮讨论的权威框架，原文经逐字核对：
"Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."
以及选型建议：
"workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale."
"…we recommend finding the simplest solution possible, and only increasing complexity when needed."
Skill 在该框架中的位置：它是给"模型自主指挥"的那一类系统（agents）供给知识与规程的载体，本身继承 agents 的非强制属性；当可预测性压倒一切时，官方的答案从来不是"把 skill 写得更凶"，而是退回 workflow/脚本。
2 对比表
维度 | Skill（建议式知识包） | 强制工作流（Workflow） |
|---|---|---|
触发者 | 模型按描述自主匹配（或用户显式触发） | 开发者预定义路径，代码/平台触发 |
执行保证 | 无运行时强制，遵从度取决于模型与指令质量 | 平台/代码保证步骤必然执行 |
可预测性 | 概率性（同任务不同轮可能路径不同） | 确定性、可重放、可审计 |
覆盖的任务形态 | 路径无法预先穷举的开放/长尾任务 | 步骤事先完全已知的结构化任务 |
维护成本 | 改 Markdown 即可，业务专家可参与 | 改代码/流程图，需工程排期 |
上下文成本 | 渐进加载，启动仅约 100 token/技能 | 每次执行走完整路径（但无需占常驻上下文） |
失败模式 | 不触发、误触发、跳步骤 | 路径之外的情形直接失败（需人工兜底） |
典型代表 | Anthropic/OpenAI/Google/AWS 的 Agent Skills | Dify Workflow、Coze 工作流、Bedrock action group、SAP Joule 预定义操作、Rasa CALM flows |
3 Skill 的优势场景（正因为非强制）
长尾与开放任务：咨询式分析、代码审查、文档撰写、调研——步骤组合依赖具体情境，"open field"型任务（官方类比），写死流程反而制造脆性；
跨域能力组合：一次任务中模型可按需叠加多个技能（如"Excel 处理 + 公司品牌规范 + 财务口径"），组合数是技能数的幂级，工作流不可能为每种组合预编排；
知识沉淀的低成本通道：专家把经验写成 Markdown 即可"教"给全组织所有 agent，无需工程介入；改动是文档级而非发布级；
探索期业务：流程尚未稳定的场景，先以 skill 沉淀最佳实践，等流程收敛、合规要求明确后，把成熟部分"降档"为脚本或迁入工作流——skill 成为从探索到固化的过渡形态；
人机协作的弹性：同一 skill 既可被模型自主调用，也可被用户斜杠显式调用（如 Manus 以显式为主），用户可在"放权"与"收权"之间按风险滑动。
4 什么时候必须用强制工作流
合规与审计要求"每一步可重放、可追责"的链路（金融交易、工单闭环、数据出域审批）；
高危操作（删库、批量外发、支付）——应脚本化/工作流化并加人工审批节点；
SLA 敏感的确定性管线（ETL、报表生成、系统对接）——Bedrock action group、SAP 预定义操作、Dify workflow 的领地；
官方最佳实践的原话值得再引一次："Clear steps prevent Claude from skipping critical validation"——反过来说明：只要步骤由模型执行，就存在跳过的可能，关键校验不能只存在于 SKILL.md 文字里。
5 混合架构：实践中的主流答案
调研到的成熟实现几乎都是混合体，而非二选一：
Skill 内部分层（官方三档自由度设计）：同一 SKILL.md 中，脆弱步骤写成低自由度脚本，开放环节保留文字指导；
模型选、平台跑（第二代语义的合理内核）：SAP Joule / ServiceNow / Salesforce 都是"LLM 负责选择与参数填充，平台保证执行"——这是企业级最稳妥的折中；
工作流内嵌 agent / skill 供知识：Coze 把工作流放进技能；Rasa 让 LLM 在预定义 flows 间路由；Dify 的 Agent 节点调用工具与子工作流；
官方工程博客对 Skill 与 MCP 的分工表述可推广为通用心法："Skills can complement MCP servers by teaching agents more complex workflows that involve external tools"——连接与执行交给协议/工作流（硬），方法与判断交给技能（软）。社区将其概括为 "methodology versus connectivity"（方法学 vs 连接性）。