AI工程化：Harness如何为Agent提供生产级可靠性与可观测性-育师

1. 项目概述：重新认识Harness的定位

最近在AI工程化领域，Harness这个词的热度突然飙升，但随之而来的误解也铺天盖地。很多人一看到“Harness”和“上下文（Context）”同时出现，就下意识地认为Harness是来解决大模型上下文窗口不够用、或者优化上下文管理策略的工具。这种理解不能说完全错误，但确实把Harness的定位想窄了，甚至可以说是南辕北辙。我花了相当一段时间去研究相关的论文、开源项目以及业内的实践讨论，发现Harness的核心价值远不止于此，它本质上是一套工程基础设施，其目标和管理“上下文”这个具体问题属于不同维度。

简单来说，你可以把大模型应用开发想象成造一辆车。Agent（智能体）是这辆车的“发动机”和“控制系统”，它负责理解指令、规划路径、执行动作。而“上下文”就像是这辆车行驶时需要看的“地图”和“实时路况信息”，发动机需要根据这些信息来决定怎么开。现在，地图太大了（上下文太长），或者路况信息太杂（上下文噪音多），这确实是问题。但Harness并不是去直接修改地图或过滤路况的，它是为整辆车的制造、测试、上路监控和维修提供一整套“汽车生产线”和“4S店服务体系”。它关心的是：如何标准化地生产不同的发动机（Agent）？如何在上路前对发动机进行全面的安全性和性能测试？如何在上路后实时监控发动机的油耗、转速、温度，并在异常时自动介入？如何快速诊断故障并更换零件？

所以，当你在讨论上下文长度、上下文压缩、上下文检索这些具体技术时，你是在“发动机研发”的层面解决问题。而Harness是在“汽车工业化生产与运维”的层面提供保障。它管的不是“上下文”本身的内容和结构，而是“使用上下文的这个过程”是否可靠、可观测、可测试、可回滚。这是一个从微观战术到宏观战略的视角转换。理解了这一点，你才能明白为什么Harness会在AI工程化浪潮中占据如此重要的位置，它回应的是当AI智能体从Demo走向真实、复杂、关键的生产环境时，所必然面临的一系列工程挑战。

2. 核心需求解析：为什么我们需要Harness？

要理解Harness为何而生，我们必须先看看当前AI智能体（Agent）在落地时遇到的真实困境。Agent不再是那个在聊天框里和你侃侃而谈的玩具，它被期望去处理实际的业务流程：比如自动分析财报并生成投资建议、在客服系统中理解用户问题并调用多个内部API完成订票改签、或者作为编程助手理解整个代码库的变更并自动生成测试。在这些场景下，Agent的表现直接关系到业务成效甚至安全。

2.1 Agent生产环境的“不可控性”痛点

第一个核心痛点是“黑盒”与“不可预测”。传统的软件，输入确定，输出基本确定，逻辑可追溯。但基于大模型的Agent，其核心是概率模型，同样的提示词（Prompt）和上下文，可能因为模型本身的随机性产生截然不同的输出。更麻烦的是，这种随机性并非完全随机，它可能在某些边缘case下系统性出错。比如，一个处理订单的Agent，在99%的情况下都能正确解析“我想改签明天早上的航班”，但偏偏当用户说“把我后天的票挪到明天早上”这种非标准表述时，它可能错误地调用成了“退票”接口。这种问题在测试阶段很难被穷尽发现。

第二个痛点是“脆弱的依赖链”。一个复杂的Agent任务往往由多步推理和多个工具调用组成。这就像一段多米诺骨牌，任何一步的微小偏差都可能导致最终结果的灾难性错误。例如，Agent第一步总结用户需求时漏掉了一个关键约束（如“必须是靠窗的座位”），那么后续查询航班、选择座位、确认订单的所有步骤都将错下去。我们缺乏有效的手段来定位是链条中的哪一环最先出现了偏差。

第三个痛点是“上下文管理的工程复杂度”。是的，这里提到了上下文，但Harness关心的不是上下文里装什么，而是“装上下文”这个动作本身是否可靠。比如，你是否能确保每次调用模型时，组装上下文的逻辑是一致的？是否会有历史对话信息被意外截断或污染？当需要从向量数据库检索相关文档片段注入上下文时，检索的准确性和延迟是否稳定？这些都属于流程和管道的可靠性问题，而非上下文内容的优化问题。

2.2 Harness要解决的根本问题

因此，Harness的诞生，是为了给Agent的整个生命周期提供“确定性”和“可观测性”。它的核心需求可以归纳为以下几点：

标准化测试与评估：提供一套框架，能够像单元测试、集成测试一样，对Agent的各种能力（工具调用正确性、逻辑推理能力、安全合规性）进行自动化、批量化的测试。并且，测试用例要能随着业务场景的扩展而方便地积累和复用。
全链路可观测性：在Agent运行时，能够无侵入地追踪其内部状态。这包括：输入的原始用户请求、每一步的推理过程（Chain-of-Thought）、每一次工具调用的请求和响应、组装给模型的完整上下文、模型的原始输出、以及最终的决策和行动。当出现问题时，工程师可以像查看分布式系统的调用链一样，清晰地回溯问题根源。
安全护栏与干预：在Agent做出不可靠或高风险决策时，能够及时拦截。例如，当Agent试图调用一个高权限的删除API，或者其生成的内容包含敏感信息时，Harness层可以触发人工审核或直接执行预设的降级策略（如fallback到一个更保守的模型或规则引擎）。
版本管理与回滚：Agent的构成不仅仅是模型本身，还包括提示词模板、工具集、推理逻辑等。Harness需要管理这些组件的不同版本，并能快速进行A/B测试或一键回滚到上一个稳定版本。
成本与性能监控：精确统计每次调用消耗的Token数、模型调用延迟、工具调用成功率等指标，为优化和成本控制提供数据支持。

可以看到，这些需求都是围绕“工程管控”展开的，其目标是将Agent从一种“艺术创作”转变为“工业化产品”。Harness就是那条确保产品出厂质量、并能在服役期间持续监控维护的生产线。

3. Harness与Agent、上下文的本质区别

概念混淆是误解的根源。我们有必要把Harness、Agent、Context这三个关键概念放在一个清晰的架构图里来看待它们的关系。

3.1 智能体（Agent）：核心决策与执行引擎

Agent是承担具体任务的主体。它通常包含以下几个核心模块：

规划器（Planner）：分解复杂任务为子步骤。
记忆（Memory）：存储和回忆历史交互、知识。
工具集（Tools）：调用外部API或函数的能力。
执行器（Executor）：按照规划调用工具并处理结果。

Agent的核心是“推理”和“决策”。它接收用户的请求，结合记忆（历史上下文），规划步骤，选择工具，执行动作，并产生最终输出。它的好坏，取决于其内部逻辑设计、使用的模型能力以及提示词工程的水平。

3.2 上下文（Context）：模型的输入信息窗口

Context特指提交给大语言模型（LLM）的那一串文本（Token序列）。它通常由以下几部分组成：

系统提示词（System Prompt）：定义Agent的角色、能力和行为规范。
对话历史（Conversation History）：本轮对话中已发生的多轮问答。
检索到的知识（Retrieved Knowledge）：从向量数据库等外部知识源中查询到的相关文档片段。
工具描述（Tool Descriptions）：可供Agent调用的工具的函数签名和说明。
当前用户查询（Current Query）：用户的最新问题或指令。

上下文管理的目标，是在有限的Token窗口内，高效、准确、无冲突地组织这些信息，以最大化模型的理解和表现。这属于“模型输入优化”的范畴。

3.3 基础设施层（Harness）：包裹引擎的底盘与控制系统

Harness并不取代Agent，也不直接构造Context。它位于Agent（以及组成Agent的各个组件）的外围，提供支撑和管控。一个典型的Harness架构可能包含以下层级：

层级	功能	类比
编排层 (Orchestration)	管理多个Agent或任务的执行流、处理异常、协调资源。	工厂的生产调度中心。
评估层 (Evaluation)	运行自动化测试套件，对Agent的输出进行评分（基于规则、模型或人工反馈）。	产品质量检测线。
可观测层 (Observability)	收集日志、指标和追踪（Trace），提供运行看板和调试工具。	汽车的仪表盘和黑匣子。
护栏层 (Guardrails)	实施内容安全过滤、合规检查、成本控制等策略。	汽车的ABS防抱死系统和电子限速器。
部署层 (Deployment)	管理Agent及其依赖的版本、配置、发布和回滚。	汽车的装配线和软件OTA升级系统。

3.4 一个具体场景下的分工示例

假设我们要构建一个“智能旅行助手Agent”。

Agent的工作：理解用户说“帮我规划一个为期三天的北京美食之旅，预算中等”，然后它需要调用“搜索景点API”、“查询餐厅评价API”、“规划路线API”等一系列工具，最终生成一份详细的行程表。
Context的工作：在Agent每一步调用模型进行推理时，负责组织好当前的对话历史（用户刚才说了什么）、相关的工具说明（各个API怎么用）、以及从知识库检索到的“北京美食攻略”片段，形成一个有效的提示，喂给模型。
Harness的工作：
- 在测试阶段：自动运行100个不同的用户请求测试用例（如“规划海岛游”、“变更行程”等），检查Agent生成的行程是否合理、预算计算是否准确、是否错误调用了“订票API”（如果当前不该调用）。
- 在运行阶段：记录下用户每一次请求的完整处理链条。当Agent错误地将“豆汁”推荐给一个明确说“不吃发酵食品”的用户时，工程师可以通过Harness提供的追踪界面，快速定位到是“检索知识”环节给了错误信息，还是Agent在推理时忽略了用户约束。
- 在安全层面：当用户输入或Agent输出中出现“帮我订一张假机票”这类敏感词时，Harness的护栏会触发，拦截该请求并通知人工审核。
- 在运维层面：当我们将Agent的模型从GPT-4升级到Claude-3时，Harness可以同时部署两个版本，并将部分流量导入新版本进行A/B测试，对比两者的成功率和成本，再决定是否全量切换。

所以，Harness管的不是“上下文里有什么”，而是“拥有上下文的这个Agent，它在被使用时的全过程，是否可靠、可见、可控”。这是工程成熟度跃升的关键。

4. Harness的核心组件与功能拆解

理解了Harness的定位，我们再来深入看看它通常由哪些核心组件构成，以及每个组件是如何工作的。这有助于我们在技术选型或自建框架时，有一个清晰的蓝图。

4.1 测试与评估框架

这是Harness最基础也是最重要的功能之一。传统的软件测试方法（单元测试、集成测试）在面对基于LLM的Agent时几乎失效，因为输出是非确定性的文本。Harness的评估框架需要解决这个问题。

评估类型：
- 基于规则的评估：适用于有明确规则的场景。例如，检查生成的SQL语句语法是否正确，生成的JSON格式是否符合预定模式，或者回答中是否包含了某些关键词。这可以通过编写断言（Assertion）函数来实现。
- 基于模型的评估：用另一个LLM（通常是更强大或更便宜的模型）作为“裁判”，来评估主Agent的输出。例如，给裁判模型提供问题和Agent的答案，让它判断“答案是否准确回答了问题”、“答案是否友好”。这需要精心设计裁判的提示词。
- 基于人工反馈的评估：将关键或存疑的案例提交给人工标注，并将结果反馈回系统，用于优化模型或提示词。Harness需要提供便捷的人工评审界面和数据管理流程。
测试用例管理：Harness需要提供一个库，用于存储和管理大量的测试用例（输入-期望输出对）。这些用例可以按功能模块、风险等级分类，并支持批量运行和结果对比。一个好的实践是，将生产环境中遇到的bad case不断转化为回归测试用例，防止问题复发。
持续集成/持续部署集成：评估框架应该能与CI/CD管道集成。每次代码或提示词更新后，自动触发测试套件运行，只有通过所有关键测试的版本才能被部署到生产环境。

实操心得：在构建评估体系时，切忌追求“完美准确率”。初期应该聚焦于“防止严重错误”的测试，比如工具调用的参数是否正确、输出是否包含明显的不安全内容。基于模型的评估成本较高且有一定波动性，更适合作为抽样检查，而非每次发布的硬性关卡。

4.2 可观测性与追踪

当Agent在生产环境出错时，一句“它回答错了”对调试毫无帮助。我们需要知道它“思考”的每一步。这就是可观测性的价值。

追踪数据采集：Harness需要在Agent执行的各个关键节点植入“探针”，自动收集以下信息：
- 输入/输出：原始用户输入、模型的每次请求和响应、工具调用的请求和响应。
- 中间状态：每一步的推理过程（如果模型支持输出CoT）、检索系统返回的文档片段、组装后的完整提示词（Context）。
- 元数据：调用时间戳、耗时、消耗的Token数、模型名称、用户ID、会话ID等。
可视化与查询：收集的数据需要被聚合和展示。一个优秀的Harness会提供一个类似分布式链路追踪（如Jaeger）的界面，以时间线或树状图的形式展示一次用户请求的完整生命周期。工程师可以点击任意节点，查看当时的详细上下文和状态。
指标与告警：基于采集的数据，可以计算关键业务指标（如任务完成率、平均对话轮次）和技术指标（如平均响应延迟、Token消耗成本）。当指标异常（如错误率飙升、平均耗时激增）时，触发告警。

4.3 安全护栏与内容策略

这是确保Agent行为符合预期的安全网。护栏通常以“过滤器”或“拦截器”的形式存在，在请求或响应的流经路径上进行检查。

输入过滤：检查用户输入是否包含恶意提示注入、敏感词、个人隐私信息等。例如，试图让Agent“忘记之前的指令”或执行越权操作的输入可以被识别并拦截。
输出过滤：检查Agent的最终输出或中间推理内容是否包含事实性错误、偏见歧视性言论、泄露内部信息等。例如，一个处理公司内部数据的Agent，其输出不应包含未脱敏的员工身份证号。
工具调用控制：检查Agent发起的工具调用是否被授权、参数是否在安全范围内。例如，一个只有查询权限的Agent试图调用“删除数据库”的API，护栏必须阻止此次调用。
动态干预：除了直接拦截，护栏还可以采取更柔和的措施，如将输出重定向给人工审核、触发一次额外的验证性模型调用、或者用更安全的模板覆盖原有输出。

4.4 编排、版本与部署

对于复杂的应用，可能需要协调多个Agent协同工作，或者管理同一Agent的不同版本。

工作流编排：定义复杂的、多步骤的业务流程，其中某些步骤由Agent处理，某些由传统代码处理。Harness需要提供一种方式来定义这种工作流（如使用YAML或DSL），并处理步骤间的数据传递、错误处理和重试逻辑。
版本管理：将Agent的构成（模型、提示词、工具列表、配置参数）打包成一个可版本化的“Bundle”。支持版本的创建、发布、回滚和灰度发布。
配置管理：集中管理不同环境（开发、测试、生产）的配置，如API密钥、模型端点、开关参数等，实现配置与代码分离。

5. 主流Harness方案分析与选型建议

目前市场上有多种形态的Harness方案，从开源框架到商业平台，各有侧重。了解它们的特性，有助于我们根据自身情况做出选择。

5.1 开源框架

这类方案提供了构建Harness的核心库和工具，灵活度高，但需要自行集成和搭建。

LangChain / LlamaIndex：虽然常被用于构建Agent，但它们也包含了大量Harness相关的组件。例如，LangChain的callbacks机制是实现可观测性的基础，Evaluators模块提供了多种评估器。LlamaIndex在检索环节的评估和可观测性方面有独到之处。它们更像是一套丰富的乐高积木，需要你自己搭建成完整的Harness系统。
Phoenix：由Arize AI开源，主打LLM应用的可观测性与评估。它提供了非常出色的追踪可视化界面，可以直观地看到每次调用的链式结构、工具使用、检索内容等。同时内置了嵌入向量分析、幻觉检测等高级评估功能。对于已经基于LangChain等框架构建的应用，可以较低成本地接入Phoenix获得强大的可观测能力。
Trulens：另一个专注于评估与追踪的开源库。它采用“反馈函数”的概念，将评估逻辑模块化，方便用户自定义各种评估指标（如相关性、毒性、真实性）。它也提供了详细的追踪记录功能。

5.2 商业平台/云服务

这类方案提供端到端的、开箱即用的平台，集成度更高，但通常有成本和供应商锁定的考虑。

Arize AI / Weights & Biases / LangSmith：这些是专门的MLOps或LLMOps平台。它们的功能非常全面，覆盖了从实验追踪、提示词管理、评估测试到生产环境监控的全生命周期。特别是LangSmith，作为LangChain的官方平台，集成度最高，提供了托管版的评估、监控和协作功能。适合团队规模较大、对工程化要求极高、且不希望自己维护底层基础设施的团队。
云厂商的AI平台：如Azure AI Studio、Google Vertex AI Agent Builder、AWS Bedrock Agent。它们将模型服务、Agent构建工具、以及一部分评估监控能力打包在一起。优势是与云生态结合紧密，部署方便。但可能在跨云、使用非自家模型时会有限制，且Harness功能的深度和灵活性可能不如独立平台。

5.3 自建Harness的考量

对于有强烈定制化需求或数据安全顾虑的大型企业，自建Harness是一个选项。这通常意味着：

定义数据模型：设计统一的格式来记录追踪信息（Trace）。
构建采集SDK：开发轻量级的库，让业务代码方便地发送追踪数据。
建立数据管道与存储：使用消息队列（如Kafka）接收数据，并存入适合查询的数据库（如Elasticsearch、ClickHouse）。
开发控制台：实现数据可视化、查询、评估和告警的界面。
集成护栏系统：将安全策略引擎（可以是规则引擎或模型）集成到请求链路中。

这条路技术挑战和运维成本都很高，除非有非常迫切的理由，否则不建议初创团队或中小项目从头开始。

5.4 选型建议

考量维度	推荐方案	理由
快速启动，验证想法	LangChain + Phoenix	LangChain快速搭建Agent原型，Phoenix以最小成本接入，立刻获得可视化追踪和基础评估能力，帮助快速迭代和调试。
中小团队，注重效率	LangSmith或Arize AI	免去自建基础设施的麻烦，提供一站式的协作、测试、部署、监控平台，能显著提升团队在Agent开发上的工程效率。
大企业，复杂场景，强定制	基于开源框架自建核心，结合商业平台	用开源框架（如Phoenix的SDK）处理核心数据采集和评估逻辑，在其上自建符合内部流程的控制台和护栏。同时可以采购部分商业平台能力作为补充。
深度绑定特定云生态	对应云的AI平台	如果技术栈已深度绑定Azure/AWS/GCP，且其提供的Agent和Harness功能满足需求，使用云平台是最省心的选择。

注意事项：无论选择哪种方案，数据隐私和安全性必须是首要考量。确保追踪日志中不会记录敏感的生产数据（如用户密码、个人身份信息）。商业平台需要明确其数据存储和传输策略是否符合公司合规要求。

6. 实战：为一个简单Agent接入基础Harness

理论说了这么多，我们通过一个具体的例子，来看看如何为一个简单的Agent添加最基础的Harness能力——即可观测性。我们假设已经有一个基于LangChain构建的、能查询天气的简单Agent。

6.1 初始Agent代码

# 一个简单的天气查询Agent from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain.llms import OpenAI import requests def get_weather(city: str) -> str: """模拟一个查询天气的API""" # 这里简化处理，实际应调用真实API return f"{city}的天气是晴朗，25摄氏度。" weather_tool = Tool( name="Weather", func=get_weather, description="查询指定城市的天气" ) llm = OpenAI(temperature=0) agent = initialize_agent( tools=[weather_tool], llm=llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=True # LangChain自带的简单日志 ) # 执行 result = agent.run("北京今天天气怎么样？") print(result)

这个Agent能工作，但除了控制台打印的verbose日志，我们没有任何运行时数据可供分析。一旦在生产环境出错，我们只能看到“它回答错了”，别无他法。

6.2 接入Phoenix实现可观测性

Phoenix提供了与LangChain无缝集成的LangChainTracer，可以自动捕获详细的追踪信息。

首先，安装并启动Phoenix：

pip install arize-phoenix # 在一个终端启动Phoenix服务 phoenix serve

然后，修改Agent代码，注入追踪器：

from langchain.agents import initialize_agent, AgentType from langchain.tools import Tool from langchain.llms import OpenAI from phoenix.trace.langchain import LangChainTracer # 导入Phoenix追踪器 import requests def get_weather(city: str) -> str: return f"{city}的天气是晴朗，25摄氏度。" weather_tool = Tool(name="Weather", func=get_weather, description="查询指定城市的天气") llm = OpenAI(temperature=0) # 创建Phoenix追踪器实例 tracer = LangChainTracer() agent = initialize_agent( tools=[weather_tool], llm=llm, agent=AgentType.ZERO_SHOT_REACT_DESCRIPTION, verbose=False, # 可以关闭LangChain自带的verbose，用Phoenix看更详细的 callbacks=[tracer] # 关键：将追踪器作为回调传入 ) # 执行多个查询，数据会被自动收集 queries = [ "北京今天天气怎么样？", "上海和广州的天气对比一下", "帮我查一下不存在城市的天气", # 一个可能出错的case ] for query in queries: try: result = agent.run(query) print(f"Query: {query}\nResult: {result}\n") except Exception as e: print(f"Query: {query}\nError: {e}\n")

运行完这段代码后，打开浏览器访问http://localhost:6006，你就能看到Phoenix的UI界面。在“Traces”页面，你会看到刚才三次调用的记录。点击任意一条，可以看到完整的追踪详情：

Agent执行概览：总耗时、Token消耗。
详细的链式结构：以树状图展示AgentExecutor->LLMChain->Tool的调用层级。
每一步的输入输出：点击LLMChain节点，可以看到发送给模型的完整提示词（Context）和模型返回的原始响应。这让你能精确地知道模型“看到了什么”以及“回答了什么”。
工具调用详情：点击Tool节点，可以看到工具被调用时的输入参数和返回结果。

通过这个简单的集成，我们就获得了远超verbose=True的洞察力。现在，当用户报告“Agent回答错了”时，我们可以通过Phoenix界面，定位到是工具返回的数据有误，还是模型错误地解析了工具的结果，亦或是初始的提示词组装就有问题。

6.3 添加基础评估

Phoenix也支持简单的评估。例如，我们可以自动检查每次Agent调用是否成功调用了正确的工具。

from phoenix.trace import SpanEvaluator from phoenix.trace.semantic_conventions import INPUT_VALUE, OUTPUT_VALUE # 定义一个简单的评估函数：检查输出中是否包含“天气”这个词（非常简单的成功指标） def contains_weather_word(span) -> bool: output = span.attributes.get(OUTPUT_VALUE, "") return "天气" in output # 在UI中，我们可以配置这个评估函数，对收集到的Trace进行批量评分。 # 这通常在Phoenix的UI界面中通过“Evaluations”功能配置，或者通过SDK以编程方式运行。

虽然这个评估函数很简单，但它演示了思路：基于追踪数据（Span），我们可以编写任意的逻辑来对Agent的表现进行自动化评分。更复杂的评估，比如用另一个LLM判断答案的相关性，也可以遵循类似的模式。

通过这个实战例子，你可以清晰地看到，Harness（这里以Phoenix为例）是如何以“非侵入”的方式附着在原有Agent之上的。它没有修改Agent的核心逻辑，也没有改变上下文组装的方式，但它让整个运行过程变得透明、可分析、可度量。这正是Harness的价值所在。

7. 实施Harness的常见陷阱与进阶思考

即使理解了Harness的概念和价值，在真正实施过程中，团队依然会踩不少坑。结合我观察到的项目经验，这里总结几个关键陷阱和对应的进阶思考。

7.1 陷阱一：过度追踪，数据泛滥

一开始，团队可能会兴奋于可观测性，试图记录所有东西：每一次中间LLM调用、每一个变量的值、整个庞大的上下文内容。这会导致：

性能开销巨大：序列化和传输大量数据会显著增加延迟。
存储成本飙升：Trace数据量可能远超业务数据本身。
信息过载：在海量数据中找到有用信息如同大海捞针，反而降低了调试效率。

避坑指南：遵循“按需采集”原则。定义清晰的排查场景，只采集满足这些场景所需的最小数据集。例如，对于大多数调试，知道模型接收到的提示词前缀和工具调用的输入输出就足够了，不必记录整个超长的上下文。利用采样率，在生产环境只对少量请求（如1%）或错误请求进行全量追踪。

7.2 陷阱二：评估指标脱离业务

团队可能花费大量精力去优化“回答的流畅度”、“与标准答案的余弦相似度”等通用指标，但这些指标提升未必能带来业务价值的提升。一个客服Agent，回答得再流畅，如果解决不了用户问题，也是徒劳。

避坑指南：评估必须与核心业务指标对齐。首先定义清楚Agent的成功标准是什么。是任务完成率？是用户满意度评分（CSAT）？是平均处理时长？还是转化率？然后，设计能间接或直接衡量这些业务指标的评估方法。例如，对于任务完成率，可以结合规则检查（关键信息是否提取正确）和模型评估（最终输出是否解决了问题）来综合判断。

7.3 陷阱三：护栏设计过于僵化

为了防止出错，设置过于严格的护栏，导致大量正常请求被误拦截，用户体验受损。例如，因为担心幻觉，就过滤掉所有包含不确定词汇（如“可能”、“也许”）的回答，这会让Agent显得非常死板和不自信。

避坑指南：护栏策略应该是有层级的、可调节的。建立“拦截”、“审核”、“放行”等多级处理机制。对于高风险操作（如删除、支付），采取严格拦截；对于中风险内容（如涉及事实的陈述），可以触发一次额外的验证性查询或打上“需要核实”的标签；对于低风险的语言风格问题，则可以适当放宽。同时，护栏的规则需要根据误报率（False Positive）和漏报率（False Negative）的数据持续迭代优化。

7.4 陷阱四：将Harness视为一次性项目

很多团队把搭建Harness当作一个开发任务，上线后就束之高阁。实际上，Harness系统本身需要持续的运营和维护。