企业官网建设流程全解析

1. 从"一个模型打天下"到角色级拆分：移动端自动化测试的架构拐点

做过移动端自动化测试的人大概都有过这种体验：脚本写了一大堆，元素定位、断言逻辑、异常处理全塞在一个流程里，跑起来倒也能跑，但一旦页面改版或者业务逻辑调整，整个脚本就像多米诺骨牌一样连环崩塌。更麻烦的是，当你试图把大语言模型引入这个流程时，如果还是沿用"一个模型包揽所有决策"的思路，问题只会被放大——模型既要理解自然语言指令，又要生成精确的UI操作序列，还要判断执行结果是否正确，最后还要决定下一步怎么走。这种"全能型"设计在Demo阶段看起来很美，一旦进入真实项目的复杂场景，延迟、准确率和可维护性会同时亮红灯。

DroidRun和Mobilerun这两个项目在移动端自动化测试领域提供了一个很有意思的解题思路：角色级模型拆分。简单说，就是不再让一个模型承担所有职责，而是把整个自动化测试流程拆解成若干个明确的角色，每个角色由一个专门的模型或模型配置来驱动。这有点像把一个全栈工程师的工作拆给前端、后端、测试三个专人去做——每个人只关心自己那一亩三分地，反而整体效率更高、出错更少。

这篇文章适合两类人看：一是已经在做移动端自动化测试、想了解如何把LLM真正落地到生产流程中的测试开发工程师；二是对DroidRun/Mobilerun这类工具感兴趣、想知道它们内部到底怎么运转的技术负责人。我会从架构设计的角度切入，把角色拆分的逻辑、每个角色的职责边界、模型选型的考量、以及实际落地时踩过的坑，尽量讲透。读完之后，你应该能判断自己的项目适不适合走这条路，以及如果走，该怎么拆。

2. 为什么"单模型全能"在移动端自动化里走不通

2.1 移动端自动化的特殊性：比Web端多出来的那些麻烦

Web端自动化测试相对成熟，DOM结构、CSS选择器、XPath这些定位手段已经非常稳定。移动端就完全是另一回事了。Android和iOS各有各的UI框架，原生控件、WebView、混合渲染混在一起，同一个按钮在不同设备上的层级结构可能完全不同。再加上屏幕尺寸碎片化、系统版本差异、权限弹窗、网络状态切换这些变量，移动端自动化的复杂度至少是Web端的两到三倍。

传统方案靠Appium这类工具做元素定位，本质上还是基于控件树的结构化查询。但LLM驱动的自动化测试走的是另一条路：用自然语言描述测试意图，让模型去理解当前屏幕内容并生成操作指令。这条路的好处是灵活，不需要为每个页面写死定位逻辑；坏处是，模型需要同时处理"看懂屏幕"和"决定怎么做"两件事，而这两件事对模型能力的要求截然不同。

2.2 单模型方案的三重困境

我最初尝试用一个通用大模型来驱动整个移动端测试流程，很快就遇到了三个绕不过去的问题。

第一是上下文窗口的浪费。移动端屏幕的UI信息非常冗长，一个中等复杂度的页面，控件树展开后动辄几千个token。如果把这些信息全部塞给一个模型，再加上测试指令、历史操作记录、断言规则，上下文很快就被撑满了。而模型真正需要用来做决策的信息，可能只占其中的一小部分。

第二是能力错配。理解屏幕内容需要的是视觉理解能力和UI结构解析能力，生成操作序列需要的是逻辑推理和动作规划能力，判断执行结果需要的是对比分析和异常识别能力。这三种能力对模型的要求完全不同。用一个模型全包，要么选一个各方面都还行但都不顶尖的通用模型，要么就得在某个环节上妥协。

第三是调试困难。当测试失败时，你很难判断到底是模型没看懂屏幕、还是操作序列生成错了、还是断言逻辑有问题。所有环节耦合在一起，排查问题的成本极高。

2.3 角色拆分的核心逻辑：让每个模型只做自己最擅长的事

角色级模型拆分的本质，是把一个复杂的端到端任务分解成若干个相对独立的子任务，每个子任务由一个专门的模型来处理。这样做的好处很直接：每个模型可以用最适合该任务的配置——包括模型规模、提示词模板、温度参数、甚至不同的模型供应商。

在DroidRun/Mobilerun的架构里，这种拆分体现得尤为明显。它把整个自动化流程拆成了几个核心角色：屏幕解析器负责把当前UI界面转换成结构化的文本描述；动作规划器根据测试目标和当前屏幕状态生成下一步操作；执行器负责把操作指令转换成具体的设备控制命令；验证器负责判断操作结果是否符合预期。每个角色各司其职，通过明确定义的接口进行通信。

这种设计思路其实借鉴了软件工程里的"关注点分离"原则。就像微服务架构把单体应用拆成多个独立服务一样，角色级模型拆分把"单体模型"拆成了多个"模型服务"，每个服务只关心自己的输入和输出，内部实现可以独立优化。

3. DroidRun/Mobilerun的角色拆分架构拆解

3.1 屏幕解析器：把像素和控件树翻译成模型能懂的"人话"

屏幕解析器是整个流程的入口。它的任务很明确：拿到当前设备的屏幕截图和控件树信息，输出一段结构化的文本描述，告诉后续环节"现在屏幕上有什么"。

这个角色的技术选型有几个关键考量。首先是输入形式，纯截图还是截图加控件树？纯截图方案对模型的视觉理解能力要求很高，而且容易受到分辨率、主题、字体大小的影响。控件树方案更稳定，但需要处理不同平台（Android的AccessibilityNodeInfo和iOS的XCUIElement）的差异。DroidRun的做法是两者结合：用控件树提供精确的控件位置和属性，用截图提供视觉上下文，两者互补。

其次是输出格式。屏幕解析器的输出需要足够简洁，避免占用过多上下文窗口，同时又要保留关键信息。常见的做法是输出一个精简的控件列表，每个控件包含类型、文本内容、位置坐标、是否可点击等属性。比如一个登录页面，输出可能是这样的：

[文本框] 用户名输入框 (id=username, 位置: 120,340, 可编辑) [文本框] 密码输入框 (id=password, 位置: 120,420, 可编辑, 密码模式) [按钮] 登录 (text=登录, 位置: 120,520, 可点击) [文本] 忘记密码 (位置: 120,580, 可点击)

这个角色的模型选型通常偏向于轻量级模型或者经过专门微调的模型。因为屏幕解析本质上是一个"结构化信息提取"任务，不需要太强的推理能力，但对准确性和速度要求很高。在实际项目中，我见过用7B参数级别的模型就能跑得不错的案例，关键是提示词模板要设计得足够清晰。

3.2 动作规划器：测试流程的"大脑"

动作规划器是角色拆分架构里最核心的一环。它接收屏幕解析器的输出，结合测试目标和历史操作记录，决定下一步该做什么。

这个角色的输入包括：当前屏幕的结构化描述、测试用例的当前步骤、之前已经执行过的操作序列、以及可能的异常状态。输出则是一个明确的操作指令，比如"点击坐标(120,520)的登录按钮"或者"在用户名输入框中输入testuser"。

动作规划器对模型的能力要求最高。它需要理解测试意图，需要根据当前屏幕状态做出合理决策，还需要在遇到意外情况时（比如弹出了权限请求对话框）能够灵活应对。这个角色通常需要选用推理能力较强的模型，参数规模一般在70B以上，或者使用专门针对Agent任务优化过的模型。

提示词设计在这个环节尤为关键。一个好的动作规划器提示词应该包含：角色定义（你是一个移动端自动化测试助手）、当前状态描述、可用操作列表、决策规则（比如优先点击明确标识的按钮，避免点击广告区域）、以及输出格式要求。我自己的经验是，在提示词里加入几个Few-shot示例，能显著提升规划准确率，尤其是在处理复杂页面时。

3.3 执行器与验证器：一个负责"做"，一个负责"查"

执行器和验证器的职责相对清晰。执行器把动作规划器的输出转换成具体的设备控制命令，比如通过ADB发送点击事件、通过WebDriver协议调用原生操作。这个环节其实不太需要大模型参与，更多是工程实现层面的工作。但在DroidRun的架构里，执行器也会用一个轻量模型来做指令的格式校验和异常处理，比如当规划器输出的坐标超出屏幕范围时，执行器会尝试修正或者返回错误信息。

验证器则是另一个需要模型能力的角色。它的任务是判断执行结果是否符合预期。比如点击登录按钮后，验证器需要判断是否成功跳转到了首页、是否出现了错误提示、还是页面没有任何变化。这个判断过程需要对比操作前后的屏幕状态，识别关键变化。

验证器的模型选型比较灵活。如果测试用例的断言规则写得很明确（比如"检查是否出现包含'欢迎'文本的控件"），用规则引擎就够了。但如果需要处理模糊断言（比如"确认页面看起来正常"），就需要模型来做视觉理解和语义判断。实际项目中，我建议把验证器设计成可配置的：简单断言走规则，复杂断言走模型，这样能在准确率和成本之间取得平衡。

3.4 角色间的通信协议：接口设计比模型选型更重要

角色拆分架构能不能跑通，很大程度上取决于角色之间的接口设计。每个角色的输出格式必须严格定义，否则下游角色就没法正确解析。

在DroidRun/Mobilerun的实践里，角色间的通信通常采用JSON格式。屏幕解析器输出一个包含控件列表的JSON对象，动作规划器输出一个包含操作类型和参数JSON对象，执行器返回执行结果的状态码和消息，验证器返回布尔值和置信度。这种结构化的通信方式，让每个角色的输出都可以被独立测试和验证。

这里有一个容易被忽略的细节：错误处理协议。当某个角色无法完成任务时（比如屏幕解析器遇到了无法识别的控件类型，或者动作规划器找不到合适的操作），它需要以一种标准化的方式把错误传递给上游。DroidRun的做法是定义一个统一的错误对象，包含错误类型、错误描述、以及可能的恢复建议。这样整个流程就能在遇到问题时做出合理的降级处理，而不是直接崩溃。

4. 模型选型与参数调优：每个角色该配什么"引擎"

4.1 屏幕解析器的模型选择：小而准比大而全更实用

屏幕解析这个任务，说白了就是"看图说话"——把UI界面转换成文字描述。这个任务的特点是输入输出都比较结构化，不需要太强的推理能力，但对准确性和延迟很敏感。

我在实际项目里试过几种方案。用GPT-4级别的模型做屏幕解析，准确率确实高，但每次调用的延迟和成本都让人心疼。后来换成7B级别的开源模型，配合精心设计的提示词和Few-shot示例，在大多数常见页面上准确率能到90%以上，延迟降低了差不多一个数量级。

关键是要做好提示词的模板化。屏幕解析的提示词应该包含：任务定义（把以下UI控件树转换成简洁的文本描述）、输出格式要求（每行一个控件，包含类型、文本、位置、状态）、以及处理规则（忽略不可见控件、合并同类控件、优先保留有文本内容的控件）。把这些规则写清楚，小模型也能干得不错。

还有一个实用技巧：缓存机制。很多测试场景下，连续几步操作的屏幕变化很小。如果每次操作后都重新解析整个屏幕，既浪费算力又增加延迟。DroidRun的做法是维护一个屏幕状态缓存，只有当检测到屏幕发生显著变化时才触发重新解析。这个"显著变化"的判断可以用简单的图像差分算法来做，不需要模型参与。

4.2 动作规划器的模型配置：推理能力是硬指标

动作规划器是整个架构里对模型能力要求最高的角色。它需要理解测试目标、分析当前状态、规划操作序列，还要处理各种边界情况。这个角色的模型选型，我的建议是不要省。

参数规模上，至少需要70B级别的模型，或者使用专门针对Agent任务优化过的模型。温度参数建议设置在0.1到0.3之间，太低会导致模型过于死板，遇到没见过的情况就卡住；太高则会让模型产生随机性，同样的输入可能给出不同的操作建议，不利于测试的稳定性。

提示词设计上，动作规划器需要比屏幕解析器更复杂的模板。我通常会包含这几个部分：系统角色定义、当前测试步骤描述、屏幕状态摘要、可用操作列表、决策优先级规则、输出格式示例。其中决策优先级规则特别重要，比如"优先点击有明确文本标识的按钮"、"避免点击屏幕边缘的广告区域"、"如果出现权限弹窗，优先选择允许"。

还有一个实战经验：给动作规划器加上"思考链"。让模型在输出最终操作之前，先输出一段简短的推理过程，说明为什么选择这个操作。这样做有两个好处：一是能提升规划准确率，因为模型在"说"的过程中会进行更多的内部推理；二是方便调试，当操作不符合预期时，你可以通过查看推理过程来判断是哪个环节出了问题。

4.3 验证器的轻量化策略：不是所有判断都需要大模型

验证器这个角色很容易被过度设计。很多人一上来就想用大模型做所有断言判断，结果发现成本和延迟都受不了。其实大部分验证场景都可以用更轻量的方案解决。

我的做法是把验证分为三个层级。第一层是精确匹配，比如检查某个控件是否存在、某个文本是否出现，这种用规则引擎直接搞定，不需要模型。第二层是模糊匹配，比如判断页面是否"看起来像"登录成功页面，这种可以用轻量模型做文本相似度比较，或者用预定义的页面特征向量做匹配。第三层才是语义判断，比如"确认用户已经完成了注册流程"，这种才需要大模型介入。

在实际项目中，我发现第一层和第二层能覆盖80%以上的验证需求，真正需要大模型做语义判断的场景并不多。把验证器设计成这种分层结构，能在保证准确率的同时大幅降低成本。

4.4 角色间模型复用的边界：哪些角色可以共享模型实例

角色拆分不意味着每个角色都必须用不同的模型。在实际部署时，有些角色可以共享同一个模型实例，只要它们的输入输出格式不冲突。

比如屏幕解析器和验证器，如果都用同一个轻量模型，通过不同的提示词模板来区分任务，是完全可行的。这样能减少模型加载的内存开销，也能简化部署架构。但动作规划器通常需要独立部署，因为它的模型配置（温度、最大token数等）和其他角色差异较大。

还有一个考虑因素是并发需求。屏幕解析和验证通常是在操作前后触发的，而动作规划是在操作前触发的，它们的调用时机不同。如果测试用例是串行执行的，共享模型实例问题不大；但如果需要并行跑多个测试用例，就需要考虑模型实例的并发处理能力了。

5. 落地实操：从零搭建角色拆分架构的关键步骤

5.1 环境准备与依赖管理

搭建这套架构的第一步是环境准备。你需要一台能跑模型的机器（或者调用云端API的权限）、Android SDK（用于设备控制）、以及Python环境（DroidRun和Mobilerun都是Python项目）。

设备控制这块，我建议用ADB（Android Debug Bridge）作为底层通信手段。虽然Appium提供了更上层的封装，但ADB更轻量、更直接，适合和LLM驱动的流程配合。你需要确保ADB能正常识别设备，并且有足够的权限执行点击、输入、截图等操作。

模型部署方面，如果用的是开源模型，可以用vLLM或者TGI来做推理服务，它们对并发请求的支持比较好。如果调用云端API，需要处理好API密钥管理和请求限流。我自己的经验是，在开发阶段用云端API快速验证流程，在生产环境切换到本地部署的开源模型来控制成本和数据安全。

5.2 角色接口的定义与实现

接口定义是角色拆分架构的地基。我建议先用JSON Schema把每个角色的输入输出格式定义清楚，然后再写代码实现。

屏幕解析器的输出格式可以这样定义：

{ "screen_id": "unique_hash", "timestamp": "2024-01-01T00:00:00Z", "elements": [ { "type": "button", "text": "登录", "bounds": [120, 520, 240, 560], "clickable": true, "enabled": true } ], "screen_summary": "登录页面，包含用户名和密码输入框" }

动作规划器的输出格式：

{ "action": "click", "target": {"x": 180, "y": 540}, "reasoning": "点击登录按钮以提交表单", "confidence": 0.95 }

执行器的输出格式：

{ "status": "success", "action_executed": "click", "timestamp": "2024-01-01T00:00:01Z" }

验证器的输出格式：

{ "passed": true, "confidence": 0.88, "details": "检测到包含'欢迎'文本的控件，页面已跳转" }

把这些格式定义好之后，每个角色的实现就变成了"输入JSON，输出JSON"的简单函数。这样做的好处是，你可以独立测试每个角色，也可以用Mock数据来模拟上下游，大大加快了开发速度。

5.3 流程编排与异常处理

角色都实现好之后，需要一个编排器来把它们串起来。编排器的逻辑其实不复杂：解析屏幕→规划动作→执行动作→验证结果→如果验证通过则进入下一步，否则触发异常处理。

异常处理是编排器里最需要花心思的部分。常见的异常包括：屏幕解析失败（模型返回了无法解析的内容）、动作规划失败（模型找不到合适的操作）、执行失败（ADB命令超时或报错）、验证失败（操作结果不符合预期）。每种异常都需要有对应的恢复策略。

我的做法是给每种异常定义一个重试次数和降级方案。比如屏幕解析失败，先重试一次；如果还失败，就降级到使用上一次的屏幕缓存。动作规划失败，先尝试用规则引擎给出一个默认操作（比如点击屏幕中心）；如果还不行，就标记该测试用例为"需要人工介入"。

5.4 测试用例的编写与调试

角色拆分架构下的测试用例编写，和传统自动化测试有比较大的区别。你不再需要写具体的元素定位和操作步骤，而是用自然语言描述测试意图。比如：

测试用例：用户登录流程 步骤： 1. 在用户名输入框中输入"testuser" 2. 在密码输入框中输入"password123" 3. 点击登录按钮 4. 验证是否跳转到首页

这种写法看起来很简单，但实际调试时需要注意几个点。首先，自然语言描述要尽量明确，避免歧义。比如"点击登录按钮"比"进行登录操作"要好，因为后者可能被模型理解为输入用户名密码后自动提交。其次，步骤之间的依赖关系要清晰，如果某个步骤依赖前一步的结果，最好在描述中体现出来。

调试的时候，我建议把每个角色的输入输出都打上日志。这样当测试失败时，你可以沿着日志链路一步步排查：是屏幕解析错了？还是动作规划选错了操作？还是验证器的判断标准太严格？这种可观测性，是角色拆分架构相比单模型方案的一大优势。

6. 踩坑记录：角色拆分实践中那些文档不会写的事

6.1 屏幕解析的"信息丢失"陷阱

屏幕解析器为了控制输出长度，通常会对控件信息做精简。但这个精简的度很难把握。我遇到过好几次这样的情况：解析器把某个控件的文本内容截断了，导致动作规划器无法准确识别这个控件的用途，最终点错了地方。

后来我的解决方案是，在解析器的输出里保留控件的完整文本，但对控件的其他属性（比如位置坐标）做精度压缩。因为文本内容是模型做决策的主要依据，而位置坐标只需要精确到可点击的范围就够了。另外，对于文本内容特别长的控件（比如一段说明文字），可以只保留前50个字符加省略号，同时在输出里标注"文本已截断"。

6.2 动作规划器的"幻觉操作"

大模型有个通病，就是会"幻觉"出一些不存在的操作。比如屏幕上明明没有"注册"按钮，但模型在规划时却输出了"点击注册按钮"的指令。这种情况在测试流程中很危险，因为执行器可能会把这个指令映射到一个错误的位置，导致误操作。

我的应对策略是在动作规划器和执行器之间加一层校验。执行器在收到操作指令后，先检查目标位置是否在屏幕范围内、该位置是否有可交互的控件。如果校验不通过，就拒绝执行并把错误返回给规划器，让规划器重新规划。这个校验层用简单的规则就能实现，不需要模型参与，但能拦住大部分幻觉操作。

6.3 验证器的"假阳性"问题

验证器的假阳性是指：明明操作没有达到预期效果，但验证器却判断通过了。这种问题通常出现在模糊断言的场景下。比如验证"页面是否正常显示"，模型可能因为页面上有一些看似正常的元素就判断通过了，但实际上页面可能处于错误状态。

解决这个问题的关键是定义清晰的验证标准。我在实际项目中会为每个验证场景定义一组必须满足的条件，比如"必须出现包含'成功'文本的控件"、"必须不出现包含'错误'文本的控件"、"页面标题必须匹配预期值"。把这些条件明确写出来，验证器的判断就会准确很多。对于那些确实需要模糊判断的场景，我会要求验证器输出置信度，只有置信度超过阈值才认为验证通过。

6.4 角色间通信的"格式漂移"

角色拆分架构运行一段时间后，容易出现一个隐蔽的问题：某个角色的输出格式发生了微小的变化，导致下游角色解析失败。比如屏幕解析器某次更新后，把控件位置的字段名从"bounds"改成了"position"，而动作规划器还在按"bounds"解析，结果就是规划器拿不到位置信息，整个流程卡住。

这个问题的根源是接口没有版本管理。我的建议是，在角色间的通信协议里加入版本号字段，每次修改格式时递增版本号。下游角色在解析输入时先检查版本号，如果版本不匹配就给出明确的错误提示，而不是默默地解析失败。另外，在CI流程里加入接口契约测试，确保每次代码变更都不会破坏角色间的通信协议。

6.5 模型更新的"连锁反应"

当你更新了某个角色的模型（比如把屏幕解析器从7B模型换成13B模型），整个流程的行为可能会发生连锁变化。新模型可能对某些控件的识别更准确了，但也可能对另一些控件的识别变差了。这种变化很难预测，只能通过回归测试来发现。

我的做法是维护一个"黄金测试集"，包含几十个典型的测试场景和对应的预期结果。每次更新任何角色的模型之前，先在这个测试集上跑一遍，对比更新前后的通过率。如果通过率下降超过阈值，就需要分析原因，可能是新模型在某些场景下确实不如旧模型，也可能是提示词需要针对新模型做调整。

7. 性能与成本：角色拆分架构的投入产出分析

7.1 延迟对比：拆分后是变快了还是变慢了

很多人担心角色拆分会导致延迟增加，因为原本一次模型调用能完成的事情，现在要拆成多次调用。这个担心有一定道理，但实际情况取决于具体的拆分方式和部署方案。

在单模型方案里，一次调用需要处理所有信息，输入token数可能达到8000到10000，模型推理时间较长。拆分之后，屏幕解析器的输入可能只有2000到3000token，动作规划器的输入在3000到4000token，单次调用的时间都缩短了。虽然总调用次数增加了，但如果这些调用能并行或者流水线化，整体延迟反而可能降低。

实测数据上，在一个中等复杂度的测试场景里，单模型方案的端到端延迟大约是8到12秒，角色拆分方案在优化后能控制在5到8秒。关键优化点在于：屏幕解析和验证可以异步进行，不需要阻塞主流程；动作规划器的提示词要尽量精简，避免不必要的上下文。

7.2 成本核算：每个角色的Token消耗分布

成本是另一个需要算清楚的账。角色拆分后，token消耗分布在多个模型调用上，需要分别核算。

以一个包含10步操作的测试用例为例，屏幕解析器每步调用一次，每次消耗约2500token（输入加输出），总共25000token。动作规划器每步调用一次，每次约3500token，总共35000token。验证器每步调用一次，每次约1500token，总共15000token。合计约75000token。

如果用单模型方案，每步调用一次，每次约8000token，总共80000token。从token总量上看，两者差不多。但角色拆分方案的优势在于，屏幕解析和验证可以用更便宜的轻量模型，只有动作规划器需要用贵一些的强模型。这样算下来，整体成本能降低30%到40%。

7.3 准确率提升：拆分带来的实际收益

准确率是角色拆分架构最核心的收益。在单模型方案里，模型需要同时处理多种任务，容易顾此失彼。拆分之后，每个模型只专注于自己的任务，准确率会有明显提升。

我在一个包含50个测试用例的项目里做过对比。单模型方案的整体通过率大约是72%，失败的原因分布很分散：有的是屏幕理解错误，有的是操作规划不合理，有的是验证判断失误。角色拆分方案在调优后，整体通过率提升到了89%。其中屏幕解析的准确率从85%提升到94%，动作规划的准确率从78%提升到91%，验证的准确率从82%提升到93%。

这个提升幅度在真实项目里是非常可观的。因为自动化测试的通过率每提升一个百分点，就意味着减少大量的人工排查和修复工作。

8. 从角色拆分到多Agent协作：下一步可以怎么走

角色级模型拆分解决的是"一个模型干太多事"的问题，但它本质上还是一个人工编排的流水线。下一步的演进方向，是让这些角色变成具有一定自主性的Agent，能够根据环境变化动态调整自己的行为。

比如屏幕解析器可以学会主动忽略某些类型的弹窗（广告、评分请求），而不是把所有控件都一股脑地输出。动作规划器可以学会在遇到未知页面时主动探索，而不是死板地按照预设步骤执行。验证器可以学会根据历史数据调整自己的判断阈值，减少假阳性和假阴性。

这些能力的实现，需要在角色之间引入更复杂的通信机制，比如共享记忆、协商决策、动态角色切换等。DroidRun和Mobilerun目前的架构已经为这些扩展留出了接口，但具体的实现还需要根据实际项目需求来定制。

我在实际项目里的体会是，不要一上来就追求全自动的多Agent协作。先把角色拆分做扎实，让每个角色的准确率和稳定性达到生产可用的水平，然后再考虑引入更复杂的协作机制。否则，多个不稳定的Agent协作，只会让问题更难排查。

最后分享一个实用的小技巧：在角色拆分架构里，给每个角色维护一个"健康度指标"，比如屏幕解析器的解析成功率、动作规划器的首次规划准确率、验证器的判断准确率。这些指标不需要很精确，但能帮你快速定位是哪个角色出了问题。当某个角色的健康度下降时，优先排查它的提示词、模型版本和输入数据，通常能很快找到原因。