1. 从概念到现实为什么我们需要 Harness Engineering如果你最近在捣鼓 AI Agent大概率经历过这样的场景你有一个绝妙的想法用大语言模型LLM作为大脑让它能自动处理任务。你兴奋地写了几十行提示词Prompt调用 API第一次运行它完美地回复了你。你觉得成了这就是你的“智能助理”。然后你开始增加功能让它能联网搜索、能读写文件、能调用工具Tools。很快代码变得混乱提示词层层嵌套错误处理像打补丁每次运行的成本和耗时变得不可预测。更头疼的是昨天还能正常工作的流程今天因为模型 API 的一个微小变动或者网络波动就彻底崩溃了。你发现自己 80% 的时间不是在设计智能逻辑而是在处理工程上的“脏活累活”日志记录、状态管理、错误重试、流程编排、成本监控……这就是当前 AI Agent 开发最真实的写照。我们拥有了强大的“大脑”LLM但缺乏一个健壮的“神经系统”和“骨骼肌肉系统”来支撑它完成复杂、持久的现实任务。Harness Engineering这个概念正是在这种背景下被提出。它不是什么高深的新算法而是一套工程哲学和最佳实践的集合核心目标是将 AI Agent 的核心推理能力做什么与支撑其稳定运行的基础设施怎么做解耦并通过系统化的工程手段让 Agent 的开发、部署、运维变得像开发传统软件一样可控、可靠、可扩展。你可以把 Harness 直观地理解为“缰绳”或“ harness”马具。它的作用不是代替马Agent去奔跑而是为这匹充满潜力但可能“野性难驯”的马套上缰绳、鞍鞯让骑手开发者能够安全、精准地驾驭它完成长途跋涉而不仅仅是短距离冲刺。这套“马具”就是包裹在 Agent 核心逻辑之外的基础设施层。为什么这变得如此关键因为 AI Agent 的本质是非确定性的状态机。传统程序是if-else的确定世界而 Agent 的每一步都可能因为 LLM 的输出波动、外部工具调用的失败、上下文Context的累积与偏差而走向不同的分支。没有 Harness你的 Agent 就是一个在复杂环境中“裸奔”的智能体一次意外的 API 超时或一个歧义的模型回复就可能导致整个任务链不可逆地失败且难以追溯和调试。因此Harness Engineering 解决的正是智能体落地“最后一公里”的工程难题是将实验室原型转化为生产级应用的关键桥梁。2. Harness Engineering 核心架构拆解不止于代码框架提到工程化很多人第一反应是找一个开发框架。市面上确实涌现了不少优秀的框架如 LangChain、LlamaIndex、Semantic Kernel基于C#/.NET等它们提供了大量工具集成和链式编排能力。但 Harness Engineering 的范畴远大于选择一个框架。它是一个自上而下的系统性视角涵盖从设计、开发到运维的全生命周期。我们可以将其核心架构分解为以下几个层次2.1 控制层智能体的“驾驶舱”这是 Harness 最核心的部分负责管理 Agent 的执行流程和状态。它决定了 Agent 如何思考、如何决策、何时停止。流程编排与状态管理Agent 的任务 rarely 是单步完成的。一个客服 Agent 可能需要先理解问题、查询知识库、生成草稿、审核、最后发送。控制层需要定义并管理这个有向无环图DAG。它需要持久化任务状态确保在系统中断后能从中断点恢复而不是从头开始。这里的关键是引入明确的状态机例如将任务划分为PENDING等待、RUNNING运行中、AWAITING_USER_INPUT等待用户输入、TOOL_CALLING调用工具中、COMPLETED完成、FAILED失败等状态。规划与反思Planning Reflection高级的 Agent 不是被动响应而是能主动规划。控制层需要集成规划模块让 Agent 能分解复杂目标为子任务序列Lets think step by step 的系统化实现。更重要的是反思Reflection机制当某个步骤结果不佳或工具调用失败时Agent 能分析原因调整策略甚至回溯到上一步重新尝试。这通常通过一个“批判者”CriticLLM 或规则引擎来实现。上下文管理与优化LLM 的上下文窗口是宝贵且有限的资源。控制层必须智能地管理对话历史和中间结果。这包括关键信息提取与摘要将冗长的历史压缩成精华动态上下文窗口根据当前任务焦点加载最相关的历史片段外部知识库的精准检索RAG避免将全部知识塞入提示词。这里的工程挑战在于平衡信息的完整性与 token 的成本。2.2 可靠性层为不确定性穿上“防弹衣”LLM 和外部服务天生具有不确定性。这一层确保 Agent 在波动的环境中依然坚韧。弹性与重试机制API 调用失败、网络抖动、工具服务暂时不可用——这些是家常便饭。简单的try-catch不够。需要实现具有退避策略的智能重试如指数退避并为不同的错误类型如速率限制、内容过滤、服务器错误配置不同的重试逻辑和回退方案如降级使用另一个模型或工具。超时与熔断防止单个步骤卡死整个 Agent。为每个 LLM 调用、工具调用设置严格的超时时间。当某个服务连续失败时触发熔断器暂时绕开该服务避免雪崩效应。验证与护栏Guardrails这是安全与可控性的生命线。在 Agent 行动前或输出前对决策和内容进行校验。输出格式验证确保 LLM 的输出严格遵循指定的 JSON、XML 或自然语言格式便于后续解析。内容安全过滤检测并拦截有害、偏见或不合规的生成内容。业务规则约束例如一个订票 Agent 不能预订过去日期的机票一个投资建议 Agent 的风险评级不能超过用户设定的阈值。这通常需要将规则硬编码或通过小型校验模型来实现。2.3 可观测层打开智能体的“黑箱”调试一个行为不可预测的 Agent 是噩梦。可观测性让我们能看清内部运作快速定位问题。结构化日志告别print语句。记录每个关键事件的结构化日志输入的提示词、LLM 的原始响应、工具调用的参数和结果、状态变迁、token 消耗量、耗时。这些日志应该易于搜索和聚合通常输出到如 Elasticsearch、Loki 等系统。链路追踪一个用户查询可能触发多个 Agent 协作和数十次 LLM/工具调用。像分布式系统一样为每个“用户会话”或“任务”分配唯一的 Trace ID贯穿整个调用链让你能完整复现决策路径。指标与监控定义关键业务和技术指标Metrics任务成功率、平均完成时间、每一步的耗时分布、LLM API 调用次数和 token 消耗成本、工具调用错误率。通过仪表盘如 Grafana实时监控并设置警报如错误率突增、成本超支。会话回放与调试能够像播放电影一样回放任意一次失败或成功的 Agent 运行全过程查看每一步的完整上下文、模型响应和内部状态。这是诊断诡异问题的终极武器。2.4 运维与资源层保障高效与合规的“后勤部”当 Agent 从单机脚本变为服务化部署时这一层至关重要。配置化管理将模型参数温度、top_p、提示词模板、工具清单、业务规则全部从代码中抽离变为配置文件或数据库中的记录。支持热更新无需重启服务即可调整 Agent 行为。成本管理与优化LLM API 调用是主要成本来源。需要精细核算每个任务、每个用户的 token 消耗并设置预算和配额。实施成本优化策略如为不同优先级的任务选择不同价位的模型或缓存常见的推理结果。版本管理与实验提示词的微小改动可能导致性能巨大波动。需要像管理代码一样管理提示词、工作流配置和模型版本的组合。支持 A/B 测试能够将不同版本的 Agent 部署给部分用户对比其任务成功率和用户满意度。3. 实战构建一个具备 Harness 的简易任务执行 Agent理论说得再多不如动手实践。让我们抛开复杂框架用最直观的方式构建一个具有基本 Harness 能力的任务执行 Agent。这个 Agent 的目标是理解用户一个包含多步骤的自然语言指令并自动调用合适的工具完成它。例如“查一下北京明天天气如果晴天就提醒我晚上去跑步。”我们将使用 Python 作为主要语言但思路适用于任何语言。这里不会直接用 LangChain而是从零开始设计以便你透彻理解每个环节。3.1 定义核心组件与接口首先我们定义几个核心的抽象接口这是良好设计的起点。# 定义工具Tool的抽象基类。所有可被Agent调用的能力都实现这个接口。 from abc import ABC, abstractmethod from typing import Any, Dict, Optional from pydantic import BaseModel class Tool(ABC): name: str description: str abstractmethod def execute(self, **kwargs) - str: 执行工具返回字符串格式的结果 pass # 定义Agent执行步骤的结果模型。使用Pydantic便于验证和序列化。 class StepResult(BaseModel): step_id: str status: str # success, failure, pending thought: Optional[str] None # Agent的“思考过程” tool_used: Optional[str] None tool_input: Optional[Dict] None tool_output: Optional[str] None error: Optional[str] None # 定义任务上下文贯穿整个执行过程保存所有状态。 class TaskContext(BaseModel): task_id: str user_input: str current_plan: Optional[str] None # 当前的执行计划 history: List[StepResult] [] # 已执行的步骤历史 accumulated_results: Dict[str, Any] {} # 累积的中间结果供后续步骤使用 status: str pending # 任务整体状态3.2 实现基础工具与可靠性包装我们实现两个简单的工具天气查询和发送提醒。关键是为工具调用添加基本的可靠性层。import requests import time from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type # 一个具体的工具实现天气查询 class WeatherTool(Tool): def __init__(self): self.name get_weather self.description 查询指定城市未来一天的天气情况。输入参数city城市名 # 使用tenacity库添加重试装饰器这是可靠性层的体现 retry( stopstop_after_attempt(3), # 最多重试3次 waitwait_exponential(multiplier1, min2, max10), # 指数退避等待 retryretry_if_exception_type((requests.ConnectionError, requests.Timeout)) # 只对网络错误重试 ) def execute(self, city: str) - str: # 模拟一个可能失败的外部API调用 print(f[WeatherTool] 正在查询{city}的天气...) # 这里为了演示我们模拟网络请求和失败 if city 网络异常城市: raise requests.ConnectionError(模拟网络连接失败) time.sleep(0.5) # 模拟延迟 # 模拟返回结果 weather_data { 北京: 明天晴天气温15-25度微风。, 上海: 明天多云转阴气温18-22度东南风3级。 } return weather_data.get(city, f未找到{city}的天气信息。) # 另一个工具发送提醒 class ReminderTool(Tool): def __init__(self): self.name send_reminder self.description 向用户发送一个提醒。输入参数message提醒内容 def execute(self, message: str) - str: print(f[ReminderTool] 发送提醒{message}) # 在实际应用中这里可能是调用短信API、邮件API或推送通知 return f提醒已发送{message}注意retry装饰器是 Harness Engineering 中“弹性”的典型实现。它让我们用声明式的方式为可能失败的操作添加了重试逻辑而不是在业务代码中写满try-catch循环。wait_exponential策略避免了失败时立即重试给服务端带来的压力。3.3 构建具备规划与反思能力的控制层核心这是 Agent 的“大脑”。我们实现一个简单的基于 LLM 的规划器和执行引擎。import openai # 或其他LLM API客户端 import json class SimpleAgentController: def __init__(self, llm_client, tools: Dict[str, Tool]): self.llm llm_client self.tools tools # 工具字典key为工具名 # 一个系统提示词用于引导LLM进行规划和工具调用 self.system_prompt 你是一个任务执行助手。请根据用户目标一步步思考并决定是否需要调用工具。 你可以调用的工具如下 {tools_descriptions} 请严格按照以下JSON格式回应 {{ thought: 你的思考过程分析当前情况和下一步该做什么。, action: next_action_type, // 只能是 call_tool 或 final_answer tool_name: 工具名仅当action为call_tool时提供, tool_input: {{参数名: 参数值}}, // 仅当action为call_tool时提供必须匹配工具所需的参数 final_response: 给用户的最终答案仅当action为final_answer时提供 }} 确保你的输出是合法的JSON。 def _create_plan(self, user_input: str, context: TaskContext) - Dict: 第一步让LLM根据用户输入和当前上下文制定计划或决定下一步行动。 # 动态生成工具描述部分 tools_desc \n.join([f- {name}: {tool.description} for name, tool in self.tools.items()]) prompt self.system_prompt.format(tools_descriptionstools_desc) user_message f用户目标{user_input}\n\n当前已执行步骤{context.history}\n当前累积信息{context.accumulated_results} try: response self.llm.chat.completions.create( modelgpt-3.5-turbo, # 或使用其他模型 messages[ {role: system, content: prompt}, {role: user, content: user_message} ], temperature0.1, # 低温度让输出更确定符合JSON格式 response_format{ type: json_object } # 强制JSON输出这是OpenAI API的一个有用特性 ) decision json.loads(response.choices[0].message.content) # 这里可以添加输出验证Guardrail确保decision格式正确action值有效 if decision[action] not in [call_tool, final_answer]: raise ValueError(f无效的action类型{decision[action]}) return decision except (json.JSONDecodeError, KeyError) as e: # 如果LLM没有返回合法JSON这是一个严重的可靠性问题需要处理 print(fLLM返回格式解析失败{e}) # 可以在这里实现一个fallback策略例如使用更简单的提示词重试或直接返回错误 return {thought: 解析响应失败, action: final_answer, final_response: 系统处理您的请求时出现了内部错误。} def execute_step(self, context: TaskContext) - StepResult: 执行单个步骤规划 - 执行工具/生成答案 - 记录结果 step_id fstep_{len(context.history)1} step_result StepResult(step_idstep_id, statuspending) # 1. 规划阶段 decision self._create_plan(context.user_input, context) step_result.thought decision.get(thought) # 2. 执行阶段 if decision[action] call_tool: tool_name decision[tool_name] tool_input decision[tool_input] step_result.tool_used tool_name step_result.tool_input tool_input if tool_name not in self.tools: step_result.status failure step_result.error f请求的工具 {tool_name} 不存在。 else: tool self.tools[tool_name] try: # 执行工具这里已经内置了重试机制 output tool.execute(**tool_input) step_result.tool_output output step_result.status success # 将工具输出累积到上下文中供后续步骤使用 context.accumulated_results[fstep_{step_id}_output] output except Exception as e: # 即使有重试仍可能最终失败 step_result.status failure step_result.error f工具 {tool_name} 执行失败{str(e)} # 这里可以触发更复杂的反思逻辑比如让LLM分析错误原因并调整策略 elif decision[action] final_answer: step_result.status success # 对于最终答案步骤我们可以将其输出也记录下来但通常不调用工具 context.accumulated_results[final_answer] decision.get(final_response, ) # 此时可以认为任务完成更新上下文状态 context.status completed # 3. 将步骤结果记录到历史 context.history.append(step_result) return step_result3.4 组装与运行体验基础 Harness 带来的韧性现在让我们把各个部分组装起来并模拟一个完整的任务执行流程同时加入简单的可观测性——日志。def main(): # 1. 初始化工具和LLM客户端这里用模拟客户端代替真实API调用 class MockLLMClient: def chat(self): return self class completions: staticmethod def create(model, messages, temperature, response_format): # 这是一个模拟的LLM它会根据输入“智能地”决定行动 user_msg messages[1][content] if 天气 in user_msg and 北京 in user_msg: # 决定调用天气工具 return type(obj, (object,), { choices: [type(obj, (object,), { message: type(obj, (object,), { content: json.dumps({ thought: 用户想查询北京天气。我需要调用天气查询工具。, action: call_tool, tool_name: get_weather, tool_input: {city: 北京} }) })() })] })() elif 晴天 in user_msg and 跑步 in user_msg: # 假设上一步的天气结果已经存在上下文中这里模拟LLM看到了晴天结果决定发送提醒 return type(obj, (object,), { choices: [type(obj, (object,), { message: type(obj, (object,), { content: json.dumps({ thought: 根据上一步结果北京明天是晴天。用户说如果是晴天就提醒跑步。我需要发送一个跑步提醒。, action: call_tool, tool_name: send_reminder, tool_input: {message: 明天北京天气晴朗适合晚上去跑步别忘了哦} }) })() })] })() else: # 最终结束 return type(obj, (object,), { choices: [type(obj, (object,), { message: type(obj, (object,), { content: json.dumps({ thought: 所有步骤已完成。, action: final_answer, final_response: 已按照您的要求查询了天气并设置了提醒。 }) })() })] })() llm_client MockLLMClient() tools { get_weather: WeatherTool(), send_reminder: ReminderTool() } # 2. 初始化控制器和任务上下文 agent SimpleAgentController(llm_client, tools) task_id task_001 user_input 查一下北京明天天气如果晴天就提醒我晚上去跑步。 context TaskContext(task_idtask_id, user_inputuser_input) print(f 开始执行任务 {task_id} ) print(f用户指令{user_input}\n) # 3. 任务执行循环直到状态变为完成或失败 max_steps 10 # 防止无限循环 for i in range(max_steps): print(f\n--- 第 {i1} 步开始 ---) step_result agent.execute_step(context) # 简单的结构化日志输出可观测层雏形 log_entry { task_id: context.task_id, step: step_result.step_id, status: step_result.status, thought: step_result.thought, action: f{step_result.tool_used if step_result.tool_used else finalize}, error: step_result.error } print(f[日志] {json.dumps(log_entry, ensure_asciiFalse)}) if step_result.tool_output: print(f[工具输出] {step_result.tool_output}) if context.status completed: print(f\n 任务成功完成最终结果{context.accumulated_results.get(final_answer, N/A)} ) break elif context.status failed or step_result.status failure: print(f\n 任务失败于步骤 {step_result.step_id}。错误{step_result.error} ) break elif i max_steps - 1: print(f\n 任务达到最大步数限制可能陷入循环。 ) # 4. 最终输出完整上下文用于调试和分析 print(f\n 任务上下文详情用于调试) print(json.dumps(context.dict(), indent2, ensure_asciiFalse)) if __name__ __main__: main()运行这段代码你会看到一个简单的 Agent 如何逐步规划、执行、记录状态。虽然 LLM 是模拟的但它完整展示了 Harness Engineering 的核心思想控制流、可靠性包装、状态管理、结构化日志。当我们将模拟 LLM 替换为真实的 OpenAI API并增加更多工具和复杂逻辑时这个基础架构依然稳固。4. 进阶实践从原型到生产的 Harness 增强策略上面的简易示例勾勒了轮廓但要应用于生产还需要在以下几个方向进行深度增强4.1 实现真正的持久化状态与工作流引擎内存中的TaskContext在服务重启后会丢失。生产环境需要将状态持久化到数据库如 PostgreSQL、Redis。更进一步的你需要一个工作流引擎来管理复杂的、可能长期运行Long-running的任务。状态持久化将TaskContext序列化后存入数据库。每次执行步骤前加载执行后保存。这带来了事务一致性的挑战。异步与队列Agent 任务可能耗时很长分钟级。应该采用异步任务队列如 Celery、RabbitMQ、Redis Queue。用户请求到来时立即返回一个任务 ID任务本身被放入队列后台执行。用户可以通过任务 ID 轮询状态或通过 WebSocket 接收结果。工作流定义对于流程固定的任务可以使用像Prefect或Airflow这样的工作流编排工具来定义 DAG。每个节点可以是一个 LLM 调用、工具调用或条件判断。这些引擎天然提供了重试、超时、依赖管理和状态持久化。4.2 构建全面的可观测性系统打印日志到控制台远远不够。你需要一个集成的可观测性栈。集中式日志将结构化日志发送到ELK Stack或Loki。确保每条日志都包含task_id、step_id、timestamp、level等字段便于通过task_id聚合查看整个任务链路。分布式追踪集成OpenTelemetry。为每个入站请求生成一个 Trace在每次 LLM 调用、工具调用、数据库查询时创建 Span 并注入 Trace 上下文。这样可以在 Jaeger 或 Tempo 中可视化整个调用链的耗时和关系。指标收集与告警使用Prometheus客户端库在代码中埋点记录agent_tasks_total任务总数、agent_tasks_duration_seconds任务耗时直方图、llm_calls_total、llm_tokens_used、tool_call_errors_total。在 Grafana 中制作仪表盘并设置告警规则如最近5分钟任务失败率 5%。4.3 设计高效的提示词管理与版本控制提示词是 Agent 的“源代码”。需要像管理代码一样管理它。模板化与变量注入使用 Jinja2 等模板引擎管理提示词。将系统指令、少样本示例Few-shot Examples、工具描述、用户输入等部分模板化运行时动态注入变量如当前日期、用户历史、上一步结果。版本存储将提示词模板存储在数据库或版本控制系统如 Git中。每个模板都有唯一版本号。Agent 配置中引用特定版本的提示词。实验与评估搭建一个简单的 A/B 测试框架。可以同时部署使用prompt_v1和prompt_v2的 Agent将少量流量导向不同版本并对比关键指标任务成功率、用户满意度调查、平均完成步数。这需要将提示词版本信息也记录在日志和追踪中。4.4 实施严格的护栏与安全策略这是确保 Agent 行为符合预期的防火墙。输入/输出验证在 Agent 处理用户输入和返回最终输出前增加校验层。输入净化检查用户输入是否包含恶意代码、敏感信息或攻击性语言。输出格式强制使用Pydantic或JSON Schema严格定义 LLM 响应的格式。如果 LLM 返回的 JSON 不合法可以尝试用一个小型“修复模型”进行修正或直接让 LLM 重试。内容安全扫描集成内容安全 API如 OpenAI 的 Moderation API或本地模型对生成的文本进行二次扫描过滤违规内容。工具调用权限控制不是所有 Agent 都能调用所有工具。根据用户身份、会话上下文或任务类型实施动态的工具权限白名单。例如一个“只读信息查询”Agent 不应该有“发送邮件”或“数据库写入”工具的权限。预算与速率限制为每个用户或每个会话设置 token 消耗预算和每分钟/每天的请求速率限制。在上下文管理器中实时计算消耗超出预算则优雅地终止任务并提示用户。5. 常见陷阱与效能优化实战指南在实际开发和运维中你会遇到许多框架文档里不会写的“坑”。以下是一些高频问题的实录与解决方案。5.1 陷阱一上下文爆炸与 Token 成本失控问题Agent 在长对话或多步骤任务中历史消息越来越长导致每次调用 LLM 的 token 数激增响应变慢成本飙升。解决方案智能摘要不要简单地将所有历史对话都塞进上下文。在每轮交互或每 N 步之后用一个单独的、成本较低的 LLM 调用如 gpt-3.5-turbo对之前的对话历史进行摘要保留关键决策、事实和用户意图丢弃无关细节。用这个摘要替代原始长历史。向量检索记忆将历史交互中的重要信息如用户偏好、已确认的事实、决策结果转换成向量存入向量数据库如 Pinecone、Weaviate。当需要相关信息时通过检索RAG只召回最相关的几条记忆而不是全部历史。这模拟了人类的“选择性记忆”。分层上下文窗口设计“工作记忆”和“长期记忆”。工作记忆是当前步骤直接相关的少量上下文如最近3轮对话当前工具结果。长期记忆是向量检索库。只在必要时从长期记忆中提取信息到工作记忆。设置硬性截断规则设定一个最大 token 限制。当上下文长度接近限制时优先移除最早的历史消息FIFO或移除优先级较低的系统指令片段。5.2 陷阱二LLM 的“幻觉”导致工具调用参数错误问题LLM 理解了要调用get_weather工具但却生成了{city_name: 北京}这样的参数而工具期望的是{city: 北京}。参数名不匹配导致调用失败。解决方案模式强制Schema Enforcement在提示词中不仅描述工具更要用严格的 JSON Schema 或 TypeScript 定义来声明工具的参数。例如“工具get_weather的参数必须是一个对象包含一个名为city的字符串属性。” 许多框架如 LangChain已经支持基于 Pydantic 模型自动生成此类描述。参数验证与后处理在工具调用前对 LLM 生成的参数进行验证。如果发现city_name可以尝试通过一个简单的映射规则或一个小型文本处理函数将其修正为city。这比让 LLM 重试一次成本更低。少样本示例Few-shot在系统提示词中提供 1-2 个完美的工具调用示例展示正确的参数格式。LLM 的模仿能力很强。使用函数调用Function Calling特性如果使用的 LLM API如 OpenAI GPT-4支持函数调用强烈建议使用。它允许你直接以 JSON Schema 的形式定义工具模型会输出一个结构化的函数调用请求参数格式的准确性大大提高。5.3 陷阱三复杂任务中的无限循环或“思维漩涡”问题Agent 在一个步骤上反复尝试失败或者在不同步骤间来回跳转无法达成最终目标陷入死循环。解决方案最大步数限制这是最基本的防护。在任务上下文或控制循环中设置一个硬性上限如 50 步达到后强制终止任务并标记为“超时”。状态检测与干预维护一个“已访问状态”的集合。如果发现 Agent 在多个步骤后回到了一个高度相似的状态例如工具调用参数相同或思考过程重复可以触发干预。干预方式可以是a) 注入一条系统消息强制其改变策略b) 切换到另一个“反思”子智能体来分析僵局原因c) 直接终止并请求人工接管。子目标明确化与验证在规划阶段不仅让 LLM 输出下一步动作也要求它输出当前子目标和对完成度的估计。如果连续几步子目标没有进展则触发反思。引入“人工审批”节点对于关键决策点或高风险操作如发送邮件、支付在设计工作流时主动插入“等待人工确认”的节点避免 Agent 在无人监督的情况下做出不可逆的操作。5.4 效能优化降低延迟与成本策略并行化工具调用如果多个工具调用之间没有依赖关系绝对不要串行执行。使用asyncio或线程池并发执行可以大幅减少总体耗时。缓存层为 LLM 调用和工具调用添加缓存。对于相同的输入提示词、参数直接返回缓存的结果。注意缓存的失效策略对于时效性强的数据如天气、股价设置较短的 TTL。模型分级使用不要所有任务都用最强大、最贵的模型如 GPT-4。将任务分类简单的分类、提取用gpt-3.5-turbo需要深度推理、规划、创作性的任务再用GPT-4。甚至可以使用本地的小模型如通过 Ollama 部署的 Llama 3来处理一些模式固定的任务。流式响应对于需要与用户长时间交互的 Agent如聊天机器人优先使用 LLM API 的流式响应Streaming。一边生成一边返回给前端可以极大提升用户体验上的“响应速度”。构建一个成熟、可靠的 AI Agent 系统其工程复杂度不亚于一个微服务架构。Harness Engineering 正是将软件工程中久经考验的原则——模块化、可观测性、弹性设计、持续集成——应用到了这个充满不确定性的新领域。它让你从疲于应付 Agent 的“不可靠”中解放出来专注于设计真正创造价值的智能逻辑。这条路没有银弹但有了这套“缰绳”你至少能确保这匹 AI 骏马是朝着正确的方向稳健地奔跑。