自我改进的编码智能体
想象一下，结束一天的工作后，第二天醒来发现新功能已经编码、测试完毕并准备好审查。 这就是自主AI编码智能体的承诺——利用 Claude Code 等工具在持续循环中改进和交付代码，即使你在睡觉。
在这篇文章中，我将介绍如何设置这些自我改进的智能体循环——从编排循环和构建上下文文件，到内存持久化、QA验证、扩展、调试和风险管理。希望这里的内容对其他人有所帮助。
这篇文章是对Ryan Carson优秀文章《如何让你的智能体在你睡觉时学习和交付》的补充，我强烈推荐阅读。 我们最近在晚餐时就智能体编码的未来进行了一些精彩的交流，我想扩展他概述的一些技术。
"持续编码循环"（Ralph Wiggum技术）
这种方法的核心是一个迭代的智能体循环，通常被称为"Ralph Wiggum"技术（由Geoffrey Huntley和Ryan Carson等人推广）。关键思想是将开发分解为许多小任务，并让AI智能体在循环中逐一处理它们。
循环的每次迭代遵循一个周期：
选择下一个任务 - 从待办事项列表（例如任务的JSON文件）中选择尚未完成的任务。
实现任务 - 智能体为该特定功能/修复编写或修改代码。
验证更改 - 为该任务运行测试、类型检查或其他质量检查。
提交代码 - 如果检查通过，将更改集成到代码库中。
更新任务状态 - 将其标记为完成并记录任何学习内容。
重置智能体上下文 - 重复下一个任务，直到所有任务完成或满足停止条件。
通过在每次迭代中重置其内存，智能体避免了从先前任务中积累混乱并保持专注。这种"无状态但迭代"的设计是可靠性的关键——它解决了上下文溢出问题，这个问题困扰着要求AI一次性构建整个功能的做法。
与其使用一个可能导致模型偏离或忘记细节的巨大提示，不如反复给智能体一个新鲜的、有界的提示来处理单个明确定义的任务。
结果是更清晰的代码和更少的幻觉，因为每次运行都从一个清晰的状态开始，并有明确的指令。
这里智能体持续选择任务、编写代码、运行测试并更新任务列表，直到所有任务通过。
具有明确标准的小任务
将工作分解为原子用户故事或任务很重要。每个任务应该足够小以适合一个AI会话，并具有明确的通过/失败标准。
例如，与其说"构建整个仪表板"，不如有这样的任务："添加一个带有主页、关于、联系链接的导航栏"，验收标准指定确切的期望（例如"当前页面链接以蓝色突出显示"）。
这种细粒度的方式确保智能体知道每一步的"完成"是什么样子。它还减少了智能体偏离轨道的机会，比如如果任务未通过测试或标准，循环可以立即捕获并纠正方向。
实施提示： 定义SPEC并将其转换为任务JSON。 首先为功能编写清晰的规范，可能在AI的帮助下充实边缘情况。
然后将其转换为结构化的任务列表（例如prd.json文件），包含所有小的用户故事和验收标准。像Carson的/prd和/tasks技能这样的工具可以自动化这种转换。
结果是一个机器可读的待办事项列表，你的智能体循环将逐步执行。
编排循环
运行循环可以通过简单的脚本完成。在Carson的实现中，这实际上就像一个Bash脚本或Python脚本（例如ralph.sh），反复调用AI智能体并使用提示模板。使用Amp或Claude Code，你可以使用它们的CLI命令或插件来实现相同的效果。例如，使用Amp的CLI，可以运行这样的伪代码循环：
while :; do
amp run -s prompt.md -o progress.txt # 使用提示运行Amp，保存输出
if grep -q "<promise>COMPLETE</promise>" progress.txt; then break; fi
done在实践中，循环脚本将加载任务列表，选择下一个未完成的任务，格式化提示（包括相关代码文件和指南等上下文），并调用AI模型。当模型的响应指示成功或失败时，脚本处理应用代码更改和运行测试。这会重复，直到所有任务完成或达到最大迭代限制。
关键是每次迭代都是隔离的——智能体每次都是新生成的，通常作为一个新的Claude或GPT进程，所以你真正地清空了状态，但每次都重新提供必要的上下文。
复合循环： 除了单一的任务序列，高级工作流编排多个阶段的循环。
例如，Compound Product是一个开源系统，首先运行分析循环（AI阅读每日报告以确定要构建什么），然后是规划循环（生成PRD和任务），最后是执行循环（实现任务的编码智能体）。这个复合管道意味着智能体不仅编码功能，还决定什么是最高优先级的功能。
虽然不是每个项目都需要这种级别的自动化，但它展示了循环如何链接：一个智能体的输出（例如任务列表或分支名称）成为另一个智能体在更大的持续交付系统中的输入。
上下文和内存的最佳实践：AGENTS.md手册
这些智能体循环中最强大的机制之一是使用持久的上下文文件，在迭代之间传递知识。
与其试图"延伸"单个AI会话来记住所有内容（这在上下文窗口之外是不可能的），我们明确地将重要信息写入磁盘，以便在未来的提示中重新注入。主要文件通常命名为AGENTS.md（尽管有些使用MEMORY.md或类似名称）。
什么是AGENTS.md？ 它本质上是智能体发现、项目约定以及你希望所有未来智能体知道的任何指导的运行笔记本。
每个任务后，循环可以追加关键学习内容：例如，"注意：代码库使用库X来做Y，所以遵循该模式"或"陷阱：每当更新用户模型时，也要更新审计日志"。
随着时间的推移，这成为一个提示宝库，引导智能体避免重复过去的错误。在Carson的Compound Product理念中，"智能体更新AGENTS.md——发现的模式被记录下来供未来迭代使用"。这意味着每次改进实际上使未来的改进更容易，因为智能体积累了关于代码库是什么样子以及如何使用它的知识库。
构建知识库： 将AGENTS.md组织成章节，使其易于被人类和AI阅读。例如：
模式和约定： 高级模式（例如"此项目使用SSR，UI组件位于/components，API在/routes"）。
陷阱： 曾经困扰智能体或开发人员的事情（"添加新枚举时，更新constants.ts文件，否则测试将失败"）。
风格/偏好： 编码风格注释（"遵循配置的ESLint规则；优先使用函数组件而不是类"，"像现有测试一样使用pytest fixtures进行测试"）。
最近的学习/更改： 最近问题的摘要以及如何解决它们。
保持条目简短和事实性——它们应该作为提示添加剂来指导模型。许多AI编码工具（Claude Code、Cursor、Amp）会自动包含某些文件，如AGENTS.md或README.md，如果它们存在的话。例如，当智能体开始新的迭代时，Amp会扫描仓库并提取AGENTS.md内容，为模型提供项目上下文。
上下文注入策略： 注意上下文大小。随着知识文件的增长，你可能不总是想为每个任务注入所有内容（上下文膨胀会降低性能或导致模型忽略指令）。
一个好的做法是保持AGENTS.md的重点和最新，如果需要，将过时的信息归档到另一个文件。一些高级设置使用检索：例如，将AGENTS.md拆分为多个主题文件，只包含与当前任务相关的部分。但更简单的方法通常就足够了——保持文件修剪到最相关的提示，让它随着项目逐渐增长。
使用示例： 假设智能体尝试使用过时的API，你发现了它。
你可以停止循环并在AGENTS.md中添加注释，如：
"v1/users端点已弃用；改用v2/users。"
下次智能体处理相关任务时，它会看到这个注释并避免使用弃用的API。事实上，你可以指示智能体自己这样做：
"不，不要使用旧端点。相反，使用新的v2/users API。在AGENTS.md中记录这一点，然后继续。"
这种实时反馈技术被开发者Eric J. Ma强调为一种*"创建持久的偏好记录以改善未来智能体行为"*的方法。
智能体会忠实地将更正追加到AGENTS.md并继续执行新指令——有效地从错误中学习。
最后，考虑在智能体或运行之间共享AGENTS.md知识。如果你运行多个循环（用于不同的项目或并行任务），你可以集中一些通用知识。Eric Ma的MCP（模型上下文协议）服务器是一个统一存储和向不同智能体提供此类上下文的系统示例。简单来说，即使是所有智能体会话引用的共享wiki或一组markdown文件，也可以确保一致性，如果你有多个自主智能体协同工作。
内存持久化和复合学习策略
除了AGENTS.md，健壮的智能体循环使用几种持久化机制来保留状态并避免迭代之间的遗忘。Carson的Ralph循环实现在运行之间使用至少四个内存通道：
Git提交历史： 每次迭代的代码更改都会被提交，因此下一次迭代可以执行git diff或检查仓库以查看更改了什么。这样，智能体不需要回忆以前的代码——它可以从仓库中读取。提交消息本身也可以提供上下文（"迭代5：添加了导航栏组件"）。像Amp或Cursor这样的工具允许智能体自主运行git log或git diff（具有适当的权限）以从版本控制中收集上下文。
进度日志（progress.txt）： 每个周期追加的纯文本日志，描述发生了什么——例如尝试了哪个任务以及是通过还是失败，以及任何错误消息或发现。这充当时间顺序的内存。如果循环停止或你需要调试，你可以检查progress.txt以查看哪里出了问题。智能体本身也可以被提示在迭代开始时读取progress.txt（或其相关部分），以提醒它之前尝试了什么。把它想象成智能体的日记。
任务状态（prd.json或任务列表）： 带有任务的JSON文件会随着任务被标记为完成或具有passes: true/false字段切换而更新。此文件持久化每个需求的状态。如果智能体崩溃并重新启动，它可以加载prd.json并确切知道哪些任务仍然存在。智能体循环脚本将跳过已经完成的任务并专注于待处理的任务。这可以防止重复工作并给出进度感。
智能体的知识（AGENTS.md）： 如前所述，这是长期语义内存——过去运行的累积智慧。
这些共同创建了一个复合学习循环：智能体不是在机器学习意义上的"在线学习"，而是系统地记录结果，以便下一次迭代（或下一个项目！）从这些学习中受益。
智能体找出的每个修复或模式都会被纳入下次的上下文中。正如Compound Product README所说，理念是每次改进都应该使未来的改进更容易。
经过数十次迭代，智能体的有效性实际上可以提高，因为它停止重复错误并遵循它学到的约定。
还有基于插件的内存扩展可以利用。
例如，Claude Code支持"技能"甚至市场插件——你可以想象（或构建）一个技能，自动保存每个编码会话的摘要并在下次加载它。Amp的自动交接功能有效地充当短期内存——当上下文窗口即将溢出时，它可以将对话交接到新会话，并提供到目前为止的浓缩摘要。这可以防止任务中途的上下文丢失，对于非常大的任务或复杂的重构很有用。
在更实验性的设置中，开发人员使用向量数据库来存储和检索内存。例如，在每次迭代后，你可以嵌入diff或错误消息，并保存带有描述的向量。在新迭代之前，查询数据库以查找类似的过去案例并将其提供给智能体。
这可以帮助识别，比如说，"哦，我以前见过这样的失败测试以及如何修复它。"然而，这种方法增加了复杂性，如果你勤奋地维护更简单的工件（文件和日志），智能体可以直接读取，可能就不需要了。
提示： 无论你使用什么持久化，定期验证智能体实际上正在使用它。内存文件只有在未来运行中注入到提示中时才有帮助。
检查你的提示模板或智能体配置，以确保例如AGENTS.md和最近的progress.txt条目被包含在内。在Amp和Claude中，默认情况下，像progress.txt这样的文件可能不会自动加载，所以你可以修改你的提示说：*"这是以前运行的注释："*并包含内容。
在Carson的设置中，鼓励为你的项目自定义提示模板（例如prompt.md或CLAUDE.md）——你可以添加加载项目特定上下文或强调特定指令的部分。
质量保证：测试和验证循环
为了让自主智能体可靠地生成工作代码**，自动化验证至关重要**。没有检查，智能体可能会愉快地引入错误或失败的构建，同时认为它成功了。健壮的智能体循环将测试和其他验证作为周期中的一等公民：
单元和集成测试： 拥有可靠的测试套件可以显著改善结果。智能体可以在实现任务后运行npm test或pytest。如果测试失败，循环知道任务还没有真正完成，可以提示智能体修复代码。理想情况下，prd.json中的每个用户故事至少有一个相关的测试，作为验收标准的一部分或在仓库的测试文件中。一些系统更进一步——例如指示智能体在编码之前编写新测试（测试驱动风格）或快照应用程序的UI状态以进行比较。但至少，在每次迭代中运行现有测试。
类型检查和Linting： 静态分析工具（类型检查器如MyPy或tsc，linters如ESLint/Flake8）是很好的自动化反馈。它们可以快速捕获错误。这些可以作为循环质量检查的一部分在提交代码之前运行。例如，你可以在config.json中配置循环应该在智能体编写代码后执行npm run typecheck && npm run lint，并且只有在这些成功退出时才继续。这可以防止智能体在错误之上堆叠错误。
循环中的持续集成（CI）： 一些高级设置甚至与CI管道绑定。例如，Cursor的多智能体实验有一个"评判"智能体可以决定项目是否完成，这可能涉及确保GitHub Actions CI是绿色的。在更简单的单智能体循环中，你可以通过在验证过程中本地运行构建脚本或任何CI检查来模拟这一点。循环应该在红旗时停止——如果检查失败，智能体应该解决它（或将任务标记为仍然失败，如果在N次尝试后卡住，可能会继续）。
AI自我评估（可选）： 在无法轻松编写自动化测试的情况下（例如没有测试框架的UI更改），你可以使用智能体本身来验证。例如，对于前端任务，Carson的智能体使用dev-browser技能：智能体可以启动无头浏览器，导航到页面，并确认UI元素存在或交互有效。这本质上是智能体驱动的集成测试。如果验证失败，智能体知道要再试一次。虽然这可能很强大，但要确保你有沙箱（稍后会详细介绍安全性），因为这意味着智能体正在执行代码或控制浏览器。
专家见解： 如何让AI智能体首先编写好的测试？ 根据Simon Willison的说法，最好的方法是以身作则——在你的代码库中维护高质量的测试，智能体会自然地模仿这些模式。基于LLM的编码者倾向于遵循他们看到的风格。如果你的仓库对现有组件有清晰、简单的测试，当被要求添加新功能时，智能体通常会为新代码生成类似的测试。
Willison指出，一旦项目有了干净的测试，"智能体添加的新测试往往在质量上与它们匹配"。他还建议主动告诉智能体参考已知的好例子：例如*"使用[某个文件]的测试风格"*或甚至指示它克隆另一个仓库以查看某些模式。这种上下文播种可以大大改善智能体的输出，并减少以后修复编写不佳的测试所花费的时间。
在实践中，你可能不总是信任智能体从头开始创建测试——许多开发人员更喜欢自己编写或至少审查测试。但即使如此，在循环中运行这些测试是必不可少的。它创建了一个反馈循环，智能体只有在代码真正满足规范时才"认为"它完成了（测试通过是其代理）。这种智能体QA循环将天真的"生成一些代码"过程转变为可靠的工程工作流。
扩展：并发智能体和多循环编排
到目前为止，我们专注于一个智能体串行处理一个任务列表。如果你想更快地同时处理多个任务甚至多个项目怎么办？该领域的最新实验已经尝试在代码库上同时运行数十或数百个智能体。
虽然这是前沿的，在日常开发中还不常见，但它对于理解扩展这些循环的限制和可能性很有启发性。
并行智能体的挑战： 如果你天真地在同一个仓库上运行许多智能体，你会遇到协调和冲突的问题。例如，两个智能体可能选择相同的任务，或者一个可能更改破坏另一个正在做的事情的代码。使用共享文件锁机制的早期尝试显示智能体卡住或浪费时间互相等待。它们也可能变得规避风险，每个都只做微小的安全更改并避免大的复杂任务——因为在自由竞争系统中，没有单个智能体对困难部分感到"负责"。
规划者-工作者模型： 一个更成功的模式是在智能体之间引入层次结构或专业化。例如，Cursor的Wilson Lin描述在群体中使用规划者智能体和工作者智能体。规划者就像项目经理：他们阅读整个代码库，决定需要做什么，并生成任务（甚至递归地创建子任务）。然后工作者接受这些任务并实现它们，而不用担心更广泛的图景。
在迭代结束时，评判智能体评估目标（例如完成项目）是否达到。这种方法防止了漫无目的的徘徊，并大大提高了吞吐量——Cursor的团队设法让数百个智能体一起工作构建一个网络浏览器，在一周内在1000多个文件中生成了超过一百万行代码。
虽然你可能不需要那种规模，但你可以为不同目的并行运行多个循环。例如，你可以将一个智能体循环专用于前端任务，另一个同时专用于后端任务（在代码库的不同部分或不同分支上操作）。
如果你这样做，确保你清楚地划分工作以最小化冲突。
另一个场景是为单独的功能分支运行单独的夜间循环——例如排队10个功能，你在10个分支上启动10个智能体进程。Ryan Carson预测最终创始人每晚会运行10多个这样的循环以加速开发。每个循环仍然遵循相同的原则，但你需要良好的CI实践来集成所有输出（就像你处理多个人类工程师同时工作一样）。
协调工具： 如果多个智能体必须触及同一个项目，考虑使用协调文件或简单的API进行通信。带有锁定方案的共享tasks.json是一种方法（尽管如前所述，文件锁可能很棘手）。另一种轻量级方法是有一个"交通警察"脚本，将任务分配给智能体并使用队列。
还有新兴的智能体编排平台可以处理多智能体工作流，但现在这些主要是定制构建或研究项目，而不是现成的解决方案。
对于今天的大多数高级用户来说，扩展意味着更深入地迭代而不是纯粹地扩大。让一个有能力的智能体循环在复杂项目上运行更长时间（过夜或多天）通常比启动难以管理的群体更有成效。随着模型能力的增长，长时间运行的单个智能体也在改进。
监控、调试和反馈仪表化
当你将编码委托给自主智能体时，你需要对其行动有可见性。像对待真正的工程师一样对待你的智能体，审查他们的工作。以下是监控和调试智能体循环的一些最佳实践：
实时日志： 保持终端打开，实时跟踪智能体的输出或progress.txt日志。循环应该打印出它正在处理的任务，你应该看到测试结果或任何错误。如果你注意到智能体在同一个错误上循环多次，它可能卡住了——你可以干预（停止它或给出提示）。许多框架让你看到AI的消息；例如，Claude Code桌面应用程序在智能体工作时显示对话线程，Amp的CLI逐步打印模型输出。
检查点提交： 由于每次迭代都提交到git，你有一个很好的审计跟踪。经常使用git log和git diff。快速的git log --oneline -5将显示智能体做的最后几次提交。如果diff中有什么看起来不对，你可以在它走得太远之前捕获它。你甚至可以自动化diff审查——例如，如果diff比预期大得多或触及任务范围之外的关键文件（表明智能体可能"失控"），则中止循环。
检查命令： 将一些调试命令纳入你的循环或使其易于运行。例如，一个显示所有任务状态的脚本（jq '.tasks[] | {id, story, passes}' prd.json）可以快速总结进度。检查progress.txt中的"ERROR"一词或阅读最后N行可以告诉你任务为什么失败。
智能体内省： 如果需要，你可以要求智能体解释自己。例如，如果它在任务上卡住了，你可以修改提示说"如果测试在3次尝试后仍然失败，输出你对原因的推理和计划。"这可以显示智能体的内部思维链（所谓的"自我反思"），这可能会给出线索。谨慎使用——过多的内省也可能混淆循环——但它是调试器工具包中的一个工具。
性能指标： 记录每次迭代花费多长时间以及使用多少成本（API令牌）很有用。你可以检测循环以记录每个任务和总体的时间。如果你看到某个特定任务比其他任务长10倍，这是一个信号，表明它很复杂或卡住了。在许多夜晚，你可以收集像"每小时功能数"这样的统计数据，这可以告知升级（模型更改、提示调整）是否有所不同。
自动停止条件： 有时事情会出错——例如，智能体陷入无用的循环（可能由于它无法解决的棘手错误）或外部依赖项关闭导致测试总是失败。除了正常的完成条件外，设置停止条件。一个简单的是最大迭代限制——例如，即使没有完成，在50个循环后停止。这可以防止失控的成本和无限循环。你还可以在时间限制上停止（"如果这运行超过3小时，杀死它"）或在空闲条件上（"如果在最后5次迭代中没有新提交，跳出"）。这些确保你回到一个停滞的智能体，而不是它整夜运行却没有做任何有用的事情。
手动覆盖： 即使有所有的自主性，在关键时刻保持人工覆盖在循环中。一个好的模式是让智能体在最后打开一个拉取请求，而不是自动合并。这意味着你每天早上都要进行最终的代码审查。你可能会捕获任何通过测试的东西（逻辑问题，或满足验收标准的字面意思但不符合精神的东西）。这个"人工QA"步骤现在是无价的——它让你相信智能体可以做繁重的工作，但不放弃最终控制权。
如果智能体一直在某种任务上失败，把它当作反馈。也许你的验收标准是模糊的或太严格的。或者也许智能体需要在AGENTS.md中关于特定框架的更好提示。使用失败作为你自己和智能体的学习信号。
例如，如果智能体在第三方API上挣扎，因为它缺乏如何使用它的上下文，考虑在AGENTS.md中添加一个简短的使用示例或作为代码中的注释供下次使用。在几天和几周内，这种反思性改进（不像结对编程回顾）将使系统更加健壮。
风险管理和保障措施
运行具有提交访问权限和shell执行权限的代码生成智能体是强大的——也是有风险的。你必须有意识地管理这些风险。以下是关键领域以及如何解决它们：
防止破坏性行动
如果配置错误，自主智能体可能会删除文件、损坏你的仓库或推送不安全的代码。为了缓解这一点：
有限范围： 在功能分支或fork上运行智能体，永远不要直接在main上。这样，即使它做了疯狂的事情，你的生产代码在审查之前是不受影响的。
只读与写权限： 大多数智能体平台对危险操作有确认门。Amp和Claude Code有像--dangerously-allow-all这样的标志来绕过自动化的确认。
谨慎使用这些。一个更安全的方法是只自动批准只读命令，并要求手动批准写入。例如，允许智能体运行grep、git log或npm test而不询问，但不允许git push或rm -rf而不需要你的明确同意。通过白名单安全操作，你让智能体自由地收集信息，同时包含副作用。
- 沙箱： 理想情况下，在受限环境中运行智能体——例如Docker容器或VM——特别是如果它有执行代码的能力（它经常为测试做）。
这限制了任何意外命令的损害。此外，使用范围最小的API密钥：如果智能体需要API密钥来，比如说，发布GitHub评论，给它一个只能做那个而不能做更多的令牌。
- 紧急停止： 始终知道如何在运行中杀死智能体。这可能就像在终端中按Ctrl+C或智能体UI中的特定命令（Claude Code使用Escape键停止生成）一样简单。
如果你看到它做有害的事情，先终止，然后再问问题。还要考虑监控资源使用——如果智能体进程消耗异常高的CPU或内存（如果它在代码中触发疯狂的无限循环，可能会发生），自动监视器可能会杀死它。
处理幻觉和偏离
AI模型有时会产生语法上合理但语义上错误的输出（幻觉）。在编码中，这可能意味着调用不存在的函数、使用不正确的算法或编写无意义的注释。还有任务偏离的风险：智能体可能错误地解释需求并实现错误的东西。
缓解措施：
强规范和提示： 清晰的验收标准和明确定义的任务是你的第一道防线。如果任务说"POST到/api/login并获得200 OK"，智能体几乎没有空间幻想不同的端点。模糊性是敌人。花时间在前面使任务明确，提示模板明确说明要做什么和不要做什么（系统提示/前言可以列举"除非指定，否则不要引入任何新依赖项"或"遵循此仓库中使用的编码风格"）。
验证以捕获幻觉： 前面提到的测试和类型检查将捕获许多幻觉的位（如调用未定义函数）。类型错误、引用错误、失败的测试——这些是智能体做了一些不真实的事情的信号。循环的逻辑应该提示智能体修复这些。通常，只需运行代码并将错误输出反馈回去就足以让模型意识到错误并纠正它。
定期重新聚焦： 长时间运行的循环可能会随着时间的推移而偏离——也许一个小的误解会复合。对抗偏离的一种技术是定期用新鲜的规划重新启动。例如，在一定数量的任务后，你可以暂停并重新运行/prd技能或重新扫描代码库以确保剩余的任务仍然有效。Carson的团队注意到在非常长的智能体运行中需要*"定期的新开始以对抗偏离和隧道视野"*。实际上，这可能意味着在智能体完成一大块后停止它，审查中间产品，如果需要更新任务列表，然后继续。
多模型交叉检查： 如果可用，对不同角色使用不同的模型。Cursor实验发现使用模型混合（一个高度胜任的用于规划，一个代码专业化的用于编码）比一个模型用于所有工作效果更好。你可能没有多个模型选项，这取决于你的工具，但即使对关键步骤使用第二意见模型（如在Claude生成的diff上运行GPT-4检查）也可以减少错误。一些开发人员手动这样做：例如，在循环完成后，在合并之前要求ChatGPT审查PR。
上下文膨胀和优化
随着项目的增长，要提供给智能体的上下文量可能变得巨大。如果AGENTS.md和progress.txt积累了数百行，你不能总是将所有这些都输入到100k令牌窗口中。一些建议：
总结旧内容： 智能体本身可以在这里帮助。你可以提示它："总结上面进度日志的关键点"并存储它，然后截断日志。如果需要，保留摘要的摘要。这以更短的形式保留了重要信息。
分而治之上下文： 使用任务ID只显示日志或代码的相关部分。如果任务7是关于登录页面的，你不需要在提示中包含关于结账功能的注释。一些自动化方法搜索仓库以查找与任务相关的关键字，并仅将这些文件作为上下文包含。
明智地利用训练知识： 记住模型已经有很多一般知识（关于常见库、算法等）。你不需要提供它可能已经"知道"的文档，除非项目使用非常新或晦涩的东西。例如，你可能不需要粘贴整个React文档；相反，只需注意"这是一个使用Hooks和Vite的React项目"，模型可以从其训练中填充其余部分。依靠模型的优势来节省上下文以获取项目特定的细节。
人工监督和持续改进
最后，将整个系统视为一个活的过程。监控它，调整它，并经常应用人类判断。Ryan Carson在他使用这些循环构建的经验中，强调了调整提示和工作流集成所需的"辛勤工作"。
没有一次性的完全自主魔法。这更多的是关于持续的改进。
你作为开发人员的角色从编写代码转变为策划过程——编写规范、审查结果，并在高层次上指导AI智能体（几乎像你的AI开发团队的工程经理）。
也要密切关注成本（API使用）。卡在循环中的智能体可能会烧掉令牌；设置合理的限制，也许还有预算警报。但在实践中，如果做得对，投资回报率可能是巨大的——Ralph社区报告了大规模的生产力提升，有轶事案例，如用几百美元的API调用交付了5万美元的项目。
自主编码智能体已经到来，通过仔细的设置，它们可以承担持续编码的繁重工作。
每次迭代，你和智能体都会变得更好。
欢迎来到AI增强软件工程的下一个层次：在你睡觉时交付，让你的智能体复合你的进步。
这篇文章使用Gemini格式化以提高可读性