【寻迹校园 HarmonyOS NEXT 实战 47】小艺 Agent 审核驳回复盘：工作流“有输出”为什么智能体“无回复”

本章导读：这是“寻迹校园 HarmonyOS NEXT 实战”系列第 47 篇。本文复盘“寻迹校园匹配助手”首轮审核被驳回后的修复过程：大模型节点单独调试可以产出字符串，审核人员使用“你能做什么？”和失物寻找类问题时，智能体却没有形成可见回答。根因不在一个节点是否生成内容，而在功能说明、开场引导、工作流路由、结束节点返回契约和最终对话表面是否连成完整链路。

上图是原创工作流故障概念图，不是开放平台截图。上半路表示节点内部已有数据但可见回复出口断裂，下半路表示修复返回契约后数据到达对话气泡。

一、先把审核反馈翻译成工程问题

首轮问题不是笼统的“AI 不够聪明”，而是两类可验证缺口：

• 功能描述与开场引导不够清晰，审核人员难以知道该怎样发问；
• 审核测试问题没有得到有效可见回复。

工程上应把它们拆为入口契约和输出契约。入口契约回答“什么问题会进入哪条工作流”，输出契约回答“工作流内部结果如何变成用户看到的文本”。

只调整模型提示词，却不检查结束节点和对话表面，可能继续得到“节点有输出、智能体无回复”。

二、“节点测试成功”只证明局部

模型节点直测看到字符串，最多证明：输入变量存在、模型调用成功、该节点产生了某种输出。它不证明：

• 用户问题路由到了这条工作流；
• 输出变量名与后续节点引用一致；
• 结束节点使用了正确返回类型；
• 结果被序列化为对话文本；
• 审核账号和已提交版本使用的是同一工作流版本。

因此“节点里有字”与“用户看到回复”之间至少隔着路由、变量映射、结束契约和版本绑定四层。

三、复现问题时必须使用审核原句

内部测试经常使用开发者熟悉的长提示词，而审核人员可能只问“你能做什么？”、“帮我找失物”或输入一个很短的场景。

复现应至少包含三类用例：

用例	目的
能力询问	验证开场和功能说明是否能被理解
典型失物寻找	验证主工作流路由与输出
缺少候选或信息不足	验证可解释的边界回复

如果只用一条精心构造的内部样例，无法解释审核环境为什么失败。

四、第一轮修复：先修产品入口

项目首先补齐功能说明、开场语和三条引导问题。目标不是堆营销文案，而是让用户和审核人员在第一屏就知道：

• 智能体比较的是脱敏候选；
• 它输出相似点与冲突；
• 它不会判断物品归属；
• 没有候选时应返回原生 App 继续查询。

入口说明明确后，“你能做什么？”不应掉入无上下文的业务模板，而应返回简洁能力边界和下一步示例。

五、第二轮修复：检查路由提示和输入结构

接着检查工作流的路由描述。路由提示需要覆盖审核可能使用的自然表达，而不是只匹配内部函数名或固定术语。

同时核对输入变量是否允许短问句进入。当候选摘要不存在时，工作流也应输出边界说明，而不是因变量为空直接结束。

这一轮能修复“问题没有进入目标工作流”，但如果结束节点契约仍错，内部链路可能有结果，用户仍看不到回答。

六、第三轮修复：从“返回变量”改为“返回文本”

最终关键改动位于结束节点。原流程使用“返回变量”，内部调试可以看到 output，但对话表面没有获得预期文本。修复后改为返回文本，并显式插入输出变量：

返回文本：${output}

这不是简单换一个 UI 选项。它把工作流内部变量转换成面向对话界面的文本契约，让宿主知道最终要展示什么。

公开文章只保留变量结构，不公开真实 Agent ID、Workflow ID、账号或平台成员信息。

七、为什么结构化变量可能没有自动显示

工作流引擎内部的对象、数组或变量引用，不一定等同于最终自然语言消息。不同结束类型可能服务于 API、分支衔接、内部调试或用户对话。

如果目标是用户可见回答，结束节点必须明确产出可呈现文本。即使 output 本身已经是字符串，也应验证变量插值、空值和换行处理，不能只看节点面板中的预览框。

八、三轮最小修复时间线

上图从左到右表示：入口说明与引导、路由与变量核对、返回文本契约修复，最后才进入预览验证和重新提交。它表达的是修复顺序，不是平台审核成功截图。

九、为什么坚持一次只改一个关键变量

审核问题出现后，如果同时重写提示词、替换模型、改路由、改节点结构和换版本，就无法知道哪项修复真正生效。

本次采用最小修复循环：

1. 用审核原句复现；
2. 修改一个最可能的阻塞点；
3. 在同一入口重测；
4. 记录可见输出；
5. 再决定是否进入下一轮。

这种做法比“整体重做一个 Agent”更适合审核驳回复盘，也减少新风险。

十、预览通过的验收标准

项目在修复后的 V6 预览中，分别使用审核原句和失物寻找类问题测试。验收不只看日志，而是看最终对话界面是否出现与问题对应的完整回复。

最低检查项包括：

• 能力询问有明确能力与边界说明；
• 失物场景能进入匹配助手的任务语境；
• 输出不是空字符串、变量名或对象序列化残片；
• 无候选时给出返回原生 App 的下一步；
• 回复不声称已经判定物品归属。

只有最终可见文本通过，才说明“工作流输出到对话表面”的链路闭合。

十一、预览通过不等于审核通过

2026-08-17 的项目记录只能证明：V6 预览对两类测试问题返回了有效答复，随后重新进入审核。这个阶段不应写成“已审核通过”或“真机已生效”。

随后用户在 2026-08-20 明确确认平台显示“已上架”，同日真机又完成系统小艺拉起和可见回复。这里仍要保留证据来源差异：平台“已上架”来自用户确认，真机行为来自本地验收记录；本文准备时没有重新登录平台独立回读该状态。

十二、版本绑定是最容易漏掉的第四层

工作流编辑器中的最新版本、智能体预览使用的版本、审核提交绑定的版本和真机实际命中的版本可能不同。

因此每次修复都应记录：

• 哪个工作流版本包含修复；
• 智能体是否绑定该版本；
• 预览是否清空旧上下文；
• 重新提交是否使用该版本；
• 真机回复是否能归因于新会话和新输入。

否则“编辑器里已经改了”可能只是未发布草稿。

十三、不要让历史会话伪造成功

系统小艺可能保留旧会话内容。测试时如果打开已有对话并看到一段历史回复，不能证明本次工作流调用成功。

更稳的做法是使用空白新会话，输入审核原句，确认发送时间、回复内容和当前输入一致。候选比较还要包含本次摘要中的独有特征，才能排除通用回复或历史残留。

十四、App 侧也要保留独立边界

即使云端 Agent 审核通过，App 侧仍需支持性检查、错误映射、脱敏和原生回退。云端工作流不能直接接触长期业务状态，也不能自动确认归属、接受认领或完成交接。

本项目只把最多 3 条、240 字以内的脱敏摘要交给小艺。回复用于辅助比较，不写回 Repository。审核通过只代表能力入口达到平台要求，不代表业务授权边界可以放宽。

十五、审核材料应该如何准备

一份可复核的修复说明应包含：

• 原始反馈的逐条拆解；
• 修复前可复现的失败现象；
• 每轮最小改动与目标；
• 工作流版本和绑定关系；
• 审核原句的最终可见回复；
• 隐私、归属判断和无候选边界；
• 仍未验证的设备、账号和地区条件。

不要只写“已优化提示词，请复审”，那无法帮助审核人员快速验证。

十六、常见误判清单

以下证据都不能单独证明对话链路成功：

• 模型节点 token 正常消耗；
• 工作流日志显示执行结束；
• 内部变量面板出现字符串；
• Agent 编辑器保存成功；
• V6 已创建；
• App 构建通过；
• FunctionComponent 可见；
• 旧会话中存在历史回复。

最终成功标准必须落到目标用户可见的当前回复，同时保留平台审核状态的独立证据。

十七、当天项目验证边界

2026-08-28，项目本地自动化与完整 APP 构建通过；当天没有连接 HDC 设备，因此没有重新执行系统小艺真机对话，也没有重新读取智能体开放平台状态。

本文使用的是日期明确的历史审核和真机记录，未把它们冒充为当天新验证。平台状态易变化，后续再次提交或升级工作流时，应重新回读版本和审核状态。

十八、建立“输入—路由—输出”证据表

每轮修复最好保留一张小表，而不是只截最终成功画面。表中记录测试输入、命中的工作流版本、模型节点是否有值、结束节点类型、最终可见文本和结论。这样下一次平台改版或版本绑定异常时，可以判断故障发生在入口、内部执行还是呈现出口。

例如，能力询问已经进入目标工作流、模型也生成了说明，但最终气泡为空，就应优先检查结束节点和变量插值；如果工作流根本没有执行，则先检查路由与绑定版本。证据表能避免所有问题都回到“继续改 Prompt”。

修复完成后还应加入一个反向用例：输入与失物招领无关的问题，确认智能体不会强行编造候选或越过能力边界。这既是质量检查，也是审核合规的一部分。

十九、从本次复盘得到的工程方法

对“工作流有输出、智能体无回复”这类问题，可以固定按以下顺序排查：

审核原句 -> 路由命中 -> 输入变量 -> 模型输出
        -> 结束节点类型 -> 文本插值 -> 版本绑定
        -> 空白新会话可见回复

从用户可见结果向内追，比只盯着大模型节点更快定位真实断点。

二十、适用范围与未证明项

本文能证明本项目曾通过修改功能说明、引导问题、路由提示和结束节点返回文本，使 V6 预览恢复可见回复，并完成后续提交；也能证明后续真机上目标智能体可以被拉起并返回可见内容。

本文不能证明未来平台版本仍使用完全相同的节点契约，不能证明所有审核账号和地区行为一致，也不能把用户确认的“已上架”替代为本轮独立平台回读。

二十一、小结

审核驳回最有价值的地方，是迫使团队把“内部有数据”和“用户得到回答”分开。真正的成功链路必须同时满足入口可理解、路由可命中、变量可传递、结束节点可呈现、版本已绑定和新会话可见。

寻迹校园最终把“返回变量”修成明确的“返回文本 ${output}”，并用审核原句验证对话表面。这次复盘的核心不是某个按钮，而是一种证据纪律：每一层只证明自己的结论，不能越级替下一层背书。

下一篇：《【寻迹校园 HarmonyOS NEXT 实战 48】不新增测试依赖：用 Node Loader 直接测试生产 ArkTS 纯规则与状态机》。