可自我改进的软件

编码 agent 已经改变了我们构建软件的方式。现在，它们也在改变我们改进软件的方式。今天我想分享一个 agent 平台：编码 agent 可以自己构建、运行并改进这个平台。

整个 agent 开发生命周期由五个 prompt 覆盖：

• Create：脚手架生成一个新的 agent。
• Improve：根据 agent 自己的规格说明，对现有 agent 进行加固。
• Extend：为现有 agent 增加新能力。
• Hill Climb：运行 eval 套件，诊断失败，并修复范围内的问题。
• Review：扫描仓库，查找文档、代码和配置之间的漂移。

「Improve → Hill Climb」这个循环，可以在极少监督下递归地改进我的 agent。很难想象要手动完成这一切。

顺便说一句，这种自动改进循环之所以可行，是因为环境从一开始就是为它设计的。Agent 代码、trace、日志、eval 套件以及正在运行的软件都放在同一个地方，所以编码 agent 可以端到端地一路推进。

它之所以有效，是因为我们控制了整个栈。

大多数软件没法自动改进，是因为它的输入和输出分散在各种工具里。要跑起这个自动改进循环，编码 agent 必须从三个不同工具里拼数据：每个工具都有自己的认证方式，也有自己的使用方式。

理论上可行。实际中摩擦太大。

我的代码库是专门为自动改进而设计的。比如，Claude Code 可以测试一个 agent，然后通过读取 session、trace 和日志来判断 PASS 或 FAIL。如果 agent 失败了，它就修改这个 agent，然后再次运行。

有三件事让这成为可能：

1. 所有动作都暴露为 API。运行 agent、读取 session、运行 eval，每个关键动作都可以用 cURL 或 bash 执行。
2. 数据放在一起。Session 和 trace 都存放在我们的 Postgres 数据库中。编码 agent 可以触发一次运行，并在不离开当前环境的情况下读取输出。
3. 日志压过一切。整个平台都在本地 Docker 上运行。编码 agent 读取实时日志，并按需更新。测试 → review 的循环大约 5 秒。日志就是解锁一切的实时反馈循环。

Agent 平台是第一类这样的软件：动作、数据和迭代工具彼此足够接近，让编码 agent 能够端到端测试、修改代码，再次测试，直到 agent 变得更好。也就是说，承载这个循环的平台，会成为这个循环首先改进的对象。

Agent 开发生命周期

接下来我会展示 Claude Code 如何运行我的 agent 平台。

1. 创建一个 agent

要创建一个新的 agent，我打开 Claude Code，然后输入：

Run create-new-agent.md in a new branch.

Claude 会先问几个问题：这个 agent 应该做什么、需要哪些工具。然后它通过 MCP 搜索 Agno 文档，找到合适的 toolkit，生成 agent 文件，把它注册到 app/main.py，重启容器，并通过 cURL 做 smoke test。从 prompt 到 agent，大约 5 到 10 分钟。

因为平台把所有事情都处理好了，我开始构建一些以前根本懒得做的 agent：一个总结夜间 Slack 消息的 agent，一个起草每周更新的 agent，一个高亮仓库中重要 issue 的 agent。这些东西都不值得做成持续几天的项目，但全都能塞进一杯咖啡的时间里。

2. 改进一个 agent

要改进现有 agent，我输入：

Run improve-agent.md on code-search agent.

Claude 会读取这个 agent 的 INSTRUCTIONS，并从中推导出 8 到 12 个 probe。有些是黄金路径，有些是边界情况，有些是工具选择，还有几个对抗性用例：prompt injection、格式错误的输入、试图把 agent 拉离其职责范围的请求。

它通过 cURL 在实时容器上运行每个 probe。读取响应。读取容器日志里的工具调用。再根据 INSTRUCTIONS 实际承诺的内容，判断 PASS 或 FAIL。

对于每个失败，它会选择一个杠杆：收紧一条规则、增加一条规则、替换一个工具、提高 num_history_runs，或者任何适合该失败模式的改法。它会编辑 agents/.py，热重载，然后只重新运行失败的 probe。

然后继续迭代。最多五轮。如果全部通过，就提前停止。

除了启动任务之外，我完全不需要输入。这件事以前要花一天时间手动到处点，现在已经完全自动化了。

3. 扩展一个 agent

要给现有 agent 增加能力，我输入：

Run extend-agent.md on code-search agent.

Extend 流程里，我坐在驾驶座上。我描述一个改动：添加工具、细化 prompt、修 bug。Claude 负责执行。Agno docs MCP 会被加载，所以 toolkit 调研是基于真实 API 的。

Claude 做出改动，运行 smoke test。每次迭代都是一个小而经过验证的步骤。改动保持外科手术式的精确，并且被独立测试。

4. Hill Climb

随着时间推移，我们会积累很多 eval，而手动修复这些失败实在太可惜了。我只需要输入：

Run eval-and-improve.md.

Hill Climb 会运行 eval 套件，诊断每一个失败，并修复范围内的问题。不同失败类型会映射到不同修复位置：INSTRUCTIONS 中缺失规则、幻觉、调用了错误工具、rubric 过度规定。对于每个失败，Claude 会选择正确的杠杆、编辑，然后只重新运行失败用例。等全部变绿后，它会重新运行完整套件来捕捉回归。

Eval 套件由两个文件组成。evals/cases.py 声明用例。每个用例都是一个输入，加上一条 rubric（正确回答应该是什么样），也可以带一个预期工具调用。它基于 Agno 的 AgentAsJudgeEval 和 ReliabilityEval 构建。

Improve 会捕捉分布外失败。Hill Climb 确保分布内用例持续通过。这两个流程配合得非常好。

5. Review

因为这个仓库主要由编码 agent 管理，所以变化很快。为了让所有东西保持同步，我输入：

Run review-and-improve.md.

Claude 会扫描整个仓库，查找文档、代码和配置之间的漂移。磁盘上的每个 agent 文件都应该注册在 app/main.py 里。代码读取的每个环境变量都应该出现在 example.env 和 AGENTS.md 中。Markdown 文档里的每个路径都应该仍然存在。每个脚本都应该做到它声称能做的事。

机械性的漂移会被就地自动修复：重命名的文件、example.env 里缺失的条目、架构图里漏掉的新 agent。更大的问题则会被标记出来，并附上推荐的下一步。

最好在发布前或重构后运行它。这类工作对人类来说枯燥，对能读取仓库里每个文件的编码 agent 来说却很简单。

文档和代码之间的漂移一直是生产软件的一项税。现在它的成本变成了零。

为什么是 Agent 平台？

Agent 平台是这种模式的完美试验场。

1. 绿地。Agent 平台相对较新，可以从一开始就面向编码 agent 设计。
2. 工作流清晰。我们知道如何改进一个 agent：运行它、读取日志、给响应打分、编辑、再次运行。
3. 这个循环真的有用。对普通软件来说，优化一个 API endpoint 未必有什么意义。但对 agent 来说，每一轮改进都是真实、可衡量，并且能增加价值的。

只要把平台搭对，你就可以在上面构建任何 agent：用 create workflow 从想法走到 agent，用 improve workflow 加固 agent，用 extend workflow 增加新能力，用 eval 锁住它们，然后针对这些 eval 做 hill climb。

用 review-and-improve workflow 让整个仓库保持同步。

这几乎不可能手工完成。

我的自动改进 Agent 平台

这里是我的自动改进 agent 平台链接：agent-platform-railway。

这是一个 agent 平台的 starter codebase，你可以在本地用 Docker 运行，也可以部署到 Railway。Prompt 放在 docs/ 文件夹里。克隆、配置，然后 10 分钟内就能跑起 agent。

完整安装指南见 README，参考资料见 Agno Docs。

可自我改进的软件

这几周我一直在跑这个循环，它仍然不断让我惊讶。

Agent instruction 被收紧了半句话。一个 docstring 和代码重新对齐。每次运行后，平台都会变得稍微更干净一点。

我能想象一个所有软件都这样运作的世界：一个编码 agent 端到端管理你的平台，修复那些小到你永远不会优先处理的问题。感谢阅读！

Ashpreet

使用 🧡 和 Agno 构建。