1. 为什么最近总有人念叨自动化该退休了先说结论我不认为自动化退休了但我确实认为纯脚本驱动的自动化正在从舞台中央挪到后台做支撑。过去大半时间我们把自动化这三个字等同于一件事人怎么点脚本就怎么点人怎么填脚本就怎么填。这条路我们走了十几年从Selenium 到 Appium从接口自动化到持续集成流水线能自动化的基本都自动化了。问题是当业务迭代速度超过脚本维护速度时账就算不平了。我带的项目里有个很典型的现象一个两百条用例的接口自动化套件季度维护工时能吃掉一个专职人力的一半。UI 自动化更夸张前端一改版一半定位符全废。这不是团队能力问题是范式问题——确定性脚本处理不了非确定性的输入。智能体这一波进入视野本质不是更聪明的脚本而是一次架构层面的重新分工机器不再只负责执行它开始接手判断和规划。你在热词里能看到的那些词——接口自动化、自动化测试框架、智能体编排、coze 智能体、dify 智能体平台、多智能体——其实描述的是同一条迁徙路径上不同的落脚点。这篇东西写给谁看两类人。一类是做测试、做运维、做 CI/CD 的工程同学你们手里已经有大量自动化资产想知道怎么平滑升级另一类是做智能体开发、桌面端软件、数据管道的同学你们想搞明白智能体到底该塞在架构的哪一层别一上来就堆功能。我尽量不聊虚的把为什么这么选怎么落地哪里会翻车掰开说。2. 自动化的天花板到底卡在哪换个说法讲清楚2.1 确定性脚本的三重脆性先明确一件事传统自动化的核心假设是输入可枚举路径可预设输出可断言。这三条只要有一条不成立脚本就开始抖。第一重是定位脆性。UI 自动化里最经典的问题就是你写//div[classbtn-primary]第二天产品改成了btn-primary-v2脚本直接挂。Appium、Selenium、Playwright 都提供了更稳的定位策略比如用 role、用 test-id、用 accessibility 标签但根本上还是提前猜好元素长什么样。第二重是数据脆性。接口自动化里测试数据往往要靠上游准备。上游数据变了断言就错。你可能遇到过这种情况接口返回里加了一个traceId字段你写的是全量字段比对结果整套用例全红。所以现在接口断言规范越来越强调结构化断言白名单断言Schema 校验其实就是在给脆性打补丁。第三重是路径脆性。业务流程一旦出现分支——比如如果优惠券可用走 A 流程否则走 B 流程脚本就得写 if-else。分支多了脚本会变成一个巨大的状态机改一处怕动全身。这三重脆性叠加起来就形成了维护成本的指数曲线脚本数量线性增长维护成本指数增长。这就是为什么很多团队做了几年自动化覆盖率没涨人力却越投越多。2.2 智能体带来的质变不是速度是分工很多人第一反应是智能体是不是跑得更快。恰恰相反单次执行上智能体通常更慢因为它要调用模型、要思考、要重试。它真正改变的是分工结构。我用一个类比。传统自动化像是一条固定传送带你把原料放上去它按固定轨道走完。智能体更像是请了一个会看图纸的工人你给他目标他自己决定先拧哪颗螺丝。传送带快但只能处理一种原料工人慢但能应付好几种活。具体到架构上智能体带来了三个质变从执行到决策脚本执行指令智能体选择指令。它可以自己决定这个元素找不到那我换一种定位策略试试。从预设到规划脚本的路径是人写死的智能体的路径是运行时生成的可以基于当前页面状态动态拼装。从无记忆到有记忆脚本失败就是失败下次还失败。智能体可以把失败案例存进知识库下次遇到类似情况直接复用经验。多智能体更进一步把决策拆给不同的角色一个负责规划、一个负责执行、一个负责校验。听起来复杂但其实是把过去一个巨型脚本里的隐性逻辑显性化了。2.3 一个正在发生的边界案例举个我自己的经历。做接口自动化的时候最头疼的不是写用例是写断言。同一份接口业务方希望断言宽松点别老误报测试方希望断言严格点别漏 bug。折中方案是维护一套字段白名单。用了智能体做校验之后思路变了。我让模型读接口的 OpenAPI 文档让它自己判断哪些字段是必须校验的哪些字段是允许漂移的。第一版准确率一般但把它的判断结果存下来做人工复核几轮之后准确率就上来了。这个过程里人从写每一条断言变成了审每一类断言工作量结构完全不一样。这就是我说的范式跃迁不是把旧活干得更快是把旧的活拆成新的活的组合。接口自动化、自动化测试框架、测试框架这些概念不会消失它们会变成智能体手里的工具箱。3. 范式跃迁的架构底座别一上来就堆智能3.1 四层结构分层比堆功能重要我见过的失败案例里八成死于把所有东西塞进一个 prompt。正确做法是先分层。一套能跑起来的智能体自动化架构我一般拆成四层层级职责典型组件感知层把世界转成智能体能读的输入DOM 解析、接口 Schema、截图 OCR、日志聚合决策层规划、选工具、判断成功与否大模型、提示词、工具定义、规划策略执行层真正动手干活的Playwright、Appium、requests、Shell、Jenkins API记忆层存经验、存上下文向量库、结构化日志、失败案例库四层各管各的好处是替换成本低。比如你从 coze 智能体平台迁到自建换的只是决策层执行层 Playwright 一行不用动。3.2 编排是灵魂但要选对场景热词里出现频率很高的两个词是智能体编排和SaaS 智能体编排平台。编排这件事本质是决定谁在什么条件下调用谁。我按复杂度做了个粗略对照你对照自己的场景挑场景编排方案理由单任务、流程固定直接用 Function Calling别过度设计多步骤、有分支LangGraph 这类状态图显式状态好调试团队协作、要可视化dify 智能体平台、coze 智能体上手快非工程同学也能改强定制、有私有模型自建编排 私有推理服务数据和成本可控我的经验是先用最简单的跑通闭环再按痛点升级。一上来就上多智能体大概率是给自己挖坑因为你连单智能体的失败模式都还没摸清。3.3 工具选型看的是可观测而不是功能多选执行层工具时新手容易被功能表吸引。我看的是三件事能不能稳定复现、能不能被抓取中间状态、出错时能不能拿到足够上下文。Playwright 在这三点上做得不错日志和 trace 都在,这也是它这两年热度上来的原因。Appium 在移动端依然是主力autojs 这类方案在特定场景有奇效但维护性一般得有心理准备。CI 侧的选择相对成熟Jenkins 自动化部署和 gitlab ci/cd 中 docker 镜像构建与自动化部署这套组合已经是很成熟的工程实践。智能体接进来之后它更多是触发器和结果校验器的角色智能体跑完一轮把结果推给流水线流水线决定要不要发版。4. 从零搭一个智能体驱动的自动化闭环4.1 环境与依赖准备我按最小可用版本给别一次装太多库。python -m venv venv source venv/bin/activate pip install playwright pytest pytest-asyncio playwright install chromium pip install openai chromadb pydantic装完先别急着写智能体先把纯脚本跑通。这一步的目的是拿到基线的执行能力智能体只是在这之上加决策。我见过有人跳过这步直接让模型去调 Playwright结果连环境问题都定位不到。注意chromadb 这类向量库在本地跑没问题但生产环境要考虑持久化和并发。小规模先本地超过几万条再考虑独立部署。4.2 感知层把 UI 和接口压缩成模型能读的形态这一步是关键也是坑最多的地方。原始 DOM 动辄几万个节点直接塞给模型又贵又不准。我的做法是做一层压缩只保留可交互元素且只保留关键属性。# 把页面压缩成可读的元素列表 async def snapshot(page): items [] for el in await page.query_selector_all([data-testid], button, a, input): items.append({ id: await el.get_attribute(data-testid), role: await el.get_attribute(role), text: (await el.inner_text())[:30], }) return items这里有个实操心得优先给元素加>def summarize_api(schema: dict) - str: required schema.get(required, []) return f必须字段: {required}4.3 决策层工具定义决定智能体的上限智能体能不能干活八成看工具定义写得清不清楚。工具不是越多越好是语义越明确越好。我把每个工具写成什么时候用它和用了会返回什么两段话。tools [ { name: click_element, description: 在当前页面点击指定元素。当目标元素已在页面上可见时使用。返回是否点击成功。, parameters: {testid: 元素标识} }, { name: fill_input, description: 向输入框填写内容。若输入框不可见应先返回失败并说明原因。, parameters: {testid: 元素标识, value: 待填内容} } ]描述里明确什么时候用非常重要。模型最大的问题不是不会用工具是在错误的时机用了对的工具。4.4 执行层与记忆层把失败变成资产执行层我建议保持薄就是纯执行、不做判断。判断全在决策层。好处是执行层可以单独做单元测试稳定得像普通工具库。记忆层是我最想强调的部分。每次失败把当前状态 模型决策 实际结果存下来下次遇到类似状态先检索。这套机制能把重复失败率显著降低。def remember(case_id, state, decision, result): collection.add( documents[f{state} | {decision}], metadatas[{case_id: case_id, success: result}] )4.5 参数计算与成本控制这块容易被忽略。一次智能体调用大概分三笔成本模型 token、执行时间、重试次数。我按最坏情况估。假设单步平均 1500 token一次任务 8 步重试系数 1.5那么单次任务 token 约 18000。按常见的输入输出价格你要控制的是压缩输入和减少步数。压缩输入靠 4.2 的摘要减少步数靠把常用动作封装成高级工具比如登录这件事别让模型分五步点直接封一个login(user, pwd)。提示给每个任务设步数上限超过就强制停止并记录。这能防住最常见的模型无限循环问题。5. 落地过程中最容易翻车的几类问题5.1 常见问题速查表现象可能原因处理思路智能体反复点同一个元素成功判断缺失给每个动作加返回值校验定位失败率高元素没有稳定标识补>