文档中心

Appearance

控制台

验证智能体实例 ​

智能体开发服务平台（AgentWorks）使用已经创建的智能体实例进行测试。生产接入前，请先创建测试实例，并验证模型回复、多轮会话、工具审批、中断和已配置能力。

在 Playground 中验证对话 ​

  1. 打开目标智能体实例。
  2. 选择 Playground。
  3. 等待连接状态显示 已连接。
  4. 发送一组固定测试问题。
  5. 验证回复内容、追问行为和多轮上下文。
  6. 对工具调用确认中断可以显示，并能完成人工批准或拒绝。

使用固定测试集可以在修改模型、提示词或能力后比较结果。至少覆盖正常输入、缺失信息、越权请求和外部能力失败。

验证微应用界面 ​

仅当智能体模板已经把沙箱标记为微应用时执行本节。API 或渠道测试不能代替 Playground 中的微应用验收。

  1. 确认智能体实例已经采用最新模板配置。
  2. 打开 Playground，等待连接成功，并确认微应用界面完整加载，没有空白区域或加载错误。
  3. 使用虚构数据完成一次新增、修改或查询，并确认界面显示预期结果。
  4. 如果使用现有沙箱实例，确认所有引用方确实可以共享该沙箱内的微应用状态；否则改用 沙箱 - 模板。

选择 微应用 不会创建或部署界面。没有兼容沙箱环境时，不要启用该选项。

使用 API 调试验证请求 ​

  1. 选择智能体实例的 API 调用。
  2. 在 API 调用状态 中开启 API 调用。
  3. 选择 生成临时 Token。
  4. 在 调试 中发送非流式和流式请求。
  5. 保存返回的 session_id，继续发送第二轮请求。

临时调试 Token 只用于控制台调试，并在页面显示的有效期后失效。业务系统上线时选择 创建正式 Token。

验证工具审批 ​

工具审批由智能体模板的 工具权限 统一控制，不再依赖沙箱或能力侧审批开关。先在测试调用的 Trace 中核对实际工具名称和顶层参数。不要用一种接入方式的测试结果代替另一种接入方式的验收。

本节用于确认你填写的工具名称、参数和规则边界正确，并且配置已经应用到目标实例；不要求你重新验证 AgentWorks 的拒绝实现。

  1. 让智能体发起一次低风险测试调用，在 Trace 中记录可调用名称和实际顶层参数。
  2. 配置匹配允许规则的低风险调用，确认自动批准并且只执行预期工具和参数。
  3. 发起匹配拒绝规则的调用，确认 Trace 将这项调用标记为拒绝。
  4. 把默认处理设为 审批，发起一项规则未命中的低风险调用，确认它进入人工审批。分别在两个新会话中批准和拒绝：批准时只执行预期工具，拒绝时确认界面和 Trace 显示拒绝结果。
  5. 关闭所有规则并把默认处理设为 未指定，确认人工审批关闭；只在测试实例执行这项检查。
  6. 对参数表达式测试边界值、空值、相似前缀和异常输入，并核对中断和最终结果。
  7. 使用渠道时，另行验证渠道用户规则只会补充自动批准；拒绝或未命中的调用仍交给人工处理。
  8. 更新模板后，同步或重启已有实例，再用固定请求确认新规则已经生效。

在 Playground 中按界面显示的中断完成人工确认。使用 Invoke API 时，调用方还要分别验证 APPROVE 和 REJECT 响应。使用 WebSocket 时，在两个无副作用的单项调用中分别提交这两个决定，并确认两次运行都返回 done: true；没有终止帧时不要重发，按 WebSocket 中断恢复步骤停止处理。使用渠道时，应使用目标渠道和目标用户验证自动处理顺序。字段来源参见找到工具名称和参数名，完整配置方法参见配置工具审批流程。

AgentWorks 将调用判定为拒绝，或者审批人选择拒绝后，不会调用目标工具。Playground 界面或 Trace 可能把拒绝结果显示为失败或 error；这不表示工具已经执行后发生错误。智能体仍可能根据对话中的已有信息继续回答。

验证 Playground 中的多个审批调用 ​

注意

只在专用测试智能体中验证

使用两个互不依赖、没有副作用的只读 MCP 调用。开始前记录原有工具权限规则和默认处理；如果无法确认智能体为测试专用、调用没有副作用或原配置可以恢复，请停止测试。

  1. 把默认处理设为 审批，并确认两个测试调用都不会命中允许或拒绝规则。保存并重启智能体模板，再按手动应用新配置把变更应用到测试实例。
  2. 使用固定请求让模型在同一轮发起两项调用。
  3. 按工具名称和唯一参数区分两项待审批记录，确认各自参数符合预期。在 Playground 中按待审批记录标识操作；在 Trace 中另按工具名称、参数和发生时间查找对应调用。
  4. 在三个新会话中分别测试全部批准、全部拒绝，以及批准一项并拒绝另一项。
  5. 每次提交第一项决定后，确认另一项仍然等待处理；所有调用都有决定后，智能体才继续运行。
  6. 在 Trace 中把声明的 tool_calls[].id 与工具结果的 tool_call_id 对应起来。确认批准项有预期远端结果，拒绝项只有拒绝结果且不含远端内容。只有在同时检查服务端或出站调用记录后，才把结果表述为精确执行次数。
  7. 再开始一个新会话，在两项都等待审批时刷新浏览器。重新打开 Playground 并选择原会话，确认两项仍然存在，再完成审批。
  8. 恢复开始时记录的工具权限规则和默认处理，重新保存并同步测试实例。发起一项低风险调用，确认原有自动处理方式已经恢复。

完成 Playground 验收后，还需要分别验收 Direct Invoke、WebSocket 和计划使用的渠道。

验证多个工具调用与结果的关联 ​

这项测试验证一个调用任务中的多个自动执行工具调用是否与各自结果正确关联。它不验证这些调用是否来自同一轮模型响应，也不验证工具是否同时执行。模型是否发起多个调用取决于所选模型、模型接口和测试请求。

  1. 选择支持一次返回多个工具调用的模型，并准备两个互不依赖、没有副作用的只读工具。
  2. 发送一个需要结合两个工具结果才能回答的固定测试请求。
  3. 在 API 调试响应中，确认自动执行的 tool_calls 包含多个不同的 id，并按 id 在 tool_call_results 中找到各自结果。通过渠道测试时，确认每个调用的状态和结果分别显示。
  4. 此处的结果关联用例仍使用自动执行工具。Playground 多项审批按上一节单独验证；Direct Invoke 或 WebSocket 中出现多个待审批 tool_calls 时，停止响应并保存原始负载和任务状态。
  5. 不要根据 tool_calls 中有多项、卡片同时显示多项或调用总耗时，推断这些调用来自同一轮模型响应或工具并发执行。

在 Trace 中检查执行过程 ​

打开 Trace，检查一次调用中的模型、工具和耗时信息。重点确认：

  • 使用了预期模型。
  • 工具参数符合预期的工具权限规则。
  • 知识库或 MCP 返回内容被正确使用。
  • 中断发生在高风险操作之前。
  • 错误位置与用户看到的结果一致。

Trace 是运行诊断信息，不是自动评测或质量优化系统。需要质量基准时，团队仍需维护测试集和验收标准。

检查能力运行记录 ​

根据所用能力继续检查：

  • 沙箱：沙箱运行记录。
  • 知识库：在 构建历史 中检查 状态，并选择 日志。
  • 渠道：检查 会话管理 和 用户绑定。
  • API 调用：在 API 调用状态 中确认服务已开启，再检查调用任务状态和流式结束事件。

通过生产验收清单 ​

只有以下条件全部满足后再切换生产流量：

  • 通过计划使用的 Playground、API 或渠道完成代表性调用，并收到预期的最终结果。
  • 在 Trace 中找到对应运行，并确认模型和已配置能力的调用结果符合预期。
  • 固定测试集通过。
  • 外部能力凭证和地址使用生产配置。
  • 已配置微应用时，界面操作和沙箱共享边界已经通过测试。
  • 正式 Token 已创建且只交付给调用服务。
  • 监控人员知道如何查看 Trace、状态和运行记录。
  • 团队记录了上一个可用配置和手动回退方法。

参见将智能体投入生产。