# MatrixFlow 自动化工作室：完整资料 > 从任务单、执行顺序、选择器排障到独立核验与审计记录，系统讲解浏览器自动化怎样做得可检查、可恢复、可交接。 更新日期：2026-10-18 ## 从一句话到任务单：范围、顺序与成功标准 URL: https://automation.matrixflow.cn/guides/task-contract-and-sequence/ 摘要：先把“在哪做、做什么、何时算完成”写清楚，再让执行器采取行动。打开页面只是步骤，不等于完成任务。 ### 核心结论 - 任务单先写“在哪做、做什么、何时算完成”，再安排动作。 - 范围要列出具体环境、账号和数据边界，避免用“全部”代替清单。 - 完成标准必须能被页面或文件独立读取。 ### 先固定目标，再安排动作 “打开 1 到 9 号窗口处理订单”包含至少两个意思：选择九个环境，以及在每个环境完成某个业务目标。任务单应把两者分开记录。窗口编号必须来自当前环境列表；同名环境要用稳定标识区分。若用户只说平台名，应先确认平台、账号与店铺，不能把相似名称当成同一个目标。 把业务目标写成可检查的输出，例如“读取待发货订单，保留订单号、SKU、金额与状态，导出为 CSV”。同时注明只读还是允许修改。这样即使网页结构变化，执行过程仍围绕结果展开，而不会把“访问过订单页”当成已经交付订单数据。 ### 把范围与依赖写成明确列表 范围“1～9”应展开为 1、2、3、4、5、6、7、8、9，并在开始前展示总数。不要仅保留起点和终点。若范围里某个编号不存在，要报告缺项；不要悄悄缩小任务。“先在 14 号导出，再在 15 号汇总”还带有依赖，第二步需要等待第一步的文件与核验结果。 依次执行与并行执行是不同的合同。用户要求依次，就应保持原顺序；某一步失败后是否继续其他环境，也应预先约定。读取多个独立店铺可能适合并行，但同一账号的修改动作需要避免竞争。并行数应结合设备资源与平台限制设置，而不是越大越好。 - 列出每个目标环境及账号核对项。 - 为每一步写前置条件、交付物和停止条件。 - 将“先、再、然后、完成后”转成不可跳过的依赖。 ### 让完成有证据可看 成功标准要对应用户真正需要的结果：文件是否存在且字段齐全，草稿是否在列表中，页面读回的账号和订单是否匹配。长任务还应记录阶段与已完成环境，方便中断后接续。任务计划工具生成的是可审查模板，不会打开窗口或执行操作；实际运行能力需要在所使用的软件和目标网站中分别验证。 ### 把自然语言拆成不可含糊的执行项 执行前把每个动作转换为“环境—页面—动作—对象—权限—结果证据”。例如“在 14 号测试环境打开订单页，只读取订单号和状态；完成并核对后，才在 15 号环境读取同一范围”。这比只保留“帮我查订单”多了环境边界、先后依赖、禁止动作和完成证据。 范围词要原样展开：1 到 9 号产生 9 个目标；“所有待发货”需说明店铺、时间范围和分页；“以后做 B”意味着 A 的成功结果是 B 的前置条件。自然语言无法确定“第 2 号”对应多个同号环境时，先暂停并把候选名称列出来。 - 目标与对象：要处理哪条数据或页面。 - 顺序与依赖：前项未验收，后项不启动。 - 成功和停止条件：定义证据及需要交还人的状态。 ### 在第一步浏览器动作前做合同校验 将模型生成的步骤和任务合同逐项比较：目标环境是否完全一致、是否保留用户提到的顺序、是否少了窗口、是否把只读转成写入、是否扩大时间或商品范围。任何一项冲突都不能靠执行器“自行猜测”，应在零浏览器副作用的状态停止并修正计划。 执行过程中任务单是唯一权威范围。新出现的弹窗、账号切换提示或页面字段差异属于新信息，先更新观察和风险，不自动扩展授权。长任务每个环境完成后写入一个可恢复检查点。 - 开始前：合同目标数量与计划步骤数量相等。 - 每步后：记录环境、动作、页面证据和下一步。 ### 任务单生成器已验证什么，尚未验证什么 本站任务单生成器的本地函数在 2026 年 10 月 16 日通过了 4 项 Node.js 回归测试：1-9 会完整展开且保留顺序；中文分隔符和全角数字能规范化并去重；倒序、负数、超范围和不完整范围会被拒绝；目标、成功证据、执行顺序及时长字段会被校验。每次测试只验证输入到任务单 JSON 的转换。 复现命令：`node --test website-network/tests/tools.test.mjs`。任务单工具是本地表单与模板，不会启动 MatrixFlow 环境、访问网页、调用 DeepSeek、执行 Browser Use 或创建定时任务。通过这些单测不能证明真实自然语言规划、窗口识别或平台写入可靠；那些能力需要独立的端到端验收。 - 演示范围：最多 1000 个编号的确定性展开与表单校验。 - 未纳入：AI 意图理解、CDP 浏览器控制、真实网站状态与 Windows/macOS 集成。 - 这些边界应在产品页面和任务结果中明确展示。 ### 常见问题 **成功标准写“操作完成”可以吗？** 不可以。要写到可观察的结果，例如“读回 3 条订单，字段完整，编号保留前导零”。 **任务步骤越多越好吗？** 不是。步骤应覆盖目标与核验，无关动作会增加失败面；关键写入前后要有检查点。 ### 参考资料 - Playwright：断言与页面状态核验: https://playwright.dev/docs/test-assertions --- ## 为什么点击成功不等于发布成功：独立结果核验 URL: https://automation.matrixflow.cn/guides/independent-result-verification/ 摘要：执行日志能证明尝试过哪些动作；业务页面、结果记录或导出文件，才是判断任务是否完成的依据。 ### 核心结论 - 执行日志证明尝试过什么，业务页面或文件才证明结果发生。 - 提交前保留可核验线索，例如订单号、标题、目标账号和可见范围。 - 结果未知时先查，不要用重复提交碰运气。 ### 分别记录动作与业务结果 自动化点击了“发布”，只能证明点击动作完成。网络请求可能超时，平台可能校验失败，也可能进入审核。可靠的流程会把“提交已尝试”与“平台结果已读回”分成两个阶段。执行器说自己完成了，也不能替代独立观察，因为它可能只看到了按钮消失或跳转。 每种业务都应有自己的核验条件。社媒帖子可核对发布列表中的内容、账号、可见范围和平台状态；订单操作可核对订单号及新状态；导出任务则检查文件存在、可打开、字段完整和记录数量。用页面标题核验订单导出，证据就与目标不匹配。 ### 提交前保留核验线索 在点击最终提交前，先记录目标账号、业务对象、内容摘要和提交时间。发布内容不要包含虚构使用经历，测试时优先采用用户授权的草稿或合适的可见范围。核验应重新读取平台结果，而不是复用提交前的编辑框。必要时保存平台提供的内容链接或记录编号，便于后续追踪。 核验也有边界：列表缓存可能延迟，审核状态可能持续变化，平台可能没有稳定记录入口。此时应说明“已提交，结果待核验”或“结果未知”，并列出已经确认的事实。不能把暂时看不到记录当成提交失败，也不能仅凭没有错误提示就宣布成功。 - 核对账号、对象标识和内容，防止在错误环境读到相似记录。 - 区分草稿、提交成功、审核中与公开可见。 - 对文件检查实际内容，保留订单号与 SKU 的前导零。 ### 未知结果先查，不能盲目再发 点击发布后遇到断网，原请求可能已被服务器接收。直接重试可能生成两篇帖子。应先使用列表、记录详情或平台回执查找本次结果；确认未提交且具备安全条件后，才考虑再次尝试。缺少独立核验通道的写入任务，应在最终提交前停下并说明限制。这里介绍的是通用设计方法，不代表任何工具已经对所有平台实现了这些核验。 ### 分开判断动作、页面和业务结果 浏览器事件只回答“是否点击或输入”；页面状态回答“当前界面显示什么”；业务结果还要回答“指定记录是否真正建立或改变”。只读任务可用页面数据和覆盖条数验收；提交任务则要从独立列表、详情页、状态记录或导出文件读回目标字段。 验证条件应在执行前按动作设定。例如订单导出：核对文件存在、目标日期范围、条数与编号字段；发布草稿：核对草稿列表中出现目标标题与账号；正式提交：还要核对平台实际状态和可见范围。不能用模型自己复述或相同页面上的 toast 作为唯一证据。 - 已尝试：动作事件与时间。 - 已读回：业务记录、标识和最终状态。 - 未验证：明确列出缺少哪条证据。 ### 提交超时后先查状态，不直接重放 请求提交后如果浏览器断开，结果可能已经写入，也可能没有。此时先从记录列表、操作历史或业务标识查询是否有新记录，等待页面加载完成并排除缓存；确认“存在、未存在、无法判断”之一，再决定后续。无法判断就报告结果未知并交给用户，不重复创建同一笔交易、订单或公开内容。 可以读取的证据要带上核验时间与目标对象。若内容进入审核中或暂不可见，区分“提交受理”“审核中”和“公开可见”，避免把平台接收请求误报成已发布。 - 外部写入通常不具备客户端可见的幂等保证。 - 任何恢复步骤都先核验业务标识，再开始新提交。 ### 常见问题 **页面出现成功提示就够了吗？** 不够。提示可能只是请求被接收；应到列表、详情页或导出文件读回实际状态。 **核验发现不一致怎么办？** 记录差异与页面证据，停止后续写入，先判断是延迟、权限还是操作失败，再决定恢复方式。 ### 参考资料 - Playwright：自动等待与断言: https://playwright.dev/docs/test-assertions - MDN：幂等性: https://developer.mozilla.org/en-US/docs/Glossary/Idempotent - Playwright：自动等待与断言: https://playwright.dev/docs/actionability - RFC 9110：HTTP 方法与幂等性: https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods --- ## 重试不是再点一次：浏览器任务的安全恢复 URL: https://automation.matrixflow.cn/guides/safe-retries-and-idempotency/ 摘要：先判断失败发生在哪个阶段，再决定读取重试、核验恢复或暂停。重复提交不应成为默认恢复手段。 ### 核心结论 - 重试前先判断失败阶段，读取失败可重试，写入失败要先核验。 - 用订单号、标题等业务标识检查是否已经产生结果。 - 从检查点恢复，不要无条件从头重跑。 ### 先给失败分类型 网页任务失败可能来自网络中断、页面加载缓慢、按钮位置变化、登录失效或权限不足。相同错误文案不一定有相同原因。恢复前应记录目标环境、当前网址、最后一个确认成功的动作和错误信息，重新观察页面状态。页面已跳到登录入口时，继续尝试原来的发布按钮没有意义。 读取列表与提交订单的风险不同。对于已确认只读的页面观察，可以设置有限重试与逐步增加的等待时间；连续失败就暂停并报告。对于验证码、平台验证与权限不足，应交给有权限的人处理。不断刷新、换环境或重复点击，不会自动修复授权问题。 ### 用业务标识防止重复 幂等性描述的是相同操作执行多次，预期效果仍与执行一次相同。浏览器按钮本身通常不能证明这一点：再点一次“创建”可能新增一条记录。即使底层使用某种 HTTP 方法，也要根据平台实际行为判断，不能仅凭请求名称就承诺安全。 业务流程可以利用订单号、平台记录编号或服务端支持的幂等键来识别重复请求。只有平台明确支持且正确实现时，幂等键才有相应作用。纯网页自动化不能凭空给平台增加这项能力；在缺少机制时，应通过提交前查重、提交后读回和未知结果暂停来降低重复风险。 - 把读取、填写、最终提交、结果核验分开记录。 - 为每次业务操作保留唯一任务标识与目标对象。 - 同一业务对象存在未确认提交时，阻止新的重复提交。 ### 从检查点恢复，而非从头重跑 任务涉及九个环境时，前四个已完成，第五个中断，不应默认重做前四个。恢复时先核验检查点仍有效，再处理尚未完成的部分。已填写但未提交的内容可能丢失，需要重新观察；已提交但未核验的任务则先查结果。日志应标明“等待重试”“需人工处理”“结果未知”，让用户看懂为什么停止以及下一步是什么。以上流程仍需要针对具体网站验收，不能用重试次数代替成功证据。 ### 用阶段状态决定恢复动作 把一项任务拆为准备、观察、填写、提交、读回五个阶段。准备或读取失败通常可在页面状态稳定后重新观察；填写失败要先检查字段当前值；提交阶段断线必须转为“结果未知”；读回失败可以重试读取，但不能因此重新提交。 任务账本应保存目标业务标识、最后一个成功阶段、提交前后时间、错误信息和验证来源。恢复时先读取浏览器当前页和业务页面现状，再从最早一个尚未确认的阶段继续。仅靠“之前完成到第 4 步”的索引不能证明第 4 步没有产生外部效果。 - 可安全重试：只读定位、刷新非破坏性数据、打开详情。 - 需先核验：创建、发布、付款、发货、退款、删除。 - 需要人工：验证码、身份确认、授权不明。 ### 区分 HTTP 幂等与页面业务语义 HTTP 标准中幂等描述重复执行同一个请求对服务器预期效果的语义；网页按钮背后的业务逻辑未必遵守这种语义。再次点“创建”“发布”有可能生成第二条记录，所以不能从按钮文案或网络请求方法推断安全可重试。只有平台明确提供幂等键或可查询的稳定业务标识，且集成逻辑已验证，才可以设计自动恢复。 回归测试应注入超时、进程退出与页面刷新，检查结果未知状态是否被保留、用户是否看到暂停原因，以及重新进入后是否先做读回核验。 - 不确定副作用时，停止写入比重复点击更安全。 - 记录平台返回的交易号、草稿 ID 或任务 ID（如存在）。 ### 常见问题 **网络超时可以直接重试吗？** 先查结果。请求可能已经到达平台；发布、付款、提交类操作尤其不能盲目重试。 **什么是幂等操作？** 执行一次和多次结果一致的操作，例如只读查询；写入操作通常需要业务标识去重。 ### 参考资料 - MDN：HTTP 方法与幂等性: https://developer.mozilla.org/en-US/docs/Glossary/Idempotent - RFC 9110：HTTP 幂等方法: https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods --- ## 本地定时任务：睡眠、错过执行与检查点 URL: https://automation.matrixflow.cn/guides/local-scheduling-and-checkpoints/ 摘要：本地排期依赖设备与应用运行条件。提前约定时区、错过执行策略和恢复检查，才能避免重复或过时操作。 ### 核心结论 - 创建排期与立即执行是两件事，排期成功不代表任务会准点运行。 - 本地定时依赖设备、应用和网络，睡眠或退出会错过触发。 - 长任务要保存进度与检查点，恢复前先确认上次结果。 ### 创建排期与现在执行是两件事 “两分钟后在 24 号环境浏览五分钟”包含触发时间与执行时长。创建排期时应保存任务单，展示具体触发日期、时区、目标环境和时长，不应马上打开环境并把排期当作完成。触发时再检查环境、账号与权限，符合条件才进入执行阶段。 日期需要明确解释。“明早九点”应显示换算后的具体日期与当地时区；跨时区团队要约定以哪一处时间为准。重复任务还需要清楚写出频率、开始日期与结束条件。不要只保存“每天”这类无法审查的文字，也不要将业务持续五分钟误解为每五分钟触发一次。 ### 设备睡眠后，不保证准点触发 本地任务通常要求电脑开机、应用可运行，并具备目标网站所需的网络连接。电脑关机或休眠时，不能把准点执行当成必然。即使网页标签仍打开，后台页面计时也可能受到浏览器节流影响；普通页面计时器不适合承担可靠排期。实际产品应说明自己使用的调度机制与系统条件。 恢复后如何处理错过的任务，需要事先选择：跳过并提示、在有效时间内补跑，或等待人工确认。读取昨天的数据可能允许补跑；已经过期的促销发布或订单修改，不能仅因恢复联网就自动执行。多次错过的重复排期也不应无条件堆积为大量补跑。 - 保存计划触发时间与实际开始时间，便于区分延迟和失败。 - 为任务设置有效期、允许延迟与最大补跑次数。 - 恢复前核对账号、页面状态及尚未确认的提交。 ### 长任务保存可核验的进度 检查点应包含已完成环境、已取得的输出、当前阶段和最后核验时间。重启恢复时，先确认这些结果仍可用，再接着运行。取消也应留下明确状态，防止后台任务继续提交。用户看到的进度应描述具体动作与对象，例如“正在读取 14 号环境订单列表”，而不是持续显示“执行操作”。本文提供调度设计原则；是否支持休眠恢复、取消与持久化，需要在实际软件和操作系统上逐项验证。 ### 先规定错过时点后的处理规则 排期字段至少包括任务、环境、时区、下次执行时间、重复规则、电脑需要保持唤醒还是可以睡眠、错过执行是跳过还是补跑、最大补跑次数。遇到夏令时的地区，应选择时区名而不是只存 UTC 偏移；界面应展示换算后的下一次本地时间供用户核对。 本地应用在关机或睡眠时通常无法按计划与网络任务一致运行。恢复后根据业务时效判断：读取日报可以补跑，过时的促销或过期价格更新可能应跳过并请求确认。不要把“补跑所有错过任务”设为通用默认值。 - 周期任务：同一时间不能启动重复的上一轮。 - 超时任务：记录停止阶段和副作用不确定性。 - 手动取消：保存取消时间与已完成范围。 ### 检查点要能支撑重启恢复 对 20 个环境的逐个读取任务，检查点可以记录已确认完成的环境 ID 列表、当前环境、各自读取条数、失败原因和下一项；不能只记“已处理 15/20”。重启后先核对列表和已完成证据，再决定从第一个未确认环境继续。 对于发布、发货或资料更新等写任务，检查点还需记录提交尝试和独立读回状态。提交尝试存在但读回缺失时应标为未知，不把环境重新排入待执行队列。 - 检查点应原子保存，损坏时保留上一个有效版本。 - 恢复后向用户显示继续位置、跳过项与需要处理项。 ### 常见问题 **到点没执行怎么办？** 先看设备状态、应用日志和检查点，再决定补跑；写入任务必须先确认上次是否已经生效。 **时区要写吗？** 要。跨地区团队应明确排期使用哪个时区，并记录实际触发时间。 ### 参考资料 - MDN：页面可见性与后台计时限制: https://developer.mozilla.org/en-US/docs/Web/API/Page_Visibility_API --- ## 页面一改，任务就断：选择器漂移怎么排查 URL: https://automation.matrixflow.cn/guides/selector-drift/ 摘要：选择器漂移是页面结构、文案或加载顺序变化导致元素定位失败。排查应先确认页面是否真到了目标状态，再检查定位策略是否依赖易变属性；修复后要用失败样本复测，而不是只跑一次成功就结束。 ### 核心结论 - 元素找不到时先确认页面状态，不要立刻归因于选择器。 - 避免依赖随机 class、深层 nth-child 和易变文案，优先使用角色、标签和稳定语义。 - 修复后用原来的失败样本复测，并增加状态断言，而不是只加 sleep。 ### 先确认失败在哪一层 只有先排除前四层，才能判断是不是选择器问题。很多“选择器失效”其实是登录过期、页面没加载完或权限不足。 - 导航层：页面是否打开了正确的 URL，是否被重定向到登录页。 - 会话层：账号是否仍然登录，是否出现验证码或权限提示。 - 加载层：目标区域是否已经渲染，是否还在骨架屏或加载状态。 - 元素层：元素是否存在、可见、可点击，是否被弹窗遮挡。 - 业务层：按钮存在但操作被平台拒绝，可能是权限或状态不满足。 ### 四类常见漂移 第一类是结构变化：新增包裹层、调整列表顺序、把元素移到弹窗或 iframe 中。第二类是属性变化：class 名带构建哈希、id 每次渲染都不同。第三类是文案变化：按钮从“提交”改成“确认发布”，按文本定位就失效。第四类是动态渲染：页面根据实验分组或加载顺序渲染不同结构。 这些变化不一定意味着页面“坏了”。自动化需要接受页面会演进，定位策略应尽量依赖稳定的语义和结构，而不是某次截图里的偶然细节。 ### 更稳的定位策略 定位策略没有永远正确的答案。稳定性和可读性要平衡：过于宽泛的定位可能点错元素，过于精确的定位又容易随页面变化失效。 - 优先使用可访问性角色、标签、名称等语义定位。 - 在目标元素附近找稳定锚点，再按相对关系定位。 - 避免使用随机 class、绝对路径和过深的 nth-child。 - 等待元素可见、可用或特定文本出现，而不是固定睡眠。 - 对关键页面保留结构快照或失败截图，便于对比。 ### 修复后怎么验证 用最初失败的样本复测，而不是只跑一个新页面。增加状态断言：操作前确认页面处于预期状态，操作后确认目标结果出现。对关键写入，读回页面或记录状态，确认动作真的生效。 如果同一页面频繁变化，考虑把定位集中管理、增加可观测性，或把不稳定步骤交给人工。不要用不断增加 sleep 和重试来掩盖结构问题。 ### 什么时候停止自动化 停止自动化不是失败，而是把风险放回可控位置。一个能明确报告“这步需要人处理”的任务，比一个不断猜测、重复提交的任务更可靠。 - 页面频繁改版，没有稳定语义锚点。 - 关键操作依赖验证码、人工审批或动态权限。 - 失败后无法判断是否已经产生结果。 - 平台规则明确限制自动化操作。 - 维护成本已经高于人工处理成本。 ### 常见问题 **加长等待时间能解决选择器问题吗？** 只能缓解加载慢，不能解决结构或文案变化。应等待明确状态，并在失败时报告页面实际状态。 **为什么昨天还能跑，今天就不行？** 常见原因是页面改版、实验分组、登录过期、权限变化或接口返回不同。先保存失败页面证据，再逐层排查。 **应该用 XPath 还是 CSS 选择器？** 两者都可能脆弱。更重要的是依赖稳定语义和状态断言；在复杂结构中，可读性和可维护性比选择器类型更关键。 ### 参考资料 - Playwright：定位器: https://playwright.dev/docs/locators - Playwright：可操作性检查: https://playwright.dev/docs/actionability - MDN：文档对象模型（DOM）: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model --- ## AI Agent 与 RPA：谁负责理解，谁负责执行 URL: https://automation.matrixflow.cn/guides/agent-vs-rpa/ 摘要：固定脚本和 RPA 适合结构稳定、步骤明确的流程；AI Agent 适合需要理解页面、处理自然语言目标或应对一定变化的场景。关键写入不应由“理解”直接变成“执行”，而要在执行前后加入确定性核验与人工接管点。 ### 核心结论 - 稳定、重复、结构固定的流程优先用确定性脚本、RPA 或 API。 - 需要理解页面和自然语言目标时再评估 Agent，并保留人工接管点。 - 混合架构更可靠：Agent 规划，确定性步骤执行，独立核验判定结果。 ### 三种执行方式 三者不是替代关系，而是不同层次的工具。能走 API 时优先 API；页面结构稳定时用确定性脚本；只有任务需要理解、判断或自然语言交互时，才需要 Agent。 - API：最稳定、字段明确，但受平台开放范围和权限限制。 - 确定性脚本 / RPA：按固定步骤执行，适合结构稳定、规则清晰的页面。 - AI Agent：理解自然语言目标，规划步骤，能应对一定页面变化，但不确定性更高。 ### 选择依据 高风险写入不应完全依赖理解能力。即使使用 Agent，也应把关键步骤拆成确定性动作，并在提交前后读回结果。 - 输入是否稳定：字段、页面和流程是否长期一致。 - 页面是否多变：改版频率、实验分组、动态渲染。 - 写入风险：只读、草稿、发布、付款、删除。 - 任务规模：单次、批量、多环境、定时。 - 审计要求：是否需要每步可解释、可回放。 ### 混合架构 一个实用的结构是：Agent 负责理解目标、选择环境和规划步骤；确定性执行器负责点击、填写、读取等具体动作；独立核验器负责读回页面、文件或记录；遇到验证码、权限不足或结果未知时，交给人处理。 这种结构把“理解”和“执行”分开，既能利用 Agent 的灵活性，又能保留可解释性和可测试性。它也便于定位失败：是理解错了、执行失败，还是结果没生效。 ### 怎样做对比测试 一个方案快但经常静默失败，不如一个稍慢但能明确报告结果的方案。评估时要看总成本，而不是单次执行时间。 - 使用同一组任务、相同账号、相同数据范围和相同时间窗口。 - 比较成功率、平均耗时、异常可解释性和人工介入次数。 - 统计核验成本：是否需要额外读回、对账或补数据。 - 记录失败样本，而不是只看成功案例。 - 在真实业务页面上测试，而不是只跑演示站。 ### 常见误区 工具选择应服务于业务目标。先明确任务的成功证据和风险边界，再决定由谁执行、如何核验。 - “用了 Agent 就不需要规则”——关键写入仍需要边界和核验。 - “RPA 不需要理解页面”——固定脚本同样需要状态断言和异常处理。 - “API 一定更好”——API 可能缺字段、限权限或延迟高。 - “成功率 100% 就是可靠”——没有失败样本，可能只是测试太简单。 ### 常见问题 **AI Agent 会取代 RPA 吗？** 短期内不会完全取代。RPA 在稳定流程上更可控、更便宜；Agent 适合需要理解和适应的任务。两者更可能混合使用。 **小团队应该选哪种？** 从稳定、只读、低风险的任务开始。能用现成 API 就用 API；需要页面操作时先用确定性流程，确实需要理解能力再引入 Agent。 **怎样判断 Agent 是否可靠？** 看它在失败样本上的表现：能否报告失败、能否说明原因、能否停止而不是乱试。成功案例多不代表异常处理可靠。 ### 参考资料 - Playwright：浏览器上下文: https://playwright.dev/docs/browser-contexts - W3C：WebDriver 规范: https://www.w3.org/TR/webdriver2/ - MatrixFlow 官方网站: https://matrixflow.cn/ --- ## 多环境任务队列：并发、限流与失败隔离 URL: https://automation.matrixflow.cn/guides/task-queue-multi-env/ 摘要：多环境任务不是“把窗口都打开一起跑”。队列应先按账号、数据源和写入目标划分独立性，再设置并发上限与限流；一个环境失败不应拖垮整批，取消和重试也要有明确边界。 ### 核心结论 - 先判断任务是否独立，再决定能否并行。 - 队列要有并发上限、限流、失败隔离、取消和结果汇总。 - 写入类任务失败后先核验，不要自动把整批重跑。 ### 先判断能不能并行 并行不是默认选项。两个任务如果操作不同账号、读取不同数据、写入不同记录，才可能独立并行；如果它们共享同一个后台数据源、同一份库存、同一个订单或同一条内容，就可能互相覆盖或重复提交。 还要考虑平台限流和本地资源。二十个环境同时启动可能让 CPU、内存、网络和浏览器进程成为瓶颈，反而降低成功率。 ### 队列的基本结构 队列的价值不只是“批量跑”，而是让每个环境的执行状态可见。最终报告应逐环境列出结果，而不是只给一个总数。 - 任务：环境、目标、范围、成功证据和停止条件。 - 状态：排队、运行、成功、失败、待核验、已取消。 - 尝试次数：记录第几次执行、失败原因和是否允许重试。 - 证据：页面读回值、文件路径、行数、截图或日志。 - 汇总：每个环境的结果和整批的异常清单。 ### 并发与限流 并发上限应通过测试确定，而不是拍脑袋。可以从低并发开始，逐步增加，观察成功率、耗时、平台错误和本机资源。遇到限流时使用退避和抖动，避免所有任务在同一秒重试。 限流不仅是请求频率，也包括页面操作节奏。短时间大量点击、翻页或提交可能触发平台风控，也会让页面来不及响应。 ### 失败隔离 失败隔离不等于忽略失败。队列应把异常集中呈现，并标明哪些结果可以继续使用、哪些必须人工处理。 - 单个环境失败时，记录原因并继续其他独立环境。 - 共享依赖失败时，暂停相关任务，避免连锁错误。 - 写入失败标记为待核验，不自动重试。 - 整批结束后输出成功、失败、未执行和待核验四类结果。 ### 取消与恢复 取消操作要有明确语义：是停止排队任务，还是中断正在执行的动作，还是只停止后续步骤？已经提交的写入可能无法撤销，取消后仍需核验。 恢复时从检查点开始，不要默认从头重跑。记录每个环境已完成到哪一步，尤其是导出、提交和发布等关键节点。 ### 常见问题 **多环境任务可以全部并行吗？** 只有在任务彼此独立、资源允许且平台限流可接受时才可以。共享数据或写入同一目标的任务应串行或加锁。 **一个环境失败要不要整批停下？** 取决于依赖关系。独立环境可以继续并记录失败；共享依赖失败时应暂停相关任务，避免扩大错误。 **队列重试几次合适？** 没有固定次数。只读任务可以有限重试；写入任务必须先核验上次结果，确认未生效后才考虑重试。 ### 参考资料 - Playwright：浏览器上下文隔离: https://playwright.dev/docs/browser-contexts - Google SRE：处理过载: https://sre.google/sre-book/handling-overload/ - MatrixFlow 官方网站: https://matrixflow.cn/ --- ## 审计记录：让每次自动操作都能回放 URL: https://automation.matrixflow.cn/guides/audit-trail/ 摘要：审计记录不是堆日志，而是能回答“谁在哪个环境做了什么、结果如何、是否重试过”。最小记录应包含任务标识、环境、账号、目标 URL、每步状态、结果证据、异常与人工接管；敏感信息要脱敏。 ### 核心结论 - 审计记录要回答谁、在哪个环境、做了什么、结果如何。 - 记录步骤状态、结果证据、异常、重试原因和人工接管。 - 日志要脱敏并设定保留期，不能保存密码、令牌和完整买家信息。 ### 审计记录回答四个问题 如果日志只能看到“任务完成”，它无法帮助复盘，也无法判断是否安全重试。审计记录的目标是让另一个人能还原过程。 - 谁：哪个执行者、哪个团队成员、哪个任务。 - 哪里：哪个环境、哪个平台账号、哪个目标 URL。 - 做了什么：哪些步骤、修改了哪些字段、提交了什么。 - 结果如何：页面读回值、文件行数、状态、异常和是否重试。 ### 最小字段 字段不必一开始就很全，但关键写入必须有前后状态。只读任务可以简化，但仍应记录范围和结果。 - 任务 ID、开始与结束时间、执行者。 - 环境名称、平台、账号别名、目标 URL。 - 每一步的动作、状态、耗时和错误信息。 - 结果证据：页面标题、表格行数、文件路径、可见范围。 - 重试次数、重试原因、人工接管记录。 - 敏感字段的脱敏标记。 ### 证据怎么保存 页面证据应包含 URL、读取时间和实际值；截图要遮盖个人信息、订单数据和浏览器工具栏。文件证据应包含文件名、行数、生成时间和哈希（如需要）。 证据不是越多越好。保存与结论直接相关的字段，能让复核者快速判断；堆积大量无关截图反而增加隐私风险和查找成本。 ### 敏感信息与保留期 日志中不要保存密码、Cookie、API 令牌、完整手机号、地址和支付信息。确实需要排查时，使用脱敏后的字段或受控的临时记录，并在排查结束后删除。 保留期按业务和合规要求设定。过长会增加泄露风险，过短会影响复盘。至少覆盖任务周期和可能的复查窗口。 ### 用审计记录做复盘 审计记录最终服务于改进。如果每次复盘都只能得出“再试一次”，说明记录还不够具体。 - 统计失败类型：登录、权限、选择器、加载、提交未知。 - 找出重复失败的环境或步骤，优先修复。 - 比较重试前后的结果，判断重试是否安全。 - 在交接时附上最近一次任务的审计摘要。 - 定期抽查日志完整性，而不是等出事才看。 ### 常见问题 **审计日志需要保存截图吗？** 关键失败可以保存脱敏截图，但不是每步都需要。优先保存可读的状态值和 URL，截图作为补充证据。 **日志里能记录账号密码吗？** 不能。密码、令牌和完整个人信息不应进入日志；需要关联账号时使用别名或内部 ID。 **日志保留多久合适？** 按业务周期、合规要求和隐私风险决定。至少覆盖任务复查窗口，过期后按策略删除或归档。 ### 参考资料 - NIST：日志管理指南: https://csrc.nist.gov/pubs/sp/800/92/final - MatrixFlow 官方网站: https://matrixflow.cn/ - Playwright：跟踪与调试: https://playwright.dev/docs/trace-viewer --- ## 本站常见问题 **点击成功为什么不等于任务完成？** 点击只是输入动作。页面可能没有提交、提交后报错、权限不足或实际记录未产生。必须读回页面或文件状态，才能确认任务完成。 **自动化任务的最小要素是什么？** 目标、环境、步骤顺序、成功证据和停止条件。缺一不可，尤其是“怎样算完成”和“什么情况下必须停下来”。 **页面改版后任务失败怎么办？** 先记录失败步骤、页面文字和截图，再检查选择器、元素文本与加载时机。不要直接反复重试，尤其是发布、提交、付款等写入动作。 **什么时候可以重试？** 只有确认上次未生效，或操作本身幂等时才适合重试。涉及发布、支付、订单提交时，先到结果页或列表核对，再决定是否重试。 **AI Agent 和 RPA 怎么选？** 固定、稳定、重复的流程适合确定性脚本或 RPA；页面变化多、需要理解与规划的任务适合 Agent。关键写入无论用哪种方式都要独立核验。 **多环境能并行吗？** 只有任务彼此独立、资源允许、平台限流可接受时才适合并行。共享账号、写同一份数据或依赖同一后台记录的任务不应并行。 **定时任务错过执行怎么办？** 先检查检查点和上次执行结果，再决定是否补跑。写入类任务不能因为“到点了没跑”就直接重复执行。 **审计日志要记什么？** 时间、环境、账号、目标 URL、步骤、结果证据、异常、重试原因和人工接管记录。日志要能回答“谁在哪个环境做了什么，结果如何”。