摘要：围绕Google最新统一工作Agent的公开能力，使用采购申请场景拆解跨应用身份、上下文、审批、副作用和长时间运行测试。
采购同事在邮件里写：“帮我把下季度的测试设备申请整理一下，预算不要超过8万元，周五前约负责人确认。”Agent读取邮件，查历史表格，生成采购清单，又在日历里创建了会议。看起来一次就做完了。
但测试真正要问的是：它读的是谁的邮箱；表格里的历史价格是否仍有效；8万元是总预算还是单项上限；会议邀请有没有把供应商也拉进内部评审；用户关掉电脑后，后台任务是否还会继续修改内容。
Google Cloud在10月8日公开Gemini agent，强调它可以在Workspace、第三方应用和不同设备之间持续工作，使用同一套记忆、上下文和企业控制，还能根据任务选择模型。对测试团队来说，这意味着用例不再停在某个页面或接口，而要跨越身份、应用、时间和业务状态。
这里我们用一个普通测试工程师也熟悉的采购流程，拆解跨应用Agent的五类高风险：权限继承、上下文串线、长任务状态、模型路由变化和不可逆副作用，并给出可以直接放进验收与CI的证据结构。
一个Agent跨应用工作，风险也会跨应用扩散
传统端到端测试会把邮箱、表格、日历分别验收：邮件能读，表格能写，会议能建。但Agent把三套系统连成一条链后，单点都正常，组合仍可能出错。
邮件中的“预算不要超过8万元”被提取为约束；表格里存在去年供应商报价；日历里有负责人空闲时间。Agent必须知道哪些是事实、哪些只是历史参考、哪些动作需要审批。若它把去年价格当成当前报价，后面每一步都可能技术成功、业务错误。
因此测试对象不是三个接口，而是一份跨系统任务。任务要有稳定ID，所有读取、推理、写入和审批动作都关联它。只看最终日历里有没有会议，无法证明预算没被改错。
第一层：身份不能跟着上下文一起漂移
用户在邮件里能看到某份附件，不代表Agent可以把附件内容写入团队共享表；Agent能创建个人日历，不代表可以替负责人接受会议；它在一个系统获得的高权限，也不能自动扩散到另一个系统。
验收时至少准备四种身份：普通申请人、预算负责人、采购管理员、外部供应商。让同一个任务分别运行，断言可读字段、可写范围和必须审批的动作。最危险的用例不是“没有权限时报错”，而是Agent换了一条工具路径绕过拒绝。
例如共享表写入被拒后，它是否把数据写进个人文档再发送链接；日历无法代替负责人确认后，是否直接创建了“已批准”事件。拒绝后的下一步必须进入Trace，不能只记录最终成功。
第二层：把上下文来源写进参数
跨应用Agent经常不是参数值错，而是参数来源错。预算上限可能来自本轮邮件、个人记忆、历史表格或团队策略。四个地方都可能出现“8万元”，含义却不同。
建议每个关键参数保存value、source、observed_at和scope。测试断言不仅检查amount=80000，还要检查来源是当前任务邮件、适用范围是本次采购、读取时间在任务启动之后。这样才能发现模型用了旧记忆但碰巧算出相同数字。
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已经创建草稿，允许更新；若它准备发送外部邮件，则必须重新审批。
第四层：模型路由变化也属于版本变化
统一Agent可能为不同步骤选择不同模型：提取邮件、分析表格、生成文档、写代码。即使主产品版本没变，路由策略变化也可能让某一步的格式、成本和稳定性改变。
Trace因此要保留每一步使用的模型类别、Prompt或Skill版本、工具Schema和输入摘要。发布回归不要只写“测试Gemini agent”，而要比较同一任务的新旧路径：哪个步骤换了模型，工具调用是否增加，关键参数是否变化，成本和P95耗时是否越线。
模型路由不需要完全固定，但业务红线必须固定。任何模型都不得替用户批准采购、把内部附件发给外部人、使用过期报价或在审批撤销后继续执行。
第五层：副作用按可逆性分级
读取邮件和搜索文档通常是低风险；创建私人草稿可撤销；写共享表会影响团队；发送外部邮件和提交审批则是高风险。测试矩阵应按可逆性和影响范围划分，而不是按应用名称划分。
低风险动作可以自动运行并抽样；中风险动作保留撤销入口；高风险动作必须有明确确认、幂等键和审计ID。Agent重试时先查动作状态，不能因为超时重复发送邀请或重复提交审批。
事故演练也要覆盖“做了一半”。例如表格已写入、会议创建失败，系统是回滚表格，还是保留草稿并提示用户？没有补偿策略的跨应用Agent，会把一个错误变成多个系统间的不一致。
把验收拆成三套用例
第一套是任务用例：采购申请、差旅安排、周报整理，验证用户目标是否完成。第二套是边界用例：跨用户、跨团队、外部联系人、撤销授权，验证不能做什么。第三套是变化用例：工具超时、数据更新、路由改变、长时间暂停，验证任务能否安全恢复。
CI阶段跑边界红线；灰度阶段使用影子任务，不真正发送外部消息；线上持续采样跨应用Trace，按“参数来源错误、权限绕行、状态过期、重复副作用”聚类。新事故进入回归集时，保留最早一处偏离，不必复制整段会话。
测试人的价值从点页面变成定义委托边界
跨应用Agent越像一个数字同事，测试越不能只做页面验收。真正稀缺的能力是把一句模糊目标拆成：允许读取什么、哪些事实必须刷新、哪些动作需要确认、失败后怎样补偿、证据保留多久。
第一次做这类测试，可以从一条三系统链路开始：读取测试需求邮件、生成用例草稿、创建评审会议。全部使用测试账号和虚拟数据，给每个动作加任务ID和来源字段，再故意撤销权限、修改需求和制造超时。能够证明Agent在条件变化后会停、会问、会回滚，比演示它一次完成任务更接近生产级AI测试开发。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
