这一篇看起来只是增加了一个循环，但它实际上改变了 Agent 的工作方式。以前我们可能是写好一套固定流程，让程序按照顺序执行；现在则是由模型结合执行结果决定下一步调用什么工具。不过，我并不认为把流程交给模型就意味着可以完全放开程序控制。对于测试系统来说，工具权限、执行次数、超时和结果记录仍然应该由程序控制。AI 负责理解和决策，程序负责约束和执行。两者配合，才更有机会把 AI Agent 真正用到

本文聚焦AI测试代理（AI Test Agent）的工具调用能力升级，通过引入标准的Tool Calling机制，实现大模型根据任务需求自主选择并生成结构化工具调用请求。相比此前依赖固定逻辑的任务理解，本方案将工具定义与执行解耦，支持动态注册与扩展。项目基于Python构建，集成三个订单相关测试工具：查询详情、检查金额、验证状态，验证模型在自然语言输入下准确选择工具并生成合规参数的能力。整个流程涵

在agent.py你是一个软件测试任务理解助手。你的工作是：1. 理解用户输入的软件测试需求。2. 判断应该使用哪个已注册的测试工具。3. 将任务转换为 JSON 格式。当前允许使用的工具：用途：检查订单接口响应，包括订单编号、订单金额和订单状态。规则：1. 只能选择上面列出的工具。2. 不允许编造工具名称。3. 无法匹配时，tool_name 返回 unknown。4. parameters 必

这一篇虽然没有使用大模型，但我们已经搭建了 AI Test Agent 的第一版工程骨架。一个统一的 Agent 入口。一个简单的任务理解模块。一个基础工具注册机制。一个订单接口检查工具。一套结构化执行结果。一个最小的任务执行闭环。它还不是一个真正具备自主规划能力的智能体，而是一个采用确定性规则驱动的 Agent 原型。这个区别需要明确。我更倾向于先把系统结构跑通，再逐步引入智能能力。这样每次增加