Closing the Loop

1. Prelude

叮，仓库里来了一个新 Issue。

Agent 读完描述，一通修改，提交了一个看似挑不出毛病的补丁。测试用例全绿，它自信满满地宣布：“搞定，问题已修复！”

但……事情真的有这么简单吗？

测试真的测到点子上了吗？这个改动有没有悄悄把别的地方改崩？如果 Code Review 提了修改意见，它能听得懂并继续改吗？要是上线之后 Bug 依旧，系统能不能意识到——这次修复其实是个“假动作”？

今天的大语言模型确实很会写代码。让它写个小功能、补个接口，或者丢一段报错日志过去，它往往几秒钟就能吐出一堆看起来很工整的代码。但在真实世界里，写出补丁仅仅是漫长工程链条的起点。

当一个真正的 Bug 被提成 Issue，彻底解决它的过程往往要曲折得多：
你需要定位问题根因，在隔离环境里复现；修改代码后，确认原有缺陷消失，同时既有功能没有被悄悄改崩；提交 PR 后，在 Code Review 中接受关于边界条件、性能隐患和项目规范的挑剔审查；通过流水线门禁，合并上线；直到几个小时后，线上监控的报错曲线彻底平复，大家才敢确信——这个问题真的搞定了。

当人们期待 Agent 能够持续辅助日常开发时，最难的往往不再是“如何让模型吐出代码”，而是如何将需求输入、代码修改、质量审查、验证隔离与运行反馈，串联成一个真正可以自洽运转的工程闭环。

这道题希望你跳出单次生成代码的玩具场景，设计并实现一个能够自主定位缺陷、执行修复，并在严格审查与验证中形成闭环的开发系统。

别担心，你不需要徒手搓一个庞大花哨的一站式研发平台。相比于堆叠组件，我们更想看到一套职责边界清晰、能真实运转，并且能够合理解释设计取舍的系统。

2. 基本假设

技术选型没有限制。

无论是云端商业模型还是本地开源模型，选择哪门编程语言、Agent 框架、任务队列或持久化方案，全凭你顺手；直接基于现有的开源 Coding Agent 进行二次开发也完全可行。

Lv1 与 Lv2 构成了本题的基础闭环；Lv3 与 Lv4 则是面向更复杂工程场景的可选探索方向。

一条典型的参考闭环可能是：

接收 Issue 需求 → 调度任务 → 执行 Agent 在隔离环境中修改代码 → 提交 PR 发起代码审查 → 自动化测试与质量门禁验证 → 运行日志与反馈回流，驱动下一轮任务。

这只是一种参考。你可以从一个简单的本地任务文件、CLI 命令行工具或 Webhook 开始，不要求绑定 GitHub，不限定特定模型，也不需要搭建复杂的部署流水线。

评价的重点不是“从零实现了多少组件”，而是各个环节是否形成了合理的系统。通知、界面或辅助服务可以直接使用现成工具或 Mock，但代码修改、质量检查与验证反馈这几个核心环节，必须真实发生。

3. Lv1：从问题到一次可验证的修复

Lv1 关注一条最简的闭环链路：接收问题 → 定位排查 → 修改代码 → 执行验证 → 交付变更。

挑选一个可以实际运行的小型代码库，给系统一条真实的缺陷描述（可以包含复现步骤、报错堆栈或失败的测试用例），让它自主完成一次完整的修复。

系统应当像一个真正的工程师那样工作：阅读源码与项目规范，在独立分支、Git Worktree 或临时工作目录等隔离环境中操作，并执行测试验证。最后交付的内容，不仅要有清晰的 Diff 或 Commit，还应当说清楚：它到底改了什么、运行了哪些检查，以及还有哪些潜在风险未能确认。

这里最关键的是修复的真实性。

直接删除失败测试、修改断言、用 try...catch 吞掉异常，或者强行将失败返回值改为“成功”，都不是有效修复。如果确实因为业务逻辑变更需要调整既有测试或约定，应当在交付时明确解释原因，留待审核环节判断。

换句话说，Lv1 的核心目标很简单：证明你的系统真正完成了一次可验证的代码工作，而不是只在聊天框里生成了一段未经检验的修复建议。

4. Lv2：让修复进入工程流程

Lv2 是本题的核心主体。

一次偶然成功的修复，还不足以说明系统可以持续工作。只有当状态流转、质量把关、容错处理和扩展机制协同运转时，自动化修复才算真正进入了工程轨道。

4.1 任务与执行状态

系统应当具备清晰的状态感知能力，能够区分待处理、执行中、等待审核、验证失败与完成等状态。具体的数据结构不限，但核心准则是：“Agent 觉得自己做完了”和“系统判定任务真正完成了”必须是两回事。

如果收到的需求语焉不详、前置依赖未就绪，或者执行中途遭遇死胡同，系统应当能够主动停下来请求补充信息、等待依赖或安全退出，并清楚说明原因。大模型可以负责理解与分析问题，但状态流转、超时控制和重试次数上限等硬性边界，应当由确定性的程序逻辑来主导。

在面对外部系统重复推送时，系统应当具备幂等性，避免无条件重复修改代码或创建多份重复交付物；如果中途遭遇进程中断，重启后应能够从已知检查点安全恢复，或者明确标记需要人工介入。

4.2 代码质量与审查

“代码能跑起来”，只是质量的一小部分。

系统需要结合项目既有的工具链（Linter、静态分析、类型检查与单元测试），建立确定性的质量门禁，明确区分检查的通过、失败与未执行状态。

在此之上，还需要一个真正的 Code Review（代码审查） 环节。审查需重点关注：需求是否被正确且完整地实现？改动范围是否过于激进、有没有误伤不相关的模块？边界条件与异常处理是否周全？代码是否符合项目约定与安全性要求？你可以引入另一个负责审查挑刺的 Agent，也可以设计独立的审核阶段，甚至直接保留人类开发者的裁决权。

审查绝不能流于形式。审核意见必须基于真实的 Git Diff、上下文源码与流水线结果，给出能精确定位到逻辑与细节的建议。执行 Agent 则必须能够理解这些意见，推倒重来并重新验证；如果反复几轮仍无法解决，系统应当及时止损，把现场证据与分歧点打包呈报给人类开发者。

这里有一条坚守的底线：只要客观的静态检查或单元测试失败，无论大模型在评语中如何夸赞，门禁都绝不应该放行。

4.3 可扩展性

我们希望这套系统具备持续的生命力，而不是针对某一个特定演示写死的脚本。

任务入口、工具链调用、代码审查准则和测试验证方式之间，应当具有清晰的职责边界。你可以通过配置文件、标准接口、适配器（Adapter）或插件机制来解耦，切忌为了追求形式上的宏大而去过度设计沉重的框架。

展示一次真实的扩展：例如快速接入第二种任务输入源（如从 CLI 扩展到读取 Markdown 任务单）、增加一项新的质量检查，或者为另一个技术栈完全不同的项目无缝接入测试指令。向我们展示新增一项能力需要修改哪些地方，以及为什么整个核心调度流程可以保持稳定。

仅仅在架构图上画出一个未落地的“插件系统”，或者在代码中保留一个从未被调用的空接口，不足以证明系统的可扩展性。

4.4 可观测性与安全边界

将代码修改权交给模型时，开发者最关心的往往是“黑盒”里的过程。

系统应当留下完整且可追溯的审计轨迹（Audit Trail）：最初的输入是什么、基于哪个版本起跑、Agent 调用了哪些工具、生成了哪版 Diff、审查提了什么意见、测试日志长什么样。当出现故障时，系统能否立刻回答：刚才究竟卡在了哪里？重试时尝试了什么方案？最后通过的检查对应哪一次提交？

与此同时，必须给 Agent 的操作空间划定清晰的安全边界：限制工作目录范围（防误删）、限制系统命令与工具调用白名单、设置超时时间与 Token 开销预算。任务描述、仓库代码乃至第三方库的报错信息，绝不能越权诱导系统执行危险操作；敏感的 API Key 与 Token 也绝对禁止被写入提交或明文日志中。

知道什么时候该停下来、并把清晰的现场证据交由人类判断，本身就是一种成熟的工程设计。

4.5 场景验证

把上述机制组装起来，系统应该能够从容应对真实工程中的几种典型局面：

1. 正常修复：缺陷具备明确的复现用例，Agent 精准定位并修复，全套回归检查通过，改动进入待审核状态；
2. 审查拦截与返工：提交了一版看似能跑、但存在设计隐患、边界漏洞或规范问题的改动，审查机制成功拦截并指出具体问题；执行 Agent 能够理解意见、完成修改并重新通过验证；
3. 无法完成的处理：当需求信息严重不足、验证持续失败或触碰执行限制时，系统主动中止，并给出准确的失败原因与排查上下文；
4. 异常恢复与扩展：展示任务遭遇意外中断后的恢复机制、重复事件到达时的幂等表现，以及 4.3 节中实现的系统扩展。

为了让演示稳定可复现，你可以预设特定的缺陷用例与故障条件，但核心的代码修改、质量检查与验证流程必须真实执行。

Lv2 最终应该证明：修复成功不再是一次偶发的巧合，而是在状态约束、质量门禁、人工授权与容错边界保护下的工程必然。这些机制不应该只是零散的代码片段，而应当构成一个可协同运转的完整流程。

5. Lv3：多个任务，多个仓库

Lv3 是面向复杂工程协作的可选探索方向。

真实世界的软件工程很少只有“单一仓库、单一任务”的温室环境。一旦某个业务需求横跨前后端多个独立代码库，或者多个 Agent 同时在对同一块代码修不同的 Bug，任务调度与协同冲突就会成为新的核心课题。

你可以尝试为系统引入任务编排与依赖分析能力：让它自动理清任务间的先后次序，判断哪些可以安全并行、哪些必须串行等待，并为并发任务维护隔离的工作空间。多个 Agent 可以协同分工，但不必盲目追求 Agent 的数量，协作机制本身才是考察核心。

跨仓库任务必须具备全局视角的验收标准，而不是每个仓库各自宣布通过。如果接口协议发生变更，依赖它的下游服务如何联合验证？如果部分子任务成功而另一部分失败，系统应当继续推进、执行回滚，还是保持现场等待人工裁决？

你可以用一个包含真实依赖关系或修改冲突的案例，展示你的协调策略。

我们真正关注的不是系统派发了多少个并发 Agent，而是它能否理清跨仓库、跨任务的真实约束，避免把彼此孤立的局部成功误判为整体完成。

6. Lv4：让运行结果回到开发流程

Lv4 同样是极富探索价值的可选方向。

当改动被合入主分支、甚至部署上线后，真正的故事才刚刚开始。

现实中的软件从来不是静态的：系统在运行中会抛出异常、指标会抖动、告警会响、用户会报障。一个真正的工程师不仅会修现成的 Bug，更会从纷繁复杂的运行时噪声中嗅出问题。

如果这套系统能够接入运行时的日志、指标或告警流，故事会变成什么样？

它能否在海量报错中做去重与聚类，敏锐捕捉到新出现的异常？能否顺藤摸瓜找到当时对应的代码提交，自动提炼出包含堆栈追踪与上下文的修复任务，重新放入前面已经跑通的修复与审查流程中？甚至，当补丁再次上线后，它能否回到运行环境中继续观察，直到确认那个跳动的异常指标真正归零？

在这条闭环链路上，如果包含自动化发布，系统的安全防线又该如何设计：验证不通过时如何坚决阻断发布？发布后异常激增时如何自动回滚或呼叫人工接管？

最终，我们希望看到的不是一个定时调用模型概括日志的外部脚本，而是一个能将真实的运行时反馈重新接入开发流、具备自我感知与闭环演进能力的生命周期系统。

7. 现场演示：这次真的修好了吗？

准备好整洁的代码、清晰的运行文档，以及一个真实 Demo。

在现场答辩展示时，我们期待看到：

• 一张能讲清楚任务流转、执行隔离、代码审查与自动化验证关系的架构设计图；
• 一次从接收问题输入到产出实际变更与验证结论的完整端到端运行；
• Lv2 所要求的关键能力：审查拦截后的返工闭环、异常与失败时的安全中止、重复事件的幂等处理或中断恢复，以及系统的实际扩展；
• 能够精确溯源到具体代码版本的审计记录、检查证据与未完成待办；
• （若挑战了更高级别）对应的多仓库协调或运行时自愈案例。

不需要华丽的前端界面。终端输出、任务状态、日志和 Diff 已经足够——能把底层运行机制解释清楚，并让我们能够按照说明稳定复现，远比界面的修饰更有价值。

请在演示的同时附带一份配置与成本说明page（所用模型、工具链、依赖环境、运行耗时及Token 账单）。

评价的重点不是连接了多少现成工具，而是系统是否构成了真正可靠的工程闭环。我们真正关注的是：修复是否触及了根因，而不是掩盖了症状；审核是否具备独立的批判与把关能力，能否在代码“看似能跑”时指出真正的隐患；整个流程在面对失败、中断或异常时是否具备确定性的容错与控制力；以及，你所设计的系统自身是否具有清晰的边界，并能合理解释其中的工程取舍。

8. 开放问题

这道题没有标准答案，软件工程的世界里也从来没有万能的银弹。

在构建这套系统的过程中，你可能会不断遇到这些耐人寻味的选择：

• 什么时候应该放手让 Agent 自动重试试错，什么时候必须果断打断并拉人类介入？
• 执行 Agent 和审核 Agent 共享了相同的上下文，会不会导致它们陷入一模一样的认知盲区和误判？
• 自动化测试全部亮起绿灯时，我们距离“放心合入代码”到底还缺少哪些维度的证据？
• 仓库里的规范或规则变了，正在排队的旧任务是按旧规矩走完，还是全部推倒重新评估？
• 在修复过程中总结出的经验知识，哪些值得作为长期记忆留存，哪些只是一次性的临时 workaround？
• 再引入一个新的 Agent，究竟是实打实地提高了准确率，还是徒增了通信开销和系统脆弱度？

这些问题没有标准答案。

我们更关心你如何定义问题、做出取舍，并用清晰的实现和实验解释自己的设计。

Appendix A. 术语速查 (Glossary)

初次上手本题？别有心理压力，先把最核心的主线理顺：

Issue（接收需求）→ Agent（分析与修改）→ Diff（产出改动）→ Review（代码审查）→ 自动化验证（跑测试）→ 结果反馈

吃透这条主线，你就已经拥有足够清晰的思路来着手设计 Lv1 了！