---
title: 你还在手动调代码，这个工程师的平台已经在自动进化了
source_url: https://mp.weixin.qq.com/s/d_Kqaw_2nxJJDXsbHDPPgA
publish_date: 2026-05-13
tags: [article, agent, claude]
review_value: 7
review_confidence: 7
review_recommendation: neutral
sha256: f0aee9cc8210ae245bb71bdaea30d7efa5d280343f88a416f6dd5451626c518e
---
# 你还在手动调代码，这个工程师的平台已经在自动进化了
**作者**：深思圈（深思SenseAI）  
**平台**：微信  
**原始链接**：https://mp.weixin.qq.com/s/d_Kqaw_2nxJJDXsbHDPPgA  
**抓取日期**：2026-05-13  
**来源**：深思圈  
**原始资料**：Ashpreet Bedi (@ashpreetbedi) "Auto-Improving Software"，2026年5月11日
## 背景
Ashpreet Bedi（Agno 创始人，前 Airbnb/Facebook 工程师）分享了他跑了好几周的自动改进代码库系统——每次运行完，软件都比上一次好一点点。
变化很小。但每次都在变好。这已经持续好几周了。
## 五条指令，完整生命周期
整套系统的核心是**五条提示词**，覆盖了 Agent 开发的完整生命周期：
1. **Create**：从零开始，一句指令搭出一个新 Agent
2. **Improve**：让 AI 对着规格说明书自己打探针、自己找问题、自己修
3. **Extend**：外科手术式加新功能，只动需要动的地方
4. **Hill Climb**：批量跑完整个测评集，把所有失败的地方一起修掉
5. **Review**：定期扫一遍整个代码库，把文档和代码之间的漂移修回来
**最关键的组合循环：Improve → Hill Climb**
> "很难想象这件事靠手工完成。"——人类工程师根本没有精力把所有小问题都排进优先级。
## 为什么大多数软件做不到
大多数软件根本不可能做到自动改进，因为**输入和输出散落在不同工具里**。
想象一下：让 Claude Code 帮优化一个 API 接口性能。它首先要从监控平台拉延迟数据，从日志系统查错误率，从另一个工具里看慢查询分析，然后才能改代码。每个工具有自己的登录方式、数据格式、调用方式。摩擦大到让整件事不现实。
Ashpreet 的做法：从一开始就把整个平台设计成为自动改进服务的。不是后来加的功能，是第一天就刻进架构的决定。
**核心：消除了"环境切换"这个步骤。**
## 三条架构原则
### 原则一：每个操作都对外暴露成 API
跑一个 Agent、读 Session 记录、执行 eval 评测——所有关键动作都可以用 cURL 或 bash 调用。Claude Code 不需要模拟点击界面，只需要发 HTTP 请求。
很多系统做不到：核心操作只能通过 UI、只能通过特定 SDK、需要先在浏览器登录。一旦有这种"必须手动操作"的环节，自动化就会卡死。
### 原则二：数据放在同一个地方
Session 记录和执行轨迹都在 **Postgres 数据库** 里。Claude Code 触发 Agent 运行，读取运行结果，完全不需要离开工作环境。没有"去另一个工具里捞数据"这一步。数据是 **colocated** 的，就在那里，随时可以读。
### 原则三：日志是第一公民
整个平台本地跑在 **Docker** 上，Claude Code 读实时日志，边看边改。测试到检查，只需要 **5 秒**。
> 这个数字我第一次读到的时候愣了一下。人工做同样的事，一轮调试少则几分钟，多则几十分钟。速度不只是便利，速度改变了什么事情"值得做"的边界。
## 五条工作流详解
### Create：一次咖啡休息
输入 `/new-agent.md` → Claude Code 问几个问题（Agent 要做什么、需要哪些工具）→ 通过 MCP 搜索 Agno 文档 → 生成 Agent 文件 → 注册到 app/main.py → 重启容器 → 用 cURL 跑冒烟测试。
全程 **5-10 分钟**。
**洞察**：以前不做某件事，不是因为不重要，而是启动成本太高。现在这条界线移动了。
### Improve：自动打探针
1. Claude Code 读取目标 Agent 的 **INSTRUCTIONS 文件**（规格说明书）
2. 从 INSTRUCTIONS 推导出 **8-12 个测试案例**（正常路径 + 边界情况 + 对抗性案例：提示注入、格式错误输入、偏离主题的问题）
3. 通过 cURL 打到正在运行的容器，读响应，读容器日志里的工具调用记录
4. 按 INSTRUCTIONS 承诺的内容判断 **PASS / FAIL**（严格对照规格说明书，不是模糊的"好不好"）
5. 对每个失败案例选择一个修改方向：收紧规则 / 新增规则 / 换工具 / 调整 num_history_runs
6. 编辑 agents/<slug>.py，热重载，只跑失败了的探针重新验证
7. **最多迭代五轮，全部通过就停**
**关键洞察**：测试案例是从 INSTRUCTIONS 里推导出来的，不是人工写的。只要 INSTRUCTIONS 写得足够清楚，测试就会自动生成。你不需要会写测试，你需要会写规格说明书。
### Extend：外科手术式扩展
"我主导，AI 执行"模式。描述想要的改动（加工具 / 改提示词 / 修 bug）→ Claude Code 执行，每步附带冒烟测试。Agno 文档通过 MCP 加载，工具包选择有文档依据。
**设计克制**：人定方向，AI 执行。判断什么有价值，这件事还在人这边。
### Hill Climb：批量对抗测评集
- Improve 针对每个 Agent 单独运行
- Hill Climb 对**整个测评集批量处理**：诊断所有失败案例，按失败类型映射到修改位置来修
**定位**：Improve 捕获超出分布的失败（你之前没想到的问题）；Hill Climb 确保分布内案例持续通过（已知问题不回退）。一个向外探索，一个向内守住。
### Review：文档和代码合在一起
**解决的问题**：README 里有函数名但三个月前就改了；example.env 缺环境变量但代码会用到；架构图里的服务早已被删……
**Review 工作流做的事**：
- 检查每个 Agent 文件是否注册在 app/main.py 里
- 检查代码里读取的每个环境变量是否在 example.env 和 AGENTS.md 里有记录
- 检查文档里的每个路径是否还存在
- 机械性的漂移直接原地自动修，大问题标记出来给推荐下一步
> "文档和代码之间的漂移一直是生产软件的隐性税。现在这张税单的成本是零。"
以前不跑 Review 不是因为懒，是因为这类工作的性价比太低——要花真实时间，但没有交付感。现在成本接近于零了。
## 为什么偏偏是 Agent 平台
三个原因：
1. **全新**：Agent 平台足够新，可以从第一天就为编程 Agent 设计，不用迁就历史包袱
2. **改进路径清晰**：改善 Agent 的方式是明确的——跑它、读日志、给响应打分、编辑、再跑
3. **循环本身有价值**：优化普通 API 意义有限，但对 Agent 来说，每一轮改进都是真实的、可度量的
**更根本的原因（文章没有明说）**：Agent 平台的"产品"本身就是**行为**，而行为天然可以自动测试和评分。
Agent 平台比普通软件更容易自动改进，不只是因为工具链好用，而是因为"改进效果"本身**更容易被机器度量**。
## 作者的反思与保留
### 系统局限
系统在自动改进的是"**Agent 的行为越来越符合规格说明书**"，不是"**Agent 变得越来越有用**"。这两件事不是同一件事。
规格说明书本身写错了怎么办？写窄了怎么办？系统会非常高效地让 Agent 完美符合一个**错误的标准**。自动改进的底层，仍然压在人写 INSTRUCTIONS 的质量上。
### 前提条件
从第一天就要把三条架构原则刻进去（API 化 / 数据同地 / 日志优先）。已经存在的、数据散落在五个工具里、文档三年没更新的代码库，要先付**迁移的代价**，才能到达 Ashpreet 起跑的地方。这个代价不小。
### 提示词文件化
这整套系统能跑起来，有一个很低调但很关键的前提：**Ashpreet 把提示词写成了文件**（docs/ 目录下的 .md 文件），而不是每次临时在 Claude Code 里打一段话。
这让工作流可以被重复执行，可以被他人克隆，也可以被 AI 自己调用。
> 提示词文件化，是这套"自动改进"能成立的最底层基础设施之一。把工作流写成 .md 文件放进 docs/ 目录，看起来只是个整理习惯，实际上是打开了一扇门。
### 真正的不确定
> 当系统足够好地自动改进自己的时候，我们要怎么知道它在优化的方向，仍然是我们真正想要的方向？这个问题 Ashpreet 没回答。我也没有。
## 开源信息
- 平台：agent-platform-railway（开源）
- 底层框架：Agno
- 评测基础：Agno 内置 AgentAsJudgeEval 和 ReliabilityEval
- Eval 集维护：evals/cases.py（每条案例 = 输入 + 判断标准，可附上期望的工具调用）
- 配置：docs/ 目录下五条 .md 提示词文件
- 部署：本地 Docker 或 Railway，10 分钟可跑起来
## 相关资料
- Ashpreet Bedi (@ashpreetbedi)：https://x.com/ashpreetbedi/status/2053885390717890757
- Agno：https://www.agno.com