一个 Android Agent 功能怎样从需求走到稳定上线？

标准回答

我会先把自然语言需求写成可验证的任务：触发入口是什么、需要哪些系统能力、成功状态如何确认、失败时用户看到什么。例如“连接耳机并播放”，必须明确支持的设备、播放器、权限和不能自动完成时的处理，不能只以模型回复“已完成”为验收依据。

然后优先验证风险最高的链路：目标镜像能否授予权限，系统接口是否可用，设备回调是否可靠，模型能否稳定生成正确工具参数。用小范围技术验证确定边界，再拆 UI、编排、模型、工具和数据任务，明确接口、依赖和负责人，避免最后联调才发现关键能力不存在。

测试分为工具协议、任务状态机、模型行为和整机链路。固定用例验证成功路径，也覆盖权限拒绝、参数错误、弱网、重复请求、取消、进程死亡、服务重启和版本升级。模型或提示词变化要跑相同任务集；同时观察工具选择与参数正确率、端到端任务成功率、耗时和资源开销，而不只看回答是否通顺。

发布时分批放量，按版本与机型观察异常，并准备关闭新功能或降级的开关。故障日志用任务标识串联各层，避免记录不必要的原始个人内容。回退前确认数据与协议兼容；已经执行的外部动作单独核实和补偿，不能把回退程序当作撤销所有影响。

新模型回答更自然，但在测试集中更容易遗漏“确认连接成功”这一步。即使语言质量提升，也应先修正编排或工具协议，通过同口径任务验证后再放量。

我会先定义任务是否真正完成，再拆工具选择、参数有效、权限处理和结果核实等中间指标。体验看首响应、总完成时间、取消成功率和可理解的失败提示；工程上看崩溃、ANR、内存功耗与成本。用固定代表性用例和真实场景抽样共同验证，不能只用模型生成文本的评分替代动作成功率。

先确认统计口径没有变化，再按应用、模型、工具版本和机型分组，判断是否集中在某次变更或某一步。必要时暂停放量、关闭受影响功能或切换已验证的实现，同时保留任务状态和定位信息。随后复现失败样本，把根因对应的场景加入回归，确认恢复后再逐步放量。

示例能跑通不代表可交付；模型、提示词、工具 Schema、应用与系统版本都可能改变行为，需要记录能解释差异的版本组合。