下班前布置任务,睡醒代码已写好

写在前面

最近看到 Addy Osmani（对，就是那个写《Learning JavaScript Design Patterns》的 Google 大神）分享了一篇关于自改进编程 Agent 的文章。

标题很吸引人：Self-Improving Coding Agents。

想象一下，下班前给 AI 布置几个任务，第二天早上醒来，代码写好了，测试跑过了，等着你 Review。

听起来很科幻？

其实已经在发生了。

核心思路

传统的 AI 编程助手是"补全工具"，你写一半，它补另一半。

自改进 Agent 不同。

它是一个循环。

写代码 → 跑测试 → 发现问题 → 改代码 → 再测试。这个循环会一直跑，直到达成目标。

关键在于三个字：能自己跑。

你不需要盯着它，它会自己决定下一步做什么。就像《三体》里的智子，有了自主意识（当然，没那么可怕）。

编排循环

第一个问题：怎么让它跑起来？

答案是设计一个状态机。

每次循环包含几个状态：读任务 → 生成代码 → 执行测试 → 分析结果 → 决定下一步。

听起来简单，但有个致命问题：什么时候停？

测试全过？性能达标？还是跑了 N 次？

没有明确的终止条件，它会一直跑下去。你的云服务账单也会一直涨下去。

Addy 提到可以用 Claude Code 来实现这个循环。

为什么是 Claude Code？

因为它能直接操作文件、执行命令、跑测试。不需要你写一堆胶水代码。

上下文管理

这是最关键的部分。

AI 有个硬伤：上下文窗口有限。

就像人的短期记忆，能记住的东西是有限的。一个项目几百个文件，不可能全塞进去。

那怎么办？

答案是：别全塞。

给它一张"地图"就够了。

这张地图包含：项目结构、关键文件路径、编码规范、常见问题的解法。

就像给新人准备的 README，但更详细。

更聪明的做法是分层。

全局信息（项目架构）、模块信息（某个功能）、局部信息（某个函数）。Agent 根据当前任务，只加载需要的那一层。

这让我想起操作系统的页表（Page Table）。

不需要把所有内存都加载进来，只加载当前需要的那一页。道理是一样的。

记忆持久化

"自改进"的关键在这里。

每次循环结束，Agent 要把经验记下来。

遇到了什么问题？用了什么方案？效果如何？

这些信息存到一个"记忆库"里。

下次遇到类似问题，先查记忆库，看看之前怎么处理的。

这就是经验积累。

做得越多，越熟练。

Addy 建议用结构化的方式存储，比如 JSON。每条记忆包含：问题描述、解决方案、代码片段、成功率。

方便检索，也方便复用。

QA 验证

不能盲目信任 AI。

这是铁律。

最基础的是自动化测试。

单元测试、集成测试、E2E 测试，该有的都得有。Agent 每次提交代码，必须跑完所有测试。

但光有测试还不够。

有些问题测试覆盖不到：代码风格、性能、安全漏洞。

这时候需要静态分析工具（ESLint、TypeScript、SonarQube）。

更进一步，设置人工审核关卡。

关键功能或高风险改动，Agent 完成后不直接合并，而是创建 PR，等人类开发者审核。

就像工厂的质检流程。

自动化生产线很高效，但最后还是需要质检员把关。

扩展到多任务

单任务能跑了，下一步自然是并行。

挑战在于任务之间有依赖。

功能 B 依赖功能 A 的接口，就必须先完成 A。

Addy 提到用任务图（Task Graph）管理依赖。

每个任务是图中的节点，依赖关系是边。Agent 根据拓扑排序决定执行顺序。

这让我想起前端构建工具（Webpack、Rollup）处理模块依赖的方式。

本质是一样的。

另一个问题是资源竞争。

多个 Agent 同时改同一个文件怎么办？

需要锁机制。

就像数据库的事务，保证同一时间只有一个 Agent 能改某个资源。

调试

再智能的系统也会出错。

当 Agent 陷入死循环、生成错误代码、或者莫名其妙卡住时，你需要能调试它。

Addy 建议记录详细的日志。

每次循环的输入、输出、中间状态、决策依据，全部记下来。

出问题时可以回溯，看看哪一步出了岔子。

更高级的做法是可视化监控。

用图表展示 Agent 的工作状态、任务进度、资源使用。

就像 DevOps 的监控面板，一眼看出问题。

还有个实用技巧：断点。

在关键步骤暂停 Agent，让你有机会检查状态、手动干预、调整参数。

风险控制

最重要的部分。

给 Agent 太大权限是危险的。

误删生产数据库？把敏感信息提交到公开仓库？

后果不堪设想。

Addy 强调必须设置权限边界。

Agent 只能访问特定文件夹、只能执行白名单命令、只能调用允许的 API。

给它戴上"紧箍咒"。

另外要有回滚机制。

每次改动都要能快速撤销。

可以用 Git 分支策略，Agent 的改动都在独立分支，确认无误再合并。

还有个容易忽视的点：成本控制。

AI 模型调用要花钱，尤其是 Claude 这种大模型。

Agent 陷入无限循环，账单会爆炸。

必须设置预算上限，超过阈值自动停止。

我的理解

读完 Addy 的文章，最大的感受是：

自改进 Agent 不是魔法，是工程。

核心不是 AI 有多聪明，而是你如何设计这套系统。

上下文怎么组织？记忆怎么存储？任务怎么编排？风险怎么控制？

这些都是工程问题。

AI 只是工具，挑战在于如何用好它。

另一个感悟是，这套方案目前更适合重复性、规则明确的任务。

写单元测试、重构代码、修 Bug，这些它能做。

但需要创造性思维的工作（设计新架构、解决复杂业务问题），它还是力不从心。

即便如此，它已经能帮我们节省大量时间了。

那些枯燥的、机械的工作，交给 Agent。

我们把精力放在更有价值的事情上。

这不就是技术进步的意义吗？

总结

自改进编程 Agent 是个激动人心的方向，但也充满挑战。

要让它真正工作，你需要：

精心设计循环机制。构建高质量的上下文文件。实现记忆系统。建立严格的 QA 流程。做好风险管理。

这是个系统工程，需要在 AI 能力、工程实践、风险控制之间找平衡。

但我相信，随着技术成熟，这种工作方式会越来越普及。

也许不久的将来，我们真能实现"睡一觉醒来，代码已经写好"的梦想。

那时候，我们这些开发者的角色会变成什么？

也许是 Agent 的"教练"、"审核员"、或者"架构师"。

技术在变，但对质量的追求不会变。

这是我从 Addy 的文章里学到的最重要的一课。

参考资料

Self-Improving Coding Agents - Addy Osmani (https://addyosmani.com/blog/self-improving-agents/)