AI Agent核心技术解析：Token、RAG、MCP到Harness工程

许多测试开发工程师正积极研究 AI Agent。

初看演示Demo，确实令人印象深刻：

能检索资料、编写代码、自动生成测试用例、调用外部工具，甚至自主分析日志。

一旦部署到实际企业项目，挑战便接踵而至。

冗长的需求文档，Agent 究竟该聚焦哪一部分？接口文档频繁更新，如何防止它胡乱猜测？生成的用例看似面面俱到，实际执行能否通过？自动调用工具时，如何精准控制权限边界？代码写错、逻辑误改、报告失真，谁来为此负责？Token 消耗如流水，怎样在效能与成本之间找到平衡？

这正是大量 Agent 项目陷入停滞的症结所在。

问题不在于无法制作Demo，而在于Demo难以平稳融入真实的工程化流程。

对于测试开发而言，评估 Agent 不能仅停留在“它能否正确作答”的层面，更要审视它能否构建一个稳定可靠的任务闭环。

例如：

从需求中精准识别测试要点，依据接口文档自动生成用例，调用自动化框架执行测试，根据执行结果定位失败根因，最终产出可追溯、可验证的测试报告。

这才是测试开发群体真正需要的 Agent。

因此，本文不会堆砌概念，而是从测试开发的实际工作场景切入，系统拆解 Agent 背后的工程逻辑。

一、先看清楚：Agent 和普通大模型有什么区别

传统大模型的工作模式是“有问必答”。

你提出一个问题，它生成一段文本作为回复。

Agent 则大不相同，它更像一个能围绕既定目标持续推进的任务执行单元。

它能理解目标、分解任务、获取上下文、调用工具、观察结果，并据此调整下一步行动。

通过一张图可以清晰理解 Agent 的基本工作闭环，这个循环至关重要。

因为测试开发工作本身即是闭环：

从需求分析、测试设计、自动化执行，到结果校验、缺陷定位、报告输出。

因此，测试开发的业务场景天然适合 Agent 化。

举例说明。

让普通大模型生成接口测试用例，它可能直接输出一堆文本。

但一个真正的测试 Agent，其工作流程应该是这样：

这就将“生成内容”升级为了“执行任务”。

Agent 对于测试开发的核心价值，并非代写几行代码，而是将多个测试动作串联成一条可执行的工程链。

二、Token：为什么 Agent 用着用着就变贵、变慢、变不稳

许多人在初期使用大模型时，对 Token 缺乏概念。

一旦开始构建 Agent 系统，Token 问题便成为首要挑战。

Token 可以理解为大模型处理文本时的最小计算单元。

模型并非直接理解中文、英文或代码，而是先将文本切分为 Token，再映射为数值进行计算。

Token 对 Agent 的影响主要体现在三个方面。

1. 影响成本

输入内容越长，输出字数越多，Token 消耗就越高。

如果 Agent 每轮都加载全部的需求文档、接口文档、历史日志和代码片段，成本会迅速攀升。

2. 影响上下文

模型一次能处理的上下文窗口有上限。

资料过多时，模型只能处理部分信息。

这会导致一个关键问题：它看似在回答一个完整问题，实则仅依赖部分信息进行判断。

3. 影响稳定性

Agent 的执行是多轮交互的。

它会持续累积用户目标、任务步骤、工具返回结果、历史对话和中间推理过程。

若不进行上下文管理，Agent 很容易越跑越长、越跑越贵、越跑越偏离初始目标。

因此，开发 Agent 不能简单地一股脑把所有资料塞给模型。

更理想的做法是这样：

对测试开发而言，Token 管理绝非底层技术细节，而是 Agent 能否稳定落地的基石。

上下文控制若是失当，后续的 RAG、工具调用、报告生成等环节都将受到影响。

三、RAG：为什么企业 Agent 不能只靠模型自己回答

测试开发场景有一个显著特征：

大量关键知识并不内置于大模型中，而是存储在企业自身的系统里。

例如：

• 需求文档
• 接口文档
• 测试用例库
• 缺陷记录
• 日志规范
• 数据字典
• 测试平台操作手册
• 历史事故复盘报告
• 团队自动化框架约定

如果 Agent 无法接入这些资料，仅凭模型自身知识回答，极易出现“看似合理，实则不准确”的状况。

这正是 RAG 技术发挥作用的地方。

RAG 的核心逻辑很清晰：

在大模型给出回答前，先检索相关资料，再结合这些资料生成最终答案。

这相当于让模型从闭卷考试模式切换为开卷考试模式。

对于测试开发，RAG 的应用场景非常广泛。

但 RAG 的实现绝非简单地把文档存入向量数据库。

实际落地时，任一环节处理不当，RAG 都可能沦为“表面接入了知识库，实际回答仍靠猜测”。

因此，企业级 Agent 想要做到可靠，RAG 是不可或缺的一步。

四、Memory：Agent 如何记住当前任务和历史经验

Agent 要完成复杂任务，不能每次执行都像首次运行。

它需要记住当前任务的进展状态，也需要在适当时机复用历史经验。

因此，Agent 的记忆通常分为两类：

短期记忆与长期记忆。

短期记忆服务于当前会话任务。

例如，用户刚才的对话内容、当前执行到哪个步骤、工具返回了什么结果、下一步应该做什么。

长期记忆服务于跨任务的复用。

例如，特定项目的接口命名风格、团队的自动化框架规范、某类报错的排查方法、某种报告的输出格式要求。

就测试开发而言，长期记忆非常适合沉淀这些内容：

• 项目常见的缺陷模式
• 接口自动化框架约定
• 页面元素定位常用规则
• 测试报告输出的标准格式
• 常见环境问题的排查路径
• 历史线上事故的复盘经验
• 团队常用的测试设计模板

然而，记忆并非越多越好。

错误的经验会污染后续决策。过时的规则会误导 Agent 行为。敏感信息不能随意写入长期记忆。不同项目间的经验也不能混用。

因此，企业级 Agent 的记忆系统，必须配备完善的更新、过期、权限和审计机制。

五、Skill：把测试经验封装成可复用能力

许多测试开发团队的问题并非缺乏经验，而是经验过于分散。

有的存在于资深员工的头脑中，有的散落在项目文档里，有的固化在自动化脚本中，有的沉睡在测试平台的说明里，还有的藏匿在一次次的踩坑教训中。

如果这些经验无法被结构化沉淀，Agent 每次执行任务都需要从零理解。

这时就需要引入 Skill 概念。

Skill 可以理解为面向大模型的能力封装。

它不是简单的 Prompt，而是一组结构化的资料、流程、模板和工具调用定义。

这样，Agent 在生成接口用例时，就不是自由发挥，而是严格按照团队规范执行。

Skill 的价值不是让模型变聪明，而是把团队的经验转化为可复用的数字资产。

测试开发团队非常适合构建 Skill。

因为测试工作中存在大量流程化、模板化、规范化的经验，例如：

• 需求评审 Skill
• 接口测试 Skill
• Web 自动化 Skill
• App 自动化 Skill
• 性能分析 Skill
• 日志分析 Skill
• 缺陷定位 Skill
• 测试报告 Skill
• 代码评审 Skill
• 测试平台操作 Skill

未来，一个成熟的测试 Agent，不应仅仅接入一个通用大模型，而应沉淀一组属于团队自己的测试 Skill。

六、ReAct：让 Agent 边想、边做、边验证

Agent 的工作模式并非一次性生成答案就结束。

许多任务需要边执行边观察结果，再决定下一步行动。

这正是 ReAct 模式的价值所在。

ReAct 是 Reason（推理）和 Act（行动）的结合。

它描述了 Agent 的一种典型工作方式：

首先分析当前信息是否充足，如果不足，就调用工具去获取，拿到结果后继续判断，再决定新的动作。

这一模式与测试开发排查问题的过程高度相似。

例如，接口自动化失败后，测试开发不会立即下结论，而会一步步排查。

Agent 的逻辑亦是如此。

它不能仅靠一次回答完成复杂的任务，必须持续观察结果，再决定下一步。

但 ReAct 模式也必须有明确的边界。

否则 Agent 可能陷入无效循环：

反复调用同一个工具，反复分析同一段日志，反复生成没有依据的猜测。

因此，工程上必须加以控制：

• 设置最大执行轮数
• 限定可调用的工具白名单
• 定义工具失败后的降级策略
• 明确何时终止任务
• 确定何时转交人工处理
• 高风险操作是否需要二次确认

Agent 的自主任越大，就越需要清晰的安全边界。

七、MCP：让 Agent 更标准地连接外部工具

一个无法连接外部系统的 Agent，其能力将受到极大限制。

在测试开发场景中，Agent 通常需要对接大量工具：

需求管理系统、接口文档平台、数据库、日志系统、Git 仓库、CI/CD 流水线、自动化测试框架、缺陷管理系统。

过去，为每个工具单独开发适配接口存在显著弊端：

接入成本高、协议不统一、上下文格式各异、权限控制困难、不同 AI 应用之间难以复用。

MCP 的价值在于，它让 AI 应用能以标准化的方式连接外部工具和数据源。

对于测试开发，MCP 的想象空间巨大。

未来一个测试 Agent 可以这样工作：

这意味着 Agent 不仅“知道怎么说”，更“知道去哪查资料、调用什么工具、拿回什么结果、下一步如何处理”。

这是 Agent 从 Demo 迈向工程化系统的关键一步。

八、SDD：先写清规格，再让 AI 干活

很多人在使用 AI 编写代码时，容易犯一个典型错误：

直接抛出一句模糊的需求描述，然后期望 AI 能自动理解所有上下文。

例如：

这种描述对 AI 来说过于宽泛。

它不知道具体优化哪个模块，不清楚哪些逻辑不能动，不了解旧数据是否需要兼容，不确定接口返回格式能否更改，更不知道验收标准是什么。

这时就需要引入 SDD。

SDD 是 Spec-Driven Development（规格驱动开发）的缩写。

它强调，在正式开发前，先将目标、范围、约束、行为和验收标准明确下来，再让 AI 按规格执行。

例如，同样是优化测试报告，更好的规格应这样定义：

SDD 对测试开发至关重要。

因为未来的测试开发不仅需要编写脚本，更要学会为 AI 编写清晰的规格说明。

适用 SDD 的场景包括：

• 测试方案的设计
• 自动化用例的生成
• 测试平台的功能改造
• Agent 工作流的设计
• AI 生成代码的验收约束
• 测试工具的重构

谁能把需求阐述清楚，谁就能更好地驾驭 AI。

九、Harness 工程：给 Agent 搭一个可控的工作环境

Agent 一旦进入真实工程系统，其活动范围远不止生成文本。

它可能会读取文件、查询数据库、调用接口、修改代码、触发流水线、创建缺陷、生成报告。

此时，仅靠 Prompt 远远不够。

我们需要为 Agent 构建一个可靠、可控、可观测的工作环境，这就是 Harness 工程。

Harness 工程需要解决的现实问题包括：

这些工作，测试开发同学其实并不陌生。

在构建自动化测试平台、质量平台、性能平台时，我们同样要考虑环境、权限、日志、报告、监控、回滚和稳定性。

Agent 工程并未脱离传统的工程规律。

它只是将大模型置于工程系统中，因此对工程治理提出了更高的要求。

十、把这些概念串起来：Agent 的完整工程链路

前面讨论了很多概念。

但这些概念并非孤立存在。

真正的 Agent 落地，需要将它们串联成一条完整的链路。

这张图揭示了一个核心要点：

Agent 不是单点技术，而是一套工程组合拳。

仅会写 Prompt，做不出稳定的 Agent。只接入知识库，同样不行。只会调用工具，也远远不够。

一个能真正落地的 Agent，必须同时考虑：

• 上下文管理
• 知识检索
• 工具集成
• 权限控制
• 结果验证
• 日志记录
• 成本控制
• 反馈闭环

这正是测试开发同学应当投入精力的方向。

我们关注的不是 AI 能否生成内容，而是它能否融入工程流程，稳定、可控、可验证地完成任务。

十一、测试开发同学应该怎么切入 Agent

对于测试开发而言，Agent 并非遥远概念。

它已经开始重塑许多具体工作。

未来，大量测试任务将从“人工手写脚本”转变为“人定义目标和规则，Agent 执行并反馈”。

测试开发同学可以从以下几个方向切入。

1. 从 RAG 切入

首先将需求文档、接口文档、测试用例库、缺陷记录接入知识库。

让 Agent 能基于真实资料做出判断，而非凭空猜测。

2. 从 Skill 切入

将团队积累的测试经验整理成标准化的 Skill。

例如，接口测试规范、自动化脚本模板、日志分析流程、测试报告模板。

3. 从工具调用切入

让 Agent 具备调用真实测试工具的能力。

例如，接口测试框架、浏览器自动化工具、日志查询系统、CI/CD 管道、缺陷跟踪系统。

4. 从 SDD 切入

将模糊的需求转化为清晰的规格说明。

让 AI 能够依据明确的目标、范围、约束和验收标准来执行。

5. 从 Harness 切入

建立包括权限、日志、沙箱、验证和人工审核在内的工程框架。

确保 Agent 不仅能跑，更能被管控、被审计、可回滚。

测试开发同学不能仅仅停留在“会使用 AI 工具”。

更重要的是深入理解 Agent 背后的工程结构。

你需要知道：

• 何时该使用 RAG
• 何时该封装 Skill
• 何时需要 MCP 来连接工具
• 何时必须引入人工审核环节
• 何时需要沙箱验证
• 何时需要编写 SDD 规格
• 何时不能让 Agent 自主执行

普通用户关心 AI 能否给出答案。

测试开发更应关注：

• 这个答案是否有据可查
• 能否被验证
• 能否被复用
• 能否接入现有工具链
• 能否在工程系统中稳定运行

这正是测试开发与普通使用者的本质区别。

十二、最后：Agent工程能力的延伸

很多人初接触 Agent，会被各种专业术语吓到。

Token、RAG、Skill、MCP、Memory、ReAct、SDD、Harness……

但如果用测试开发熟悉的语言来理解，它们可以这样对应：

Agent 最终的比拼，并非一个酷炫的 Demo，而是在真实业务中稳定运行的能力。

对测试开发而言，这恰恰是机遇所在。

因为我们本就擅长流程管理、质量保障、自动化建设、结果验证和工程闭环。

在 AI Agent 时代，测试开发不仅能成为工具的使用者，更能成为 Agent 工程落地的重要建设者。

真正的分水岭，不在于会不会向 AI 提问。

而在于你能否将 AI 嵌入真实的工程流程，使其稳定、可控、可验证地完成任务。