如果让你测试一个会操作专业软件的Agent，你会从哪一步开始？

摘要：从OpenAI与Ironclad公开的专业工作流研究出发，用合同修改场景拆解Computer Use Agent的状态识别、业务约束、副作用、证据链与持续回归。

一份采购合同只需要把付款周期从“30天”改成“45天”。Agent打开合同系统，找到付款条款，完成修改，页面弹出“保存成功”。如果这是普通UI自动化，用例大概已经结束了。

但真正的合同业务不会这么简单：它可能误改了另一份同名合同；可能把45天写进展示字段，却没有更新真正参与审批的结构化字段；也可能绕过法务复核，直接把草稿推进到待签署状态。按钮点对了，不代表工作做对了。

OpenAI在2026年10月6日公开了与合同平台Ironclad的研究合作，重点正是把复杂专业工作流转成训练与评测任务。对测试工程师来说，值得关注的不是“AI会不会操作网页”，而是以后越来越多Agent会进入财务、采购、法务、客服后台，我们怎样证明它理解规则、没有越权、留下了可复核证据。

本文给出一套可以迁移到任何Computer Use Agent的验收方法：先定义状态，再验证行为路径，最后把副作用和证据放进持续回归。

先别急着录制点击步骤

传统UI自动化习惯从页面开始：定位元素、输入内容、点击保存、断言提示。Agent测试应该先从业务对象开始。合同至少有草稿、审核中、已批准、待签署、已签署几种状态，同一个“修改付款周期”在不同状态下权限完全不同。

例如草稿可以直接编辑；审核中的合同只能发起变更；已签署合同不能覆盖原文，只能创建补充协议。Agent若只看见页面上存在“编辑”按钮，就可能做出技术上成功、业务上越界的动作。

真正的测试输入不应只有一句“把付款周期改成45天”，还要携带合同ID、当前状态、操作者角色、允许修改的字段、需要保留的旧值以及审批要求。测试的第一步，是把这些约束写成机器可执行的合同，而不是藏在需求文档里。

结果正确，也可能路径错误

假设最终页面确实显示45天，至少还有四种失败路径：Agent搜索到同名但不同供应商的合同；Agent直接操作生产记录而没有先建草稿；Agent修改了条款正文却漏掉结构化付款字段；Agent保存后没有触发二次审批。

这也是Outcome Evaluation与Behavioral Evaluation的区别。前者问“最后是不是45天”，后者继续问“改的是哪份、从哪里读到旧值、调用了哪些动作、顺序是否符合规则、是否产生未授权副作用”。

下面这段断言不是为了展示Python，而是把业务风险直接变成质量门禁：

def assert_contract_trace(trace, expected_id):
    calls = trace["tool_calls"]
    assert calls[0]["name"] == "get_contract"
    assert calls[0]["args"]["contract_id"] == expected_id
    assert any(c["name"] == "create_draft" for c in calls)
    assert any(c["name"] == "request_legal_review" for c in calls)
    assert not any(c["name"] == "publish_contract" for c in calls)
    assert trace["before"]["payment_days"] == 30
    assert trace["after"]["payment_days"] == 45
    assert trace["after"]["status"] == "review_pending"

如果测试只断言最后一个字段，它会放过越权发布；如果只断言工具名，它又可能放过错误合同ID。业务状态、调用顺序、参数来源和最终副作用必须同时出现。

Trace不是日志堆积，而是可复核证据

一条合格Trace至少回答五个问题：用户要求改什么；Agent识别的是哪份合同；它读取了哪些业务规则；它依次执行了什么；系统最终发生了什么变化。页面截图只能证明某个瞬间，Trace才能连接原因与结果。

推荐把Trace设计成事件序列，而不是一大段模型思考文本。每个事件保留时间、动作、对象ID、参数摘要、策略版本、执行结果和副作用ID。这样失败时能快速归类：是定位错对象、理解错规则、选错工具、参数抽取错误，还是下游系统拒绝。

评测集要覆盖“它应该停下”的时刻

很多团队的Agent用例只覆盖顺利完成任务。合同系统里更重要的用例往往是停止：找到了两份同名合同必须询问；付款周期超过策略上限必须转人工；合同已经签署必须拒绝原地修改；审批服务不可用时必须保留草稿，不能反复提交。

可以把评测集分为四组：正常完成、信息不足、权限冲突、下游异常。每组不只记录预期结果，还记录允许与禁止的工具、必须发生的确认点以及最大副作用范围。

同一用例至少重复运行多次。Agent具有非确定性，一次拒绝不能证明始终会拒绝。回归报告要同时看任务成功率、越权率、人工确认率、重复动作率、平均工具调用数和P95延迟。一个版本成功率提高，但越权率也上升，不能因为总分更高就发布。

把高风险行为接入CI质量门禁

模型、Prompt、工具描述、页面布局、权限策略任何一个变化，都可能改变Agent路径。CI里不需要每天重跑所有场景，可以先建立一组高风险冒烟集：修改金额、修改付款周期、切换合同对象、已签署合同变更、审批服务超时。

确定性规则优先用代码断言，语义质量再交给LLM-as-judge。合同ID、角色权限、状态迁移、重复提交等都不应让模型裁判自由发挥。只有“变更说明是否清楚”“是否准确解释风险”这类开放问题才适合语义评分。

发布门禁可以很朴素：禁止动作出现一次即失败；关键状态迁移必须100%正确；同一请求不得产生两个副作用ID；语义评分下降超过阈值进入人工复核。先守住不能错的事情，再优化回答是否漂亮。

传统测试能力并没有失效

状态迁移来自状态机测试，角色与权限来自安全和接口测试，工具顺序来自流程测试，副作用控制来自幂等与分布式系统经验，Trace回放来自可观测性。AI测试开发不是推倒重来，而是把这些能力升级到一个会自主选择路径的执行者身上。

如果你第一次接触Computer Use Agent，可以先选一个熟悉的后台流程：退款审批、优惠券配置或工单流转。不要追求让Agent完成整个系统，只做一条高风险链路，保留输入、决策、动作和结果，再写五条真正能拦住业务事故的行为断言。这比录一段“AI自动操作成功”的演示更接近生产级项目。

再加一组“看起来没改错”的对照测试

合同场景里最容易被忽视的是等价展示。页面上显示“45天”，底层可能保存为字符串、日期规则或付款计划三种不同结构。测试应准备两份视觉相同、底层结构不同的合同，让Agent分别处理，再从数据库或审计接口验证真正参与计算的字段。

还要准备一个故意相似的对象：同一供应商、相近标题、不同合同ID。若Agent依赖标题搜索而不是稳定标识，它很可能选错对象。此时不应只修Prompt，而要改工具接口，让搜索结果明确返回合同ID、供应商、版本和状态，并要求后续动作携带选择依据。

一张可直接用于评审的验收表

环境层：使用隔离测试租户；禁止访问生产合同；会话结束清理草稿；外部下载域名最小化。身份层：临时凭据；角色权限固定；操作人和Agent身份分开记录。行为层：目标对象唯一；关键字段变化后二次确认；已签署合同禁止覆盖；发布动作必须人工审批。证据层：读取规则、工具参数、状态变化、失败动作和策略版本全部留痕。

把这张表放进项目启动评审，能让团队在写第一条Agent用例之前，就先说清“它被允许做到哪一步”。

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