跳转至

你还在手动调代码，这个工程师的平台已经在自动进化了

Ch01.209 你还在手动调代码，这个工程师的平台已经在自动进化了

📊 Level ⭐⭐ | 17.3KB | entities/auto-improving-agent-platform-ashpreetbedi-shensi.md

Auto Improving Agent Platform Ashpreetbedi Shensi

你还在手动调代码，这个工程师的平台已经在自动进化了

作者：深思圈（深思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/.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 平台比普通软件更容易自动改进，不只是因为工具链好用，而是因为"改进效果"本身更容易被机器度量。

深度分析

自动改进的本质：规格说明书即测试用例

Ashpreet 的系统在做的事，本质上是把规格说明书（INSTRUCTIONS）当成测试生成器来用。 传统的自动测试需要人工写测试用例——这是昂贵的、容易过时的、难以覆盖边界情况的。而 Ashpreet 的洞察是：如果你把规格说明书写得足够精确，AI 就能从规格说明书自动推导出测试案例。正常路径 + 边界情况 + 对抗性案例，全部从 INSTRUCTIONS 生成，不需要人工介入。 这意味着整个系统的瓶颈从"会不会写测试"变成了"会不会写规格说明书"。这是一个更高级的技能，但也是一个更可扩展的技能——写一份好的规格说明书，然后自动生成一套测试，比手工维护测试套件要高效得多。

架构原则的深层含义

API 化：把每个操作暴露成 HTTP 接口，表面上是技术决策，实际上是把人类工作流翻译成机器可执行工作流的前提。没有 API 化，就没有自动化。 数据同地：Session 记录和执行轨迹存在 Postgres 里，Claude Code 可以直接查询，不需要切换工具。这意味着自动改进的反馈循环是低摩擦的。每一点摩擦都会让自动化变得不经济——数据同地消除了这种摩擦。 日志优先：5 秒完成测试到检查的循环。这个速度改变了什么工作"值得做"的边界——那些以前因为性价比太低而不做的任务（如 Review），现在成本接近于零。

Improve → Hill Climb 的分工逻辑

Improve 和 Hill Climb 解决的是不同维度的问题：

  • Improve：外向探索，捕获超出分布的失败——你之前没想到的问题
  • Hill Climb：向内守住，确保已知问题不回退 这两者形成了一个完整的质量保证循环。Improve 发现新问题，Hill Climb 防止旧问题复现。一个探索，一个防守。

根本性局限：规格说明书的正确性无法自我验证

系统在自动改进的是"Agent 的行为越来越符合规格说明书"，不是"Agent 变得越来越有用"。 这是一个根本性的局限。系统会非常高效地让 Agent 完美符合一个错误的标准。自动改进的底层，仍然压在人写 INSTRUCTIONS 的质量上。 规格说明书本身写错了怎么办？写窄了怎么办？系统会非常高效地让 Agent 完美符合一个错误的标准。这个问题文章没有回答。

真正的不确定：当系统优化方向偏离真正想要的

当系统足够好地自动改进自己的时候，我们要怎么知道它在优化的方向，仍然是我们真正想要的方向？这个问题 Ashpreet 没回答。 这个问题没有好的答案——它触及的是 AI 价值对齐问题的核心。如果自动改进系统足够强，这个问题会被无限放大：你越擅长优化某个目标，你就越需要担心那个目标是否真的是你想要的。

实践启示

1. 把提示词文件化，是自动改进的底层基础设施

Ashpreet 能实现这套系统，有一个低调但关键的前提：把提示词写成 .md 文件放进 docs/ 目录，而不是每次临时在 Claude Code 里打一段话。 这让工作流可以被重复执行，可以被他人克隆，也可以被 AI 自己调用。提示词文件化打开了自动改进的第一道门。 行动项：如果你在用 Claude Code 或类似的编程 Agent，从今天开始把提示词结构化地写进文件。不要依赖临时对话。

2. 架构要从第一天就为自动化服务

Ashpreet 的三条架构原则（API 化 / 数据同地 / 日志优先）不是后来加的功能，而是第一天就刻进架构的决定。 对于已经存在的代码库，迁移到这种架构的代价不小。但对于新项目，这是唯一正确的选择——从第一天就把自动化考虑进去，而不是后来打补丁。 行动项：评估你现有的系统，有多少操作是只能通过 UI 做的？有多少数据散落在不同的工具里？这些是需要优先解决的摩擦点。

3. 测试生成的核心瓶颈是规格说明书

测试案例是从 INSTRUCTIONS 推导出来的，不是人工写的。只要 INSTRUCTIONS 写得足够清楚，测试就会自动生成。 行动项：把你花在写测试上的时间，转移一部分到写规格说明书上。一份好的 INSTRUCTIONS.md 是整个系统的基础。

4. 速度改变什么事情"值得做"

测试到检查只需要 5 秒。这改变了什么事值得做的边界。Review 类的任务（文档和代码漂移检查）以前因为性价比太低而不做，现在成本接近于零。 行动项：列出那些你以前因为"太费时间"而不做的质量维护任务——现在重新评估它们。

5. 人定方向，AI 执行——设计克制

Extend 工作流的核心是"我主导，AI 执行"。判断什么有价值，这件事还在人这边。 自动改进可以无限高效地优化一个目标，但目标本身需要人来设定。保持对目标的主权，是避免系统优化方向偏离真正想要的方向的第一道防线。

相关实体

→ 原文存档