@chenchengpro: 最近大家都在聊 agent 的「loop」，但很少人讲清它到底是什么。Warp CEO Zach Lloyd 给了一个能落地的版本：让 Skill 从反馈里自我进化的双层循环，以 GitHub issue 三分类为例。 内循环：每来一个新…

最近大家都在聊 agent 的「loop」，但很少人讲清它到底是什么。Warp CEO Zach Lloyd 给了一个能落地的版本：让 Skill 从反馈里自我进化的双层循环，以 GitHub issue 三分类为例。

内循环：每来一个新 issue，GitHub Action 触发云 agent 跑 triage Skill，自动分到 ready-to-implement / needs-info / duplicate 三档，打标签并发一条带隐藏标记 oz-triage v:N 的评论，求 /。

外循环：每天一个定时 agent 拉取近 14 天所有被分类的 issue，收集三类信号，评论赞踩、人工纠正回复，还有「人把标签从 ready 改成 needs-info」这种标签漂移（最强 ground truth）。然后把信号提炼成可泛化规则，比如别盯着单个 issue 改，而是写成「崩溃报告缺 OS 版本号一律归 needs-info」，再塞进 Skill 的 Learned guidelines 段、版本号 +1，开 PR 让人 review 合并，永不自动改 main。

要点就一句：Skill 就是文件，改进 = 对文件做 diff；反馈天然藏在 issue 标签和评论里，零额外标注成本。同样适用于 code review、bug 修复、事件响应；目标明确时可用自动 grader 替代人工。Warp 已用它管理自家开源仓库并开源了框架（oz-for-oss）。

Lately, everyone’s been talking about the “loop” in agents, but few people explain clearly what it actually is. Warp CEO Zach Lloyd offered a practical, implementable version: a dual-layer loop that lets Skills self-evolve from feedback, using the three-way classification of GitHub issues as an example.

Inner loop: For every new issue that comes in, a GitHub Action triggers a cloud agent to run the triage Skill, automatically sorting it into ready-to-implement / needs-info / duplicate buckets, applying labels and posting a comment with a hidden oz-triage v:N marker, soliciting /.

Outer loop: Once a day, a scheduled agent pulls all classified issues from the past 14 days, collects signals across the three categories—comment upvotes/downvotes, manual correction replies, and label drifts like “someone changes the label from ready to needs-info” (the strongest ground truth). Then it refines those signals into generalizable rules, like don’t tweak for a single issue but write something like “crash reports missing OS version number all go to needs-info,” and feed it into the Skill’s Learned guidelines section, bump the version number +1, open a PR for human review and merge—never auto-modifying main.

The key point in one sentence: A Skill is just a file, improvement = diffing the file; feedback is naturally embedded in issue labels and comments, zero extra annotation cost. The same applies to code review, bug fixes, incident response; when goals are clear, you can swap in auto-graders for humans. Warp already uses it to manage their own open-source repos and has open-sourced the framework (oz-for-oss).

Factory 2 看起来把 Loop 的工程化做的已经很好了。

Factory 创始人 Matan Grinberg 宣布 Factory 2.0，一句话定调：提升单个工程师的效率已经不够了。真正要解锁的是组织级生产力，而它需要的不是更快的代码补全，而是一个互联、agent 原生、端到端、且能通过观察自身而持续改进的系统，最小增量单元是 AI agent。他给这个系统起名叫「软件工厂」。

软件工厂与其说是新工具，不如说是一种系统拓扑：从外部信号出发（bug 报告、内部对话、客户反馈、业务需求）→ triage 分诊成计划内变更 → 被构建/测试/评审/加固/发布/监控 → 监控又产出新信号，整条是一个连续反馈闭环，闭环本身就是产品。作者的判断是：几乎没人把这条 loop 真正做成了全 AI 驱动，现在还很早，但扩散会很快。

它给「robust 的软件工厂」立了三根硬支柱。一是 Model Independence：没有单一模型适配企业全部需求，要能为不同任务刻意选模型，或用 Router 按 cost/performance/speed 自动或按规则选「最佳」模型，对冲模型商品化带来的成本与能力变化。二是 Sovereign Intelligence 主权智能：部署形态从全托管云、自带密钥、自托管 data plane、EU 专属一直到完全 air-gapped 无外网；但主权的重点不在「在哪运行」，而在拥有一个从自身学习的系统，每次 agent 会话、代码评审、已解决的事故都回流进 loop，能力永远留在你的墙内。三是 Continual Learning：SDLC 每个阶段都要 instrument，代码评审/安全分析/文档/QA/事故响应跑在同一平台、共享同一个 agent core 和 router 和组织上下文，于是安全发现能反哺代码评审、部署能触发文档更新、事故能关联回引发它的那个 PR。

这些不停留在概念，已在 NVIDIA、EY、Adobe、Palo Alto Networks、Adyen、Blackstone、Wipro、Comarch 等组织的生产环境运行。自治被做成一个谱系，而不是一个开关：well-defined 任务用简单 Droid agent 或 skill，周期性工作流用带共享目标与记忆的 Automations，远程持久执行用 Droid Computers，复杂任务用 Missions 把工作拆成并行轨道跨小时数天解。最后落在「人」上：工程师不再是造软件的唯一守护者，而是要去建造那座造软件的工厂，随之承担治理、安全与业务结果的所有权，下一个时代是 engineering-led。