从编码助手到自治进化
Coding Agent 已经改变了我们写软件的方式。现在它们正在改变软件如何自我改进。
Ashpreet Bedi（Agno 创始人）分享了一套由编码 Agent 构建、运行和自动改进的 Agent 平台。整个 Agent 开发生命周期被压缩成五个 prompt：
- Create — 脚手架一个新 Agent
- Improve — 基于自身规格硬化现有 Agent
- Extend — 为现有 Agent 添加新能力
- Hill Climb — 运行 eval 套件，诊断失败，修复范围内问题
- Review — 扫描仓库，发现文档、代码、配置之间的漂移
"Improve → Hill Climb" 循环以最小人工监督递归改进 Agent。手动做这件事几乎不可想象。
为什么大多数软件无法自改进
这个自动改进循环之所以可能，是因为环境专门为它设计。Agent 代码、trace、日志、eval 套件和运行中的软件都住在同一个地方，编码 Agent 可以端到端地撕扯。
大多数软件无法自改进，因为输入输出散落在不同工具里。要让编码 Agent 运行自动改进循环，它得从三个不同工具拼凑数据，每个都有自己的认证方式，自己的操作逻辑。理论上可行，实践中摩擦太大。
Bedi 的代码库专门为自动改进而设计。三个关键设计决策：
每个动作都暴露为 API
运行 Agent、读取会话、运行 eval——每个关键动作都可以用 cURL 或 bash 执行。编码 Agent 不需要点击 UI，不需要理解复杂的界面，只需要 HTTP 请求。
数据同地化
会话和 trace 住在 Postgres 数据库里。编码 Agent 触发一次运行，读取输出，全程不离开它的环境。没有跨系统跳转，没有上下文丢失。
日志至上
整个平台在 Docker 上本地运行。编码 Agent 读取实时日志，按需更新。测试→审查循环约 5 秒。日志是解锁一切的实时反馈回路。
Agent 平台是第一个动作、数据和迭代工具足够接近的软件类别，编码 Agent 可以端到端测试、修改代码、再测试，直到 Agent 改进。这意味着托管循环的平台，正是循环首先要改进的东西。
五个 Prompt 的工作流
Create：从想法到 Agent
打开 Claude Code，输入：
Run create-new-agent.md in a new branch.
Claude 先问几个关于 Agent 应该做什么、需要什么工具的问题。然后通过 MCP 搜索 Agno 文档找到正确的 toolkit，生成 Agent 文件，在 app/main.py 中注册，重启容器，通过 cURL 做冒烟测试。从 prompt 到 Agent，5-10 分钟。
因为平台包揽了一切，Bedi 正在构建以前懒得做的 Agent：总结隔夜 Slack 消息的 Agent、起草周报的 Agent、高亮仓库中重要 issue 的 Agent。这些都不会撑过多天项目，但都 fits into a coffee break。
Improve：硬化现有 Agent
输入：
Run improve-agent.md on code-search agent.
Claude 读取 Agent 的 INSTRUCTIONS，从中推导 8-12 个探针。有些是黄金路径，有些是边界情况，有些是工具选择测试。还扔几个对抗性的：prompt 注入、畸形输入、试图把 Agent 拉离目标的尝试。
它通过 cURL 对每个探针运行实时容器。读取响应。从容器日志读取工具调用。根据 INSTRUCTIONS 的实际承诺判断 PASS 或 FAIL。
每个失败它选一个杠杆：收紧规则、添加规则、换工具、调 num_history_runs。编辑 agents/<slug>.py，热重载，只重跑失败的探针。
然后迭代。上限五轮。全部通过则提前停止。
零人工输入，除了 kick-off。以前这需要一天手动点来点去，现在全自动。
Extend：添加能力
输入：
Run extend-agent.md on code-search agent.
Extend 让人类在驾驶座。描述一个变更：添加工具、精炼 prompt、修复 bug。Claude 执行。Agno 文档 MCP 已加载，toolkit 研究基于真实 API。
Claude 做变更。运行冒烟测试。每次迭代是一小步验证过的步骤。变更保持外科手术式精确，隔离测试。
Hill Climb：Eval 驱动的持续改进
输入：
Run eval-and-improve.md.
Hill Climb 运行 eval 套件，诊断每个失败，修复范围内的问题。失败类型映射到修复位置：INSTRUCTIONS 中缺失规则、幻觉、错误工具触发、过度指定的评分标准。对每个失败 Claude 选对杠杆，编辑，只重跑失败案例。全部变绿后重跑完整套件抓回归。
Eval 套件是两个文件。evals/cases.py 声明案例。每个案例是一个输入加评分标准（正确响应应该什么样），可选预期工具调用。基于 Agno 的 AgentAsJudgeEval 和 ReliabilityEval。
Improve 捕捉分布外失败。Hill Climb 确保分布内案例继续通过。两者配合得很好。
Review：消除漂移
输入：
Run review-and-improve.md.
Claude 扫描整个仓库，发现文档、代码、配置之间的漂移。磁盘上的每个 Agent 文件都应该在 app/main.py 中注册。代码读取的每个环境变量都应该在 example.env 和 AGENTS.md 中。每个 markdown 文档中的路径都应该仍然存在。每个脚本都应该做它声称的事。
机械漂移就地自动修复：重命名的文件、example.env 中缺失的条目、架构图中缺失的新 Agent。更大的问题标记出来，附带推荐的下一步。
最好在发布前或重构后运行。这种工作对人类很乏味，对能读取仓库中每个文件的编码 Agent 来说微不足道。
文档和代码之间的漂移一直是生产软件的税。现在成本为零。
为什么 Agent 平台是完美试验场
三个原因：
Greenfield。Agent 平台相对较新，可以从一开始就为编码 Agent 设计。
工作流清晰。我们知道如何改进 Agent：运行它，读日志，评分响应，编辑，再运行。
循环真的有用。对普通软件，优化 API 端点没太大意义。对 Agent，每轮改进都是真实、可测量、有价值的。
平台搭对之后，可以在上面构建任何 Agent：用 create 工作流从想法到 Agent，用 improve 工作流硬化 Agent，用 extend 工作流添加新能力，用 eval 锁定它们，然后 hill-climb 对抗它们。用 review-and-improve 工作流保持整个仓库同步。
手动做这些几乎不可能。
开源与上手
Bedi 开源了这套自动改进 Agent 平台：
- 一个可以用 Docker 本地运行或部署到 Railway 的 Agent 平台 starter codebase
- Prompt 放在 docs/ 文件夹
- 克隆、配置，10 分钟内运行 Agent
这套系统已经运行了几周，每次运行都有惊喜：Agent instructions 收紧了半句话，docstring 与代码同步了，平台每次运行都更干净一点。
Bedi 的愿景：一个编码 Agent 端到端管理你的平台，修复那些小到永远不会被人类优先处理的问题。所有软件都将这样工作。