AI 编程助手已经越过补全代码阶段。它能读报错，改文件，跑测试，再根据结果继续改。团队现在要面对的问题变成了：要给它多大的自主权。有人把这个方向叫“软件工厂”。人给目标，Agent 拆任务、写代码、验证结果。多个 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 放进一个可控、可测、可回滚的系统里，谁才能吃到这波红利。