AI Agent 的下一站:软件工厂,还是失控循环?

我看完 Latent.Space 对 AI Engineer World’s Fair 的记录后，最想单独拎出来聊的是 Agentic Loop。

AI 编程助手已经越过补全代码阶段。它能读报错，改文件，跑测试，再根据结果继续改。团队现在要面对的问题变成了：要给它多大的自主权。

有人把这个方向叫“软件工厂”。人给目标，Agent 拆任务、写代码、验证结果。多个 Agent 分工以后，一条自动化开发流水线就有了轮廓。

这个画面很诱人。它也很容易失控。

“

原文来源：Latent.Space: AIEWF Daily Dispatch

Agentic Loop 是一套反馈循环

Agentic Loop 做的事并不神秘。

它观察当前状态，制定下一步计划，调用工具，修改文件，运行测试，读取结果，然后继续下一轮。

工程师平时也这样写代码。你改一点，跑一下，看报错，再改一点。Agentic Loop 想把这段重复劳动交给模型和工具。

这部分价值很清楚。开发里有大量细碎循环：修类型错误，补单测，看 CI 日志，处理 lint，改一个边界条件。Agent 如果能稳定接住这些活，工程师能少消耗很多注意力。

循环本身不代表可靠。一个没有边界的循环，会把错误放大得更快。它可能连续改十轮，最后把代码库带到一个没人愿意接手的状态。

软件工厂需要刹车

支持 Agentic Loop 的人看到了一个趋势：工程师会从“写代码的人”变成“调度代码生成过程的人”。

你写清楚目标、约束、验收标准。Agent 执行。人类在关键节点检查。

这个模式会继续发展。Anthropic 相关讨论里提到的 Claude Tag，也在靠近这种异步委托形态。它不像聊天框里的助手，更像一个能长期跟进某段上下文的工程参与者。

但软件工厂难在控制。

传统工厂有工序、质检、权限和停机按钮。Agentic Loop 进生产环境前，也要有这些东西。否则团队得到的不是软件工厂，而是一个会自动提交代码的黑盒脚本。

团队缺的是控制层

很多团队现在这样用 Agent：

• 给一个大目标
• 塞很多上下文
• 打开工具权限
• 等它跑完
• 人工看结果

这个流程在 demo 里好看。放进真实代码库，风险马上出现。

Agent 从读代码走到改代码后，团队就要把它当执行者治理。它如果还能写数据库、调内部接口、发 PR、触发部署，风险会再上一级。

团队至少要回答这些问题：

• Agent 能读哪些目录？
• Agent 能改哪些文件？
• 哪些命令可以自动跑？
• 哪些操作需要人确认？
• 跑几轮失败后必须停？
• 每一轮改动怎么追踪？
• 出问题后谁接手，怎么回滚？

模型能力还会提升，控制层不会自己长出来。团队需要把权限、日志、验证、接管写进流程。

成本会筛掉一批幻想

Agent 跑循环会花钱。

一次任务里，它会反复读文件、请求模型、跑命令、总结上下文。一个人类看一眼就能定位的问题，Agent 可能转十几轮还在试。

团队需要算一笔账：这次自动化省下了人工，还是把人工成本换成了 token 成本。

Latent.Space 那篇提到，越来越多团队已经把 token 使用量当成生产指标看，而且权重很高。这个变化说明 AI 工程开始进入算账阶段。

早期团队只关心能不能跑通。现在团队还要看质量、延迟、失败率、返工成本和代码债。

一个 Agent 如果 80% 的任务能做对，但剩下 20% 需要工程师花两倍时间排雷，它没有真正提高效率。

AI 写得越快，团队越要守住代码库

我现在最警惕的不是 AI 写不出代码，而是它太能写。

它能快速补一堆胶水代码，也能为了让测试通过绕开原来的设计。短期看功能动了，长期看没人知道那段逻辑为什么存在。

代码库不靠产量保持健康。团队要有清晰的模块边界、测试标准、review 习惯和 ownership。缺少这些东西，Agent 只会把混乱加速。

AI 适合做 demo，也适合做局部修补。团队把它带进 production 时，仍然要靠工程纪律。

AI 可以写代码。团队必须定义什么代码值得留下。

先做小循环

我不建议团队一开始就追全自动软件工厂。

更稳的做法是把 Agent 放进小循环，让它处理边界清楚、容易验证、失败可控的任务。

可以先从这些地方试：

• 修 lint
• 补单测
• 根据失败测试生成候选 patch
• 根据 PR diff 写变更说明
• 根据 issue 草拟排查计划
• 在沙箱里跑有限验证
• 对低风险模块做机械改动

这类任务不会让 Agent 一上来接管核心业务。团队能看清它在哪些环节可靠，在哪些环节需要人接手。

小循环跑稳以后，再扩大权限。

AI Native 公司会改流程

Garry Tan 在 closing keynote 里提到一个说法：增长快的公司会把 AI 当 workforce。

这句话不能理解成“公司接了一个 AI API”。很多团队已经开了 Copilot，也在产品里加了聊天功能，但流程还没变。

更深的变化发生在工程系统里。

团队要重新设计任务拆解、代码组织、文档写法、测试入口、权限分层和 CI 输出。Agent 能不能干活，很大程度取决于这些系统给不给它明确的路。

一个聊天框不会让团队变成 AI Native。工程流程适配 AI 后，Agent 才能稳定参与开发。

我会这样落地

如果今天让我在团队里试 Agentic Loop，我会先定五条规则。

1. 从低风险任务开始

先让 Agent 做单测补齐、文档同步、lint 修复、依赖升级说明。失败了也容易回滚，人也容易检查。

2. 给 Agent 设置退出条件

最多跑几轮，哪些错误要停，停下来要输出什么。比如测试连续失败 3 轮后暂停，并说明它改过哪些文件、看到哪些错误。

3. 权限分层

读代码、改代码、跑命令、发 PR、部署，分成不同权限。新 Agent 先拿最小权限。

4. 留下 trace

Agent 每一步都要留下记录。它为什么改这个文件，跑了什么命令，看到什么错误，下一步为什么这样做，都要能查。

5. 同时看成功率和成本

团队不能只看任务是否完成。单次任务花了多少钱、用了多久、是否需要人工返工，也要进报表。

AI早咖啡观点

Agentic Loop 会成为软件工程的新自动化层。

它能把重复反馈循环交给模型和工具。团队要为它设计边界、权限、验证和接管机制。

未来的软件工程师不会退回纯手写代码。更值钱的能力会变成：

• 把任务拆到 Agent 能稳定执行
• 给模型提供刚好够用的上下文
• 设计能验收结果的测试和指标
• 控制权限和成本
• 在 Agent 失败时接管现场

AI 编程的下一阶段，不比谁生成代码更多。

团队要比的是工程闭环质量。谁能把 Agent 放进一个可控、可测、可回滚的系统里，谁才能吃到这波红利。