企业官网建设流程全解析

1. 为什么"能修Bug"不能靠Prompt堆出来

做AutoDebug Agent之前，我一直有个直觉：只要给大模型的Prompt写得足够详细——告诉它项目结构、代码规范、常见漏洞模式——它就能像资深工程师一样把缺陷修好。这个直觉在简单Demo里确实成立，模型能给出看起来很专业的修复建议，逻辑通顺，注释得体，甚至还能顺带优化一下代码风格。但一旦放到真实的工程环境里，问题就暴露得很彻底：它经常给出一个上下文里完全自洽、编译一跑却直接报错的"伪修复"。它其实不知道自己改完后程序是否真的能跑起来。

后来我彻底想明白了一件事：大模型在调试任务里缺的不是推理能力，而是"反馈回路"。一个人类工程师修Bug时，会反复做三件事：改代码、跑程序、看错误输出。错误输出是最重要的老师，它会告诉你"你这改得不对，具体错在哪个文件哪一行、什么类型的错误"。模型如果有这个回路，就能在几轮迭代里自己纠正方向；如果没有，它就只能在第一次回答的基础上凭空猜测，运气好碰对了，运气不好就陷入"看起来很合理但实际是错的"状态。

AutoDebug Agent的核心思路就很直接了：把"代码修复"从一个单轮问答任务改造成一个多轮闭环任务。每一轮，Agent提出一个修复方案，系统立刻执行它，收集真实的程序反馈（编译错误、运行时异常、测试失败信息），再把这些反馈喂回给Agent，让它基于真实结果继续修正。整个循环一直跑到测试通过、程序符合预期，或者达到最大迭代次数为止。

这篇文章会围绕这个思路，把AutoDebug Agent从架构设计到Rust环境下的具体实现完整拆开。内容包括反馈回路怎么设计、执行反馈和测试反馈怎么组织、迭代过程里最常见的坑是什么、以及三个真实缺陷的复现案例。无论你是准备自己搭一个调试Agent，还是想理解最近很火的"AI编程助手到底怎么做到自动修Bug"，这篇应该都能给你一个能直接落地的参考。

先说清楚适用范围。AutoDebug Agent面向的是可以被自动验证的缺陷：程序有明确的失败信号（崩溃、断言失败、测试不通过），修复目标也相对清晰。它不适合那种需求模糊、设计决策占主导的任务——比如"重构这个模块使其更易维护"这种没有客观判据的事情，Agent无从迭代。所以在架构上，我们一切的起点都是"验证"。

2. 反馈信号的设计：Agent究竟该听什么

2.1 执行反馈（Execution Feedback）

执行反馈是整个AutoDebug Agent里最基础、也是建成后收益最明显的一条信号通道。思路很简单：修复完代码后，直接用真实指令把程序跑起来，捕获退出码、标准错误输出、崩溃堆栈，然后把这些原始信息送回给Agent。

在Rust环境里，执行反馈的采集通常这样做：

use std::process::Command; use std::str; fn run_execution_feedback(project_dir: &str, run_cmd: &[&str]) -> String { let output = Command::new(run_cmd[0]) .args(&run_cmd[1..]) .current_dir(project_dir) .output() .expect("failed to execute process"); let mut feedback = String::new(); let exit_code = output.status.code().unwrap_or(-1); feedback.push_str(&format!("[exit_code]\n{}\n", exit_code)); if !output.stdout.is_empty() { feedback.push_str(&format!("[stdout]\n{}\n", String::from_utf8_lossy(&output.stdout))); } if !output.stderr.is_empty() { feedback.push_str(&format!("[stderr]\n{}\n", String::from_utf8_lossy(&output.stderr))); } feedback }

你可能觉得，把stdout也塞进反馈会让Agent被无关日志干扰。实际测试下来，我建议保留stdout，但要截断，比如每个通道最多保留3000字符。理由很简单：有些缺陷的表现并不在报错里，而在输出内容的异常上。比如一个排序函数，程序跑完了没有任何报错，但输出里顺序是乱的，这种错误只靠stderr根本发现不了。

执行反馈天然适合捕获三类问题：第一类是运行时崩溃，比如Rust里对None直接.unwrap()导致的panic；第二类是资源型错误，比如文件打不开、网络连不上，这种一般在stderr里有明确信息；第三类是输出异常，程序退出码正常但输出内容和预期不符。前两类容易处理，第三类往往需要配合测试反馈来兜底。

2.2 编译/静态检查反馈

Rust是一门编译器极其严格的静态类型语言，这反而是调试Agent的巨大优势：编译器本身就是最敏锐的第一道探测器。修复方案一旦引入类型错误、借用检查错误、未使用的mut，cargo check直接就是一大堆红色报错。Agent拿到这些信息，比开十次盲猜都有效。

在AutoDebug Agent里，编译反馈作为每轮循环的第一步检查，并且有优先级：编译不通过，就没必要去跑程序。Rust的报错信息质量很高，典型格式包含文件路径、行号、错误代码（比如E0308类型不匹配、E0499借用冲突），以及一段具体的解释。把这些原生信息喂给模型，不需要额外翻译。

cargo check --message-format=short 2>&1 | head -n 120

--message-format=short的产物更紧凑，每行聚焦文件:行号:错误主体，减少token消耗。保留120行，基本覆盖主要的编译错误。

但这里有个细节要提醒：编译反馈只能告诉Agent"哪里不行"，不能告诉它"该怎么改才是设计意图"。比如某个生命周期标注错误，编译器说'a活得不够久，Agent可能给出一个"通过加'static逃避问题"的解决方案，编译能过，但运行时可能变成悬垂引用或者直接panic。所以编译反馈要和执行反馈、测试反馈配合使用，交叉验证，别让Agent找到一个"编译器满意但行为不对"的伪修复。

2.3 测试驱动反馈

测试反馈是整个反馈回路里最像"验收标准"的一环。一个缺陷能不能算修好，最终得看行为是否符合预期，而测试用例恰好就是把预期固化成代码的载体。

AutoDebug Agent的测试反馈分两层：

第一层是原有测试的执行结果。在用户跑修复方案之前，先把项目里已有的测试跑一遍，得到基线结果。修复后再次执行，对比哪些用例从红变绿、哪些还是红的、哪些反而新红了。这组diff信息直接告诉Agent它的修改产生了什么实际影响。

第二层是新增的回归测试。这一步很多人忽略，但它极其重要。如果Agent定位到某个函数应该处理某种边界情况，就应当主动补一个对应的测试用例，写进测试文件里，然后跑一次证明这个用例能捕获原来的缺陷。这样一次修复交付的不只是补丁，还有一个永久守护该缺陷的防线。

推荐的项目里测试命令是：

cargo test -- --nocapture

--nocapture保留测试里的println输出，否则有些调试打印会被吞掉，Agent看不到关键细节。

在实际实现中，我通常把测试结果整理成结构化文本：

[test_case] test_add_valid_numbers [status] PASS [stdout] ... [test_case] test_add_negative_numbers [status] FAIL [error] assertion `left == right` failed left: 3 right: 5

模型读这种结构化反馈的效率远高于读一坨混在一起的日志。格式统一后，prompt里只要说明"每条FAIL代表一个未通过的验收点"，模型就知道该往哪个方向修。

2.4 反馈聚合与行动决策

三种反馈信号收集完之后，Agent面临一个关键问题：**这一轮它到底该干什么？**是继续修代码、补测试、还是觉得已经修好了直接收工？

我的做法是给Agent一个明确的决策状态机，把搜索空间限制住，减少模型自由发挥导致的漂移。

这个状态机的价值在于：Agent不需要从"空泛的代码优化"开始思考，而是被反馈信号直接推到具体的修复动作上。反馈聚合的消息格式长这样：

{ "round": 3, "compile_status": "PASS", "test_summary": {"total": 12, "passed": 10, "failed": 2}, "failed_tests": [ {"name": "test_parse_empty_input", "error": "panic: index out of bounds"} ], "recent_patch": "..." }

把最近一轮的补丁也带进去，模块可以对照自己上一次的动作判断"这次失败是不是我上轮改动引起的"，避免瞎回退。

3. Rust环境里的实际搭建过程

3.1 一个值得复用的Agent主循环骨架

理论上讲清楚了，现在看代码。下面是我在Rust项目里实际在用的Agent主循环骨架。它不依赖任何复杂的Agent框架，核心就一个loop：获取反馈、生成补丁、执行验证、判断退出。依赖尽可能少，运行起来非常稳。

async fn run_autodebug_loop( project_dir: &str, llm: &dyn LLMClient, max_rounds: usize, ) -> Result<DebugReport> { let mut history: Vec<RoundRecord> = Vec::new(); let mut current_patch: Option<String> = None; for round in 0..max_rounds { // 1. 收集当前状态：编译反馈 + 测试反馈 let compile_feedback = run_cargo_check(project_dir); let test_feedback = run_cargo_test(project_dir); // 2. 判断是否已经通过 if compile_feedback.is_empty() && test_feedback.all_passed() { return Ok(DebugReport::success(history, current_patch)); } // 3. 构建本轮Prompt，融合原始缺陷描述 + 历史记录 + 最新反馈 let prompt = build_debug_prompt( &history, &compile_feedback, &test_feedback, current_patch.as_deref(), ); // 4. 调用LLM获得修复补丁 let response = llm.complete(&prompt).await?; let patch = extract_patch_from_response(&response); apply_patch(project_dir, &patch)?; // 5. 记录历史 history.push(RoundRecord { round, feedback_preview: first_80_chars(&compile_feedback, &test_feedback), patch: truncate_patch(&patch, 500), }); current_patch = Some(patch); } Err(DebugReport::timeout(history)) }

这段代码有两点值得说明。第一，历史记录的截断策略很重要。3个回合之后，如果把全部历史都塞进上下文，token消耗会爆炸，而且模型会被早期无关信息干扰。我的策略是最多保留最近5轮，每轮的patch只截前500字符，反馈只截前80字符。第二，退出条件必须放在"编译反馈为空且测试全过"上，而不是Agent自己说"我修好了"。模型说修好了不算数，验证通过了才算数。

3.2 Lambda调用的封装与上下文构建

真正连接Agent和LLM的那层封装，我放在独立的模块里。它负责把分散的信号组装成一封"给调试工程师看的工单"，而不是简单地把报错粘在一起。

def build_debug_prompt(history, compile_feedback, test_feedback, defect_desc, source_snapshot): sections = [] sections.append("## Task\n修复以下代码缺陷。请只输出一个完整的补丁(diff格式)。") sections.append(f"## Defect Description\n{defect_desc}") sections.append(f"## Source Snapshot\n{source_snapshot}") if compile_feedback: sections.append(f"## Compile Feedback\n{compile_feedback}") if test_feedback: sections.append(f"## Test Feedback\n{test_feedback}") if history: sections.append("## Previous Attempts") for h in history[-5:]: sections.append(f"Round {h['round']}: {h['summary']}") sections.append("## Instruction\n输出格式: 以```diff开头, 包含具体文件路径和修改行。") return "\n\n".join(sections)

这一步最容易踩的坑是：把整个仓库塞进prompt。模型不是不聪明，是会被无关代码淹死。我建议优先给这四样东西：

1. 原始缺陷描述（用户报的Bug现象）
2. 与错误直接相关的源码快照（比如崩溃堆栈指向的文件和函数）
3. 编译错误和测试失败输出
4. 前几轮的尝试摘要

上下文里的源码快照怎么选？这里用到一个很实用的小技巧：编译器和运行时错误里都有文件名和行号，用它们反查源码。一次崩溃指向src/parser.rs:42，那就把parser.rs整个文件或核心函数摘出来，而不是把整个src目录丢给模型。

3.3 从"修复建议"到"修复验证"的闭环

闭环看起来只差最后一步——把patch应用上去、再跑验证。但真正动手后你会发现，这中间其实隔着几个工程陷阱。

第一个陷阱是patch格式不统一。模型有时返回完整文件内容，有时返回差异块，有时只给几个代码片段。如果只兼容一种格式，你会经常在"解析patch"这步失败，白白浪费一整轮。我最后的处理方案是修复Agent只输出标准unified diff，解析逻辑兼容三种常见变体：带---和+++的标准diff、只有+和-行的极简diff、以及包含@@上下文块的完整diff。解析失败时不要直接崩溃，把原始输出存下来，当作反馈告诉模型"你的patch格式无法解析，请重新输出"，它通常会自己纠正。

第二个陷阱是源码结构的漂移。对大型仓库来说，Agent第一轮修复时改了第100线，第三轮修复时又改了第100线附近的代码，但因为前面改动导致行号变更，patch应用失败。解决这个问题，我建议用git apply --3way这样的三方合并策略，让patch应用容忍一定的上下文偏移。如果还是冲突，就返回冲突信息，让Agent基于新代码重新生成patch。

第三个坑更隐蔽：验证本身可能受环境因素干扰。比如测试依赖外部网络，某次运行超时导致误判"修复失败"。所以验证环节要加超时和重试机制，至少跑两轮确认结果稳定，再决定是继续还是收工。

4. 让Agent真正"会修"的四个关键细节

4.1 反馈冗余：多个信号交叉验证

你可能会好奇：既然编译反馈已经能证明"代码能编译"，执行反馈能证明"程序不崩溃"，测试反馈能证明"行为符合预期"，为什么还要重复收集？原因很简单——单一信号不足以排除"伪修复"。

举一个真实例子。某个函数对空数组求平均值，Agent的第一次修复是避免index out of bounds崩溃，直接提前返回0。编译过了，程序不崩了，但测试里预期是返回一个Option::None表示"无数据可平均"，结果Agent返回0，测试还是红的。如果只看编译和执行，你会误以为修好了，但测试兜住了这个语义错误。

所以我把三条反馈通道全部保留，让它们形成交叉验证。编译反馈管"语法和类型层面"，执行反馈管"运行时层面"，测试反馈管"语义正确性层面"。三个信号不是互斥的，而是互补的。一个真正能用的调试Agent，必须同时响应这三种信号，并且在Prompt里明确告诉模型它们各自的优先级。

4.2 失败保留：修复后不轻易删除失败用例

迭代过程里有个反面诱惑：Agent发现某个测试用例很顽固，怎么修都过不了，它可能会反过来"建议"修改测试用例，降低断言标准，或者删掉这个用例。这在短视来看能让测试变绿，但从长期看是自杀式修复——你修掉的不是Bug，是守护这道Bug的防线。

AutoDebug Agent在处理这个问题的策略很简单：测试文件默认只读。发给模型的Prompt里明确声明"不允许修改测试代码，测试文件是验收标准"，并且在代码层面做检查，如果生成补丁里包含对tests/目录的修改，直接拒绝并提示"请仅修改源代码"。

但这里有一个例外场景：新增回归测试是允许且鼓励的。Agent可以在tests/下新增一个文件，写一个能捕获原始缺陷的测试用例。新增和修改的区别在于，新增是对验收标准的扩展，修改是对验收标准的篡改。这个边界在工程上要提前写清楚。

4.3 上下文裁剪：围绕错误点的局部快照

前面提过，不要整个仓库都塞给模型。但怎么精准地裁剪出"围绕错误点的局部快照"，其实有更进阶的做法。

我常用的快照选取规则是：

1. 根据错误里的文件:行号，提取那个文件中出现错误的函数，或者整个文件如果小于150行。
2. 如果错误指向的函数调用了其他函数，把关键的被调用函数签名带上，帮助模型理解数据流。
3. 如果错误是类型层面的（编译错误），把相关的结构体定义、trait声明带上。
4. 核心快照之外，再附上仓库的readme或模块说明，给模型一些业务上下文。

快照和反馈加起来，Prompt通常在3000-5000 token之间。控制在这个范围内，模型才能把注意力集中在矛盾点上，而不是在一堆无关代码里找线索。

一段实际用过的快照格式参考：

/// FILE: src/calculator.rs (lines 1-72) /// 这是计算器模块，负责表达式的解析与求值。 /// 当前缺陷：当输入为"5 +"时，程序panic，报错 location: src/calculator.rs:64 /// /// (源码内容...) /// /// 相关类型定义: /// pub enum Token { Number(i64), Plus, Minus, Eof } /// pub struct ExprParser { tokens: Vec<Token>, pos: usize }

4.4 停止条件与最大迭代轮数

闭环设计的最后一块拼图是停止条件。没有明确的退出规则，Agent可能陷入"改-Bad-再改"的死循环，白白烧掉大量token，项目的日志也越来越乱。

我的项目里配置了三个停止条件，都可配置：

• 验收通过：编译通过、测试全绿、执行无崩溃。这个直接进入成功收尾。
• 达到最大轮数：默认8轮，超过就宣告失败，保留历史上的patch供人工分析。
• 连续重复：如果连续两轮产生完全相同的patch，说明Agent已经陷入局部最优，直接终止，避免无意义死循环。

第三个条件经常被忽略，但它很重要。有一次Agent在修一个正则表达式错误，连续4轮输出一模一样的内容，因为Prompt里的反馈没有变化。加入重复检测后，第2次重复就停止并提示"检测到循环，请人工介入"，节省了三分之二的token开销。

5. 复现案例：三个真实缺陷的修复表现

5.1 场景一：空指针/Unwrap调用导致的运行时崩溃

最经典的Rust缺陷类型。看下面这个例子：

fn parse_first_number(line: &str) -> i32 { let mut parts = line.split_whitespace(); let first = parts.next().unwrap(); // 如果line为空，直接panic first.parse().unwrap() }

输入空字符串时，parts.next()返回None，.unwrap()触发panic。AutoDebug Agent的修复路径是：

第一轮，编译通过，程序正常运行空行输入时崩溃。执行反馈捕获到panic堆栈，精确指向unwrap()那一行。Agent的第一版修复是加一个判断：

fn parse_first_number(line: &str) -> i32 { if line.trim().is_empty() { return 0; } let mut parts = line.split_whitespace(); let first = parts.next().unwrap(); first.parse().unwrap() }

编译过、不崩了，但测试挂了。原测试期望空输入时返回Option::None语义，也就是说返回值应该用Option<i32>而不是i32。测试反馈明确告诉Agent语义要求。第二轮Agent正确地把返回值改成Option<i32>，返回None分支，测试全过。

这个案例的价值在于展示"编译正确"和"行为正确"的差距，以及测试反馈如何把Agent拉回正轨。如果只做执行反馈，Agent大概率停在第一版"返回0"的状态就收工了。

5.2 场景二：边界条件引发的逻辑错误

第二类缺陷更隐蔽——不崩溃，但算错。假设有一个二分查找函数，左闭右开区间的右边界处理写错了，导致查找末尾元素时返回-1。

第一轮测试反馈准确捕获了失败点：查找最后一个元素时返回None。Agent看了源码，第一反应是"检查中间索引计算逻辑"，它把mid = low + (high - low) / 2改成了mid = (low + high) / 2。编译过，测试还是挂。

第二轮反馈依然指向同一个用例。Agent这次注意到左侧查找的边界条件，把返回逻辑改成了包含右边界。测试通过，同时Agent主动新增了一个边界测试用例test_search_last_element。因为原始测试没有覆盖"查找最后一个元素"这个场景，Agent通过推理补上了回归防线。

这个案例说明两件事：一是边界的定位往往需要多轮反馈，一轮就中的概率不高，需要Agent能读反馈、调整假设；二是新增回归测试应该被鼓励，这是修复质量和长期可维护性的保障。

5.3 场景三：依赖版本变化导致的接口不兼容

第三个场景更接近真实工程中的麻烦。项目升级了一个依赖库，某个函数的签名变了，但调用方还按旧签名调用，编译报错。

这类缺陷的典型特征是：编译错误信息非常明确，但修复可能不止一处。Agent需要做的是遍历所有调用点，统一替换为新接口。第一次修复往往只改了第一处，编译反馈又暴露第二处、第三处。编译错误信息在这里扮演了"清单"角色，模型每轮按照清单消项，直到编译通过为止。

这个案例的核心教训是：某些缺陷本质上不是逻辑错误，而是"需要系统性地应用一处变更"。Agent面对的不仅仅是"改对一行"，而是"找到所有受影响的位置并一致地修改"。编译反馈在这里的价值不可替代，它能精确告诉Agent还差哪里没改。

6. 调试过程中的常见问题与排查方法

6.1 反馈吞掉关键错误信息

使用中最高频的问题就是：反馈信息被截断得太狠，Agent看不到错误的关键行。

典型的截断灾难是这样发生的：程序输出2万字符日志，我只保留前3000字符，但真正的panic堆栈在第1.2万字符位置。Agent拿到的是无意义的早段日志，自然无法定位问题。修复方案有两个方向：一是智能截断，优先保留stderr、panic信息、错误堆栈，把普通的println输出往后放；二是错误特征提取，把包含error:、panic:、.rs:\d+的行优先提取出来，拼成一段精简的错误摘要。

我最终用的是第二种，效果最好。提取逻辑不复杂：

按行扫描输出，命中以下模式的行优先保留： - 包含 "error[" / "error:" / "panic:" / "thread 'main' panicked" - 包含 ".rs:" 加数字（文件行号） - 包含 "FAILED" / "assertion" / "left == right"

保留下来的错误摘要通常只有几百到一千字符，信息密度极高，Agent定位准、消耗少。

6.2 Token耗尽与迭代失控

调试Agent跑得越久，token消耗越惊人。特别是模型分析一个几千token的Prompt，再生成一个几千token的patch，一轮轻松上万token，8轮下来成本不低。

控制措施有这几条，我按优先级排序：

1. 限制最大轮数，默认6轮，复杂项目最多10轮，超时就人工介入。
2. 压缩历史记录，每轮记录只保留摘要，不保留完整patch。完整patch用git提交记录保存，不进Prompt。
3. 限制输出长度，明确要求"只输出diff，不要解释、不要总结、不要代码重构建议"。
4. 动态降级：如果连续3轮测试结果没有实质变化，自动缩小上下文，只保留最新反馈和源码快照。

还有一个省钱技巧：当测试全绿、只差一个用例时，不要重新跑全部测试，只跑失败用例所在模块。cargo test <test_name>比cargo test省一半时间，也能给Agent更聚焦的反馈。

6.3 修复引入新缺陷的回归检测

Agent在修复一个Bug时引入另一个新Bug，这是多轮迭代里最危险的场景。我说一个实际踩过的坑：某个Agent修一个"日期解析时区偏移"的Bug，它改了时区计算逻辑，原Bug确实修好了，但原本只适用于UTC的另一个测试挂了——因为新逻辑把UTC也当成偏移对象了。

这个场景映射到工程实践，就是"局部修复，全局回归"。应对措施很简单但必须强制：

• 每次循环至少跑一次完整测试集，而不是只跑失败用例。
• 比较"修复前测试基线"和"修复后测试结果"，新出现的失败用例要重点提醒Agent。
• 如果Agent为修复原Bug而不得不调整某处设计，必须明确说明影响面，不能悄悄改。

在反馈Prompt里，我会把每轮对比写成这样的格式：

[regression_check] previously_passing: 11 tests now_failing: 1 test (test_with_utc_time) likely_regression: YES

模型看到likely_regression: YES，通常会把注意力放到"我这次改动是不是影响到了原本正常的功能"上。

6.4 无法解决的Bug：人机分工边界

最后必须诚实地说，AutoDebug Agent不是什么Bug都能修。根据我的实际使用经验，以下三类问题它表现很差：

1. 需求层面的误解：如果缺陷描述本身模糊，Agent可能在错误的方向上越修越远。比如"程序跑得太慢"，这背后可能是算法问题、配置问题、并发问题，甚至可能是硬件瓶颈，没有确定性的验收信号，Agent无从收敛。
2. 多文件、跨模块的架构性缺陷：设计层面的继承关系混乱、模块边界错误，这类问题需要全局视野，Agent在被裁剪的局部上下文里看不到全貌。
3. 涉及外部系统的间歇性问题：网络超时、服务端异常、数据竞争，这些不稳定信号会反复误导Agent，因为它无法区分"代码错误"和"环境波动"。

我的应对方式是：给Agent一个"主动放弃"的选项。当模型判断当前问题超出它的能力边界，或者连续多轮没有进展时，允许它输出[NEED_HUMAN]标记。系统收到这个标记后停止迭代，保留当前状态生成一份报告给人类工程师。这套设计减少了无用token消耗，也让Agent不在一棵树上吊死，反而解决了"无法收敛"的大部分问题。

AutoDebug Agent从设计到落地，真正的核心其实不是"大模型多聪明"，而是那一圈围绕模型的反馈工程。把验证做扎实、把反馈做聚焦、把边界说清楚，模型自然会在真实信号的引导下从"给出建议"进化到"修好缺陷"。这套思路在Rust项目里已经验证了效果，迁移到其他语言也只是替换编译和测试命令的事。我在调试过程中最深的体会是：别指望模型一次做对，但只要你把反馈回路做得足够干净，多迭代几轮，它能做到很多原本以为只有资深工程师才能完成的修复。