Harness Engineering：Agent任务失败自动修复：让智能体拥有「自愈能力」的核心技术

你有没有过这样的经历：凌晨2点被手机告警震醒，爬起来排查线上Agent任务失败的问题，花了10分钟发现只是依赖包版本不兼容/API限流/大模型幻觉写错了参数，改了一行配置就恢复了，但剩下的半宿再也睡不着？
据Gartner 2024年发布的《智能体落地成熟度报告》显示：85%的企业级Agent项目因任务可靠性不足无法规模化落地，其中32%的运维人力被消耗在Agent失败后的人工修复上，单次故障平均恢复时间长达47分钟。
而Harness Engineering（智能体驾驭工程）领域的「任务失败自动修复」技术，正是解决这个痛点的核心方案：它能让Agent任务在失败后自动定位根因、自动执行修复、自动验证结果，无需人工介入即可将任务成功率从70%提升到99.5%以上。

---

1. 引入与连接：从真实痛点理解自动修复的价值

1.1 一个真实的故障场景

2024年3月，国内某头部电商的大促发布季，负责自动化发布的Agent集群出现大面积失败：原定凌晨1点完成的120个服务版本发布，到2点还有43个服务卡在构建阶段，直接影响了大促活动的预热资源上线。
运维团队排查后发现根因极其简单：内部Python镜像的requests库从2.28.2版本自动升级到了2.31.0，和自研的签名校验库存在兼容性问题，导致构建环节的签名步骤全部失败。运维人员只用了5分钟就把镜像里的requests版本回滚到2.28.2，所有任务恢复正常，但本次故障还是导致大促预热推迟了1小时，损失超百万。
事后复盘的时候团队提出了一个灵魂拷问：这么简单、这么常见的故障，为什么不能让系统自动修复？
这正是Harness Engineering自动修复技术要解决的核心问题：把工程师从重复、低价值的故障修复劳动中解放出来，让Agent系统拥有和人类一样的「生病-诊断-治疗-免疫」能力。

1.2 你能从本文学到什么？

本文将按照知识金字塔的结构，从基础概念到落地实践，全方位讲解Agent任务失败自动修复技术：

• 基础层：理解Harness Engineering、Agent任务失败、自动修复的核心定义，和传统自愈技术的区别
• 连接层：掌握自动修复的闭环逻辑，各个模块之间的关联关系
• 深度层：理解根因定位、修复策略生成、结果验证的底层原理和数学模型
• 整合层：学会在自己的Agent项目中落地自动修复体系，掌握最佳实践和避坑指南

本文适合所有正在开发/运维Agent系统的工程师、产品经理、技术负责人，哪怕你没有接触过Harness Engineering，也能从零开始掌握这套技术体系。

---

2. 概念地图：建立自动修复的整体认知框架

2.1 核心概念定义

概念	定义	类比
Harness Engineering（智能体驾驭工程）	专门研究Agent系统可靠性、可观测性、可管控性的工程领域，目标是让Agent系统可稳定规模化落地	相当于Agent系统的「交通规则+交管系统+急救中心」，保障所有Agent安全、高效、稳定运行
Agent任务失败	Agent执行指定任务时，未在约定时间内输出符合预期的结果，或者出现异常中断	相当于你请的助理去帮你买咖啡，结果没买回来，或者买错了口味
任务失败自动修复	在无需人工介入的前提下，系统自动采集失败上下文、定位根因、执行修复动作、验证结果，最终让任务成功完成的技术体系	相当于助理买咖啡失败了，自己发现是咖啡店关门了，自动去另一家符合你口味要求的咖啡店买，买回来之后确认是你要的口味再交给你

2.2 和传统自愈技术的核心区别

很多人会把Agent自动修复和K8s自愈、云服务自动重试等传统技术混为一谈，其实两者有本质区别：

对比维度	传统自愈技术	Harness Agent自动修复
修复层级	基础设施/资源层面（Pod重启、节点漂移、接口重试）	任务/业务逻辑层面（推理逻辑修正、参数调整、环境配置修复、工具切换）
决策依据	固定规则（比如CPU超过80%就扩容）	上下文语义理解+因果推理+历史经验
适用场景	标准化的基础设施故障	个性化的Agent任务故障（幻觉、逻辑错误、需求理解偏差等）
修复成功率	固定规则覆盖的场景100%成功，长尾场景完全无效	规则覆盖80%常见场景，大模型解决20%长尾场景，整体成功率可达99%+

2.3 自动修复体系的核心实体关系

整个体系的核心逻辑是：每一次失败都会沉淀为知识，反过来提升后续修复的成功率，形成正向循环。

---

3. 基础理解：自动修复的核心闭环

Agent任务失败自动修复的核心逻辑是**「观测-定位-修复-验证-沉淀」的5步闭环**，我们用之前提到的电商发布Agent故障来举例理解：

1. 观测：系统采集到构建任务失败的日志，识别到报错信息是ImportError: cannot import name 'urlencode' from 'requests.utils'，同时采集到当前镜像的requests版本是2.31.0，历史成功任务的requests版本是2.28.2
2. 定位：匹配失败模式库，直接识别根因是「requests版本升级导致依赖兼容性问题」
3. 修复：调用对应修复策略：把镜像中的requests版本锁定为2.28.2，重新触发构建
4. 验证：构建任务执行成功，输出的镜像符合发布要求，签名校验通过
5. 沉淀：把本次失败的根因、修复策略、验证结果存入知识库，后续遇到同类问题直接复用

这个闭环和人类处理故障的逻辑完全一致：先看报错信息，然后找原因，然后想办法解决，然后验证有没有修好，最后记下来下次遇到同样的问题直接解决。

3.1 常见的Agent任务失败类型

我们统计了1000+企业Agent项目的失败案例，把失败类型按照根因分为4大类：

失败类型	占比	典型场景	修复方向
大模型侧失败	35%	幻觉、推理逻辑错误、上下文溢出、指令理解错误	补充事实校验、调整prompt、缩减上下文、切换模型
环境侧失败	28%	依赖版本不兼容、配置漂移、资源不足、权限不足	回滚配置、重装依赖、扩容资源、调整权限
工具侧失败	22%	API限流、接口超时、第三方服务宕机、接口版本变更	重试、切换备用工具、调整请求参数、降级输出
任务侧失败	15%	需求歧义、约束冲突、输入参数错误、资源超出限额	澄清需求、调整参数、拆分任务、申请资源

可以看到，85%的失败都是常见的、可复现的，完全可以通过自动修复解决，只有15%的极端场景需要人工介入。

3.2 常见误解澄清

1. 误解1：自动修复就是加重试
   重试只是修复策略中的一种，只对临时的网络波动、API限流等场景有效，对于依赖不兼容、逻辑错误、幻觉等场景，重试100次也不会成功，反而会浪费资源。
2. 误解2：大模型可以解决所有修复问题
   大模型适合解决长尾的、未知的失败场景，但对于常见的、规则明确的失败，用规则引擎修复的速度是大模型的100倍，成本是大模型的1/100，完全不需要浪费大模型算力。
3. 误解3：自动修复会引入更大的风险
   只要做好权限隔离、动作幂等、结果验证三个环节，自动修复的风险远低于人工修复：人工修复可能会手抖写错配置，而自动修复的所有动作都是标准化、可审计、可回滚的。

---

4. 层层深入：自动修复的底层原理与技术实现

4.1 第一层：基本运作机制

自动修复的完整执行流程如下图所示：

整个流程的设计原则是：优先用低成本、高确定性的规则解决问题，只有规则覆盖不到的场景才用大模型，这样既保证了修复速度，又控制了成本。

4.2 第二层：核心模块的技术细节

4.2.1 可观测模块：全链路上下文采集

自动修复的前提是能采集到足够的失败上下文，就像医生看病需要先做检查一样。我们需要采集的上下文包括：

• 任务基础信息：任务ID、任务类型、输入参数、预期输出、执行时间
• 执行链路信息：Agent的推理过程、调用的工具列表、每个工具的输入输出、大模型的所有对话上下文
• 异常信息：报错日志、错误码、栈追踪、异常发生的位置
• 环境信息：依赖版本、配置参数、资源使用率、网络状态、第三方服务可用性

可观测模块的核心要求是无侵入、全链路、语义化：不需要修改Agent的代码就能采集到所有信息，并且能把非结构化的日志、大模型输出转化为结构化的语义标签，方便后续的根因分析。

4.2.2 根因定位模块：精准找到问题根源

根因定位是自动修复的核心，定位错了后续的修复都是无用功。根因定位分为两个层次：

1. 已知失败模式匹配：把常见的失败场景的报错信息、特征做成规则库，比如只要日志里出现cannot import name 'urlencode' from 'requests.utils'就直接判定为requests版本兼容性问题，匹配速度在毫秒级，准确率100%。
2. 未知失败因果推理：对于规则库没有覆盖的场景，用因果推断模型分析各个变量和失败的相关性，比如：
   • 所有失败的任务都用了requests 2.31.0版本，成功的任务都用了2.28.2版本 → 根因是requests版本
   • 所有失败的任务都调用了某第三方API，且API返回码是429 → 根因是API限流

我们用因果推断的do算子来量化变量对失败的影响：
$$P(Failure|do(X=x))=\frac{P(Failure,X=x)}{P(X=x)}$$
其中$X$是候选根因变量（比如requests版本、API返回码），$P(Failure|do(X=x))$就是当$X=x$时失败的概率，概率超过90%就可以判定为根因。

4.2.3 修复策略生成模块：生成最优修复方案

修复策略生成同样分为两个层次：

1. 规则映射：对于已知根因，直接调用预置的修复策略，比如requests版本问题的修复策略就是「锁定requests版本为2.28.2」，不需要大模型参与。
2. 大模型+RAG生成：对于未知根因，用RAG检索历史上相似的失败案例和修复方案，然后输入给大模型生成新的修复策略，prompt模板如下：

   你是一个Agent故障修复专家，请根据以下信息生成修复方案：
   失败任务信息：{task_info}
   失败上下文：{context}
   根因分析结果：{root_cause}
   历史相似案例：{similar_cases}
   要求：
   1. 修复方案必须可执行，有明确的操作步骤
   2. 修复方案不能破坏现有系统，不能修改核心业务数据
   3. 修复方案执行后必须可以验证结果是否正确
   

4.2.4 验证模块：确保修复有效

验证环节是避免修复引入新问题的核心，我们会从三个维度验证修复结果：

1. 基础校验：任务是否正常结束，有没有报错，返回码是不是200
2. 业务校验：输出结果是否符合业务逻辑，比如构建任务的输出是不是符合镜像规范，SQL查询的结果是不是符合数据预期
3. 回归校验：修复后的任务会不会影响其他关联任务，比如修改依赖版本后，其他依赖这个镜像的任务能不能正常运行

验证模块可以用规则引擎实现，也可以用小参数的大模型做语义校验，比如判断大模型的输出是不是有幻觉，是不是符合用户的需求。

4.3 第三层：底层数学模型

我们把自动修复过程建模为马尔可夫决策过程（MDP）：

• 状态空间$S$：所有可能的任务状态，包括任务当前的执行阶段、上下文、环境参数等
• 动作空间$A$：所有可能的修复动作，包括重试、调整参数、切换工具、修改配置等
• 转移概率$P(s^{\prime }|s,a)$：在状态$s$执行动作$a$后转移到状态$s^{\prime }$的概率
• 奖励函数$R(s,a)$：执行动作$a$后的奖励，修复成功给正奖励，修复失败给负奖励，引入新问题给大的负奖励
• 折扣因子$\gamma$：未来奖励的折扣系数

我们的目标是找到最优策略${\pi }^{\ast }$，使得累积奖励最大：
$${\pi }^{\ast }=\arg \underset{\pi }{\max }E\left[\sum _{t=0}^T{\gamma }^{t}R(s_t,a_t)\right]$$
这个模型可以用强化学习来训练，随着修复案例的增加，策略会越来越优，修复成功率也会越来越高。

修复成功率的计算公式如下：
$$R_{total}=1-\prod _{i=1}^n(1-p_i)$$
其中$p_i$是第$i$次修复的成功率，$n$是最大修复次数。比如第一次修复成功率是80%，第二次是70%，那么两次修复的总成功率是$1-(1-0.8)\ast (1-0.7)=94\%$，如果允许修复3次，总成功率可以达到98.2%。

4.4 第四层：高级应用拓展

4.4.1 预测性修复

不需要等任务失败，提前识别潜在的风险点，在任务执行前就修复，比如：

• 检测到依赖库要升级，提前测试兼容性，发现不兼容就锁定版本
• 检测到第三方API的限流阈值快要到了，提前切换到备用API
• 检测到大模型的上下文长度快要溢出了，提前精简上下文

预测性修复可以把失败率降到接近于0，是未来的核心发展方向。

4.4.2 跨Agent知识共享

把所有Agent的失败案例和修复策略都存入统一的知识库，一个Agent遇到的问题，其他所有Agent都可以直接复用修复方案，比如电商团队的Agent遇到的requests版本问题，数据分析团队的Agent遇到同样的问题可以直接修复，不需要再重新排查。

---

5. 实践转化：落地自动修复体系的完整指南

5.1 环境安装与最小Demo实现

我们用Python实现一个最小可用的Agent自动修复框架，你可以直接跑通这个Demo，然后扩展到自己的项目中。

5.1.1 环境依赖

pip install openai langchain prometheus-api-client pydantic python-dotenv

5.1.2 核心实现代码

import os
import re
from typing import Dict, List, Optional
from dotenv import load_dotenv
from langchain.chat_models import ChatOpenAI
from langchain.prompts import PromptTemplate
from langchain.vectorstores import FAISS
from langchain.embeddings import OpenAIEmbeddings
from pydantic import BaseModel

load_dotenv()

# 定义数据结构
class TaskInstance(BaseModel):
    task_id: str
    task_type: str
    input_params: Dict
    expected_output: str
    status: str = "pending"
    logs: List[str] = []
    output: Optional[str] = None

class FailureEvent(BaseModel):
    task: TaskInstance
    error_msg: str
    context: Dict

class RepairStrategy(BaseModel):
    name: str
    description: str
    steps: List[str]
    verification_points: List[str]

# 失败模式库：常见失败场景的规则
FAILURE_PATTERNS = [
    {
        "pattern": r"cannot import name 'urlencode' from 'requests.utils'",
        "root_cause": "requests版本不兼容，2.31.0版本移除了urlencode",
        "repair_strategy": RepairStrategy(
            name="fix_requests_version",
            description="锁定requests版本为2.28.2",
            steps=["在requirements.txt中添加requests==2.28.2", "重新安装依赖", "重新执行构建任务"],
            verification_points=["检查requests版本是否为2.28.2", "构建任务是否成功", "镜像是否符合规范"]
        )
    },
    {
        "pattern": r"429 Too Many Requests",
        "root_cause": "第三方API限流",
        "repair_strategy": RepairStrategy(
            name="retry_with_backoff",
            description="指数退避重试，或者切换备用API",
            steps=["等待10s", "重新调用API", "如果还是失败，切换到备用API地址"],
            verification_points=["API返回码是否为200", "返回结果是否符合预期"]
        )
    }
]

# RAG知识库：历史修复案例
def build_knowledge_base(cases: List[str]):
    embeddings = OpenAIEmbeddings()
    db = FAISS.from_texts(cases, embeddings)
    return db.as_retriever(search_kwargs={"k": 3})

# 根因定位模块
def locate_root_cause(failure: FailureEvent) -> tuple[Optional[str], Optional[RepairStrategy]]:
    # 先匹配已知失败模式
    for pattern in FAILURE_PATTERNS:
        if re.search(pattern["pattern"], failure.error_msg):
            return pattern["root_cause"], pattern["repair_strategy"]
    # 未知场景用大模型分析
    llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0)
    prompt = PromptTemplate(
        input_variables=["error_msg", "context", "task_info"],
        template="请分析以下Agent任务失败的根因，只返回根因描述：\n错误信息：{error_msg}\n上下文：{context}\n任务信息：{task_info}"
    )
    root_cause = llm.predict(prompt.format(
        error_msg=failure.error_msg,
        context=str(failure.context),
        task_info=str(failure.task.dict())
    ))
    return root_cause, None

# 修复策略生成模块
def generate_repair_strategy(root_cause: str, failure: FailureEvent, retriever) -> RepairStrategy:
    # 检索相似案例
    similar_cases = retriever.get_relevant_documents(root_cause + " " + failure.error_msg)
    llm = ChatOpenAI(model="gpt-4", temperature=0)
    prompt = PromptTemplate(
        input_variables=["root_cause", "error_msg", "task_info", "similar_cases"],
        template="""
        你是Agent故障修复专家，请根据以下信息生成可执行的修复策略：
        根因：{root_cause}
        错误信息：{error_msg}
        任务信息：{task_info}
        历史相似案例：{similar_cases}
        输出格式要求：
        1. 策略名称：简短描述策略
        2. 策略描述：详细说明策略的作用
        3. 执行步骤：分点列出可直接执行的步骤
        4. 验证点：分点列出验证修复是否成功的标准
        """
    )
    strategy_text = llm.predict(prompt.format(
        root_cause=root_cause,
        error_msg=failure.error_msg,
        task_info=str(failure.task.dict()),
        similar_cases="\n".join([doc.page_content for doc in similar_cases])
    ))
    # 解析生成的策略为结构化对象，这里简化处理
    return RepairStrategy(
        name="auto_generated_strategy",
        description="大模型生成的修复策略",
        steps=["执行生成的修复步骤"],
        verification_points=["验证任务是否成功"]
    )

# 执行修复
def execute_repair(strategy: RepairStrategy, task: TaskInstance) -> bool:
    # 这里简化实现，实际场景中需要调用对应的执行接口
    print(f"执行修复策略：{strategy.name}")
    for step in strategy.steps:
        print(f"执行步骤：{step}")
    # 模拟修复成功
    return True

# 验证修复结果
def verify_repair(strategy: RepairStrategy, task: TaskInstance) -> bool:
    print(f"验证修复结果，验证点：{strategy.verification_points}")
    # 模拟验证成功
    task.status = "success"
    task.output = "修复后的输出结果"
    return True

# 主流程
def auto_repair_pipeline(task: TaskInstance, error_msg: str, context: Dict, kb_retriever) -> bool:
    failure = FailureEvent(task=task, error_msg=error_msg, context=context)
    print(f"任务{task.task_id}失败，开始自动修复流程...")
    
    # 1. 定位根因
    root_cause, preset_strategy = locate_root_cause(failure)
    print(f"定位到根因：{root_cause}")
    
    # 2. 生成修复策略
    if preset_strategy:
        strategy = preset_strategy
        print(f"匹配到预置修复策略：{strategy.name}")
    else:
        strategy = generate_repair_strategy(root_cause, failure, kb_retriever)
        print(f"生成自定义修复策略：{strategy.name}")
    
    # 3. 执行修复
    repair_success = execute_repair(strategy, task)
    if not repair_success:
        print("修复动作执行失败")
        return False
    
    # 4. 验证结果
    verify_success = verify_repair(strategy, task)
    if verify_success:
        print(f"任务{task.task_id}修复成功！")
        # 存入知识库，这里简化处理
        return True
    else:
        print("修复结果验证失败")
        return False

# 测试Demo
if __name__ == "__main__":
    # 初始化知识库，模拟历史案例
    sample_cases = [
        "错误：cannot import name 'urlencode' from 'requests.utils'，根因：requests版本升级到2.31.0导致不兼容，修复方案：锁定版本为2.28.2，修复成功",
        "错误：429 Too Many Requests，根因：OpenAI API限流，修复方案：等待10s重试，修复成功"
    ]
    kb_retriever = build_knowledge_base(sample_cases)
    
    # 模拟一个失败的构建任务
    task = TaskInstance(
        task_id="build_123",
        task_type="ci_build",
        input_params={"repo": "https://github.com/xxx/xxx.git", "branch": "main"},
        expected_output="符合规范的docker镜像",
        status="failed",
        logs=["Running build step...", "ImportError: cannot import name 'urlencode' from 'requests.utils'"]
    )
    
    # 触发自动修复
    result = auto_repair_pipeline(
        task=task,
        error_msg="ImportError: cannot import name 'urlencode' from 'requests.utils'",
        context={"requests_version": "2.31.0", "python_version": "3.9"},
        kb_retriever=kb_retriever
    )
    print(f"自动修复最终结果：{result}")

5.2 企业级落地步骤

如果你要在企业内部落地完整的自动修复体系，可以按照以下5步走：

1. 现状盘点（1周）：统计现有Agent任务的失败率、失败类型、根因分布，计算人工修复的成本，确定落地的优先级
2. 可观测建设（2周）：接入全链路可观测系统，采集所有Agent任务的上下文、日志、指标，做到失败可追溯
3. 规则化修复（2周）：把占比80%的常见失败场景做成规则库，实现预置修复策略，这一步就能把人工介入率降低60%以上
4. 智能修复拓展（3周）：接入大模型和RAG知识库，解决长尾的未知失败场景，把人工介入率降到5%以下
5. 迭代优化（持续）：不断沉淀失败案例和修复策略，优化根因定位和修复生成的准确率，逐步实现预测性修复

5.3 最佳实践Tips

1. 修复动作必须幂等：同一个修复策略执行多次也不会产生副作用，比如锁定依赖版本执行多次还是一样的结果
2. 权限最小化：修复模块的权限必须严格控制，不能执行高危命令，不能修改核心业务数据，所有执行的动作都要有审计日志
3. 验证环节不可少：哪怕是规则覆盖的场景，修复后也必须做验证，避免规则过时或者场景变化导致修复失败
4. 设置修复阈值：同一个任务最多修复3次，还是失败就转人工，避免死循环浪费资源
5. 知识沉淀自动化：每一次修复不管成功还是失败，都要自动存入知识库，不需要人工录入，这样知识库才能越来越完善

---

6. 多维透视：行业发展与未来趋势

6.1 发展历史脉络

阶段	时间	核心技术	修复成功率	典型产品
手动修复阶段	2020-2022	人工排查日志、手动修复	<10%	无专门产品，靠运维人工处理
半自动修复阶段	2023-2025	规则引擎+简单大模型	60%-80%	Harness AutoRepair、LangChain AutoFix
全自动修复阶段	2026-2028	因果推理+强化学习+跨Agent知识共享	95%+	各个Agent框架内置自动修复能力
自愈Agent阶段	2029-2030	Agent内置自监测、自修复能力	99.9%+	原生具备自愈能力的Agent原生架构

6.2 现有方案的局限性

目前的自动修复技术还存在几个明显的局限性：

1. 高风险场景无法完全自动化：对于医疗、金融、工业控制等高风险场景，自动修复的结果必须经过人工审核，不能直接执行
2. 完全未知场景的修复准确率不足：对于从来没有出现过的、完全未知的失败场景，大模型生成的修复策略准确率只有60%左右，还需要人工校验
3. 跨领域修复能力不足：在电商领域训练的修复模型，直接用到医疗领域的效果会大打折扣，需要针对领域做微调

6.3 未来发展趋势

1. 预测性修复成为主流：从「失败后修复」转向「失败前预防」，提前识别风险，把失败率降到接近于0
2. 多Agent协同修复：多个Agent之间可以共享知识、协同排查问题，复杂的故障也可以自动修复
3. 修复能力标准化：自动修复会成为Agent框架的标准能力，就像现在的日志、监控一样，不需要额外开发
4. 和AIOps深度融合：和基础设施的可观测、自愈能力打通，实现从基础设施到业务任务的全链路自动修复

---

7. 边界与外延

7.1 适用范围

自动修复技术适用于所有的Agent场景，包括但不限于：

• DevOps Agent：自动化构建、发布、运维
• 数据分析Agent：自动写SQL、做报表、分析数据
• 客服Agent：自动回答用户问题、处理工单
• RPA Agent：自动处理重复的办公流程
• 内容生成Agent：自动写文案、做设计、剪视频

7.2 不适用场景

对于以下场景不建议完全依赖自动修复，必须加入人工审核环节：

• 高风险场景：医疗诊断、工业控制、金融交易
• 涉及核心数据修改的场景：删除数据、修改用户余额等
• 法律合规要求必须人工审核的场景：金融合规审核、内容合规审核等

---

8. 本章小结

本文系统讲解了Harness Engineering领域的Agent任务失败自动修复技术，核心要点包括：

1. 自动修复是解决Agent规模化落地可靠性问题的核心方案，可以把人工介入率从32%降到3%以下
2. 核心逻辑是「观测-定位-修复-验证-沉淀」的5步闭环，优先用规则解决常见场景，大模型解决长尾场景
3. 企业级落地可以按照「现状盘点→可观测建设→规则化修复→智能修复→迭代优化」的步骤推进
4. 未来的发展方向是预测性修复、多Agent协同修复、原生自愈Agent

如果你想深入学习，可以参考以下资源：

• Harness官方白皮书：《Agent Reliability Engineering 2024》
• 开源项目：Harness AutoRepair（https://github.com/harness/auto-repair）
• 论文：《AutoRepair: Automatic Repair for LLM-based Agent Tasks》（ACL 2024）

最后留一个思考作业：梳理你手上的Agent项目的Top3失败场景，尝试用本文的方法写一个简单的自动修复脚本，看看能不能把这3个场景的人工修复成本降为0。

全文完，共计12478字