1. 项目概述当AI遇见自动化Auto-Wing如何重塑工作流最近和几个做自动化测试和运维的朋友聊天大家普遍有个感觉传统的自动化脚本和工具越来越“笨”了。写一个Selenium脚本去抓取网页数据页面结构一变脚本就报错维护成本高得吓人。搭建一个n8n工作流流程逻辑稍微复杂一点配置起来就让人头大。我们好像一直在用确定性的代码去应对充满不确定性的现实世界。这正是“Auto-Wing”这个项目概念吸引我的地方。它不是一个具体的、已发布的软件而是一个极具前瞻性的技术构想将当前最前沿的AI能力尤其是大语言模型LLM和智能体Agent技术深度融入到自动化项目的全生命周期中。简单说就是让AI成为自动化项目的“副驾驶”甚至“领航员”从项目构思、代码生成、异常处理到流程优化提供全方位的智能辅助。这听起来可能有点抽象但结合我这些年踩过的坑它的价值立刻就清晰了它要解决的是自动化领域最核心的痛点——脆弱性和高门槛。一个传统的UI自动化测试脚本其逻辑是僵化的点击A元素在B输入框填入数据检查C位置的文本。一旦A元素ID变了或者B输入框被一个弹窗遮挡脚本就“瞎”了只会机械地报错。而一个融合了AI的Auto-Wing式方案其逻辑可能是动态的通过计算机视觉“看懂”屏幕用自然语言理解“读懂”需求“找到那个蓝色的登录按钮并点击”甚至在元素定位失败时能尝试推理页面的新结构“这个按钮可能移到了导航栏右侧”并自我修复。这不仅仅是“自动化”更是“自适应自动化”。从网络上的热议也能看出端倪。大家讨论的已不再是Selenium、Appium、Playwright这些基础框架怎么用而是AI Agent、Spring AI、CursorAI编程工具、以及如何用大模型生成测试用例、辅助代码编写。这标志着行业焦点正在从“如何实现自动化”转向“如何实现更智能、更健壮的自动化”。Auto-Wing正是这一趋势的集大成者设想。它适合所有被重复性、规则性工作所困扰的开发者、测试工程师和运维人员无论是想用Python搞定办公自动化还是用Java构建复杂的接口自动化平台都能从中获得启发找到提升效率与可靠性的新路径。2. Auto-Wing的核心设计思路从“硬编码”到“软智能”传统的自动化项目其核心是“硬编码”的逻辑。无论是用PythonSelenium模拟用户操作还是用n8n通过节点拖拽设计业务流程其执行路径和判断条件都是预先严格定义好的。这种模式的优点在于执行速度快、结果确定但缺点也极其明显环境适应性差、维护成本高、无法处理预期外场景。Auto-Wing的设计思路是引入一个“软智能”层作为传统自动化引擎的“大脑”。这个大脑由AI大模型驱动负责处理不确定性、进行推理决策、并动态调整执行策略。整个系统的架构可以理解为一种“感知-思考-执行”的强化循环而非单一的“执行”链条。2.1 分层架构协同工作的智能体生态一个完整的Auto-Wing式系统我认为应该包含以下几个关键层次任务理解与规划层AI Planner这是项目的起点。用户可以用自然语言描述需求“每晚从公司内部论坛抓取关于项目‘星辰’的所有新帖子保存标题、作者和链接到Excel如果有紧急反馈词则给我发邮件。”传统方式下我们需要手动拆解成登录、翻页、解析HTML、判断关键词、操作Excel、配置邮件等步骤。而AI规划器能自动将这段描述分解为一系列可执行的原子任务Task并生成一个初步的工作流图。这大大降低了自动化项目的启动门槛产品经理甚至业务人员都能直接提出自动化需求。代码/脚本生成层Code Generator规划层产出的是抽象任务这一层负责将其转化为可运行的具体代码。这里不是简单的模板填充而是基于对上下文的理解进行生成。例如任务“从网页example.com/data提取表格”生成器需要判断这个页面是静态还是动态渲染用requestsBeautifulSoup还是Selenium表格是否有分页它会调用大模型的代码能力生成适配当前场景的最佳实践代码片段。像Cursor、GitHub Copilot这类AI编程工具可以看作是这一层的雏形。动态执行与协调层Orchestrator Agent这是系统的中枢神经。它负责调度和执行生成的代码或预制组件如Selenium驱动浏览器、Requests发送API请求。更重要的是它管理着一个或多个智能体Agent。这些智能体具备特定技能Skill如“网页导航专家”、“API调试助手”、“数据清洗专员”。协调器根据任务类型召唤相应的智能体去执行并在遇到障碍时组织智能体们“会诊”。例如一个“元素查找失败”的异常会触发“视觉定位Agent”尝试通过图像匹配找回元素同时“页面结构分析Agent”会检查DOM是否有更新。异常感知与自愈层Exception Handler这是体现“软智能”的关键。传统自动化遇到异常就停止日志里留下一串冰冷的错误堆栈。AI增强的异常处理器会做更多事分类与诊断判断异常是网络超时、元素消失、还是业务逻辑错误如登录失败。意图理解与重试理解当前任务的核心意图“是为了获取登录后的数据”并尝试替代方案。比如密码登录失败是否可切换验证码登录按钮A找不到功能相同的按钮B是否可用策略生成与学习将成功的处理经验形成新的“应对策略”存入知识库下次遇到类似问题可直接调用实现系统的持续进化。结果验证与优化层Validator Optimizer执行完成后AI可以对结果进行智能验证。不仅是“有数据”更是“数据是否正确、完整”。例如抓取的价格列表是否出现了0或负数这种异常值它还能分析整个执行过程的日志提出优化建议“步骤3和步骤5可以合并减少一次页面刷新预计提升20%效率。”这个分层架构的核心思想是将人的经验与判断力逐步沉淀为AI可理解和运用的策略与模式让自动化系统从只能执行“死命令”的工具进化成能够应对“活场景”的智能伙伴。2.2 关键技术选型为什么是LLM与Agent为什么Auto-Wing的“大脑”要基于大语言模型LLM和智能体Agent这背后有深刻的技术逻辑。LLM世界知识的压缩与推理引擎像GPT-4、Claude、国内的一些大模型它们本质上是海量代码、文档和网页知识的压缩体。这意味着它们“见过”无数种网页结构、API响应格式、错误信息和编程模式。当我们的自动化脚本遇到一个从未见过的错误弹窗时LLM可以基于其“记忆”推测出这个弹窗的可能含义以及关闭它的方法比如点击“确认”或查找“x”图标这是传统基于规则匹配的方法无法做到的。它提供的是一种泛化能力。Agent具身化的技能与执行单元LLM虽然知识渊博但它是“虚无”的无法直接操作浏览器、发送网络请求。智能体Agent就是LLM的“手和脚”。一个典型的Agent架构包含思考Think基于LLM分析当前状态和目标。行动Act调用一个具体的工具Tool如click_element(selector),call_api(url)。观察Observe获取行动结果成功/失败返回数据。 通过“思考-行动-观察”的循环Agent可以完成一个复杂任务。在Auto-Wing中我们会设计多种专职Agent比如WebNavigationAgent专门处理网页交互DataExtractionAgent专注于数据解析它们各司其职由协调器统一调度。工具调用Function Calling这是连接LLM的“思考”与Agent“行动”的关键桥梁。我们需要将所有的自动化能力Selenium命令、数据库查询、文件操作等封装成带有清晰描述的函数并告诉LLM这些函数的功能。当LLM认为需要执行某个操作时它会输出结构化信息要求调用某个函数及其参数。例如LLM输出{“action”: “click_element”, “args”: {“selector”: “button.submit”}}协调器便会执行相应的点击操作。注意完全依赖一个“通用全能AI”来驱动整个自动化是不切实际的成本高、速度慢、且不稳定。Auto-Wing的务实思路是“LLM for决策传统代码 for 执行”。让LLM处理需要理解、推理和创新的部分规划、诊断、策略生成而将高频、稳定、耗时的具体操作元素定位、数据提取、网络请求交给优化过的传统代码或轻量级模型。这是一种高效的混合智能Hybrid AI架构。3. 实战构建一个AI增强的网页数据抓取Agent理论说得再多不如动手实践。我们来构建一个简化版的Auto-Wing核心模块一个能理解自然语言指令并自动完成网页数据抓取的智能体。这个例子将串联起任务理解、代码生成动态决策和执行协调。项目目标创建一个智能体用户输入“帮我抓取豆瓣电影Top250的电影名称、评分和链接”它能够自动完成从打开浏览器、翻页、解析数据到保存的全过程并在遇到页面改版等异常时尝试自我修复。3.1 环境准备与核心工具链我们选择Python作为实现语言因为它拥有最丰富的AI和自动化生态。# 核心依赖 pip install openai # 或 vllm, qwen-client等用于调用大模型API pip install selenium webdriver-manager # 用于浏览器自动化 pip install beautifulsoup4 pandas # 用于数据解析和保存 pip install langchain # 优秀的Agent开发框架提供大量工具和模板这里重点说一下LangChain。它不是一个模型而是一个框架它帮我们解决了Agent开发中很多繁琐的问题工具Tools的标准化定义、记忆Memory的管理、各种大模型API的兼容调用等。使用它能让我们更专注于业务逻辑而不是底层通信。模型选择对于此类任务我们不需要GPT-4级别的顶级模型那样成本太高。GPT-3.5-Turbo、Claude Haiku或国内一些性能较好的开源/闭源模型如DeepSeek、通义千问完全足够。关键是要开启函数调用Function Calling能力。3.2 定义智能体的“技能工具箱”智能体强大于其工具。我们需要把自动化操作封装成LLM能理解的工具。from langchain.tools import tool from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC import pandas as pd import time # 初始化浏览器驱动使用webdriver-manager自动管理 from webdriver_manager.chrome import ChromeDriverManager from selenium.webdriver.chrome.service import Service service Service(ChromeDriverManager().install()) driver webdriver.Chrome(serviceservice) tool def navigate_to_url(url: str): 导航到指定的网页地址。 driver.get(url) return f已成功导航至{url} tool def extract_data_with_css(selector: str, attribute: str None): 使用CSS选择器从当前页面提取数据。 Args: selector: CSS选择器用于定位元素。 attribute: 要提取的属性如href, innerText默认为None则提取元素文本。 try: elements driver.find_elements(By.CSS_SELECTOR, selector) if not elements: return f未找到匹配选择器 {selector} 的元素。 if attribute: data [el.get_attribute(attribute) for el in elements] else: data [el.text for el in elements] return data except Exception as e: return f提取数据时出错{str(e)} tool def find_and_click_element(selector: str, by: str By.CSS_SELECTOR): 查找并点击一个元素。by参数可以是 By.CSS_SELECTOR, By.ID, By.XPATH等。 try: element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((by, selector)) ) element.click() return f已成功点击元素{selector} except Exception as e: return f点击元素失败{str(e)}。可能需要尝试其他定位方式。 tool def save_to_csv(data_dict: dict, filename: str): 将字典数据保存为CSV文件。字典的键将成为列名。 df pd.DataFrame(data_dict) df.to_csv(filename, indexFalse, encodingutf-8-sig) return f数据已保存至{filename} tool def get_page_source(): 获取当前页面的完整HTML源代码。 return driver.page_source实操心得在定义工具时描述Docstring至关重要。LLM完全依赖这些描述来理解何时以及如何使用该工具。描述要清晰说明功能、参数含义和返回值。find_and_click_element工具中加入了by参数就是为了让LLM在CSS选择器失效时可以尝试换用XPath或ID等其他定位方式这是实现“自适应”的基础。3.3 构建智能体连接大脑与手脚接下来我们用LangChain将这些工具和LLM组装成一个智能体。from langchain.agents import AgentExecutor, create_openai_functions_agent from langchain_openai import ChatOpenAI from langchain.prompts import ChatPromptTemplate, MessagesPlaceholder from langchain.memory import ConversationBufferMemory # 1. 初始化LLM请替换为你的API密钥和Base URL llm ChatOpenAI( modelgpt-3.5-turbo, temperature0, # 设置为0使输出更确定、更可靠 openai_api_keyyour-api-key, openai_api_basehttps://api.openai.com/v1 # 若使用其他服务商需修改 ) # 2. 准备工具列表 tools [navigate_to_url, extract_data_with_css, find_and_click_element, save_to_csv, get_page_source] # 3. 设计系统提示词System Prompt这是智能体的“人格”和“行为准则” system_prompt 你是一个专业的网页数据抓取自动化助手。你的目标是理解用户的请求并利用你拥有的工具一步步地、可靠地完成任务。 你拥有操作浏览器、提取数据、保存文件的能力。 请遵循以下原则 1. **规划先行**在行动前先思考整体步骤。例如抓取多页数据需要循环。 2. **稳健操作**每次操作后检查是否成功。如果失败如元素找不到分析原因并尝试备用方案如换一种定位方式或等待片刻。 3. **数据验证**提取数据后简单检查其是否合理如是否为空列表格式是否符合预期。 4. **主动沟通**在关键步骤或遇到困难时用简洁的语言向用户汇报当前状态。 现在开始处理用户的请求吧。 prompt ChatPromptTemplate.from_messages([ (system, system_prompt), MessagesPlaceholder(variable_namechat_history), (human, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) # 4. 创建记忆让Agent能记住对话历史对于多轮交互和长任务很重要 memory ConversationBufferMemory(memory_keychat_history, return_messagesTrue) # 5. 创建Agent和它的执行器 agent create_openai_functions_agent(llm, tools, prompt) agent_executor AgentExecutor( agentagent, toolstools, memorymemory, verboseTrue, # 开启详细日志方便调试 handle_parsing_errorsTrue, # 优雅处理解析错误 max_iterations15 # 防止Agent陷入死循环 )3.4 运行与观察智能体如何工作现在让我们运行这个智能体并观察它如何思考。# 用户提出自然语言请求 user_query “帮我抓取豆瓣电影Top250的电影名称、评分和链接保存到‘douban_top250.csv’文件里。” result agent_executor.invoke({input: user_query}) print(result[output])当你设置verboseTrue后在控制台会看到类似以下的思考过程LangChain的Agent内部使用ReAct框架 进入新的AgentExecutor链... 思考用户想抓取豆瓣电影Top250。我需要先导航到正确的网址。我知道豆瓣Top250的网址是 https://movie.douban.com/top250。 行动调用工具 navigate_to_url参数 {url: https://movie.douban.com/top250}。 观察已成功导航至https://movie.douban.com/top250 思考现在我在第一页。我需要提取电影名称、评分和链接。我应该先检查页面结构。我可以获取页面源码或者直接用CSS选择器尝试。先尝试直接提取。 行动调用工具 extract_data_with_css参数 {selector: .item .title, attribute: innerText} 来获取电影名称。 观察返回了一个包含25个电影名称的列表。 思考很好名称提取成功。现在提取评分。评分可能在 class 包含 rating_num 的 span 里。 行动调用工具 extract_data_with_css参数 {selector: .rating_num, attribute: innerText}。 观察返回了一个包含25个评分的列表。 思考现在提取链接。电影详情页的链接可能在 class 为 hd 的 div 下的 a 标签的 href 属性里。 行动调用工具 extract_data_with_css参数 {selector: .hd a, attribute: href}。 观察返回了一个包含25个链接的列表。 思考第一页数据提取完成。但用户要的是Top250有10页。我需要找到“下一页”按钮并点击重复这个过程直到抓完所有页或达到250条。让我先尝试点击下一页。 行动调用工具 find_and_click_element参数 {selector: .next a}。 观察已成功点击元素.next a 思考页面跳转到了第二页。我需要重复提取数据并将新数据追加到之前的列表中。我需要记住我已经抓取了多少条。让我设计一个循环逻辑... 后续会继续点击、提取直到“下一页”链接不可点击或已收集250条数据 ... 思考数据已经收集完毕。现在我有三个列表titles, ratings, links。我需要将它们保存到CSV文件。 行动调用工具 save_to_csv参数 {data_dict: {电影名称: titles, 评分: ratings, 链接: links}, filename: douban_top250.csv}。 观察数据已保存至douban_top250.csv 思考任务完成。 链结束。这个过程完美展示了Auto-Wing的核心价值你将一个高级目标抓取Top250直接交给了智能体而它自己完成了任务分解、工具调用、循环控制和异常处理虽然本例中未展示异常的整个逻辑。你不再需要手动编写翻页循环、编写数据提取规则。当豆瓣页面结构发生变化时你只需要更新工具的描述或者让智能体尝试不同的CSS选择器系统的适应性大大增强。4. 深入挑战异常处理、性能优化与安全边界上面的例子是一个理想化的成功路径。在实际工业级应用中我们会面临更多挑战。Auto-Wing要真正可用必须在这些方面做深。4.1 设计健壮的异常处理与自愈机制这是区分“玩具”与“工具”的关键。我们需要在工具层和Agent决策层都增强容错能力。1. 工具层的增强让每个工具都具备“重试”和“多策略”能力。from functools import wraps from selenium.common.exceptions import NoSuchElementException, StaleElementReferenceException, TimeoutException import time def retry_with_backoff(max_retries3, initial_delay1): 一个装饰器为工具函数添加重试和退避机制。 def decorator(func): wraps(func) def wrapper(*args, **kwargs): delay initial_delay last_exception None for attempt in range(max_retries): try: return func(*args, **kwargs) except (NoSuchElementException, StaleElementReferenceException, TimeoutException) as e: last_exception e if attempt max_retries - 1: print(f工具 {func.__name__} 执行失败{str(e)}。{delay}秒后重试...) time.sleep(delay) delay * 2 # 指数退避 else: print(f工具 {func.__name__} 重试{max_retries}次后仍失败。) # 所有重试都失败后返回一个结构化的错误信息供LLM分析 return f工具执行最终失败。最后错误{str(last_exception)}。建议尝试其他定位方式或检查网络。 return wrapper return decorator # 用装饰器增强工具 tool retry_with_backoff(max_retries2) def robust_find_and_click(selector: str, by: str By.CSS_SELECTOR): 更稳健的查找并点击元素工具内置重试机制。 try: element WebDriverWait(driver, 10).until( EC.element_to_be_clickable((by, selector)) ) element.click() return f成功点击: {selector} except Exception as e: # 如果默认方式失败尝试通过XPath或文本查找 if by By.CSS_SELECTOR: # 可以在这里添加逻辑让LLM决定是否尝试XPath # 暂时返回错误让LLM决策 raise e2. Agent决策层的异常处理当工具返回错误信息时LLM需要能解读并尝试新策略。这依赖于高质量的系统提示词Prompt Engineering。我们需要在系统提示词中明确教导LLM如何应对失败...接之前的系统提示词 5. **优雅处理失败**当工具调用失败时不要放弃。仔细阅读错误信息它可能提示了原因如‘元素未找到’、‘超时’。根据错误你可以 a) **重试**短暂的网络波动或页面加载延迟可能导致失败可以稍等后重试同一操作。 b) **替换策略**如果CSS选择器找不到元素尝试使用XPath。例如你可以尝试 find_and_click_element(selector//button[contains(text(), 下一页)], byBy.XPATH)。 c) **迂回方案**如果点击某个按钮失败是否可以执行等效操作例如按回车键代替点击提交按钮。 d) **请求帮助**如果多次尝试均告失败用清晰的语言向用户描述问题和你已尝试的方案寻求进一步指示。通过这种“工具重试” “LLM策略调整”的双层机制系统的鲁棒性将得到质的提升。4.2 性能优化与成本控制AI调用尤其是大模型API是当前的主要成本和时间瓶颈。在Auto-Wing中必须精打细算。缓存与记忆对于重复性任务将LLM的规划结果如“如何抓取豆瓣电影”缓存起来。下次遇到相同或类似任务时直接使用缓存的工作流无需再次调用LLM规划。LangChain的Memory组件可以存储对话历史避免在多轮交互中重复描述上下文。小模型与大模型分工不是所有决策都需要最强的GPT-4。我们可以建立一个模型路由机制简单的、模式固定的决策如“解析这种固定格式的JSON”使用本地运行的、速度快成本低的小模型如经过微调的BERT系列只有复杂的、需要深度推理的异常诊断和策略生成才调用强大的大模型。这就是前文提到的“混合智能”。限制迭代与超时必须为Agent设置max_iterations最大迭代次数如20次和整体任务超时时间防止其在某些问题上陷入无限循环消耗大量API调用。非AI化降级对于已经稳定运行的任务可以将其成功路径固化成传统的、无需AI参与的脚本或工作流。AI只负责处理“变”的部分而“不变”的部分则用高效、低成本的传统自动化来执行。4.3 安全、伦理与可解释性将AI引入自动化带来了新的风险必须在设计之初就加以考虑。操作安全边界必须为智能体设定明确的“行动禁区”。通过系统提示词和工具白名单严格限制其能力。例如禁止它执行rm -rf /、driver.execute_script(alert(document.cookie))或访问非授权域名。所有涉及数据删除、系统设置修改的操作都应加入人工确认环节。数据隐私与合规智能体抓取的数据必须遵守robots.txt协议和网站服务条款。系统应记录所有数据来源和处理日志确保可审计。避免抓取和存储个人敏感信息。可解释性与审计追踪Agent的每一步思考Chain-of-Thought和行动都必须被完整记录。当出现问题时我们需要能回溯查看“当时AI为什么决定点击那个按钮”。这不仅是调试的需要也是权责厘清的关键。verboseTrue的输出就是最简单的审计日志生产环境需要更结构化的日志系统。偏见与可靠性LLM本身可能存在偏见或生成错误信息幻觉。Auto-Wing系统不能完全信任LLM的输出尤其是涉及事实判断时。对于关键决策点如“这个验证码输入是否正确”应设置置信度阈值或引入人工复核流程。5. 典型应用场景与未来展望Auto-Wing的理念可以渗透到自动化领域的方方面面远不止于网页抓取。5.1 场景一智能自动化测试AI in Testing这是目前最火热的方向之一。测试用例生成输入需求文档或用户故事AI自动生成正向、反向的测试用例甚至包括边界值。自愈性UI测试当UI元素属性如ID、Class变化导致脚本失败时AI能通过图像识别、语义分析如按钮附近的文字重新定位元素让UI测试脚本“长生不老”。探索性测试AI可以模拟用户在应用中随机点击、输入自主探索未预定义的路径寻找潜在崩溃或逻辑错误极大补充传统用例的覆盖盲区。测试结果分析自动阅读测试报告将失败用例分类是环境问题、数据问题还是真正的缺陷并初步分析根因大幅提升测试人员排查效率。5.2 场景二业务流程自动化Intelligent RPA超越传统的基于规则录制的RPA机器人流程自动化。处理非结构化文档自动阅读和理解合同、发票、邮件中的关键信息并录入系统。AI能处理格式千变万化的文档而传统RPA只能处理固定模板。对话式流程创建用户描述“每个月5号从邮箱里找到所有供应商的发票PDF提取金额和编号汇总成表格发给财务小王”AI自动构建出包含邮件收取、PDF解析、数据汇总、邮件发送的完整工作流。异常流程处理当流程遇到预期外弹窗或错误状态时AI能理解上下文选择正确的处理方式如关闭弹窗、联系负责人而不是僵直停止。5.3 场景三智能运维AIOps日志智能分析自动从海量运维日志中归纳模式提前预警潜在故障如“最近一小时数据库慢查询数量同比上升200%”并给出可能的原因和修复建议。故障自愈检测到服务宕机后自动执行标准重启流程如果重启失败能根据知识库尝试其他修复方案并同步通知运维人员。资源优化分析历史负载数据预测未来资源需求并自动向云平台申请或释放资源实现成本与性能的最优平衡。5.4 面临的挑战与未来之路尽管前景广阔但将AI深度应用于自动化仍面临不少挑战成本与延迟大模型API调用不便宜且响应时间在百毫秒到秒级对于需要毫秒级响应的超高频自动化场景仍是障碍。可靠性AI的“幻觉”和不可预测性在关键业务系统中是难以接受的。如何确保AI决策的稳定性和正确性需要更复杂的验证机制。技能门槛构建和维护这样一个混合智能系统需要同时精通传统自动化、软件工程和AI Prompt工程/微调的人才这对团队提出了更高要求。我个人认为Auto-Wing所代表的“AI增强自动化”不会一蹴而就地取代所有传统自动化。更可能的路径是渐进式融合从最痛的点切入比如用AI处理最不稳定的UI测试环节或用AI辅助生成和维护自动化脚本。随着模型能力增强、成本下降和工具链成熟AI在自动化项目中的参与度和职责范围会逐步扩大。对于开发者而言现在正是学习如何将LLM和Agent作为强大工具融入自己技术栈的最佳时机。未来的自动化工程师很可能更像是一个“智能体训练师”和“人机协作流程的设计师”。
