让AI不再幻觉：如何用一副'马具'让自然语言测试成为现实
从硬编码到自然语言：用"Harness Engineering"重构自动化测试
——以 Agent 系统为例
当我们面对一个业务流程密集的系统——比如可配置的AI Agent平台——传统的自动化测试很容易撞上南墙。API的组合爆炸、业务理解的断层、维护成本的指数级增长，这些都是真实存在的痛点。这篇文章记录了一次完整的探索：从pytest的硬编码封装，到构建CLI SDK与Skill体系，最终实现了"用自然语言描述测试场景即可执行"的目标。
虽然本文以Agent系统为例，但这套方法论本质上适用于绝大多数暴露API的软件产品——无论是电商、金融、SaaS还是内部工具平台。核心思路是从"喂代码给AI生成测试"的Context Engineering，转向"给AI套上一副马具"的Harness Engineering。在充分发挥AI决策能力的同时，约束其对业务系统的理解方式，让测试真正回归"用自然语言描述行为和预期"的初始形态。
1. 背景：当业务系统的复杂度超出传统自动化测试的承载能力
为了把问题说透，我们先来看一个颇具代表性的案例：一个面向用户的Agent构建平台。用户可以在Web页面上完成以下操作：
· 创建Agent，为其命名；
· 选择并配置底层的大语言模型；
· 绑定知识来源（文档库、数据库等）；
· 配置技能（插件、工具调用、工作流）；
· 保存Agent并将其发布给指定用户；
· 以某一用户的身份对该Agent发起问答，并获得带技能调用记录、引用来源的结构化响应。
系统中的每一步操作都有独立的RESTful API提供支持。创建Agent是一个API，绑定知识来源是另一个API，发起问答则是一个需要带上会话上下文的API。这种业务流程密集、接口编排复杂的特征，在电商下单、贷款审批、SaaS多租户配置等场景中同样普遍存在。因此，这个Agent平台所遇到的测试难题，实际上代表了一大类软件系统的共同痛点。
最开始，我们的自动化测试策略非常"标准"：在pytest框架中为每个API编写封装函数，然后在测试用例中按顺序调用这些函数，硬编码参数、捕获响应、提取字段、执行断言。举个例子，一个"端到端问答"的测试大概是这样的：
def test_agent_qa_with_skill():
# 1. 创建 agent
agent_id = create_agent(name="test_agent", model="gpt-4o")
# 2. 绑定知识库
bind_knowledge(agent_id, kb_id="kb_123")
# 3. 配置技能
add_skill(agent_id, skill_name="weather_search")
# 4. 保存并发布
publish(agent_id, user="user_001")
# 5. 以用户身份提问
resp = chat(agent_id, user="user_001", question="今天上海天气如何？")
# 6. 断言技能调用记录及语义
assert "weather_search" in resp["skill_calls"]
assert resp["ttft"] < 2.0
这种写法在业务逻辑简单时尚可应付，但当系统功能迅速膨胀时，问题就接踵而来了：维护成本极高——一个业务变更可能导致数十个测试函数的硬编码参数需要修改；表达能力受限——测试人员的大多数精力花在编排API调用顺序和数据传递上，而不是描述"这个功能该如何表现"；非开发人员被拒之门外——产品经理或QA脑子里有清晰的行为预期，却无法绕过Python代码直接参与自动化测试设计。
我们需要一种新的方式，让测试的编写和执行更接近于人类描述软件行为的方式——用自然语言表达用例，且这个用例能被可靠地执行。而且，这种方式不应只适用于Agent平台，而应能推广到任何可以通过API驱动的业务系统。
2. 灵感：LLM as a Judge 与 AI 驱动的交互式工具
在LLM as a Judge模式的启发下，我们开始尝试用大模型评判测试结果的语义一致性，而不是死板地匹配关键词。与此同时，像Claude Code、OpenCLAW这类AI交互工具的流行，让市场看到了另一种可能性：如果开发者可以通过自然语言让AI操作终端、读写文件、调用外部工具，那么是不是也能让AI直接操作我们的业务系统？
一个朴素的想法是：把整个业务系统的接口文档、使用示例甚至源码全部喂给大模型，然后要求它根据自然语言描述生成测试代码并执行。这就是典型的Context Engineering——通过提供尽可能完整的上下文，期望AI能自主理解业务、编排API并产出正确的测试。
但现实很快给了我们教训：幻觉严重——大模型会"发明"不存在的API端点、错误的参数组合，甚至臆造业务规则；API协调失控——创建资源、配置属性、触发动作这些操作之间存在严格的顺序依赖和状态传递（例如必须用上一步返回的ID进行下一步），完全让AI自主决策，生成的调用序列经常因顺序错乱而失败，试错成本高昂；反馈循环长——当测试本身依赖AI生成的代码时，失败后很难判断是业务缺陷还是生成的代码有问题。
于是结论很清晰：不能放任AI在黑暗里摸索。需要给它一张"地图"和一套"标准动作"，让它既能在限定范围内发挥决策能力，又不会偏离业务的正确路径。这张"地图"不应该只为某一类系统定制，而应成为一种可复用的模式。
3. 从 Context Engineering 到 Harness Engineering
我们提出的方案是Harness Engineering（马具工程）。这个词的意象很直白：给AI套上一副马具，让它有方向地奔跑，而不是在旷野中盲目冲撞。
实现Harness的核心步骤有两层，这两层对任何有API的系统都成立：
第一层：对业务API进行CLI SDK封装
将系统中所有核心API封装成一个命令行接口（CLI），每个业务操作就是一个带有明确参数和输出的命令。例如在我们的Agent平台中：
agent-cli create --name "test_agent" --model "gpt-4o"
agent-cli bind-knowledge --agent-id
agent-cli add-skill --agent-id
agent-cli publish --agent-id
agent-cli chat --agent-id
CLI层强制规定了正确的调用方式，参数校验在命令执行前就已经完成。任何不符合规范的调用都会立即得到明确的错误提示，而不是等到几个步骤后才报错。
第二层：基于CLI SDK开发Skills（技能）
有了CLI命令，我们进一步将其抽象为AI可调用的Skills。在Claude Code或OpenCLAW这类环境中，Skill就是一个带有详细描述、参数定义和调用示例的"工具"。例如，一个create_agent的Skill定义包含：描述——在平台中创建一个新的Agent，需要指定名称、模型等；参数——name (string), model (string), knowledge_bases (list), skills (list)...；调用方式——背后实际执行agent-cli create ... 命令。
这就是Harness Engineering的核心价值：将"理解业务如何运转"的责任从AI转移到事先设计好的工具和约束上，同时保留AI在任务规划和语义判断上的优势。AI不再需要从零推导业务流程，而是在一个安全的沙盒里，利用标准化的动作完成目标。无论被测系统是Agent平台、交易系统还是审批流程，只要其行为可以通过API驱动，就能套用这副"马具"。
4. 实践落地：用自然语言直接完成集成测试
经过上述改造，测试执行变成了下面这样的流程：
1. 测试人员（或产品经理、开发者）打开Claude Code，在提示词中用自然语言描述测试场景。
2. AI根据描述，调用预置的业务Skills，按正确顺序操作系统。
3. 每一步的响应被AI解析；最终结果通过LLM as a Judge进行语义断言。
一个真实的测试指令可能是这样的：
帮我创建一个名叫"天气助手"的Agent，使用系统已有的gpt-4o模型，配置weather_search技能和tra vel_kb知识库，保存后发布给用户lily。然后用lily的身份向这个Agent提问："明天去杭州需要带伞吗？" 预期的答案是：答案中必须能够看到weather_search技能的调用记录，最终回复的语义应当表明明天杭州是否下雨，并且TTFT不得高于2秒。
AI会自行规划任务序列，调用create_agent、bind_knowledge、add_skill、publish、chat等Skill，收集最终返回结果，然后基于预设的Judge规则（语义相似度、关键字包含、TTFT指标）给出通过与否的结论。整个过程不再需要一行hard code的测试函数。
对于其他系统，场景同样自然。例如：
在订单系统中，帮我用用户张三的账号创建一个包含商品A和商品B的订单，使用优惠码"SUMMER"，预期订单总价应该是原价的8折，且订单状态为"待支付"。
只要将订单系统的API封装为对应的order-cli命令和Skills，AI就能以完全相同的方式执行这种测试。整个体系的核心就是：用CLI封装了全部RESTful API（Harness的第一层）；将CLI命令映射为AI环境中的Skill（Harness的第二层）；为AI配备了一个Judge Skill用于结果断言；让人类用自然语言定义输入和预期。
测试的形态发生了根本性变化：测试用例本身回归到了自然语言描述的行为与预期，而执行和断言则交给了受约束的AI。
5. 为什么这条路径可行：自动化测试的演进回顾
回顾自动化测试所走过的路，可以发现一条清晰的演进脉络：
过去：自然语言描述的测试用例，指导测试人员手动操作；
现在：自然语言用例指导测试人员写出自动化脚本（pytest、Selenium等），然后通过CI流水线定时执行；
不久的过去：尝试将用例和代码一起塞给AI，让它生成测试脚本并执行，但幻觉和协调成本高；
未来（我们正在做的事）：测试人员将业务能力封装为Skills（Harness），然后直接用自然语言编写测试用例，让Agent执行它们。
最后这个阶段，其实是让测试回归到它的初始状态：用自然语言描述软件该做什么，以及期望看到什么。不同的是，现在有一个受过"马具训练"的AI Agent可以忠实地去完成这个验证工作，而不是必须由人去充当翻译官，把自然语言转写为代码。
6. 收益与反思
这套测试体系在我们的Agent平台及其他业务系统上落地后，收获了明显的收益：
测试编写效率大幅提升：用自然语言描述一个端到端场景，比编写对应的Python代码快5倍以上。
维护成本骤降：当业务API发生变更时，只需修改对应CLI命令和Skill的实现，所有自然语言测试用例无需任何改动即可继续运行。
团队协作边界消融：产品经理可以将验收标准直接以自然语言形式写入测试集合，它们会在每次发布前被AI自动执行，真正做到"活文档"。
测试即文档：自然语言用例本身就高度可读，省去了额外维护测试说明的负担。
当然，挑战同样存在。Harness Engineering要求初期投入精力设计合理的CLI接口和Skill抽象，这需要测试开发人员对业务有深度的理解，但这一投入是一次性的，且可以跨项目复用模式。另外，LLM as a Judge在某些模糊场景下仍可能产生评判偏差，需要持续校准Judge的提示词和标准。
7. 结语：让测试回归本原
这次探索最深刻的体会是：让AI成功落地的关键，往往不是给它更多的自由，而是赋予它恰到好处的约束。通过构建"马具"——CLI SDK和Skill体系，我们让AI在理解业务系统时既有方向又有边界。这一方法并不局限于Agent系统，它在订单、审批、配置、数据流等各类软件场景中同样成立。最终，测试行为回归到了人类交流的原始形式：用句子描述你希望系统做什么，以及你如何判定它做对了。
当有一天，任何一个团队成员都能在聊天框中输入一段自然语言，便能驱动一个覆盖全业务流程的自动化测试运行时，我们才真正可以说：测试没有阻碍交付，它本身就是交付的一部分。
