Agent 如何从一次生成走向长期维护？——南京大学《生成式软件工程》第八讲

课程页面：Agent Native 开发 · 课件 · 视频

AI 可以很快生成一个能运行的页面，也可以在同一个项目里持续增加功能、测试和文档。两种能力之间仍然隔着一个工程问题：每一次修改是否真的推进了目标，留下来的结果是否便于理解，下一次会话能否接着工作。一个实现不断增长的项目，也可能不断积累重复、矛盾和已经失效的设计。

Agent Native 开发把 Agent 当作实际参与工作的开发者，为它组织工具、上下文、协作状态、反馈和验证机制。人的职责随之扩展到整个生产过程：比较可能的方案，决定什么状态允许进入主干，保留足以恢复判断的记录，并在架构开始失效时改变方向。快速生成提供了更多尝试的机会，工程机制决定这些尝试能否积累成一个可以长期维护的系统。

一、在搜索空间里同时管理广度和深度

人的意图、系统规约和具体实现之间，都存在一对多的关系。同一个目标可以有不同的业务规则，同一份规则可以有不同的架构和技术实现。即使已经有了一个合理想法，它也只是设计空间中的一条路径。沿着这条路径实现原型、优化性能、补充实验，可以走得很深，却未必接近更合适的整体方案。

深度优先让一个想法获得真实反馈。广度优先则比较较早出现的分叉，例如应该保存哪些事实、怎样划分模块、是否采用事件溯源。越靠近起点的选择，越可能影响后续的可维护性与可观测性。算力和时间有限，工程工作需要在两种探索之间分配资源：先比较影响深远的候选，再让值得验证的方案走到能够运行的位置。

评审提供了一种拓宽搜索的方式。使用不同模型讨论同一个方案，可能得到不同的偏好、遗漏和反例；让它们互相检查，有机会避免过早围绕第一个想法达成共识。同一个模型反复扮演不同角色，也可能很快赞同自己已经提出的路线。不过，模型不同并不保证观点独立，双方都同意也不等于结论正确。评审的价值在于提出可核对的差异，再用需求、材料和实验判断这些差异。

Deeper Research 实验把这种探索放进一个自己构造的 Agent Loop。除了原先个人数字助手里的资料，还可以组织论文、博客、开源项目和书籍片段，使搜索有更丰富的依据。观察真实的执行轨迹，才能知道模型什么时候在比较方案，什么时候已经陷入局部实现，以及继续投入算力究竟增加了什么信息。

原型在这里承担的是验证假设的工作。讨论尚未完全收敛时，可以让 AI 做出一个版本，再用典型用例检查：目标是否清楚，规约是否遗漏交互，模块之间是否出现未曾考虑的依赖。允许原型失败，才能较早发现应该修改哪一层决定。版本生成得更快，也就有了比较不同方向的条件。

二、一个最小 Agent 展示了什么

能够调用工具的 Agent，可以从一个很小的程序开始。一个约 150 行的 Python 原型，只向模型提供 Bash 工具，也能完成文件生成、命令执行和浏览器相关任务。关键机制是模型与环境反复交换消息，工具承担实际动作。

程序先读取用户输入，把任务与工具定义放进请求。Bash 工具声明自己的名称、说明和参数，例如需要执行的 command。模型返回普通文本时，程序把文本输出；返回工具调用时，程序解析参数，运行对应命令，再把结果作为工具消息送回模型。工具调用 ID 将请求与结果关联起来，模型据此继续选择动作。

这构成了一个 ReAct 式的交互循环：根据当前信息决定动作，执行动作，观察结果，再继续决策。Bash 是一个通用入口，模型可以通过它读写文件、调用已有程序，也可以先生成脚本再运行。工具种类很少，并不意味着可组合的操作很少；实际能力仍然取决于模型、环境、可用程序和允许执行的动作。

“足够聪明的模型只需要一个 Bash 入口”可以作为思想实验，用来理解通用工具的表达能力。它并不说明现有模型已经能够完成任意研究问题。会使用工具、能够长时间运行、能够找到正确方案，是不同层次的能力，不能从其中一项直接推出其余两项。

一个小原型也会暴露产品化需要补足的地方。工具执行如果硬编码超时，访问较慢的网络资源时，就可能提前终止仍在正常进行的任务。模型可以决定换一个超时重试，运行时却未必提供这种参数。环境感知、执行控制和错误反馈，由此成为架构问题；只有把原型运行起来，这些缺口才容易显现。

同样，模型已经输出一段回答，只表示这一轮交互到达了输出阶段。它是否满足了用户的完整任务，还需要由目标和验收条件判断。基础工具循环给出了一个能够工作的起点，持续开发还需要更完整的外围机制。

三、Harness 把自主行动组织成工程过程

模型在自己的推理中可以比较方案，也会根据已有上下文形成行动倾向。生成一个页面时，它可能打开多个浏览器窗口、截图检查，再询问是否满意。对于一个需要持续向前推进的任务，这种行为未必就是合适的工作节奏。Harness 负责组织模型可以使用的工具、上下文、权限与反馈，让自主行动发生在明确的工程环境里。

既有代码也会影响模型的判断。一个项目已经采用某种结构时，Agent 往往沿着当前结构继续补丁，努力把功能修到能运行。对于需要立即恢复服务的故障，这种局部修复有实际价值；对于已经失效的架构，持续修补却可能让项目越来越难维护。目标和允许改变的范围必须明确，才能判断这一轮应当恢复功能、比较方案，还是重构模块。

因此，Harness 也在管理搜索空间。它可以让模型先评审设计，可以在一轮修改后运行检查，可以安排另一个模型检查结果，也可以定期审视整体架构。哪些动作值得执行、什么时候执行、执行后怎样判断下一步，都可以进入工作流，而不必依赖模型在一段长对话里自行记住全部约束。

这些安排没有一个适用于所有任务的最终版本。模型更新后，原来有效的系统提示词和 Skills 可能变得多余，也可能继续发挥作用。选取熟悉的任务，对比加入和去掉某项约束后的结果，可以帮助判断它是否仍然有用。提示词、模型和运行机制需要共同评估，长期积累的配置也需要重新检查。

四、Ralph Loop：提示词相同，工作区不断改变

Ralph Loop 的基本形式很朴素：反复把同一个任务交给 Agent，每轮检查、修改和验证，再开始下一轮。提示词可以保持不变，上一轮留下的工作区却已经变化。代码、测试、文档和待办记录成为下一轮的输入，任务由此能够跨越多次会话推进。

这里需要区分两层循环。最小 Agent 内部的循环，连接模型请求、工具调用和结果反馈；外部 Ralph Loop 则组织多轮任务执行及其交接。一次内部会话结束后，外层仍然可以继续启动下一轮。它把一个容易在长上下文中发生漂移的大任务，拆成一系列较小的推进步骤。

工作区可以被视为开发状态。起点可能只有一份规约，下一轮增加一个实现，再下一轮定位测试失败，之后修复并留下验证结果。一次 Agent 执行就是一次状态迁移。Git 可以保存这些状态，需求、代码、测试和日志则让状态拥有可解释的含义。

这种状态比“功能已完成”一句话丰富得多。未完成的部分需要记录下一步，重要结论需要保留依据，运行失败需要留下能够复查的信息。新会话读取这些材料后，才能判断哪些工作已经成立，哪些仍然只是计划。只存在于上一轮聊天上下文里的经验，在会话结束或压缩后可能无法可靠恢复。

外层循环还需要停止条件。一个特殊的完成标记可以作为程序约定，用来结束运行；标记本身却不能证明任务已经完成。验收要求、验证结果和尚未解决的问题，仍然决定它是否有理由输出这个信号。反复执行相同提示词也不保证质量单调提升，循环必须有能识别进展和失败的反馈。

五、小步推进以后，立即验证和评估

一个实用的循环要求是：每轮先检查当前状态，只推进一个明确步骤，然后验证并评估结果。步骤较小，意味着需要核对的改动较少，也更容易发现偏离目标的位置。检查不通过时，后续工作首先处理失败，而不是在不可靠的状态上继续增加功能。

验证可以来自不同层次。测试和检查脚本核对明确条件，另一个模型评审当前改动，人核对目标、架构与体验。它们提供不同的信息：测试能检查已经表达出来的行为，评审可以质疑遗漏的假设，实际使用则可能暴露规约没有描述的问题。选用什么检查，应当由这一步可能破坏什么决定。

名片页面生成实验展示了投入方式怎样影响结果。一个版本带有玻璃动效和终端装饰，却填错了邮箱与机构标识；另一个更朴素的版本，邮箱和 GitHub 信息能够对应实际对象。视觉完成度与事实正确性是两项需要分别检查的属性。

这个对比也有明确限制：生成有随机性，提示词和多轮投入同时发生变化，已有上下文还可能影响风格。一次展示可以说明两份结果存在差异，不能据此证明任何 Loop 都稳定优于一次生成。真正值得保留的是评估方法：把事实、功能与呈现分别核对，再观察多轮修改实际改善了哪一项。

小步循环还允许替换推进方式。在同一个工作区状态上，可以选择实现一个功能、换模型评审、执行测试，或者检查架构。任务的下一步由当前证据决定。状态迁移因此既包含向前实现，也包含纠正路线和清理已有结果。

六、在状态迁移时检查，就有了 CI/CD

“开发者是不可信的”表达了一种工程出发点：不能仅凭开发者的自信接受变更。人可能认为只改一句文档、换一个循环起点不会有问题，Agent 也可能在完成局部任务后忽略其他影响。把重要要求写成检查，并在关键事件上自动执行，才能让它们稳定进入开发过程。

提交、推送、发起合并请求、更新主干和发布版本，都可以成为触发动作的节点。本地的 pre-commit 适合执行较快的格式、静态分析或局部检查；集成环境可以运行构建、测试和更完整的验证；发布流程则核对准备交付的产物。要求开发者记得手工运行一切，远不如把相应检查接入必经流程可靠。

CI，即持续集成，把各项改动不断集成并自动验证。CD 可以表示持续交付，也可以表示持续部署：前者保持产物可以交付，实际发布由人决定；后者进一步把通过要求的变更自动部署。采用哪种方式，需要在工作流中明确，不能仅从“有自动构建”推断已经完成线上发布。

Lint 属于无需执行被检查业务程序即可完成的静态检查，可以涉及格式、命名和可静态判定的问题。它能够挡住一批基础错误，不能替代系统行为验证。单元测试、集成测试和长程模糊测试也各有检查范围，流程需要知道在什么变化后运行哪一种。

Agent 可以辅助生成流水线配置，人的理解仍然决定检查的含义：什么事件应该触发什么动作，失败后必须处理什么问题，哪些要求能够阻止集成或发布。CI/CD 的价值在于把这些要求变成可执行的反馈；所有已知检查通过，也只说明满足了当前已表达的条件。

七、AI Slop 会从文档与代码之间生长

AI 能快速生产大量内容，也容易留下人难以维护的生成物，通常被称为 AI Slop。长篇文档事无巨细地复述实现、记录已经结束的调试过程，或者用许多近似段落包装简单行为，看起来完整，却增加了查找与更新的负担。

更危险的问题来自隐含关系。一个文档描述某段代码，它们在写下时可能一致；代码改了以后，新会话未必知道需要同步这份文档。两份文本继续作为权威材料存在，项目就出现相互矛盾的解释。复制一段接口声明、把同一规则写到多个位置，都在建立未来需要维护的对应关系。

文件目录可以保存这些材料，却不会自动表达哪些内容必须一致、谁是依据、什么变化需要触发更新。软件项目中的重要对象因此还包括关系：文档与源码、中文与英文、架构与模块、任务与实现状态。把关系显式记录并检查，才能避免它们依赖某一轮 Agent 的记忆。

Agent 开发使可判定的文档约束更有价值。例如给关键文档设置长度预算，验证链接能否到达目标，核对文档中的类型声明与源码。过长或失配的内容触发失败，Agent 就能在继续工作前看到具体反馈。只有一句“文档不要膨胀”的提示，随着上下文增长，未必始终得到遵守。

这些检查也有边界。篇幅短不保证含义清楚，链接合法不保证解释准确，接口文字一致不保证整个系统满足需求。机械规则负责稳定发现某一类问题，语义评审继续判断内容是否有用、是否与设计相符。门禁要有准确的检查对象，失败信息也要能够帮助修正。

八、DeepSeek Harness 怎样维护中英文文档

DeepSeek Harness 的文档一致性实践，把本来隐含的关系放进了仓库。受配对规则管理的一篇文档，由中英文 Markdown 和一份 i18n YAML 配对清单共同表示。配对清单作为 Sidecar，保存两个版本的关联和哈希等元数据，使更新能够被检测和追踪。

两种语言的权威地位对等。任何一侧都可以先修改，并成为本次同步的来源；另一侧根据差异更新相应内容。哈希用于判断内容是否相对记录发生了变化，版本历史提供此前状态。哈希本身不表达新旧顺序，更不能证明两份文档的含义相同，变化检测与语义对应需要分别处理。

同步采用补丁式更新：先看源文档改变了什么，再修改另一份文档中对应的段落，其余部分保持稳定。整篇重新翻译会扩大审查范围，也可能让原来已经一致的术语、表达和内容再次漂移。只处理差异，可以把一次修改的影响限制在更容易核对的部分。

翻译配对门禁把这种要求接入验证流程。Agent 负责完成翻译与修订，程序检查需要机械保证的对应关系，评审再核对意思是否准确。术语约定和风格示例进一步明确怎样写，避免每次翻译都重新选择一套名词。

对术语出现次数或段落对应关系做检查，也可以辅助发现遗漏，但阈值必须谨慎设置。自然语言允许不同的合理表达，过严的规则可能拒绝正确的翻译。能够执行的条件需要覆盖真实错误，同时保留语义判断的空间。

这套结构增加了目录中的文件数量。IDE 可以隐藏 Sidecar，或者只显示使用者需要阅读的语言，提供更简洁的浏览视图。展示层的简化可以改善阅读体验，仓库中用于维护关系的信息则继续存在。人的视图与实际工程状态，由此可以采用不同的组织方式。

类似的方法还可以维护文档与源码之间的关系。文档中的指定接口、类型或代码块，需要和相应源文件核对；源码变化后，失配就成为明确的检查失败。给 Markdown 代码块附加轻量的检查语义，还能说明这段内容应该出现在哪里、与什么对象保持关联。关联越明确，更新越容易获得反馈。

九、分层指令、按需加载和协作状态

所有规范都塞进一份常驻文档，会让模型在每个任务里都面对大量无关细节。分层 AGENTS.md 可以在适当范围说明规则，文档长度预算控制常驻信息的规模。翻译、写作、评审等具体流程则放进 Skills，在需要执行这类任务时加载。

这种渐进式披露让任务与方法拥有不同的归属。任务记录描述当前要做什么、做到什么程度；Skill 描述如何实施、如何检查。风格样例、术语约定和检查程序也分别承担自己的职责。Agent 获得完成当前工作所需的上下文，维护者则可以在对应位置更新规则。

Logbook 或 Agent Notes 负责保存协作状态。计划、已经执行的步骤、验证证据、待处理问题，以及提议、实现、拒绝和归档等状态，帮助后续会话理解项目正在发生什么。状态词只是入口，具体记录仍然需要说明做了什么、为什么接受或拒绝，以及还缺少哪些工作。

这些记录也可以和架构图、CI 结果及进度面板关联起来。维护者看到哪个模块正在变化，哪些任务存在依赖，哪些检查已经通过，就能安排下一步。一个面板上的进度估计不能替代完成证据，架构和任务的对应关系却能降低协调许多 Agent 时的认知负担。

验证还需要理解修改范围。只调整任务计划与修改实际代码，可能需要不同的检查；一种类型或文档更新，也有自己的关联验证。能明确变化影响什么，才有条件安排适当的反馈，而不是机械地在每一步重复全部流程。

十、并行协作需要任务真的能够拆开

工作区是状态，也就可以从同一个状态分叉。不同 Agent 在独立的 Git Worktree 中推进不同模块，最后把结果集成起来。版本管理提供隔离与合并机制，模块边界、任务分工和检查机制决定这种并行是否有效。

如果多个 Agent 都只看到“整个项目失败了”，它们可能同时扑向同一个错误，重复修复，或者覆盖彼此的改动。增加执行者数量，并不会自动产生更多独立的进展。任务需要说明对象、责任和依赖，调度机制需要知道哪些工作正在进行，集成检查需要处理单独正确、组合失败的情况。

跨模型评审与并行实现也承担不同职责。前者尝试获得不同视角，后者尝试同时推进可以分离的工作。它们都需要交换必要信息，但不应让全部执行细节无条件进入每一个会话。可复查的结果和简洁交接，让其他参与者获得判断依据，也减少重复读取无关轨迹的成本。

人的管理能力同样有限。Agent 输出速度提高以后，瓶颈可能从编码转向需求判断、评审和协调。架构图、任务记录与自动门禁把状态组织得更清楚，才可能让更多执行活动仍然处于能够理解和调整的范围内。

十一、持续清理有边界，工程经验来自真实试错

周期性的架构评审、文档修正和重复代码清理，可以防止技术债快速积累。把这些维护活动类比为垃圾回收，有助于理解持续整理的作用；这里讨论的是工程维护，和程序运行时回收内存并非同一件事。

但持续清理无法修好所有问题。系统如果建立在不合适的模块边界或设计假设上，局部补丁可能越修越复杂。必要时，需要重构一个模块，甚至建立新的结构，再把已有功能逐步迁移进去。重构的依据是已经识别出的架构问题，迁移过程也要检查功能与行为。

这些判断往往来自实际失败。一个设计在小规模时能够工作，遇到增长或新需求后暴露局限；一个门禁最初只是术语约定，经历失配以后才变成自动验证。阅读开源项目的代码、文档和历史，可以看见机制如何从真实问题中生长，而不仅是记住最终出现的一组名词。

实践资源还会影响获得经验的机会。更多 Token 和运行预算，使人能够尝试更长的任务、比较更多方案；理解反馈、追问失败和吸收好的设计，则决定尝试能否转化为判断力。消耗更多资源与学到更多东西之间，没有自动成立的对应关系。

这里也存在一种教育与培养风险：如果组织只追求短期产出，它可能更倾向于让有经验的人协调大量 Agent，减少培养初学者的投入。初学者因此更难获得形成经验所需的实践机会。这是一种需要讨论的可能趋势，不能把对某个模型的即时感受，直接当成所有学生、职业或教育机构的确定命运。

开源降低了观察优秀工程机制的门槛，亲自运行、修改和失败则补充无法只靠阅读获得的体验。好的想法仍然需要团队把它组织成可靠系统，快速生成也仍然需要能比较方向、识别问题并安排验证的人。

Agent Native 开发由此形成一个相互关联的过程：意图与规约为行动提供目标，工作区保存能够交接的状态，工具与 Harness 组织执行，门禁和评审给出反馈，真实失败促使设计继续演化。一个项目能否长期推进，取决于这些环节能否共同保留判断与修正的能力。