一个公共图书馆准备更新活动预约系统。维护者周一要诊断失败的提交检查，周五要核对下周的活动是否都能预约，月底还要清理测试用的技能目录。三件事都可以交给 Agent 协助，但它们需要不同的输入、权限和输出。先用这三条任务做路由验收，再开放自动调用，比从技能名字猜用途更容易定位问题。
开发任务：让证据决定第一步
遇到“周五的活动页面坏了”这类描述，先问坏在哪一步。用户可以附提交编号、浏览器环境、报错文字和预期结果。只有提交检查失败时，先读对应作业的日志，区分依赖安装、构建、测试和上传制品阶段。先保留失败任务的名称和最短复现命令，再决定需不需要浏览器。日志不可访问时把它列为缺失输入，避免凭工单标题重写页面。
如果报告说能打开页面却无法选择场次，就把任务分给浏览器验收步骤。关联的 Webapp Testing 可用于在测试环境重放预约操作，保留操作步骤、页面反馈和截图。准备一条开放场次和一条满员场次，用测试账号验证按钮状态和错误反馈。浏览器看到的成功消息与后台预约记录应一一对应，后台记录由有权限的维护者核对。交付物是一张带证据的复现单，包含入口、数据、动作、预期和实际结果。
遇到既有构建告警又有线上反馈时，可以并行收集两类证据。分别给子任务输入范围与截止条件，再让主流程按版本号归并。若日志对应新版而截图来自旧版，保留两份证据并要求用同一版本复现。先确认它们是否指向同一故障，再合并修复请求。
重复任务：用样例把自动化边界跑通
每周检查活动预约时，先写出输入和结果。输入是上一次检查通过的活动清单、本周活动草稿以及测试站地址。清单需要活动编号、开放时间、报名规则和预期状态。结果应列出通过项、失败项、跳过原因和发现问题的页面，方便运营同事在排期前逐一确认。先选三条样例：普通开放、报名尚未开始、名额已满。样例的预期由活动负责人签字确认。
把动作排成四段：读取活动清单，按规则生成待验证场景，用 Webapp Testing 运行测试页面，按活动编号整理结果。读取与整理可以由普通脚本完成，浏览器技能在第三段处理点击、等待页面状态与记录证据。若测试站使用不同的时区，先准备恰好在开放时间前后各一分钟的场景，检查页面与活动清单是否采用同一时间基准。对无法自动判定的条目，标为待人工核对并保留测试时间。
第一次用手动触发运行，先确认同一份输入重复执行能得到同一组结果。若必须创建测试预约，为每次运行加唯一标识，核对重跑能清理旧数据或复用原记录。进入定时流程后，把版本、输入批次和每步状态写进运行记录。失败时停在产生证据的节点，复跑该节点前确认输入版本。发送通知和写入正式站点各设独立步骤，检查对应权限后再开放。
技能管理：先选择，再按需读取
为每项已批准的技能维护一张简表，写上任务类别、接受的输入、运行前提、产物和明确的排除条件。以 Webapp Testing 为例，可以写“有可访问的测试 URL，需要通过浏览器复现交互，并能提供安全的测试数据”。排除条件可以写“只需查构建日志”“没有测试账号且场景要求登录”。目录里也写清楚谁负责更新定义，升级后由谁复跑基准用例。
按 Agent Skills 的按需加载思路，先让路由器看技能名称和描述。选中后再打开完整的操作说明，真正需要截图或测试数据模板时再读对应文件。加载说明、启动工具和写入业务系统是三个不同动作，分别记录是否发生。匹配不到时给出缺少的前提，提供人工处理选项。目录外发现的新技能可以进入待评估清单，评估通过后才加入可自动选择的集合。
一次路由评审怎么做
准备六条测试输入：两条准确指向已装技能，两条只靠关键词看起来相关，一条同时包含两个独立目标，一条缺少必要输入。比如“登录后活动卡片无按钮”应要求测试站和账号，而“把活动卡片的按钮描述写进周报”应交给文档步骤。对于“查昨晚构建失败，同时确认满员样例仍显示候补”，输出中应分别列出日志检查和浏览器检查的产物。每条测试输入记录预期路径、实际路径、最终产物与是否出现额外的工具调用。
评审发现误触发时，先判断缺的是输入约束、权限检查还是输出定义。若名称相似的两个技能都被选中，写一条可观察的判别条件，例如“必须操作浏览器”或“只处理 CI 日志”。调整后把同类反例和一条本来正确的样例一起复跑。只在看到反例回到正确路径且原本正常的任务仍通过时更新规则。部署后可按周抽样检查跳过项与误选项，让后续改动有依据。
故障排查与常见问题
技能选对了，页面还是打不开怎么办？
先从同一运行环境打开测试地址，核对服务是否启动、测试数据是否加载，以及账号能否访问该路由。记录是超时、登录跳转还是服务报错。若环境不具备前提，将步骤标为待复测并附环境问题，避免把结果当成页面业务失败。
能否一次调用多个技能？
可以让独立读取任务并行，比如收集构建日志和查看测试站状态。修改同一测试数据的步骤应约定执行顺序和清理责任。合并输出时用任务编号与输入版本核对每项结果，缺失分支单独列出。等各分支都有证据后再写最终结论。
明确指定了技能还需要路由吗？
可以优先检查指定技能能否满足任务。比如指定浏览器验收但只给了工单标题，下一步是索取可访问的测试页面与预期结果。显式指定给出了偏好，仍需要检查运行环境、输入是否齐全和操作权限。这样同一套验收规则也能覆盖手动调用。
上线前核对调度结果
在活动上线前安排一次无写入演练。把“下周一的绘本活动还能报名吗”作为输入，同时准备一场名字相同但活动编号不同的旧活动。正确流程应根据日期和活动编号读取目标记录，只检查这条记录的预约页面。若两场活动都符合输入，流程应在匹配阶段停下，请求选择具体场次。运营同事拿到的结果应保留两条候选及各自的日期，便于核实选择。
另一条演练把正式站的地址误填到测试参数里。运行器在发起预约之前应核对域名与环境标识，并在运行记录里说明阻断发生在哪一步。修正配置后，从上一次有效的输入清单开始跑。核对新运行编号、浏览器日志与测试预约数量，确认两次运行的证据不会混在同一个目录。还可以模拟一次清单读取成功但页面服务不可用，验证报告能区分已完成的数据准备与尚待执行的浏览器检查。
交接时，把样例、路由结果与操作记录放在同一份交付清单里。指定负责确认异常的同事，并给出重跑所需的活动清单版本和测试环境。下一轮增加新技能时，从同一组输入里抽取相关样例复测，比较选择理由、执行步骤和产物是否仍符合维护者的预期。