夜雨聆风普通聊天机器人主要是在“回答问题”，AI Agent 则是在“完成任务”。
这句话听起来只差几个字，但工程含义完全不同。回答问题时，模型只要生成一段文本；完成任务时，模型需要理解目标、拆解步骤、调用工具、观察结果、继续决策，最后把事情办完。
一个生活化例子
如果你对普通聊天机器人说：
帮我规划一下明天去上海出差的行程。它可能会给你一段建议：
建议早上乘坐高铁，中午到达后先去酒店，下午安排客户拜访，晚上整理会议纪要。
这叫“给建议”。
如果你对 Agent 说同样的话，它可能会继续做这些事：
查询明天高铁或航班。
根据你的日历避开已有会议。
查询客户公司地址。
预估路程时间。
帮你生成行程表。
在需要时发起订票或提醒你确认。
这叫“执行任务”。
Agent 的核心不是“更会聊天”
很多人第一次听 Agent，会以为它只是一个更聪明的聊天机器人。其实 Agent 的关键能力不是闲聊，而是闭环。
一个典型 Agent 循环可以写成：
目标 -> 思考下一步 -> 调用工具 -> 观察结果 -> 再决定下一步 -> 完成或停止
在工程里，这个循环通常包括：
| 能力 | 通俗解释 | 例子 |
|---|---|---|
| 目标理解 | 知道用户到底要达成什么 | “查投诉并生成建议”不是只写建议 |
| 计划拆解 | 把大任务拆成小步骤 | 先查客户，再查工单，再总结 |
| 工具调用 | 使用外部能力 | 查数据库、调用 API、读文件、发邮件 |
| 状态管理 | 记住任务进展 | 已经查过哪些系统、下一步是什么 |
| 自我修正 | 出错后能重试或换路 | 接口超时后重试，参数错了重新生成 |
| 停止判断 | 知道什么时候完成 | 不无限循环，也不半途结束 |
OpenAI Agents SDK、LangChain Agent、LangGraph、AutoGen、CrewAI 等框架，虽然实现方式不同，但基本都围绕这个循环展开。
Agent = 模型 + 工具 + 运行时 Harness
LangChain 文档里有一个很直白的说法：Agent 是模型在循环中调用工具直到任务完成，而 Harness 是围绕这个循环的一切，包括模型、提示词、工具和中间件。
换成测试工程师熟悉的话：
模型只是大脑，Agent 运行时才是身体和手脚。
没有工具，模型只能说；有了工具，它才能查、算、写、改、提交。
Agent 和工作流有什么区别
AI Agent 经常和 Workflow 混在一起讲。两者都可以自动化任务，但决策方式不同。
| 对比项 | 传统工作流 | AI Agent |
|---|---|---|
| 步骤 | 预先写死 | 可由模型动态决定 |
| 分支 | 明确配置 | 根据上下文判断 |
| 适合场景 | 稳定、规则清楚 | 开放、步骤不完全固定 |
| 风险 | 逻辑写错 | 模型误判、工具误用 |
| 测试重点 | 分支覆盖 | 目标完成率、工具调用正确率 |
比如发票审批流程，规则很明确，适合传统工作流。客户投诉分析，可能要查多个系统、判断投诉类型、结合上下文写建议，更适合 Agent 或“工作流 + Agent”的混合模式。
工程上不建议所有事情都做成 Agent。越能写成确定规则的部分，越应该保持确定性。Agent 适合放在那些“需要理解、判断、综合”的位置。
一个企业场景：客服 Agent
假设我们做一个售后客服 Agent，用户说：
我上周买的净水器一直漏水，客服没人回我，帮我处理一下。
一个比较完整的 Agent 可能会这样运行：
| 步骤 | Agent 行为 | 测试关注点 |
|---|---|---|
| 识别意图 | 判断是售后投诉，不是普通咨询 | 意图分类是否正确 |
| 获取订单 | 调订单接口查询购买记录 | 是否查对用户和订单 |
| 查询工单 | 看是否已有客服记录 | 是否重复创建工单 |
| 判断优先级 | 漏水可能影响安全，提升优先级 | 规则是否符合业务 |
| 生成方案 | 给出退换修建议 | 是否超出政策承诺 |
| 创建工单 | 写入售后系统 | 参数是否完整、权限是否正确 |
| 回复用户 | 告知处理进度和工单号 | 是否清楚、可追踪 |
如果只看最后一句回复，可能觉得“写得还行”。但真正上线时，测试必须看全链路：有没有查错订单、有没有误创建工单、有没有承诺不存在的赔偿、有没有泄露其他人的信息。
Agent 的几个典型形态
| 类型 | 说明 | 适合场景 |
|---|---|---|
| 工具型 Agent | 会调用有限工具完成任务 | 查订单、查知识库、生成报告 |
| RAG Agent | 会主动检索知识并判断是否足够 | 企业知识库、法律检索、技术支持 |
| Coding Agent | 能读仓库、改代码、跑测试 | 自动修 Bug、生成脚本、代码审查 |
| 多 Agent | 多个角色协作 | 研究、写作、复杂分析 |
| 人机协同 Agent | 关键动作需要人工批准 | 发邮件、下单、删除数据、转账 |
这里最值得注意的是“人机协同”。在生产系统里，不是 Agent 越自主越好。越高风险的动作，越应该加入人工确认。
Agent 测试不能只看最终答案
测试 Agent 至少要看 6 类指标：
| 指标 | 说明 |
|---|---|
| 任务完成率 | 用户目标是否真正完成 |
| 工具选择准确率 | 是否调用了正确工具 |
| 参数正确率 | 调接口时参数是否对 |
| 越权率 | 是否访问或操作了不该碰的数据 |
| 失败恢复率 | 工具失败后是否能合理处理 |
| 成本与延迟 | 是否调用太多模型或工具 |
举个例子，Agent 最后回答“已为你创建工单”，但实际上接口返回失败。如果没有 trace 和工具调用记录，测试人员很难发现这个问题。Agent 的质量证据必须包含中间过程。
常见坑
第一个坑：把 Prompt 写得很长，以为这就是 Agent。
Prompt 可以指导行为，但 Agent 需要运行时支持，包括工具注册、工具权限、状态管理、执行循环、错误处理和日志追踪。
第二个坑：工具太多，模型反而选错。
给 Agent 100 个工具，就像给新人 100 个系统入口。工具描述不清、参数相似、权限混乱，都会导致误调用。工具设计要少而清楚。
第三个坑：没有停止条件。
Agent 可能陷入反复查询、反复改写、反复尝试。上线前要设置最大步骤数、最大工具调用次数、最大成本和超时。
第四个坑：让 Agent 直接执行高风险动作。
删库、转账、发正式邮件、修改合同、提交生产配置，这些动作都应该有人工确认或强规则护栏。
算法测试工程师怎么入手
可以从一个小型任务开始，比如“根据工单内容生成分类和摘要”。
第一版不要急着做全自动闭环，先做：
固定输入样本。
允许 Agent 调用 1 到 2 个只读工具。
记录每次工具调用。
人工标注任务是否完成。
把失败样本沉淀成回归集。
等只读链路稳定后，再引入写操作，并把写操作放到人工确认后面。
实践清单
列出一个业务任务，判断它是更适合工作流，还是 Agent。
如果需要 Agent，先写清楚它可以使用哪些工具。
给每个工具写一句非常明确的用途说明。
设置最大执行步数、超时、成本上限。
对所有工具调用做 trace。
高风险操作加人工确认。
用 20 个真实样本测试任务完成率和工具调用正确率。
最后小结
AI Agent 的价值，不在于它会说漂亮话，而在于它能把“理解”转化为“行动”。但行动越多，风险也越多。
对测试工程师来说，Agent 是一个很有挑战的新对象。它既像软件系统，又像算法系统，还像自动化流程。测试时必须同时关注最终结果、中间链路、权限边界、失败恢复、成本延迟和用户体验。
一句话：普通聊天机器人测答案，Agent 要测任务闭环。
