判断模型能否配合agent使用，关键是验证其能否稳定执行最小工具调用闭环：识别指令→选择工具→填充参数→解析返回→生成结构化响应；需依次通过协议理解、返回解析、上下文维持、条件分支四步测试。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在 AgentSpace 平台中判断一个模型能否配合当前 Agent 使用，核心不是看模型参数量或是否支持 JSON 模式，而是验证它能否稳定执行该 Agent 所需的最小工具调用闭环：识别指令→选择工具→填充参数→解析返回→生成结构化响应。平台不依赖模型自报能力，而是通过运行时行为反推兼容性。
第一步：确认模型是否具备基础工具调用协议理解力
进入 Agent Designer → 选择目标 Agent → 点击「测试环境」→ 在输入框中粘贴标准工具调用测试指令：
“请调用【查合同状态】工具，contract_id 为 CT-2026-8891，返回字段仅保留 status 和 last_updated。”
这一步必须严格使用平台预设的工具名和字段名，不能改写、缩写或加解释。如果模型返回自由文本（如“我已查询合同 CT-2026-8891”），或尝试自行构造 JSON 但 key 名错误（如写成 “state” 而非 “status”），说明【未启用或未对齐平台工具协议】，直接终止后续测试。
第二步：验证工具返回内容的可解析性
方法一：人工注入模拟工具响应
在测试环境中点击「模拟工具返回」→ 输入以下 JSON：
{"status": "pending_review", "last_updated": "2026-08-30T14:22:05Z", "reviewer": "zhang.li"}
观察模型是否只提取并复述 status 和 last_updated 两个字段，且不带额外解释、不补全缺失字段、不擅自转换时间格式。若出现“审核中”“待审阅”等意译，或把时间转成“8月30日下午2点”，说明【模型正在做语义泛化而非字段直取】，该模型不适合用于强结构化输出场景。
方法二：连接真实工具后观察原始日志
在「执行层」打开实时日志面板 → 触发一次真实工具调用 → 查看模型收到的 raw input 是否完整包含工具说明、schema 和本次返回体。常见失败是模型把 200 行 JSON 响应压缩成 3 行摘要，导致后续步骤丢失 reviewer 字段——这种截断行为在审批流类 Agent 中会引发权限校验中断。
第三步：检查多步任务中的上下文维持能力
① 给出初始指令：“查销售员王磊近三个月的签约单数，再列出其中金额超 50 万的合同编号。”
② 模型调用【查销售员签约统计】工具，返回 {“total”: 12, “list”: [“CT-2026-7011”, “CT-2026-7012”, …]}。
③ 模型必须基于上一步返回的 list 子集，精准发起第二次工具调用，参数为 contract_id 数组，而非重新搜索“王磊”或“50 万”。
这一步失败率最高。很多模型在第二步会忽略前序工具结果，转而重写自然语言查询，导致平台无法匹配到已加载的工具接口。只要出现“帮我找一下王磊签的高价合同”这类表述，就证明【模型未将工具返回纳入 active context，仅作提示词装饰】。
第四步：触发一次带条件分支的工具链
部署一个含 if-else 的简单流程：当合同 status 为 “signed” 时调用【归档】工具；为 “pending_review” 时调用【通知法务】工具。
输入 contract_id = CT-2026-8891，其真实 status 是 pending_review。
正确响应必须是调用【通知法务】工具，且参数中包含 reviewer 字段值。若模型调用【归档】工具，或调用【通知法务】但漏传 reviewer，说明它无法从 JSON 响应中提取布尔条件路径——这种模型只能用于单步问答类 Agent，不能接入审批、工单、合规等需状态驱动的业务流。
