首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >不再写 Prompt,改写 Loop

不再写 Prompt,改写 Loop

作者头像
用户10097875
发布2026-06-25 16:12:28
发布2026-06-25 16:12:28
1850
举报

点击上方 「模型之外的事」 蓝字,关注并星标。以后这类 AI 落地 / 工程化 / 受监管行业选型 的长文,会第一时间出现在你的订阅里。

2026 年 3 月,Karpathy 上了 No Priors 播客,谈到 AutoResearch 和他所说的"loopy era"。核心意思不是"多写几个 prompt",而是把实验流程设计成可以连续运行:agent 自己改代码、跑实验、看指标、决定下一轮,人不再做每一步的中转站。

一个多月后,他在 Sequoia Ascent 2026 的摘要里又强调了另一面:

"You need to treat them as tools and stay in touch with what they are doing."

也就是:不要把自己变成每一步的瓶颈,但也别从系统里消失。

同一个人,在两种语境里,说了两种看似相反的态度。他矛盾了吗?

如果你觉得他前后矛盾——那说明 loop 这个词,你还没真正理解它有几层意思。这篇文章,就从解这个矛盾开始。

一、Loop 不是一个词,是三层结构

在往深里走之前,先把概念对齐。因为 Karpathy 说的、Anthropic 说的、Boris Cherny 说的"loop"——表面上同一个词,实际上指的是三件不同层次的事。

执行 Loop:agent 在单次任务里的运作单元。Anthropic 的 Claude Agent SDK 官方文档给过最工整的定义——接收 prompt → 评估响应 → 执行工具 → 结果回送 → 重复,直至仅有文本回复为止(终止信号)。这是最基础的那层,是绝大多数人说"agent 在跑"时指的东西。

改进 Loop:eval → 改 harness → 再部署 → 再 eval。这是 Karpathy 用 AutoResearch 展示的那层:agent 不停地修改代码、运行实验、评估结果、决定保留或丢弃,继续下一轮——没有人在中间做中继站。人在这里的工作,是在 loop 开始之前设好目标和 Boundary,在 loop 结束之后看 eval 汇总。

递归 Loop:AI 写 AI、AI 改 AI。Dario Amodei 在个人博客里写了一句话:"This feedback loop is gathering steam month by month." 这是第三层——Anthropic 在做实验,但大多数人还没进入这个层次。

Loop 层次

是什么

谁在说

人的位置

执行 Loop

单次任务内的 tool call 循环

Anthropic SDK 官方文档

监督,设边界

改进 Loop

eval → 改 harness → 再测

Karpathy AutoResearch;Boris Cherny

设计者,不是中继

递归 Loop

AI 写 AI / AI 改 AI

Dario Amodei

尚在实验室

现在回到那个矛盾:Karpathy 说"把自己移出去"——他在说改进 Loop;他说"还是要在里面"——他在说执行 Loop 层面的监督。矛盾消解了——他说的不是同一层 loop。

二、为什么"Loop"现在成了核心词

我先讲三个让我觉得这是范式转移——而不是技巧升级——的理由。

第一,Karpathy 的时间线

他在 Sequoia Ascent 2026 摘要里,把 2025 年 12 月前后描述成 agentic workflow 的明显转折:生成的代码块变得更大、更连贯、更可靠,他开始把更多工作交给 agent。这不是单次 prompt 变强了,而是 loop 的可靠性越过了某条线,人才能真的退后一步。

第二,Anthropic 的实测数据

Anthropic 的《Measuring AI Agent Autonomy》研究报告里有两个数字值得反复读:Claude Code 99.9th percentile 任务时长,从 2025 年 9 月的不足 25 分钟,增长到 2026 年 1 月的超过 45 分钟——3 个月翻了接近一倍;平均每次对话人工干预次数从 5.4 次降到 3.3 次。Loop 在变长,人在被移出。

另一篇 Anthropic 工程 blog《How We Contain Claude》把问题讲得更工程化:Claude Code auto mode 会把命令审批交给模型分类器,以减少摩擦;官方脚注给出的边界是,约 0.4% 的正常命令会被误拦,同时仍会漏过约 17% 的过激行为。这说明 Human-in-the-loop 不能只靠每一步点确认——有效监督要落在权限、隔离、预算、日志和可截停点上。

第三,词语被正式命名

2026 年 6 月 7 日,Addy Osmani 在博客上命名了"Loop Engineering"这个词。他转引了 Boris Cherny(Anthropic Claude Code 负责人)在 X 上发的一段话:

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

注意 Boris Cherny 的职位:他是 Anthropic 内部 Claude Code 的负责人,不是外部布道师。这句话说出口——意味着 Anthropic 内部的最高级别工程师,已经不是"提示 AI"的人,而是"设计让 AI 运转的系统"的人。

从"调用 AI"到"设计让 AI 运转的系统"——这是范式转移,不是技巧升级。

有人会说:传统 ETL pipeline、工作流引擎(Airflow/Luigi)早就是 loop,工程师一直在写 loop,有什么新鲜的?这个反驳值得正面回应。传统 loop 和 LLM loop 的本质差别在 Karpathy 那句话里:传统 loop 自动化的是你能 specify 的规则——路径已知,系统沿路走;LLM loop 自动化的是你能 verify 的目标——路径未知,系统自己找,你只需要判断"到没到"。凡是规则写不完整、路径需要推理、目标清晰但方法模糊的任务,LLM loop 才有意义,传统 loop 在那里只能报错或硬编码例外。

三、好的 Loop 长什么样

Karpathy 在 YC 的 Software 3.0 演讲里说过一句话,我觉得是理解 loop 最重要的一把钥匙:

"Traditional software automates what you can specify. LLMs and reinforcement learning automate what you can verify."

"可 specify"和"可 verify"——这两个词的区别,决定了一个 loop 能不能自主运行。旧软件的逻辑:把规则写死,机器执行,规则不完整机器就出错。LLM 的逻辑:给定目标和评估标准,让 AI 自己找路走。只要你能判断"走到了吗",AI 就能在 loop 里不断逼近答案。

可验证性,是 loop 自主性的天花板。

Karpathy 说得直接:"if you can't evaluate it, you can't auto research it." 他的 AutoResearch 就是这个逻辑的极端实践。你可以从中提炼出好的 loop 的五个要素:

Objective——这个 loop 在优化什么?

Metric——怎么量?AutoResearch README 里用的是 val_bpb,低一点就是更好,客观、可对比、可回溯。

Boundary——什么时候停?AutoResearch 的训练实验固定 5 分钟 wall-clock 预算。

Worker loop——谁在跑?agent 修改代码 → 运行实验 → 评估 → 保留或丢弃 → 进入下一轮。

Result review——谁来看结果?人看实验日志和 eval 汇总,不再盯着每一步中间动作。

AutoResearch README 给出的估算是:固定 5 分钟一次实验,大约 12 次实验 / 小时,睡一觉可以跑出约 100 次实验。这不是因为用了更好的模型——是因为 loop 结构让错误可测量、让迭代可持续。

三层 Loop 结构拆解:执行Loop / 改进Loop / 递归Loop
三层 Loop 结构拆解:执行Loop / 改进Loop / 递归Loop

Anthropic 自己的研究也佐证了这个逻辑:在最复杂的任务上,Claude 主动要求澄清的频率是简单任务的两倍以上。它在判断:"这个节点,我需要更多信息才能继续。"这不是谦虚——是好的 loop 在执行 Boundary 条件,而不是强行往下跑。

我的判断:Eval 不是可选项,是 loop 的点火装置。没有 metric 的 loop,只是快速堆幻觉的机器——跑得越快,幻觉堆得越多。

四、人应该在 Loop 的哪里

这是传统行业从业者问得最多的问题,也是最容易被两个极端带跑偏的问题。一个极端:每一步都要人审批。另一个极端:让 agent 完全自主。

位置

描述

适用场景

关键判断

Human IN

每一步都审批

新手期 / 高风险不可逆操作

逐步审批不等于有效监督,高风险不可逆操作仍要人工确认

Human ON

监测 + 必要时截停

大多数生产场景(正确答案)

40%+ 会话开启全自动模式,但中断率从 5% 升到 9%

Human OUT

无人介入,agent 自主

任务有硬性客观标准、可回溯、边界清晰

Karpathy AutoResearch;前提极苛刻

人应该在 Loop 的哪里:IN / ON / OUT 三个位置对比
人应该在 Loop 的哪里:IN / ON / OUT 三个位置对比

Amanda Askell(Anthropic)在一篇访谈里说过一句值得记住的话:"As models are more autonomous, suddenly they have a lot more decision points that you have to map out and make work well in advance."

注意"in advance"——人工介入点要提前设计,不是临时救火。提前设计和临时救火有本质区别:临时救火是"出问题了,人来接手";提前设计是"我在画 loop 架构的时候,就把'这里需要人判断'写进了 loop 的结构里"。等 loop 跑起来再想这个问题,已经晚了。

我的判断:大多数企业项目的正确答案是第二级(Human ON),不是第三级(Human OUT)。第三级不是目标,是工具,而且是有严苛前提条件的工具。

这里有一个反常识的结论,我想明确说出来:

反常识

合规要求 / 审计节点,是 loop 设计的坐标轴,不是障碍。

当监管要求某个决策必须有人签字,它实际上是在告诉你——这个节点的 Boundary 条件是"人工确认",这个节点的 metric 是"人签没签字"。这不是给 loop 加阻力——是帮你把 loop 的 Boundary 画清楚了。医疗、金融、保险、政务——这些行业的合规体系,当规则定义清晰时,是 loop 设计图里最精确的那几条线。哪里必须有人,哪里可以自动,监管已经帮你做了大量决策。用好这张图,不要对抗它。

当然,这有一个前提:合规规则本身定义清晰。现实里规则常常模糊或滞后——遇到这种情况,先做规则精化,再谈 loop 设计。把一个模糊的 Boundary 条件固化进 loop,只会把问题埋得更深。

五、Loop 断在哪里,项目死在哪里

知道了 loop 怎么设计,接下来是工程现实:大多数 AI 项目的 loop,断在哪里?

断点一:没有 Eval

没有 metric,loop 跑得再快也是方向不明。Karpathy 说"无法 evaluate 的就无法 auto research"——这话翻译成工程实践就是:在你有可测量的 eval 之前,不要让 loop 自主跑。先把 eval 搭起来,再谈 loop 自主化。顺序不能颠倒。

断点二:Boundary 失控

Anthropic 的 Claude Code Agent SDK 文档(code.claude.com/docs/en/agent-sdk/agent-loop,截至本文查阅时)里有一条很低调的说明:max_turns(最大工具调用轮次)和 max_budget_usd(最大预算)默认都没有上限不设上限会怎样——一个开放式 prompt 会持续吃 turn、吃上下文、吃预算;一个跑偏的 loop 可以一夜产生不必要的成本,这不是理论风险。

断点三:人工接管点设计错误

两种错误方向:

在不该批的地方要求审批——把速度杀死,让 loop 退化成人工逐步确认的工具。如果审批只是例行点确认,没有真实 review,那这个"审批"不如改成权限、预算和日志层面的自动护栏。

在该截停的地方放行——让不可逆的决策通过了 loop,发现问题时已经难以修复。Anthropic 的 Auto Mode 是工程层面尝试解决这个问题的方案(数据来自《How We Contain Claude》工程 blog):拦截约 83% 的过激行为,误拦约 0.4% 的正常操作。这是工程权衡——没有完美答案,只有在拦截率和误拦率之间找平衡。

断点四:改进 Loop 不闭合

这是最隐蔽的断点。执行 Loop 跑完了,任务完成了。然后呢?eval 数据存哪了?谁在看?谁在用这些数据改下一个 loop 的 harness 和边界?Anthropic 的 harness 工程指南对此有明确要求:每次 session 末必须更新 progress 文件和 git commit。这条要求看起来像工程洁癖,实际上是改进 Loop 能不能形成飞轮的前提。没有数据沉淀,你每次 loop 都在从零开始——无论执行 Loop 跑得多快。

六、三个冷静的提醒

提醒一:loop 不是每个场景都适用

Karpathy 在 Sequoia 演讲里说了:AI 在可形式化验证的领域(代码、数学、棋类)超人;在"去洗车"类不可验证场景下会出错。AutoResearch 能成立,是因为"哪个超参数更好"有一个客观的 eval metric。你的业务场景有这个 metric 吗?先问这个问题——比问"用哪个 agent 框架"重要得多。

提醒二:Anthropic 的数字是自报数据

本文引用的部分 Anthropic 数字(任务时长翻倍、Auto Mode 拦截率等)来自官方报告,是 Anthropic 内部测量的结果,未经独立第三方完整复现。方向性参考可信;具体数字,在自己的场景验证之前,保持保留态度。

提醒三:Loop Engineering 是设计挑战,不是工具替换

有一种危险的简化是:把"loop engineering"理解成"我去找一个能帮我自动建 loop 的工具"。Boris Cherny 说的"我的工作是写 loop",不是"我找了一个工具来帮我写 loop"——是他在做架构设计,在定义目标、Boundary、eval、干预点。这是设计工作,不是工具采购。

今天就做的一件事

找你现在最想让 AI 帮你自动化的一个工作流,在纸上画出这个流程,然后问自己一个问题:

这件事,我能不能在 10 分钟内判断 AI 做得对不对?

如果答案是"能"——你有了一个 loop 的 eval 基础,可以往下走。

如果答案是"不能"——先别急着谈 loop,先把你的评估标准定义清楚。

因为没有 eval 的 loop,不叫自动化。叫自动出错。

关注「模型之外的事」

进入一个带你解读 AI 落地、模型治理与产业真实约束的频道。

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-06-23,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 模型之外的事 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、Loop 不是一个词,是三层结构
  • 二、为什么"Loop"现在成了核心词
  • 三、好的 Loop 长什么样
  • 四、人应该在 Loop 的哪里
  • 五、Loop 断在哪里,项目死在哪里
  • 六、三个冷静的提醒
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档