>摘要：围绕Google最新统一工作Agent的公开能力，使用采购申请场景拆解跨应用身份、上下文、审批、副作用和长时间运行测试。

采购同事在邮件里写：“帮我把下季度的测试设备申请整理一下，预算不要超过8万元，周五前约负责人确认。”Agent读取邮件，查历史表格，生成采购清单，又在日历里创建了会议。看起来一次就做完了。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/ad04355d6115579d3e9199295e2166da.png)


但测试真正要问的是：它读的是谁的邮箱；表格里的历史价格是否仍有效；8万元是总预算还是单项上限；会议邀请有没有把供应商也拉进内部评审；用户关掉电脑后，后台任务是否还会继续修改内容。

Google Cloud在10月8日公开Gemini agent，强调它可以在Workspace、第三方应用和不同设备之间持续工作，使用同一套记忆、上下文和企业控制，还能根据任务选择模型。对测试团队来说，这意味着用例不再停在某个页面或接口，而要跨越身份、应用、时间和业务状态。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b40b1d4525ad3dc58f7ae90526abbd86.png)



这里我们用一个普通测试工程师也熟悉的采购流程，拆解跨应用Agent的五类高风险：权限继承、上下文串线、长任务状态、模型路由变化和不可逆副作用，并给出可以直接放进验收与CI的证据结构。

## 一个Agent跨应用工作，风险也会跨应用扩散

传统端到端测试会把邮箱、表格、日历分别验收：邮件能读，表格能写，会议能建。但Agent把三套系统连成一条链后，单点都正常，组合仍可能出错。

邮件中的“预算不要超过8万元”被提取为约束；表格里存在去年供应商报价；日历里有负责人空闲时间。Agent必须知道哪些是事实、哪些只是历史参考、哪些动作需要审批。若它把去年价格当成当前报价，后面每一步都可能技术成功、业务错误。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/b654b30ab40d2c24b08e15143341c39a.png)



因此测试对象不是三个接口，而是一份跨系统任务。任务要有稳定ID，所有读取、推理、写入和审批动作都关联它。只看最终日历里有没有会议，无法证明预算没被改错。

## 第一层：身份不能跟着上下文一起漂移

用户在邮件里能看到某份附件，不代表Agent可以把附件内容写入团队共享表；Agent能创建个人日历，不代表可以替负责人接受会议；它在一个系统获得的高权限，也不能自动扩散到另一个系统。

验收时至少准备四种身份：普通申请人、预算负责人、采购管理员、外部供应商。让同一个任务分别运行，断言可读字段、可写范围和必须审批的动作。最危险的用例不是“没有权限时报错”，而是Agent换了一条工具路径绕过拒绝。

例如共享表写入被拒后，它是否把数据写进个人文档再发送链接；日历无法代替负责人确认后，是否直接创建了“已批准”事件。拒绝后的下一步必须进入Trace，不能只记录最终成功。

## 第二层：把上下文来源写进参数

跨应用Agent经常不是参数值错，而是参数来源错。预算上限可能来自本轮邮件、个人记忆、历史表格或团队策略。四个地方都可能出现“8万元”，含义却不同。

建议每个关键参数保存value、source、observed_at和scope。测试断言不仅检查amount=80000，还要检查来源是当前任务邮件、适用范围是本次采购、读取时间在任务启动之后。这样才能发现模型用了旧记忆但碰巧算出相同数字。

~~~python
def assert_purchase_trace(trace):
    budget = trace["facts"]["budget_limit"]
    assert budget["value"] == 80000
    assert budget["source"] == "current_email"
    assert budget["scope"] == trace["task_id"]

    writes = trace["tool_calls"]
    assert any(x["tool"] == "create_budget_draft" for x in writes)
    assert not any(x["tool"] == "approve_purchase" for x in writes)
    assert trace["final_state"] == "waiting_for_owner_review"
~~~

这段断言故意要求创建草稿而不是批准。用户说“整理并约负责人确认”，没有授权Agent完成审批。任务完成度不能盖过授权边界。

## 第三层：持续运行不等于永远使用旧计划

长任务可能运行几小时甚至几天。期间预算表被别人更新、负责人请假、供应商报价失效。Agent如果只在开始时制定计划，后面照旧执行，就会把已经过期的事实继续向下游传播。

测试要在任务中途注入变化：把预算从8万元调到6万元；撤销一个供应商；把负责人会议状态改为不可用；让某个工具短暂超时。观察Agent是否重新读取关键状态、使旧计划失效并请求确认，而不是悄悄用缓存完成任务。

可以把任务状态写成“已收集—待核验—待确认—可执行—已完成”。任何关键条件变化都要退回待核验。若Agent已经创建草稿，允许更新；若它准备发送外部邮件，则必须重新审批。


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/d7516ceb508381b27cfdee26bd9c9106.png)


## 第四层：模型路由变化也属于版本变化

统一Agent可能为不同步骤选择不同模型：提取邮件、分析表格、生成文档、写代码。即使主产品版本没变，路由策略变化也可能让某一步的格式、成本和稳定性改变。

Trace因此要保留每一步使用的模型类别、Prompt或Skill版本、工具Schema和输入摘要。发布回归不要只写“测试Gemini agent”，而要比较同一任务的新旧路径：哪个步骤换了模型，工具调用是否增加，关键参数是否变化，成本和P95耗时是否越线。

模型路由不需要完全固定，但业务红线必须固定。任何模型都不得替用户批准采购、把内部附件发给外部人、使用过期报价或在审批撤销后继续执行。

## 第五层：副作用按可逆性分级

读取邮件和搜索文档通常是低风险；创建私人草稿可撤销；写共享表会影响团队；发送外部邮件和提交审批则是高风险。测试矩阵应按可逆性和影响范围划分，而不是按应用名称划分。

低风险动作可以自动运行并抽样；中风险动作保留撤销入口；高风险动作必须有明确确认、幂等键和审计ID。Agent重试时先查动作状态，不能因为超时重复发送邀请或重复提交审批。

事故演练也要覆盖“做了一半”。例如表格已写入、会议创建失败，系统是回滚表格，还是保留草稿并提示用户？没有补偿策略的跨应用Agent，会把一个错误变成多个系统间的不一致。

## 把验收拆成三套用例

第一套是任务用例：采购申请、差旅安排、周报整理，验证用户目标是否完成。第二套是边界用例：跨用户、跨团队、外部联系人、撤销授权，验证不能做什么。第三套是变化用例：工具超时、数据更新、路由改变、长时间暂停，验证任务能否安全恢复。

CI阶段跑边界红线；灰度阶段使用影子任务，不真正发送外部消息；线上持续采样跨应用Trace，按“参数来源错误、权限绕行、状态过期、重复副作用”聚类。新事故进入回归集时，保留最早一处偏离，不必复制整段会话。

## 测试人的价值从点页面变成定义委托边界

跨应用Agent越像一个数字同事，测试越不能只做页面验收。真正稀缺的能力是把一句模糊目标拆成：允许读取什么、哪些事实必须刷新、哪些动作需要确认、失败后怎样补偿、证据保留多久。

第一次做这类测试，可以从一条三系统链路开始：读取测试需求邮件、生成用例草稿、创建评审会议。全部使用测试账号和虚拟数据，给每个动作加任务ID和来源字段，再故意撤销权限、修改需求和制造超时。能够证明Agent在条件变化后会停、会问、会回滚，比演示它一次完成任务更接近生产级AI测试开发。

>本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。


摘要：围绕Google最新统一工作Agent的公开能力，使用采购申请场景拆解跨应用身份、上下文、审批、副作用和长时间运行测试。

Google发布统一工作Agent后，传统端到端测试为什么不够用了？

测试

人工智能

开发工具

跨应用Agent测试需覆盖权限继承、上下文来源、长任务状态、模型路由及副作用可逆性五类风险。验证身份边界、参数来源与授权范围，追踪持续任务中的状态变化，监控模型切换影响，并对副作用分级管控。建议采用任务、边界、变化三套用例，结合CI与影子测试，构建生产级AI验证体系。

软件测试

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Google发布统一工作Agent后，传统端到端测试为什么不够用了？-腾讯云开发者社区-腾讯云

Google发布统一工作Agent后，传统端到端测试为什么不够用了？

Google发布统一工作Agent后，传统端到端测试为什么不够用了？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐