1. 项目概述当AI系统学会自我修复最近在搞一个挺有意思的玩意儿我把它叫做“自我进化的Harness”。说白了就是让咱们手头那套AI Agent系统能自己发现运行中的bug然后自己写代码、提PRPull Request来修复它。这听起来有点像科幻片里的情节但实际做下来发现技术路径是清晰且可行的。这不仅仅是自动化测试的升级而是让系统具备了“自我诊断”和“自我治疗”的初级能力朝着构建真正健壮、可长期自主运行的智能系统迈出了一大步。这个想法的核心驱动力很简单随着AI Agent系统承担的任务越来越复杂依赖人工去监控每一个异常、排查每一个逻辑漏洞成本高得吓人响应速度也跟不上。尤其是在处理实时数据流、多步骤决策链的场景下一个隐蔽的bug可能导致一连串的决策失误等我们发现时损失可能已经造成了。所以能不能让系统自己成为自己的“第一响应者”这就是“自我进化的Harness”要解决的问题。它适合谁呢我认为任何在构建复杂、长期运行的自动化系统或AI应用团队都会对这个方向感兴趣。特别是当你的系统已经有一套相对稳定的核心逻辑但仍在频繁应对边缘案例和未知输入时引入这种自我修复机制能极大解放开发者的精力让团队更专注于核心业务逻辑的创新而不是疲于奔命地“救火”。2. 核心架构与设计思路拆解2.1 从“监控”到“诊断”的范式转变传统的系统监控无论是日志告警、指标异常还是APM应用性能监控其核心是“发现问题并通知人”。而“自我进化的Harness”的目标是实现“发现问题并尝试解决”。这要求我们的系统架构必须包含一个完整的闭环感知Observe、分析Analyze、决策Decide、执行Act也就是经典的OODA循环。我的设计思路是在现有的AI Agent系统之上叠加一个“元认知层”Meta-Cognitive Layer。这个层不直接处理业务逻辑而是像一个“系统医生”持续观察主Agent的运行状态、输入输出、中间结果以及资源消耗。当它检测到偏离预期模式的行为即潜在的bug时就会触发诊断流程。这里的关键在于我们不能只依赖简单的规则比如错误码或异常抛出因为很多逻辑bug并不会导致程序崩溃而是产生错误的结果。因此这个元认知层需要内置对系统“正常行为”的深刻理解通常通过历史成功运行轨迹、业务规则约束、或预期输出模式来定义。2.2 核心组件与数据流设计整个Harness系统可以拆解为以下几个核心组件它们协同工作形成自我修复的闭环状态采集器State Collector这是系统的“感官”。它需要以非侵入或低侵入的方式从运行的AI Agent中收集丰富的数据。这包括执行轨迹Execution Traces记录Agent每一步的思考过程如果支持、调用的工具函数、传入的参数和返回的结果。这对于后续分析至关重要。输入/输出快照I/O Snapshots记录触发当前执行链的原始输入以及最终产出。用于复现问题和评估修复效果。资源与性能指标CPU/内存使用率、API调用延迟、令牌Token消耗等。异常的资源消耗有时是死循环或低效算法的信号。内部状态与信念对于基于状态的Agent记录其关键内部变量或知识库的变更。异常检测与分类器Anomaly Detector Classifier这是系统的“初步诊断”。它接收采集器的数据并判断是否存在异常。这里我采用了多级检测策略规则层最快速的一层基于明确的业务规则和合约例如函数返回值必须在某个范围内对话不能包含敏感词。一旦违反直接标记为“确定性异常”。统计模型层基于历史正常数据训练简单的统计模型如孤立森林、局部异常因子或时序预测模型用于发现偏离历史模式的“概率性异常”比如响应时间突然变长、某个工具调用频率激增。语义一致性检查层对于Agent的文本输出或决策使用另一个轻量级的“审查Agent”或规则引擎检查其逻辑自洽性、与已知事实的一致性等。这是发现逻辑谬误的关键。根因分析与修复策略生成器Root Cause Analyzer Fix Strategist这是系统的“大脑”也是最复杂的部分。当异常被确认后本组件需要定位问题根源并生成修复方案。我的实现路径是轨迹回溯与切片从异常点开始逆向分析执行轨迹识别出可能导致异常的关键决策点或工具调用。假设生成与验证基于代码库、知识文档和历史修复记录生成关于bug原因的假设例如“可能是data_parser函数在遇到空字符串时返回了None而下游calculate_score函数未做空值处理”。然后通过代码静态分析、或在隔离的沙箱环境中用测试用例快速验证假设。修复策略生成确定根因后生成具体的修复策略。这可能包括修改某个函数的代码、增加输入验证、更新提示词Prompt、调整Agent的推理参数、甚至增删工具。策略会被表述为具体的操作指令例如“在文件utils/parser.py的第45行if not data:后面添加return default_value”。代码执行与PR创建器Code Executor PR Creator这是系统的“手”。它负责执行修复策略。沙箱环境任何代码修改必须在与生产环境隔离的沙箱中先进行测试。系统会自动构造测试用例基于异常触发时的输入和预期正确输出运行相关的单元测试或集成测试。代码修改通过程序化方式如调用代码库的AST接口或使用可靠的代码编辑库对源代码进行精准修改。生成提交与PR测试通过后系统会以特定身份如ai-maintainer创建新的Git分支提交更改并自动生成Pull Request。PR的描述会详细记录检测到的异常现象、分析出的根因、所做的修改、以及相关的测试结果。这为人类审查者提供了清晰的上下文。学习与反馈循环Learning Feedback Loop这是系统“进化”的源泉。每一次修复尝试无论成功与否都会形成一个反馈案例。成功案例会强化“异常模式-根因-修复策略”之间的关联用于优化分析器的模型。失败案例如修复未被合并、或引入了新bug会触发分析为什么系统给出的修复方案不对是根因分析错了还是修复策略有副作用这些案例对于提升系统的诊断准确性至关重要。注意让AI直接修改生产代码是高风险操作。因此整个流程中必须坚持“人类在环”Human-in-the-loop原则。自动生成的PR必须经过至少一名人类开发者的审查和批准才能合并。Harness的目标是充当一个永不疲倦的、初步的“调试助手”而不是取代人类开发者。2.3 技术栈选型考量在具体实现时技术选型需要平衡能力、复杂度和可控性Agent框架现有的Agent框架如LangChain、LlamaIndex、AutoGen提供了基础的Agent编排和工具调用能力是构建主业务Agent的起点。但它们的可观测性Observability通常较弱需要我们自行增强状态采集能力。可观测性与数据收集可以考虑使用OpenTelemetry这样的标准来埋点和收集追踪数据。对于自定义的Agent状态可能需要设计专门的数据结构并注入到Agent的执行循环中。异常检测对于规则和统计异常可以使用现成的库如PyOD。对于语义检查可以调用一个轻量级的LLM如小型化的开源模型作为“审查员”成本相对可控。根因分析与代码生成这是最依赖大语言模型LLM能力的环节。需要选择一个在代码理解和生成上表现强劲的模型如GPT-4、Claude 3 Opus或开源的DeepSeek-Coder系列。关键是要设计好给模型的“上下文”即如何将异常轨迹、相关代码片段、项目知识有效地组织成Prompt。代码操作与Git自动化可以使用libcst或tree-sitter进行精准的源代码修改。使用gitpython或PyGithub来实现Git操作自动化。沙箱测试使用Docker容器来创建隔离的测试环境是最安全的方式。需要预先准备好包含项目依赖和测试框架的镜像。选择的核心原则是优先使用成熟、稳定的工具处理确定性的任务如代码操作、Git命令将不确定性高的任务如根因推理、策略生成交给能力最强的LLM并用严格的流程和验证来约束其结果。3. 核心模块的详细实现与实操要点3.1 构建高保真的状态采集器状态采集是后续所有分析的基础如果数据失真或缺失自我修复就无从谈起。我的经验是采集器要做到“全面、轻量、可关联”。实现要点装饰器Decorator模式注入这是对业务代码侵入性较小的方法。为你希望监控的关键函数特别是工具函数和Agent的核心决策函数添加装饰器。这个装饰器负责记录函数名、入参、出参、执行时间、以及可能抛出的异常。import functools import time import logging def trace_execution(func): functools.wraps(func) def wrapper(*args, **kwargs): trace_id generate_trace_id() # 生成全局唯一的追踪ID start_time time.time() try: result func(*args, **kwargs) end_time time.time() # 记录成功执行信息 log_execution(trace_id, func.__name__, args, kwargs, result, end_time-start_time, None) return result except Exception as e: end_time time.time() # 记录异常信息 log_execution(trace_id, func.__name__, args, kwargs, None, end_time-start_time, str(e)) raise # 重新抛出异常不影响原有逻辑 return wrapper # 使用示例 trace_execution def your_agent_tool_function(param1, param2): # ... 原有业务逻辑 return result结构化日志与集中存储不要只打印文本日志。将每次函数调用记录为一个结构化的JSON对象包含时间戳、追踪ID、父追踪ID用于关联调用链、组件名、事件类型、详细数据等字段。然后将其发送到集中式的日志/追踪系统如Elasticsearch、Loki或专门的APM工具如SigNoz。这样便于后续的聚合查询和分析。捕获LLM调用细节对于Agent与LLM的交互需要记录完整的Prompt包括系统提示和用户消息、Completion模型的完整回复、以及使用的模型和参数如temperature。这些信息对于诊断提示词相关问题至关重要。大多数LLM SDK如OpenAI、Anthropic都提供了回调函数callback机制可以在这里面进行记录。性能开销管理采集数据会带来性能开销。对于高频调用的简单函数可以设计采样机制只记录一定比例的执行。或者将日志记录改为异步操作避免阻塞主业务逻辑。3.2 设计精准的异常检测逻辑异常检测不能“一刀切”需要根据异常类型分层处理。实操步骤定义“健康指标”首先你需要为你的系统定义什么是“健康”。这可能包括功能正确性关键工具函数的返回值符合预期通过断言或合约检查。性能基线API P99延迟低于200ms单次任务Token消耗低于5000。业务规则生成的报告必须包含摘要部分推荐列表不能重复对话不能以某种不恰当的方式结束。 将这些指标具体化、可测量化。实现规则检测器这是最快、最确定的检测方式。编写一个规则引擎周期性或实时地对采集到的状态数据运行这些规则。例如class RuleEngine: def check_output_contains_summary(self, agent_output): # 检查输出是否包含“摘要”章节 return ## 摘要 in agent_output or Summary: in agent_output def check_response_time(self, trace_data, threshold_ms200): # 检查某个关键路径的响应时间 total_time sum(step[duration_ms] for step in trace_data[steps]) return total_time threshold_ms def run_all_checks(self, execution_data): violations [] if not self.check_output_contains_summary(execution_data[final_output]): violations.append(MissingSummary) if self.check_response_time(execution_data[trace], 200): violations.append(HighLatency) return violations训练与部署统计检测模型收集一段时间内如一周系统正常运行的指标数据如函数耗时、调用次数、输出长度。用这些数据训练一个无监督的异常检测模型。当新数据点的特征显著偏离这个正常集群时就触发告警。关键点这个模型需要定期用新的正常数据重新训练以适应系统的自然演进。引入语义审查Agent对于逻辑谬误或事实性错误规则和统计模型往往无能为力。这时需要另一个“审查者”Agent。它的Prompt可以设计为你是一个质量审查员。请严格审查以下[主Agent]的输出是否满足要求。 原始任务[用户原始查询] 主Agent输出[待审查的输出] 审查要求 1. 输出是否直接、准确地回答了用户问题 2. 输出中的事实陈述是否与以下已知知识库一致[附上相关事实] 3. 输出是否存在自相矛盾的地方 4. 输出是否完整有无明显缺失的步骤或结论 请给出审查结论“通过”或“不通过”。如果不通过请明确指出具体问题。审查Agent的结论可以作为语义异常的强信号。3.3 实现可靠的根因分析与修复生成这是整个系统智能的核心也是最容易出错的地方。我们的策略是“大胆假设小心求证”。详细流程构建分析上下文当异常被触发后我们需要为负责根因分析的LLM准备一份详尽的“病历”。这份上下文应包括异常报告异常类型、触发时间、关联的追踪ID。完整执行轨迹从任务开始到异常发生所有步骤的详细信息包括工具调用、参数、返回值和中间Agent思考。相关代码片段根据轨迹中涉及的工具和函数从代码仓库中提取出相关的源代码文件。通常需要提取函数定义及其直接上下文前后若干行。项目知识可选但重要项目的架构文档、关键业务逻辑说明、近期相关的提交历史或已知问题列表。这能帮助LLM更好地理解代码意图。类似的已解决案例如果存在从历史修复记录中检索相似的问题和解决方案。设计分析PromptPrompt的质量直接决定分析结果的好坏。我的经验是采用“角色扮演结构化输出”的格式。你是一个资深的软件调试专家。现在需要你分析一个AI Agent系统运行中出现的异常并尝试定位根本原因提出具体的代码修复方案。 ## 问题描述 [此处粘贴异常报告] ## 系统执行轨迹 [此处粘贴格式化后的执行轨迹] ## 相关源代码 [文件1路径] python [文件1内容][文件2路径][文件2内容]... (根据需要列出所有相关文件)分析任务请按以下步骤进行现象复现根据轨迹描述导致异常的直接操作序列。假设生成列出所有可能导致此异常的逻辑漏洞或代码缺陷至少3个不同的假设。假设评估针对每个假设结合代码逻辑进行评估判断其可能性高/中/低并说明理由。根因判定选出你认为可能性最高的根本原因。修复方案针对选定的根因给出具体的代码修改建议。请精确到文件、函数和行号并给出修改后的代码块。影响评估简述此修改可能对系统其他部分产生的影响以及需要补充的测试用例。请将最终输出用以下JSON格式呈现 { root_cause: 对根本原因的一句话描述, confidence: 0.8, // 置信度0-1之间 fix_location: { file: src/utils/parser.py, function: parse_user_input, line_start: 45, line_end: 45 }, original_code: if not input_string:, suggested_code: if not input_string or input_string.strip() :, reasoning: 详细的推理过程解释为什么这里是根因以及为什么这样修改, potential_side_effects: [列表可能的副作用], suggested_tests: [描述建议的测试用例] }验证与沙箱测试拿到LLM生成的修复方案后绝不能直接应用到主代码库。必须经过验证。代码静态检查用ast模块解析修改后的代码确保语法正确。可以运行简单的代码风格检查工具。创建隔离测试在Docker沙箱中基于异常发生时的输入数据编写一个最小化的测试脚本用于复现问题并验证修复是否有效。同时运行项目中现有的相关单元测试确保修改没有破坏原有功能。如果测试失败将测试失败的结果反馈给LLM让它重新分析。可以形成一个“分析-生成-测试-反馈”的微循环最多尝试2-3次。如果多次失败则将该案例标记为“复杂”需要上报给人类工程师。实操心得根因分析环节的LLM调用成本较高因为上下文长。为了控制成本并提高响应速度可以设立一个优先级队列。对于高置信度的规则异常可以直接走预设的修复模板只有那些复杂的、不确定的异常才触发完整的LLM深度分析流程。3.4 自动化PR创建与协作流程修复方案经过验证后就需要将其“产品化”——即创建PR。这个过程必须规范、透明。实现步骤分支与提交使用自动化服务账号如github-actions[bot]或专门创建的机器账号来执行Git操作。创建分支的名称最好有规律例如fix/auto-bugfix-{异常ID}-{日期}。提交信息Commit Message需要清晰[Auto-fix] Fix {异常类型} in {函数名} Problem: {简要描述异常现象引用异常ID} Root Cause: {LLM分析出的根因摘要} Solution: {具体的代码修改描述} Verified by automated test: {测试结果简述} Issue-Link: {内部问题追踪链接如果有}生成PR描述PR的描述是给人类审查者看的第一份材料必须信息完整。应该包括标题[Auto] Fix: [简要问题描述]是什么问题用通俗语言描述用户或系统遇到了什么现象。根本原因转述LLM的分析结论。如何修复用Diff格式展示具体的代码变更让审查者一目了然。测试说明已经做了哪些测试包括复现测试和回归测试及其结果。潜在影响列出LLM评估的潜在副作用提请审查者注意。相关上下文附上异常追踪的链接或ID方便深入查看。设置PR标签与审查者自动为PR打上auto-generated、bug-fix等标签。根据修改的文件路径利用CODEOWNERS文件或预设规则自动请求相关模块负责人的审查。这是“人类在环”的关键一步。状态同步将PR的链接更新到异常追踪记录中。后续PR被合并、评论或关闭的状态也应同步回来形成闭环。4. 部署策略、监控与持续迭代4.1 渐进式部署与安全边界将这样一个“能自己改代码”的系统直接推向生产是极其危险的。必须采用最保守的渐进式部署策略。只读模式观察期第一阶段只开启系统的“感知”和“分析”部分。让它像一名实习医生一样只负责“诊断”和“开出处方”生成修复方案但不允许“动手术”执行代码修改。所有生成的修复方案以报告形式呈现由人工验证其准确性。这个阶段的目标是评估系统诊断的准确率Precision和召回率Recall。沙箱演练模式第二阶段允许系统在完全隔离的代码仓库分支或沙箱环境中执行完整的“分析-修复-测试”流程。人类工程师定期检查它生成的PR并与人工修复方案进行对比。这个阶段主要测试整个技术流程的可靠性以及修复代码的质量。受控的自动修复模式当系统的准确率达到一个非常高的可信阈值例如诊断准确率95%生成的修复方案被人工采纳率90%后可以进入第三阶段。在此阶段系统可以对预先定义的白名单内的、低风险的模块进行自动修复并创建PR。例如只允许修改工具函数中的空值处理、日志格式等非核心逻辑。所有PR仍需强制人工审查但可以优先处理。明确的安全边界代码修改范围限制通过配置文件明确系统可以修改哪些目录、哪些文件。关键文件保护将核心业务逻辑、身份认证、支付等关键代码加入黑名单绝对禁止自动修改。变更规模限制单次PR的修改行数不得超过一定阈值如50行防止大规模重构。强制人工审查无论何时自动创建的PR必须至少有一名指定的人类成员批准才能合并。可以设置规则如果PR在24小时内未被处理则自动通知更广范围的工程师。4.2 对Harness系统自身的监控一个旨在修复别人的系统自身必须足够健壮。我们需要对“自我进化的Harness”建立同样严格的监控。性能监控监控状态采集器的数据延迟、分析引擎的处理耗时、LLM API的调用成功率和延迟。确保自我修复系统不会成为主系统的性能瓶颈。质量监控这是最重要的。需要跟踪几个核心指标误报率系统标记为异常但经人工确认为正常行为的比例。漏报率人工发现bug但系统未检测到的比例。修复采纳率系统创建的PR被人类审查者合并的比例。修复回滚率系统合并的修复后续因引入新问题而被回滚的比例。成本监控详细记录LLM API的调用消耗特别是用于根因分析的长上下文调用。优化Prompt、设置分析频率上限、对低优先级异常使用更便宜的模型都是控制成本的必要手段。4.3 系统的持续学习与优化系统的“进化”能力就体现在这里。我们需要建立一个反馈知识库。构建修复案例库每一个完整的异常处理案例无论最终是否生成修复都是一个学习样本。案例库应包含异常特征、执行轨迹、分析过程、采取的修复行动或决定不修复的理由、以及最终结果PR合并成功、被拒绝、修复后引入新bug等。优化异常检测模型利用案例库中的“漏报”系统没发现但实际存在的bug样本可以重新训练或调整统计异常检测模型的参数降低未来的漏报率。利用“误报”样本可以帮助系统更好地理解什么是“正常”的边界情况。提炼修复模式与模板分析那些被成功采纳的修复可以发现常见的bug模式及其对应的修复代码模式。例如“空值导致异常”常常对应“增加空值检查”“列表索引越界”对应“检查列表长度”。可以将这些模式固化成“修复模板”。当下次检测到类似异常时可以优先尝试匹配模板而不是每次都调用昂贵的LLM进行深度分析从而提升效率和确定性。Prompt工程迭代根因分析Prompt的效果需要持续优化。通过分析那些导致错误修复或低质量PR的案例检查当时给LLM的上下文是否缺失了关键信息或者Prompt的指令是否不够清晰。定期基于反馈迭代Prompt是提升系统诊断能力性价比最高的方法。5. 常见挑战、应对策略与避坑指南在实际构建和运行这样一个系统的过程中我遇到了不少坑。这里分享一些典型的挑战和应对策略。5.1 挑战一异常检测的准确性与噪声平衡问题初期系统非常敏感规则设得严统计模型阈值设得低导致误报非常多。工程师很快就会被警报淹没产生“狼来了”效应反而忽略了真正的严重问题。应对策略分级告警将异常严重程度分级。例如P0致命功能完全失败、数据丢失、安全漏洞。立即通知要求自动创建PR并高亮。P1严重核心功能降级、性能严重劣化。自动创建PR但在非工作时间不通知。P2一般非核心功能异常、轻微的逻辑错误。系统记录并生成修复建议但仅在每日报告中汇总不自动创建PR由工程师决定是否处理。P3提示可能的代码异味、潜在的优化点。仅记录供后续代码审查参考。引入静默期与聚合对于同一代码位置、同一类型的异常在短时间内频繁触发时进行告警聚合只发送一条汇总通知避免刷屏。反馈闭环提供便捷的渠道让工程师标记告警是“有效”还是“无效”。用这些反馈数据持续优化检测规则和模型阈值。5.2 挑战二LLM分析的“幻觉”与不确定性问题LLM在分析复杂bug时有时会“一本正经地胡说八道”给出看似合理但完全错误的根因分析和修复方案甚至试图修改无关的代码。应对策略提供高质量上下文这是减少幻觉最有效的方法。确保提供给LLM的代码片段是完整的、相关的并且包含足够的注释。如果项目有清晰的架构图或模块说明也可以摘要后提供给LLM。要求结构化输出与推理链如前文所示强制要求LLM以JSON等结构化格式输出并要求其展示推理过程reasoning字段。人类审查者可以通过检查推理链来快速判断分析是否合理。设置置信度阈值让LLM对自己分析的置信度打分。只对高置信度如0.7的分析结果执行自动修复流程。低置信度的结果转为人工审核建议。多模型验证成本较高对于P0级的关键问题可以调用两个不同的LLM如GPT-4和Claude 3分别分析对比它们的结果。如果结论一致则可信度大增如果不一致则直接上报人工。严格的沙箱测试这是最后的、也是最可靠的防线。任何修复必须通过沙箱中的复现测试和回归测试才能进入创建PR的流程。5.3 挑战三修复的副作用与回归风险问题系统修复了A处的bug却意外地在B处引入了新问题或者破坏了原有的功能。应对策略影响范围分析在Prompt中明确要求LLM进行“影响评估”。同时在自动化流程中可以集成简单的静态代码分析工具检查修改是否会影响其他调用该函数的地方。强化回归测试套件这是根本。项目的自动化测试覆盖率越高自我修复系统就越安全。在沙箱测试阶段不仅要运行针对该bug的特定测试还必须运行完整的相关测试套件。小步快跑渐进合并鼓励系统生成小而精的PR每次只解决一个明确的问题。大范围的改动风险极高应设置为禁止或需要特殊审批。代码回滚预案做好随时回滚自动化合并的PR的准备。确保部署流程支持快速回退。5.4 挑战四文化接受度与流程变革问题工程师可能不信任AI生成的代码觉得审查AI的PR更费神或者担心自己的价值被取代。应对策略定位为“超级助手”而非“替代者”始终强调系统的目标是处理那些重复、琐碎、模式化的bug把工程师从枯燥的调试中解放出来去从事更有创造性的架构设计和复杂问题解决。透明化与可解释性确保系统每一个决策为什么认为是bug、为什么这么修都有迹可循并且以工程师能理解的方式呈现清晰的PR描述、推理链。让工程师拥有控制权工程师可以随时关闭某个模块的自动修复、调整检测灵敏度、或者将系统生成的PR标记为“需要改进”。系统是服务于工程师的控制权必须在人手中。展示价值定期展示数据系统处理了多少个低级警报、自动修复了哪些常见问题、为团队节省了多少小时的人工调试时间。用事实赢得信任。构建“自我进化的Harness”是一个长期迭代的过程不可能一蹴而就。从我个人的实践经验来看最重要的不是一开始就追求全自动而是先搭建起从“感知”到“分析”的闭环哪怕分析结果只是给工程师一份高质量的调试报告其价值已经非常显著。然后再在信任和验证的基础上逐步、谨慎地开放“执行”的权限。这个系统的终极目标是让工程师和AI形成一种高效的协同关系共同守护系统的稳定与健壮。
