研发 Loop：让 Agent 平台自己给自己提需求的研发闭环

多数平台的功能迭代是这么运转的：创始人或产品经理盯着竞品动态拍需求，排期会上一顿争论，功能上线后没有人回头验证它到底有没有用。本文给我们的 Agent 平台 Proteus AI 设计了一条替代路径——「研发 Loop」：先定义清楚平台指标，定时任务去 GitHub 爬取同类平台的新功能，由 Agent 形成实现 PR 并部署到灰度环境，跑一段时间真实流量后看平台统计数据有没有变好；变好，再经 Astra 模型 review 决定是否合入主干；变差，自动回滚。合入与否不再由会议室决定，由数据决定。

这条闭环的价值不只是省人力。它把「功能好不好」从主观争论变成可证伪的实验命题，把「发现需求」从偶发灵感变成每日常态化雷达，也把平台此前散落的自进化零件（指标采集、A/B 分桶、进化编排器、定时任务）第一次串成一条完整流水线。

为什么要造这个轮子

在动手设计之前，我们先对平台做过一轮自进化（Self-Evolution）与递归自我改进（RSI）的差距分析，对照学界七组件框架（经验采集、反思归因、变异算子、适应度评估、选择存档、自主循环、安全边界）逐项盘点源码。结论是：平台已有一条内源失败驱动的进化回路——失败案例自动归因、生成技能候选、离线评测门禁、提交 PR 待人工合入，零件齐全但变异源只有「自己的失败」。

缺的是外源市场驱动：同类平台发布了什么好功能、用户在为什么买单，这些信号完全没有进入平台的进化回路。研发 Loop 就是补上这一块——它复用内源回路已验证的全部基础设施（指标采集、门禁模式、定时任务、PR 快照回滚），把变异源从「失败案例」换成「外部竞品功能」，把适应度评估从「离线评测」升级成「灰度环境真实用户指标」。

两者的关系是互补而非替代：内源回路修平台已知的问题，研发 Loop 为平台引入它自己想不到的新能力。

平台已有的零件

设计的第一原则是不造第二套轮子。盘点下来，六阶段流水线需要的基础设施大部分已经在库里：

已有零件	位置	在研发 Loop 中的角色
任务级指标采集	task_metrics_tracker，ChatAgent 收尾锚点落库	过程指标与北极星指标数据源
A/B 分桶与 z 检验	evaluation/experiments.py：md5 确定性分桶、两比例 z 检验	灰度分桶与统计判定，直接复用
进化编排器	evolution_orchestrator：游标、健康门禁、预算环境变量	DevLoop 编排器的结构模板
候选对比门禁	candidate_gate：merge 前候选对基线，报告写回 PR	Astra 证据包的雏形
定时任务与长任务	timer_task_operator、长任务预算与墙钟控制	雷达爬取与每轮循环的触发载体
Skill PR 快照回滚	merge 前自动快照、一键回滚	回滚机制的既有范式
K8s 部署清单	core 与 gateway 两套 manifest	复制一份即得灰度命名空间

真正需要新建的只有四块：指标注册表与每日快照、功能雷达（爬取与评分）、灰度命名空间、Astra Review 证据包组装器。这个比例决定了项目是「装配」而不是「重建」，工程量可控。

六阶段流水线总览

整条流水线自上而下六站，数据在站与站之间单向流动，唯一的大回环是「合入与回流」绕回「功能雷达」——每一轮的经验都会沉淀下来影响下一轮的选择。

flowchart LR
    A[定义指标] --> B[爬取功能]
    B --> C[形成 PR]
    C --> D[灰度部署]
    D --> E[观测数据]
    E --> F{统计判定}
    F -->|显著变好| G[Astra Review]
    F -->|护栏击穿| R[自动回滚]
    F -->|样本不足| E
    G -->|通过| M[合入全量]
    G -->|不通过| C
    M --> A

把六站抽象成一句话：S1 让「变好」可计算，S2 让需求发现常态化，S3 让每个 PR 自带可证伪假设，S4 让效果在真实流量上可测量，S5 用统计代替直觉做判定，S6 用模型 review 做代码与证据的终审。下面逐站展开。

第一站：指标地基

没有指标口径，后面所有环节都是主观判断。这一站新建一个指标注册表 MetricRegistry，每个指标登记五件事：key、层级、口径 SQL、方向性（涨是好是坏）、容忍带。指标定义进仓库版本化、走代码评审，Agent 在运行期改不了——这是「评估器不可被博弈」的第一道保证。

指标分三层：

层级	指标	说明
北极星	任务成功率、人均完成任务数	定义平台长期方向
护栏	单任务成本、p95 时延、点踩率、安全事件数	任何北极星改善都不得击穿护栏
过程	工具调用成功率、平均迭代轮数、token 消耗、任务时长	定位问题用，全部已有采集锚点

数据源全部是现成的：任务级指标、成本账本、点赞点踩反馈、离线评测与工具指标五条采集链路都已在生产运行，缺的只是一个每日快照表——由定时任务按环境（production / canary）与分桶（baseline / treatment）两个维度聚合落库。判定灰度效果时只读快照、不重算，保证前后口径一致。

第二站：功能雷达

雷达解决「需求从哪来」。每天一次定时任务触发长任务，去 GitHub 爬三类信息：Trending 榜、对标仓库的 Release 与 Changelog（Dify、n8n、Coze、LangGraph 这类同类平台）、相关 awesome 清单与高热度 issue。爬取只读公开信息，遵守频率限制，来源清单白名单化管理。

爬到的原始信息经 LLM 三步加工：先与候选库已有项和平台现有功能做去重比对，再按三个维度打分——需求热度（stars 与 issue 量）、差异度（我们有没有）、实现成本预估——最后产出结构化的 Feature Brief：功能是什么、对标来源、目标指标假设、影响面、成本档位。全部落进候选库，状态机为「发现 → 筛选 → 立项 → PR 已开 → 灰度中 → 已合入 / 已拒绝 / 已回滚」。

人的角色保留在筛选环节：管理员在候选库里决定本轮做哪个。试点期不授权自动挑选——机器负责发现与评估，人负责取舍。

第三站：PR 工厂

每个立项必须绑定一条可证伪的指标假设：预期改善哪个北极星或护栏指标、幅度多少、观测窗口多长。写不出假设的功能不立项——这条规则强迫所有需求在动手前想清楚「怎么算成功」。

实现交给 coding Agent：在独立 worktree 里按仓库纪律干活（失败测试先行、最小变更、跑完验证矩阵），产物是带测试与文档的标准 PR。PR 元数据里记录候选来源、指标假设与预算消耗，供后续裁决与审计追溯。

一道关键的 CI 门禁：变异面白名单。PR diff 只允许触碰白名单目录（产品功能代码、skills、prompts、workflows）；认证、权限、数据隔离、存储迁移、密钥这些目录出现 diff 直接拒绝，根本进不了灰度。这是工程约束，不是君子协定。

第四站：灰度环境

K8s 部署清单复制到独立命名空间 proteus-canary：独立数据库 schema、独立 Redis、独立对象存储前缀，与生产物理隔离。镜像由 PR 的 CI 构建，tag 就是 PR 号——回滚时可以精确回到任意版本。

流量切分直接复用平台已有的实验分桶：md5(user) % 100，同一用户永远落在同一桶，跨会话稳定。试点期 5% 用户进实验桶（treatment），由灰度环境服务；其余 95% 留在对照桶（baseline），继续由生产环境服务。两组用户走的是同一套指标口径，唯一的区别是那 5% 用上了新功能。

数据隔离同样严格：灰度产生的会话与任务数据带 env=canary 标记落库，聚合时按维度切分，灰度期数据不污染生产基线时间序列——否则「对照」就失真了。

第五站：统计判定

观测窗口 7-14 天，每日对比四组核心数字：任务成功率、单任务成本、点踩率、p95 时延。窗口结束做两比例 z 检验，按结果走三个分支：

• 分支 A，显著变好：北极星指标改善且 p < 0.05，护栏全部不击穿——进入终审；
• 分支 B，不能确定：结果持平或样本不足——延长窗口一次（最多 7 天），再不显著按拒绝处理；
• 分支 C，护栏击穿：成本涨超 20%、点踩率上升、或出现任何安全事件——立即自动回滚并熔断该候选。

这一站最重要的一条纪律是样本不足不放行：z 检验不显著就宁可多等 7 天，绝不让噪声决定合入。统计显著性的意义在于把「看起来变好了」和「真的变好了」区分开——低流量平台的灰度实验最容易死在这一点上，设计里必须预留「延长窗口」和「临时调桶」的预案，而不是降低门槛。

第六站：Astra Review 与合入回流

数据说「变好」之后，终审交给 Astra 模型。它拿到的不是一段孤零零的 diff，而是一个完整证据包：代码 diff、treatment 与 baseline 的指标曲线、z 检验报告、原始 Feature Brief、测试结果。证据包组装后写回 PR 留证，任何人事后都能复盘当时的裁决依据。

Astra 输出结构化裁决：APPROVED（合入主干、全量发布、回收灰度环境）、REJECTED（写回候选库并附原因）、RETRY（打回 PR 工厂修复）。合入不等于结束——护栏指标进入持续监控，合入后击穿依然触发回滚。每轮「做了什么、效果如何」的经验沉淀回候选库，作为后续雷达评分的先验：哪类功能在这个平台上历史上有效，数据会慢慢教会让它学会挑。

安全治理：让循环敢自己转

一条能自己转的研发回路，必须在设计时回答三个问题。评估器能被收买吗？ 不能：指标注册表与快照聚合在变异面白名单之外，PR 改不了历史快照，z 检验是纯函数。退化能撤销吗？ 能：回滚三件套是 git revert 加 K8s rollout undo 加关 Feature Flag，镜像 tag 即 PR 号可以精确回退。人在哪一环？ 看板与熔断：每一步落审计日志，管理员随时可以叫停整条循环。

熔断与预算四条底线：连续 2 轮指标变差自动暂停循环、单任务成本超预算 20% 终止本轮、每月最多 8 个自动 PR 防刷屏、出现 1 起安全事件立即全停告警。所有开关走环境变量、默认关闭，与平台既有编排器的惯例一致。

最后一条原则写给未来的自己：自动化程度是挣来的。试点期 Astra review 通过后仍由管理员确认合入；护栏连续稳定后，再放开功能类 PR 的自动合入；连续三个月零安全事件，才谈全自动化。护栏越稳，环路越开——这个次序不该反过来。

落地路线与风险

数据模型只新增四张表：指标注册表、每日快照、功能候选库、轮次记录，全部走既有 Repository 模式与 Alembic 迁移。实施按六个里程碑推进：指标地基（有连续 7 天生产快照）、功能雷达（一条候选全链路可追溯）、PR 工厂（白名单外 diff 被负向测试拒绝）、灰度环境（分群正确、互不污染）、裁决闭环（一次真实回滚演练成功）、全自动试点（两周无人工干预跑通两个候选）。

三个已识别的风险：流量不足——低日活下 5% 灰度桶可能 7-14 天凑不齐显著样本，预案是延长窗口或临时调桶，绝不降低统计门槛；指标噪声——上游模型波动会污染北极星，预案是重大外部变更期间冻结轮次；评审单点——Astra 误判的兜底是 RETRY 通道、人工可推翻与全程留证。

这套设计最有趣的副产品是视角转换：平台不再只是「被开发的对象」，而是一个会自己盯着行业、给自己提需求、用数据验证每一个想法是否成立的系统。人从需求过滤器变成目标与边界的设定者——这大概就是「研发 Loop」这个名字里 Loop 的真正含义。

参考资料

• Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents（arXiv:2505.22954）：迭代修改自身代码、以实证基准验证的编码 Agent，本文安全边界设计的参照。
• AlphaEvolve: A coding agent for scientific and algorithmic discovery（arXiv:2506.13131）：评估器级联与程序数据库的进化回路范式。
• Voyager: An Open-Ended Embodied Agent with Large Language Models（arXiv:2305.16291）：技能库经验回流与验证门禁的先行者。
• A Survey of Self-Evolving Agents（arXiv:2507.21046）：自进化四维分类（what/when/how/where），本文七组件对照框架的来源。
• Dify、n8n：功能雷达的对标平台代表。