LLM如何介入移动端自动化测试？ARTEMIS双模式架构拆解

移动端自动化测试这件事，真正上手做过的人都清楚，它跟Web端完全不是一个难度量级。Web端你打开浏览器、定位元素、点击输入，一套流程跑下来行云流水；可一旦切到移动端，设备碎片化、系统权限、渲染机制差异、网络抖动、弹窗干扰，随便一个因素就能让你的用例挂得莫名其妙。而当我们试图把LLM引入移动端自动化测试时，问题会变得更加棘手——LLM擅长理解语义、生成文本、做推理判断，但它对移动端UI的动态性和不确定性几乎没有天然的适配能力。ARTEMIS这套双模式架构，就是在这个背景下被设计出来的，它试图回答一个核心问题：LLM到底应该以什么姿态介入移动端自动化测试？是当一个"翻译官"把自然语言指令转成操作步骤，还是当一个"决策者"在运行时动态判断下一步该做什么？这篇文章就把ARTEMIS的双模式架构彻底拆开，从设计动机、模式分工、核心流程到实操中的坑，全部讲透。

1. 为什么移动端自动化测试需要LLM介入

1.1 传统移动端自动化框架的天花板在哪里

Appium、Espresso、XCUITest这些框架本质上都是"指令式"的——你告诉它点哪个元素、输入什么内容、断言什么结果，它就照做。这套逻辑在页面结构稳定、元素ID规范的项目里跑得挺好，但现实往往不是这样。移动端App的UI变动频率远高于Web端，一个版本迭代可能就把你一半的定位器全废了。更麻烦的是，很多元素根本没有稳定的ID，你只能用XPath或坐标去定位，而XPath在复杂布局里又极其脆弱。

我见过太多团队在维护自动化用例上花的时间比写新用例还多。每次发版前跑一遍回归，总有几个用例因为元素找不到或者页面加载时序问题挂掉，排查半天发现只是某个按钮的层级变了。这种"维护地狱"是传统框架绕不过去的坎，因为它的核心假设是"UI结构是稳定的"，而移动端恰恰最不稳定。

另一个天花板是跨平台适配。同一套业务逻辑，iOS和Android的UI结构、控件类型、交互方式都不一样，你得写两套用例。即便用了Appium这种跨平台方案，底层驱动差异仍然会导致大量条件分支，代码可读性和可维护性都很差。

1.2 LLM能补上哪些能力缺口

LLM的强项在于语义理解和模糊匹配。你给它一张页面截图或者一段UI层级描述，它能理解"这是一个登录按钮"或者"当前页面处于加载状态"，而不需要你精确指定元素ID。这就解决了传统框架最头疼的定位脆弱性问题——即使按钮的ID变了、位置挪了，只要它的视觉特征和语义没变，LLM就能认出来。

再一个是自然语言驱动的用例生成。传统方式你得手写代码或者用录制工具生成脚本，门槛不低。有了LLM，你可以直接用自然语言描述测试意图，比如"验证用户用错误密码登录时会提示错误信息"，LLM能把它拆解成具体的操作步骤和断言条件。这大幅降低了用例编写的门槛，也让非技术背景的测试人员能参与到自动化中来。

还有一个容易被忽略的点：LLM可以做运行时决策。移动端测试中经常遇到意外弹窗、权限请求、网络异常等情况，传统框架只能预先写好各种异常处理分支，穷举成本极高。LLM可以在运行时根据当前页面状态动态判断该怎么处理，这种灵活性是规则引擎做不到的。

1.3 ARTEMIS双模式架构要解决的核心矛盾

但LLM介入移动端自动化并不是简单地"把LLM塞进去"就完事了。这里有一个核心矛盾：LLM的推理速度慢、成本高、输出不确定，而移动端自动化测试要求快速、稳定、可重复。如果你每一步操作都让LLM去推理，那测试执行时间会膨胀到不可接受的程度，而且LLM偶尔的"幻觉"会导致测试结果不可靠。

ARTEMIS的双模式架构正是为了调和这个矛盾。它把LLM的介入分成两种模式：一种是在用例生成阶段深度介入，把自然语言转成结构化测试步骤；另一种是在执行阶段轻量介入，只在遇到异常或不确定场景时才调用LLM做决策。两种模式各司其职，既发挥了LLM的语义理解优势，又避免了它在高频操作中的性能瓶颈。

2. ARTEMIS双模式架构的整体设计

2.1 两种模式的分工逻辑

ARTEMIS把整个测试生命周期拆成两个阶段，每个阶段对应一种LLM介入模式。

第一种叫编排模式（Orchestration Mode），发生在测试用例的生成和规划阶段。在这个模式下，LLM扮演的是"测试架构师"的角色。你给它一段自然语言描述的测试需求，它负责理解意图、拆解步骤、识别前置条件、生成断言逻辑，最终输出一份结构化的测试计划。这份计划不是直接可执行的脚本，而是一种中间表示——它描述了"要做什么"，但不关心"具体怎么点"。

第二种叫执行模式（Execution Mode），发生在测试用例的实际运行阶段。在这个模式下，LLM扮演的是"现场决策者"的角色。大部分操作由传统的自动化引擎按预定义步骤执行，只有当引擎遇到无法处理的场景——比如元素定位失败、页面状态与预期不符、出现未知弹窗——才会触发LLM介入。LLM根据当前页面截图和上下文信息，判断下一步该怎么做，然后返回一个操作指令给引擎执行。

这两种模式的关键区别在于调用频率和延迟容忍度。编排模式是"一次性"的，生成一份测试计划可能只需要调用几次LLM，延迟几秒完全可以接受。执行模式是"按需触发"的，理想情况下大部分用例执行过程中根本不需要调用LLM，只有异常场景才会触发，这样整体执行效率不会受到太大影响。

2.2 编排模式：从自然语言到结构化测试计划

编排模式的核心任务是把模糊的自然语言需求转化成精确的结构化测试计划。这个过程不是简单的"翻译"，而是需要LLM做大量的推理和补全。

举个例子，你输入的需求是"验证用户登录功能"。这句话信息量极少，LLM需要补全大量隐含信息：登录页面怎么进入？需要哪些输入字段？正常登录和异常登录分别要验证什么？登录成功的判断标准是什么？登录失败又该检查什么？这些都需要LLM基于常识和领域知识去推理。

ARTEMIS在编排模式中采用了一种"分步推理+结构化输出"的策略。首先让LLM做意图理解，明确测试目标和范围；然后做步骤拆解，把测试目标分解成有序的操作序列；接着做条件补全，识别每个步骤的前置条件和预期结果；最后做断言生成，为每个验证点生成可执行的断言逻辑。

输出格式上，ARTEMIS定义了一套JSON Schema来描述测试计划。每个测试步骤包含操作类型、目标描述、输入参数、预期结果、超时时间等字段。这种结构化表示的好处是它跟具体的自动化引擎解耦——你可以把它翻译成Appium脚本，也可以翻译成其他框架的脚本，甚至可以在不同平台之间复用同一份测试计划。

2.3 执行模式：运行时LLM决策的触发条件

执行模式的设计哲学是"最小化LLM调用"。传统自动化引擎能处理的事情，绝不麻烦LLM。只有当引擎"卡住"了，才让LLM来救场。

那什么情况算"卡住"？ARTEMIS定义了以下几类触发条件：

• 元素定位失败：引擎按照测试计划中的描述找不到目标元素，可能是ID变了、层级变了、或者页面根本没加载出来。
• 页面状态异常：当前页面与预期不符，比如预期在首页却跳到了登录页，或者出现了未知的弹窗、广告、权限请求。
• 断言结果模糊：某些断言不是简单的"等于/不等于"，而是需要语义判断，比如"页面上显示了错误提示"——具体是什么提示？位置在哪？这些需要LLM来理解。
• 多路径决策：当前场景有多种可能的操作路径，引擎无法确定该走哪条，需要LLM根据上下文做判断。

触发LLM介入后，ARTEMIS会把当前页面截图、UI层级树、已执行步骤的历史、原始测试计划等信息打包成一个上下文，发给LLM。LLM返回一个决策结果，包含操作类型、目标元素描述、操作参数、以及决策理由。引擎拿到这个结果后执行操作，并把执行结果反馈回去，形成一个闭环。

2.4 两种模式之间的数据流转

两种模式不是孤立的，它们之间通过一份共享的"测试计划中间表示"来衔接。编排模式生成的测试计划，既是执行模式的输入，也是执行模式中LLM决策的上下文依据。

当执行模式触发LLM决策时，LLM不仅能看到当前页面状态，还能看到原始测试计划中定义的预期步骤和断言。这让LLM的决策有了"全局视角"——它知道当前步骤在整个测试流程中的位置，知道最终要验证什么，因此能做出更合理的判断。

反过来，执行模式中LLM做出的决策也会被记录下来，反馈给编排模式。如果某个测试计划在执行过程中频繁触发LLM介入，说明这份计划在某些步骤上描述不够精确，需要优化。这种反馈机制让整个系统有了持续改进的能力。

3. 编排模式的落地细节

3.1 自然语言需求的结构化拆解流程

编排模式的第一步是把自然语言需求拆解成结构化的测试步骤。这个过程看似简单，实际上有很多细节需要处理。

ARTEMIS采用的是一种"分层拆解"的策略。第一层是测试场景识别，从需求描述中提取出有几个独立的测试场景。比如"验证登录功能"可能包含"正常登录"、"密码错误"、"账号不存在"、"空输入"等多个场景。第二层是步骤序列生成，为每个场景生成有序的操作步骤。第三层是参数填充，为每个步骤补充具体的输入数据和配置参数。第四层是断言绑定，为每个验证点生成断言逻辑。

这个流程中，LLM的prompt设计非常关键。你不能简单地说"把这段话转成测试步骤"，那样LLM的输出会非常不稳定。ARTEMIS的做法是给LLM提供一套"拆解模板"和"领域知识库"，让LLM在约束下做推理。

拆解模板定义了测试计划的基本结构，包括场景列表、步骤列表、断言列表等字段。领域知识库则包含了一些常见的移动端测试模式，比如"登录测试通常需要验证哪些点"、"表单提交测试的典型步骤是什么"。这些知识以few-shot示例的形式注入prompt，引导LLM生成符合规范的结构化输出。

3.2 测试计划的JSON Schema设计

测试计划的结构化表示是整个架构的基础。ARTEMIS定义了一套JSON Schema，核心字段包括：

{ "plan_id": "string", "target_app": "string", "platform": "ios|android", "scenarios": [ { "scenario_id": "string", "description": "string", "preconditions": ["string"], "steps": [ { "step_id": "integer", "action": "tap|input|swipe|assert|wait", "target": { "description": "string", "locator_hint": "string", "fallback_locators": ["string"] }, "input_data": "object", "expected_result": "string", "timeout_ms": "integer", "llm_fallback": "boolean" } ], "assertions": [ { "assertion_id": "string", "type": "element_exists|text_contains|visual_match|semantic", "target": "string", "expected_value": "string" } ] } ] }

这个Schema的设计有几个关键考量。locator_hint字段是给传统引擎用的，提供一个粗略的定位提示；fallback_locators是备选定位方案，当主定位失败时依次尝试；llm_fallback标记该步骤是否允许LLM介入，有些关键步骤不允许LLM做决策，必须严格按计划执行。

assertions中的type字段区分了断言的类型。element_exists和text_contains是传统断言，引擎可以直接判断；visual_match需要图像比对；semantic则需要LLM做语义判断。这种分类让引擎知道哪些断言可以自己处理，哪些需要调用LLM。

3.3 Prompt工程中的关键约束

编排模式的输出质量高度依赖prompt设计。ARTEMIS在实践中总结了几条关键约束：

约束一：强制结构化输出。要求LLM必须按照指定的JSON Schema输出，不允许自由发挥。这可以通过在prompt中嵌入Schema定义、提供示例输出、以及使用结构化输出API来实现。

约束二：限制推理深度。LLM容易过度推理，把一个简单的测试需求拆成几十个步骤。ARTEMIS在prompt中明确要求"每个场景的步骤数不超过15步"，避免生成过于冗长的测试计划。

约束三：强制引用领域知识。在prompt中注入领域知识库的片段，要求LLM在拆解步骤时参考这些知识。比如"根据领域知识，登录测试通常需要验证：输入框存在性、密码掩码显示、错误提示文案、登录后跳转目标"。

约束四：输出自检。要求LLM在生成测试计划后，自己检查一遍：步骤是否完整？断言是否覆盖了所有验证点？前置条件是否明确？这种自检机制能显著减少遗漏。

3.4 生成结果的校验与修正

LLM生成的测试计划不能直接使用，必须经过校验和修正。ARTEMIS设计了一套多层次的校验机制。

第一层是Schema校验，检查输出是否符合JSON Schema定义，字段是否完整、类型是否正确。这一层可以用标准的JSON Schema验证工具完成。

第二层是逻辑校验，检查测试计划的逻辑是否自洽。比如步骤序列中是否有"先断言后操作"的错误顺序？前置条件是否在步骤中被满足？断言的目标是否在步骤中被操作过？这些逻辑检查可以用规则引擎实现。

第三层是语义校验，用另一个LLM实例对测试计划做review，检查是否有遗漏的验证点、是否有不合理的步骤、是否有模糊的描述。这一层相当于"LLM审LLM"，能发现一些规则引擎检查不出来的问题。

校验发现的问题会反馈给编排模式的LLM，要求它修正后重新输出。这个循环最多执行3次，如果3次后仍有问题，就标记为"需人工介入"，交给测试人员处理。

4. 执行模式的运行时决策机制

4.1 触发条件的精确判定

执行模式的核心是"什么时候该让LLM介入"。触发条件判定得太宽松，会导致LLM调用频繁、执行效率下降；判定得太严格，又会在真正需要LLM的时候错过时机。

ARTEMIS的触发判定采用了一种"分级触发"策略。第一级是硬触发，包括元素定位失败超过重试次数、页面加载超时、应用崩溃等明确异常。这些情况必须触发LLM介入。第二级是软触发，包括页面状态与预期不完全匹配、断言结果处于模糊地带、出现了计划中未定义的元素。这些情况会根据置信度评分决定是否触发LLM。第三级是预判触发，引擎根据历史执行数据预测当前步骤可能出问题，提前触发LLM做决策。

置信度评分是软触发的关键。ARTEMIS为每个步骤计算一个"执行置信度"，综合考虑元素匹配度、页面相似度、历史成功率等因素。当置信度低于阈值（默认0.7）时，触发LLM介入。这个阈值可以根据项目实际情况调整，对稳定性要求高的项目可以调高，对执行速度要求高的项目可以调低。

4.2 上下文构建：给LLM看什么

LLM做决策的质量取决于它接收到的上下文。上下文太少，LLM无法做出准确判断；上下文太多，又会超出token限制或者引入噪声。ARTEMIS在上下文构建上做了精细的设计。

核心上下文包括四部分：

• 当前页面信息：页面截图（经过压缩和标注）、UI层级树（经过裁剪，只保留可见元素和关键属性）、当前Activity/ViewController名称。
• 测试计划上下文：当前执行到哪个场景、哪个步骤，原始计划中该步骤的定义是什么，后续还有哪些步骤。
• 执行历史：最近N步的操作记录和结果，包括成功和失败的步骤。
• 异常信息：触发LLM介入的具体原因，比如"元素定位失败，已尝试的定位器：xxx"。

这四部分信息被打包成一个结构化的prompt，发给LLM。prompt中还会包含一些决策约束，比如"你只能返回以下操作类型之一：tap、input、swipe、wait、skip、abort"，以及"如果无法确定如何操作，返回abort并说明原因"。

4.3 LLM返回结果的解析与执行

LLM返回的决策结果需要经过解析和验证才能执行。ARTEMIS定义了一套决策结果的格式：

{ "decision": "tap|input|swipe|wait|skip|abort", "target": { "description": "string", "coordinates": {"x": "integer", "y": "integer"}, "locator": "string" }, "input_data": "object", "reasoning": "string", "confidence": "float" }

解析时首先要检查decision字段是否在允许的操作类型范围内。然后检查target是否有效——如果LLM返回了坐标，引擎会验证坐标是否在屏幕范围内；如果返回了定位器，引擎会尝试用该定位器查找元素。如果验证失败，会把错误信息反馈给LLM，要求重新决策。

confidence字段是LLM对自己决策的置信度评分。如果置信度低于某个阈值（比如0.5），引擎可以选择不执行该决策，而是直接标记为"需人工介入"。这避免了LLM在不确定的情况下做出错误操作。

4.4 决策失败的降级策略

LLM不是万能的，它也会决策失败。ARTEMIS设计了一套降级策略，确保即使LLM无法处理，测试也不会完全卡死。

第一级降级是重试。如果LLM返回的决策执行失败，引擎会把失败信息加入上下文，再次请求LLM决策。最多重试2次。

第二级降级是回退到传统策略。如果LLM连续决策失败，引擎会回退到预定义的异常处理逻辑，比如"关闭当前页面，重新进入"、"跳过当前步骤，继续执行后续步骤"。

第三级降级是标记并继续。如果传统策略也无法处理，引擎会把当前步骤标记为"执行失败"，记录详细的错误信息，然后继续执行后续步骤。这样至少能保证测试流程不中断，失败的步骤可以在测试报告中单独分析。

第四级降级是终止并报告。如果失败步骤是关键步骤（比如登录），后续步骤依赖它，那么继续执行也没有意义。引擎会终止当前场景的执行，生成详细的失败报告，包括页面截图、UI层级、LLM决策历史等，供人工分析。

5. 双模式协同中的实操坑与应对

5.1 编排模式生成计划过于理想化

这是最常见的问题。LLM在编排模式下生成的测试计划，往往是"理想路径"——它假设每一步都能顺利执行，页面加载瞬间完成，元素总是可见可点击。但实际执行中，网络延迟、动画过渡、异步加载都会导致步骤失败。

应对方法是在编排模式的prompt中强制要求LLM考虑异常情况。具体做法是要求LLM为每个步骤生成"正常路径"和"异常路径"两套逻辑。正常路径是理想情况下的操作序列，异常路径则包含常见的异常处理，比如"如果元素未出现，等待2秒后重试"、"如果出现弹窗，先关闭弹窗再继续"。

另一个技巧是在测试计划中增加"弹性等待"步骤。不要假设操作后页面立即响应，而是在关键操作后插入一个"等待页面稳定"的步骤，让引擎等待页面加载完成后再继续。这个等待时间可以由LLM根据页面复杂度估算，也可以设置一个保守的固定值。

5.2 执行模式LLM调用频率失控

执行模式设计初衷是"按需触发"，但实际运行中可能出现LLM调用频率远超预期的情况。原因通常是触发条件太宽松，或者页面本身稳定性差，导致大量步骤都触发LLM介入。

控制调用频率的方法有几个。一是提高软触发的置信度阈值，减少不必要的LLM调用。二是增加"LLM调用预算"，每个场景最多允许调用LLM N次，超过后强制走降级策略。三是对触发LLM的步骤做聚类分析，如果发现某类步骤频繁触发LLM，说明测试计划在该类步骤上描述不够精确，应该回到编排模式优化计划。

我实测下来，一个设计良好的测试计划，LLM调用率应该控制在总步骤数的5%以内。如果超过10%，就需要检查是计划质量问题还是触发条件设置问题了。

5.3 页面截图质量影响LLM判断

执行模式中LLM做决策的重要依据是页面截图。但移动端截图有很多坑：分辨率太高导致token超限、截图时机不对导致页面还没渲染完、截图包含敏感信息等。

ARTEMIS的处理方式是对截图做预处理。首先压缩分辨率，把截图缩放到LLM能有效识别的最小尺寸，通常宽度控制在720px左右就够了。其次做时机控制，截图前先等待页面稳定，可以通过监听页面加载事件或者检测页面是否有动画来判断。最后做敏感信息脱敏，对截图中的手机号、身份证号等敏感区域做模糊处理。

还有一个细节是截图标注。在截图上叠加UI元素的边界框和索引编号，能显著提升LLM定位元素的准确率。ARTEMIS会在截图预处理阶段自动完成这个标注，把标注后的截图和UI层级树一起发给LLM。

5.4 两种模式之间的信息不一致

编排模式生成的测试计划，和执行模式实际遇到的情况，经常存在不一致。比如计划中描述的元素是"登录按钮"，但实际页面上显示的是"立即登录"；计划中预期跳转到首页，但实际跳转到了引导页。

这种不一致有两种处理思路。一种是"以计划为准"，执行模式尽量向计划靠拢，遇到不一致时尝试修正当前状态以匹配计划。另一种是"以实际为准"，执行模式根据实际情况灵活调整，只要最终验证目标达成即可。

ARTEMIS采用的是混合策略：对于关键步骤（如登录、支付），以计划为准，确保测试的严谨性；对于非关键步骤（如页面浏览、信息查看），以实际为准，允许LLM灵活处理。这种策略在严谨性和灵活性之间取得了平衡。

5.5 LLM决策的可解释性与审计

在自动化测试中，LLM做出的每个决策都需要可追溯、可审计。否则当测试结果出现异常时，你根本不知道是应用真的有问题，还是LLM决策失误导致的。

ARTEMIS为每次LLM决策生成一条审计日志，包含：触发决策的原因、发送给LLM的完整上下文、LLM返回的原始结果、解析后的决策、执行结果、以及LLM给出的reasoning。这些日志按测试执行批次归档，支持按场景、步骤、决策类型等维度检索。

审计日志的另一个用途是优化prompt。通过分析LLM决策失败的案例，可以发现prompt中的不足之处，比如某些约束不够明确、某些上下文信息缺失等，然后针对性地改进prompt。

6. 从零搭建ARTEMIS双模式架构的关键步骤

6.1 环境准备与依赖选型

搭建ARTEMIS双模式架构，你需要准备以下组件：

• 移动端自动化引擎：Appium是首选，跨平台支持好，社区活跃。如果只做Android，Espresso性能更好；只做iOS，XCUITest更原生。但考虑到双模式架构需要统一的执行接口，Appium的通用性更合适。
• LLM服务：需要一个支持结构化输出、响应速度可接受的LLM服务。编排模式对LLM的推理能力要求高，可以用能力更强的模型；执行模式对响应速度要求高，可以用轻量级模型。
• 截图处理工具：OpenCV用于截图压缩和标注，Pillow用于图像格式转换。
• UI层级解析工具：Appium自带的页面源获取功能可以拿到UI层级树，但需要做裁剪和格式化。
• 任务队列：用于管理LLM调用请求，避免并发过高导致服务限流。Redis或RabbitMQ都可以。

环境准备中最容易忽略的是设备农场的配置。移动端自动化测试需要真机或模拟器，设备数量、系统版本、屏幕分辨率都会影响测试结果。建议至少准备3-5台不同配置的设备，覆盖主流分辨率。

6.2 编排模式的实现骨架

编排模式的实现可以分为四个模块：

需求解析模块：接收自然语言输入，调用LLM做意图理解和场景识别，输出场景列表。

步骤生成模块：为每个场景生成操作步骤序列，调用LLM做步骤拆解和参数填充。

断言生成模块：为每个验证点生成断言逻辑，调用LLM做断言类型判断和预期值提取。

计划组装模块：把上述模块的输出组装成完整的测试计划JSON，并做Schema校验和逻辑校验。

代码结构上，建议把LLM调用封装成一个独立的服务类，统一处理prompt构建、API调用、结果解析、重试逻辑。这样编排模式和执行模式可以复用同一套LLM调用基础设施。

6.3 执行模式的实现骨架

执行模式的实现可以分为三个模块：

执行引擎适配层：封装Appium的操作API，提供统一的tap、input、swipe、assert等操作接口。这一层还负责元素定位，支持多种定位策略的依次尝试。

触发判定模块：在每个步骤执行前后做状态检查，根据触发条件判定是否需要LLM介入。这一层需要维护执行上下文，包括当前步骤、历史步骤、页面状态等。

LLM决策模块：构建上下文prompt，调用LLM获取决策结果，解析并验证决策，返回给执行引擎执行。

执行模式的关键是状态管理。你需要维护一个执行状态机，记录当前执行到哪个场景、哪个步骤、上一步的结果是什么、是否处于异常处理流程中。这个状态机是触发判定和LLM决策的基础。

6.4 两种模式的联调与验证

两种模式分别实现完成后，需要做联调验证。联调的重点是检查数据流转是否正确、异常处理是否闭环、性能是否达标。

联调验证可以分三步走。第一步是单元测试，分别测试编排模式的计划生成质量和执行模式的操作执行准确性。第二步是集成测试，用编排模式生成的计划驱动执行模式运行，检查端到端流程是否通畅。第三步是压力测试，用大量测试计划并发执行，检查LLM调用频率、执行成功率、平均执行时间等指标是否在可接受范围内。

联调中最容易发现的问题是上下文传递丢失。编排模式生成的测试计划中某些字段，在执行模式中没有被正确传递给LLM，导致LLM决策缺少关键信息。解决方法是定义一份明确的"上下文契约"，规定哪些字段必须在两种模式之间传递，并在联调中重点验证。

6.5 上线后的监控与迭代

ARTEMIS双模式架构上线后，需要持续监控几个核心指标：

这些指标异常时，需要回溯审计日志，定位是编排模式的计划质量问题，还是执行模式的触发条件或prompt问题。迭代优化的方向通常是：优化prompt减少LLM幻觉、调整触发阈值平衡效率和准确性、补充领域知识库提升计划生成质量。

我个人在实际操作中的体会是，ARTEMIS双模式架构的搭建不是一蹴而就的，前期需要大量调参和prompt迭代。但只要把编排模式的质量做上去，执行模式的LLM调用率就能控制在很低的水平，整体测试效率和稳定性都会有明显提升。另外一个小技巧是，在执行模式中给LLM的prompt里加入"历史成功决策"的示例，能显著提升LLM决策的一致性——它看到类似场景之前是怎么处理的，就更倾向于做出相同的判断。