1. 项目概述：从“Agent Harness”到“自工程完结”的启示

最近在AI Agent开发圈里，“Agent Harness”这个概念讨论得挺热。乍一听，这词儿有点技术黑话的味道，但如果你拆开来看，它其实指向了一个非常朴素却至关重要的工程理念。Harness，原意是“马具”、“安全带”，在软件工程里，它指的是一套用于约束、管理和测试核心逻辑的“基础设施层”或“框架”。而“Agent Harness”顾名思义，就是包裹在AI Agent核心推理逻辑之外的那层“安全网”和“操作手册”。

这个概念的走红，恰恰反映了当前AI应用开发，特别是基于大语言模型（LLM）的Agent开发，正从一个“炫技演示”阶段，迈向“工程化落地”的深水区。大家不再满足于一个能跑通的Demo，而是开始严肃思考：如何让这个充满不确定性的“智能体”在真实、复杂的环境中稳定、可靠地工作？如何确保它的每一次输出都符合预期，至少不会捅出大篓子？这时，“Agent Harness”的价值就凸显出来了——它不替代Agent的“大脑”（核心推理），而是为这个大脑套上缰绳，规划跑道，并准备好随时勒马的刹车。

而标题中提到的TPS（丰田生产方式）的“自工程完结”，则给这个技术问题提供了一个更高维度的管理哲学视角。“自工程完结”是TPS里“品质在工序内保证”的核心思想。它要求每个生产工序都必须将自己负责的环节做到100%合格，绝对不把缺陷（Bug）流到下一道工序。这听起来像是制造业的“老黄历”，但把它映射到软件开发和AI系统构建上，简直是醍醐灌顶。我们过去太习惯于“敏捷迭代”、“快速上线”，潜意识里觉得“有点小Bug很正常，后面再修”，或者把质量保证的希望寄托在最后的测试环节。但“自工程完结”告诉我们： Bug的修复成本，会随着它在流水线中传递而指数级增长。 一个在需求分析阶段就能发现的逻辑漏洞，其修复代价可能只是几句话的沟通；如果它溜进了设计文档，代价是修改几张图；如果写成了代码，代价是重构几个函数；如果通过了测试部署上线，代价可能就是一次线上事故、用户投诉和紧急回滚。

所以，“【Agent Harness】TPS的‘自工程完结’教会了我一件事：别把Bug留给下一道工序”这个标题，精准地戳中了当前AI Agent工程化的痛点。它告诉我们，构建AI应用，尤其是Agent这类具有自主性的系统，不能只关注LLM的“魔法”效果，必须用扎实的工程方法（Harness）来约束和保障，并且要将质量意识前置到每一个环节（自工程完结），从源头扼杀Bug。这篇文章，我就结合自己趟过的坑，聊聊如何为你的AI Agent打造一套实用的“Harness”，并把“自工程完结”的理念贯彻到开发全流程中。无论你是刚开始接触AI Agent的开发者，还是正在为智能体系统的稳定性头疼的工程师，相信这些实践和思考都能给你带来一些直接的帮助。

2. 核心理念拆解：为什么AI Agent特别需要“Harness”与“自工程完结”

在深入实操之前，我们得先搞清楚，为什么传统软件开发的经验，在AI Agent这里好像有点“不够用”，以至于需要特别强调“Harness”和“自工程完结”。

2.1 AI Agent的独特挑战：不确定性是常态

传统的软件是确定性的。输入A，经过我们编写的确定逻辑，必然输出B。我们的测试可以基于“断言”（Assertion）来验证： assert function(input) == expected_output 。但AI Agent的核心驱动力——大语言模型，本质是一个概率模型。你给它相同的输入（Prompt），它可能给出不同的输出。这种“不确定性”是它的能力来源（创造性、泛化性），但也成了工程化的噩梦。

1. 输出的非结构化与漂移 ：LLM的输出是自然语言文本。你需要从中解析出结构化的意图、参数或结果。今天它可能规整地返回一个JSON，明天同一个Prompt它可能用一段话描述。更可怕的是“模型漂移”，同一个云服务商提供的模型，随着版本更新，其行为也可能发生微妙变化，导致之前运行良好的Agent突然“失常”。
2. 上下文的长尾依赖 ：Agent往往需要维护一个会话上下文（Context）。一个看似无关的早期对话内容，可能会在几十轮之后被模型重新引用并产生意想不到的影响。这种长距离的依赖关系，使得Bug的复现和排查极其困难。
3. 工具调用的可靠性 ：Agent的核心能力之一是调用外部工具（API、函数、数据库）。如何确保它生成的调用参数是合法、安全的？如何防止它陷入调用失败的死循环？如何管理工具调用的副作用（比如，会不会重复提交订单）？
4. 幻觉与胡说八道 ：LLM的“幻觉”问题在Agent场景下危害更大。如果Agent基于幻觉的事实去做出决策或执行动作，其后果可能是灾难性的。

这些挑战意味着，我们不能像测试传统软件那样，只测试Agent的“最终输出”是否正确。我们必须测试并约束其 整个推理和行为链条 的可靠性、安全性和稳定性。这就是“Agent Harness”要解决的问题。

2.2 “自工程完结”在AI开发流水线中的映射

将TPS的“自工程完结”思想映射到AI Agent的开发中，我们可以构建一条清晰的质量防线：

1. 第一道工序：需求与Prompt设计 。目标：确保需求明确、无歧义，且Prompt能稳定引导模型理解该需求。这里的“Bug”就是模糊、矛盾的需求，或脆弱的Prompt。 “完结”动作 ：必须进行Prompt的单元测试和评估，使用少量但具代表性的样例，验证Prompt的意图识别准确率。如果Prompt在少量样例上表现都不稳定，绝不能流入下一环节。
2. 第二道工序：核心逻辑与流程编排 。目标：设计健壮的Agent工作流（如ReAct、Plan-and-Execute），处理好各种异常分支（工具调用失败、模型输出无法解析等）。这里的“Bug”是逻辑漏洞和缺失的异常处理。 “完结”动作 ：进行工作流的“纸面推演”或使用模拟工具进行测试，覆盖主要成功路径和关键异常路径。逻辑不闭环，绝不开始编码。
3. 第三道工序：代码实现与Harness集成 。目标：编写Agent核心代码，并同步集成Harness框架（如输入输出校验、对话状态管理、工具调用拦截器、审计日志等）。这里的“Bug”是代码错误和Harness的缺失。 “完结”动作 ：针对每个工具函数、状态转换函数编写单元测试；针对Harness的每个约束条件编写测试用例。代码覆盖率（尤其是分支覆盖率）需达到一定标准，且所有Harness测试必须通过，才能进入集成阶段。
4. 第四道工序：集成与端到端测试 。目标：将Agent与外部环境（模拟或真实）连接，测试完整场景。这里的“Bug”是组件间接口不匹配和复杂场景下的模型行为异常。 “完结”动作 ：建立一套高质量的端到端测试集，包含各种边界案例和“刁难”性问题。只有通过全部端到端测试，才能认为该版本Agent“完结”，具备进入预发布环境的资格。

每一道工序都对自己的产出质量负全责，坚决不让问题溜走。这样，流到最终测试和上线环节的，已经是一个经过层层把关、相对可靠的产品，最终测试的压力会小很多，线上风险也大大降低。

注意 ：很多人觉得“自工程完结”会拖慢开发速度。短期看，确实增加了单环节的时间投入。但长期看，它极大地减少了后期联调、Debug、救火的时间，总效率其实是提升的。更重要的是，它培养了一种“一次做对”的工程文化，这对于构建复杂的、难以调试的AI系统至关重要。

3. 构建你的Agent Harness：从理论到实践

Harness不是某个特定的框架，而是一种架构思想和一组可落地的组件。下面，我们来拆解一个典型Agent Harness应包含的核心层，并给出具体的实现思路。

3.1 输入/输出规范化与验证层

这是Harness的最外层，负责与外部世界（用户、其他系统）交互。它的核心任务是 将不确定的自然语言输入，转化为确定的、结构化的内部表示；并将内部的结构化决策，转化为安全、合规的输出 。

1. 输入处理（Input Sanitization & Parsing）

• 安全过滤 ：移除或转义用户输入中的潜在恶意代码、敏感信息。这是安全的第一道防线。
• 意图解析与槽位填充 ：使用一个 小而专 的LLM调用或分类器，将用户输入解析为预定义的“意图”（Intent）和“参数”（Slots/Entities）。例如，用户说“明天上海天气怎么样？”，解析为 {intent: “query_weather”, slots: {city: “上海”, date: “明天”}} 。这一步将开放性的问题转化为了确定性的数据结构，后续所有逻辑都基于此展开，稳定性大增。

  # 伪代码示例：使用Pydantic定义结构化意图
  from pydantic import BaseModel
  from typing import Optional
  import instructor # 用于将LLM输出结构化到Pydantic模型
  
  class WeatherQueryIntent(BaseModel):
      intent: Literal["query_weather"]
      city: str
      date: Optional[str] = None
  
  # 使用instructor库调用LLM进行解析
  import openai
  client = openai.OpenAI()
  
  def parse_user_input(user_input: str) -> WeatherQueryIntent:
      intent = client.chat.completions.create(
          model="gpt-3.5-turbo",
          response_model=WeatherQueryIntent, # instructor的关键
          messages=[
              {"role": "system", "content": "你是一个精准的意图解析器，将用户问题转换为结构化的查询。"},
              {"role": "user", "content": user_input}
          ]
      )
      return intent
  

  • 实操心得 ：这个解析LLM可以用比主Agent更小、更快的模型，因为它任务单一。并且，这里必须设置 重试和降级策略 。如果解析连续失败，可以回退到基于关键词规则的解析，或者直接回复用户“抱歉，我没理解您的意思，请换种方式提问”。这比让主Agent基于错误的理解乱跑要好得多。

2. 输出处理与后置校验

• 结构化输出约束 ：强制要求Agent的最终输出必须是特定格式（如JSON）。可以在Prompt中强约束，也可以在输出后使用一个轻量级解析器进行校验和修复。
• 内容安全与合规校验 ：对Agent生成的所有文本、建议进行二次检查。可以集成一个内容过滤API或本地规则库，过滤不当言论、虚假信息等。对于涉及事实的陈述，可以触发一个“事实核查”子流程，让Agent引用可信来源。
• 格式化与美化 ：将结构化的数据转化为用户友好的展示形式（如表格、图表、优美的文本）。

3.2 对话状态与流程管理层

Agent往往不是一问一答，而是多轮对话。管理好对话状态（Context）是保证连贯性和避免混乱的关键。

1. 状态机（State Machine） 为Agent设计一个明确的状态机。例如： 等待输入 -> 解析意图 -> 执行工具 -> 等待工具结果 -> 生成回复 -> 等待输入... 。每个状态都有明确的进入条件、执行动作和退出条件。

• 好处 ：逻辑清晰，易于调试和测试。你可以通过检查当前状态快速定位Agent“卡”在了哪里。
• 实现 ：可以使用简单的枚举和if-else，也可以使用更强大的框架如 transitions 库。

  from enum import Enum
  
  class AgentState(Enum):
      IDLE = “idle”
      PARSING = “parsing”
      EXECUTING_TOOL = “executing_tool”
      GENERATING_RESPONSE = “generating_response”
      ERROR = “error”
  
  class ConversationHarness:
      def __init__(self):
          self.state = AgentState.IDLE
          self.context = {}
  
      def process(self, user_input: str):
          if self.state != AgentState.IDLE:
              return “Agent正忙，请稍候...”
          try:
              self.state = AgentState.PARSING
              intent = self._parse_input(user_input) # 可能失败
              self.state = AgentState.EXECUTING_TOOL
              result = self._execute_tool(intent) # 可能失败
              self.state = AgentState.GENERATING_RESPONSE
              response = self._generate_response(result)
              self.state = AgentState.IDLE
              return response
          except ParsingError:
              self.state = AgentState.ERROR
              # ... 错误处理
          except ToolExecutionError:
              self.state = AgentState.ERROR
              # ... 错误处理
  

2. 上下文窗口管理 LLM有token限制。Harness需要智能地管理对话历史：哪些信息需要保留？哪些可以总结或丢弃？常见的策略有：

• 滑动窗口 ：只保留最近N轮对话。
• 关键信息提取 ：将长篇历史总结成几个关键点。
• 向量数据库检索 ：将历史对话存入向量库，每次只检索与当前问题最相关的片段。

注意事项 ：上下文管理不当是导致Agent“失忆”或“胡言乱语”的主要原因之一。务必对此设计充分的测试用例，例如，在长对话后询问很早之前提过的细节，看Agent是否能正确回忆。

3.3 工具调用管控与沙箱层

这是Harness中最关键的安全屏障。Agent能做什么，完全由它可调用的工具决定。必须对工具调用进行严格的管控。

1. 工具注册与权限管理

• 不是所有函数都能被Agent调用。需要一个中心化的 工具注册表 ，明确每个工具的功能、输入输出格式、以及 风险等级 。

  tool_registry = {
      “get_weather”: {
          “function”: get_weather_api,
          “description”: “查询城市天气”,
          “risk”: “low”, # 风险等级：low, medium, high
          “schema”: {“type”: “object”, “properties”: {“city”: {“type”: “string”}}}
      },
      “execute_sql”: {
          “function”: execute_readonly_sql, # 注意：这里注册的是只读函数
          “description”: “执行数据库查询（只读）”,
          “risk”: “medium”,
          “schema”: {...}
      },
      # 高风险工具，如“发送邮件”、“创建订单”，需要额外授权或根本不对Agent开放
  }
  

• 可以根据对话上下文、用户身份，动态决定本次会话中Agent可用的工具子集。

2. 参数校验与类型安全 在调用工具前，Harness必须对Agent生成的参数进行强制校验。利用Pydantic等库，可以轻松实现基于JSON Schema的严格校验。

from pydantic import ValidationError

def safe_tool_call(tool_name: str, arguments: dict):
    tool_info = tool_registry[tool_name]
    # 1. 模式校验
    try:
        validated_args = validate_against_schema(arguments, tool_info[“schema”])
    except ValidationError as e:
        return {“error”: f”参数校验失败: {e}”}
    # 2. 业务逻辑校验（例如，城市名是否存在）
    if not is_valid_city(validated_args[“city”]):
        return {“error”: “不支持的城市名”}
    # 3. 执行调用
    return tool_info[“function”](**validated_args)

3. 沙箱与环境隔离 对于执行代码、访问敏感文件等高危操作，必须在沙箱环境中运行。

• 使用容器 ：将工具执行放在一个临时的Docker容器中，限制其网络、文件系统和CPU/内存资源。
• 使用安全语言运行时 ：对于Python，可以考虑使用 RestrictedPython 或 PyPy 沙箱。
• 超时与熔断 ：为每个工具调用设置严格的超时时间。如果工具长时间无响应，Harness应能中断调用并返回错误，防止整个Agent被拖死。

3.4 可观测性与审计层

一个黑盒的Agent是可怕的。Harness必须提供全面的可观测性，让你能看清Agent内部发生了什么。

1. 结构化日志 记录每一个关键事件：用户输入、解析后的意图、触发的工具、工具参数、工具结果、模型回复、最终输出。日志必须是结构化的（JSON格式），便于后续检索和分析。

import json
import logging

structured_logger = logging.getLogger(“agent_harness”)

def log_event(event_type: str, data: dict):
    log_entry = {
        “timestamp”: datetime.utcnow().isoformat(),
        “event_type”: event_type,
        “session_id”: current_session_id,
        “data”: data
    }
    structured_logger.info(json.dumps(log_entry))

2. 链路追踪（Trace） 为每一次用户会话分配一个唯一的 trace_id ，并将该会话内所有的LLM调用、工具调用都关联到这个 trace_id 上。这样，当出现问题，你可以轻松地复现整个决策链条。这类似于分布式系统中的调用链追踪。

3. 度量指标（Metrics） 收集关键指标，用于监控和预警：

• 延迟 ：用户输入到最终输出的时间（P99， P95）。
• 成功率 ：会话成功完成的比例。
• 工具调用统计 ：各工具调用次数、失败率、平均耗时。
• Token消耗 ：每次会话消耗的Prompt和Completion的token数，这是成本控制的关键。
• 模型行为指标 ：如输出被安全过滤器拦截的比例、意图解析的置信度分布等。

这些指标可以通过Prometheus等工具暴露，并集成到Grafana看板中，让你对Agent的运行健康状况一目了然。

4. 贯彻“自工程完结”的CI/CD流水线设计

有了Harness的组件，我们需要一个自动化的流程来确保它们在每次代码变更时都能被正确测试，这就是CI/CD（持续集成/持续部署）。对于AI Agent，CI/CD流水线需要特别定制。

4.1 流水线阶段设计

一个典型的AI Agent CI/CD流水线应包含以下阶段，每个阶段都对应一道“工序”，必须“完结”才能进入下一阶段：

1. 代码质量检查（Lint & Format） ：使用 black , isort , mypy , pylint 等工具，确保代码风格一致、类型注解正确。这是最基本的卫生习惯。
2. 单元测试（Unit Test） ：
   • 测试工具函数 ：Mock外部依赖，测试工具逻辑的正确性。
   • 测试Harness组件 ：测试输入解析器、状态机、参数校验器等Harness核心逻辑。
   • 测试工具调用封装 ：Mock LLM和外部API，测试工具调用管控层的逻辑。
   • 目标 ：达到高代码覆盖率（如>80%）。
3. 集成测试（Integration Test） ：
   • 测试Agent工作流 ：使用Mock的LLM（例如，使用 pytest 的 monkeypatch 替换 openai.ChatCompletion.create ，返回预设的响应），测试从输入到输出的完整工作流，包括各种异常分支（如解析失败、工具调用超时）。
   • 测试与向量数据库/外部服务的连接 ：可以使用测试专用的数据库实例或容器。
4. 端到端测试（E2E Test） - 核心防线 ：
   • 使用真实LLM（但成本可控） ：针对最关键、最核心的功能路径，编写端到端测试用例，使用真实的LLM API（如gpt-3.5-turbo）进行测试。为了控制成本和速度，需要：
     • 精心设计测试集 ：数量不必多，但必须覆盖核心场景和边界情况。
     • 使用低功耗模型 ：在测试环境使用更小、更便宜的模型。
     • 缓存LLM响应 ：使用 vcr.py 或类似库录制并回放LLM的HTTP请求，避免每次测试都产生API调用和费用。这是提升测试速度、实现“完结”的关键。
   • 评估（Evaluation） ：端到端测试不能只判断通过与否，还需要 评估 输出质量。这需要定义清晰的评估标准（Metrics）：
     • 基于规则的评估 ：检查输出是否包含特定关键词、是否符合JSON格式。
     • 基于模型的评估 ：使用另一个LLM（如GPT-4）作为“裁判”，判断Agent的回答是否准确、相关、无害。可以设计一套标准问题，并对比Agent输出与“标准答案”的相似度（使用嵌入向量计算余弦相似度）。
5. 安全与合规扫描 ：集成SAST（静态应用安全测试）工具，检查代码中的安全漏洞。对Prompt进行扫描，防止其中包含敏感信息或不当引导。
6. 性能与负载测试（可选但推荐） ：在预发布环境，模拟多用户并发请求，测试Agent系统的吞吐量和延迟，确保其能满足线上要求。

4.2 实现示例：一个基于GitHub Actions的CI流水线

# .github/workflows/ci.yml
name: AI Agent CI Pipeline

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: ‘3.11’

      - name: Install dependencies
        run: |
          pip install -r requirements.txt
          pip install -r requirements-dev.txt # 测试专用依赖

      - name: Lint and Format Check
        run: |
          black --check .
          isort --check-only .
          mypy .

      - name: Run Unit Tests
        run: |
          pytest tests/unit/ --cov=src --cov-report=xml -v
        env:
          OPENAI_API_KEY: ${{ secrets.TEST_OPENAI_API_KEY }} # 使用测试环境的Key

      - name: Run Integration Tests (with mocked LLM)
        run: |
          pytest tests/integration/ -v

      - name: Run Critical E2E Tests (with cached LLM)
        run: |
          # 假设我们使用vcr.py缓存，首次运行会真实调用并录制，后续运行使用缓存
          pytest tests/e2e/critical/ -v --record-mode=once
        env:
          OPENAI_API_KEY: ${{ secrets.TEST_OPENAI_API_KEY }}
          # 其他API Keys...

      - name: Upload Coverage
        uses: codecov/codecov-action@v3
        with:
          file: ./coverage.xml

实操心得 ：E2E测试的稳定性是个挑战。LLM输出的非确定性会导致测试时而过、时而不过。应对策略有：

1. 放宽断言 ：不断言完全相同的字符串，而是断言输出中是否包含某些关键信息，或者使用语义相似度判断。
2. 设置重试 ：对于非确定性的失败，可以允许测试重试1-2次。
3. 黄金数据集（Golden Dataset） ：维护一个由人工标注的“黄金”输入输出对。每次代码更新后，运行E2E测试并与黄金数据集对比，如果差异超过某个阈值（由模型评估或人工审核），则发出警报，而不是直接失败。这更符合AI系统的测试特点。

5. 常见问题与避坑指南实录

在实际构建Agent Harness和落实“自工程完结”的过程中，我踩过不少坑，也总结出一些有效的排查技巧。

5.1 问题：Agent陷入死循环或重复动作

• 现象 ：Agent不停地调用同一个工具，或者来回切换几个状态，无法给出最终答复。
• 根因分析 ：
  1. 状态机设计缺陷 ：缺少终止状态，或状态转移条件有重叠/漏洞。
  2. 工具调用结果处理不当 ：工具返回了Agent无法理解的结果（如错误信息），导致Agent反复尝试。
  3. 上下文混乱 ：历史对话中包含了导致混淆的指令。
• 排查与解决 ：
  • 检查日志 ：查看结构化日志中的状态流转和工具调用序列，能快速定位循环点。
  • 强化Harness ：在状态机中为每个状态设置 最大重试次数 （如，连续3次进入同一状态则强制跳转到 ERROR 状态）。在工具调用层，如果连续N次调用同一工具失败，应阻止再次调用并向上返回明确错误。
  • 优化Prompt ：在给Agent的Prompt中明确指示“如果XX工具调用失败，请直接告知用户并停止尝试”。

5.2 问题：Token消耗失控，成本激增

• 现象 ：简单的对话消耗了数万token，API费用飙升。
• 根因分析 ：
  1. 上下文无限增长 ：没有管理对话历史，所有内容都塞进Prompt。
  2. Agent“话痨” ：模型生成过于冗长的思考过程或回复。
  3. 工具描述过长 ：在Prompt中提供了过于详细（几十行）的工具描述。
• 排查与解决 ：
  • 实施上下文管理 ：立即接入上文提到的滑动窗口或总结策略。
  • 设置Token上限 ：在调用LLM API时，明确设置 max_tokens 参数，强制限制生成长度。
  • 精简工具描述 ：为Agent提供的工具描述，应简洁、格式统一，只包含必要信息（名称、功能、参数格式示例）。详细的文档可以放在别处。
  • 监控与告警 ：在可观测性层加入Token消耗的实时监控。当单次会话或每分钟消耗超过阈值时，触发告警并可能终止该会话。

5.3 问题：工具调用参数错误，导致下游服务异常

• 现象 ：Agent生成的SQL语句语法错误，或调用天气API时传入了不存在的城市名。
• 根因分析 ：Harness中的参数校验层不够严格，或者LLM在生成参数时出现“幻觉”。
• 排查与解决 ：
  • 实施多层校验 ：
    1. 语法校验 ：对于SQL，可以使用轻量级解析器（如 sqlparse ）进行初步语法检查。
    2. 业务规则校验 ：维护一个合法的城市列表、用户ID列表等白名单，进行校验。
    3. 沙箱预执行 ：对于高风险操作（如写数据库），可以先在隔离环境执行“模拟”或“解释”命令（如 EXPLAIN SELECT ... ），确认无误后再执行真实操作。
  • 使用更精确的解析模式 ：利用LLM的Function Calling或JSON Mode特性，强制其输出结构化参数，这比从自由文本中提取要可靠得多。

5.4 问题：端到端测试不稳定，经常“玄学”失败

• 现象 ：CI流水线中的E2E测试时而过、时而不过，难以判断是代码问题还是模型波动。
• 根因分析 ：直接断言LLM输出的字符串完全匹配，对非确定性系统而言过于脆弱。
• 排查与解决 ：
  • 采用更健壮的评估方式 ：

    测试类型	评估方法	工具/示例
    功能性测试	检查输出是否包含 关键信息	assert “北京” in response and “晴” in response
    格式测试	检查输出是否为合法JSON/XML	json.loads(response) 不抛异常
    语义测试	使用 另一个LLM作为裁判 评估相关性、准确性	提问：“基于Assistant的回答，它是否正确回答了关于天气的问题？”
    相似度测试	计算输出与“黄金答案”的 嵌入向量相似度	使用 text-embedding-ada-002 计算余弦相似度，设定阈值（如>0.85）

  • 建立“测试基线” ：定期（如每周）在稳定的代码版本上运行一遍完整的E2E测试，将结果（包括LLM的输出）保存为基线。后续的测试失败，可以对比基线，快速判断是预期内的模型波动，还是代码引入的回归问题。

5.5 问题：Prompt的微小改动导致效果大幅下降

• 现象 ：为了优化某个表述，稍微改了改Prompt，结果整个Agent的表现一落千丈。
• 根因分析 ：LLM对Prompt极其敏感，存在“蝴蝶效应”。缺乏对Prompt变更的管控和测试。
• 排查与解决 ：
  • 将Prompt代码化 ：不要将Prompt以字符串形式硬编码在代码里。将其放在单独的配置文件（如YAML、JSON）或数据库中，便于版本管理和对比差异。
  • 建立Prompt版本库 ：使用Git管理Prompt文件，每次修改都有清晰的提交记录。
  • 实施Prompt的单元测试 ：为每个关键的Prompt编写一个小型测试套件，用一组固定的输入验证其输出是否稳定在可接受范围内。这个测试要跑在CI流水线里，任何对Prompt文件的修改都必须通过这套测试。
  • A/B测试 ：对于重大的Prompt优化，不要直接全量替换。通过A/B测试框架，将新旧Prompt同时部署给一小部分用户，收集效果数据（如任务完成率、用户满意度），用数据驱动决策。

构建一个稳定、可靠的AI Agent，是一场与不确定性的持久战。“Agent Harness”是我们手中的武器和盾牌，而“自工程完结”则是我们坚守的阵地和纪律。这套组合拳的核心思想，就是把AI系统的“智能”关进工程的“笼子”里，让它的能力得以安全、可控地释放。这个过程没有银弹，需要我们在架构设计、测试方法、运维监控上投入比传统软件更多的心思。但当你看到自己构建的Agent能够7x24小时稳定、准确地处理复杂任务，而你再也不用在深夜被报警电话吵醒时，你就会明白，所有这些前期看似“繁琐”的投入，都是值得的。从今天起，试着在你的下一个Agent项目中，引入哪怕一两个Harness组件，并坚持在当前的工序里解决掉你发现的问题，你会立刻感受到那种对系统掌控力提升带来的踏实感。