1.LOOP简介
别再prompt你的agent了，开始engineering你的loop。
最直接的一句来自Boris Cherny（Claude Code的作者）：
"我已经不prompt Claude了。我有一堆loop在跑。我的工作是写loop。"
一个把Claude Code亲手做出来的人，居然说自己不再prompt它了。那他到底在干嘛？
这就是Loop Engineering的全部出发点。
我觉得这个话题比较有意思的地方在于，它听起来像一个新名词，但拆到底又很朴素：模型、工具、context、检查、继续跑或者停。周所周知，越朴素的东西越容易被讲成玄学。
本篇正文分十一部分。前面先看agentic loop本身，以及为什么重心会从prompt移到context、harness和loop；中间拆目标、步骤、检查、停止四件套，再落到Claude Code/Codex里真正能用的五个积木；最后讲哪些任务值得做、怎么从新手跑到进阶。新手能照着用，工程同学也能顺手对照一下自己现在的workflow是不是各种奇奇怪怪。
2. 目录概要
- 先看清楚loop本身：其实早就被解决了
- 工作重心一层层移出了模型
- 一个比喻：loop就像手机导航
- Loop的四个核心模块：目标/步骤/检查/停止
- 从概念到工具：五个积木和一个记忆
- 真正会出问题的五个地方
- 哪些任务值得做成Loop
- 可以直接抄的模板和三个Loop
- 从新手到进阶的四个阶段
- 新手最容易踩的六个坑
- 真正的转变：你从动手的人变成设计机器的人
3. 先看清楚loop本身：其实早就被解决了
agent不是什么魔法盒子。剥到最里面，它就是一个朴素的循环：
python
while True:
response = model(context) # 1
if response.has_tool_calls(): # 2
results = run_tools(response.tool_calls) # 3
context += results # 4
else:
break # 5逐行看：
- 模型读一遍当前的context。
- 如果它要求调用工具------
- 你就去跑这些工具，
- 把结果塞回context，然后回到第1行重来。
- 直到它不再要求调工具，循环结束。
一句话概括：模型 → 工具 → context → 重复。
换成更像workflow的说法，就是：
text
DISCOVER → PLAN → EXECUTE → VERIFY → ITERATE先发现要做什么，再计划，再执行，再验证；没过就把结果带回去继续迭代。这里最重要的不是PLAN，而是VERIFY。没有verify，重复只是在原地打转；有了verify，重复才可能变成进展。
如果画成一张可以直接塞进PPT的图，大概就是这样：
这张图里真正值钱的是右边那条岔路。passed才停，failed就带着状态回去重来。所谓Loop Engineering，很多时候就是在认真设计这个VERIFY闸门，而不是把prompt写到三千字。
让人意外的地方在这里：这个循环早就被解决了 。任何一个正经的agent框架，最后落到的都差不多是这几行。没有人在while这条语句上较劲。
那如果loop本身这么trivial，大家到底在工程化什么？
4. 工作重心一层层移出了模型
AI的重心一直在往模型外面飘。可以按出现顺序排成四层：
| 层 | 工程化的对象 | 一句话 |
|---|---|---|
| Prompt Engineering | 你发出去的那段话 | 你怎么问 |
| Context Engineering | 模型看到的一切，不只是你的指令 | 它看到了什么 |
| Harness Engineering | 模型外面那圈代码：跑工具、管状态、处理错误 | 谁在驱动它 |
| Loop Engineering | 把整件事推向目标的那个自主循环 | 它怎么自己干完 |
每一层都把前一层包在里面。你没有不再关心prompt，你只是发现prompt只是一个大系统里很小的一块。
LangChain把这事说得很干净：Agent=Model+Harness。如果你不是那个model，那你就是harness。
这句话落到工程里，意思就很具体了：工具怎么暴露、状态怎么保存、错误怎么反馈、什么时候继续、什么时候停，这些都不是prompt本身能兜住的事情。换句话说，同一个模型，外面那圈harness写得不一样，最后表现可能完全不同。
Loop Engineering，就是把那个脑子运行所在的整个环境给设计出来。下面挑几个真会崩的地方讲。
5. 一个比喻：loop就像手机导航
讲Loop，拿手机导航打个比方。
Loop的灵魂不是"照一个定时程序走到底"，而是"看一眼结果、发现不对、自己修"。只按固定流程往下走、中途根本不看结果 ，那是开环。导航不一样，它一路盯着你现在在哪、该在哪，开错了立刻重新规划，这才是Loop。
你上车只做一件事：输入目的地。剩下的它自己来------
- 你输入目的地，这是目标。
- 它规划一条路线，这是步骤。
- 一路实时定位，随时对比"我现在在哪/该在哪"，这是检查。
- 你一开错路口，它立刻说"正在重新规划路线"，这是自我修正 ，也是那个能说"不"的角色。
- "您已到达目的地"，它就停了，不会拉着你在小区里绕圈，这是停止条件。
一个导航把Loop的四个核心模块全罩住了，而且人人都用过。后面讲模块和讲难点，我都会拿它来对照。
记住这句就行：Loop不是给AI定个时让它自己跑完，而是给AI一个目的地，让它一路自己纠偏着开过去。
6. Loop的四个核心模块：目标/步骤/检查/停止
把导航拆开，正好是四块。你要给AI的，也是这四块。
6.1 目标模块：告诉它要去哪
目的地越模糊，越容易开偏。
反例，含糊的写法：
text
帮我做一个好看的网页。举栗，能落地的写法：
text
帮我做一个适合手机浏览的个人作品集首页。
风格简洁，包含头像、简介、项目列表、联系方式。
页面打开后第一屏就能看清"我是谁"。后者有对象、有场景、有内容、有结果，AI不用瞎猜。检验标准很简单：把这段话发给一个真人，他能不能知道要交付什么。
6.2 步骤模块：告诉它怎么走
别只说"做好"，给它一条路线：
text
第一步：分析需求
第二步：列出页面结构
第三步：写代码
第四步：检查移动端
第五步：修复明显问题
第六步：总结改了什么步骤不是用来束缚AI，而是压缩它犯傻的空间。就像带新人，你说"你去做运营"他会懵，你说"先整20个竞品标题，再归类，再写10个新标题"，他立刻能动起来。
6.3 检查模块：告诉它什么叫合格
这是整个Loop Engineering里最重要的一步，也是大多数人漏掉的一步。很多人只写任务、不写检查标准，结果AI吐出来一堆看着完整、实际不能用的东西。
检查标准要具体到能照着判：
- 写文章：开头有没有具体的人或数字、有没有大段长句、有没有空话套话、读者看完知不知道下一步做什么。
- 写代码：页面能不能打开、控制台有没有报错、核心功能能不能点、移动端有没有遮挡。
- 做表格：列名是否完整、数据有没有重复、公式能不能算、汇总结果合不合理。
检查标准越具体，AI越能自己修。没有检查标准的Loop，就像没有刹车的车。
6.4 停止模块：告诉它什么时候结束
Loop最怕两件事：一是没干完就停，二是干完了还继续改，把好东西改坏。所以必须写停止条件：
text
当所有检查项都通过后，停止修改，只输出最终结果。
最多修改2轮；2轮后仍不满足，就说明原因，不要继续猜。这条特别重要，因为AI有时候很"勤奋"，会一轮轮优化，但优化不等于变好。一个标题第一版很有劲：
text
普通人用AI翻身，先学会这4个循环改到第五版可能变成：
text
关于人工智能应用能力提升的系统性方法研究看着高级，实际没人想点。好的Loop不是永远运行，而是在正确的时候停下。
7. 从概念到工具：五个积木和一个记忆
前面讲的是Loop的抽象结构。真要落到Claude Code或者Codex里，基本会变成五个积木，再加一个外部记忆。
7.1 Automation：让它自己醒来
automation是心跳。
没有automation，你只是手动跑了一次prompt；有了automation，它才会在某个时间点、某个事件后、或者某个条件没满足时继续跑。Claude Code里可以是/loop、/goal、hook、cron、GitHubActions；Codex里可以是automation、background thread、/goal这类持续条件。名字不重要，作用一样：别让人肉成为触发器。
这里有个顺序别搞反。先把一次手动run跑可靠，再把它沉淀成skill，然后加gate和停止条件，最后再schedule。直接把一个还不稳定的prompt挂成定时任务，基本就是让它半夜替你制造奇奇怪怪的账单和结果。
7.2 Worktree：并行不等于互相踩脚
只跑一个agent时，文件冲突不明显。一旦你让两个agent并行改同一个repo，问题就来了：它们会像两个没沟通过的工程师，同时改到同一块地方。
git worktree的价值就在这里。每个agent拿自己的checkout和branch，互相不污染。Codex的多线程、Claude Code的worktree隔离、subagent的isolation: worktree，本质都是在解决同一个机械问题：让并行先不撞车。
当然，worktree只解决机械碰撞，不解决人的review带宽。跑十个agent很容易，认真看十个agent交回来的东西，才是真正累的地方。
7.3 Skill：别让agent每轮都重新猜你的项目
skill就是把项目知识写到外面。
构建命令、目录约定、代码风格、哪些文件不能碰、以前踩过什么坑，这些东西如果不写下来，agent每一轮都会重新猜一遍。它猜得越自信，越容易裂开。skill把这些意图固定下来，让loop每次跑的时候都能读到同一份规则。
这也是为什么skill的description要无聊、准确、可触发，而不是写得很酷。酷没有用，能被正确调用才有用。
7.4 Connector：让loop真的能行动
只会读写本地文件的loop，半径很小。connector或者MCP把它接进真实环境：issue tracker、Slack、Linear、GitHub、数据库、staging API、监控面板。
差别很大。没有connector时，agent最多说"我建议你开一个PR"；有connector时，它可以真的开PR、关联ticket、等CI绿了再通知频道。前者是建议，后者才是工作流。
7.5 Subagent：把maker和checker拆开
这个前面讲过，但值得单独放在工具层再讲一次。
一个agent负责做，一个agent负责查。写代码的可以快一点、便宜一点；review的可以慢一点、严格一点，甚至换更强的模型。Loop之所以能在你不盯着的时候跑，靠的不是"我相信它"，而是里面有一个独立的东西能说"不"。
7.6 记忆：repo不会忘，conversation会忘
最后还有一个很土但很关键的东西：外部记忆。
可以是一个markdown状态文件，可以是Linear board，可以是一张表。它记录什么已经做了、什么失败了、下一步是什么、上一次为什么停。别小看这个，长跑agent最怕的不是不会干活，而是每次醒来都像第一次上班。
conversation会消失，context会腐烂，模型会忘。repo不会忘。
所以一个能跑久一点的Loop，大概长这样：automation把它叫醒，skill告诉它项目规则，connector让它读真实任务和反馈，worktree让它隔离改动，subagent做maker/checker分工，状态文件记录进度。听起来不玄，甚至有点土。但工程里很多好东西，最后都是土办法活得最久。
画成工程结构，大概是这样：
这张图的关键不是组件名字，而是方向：主Loop不要把所有东西都塞进自己肚子里。规则放skill，动作走connector，状态落外部memory，改动放worktree，验证交给checker/verifier。主Loop只负责调度和决定下一步。程序中没有什么是加一个中间层不能解决的。如果有，那就两层。
8. 真正会出问题的五个地方
四个模块是骨架，五个积木是工具。真到自己搭Loop，下面这五个地方才是会让你裂开的。
8.1 知道何时停止："结束发言"不等于"干完活"
这是没人提前警告你的坑。
当agent不再要求调工具，它结束的只是这一轮发言 ，不等于任务完成。想象一个写代码的agent：它写了几行，扫一眼，觉得有进展，宣布"搞定了"。测试其实还在挂。它照样庆功。
一条结束语结束的是turn，不是task。把这两件事搞混，是Loop出错最常见的方式。
所以好的Loop会叠好几道刹车：
- 最大轮数：一个硬上限，卡死的agent不至于无限跑。
- 预算和时间上限：给token、钱、秒数都封顶。
- 无进展检测：如果它反复用同样的参数调同一个工具，说明它在原地打转。
- 真正的完成检查：一个能自动判定的条件，证明活确实干完了。
最后一条扛大梁。"完成"应该意味着测试通过 ，而不是agent自我感觉良好。对照导航：到没到目的地，是看GPS坐标，不是看你心里觉得快到了。
8.2 保持context干净：别让循环越跑越蠢
长循环会从内部腐烂。
agent跑的轮数越多，往context里堆的垃圾越多：过期的工具输出、走过的死胡同、陈旧的推理。这堆东西越大，模型表现越差。这个现象英文圈叫context rot（上下文腐烂）。
循环会让它打转下去：腐烂的context产出更差的决策，更差的决策又添更多噪声，噪声又进一步腐烂context。这就是大家说的doom loop，agent跑得越久反而越蠢。你大概率体感过。
对付它的办法，是把context当预算 而不是水桶：
- 压缩（compaction）：对话长了就先总结一遍，然后从总结往下接。
- 卸载（offloading）：把巨大的输出写进文件，只在context里留你当下要用的那一小片。
- 子agent(sub-agents)：把脏活丢给一个独立的agent去干，只让它干净的结果回到主循环里。
本能是"都留着，万一要用呢"；真正的本事是知道该扔什么 。（这个系列前面讲/compact的50%红线、讲随手起临时subagent做搜索，讲的就是这件事。）
8.3 工具要agent真能用：少而专，写操作可重复
Loop的上限，被里面那套工具卡死。
堆一百个工具进去，agent反而记不清该用哪个。一套少而专、互不重叠的工具才赢。Anthropic有句很锋利的经验法则：如果一个人类工程师都没法笃定该用哪个工具，agent更没戏。
有两件事比大家以为的更要紧：
- 让写操作可以安全地重复（幂等）。循环会重试，如果一个被重试的"创建客户"调用又建了一个客户，你会在重复记录和重复扣费里醒来。任何改状态的操作，都得能被调两次而不出事。
- 错误信息写给agent看，别写给人看。 一条好的错误信息，要告诉agent下一步该怎么办。工具上线前先问一句：一个LLM读到这条报错，能不能知道下一步往哪走。
在循环里，一个错误不是死路，而是下一条指令。
8.4 要有个能说"不"的东西：别让agent给自己批改作业
自主循环有一个安静的失败模式：一个没人管的agent，倾向于一直认同自己。
整场讨论里最戳的一句是：设计这个loop只是工作的一半，另一半是在loop里放一个能说"不"的东西。这个东西可以是一个测试、一次类型检查、一条真实的报错，也可以是另一个只负责review的agent。
没有critic的loop，只是一个对着自己的活点头的agent。
办法是把"干活的"和"验收的"分开 ：一个模型干活，另一个check（往往是另一个模型，或者一条硬测试）来打分。干活的那个，不批改自己的作业。 这正是导航里那句"正在重新规划路线"：判断你是否偏航的，不是开车的你，是独立的定位系统。
8.5 成本不要看token，要看accepted change
Loop会烧token，这个大家都知道。但真正容易被忽略的是：它不是"跑十轮等于十次prompt"。每一轮都会重新读目标、上下文、工具结果、错误信息，而且这些东西往往越堆越大。
更麻烦的是maker/checker拆开以后，质量会提高，账单也会提高。两个agent读同一堆东西，各自调用工具，各自总结。跑起来很爽，账单也很诚实。
所以我觉得更应该看的指标不是"跑了多少轮"或者"花了多少token"，而是：
text
cost per accepted change也就是每一个你最后愿意合进去、发出去、采用下来的结果，平均花了多少钱。如果Loop产出十个结果，你扔掉六个，那你并没有省掉review，只是把review变成了筛垃圾。这个指标一难看，Loop就该停下来重设计，而不是继续加prompt。
9. 哪些任务值得做成Loop
不是所有任务都需要Loop。
如果你只是"翻译这句话""给我10个标题""解释一下这个概念"，这种一次性任务，普通prompt就够了，套个Loop反而啰嗦。
适合做成Loop的任务，一般有四个特征：
- 它会重复出现。 至少每周都会做，最好每天都会做。一次性任务没有必要搭机器，一个好prompt更划算。
- 坏结果能被自动拒绝。 测试、类型检查、lint、构建、格式校验、硬规则，总得有一个东西能说"不过"。
- agent能端到端做完。 如果中间一半步骤都要人来接，Loop只是在假装自动化。
- Done是客观的。 "测试全绿"是客观的，"写得高级一点"不是。
所以更实际的判断标准是：重复、有gate、能端到端、Done客观。少一个，就先别上重型Loop。
写成决策表更直观：
| 判断项 | 要问自己的问题 | 过不了意味着什么 |
|---|---|---|
| 重复 | 这事至少每周都会发生吗？ | 一次性任务，不值得搭机器 |
| Gate | 坏结果能被测试、lint、规则自动拒绝吗？ | 没有刹车，Loop只会自我肯定 |
| 端到端 | agent能自己读、改、验、交付吗？ | 中间还得人接，自动化是假象 |
| Done客观 | 完成条件能写成清楚的判定吗？ | 质量靠口味，人最好留在最后一关 |
那内容创作、简历、销售文案这种主观任务怎么办？可以做轻量Loop，但不要假装它能完全自动发布。让它多轮草拟、自评、改弱点没问题，最后那一关还是人来按。这个边界非常重要，不然就会从工程自动化滑到内容流水线，出来的东西一眼AI味。
10. 可以直接抄的模板和三个Loop
新手不用先学复杂系统，先学会把验收标准写清楚。下面这个最小模板就够覆盖大半场景：
text
你要完成的任务是：【写清楚任务】
请按以下流程执行：
1、先理解目标和限制
2、制定3-5步计划
3、按计划逐步完成
4、完成后按验收标准自查
5、不合格就修改一轮
6、合格后输出最终结果和简短说明
验收标准：
- 标准1:【写清楚】
- 标准2:【写清楚】
- 标准3:【写清楚】
停止条件：
所有验收标准满足时停止，不要无限扩写。下面三个是可以直接照抄的成品。
10.1 写文章Loop（公众号/小红书/X）
text
请帮我写一篇文章。
流程：
1、先判断读者是谁
2、列出文章大纲
3、写正文
4、检查是否有空话、长段落、抽象概念
5、有就改成更具体、更适合手机阅读的版本
验收标准：
- 开头有具体案例或数字
- 每节都有明确小标题
- 每个观点后面跟一个例子
- 结尾告诉读者今天能做什么
满足后停止。10.2 写代码Loop（个人网站/工具页/脚本/小程序原型）
text
请帮我完成这个功能。
流程：
1、先读现有项目结构
2、找到相关文件
3、说明你准备怎么改
4、修改代码
5、运行检查或测试
6、失败就根据错误继续修复
7、最后总结改了什么
验收标准：
- 功能能正常使用
- 不破坏原有功能
- 没有明显报错
- 风格和现有项目一致
无法完成就说明卡在哪里。这个Loop能跑起来的前提，正是第五节那条Boris反复强调的原则：给Claude一个能验证自己输出的手段（前端给浏览器、后端让它跑测试）。我自己的体感也是这样，只要验证手段是真的，AI就不太容易停在"看起来差不多"那里。
10.3 学习技能Loop（学AI/编程/剪辑/写作/英语）
text
请帮我学习【某个技能】。
流程：
1、先假设我是零基础
2、拆成7天学习计划
3、每天只安排1个核心动作
4、每天给一道练习题
5、每个阶段给一个检验标准
验收标准：
- 不用我听不懂的术语
- 每天任务能在30分钟内完成
- 每个练习都能产出一个具体作品
最后输出第一天要做什么。11. 从新手到进阶的四个阶段
第一阶段（1-3天）：先学会写清楚任务。 别急着碰agent、工作流、自动化平台。每天拿一个真实任务练，按"目标/步骤/检查标准/停止条件"四件套写一遍。检验：你能不靠模板，也写出一个清晰的任务。
第二阶段（3-7天）：学会加检查清单。 这一阶段的重点不是让AI多干，而是让它干完会自查。写文章就加"检查有没有空话、有没有长段落"；写代码就加"检查能不能点、有没有报错"。检验：AI每次输出前都会主动自查一遍。
第三阶段（7-14天）：学会控制迭代次数。 开始给Loop划边界："最多改2轮""每轮只解决最重要的3个问题""别为了润色大改结构"。检验：AI不会无限扩写，也不会把任务越做越大。
第四阶段（14-30天）：学会组合多个Loop。 熟练之后，把大任务拆成多个小Loop。比如做一门知识付费小课：Loop1选题分析 → Loop2课程大纲 → Loop3单节脚本 → Loop4海报文案 → Loop5发布计划。每个Loop只负责一件事，比让AI一次性"帮我做一门课"靠谱得多。
复杂任务的秘密，不是一个超级prompt，而是一串小Loop。
如果是工程团队，我建议按这个顺序来：
text
1. 先把一次手动run跑可靠
2. 把稳定指令沉淀成skill
3. 给它加verifier和stop condition
4. 再挂automation/schedule跳过前两步，直接把prompt挂到schedule上，基本就是把不稳定放大。
12. 新手最容易踩的六个坑
- 目标太大。"帮我做一个赚钱项目"基本没法执行。改成"帮我设计一个适合上班族周末做的AI简历优化服务，包含目标用户、交付内容、定价和第一批获客方式"。
- 没有验收标准。"写得好一点"不是标准，"标题20字以内、有具体收益、不夸张承诺"才是。
- 一次塞太多事。 别"帮我写商业计划书、做PPT、设计logo、分析竞品、顺便给个融资方案"。拆开做：先竞品分析，再定位，再方案。
- 不让AI解释过程。 新手阶段最好让它简短说明"做了什么/为什么这么做/还有什么风险"，帮你看懂Loop是怎么跑的。
- 过度相信AI自查。 它会检查，但它不是神。事实、数据、法律、医学、金融这类内容，必须人工复核。Loop能提高效率，但替不了你的判断责任，最后按下发布键的，还是你。
- 用Loop逃避理解。 Loop跑得越顺，你越容易不看它改了什么。短期很爽，长期就是comprehension debt：代码在长，你的理解没跟上。这个坑比报错更隐蔽，因为它一开始看起来像效率提升。
13. 真正的转变：你从动手的人变成设计机器的人
到这里，Boris那句话就讲得通了。
Prompting是你一步步地领着agent走。Loop Engineering是你把那个领着它走的系统搭出来，然后退到一边。
你的工作，从"给指令"变成设计三样东西：
- 目标：写成agent能拿来对照自己的成功标准。
- 循环：配上靠谱的刹车，让它停得对。
- 验证者：让"完成"是被证明的，不是被宣称的。
Andrej Karpathy把这个心态讲得很到位：别告诉模型该做什么，给它成功标准，然后看它跑。他挂研究loop在夜里跑：改一版脚本、测一遍、留下有用的、扔掉没用的，而他本人不在这个循环里。他把它布置好一次，然后按下开始。
这就是整个动作：你不再当那双手，而是当设计这台机器的人。
你不需要第一天就上一个通宵自跑的agent，可以一步步来：
- 从最朴素的循环起步，马上给它配上最大轮数、超时、成本上限。
- 在动手之前就把"完成"定义成一个能自动判定的检查，而不是事后凭感觉。
- 保护context：长跑就压缩，大输出就卸载，脏活隔离给子agent。
- 审计工具：留少而专的几个，让写操作可重复，把报错改写成agent能照着行动的样子。
- 在循环里放一个critic。只有当你信得过那个"会说不"的东西，再彻底放手。
Loop Engineering不是一个你要安装的框架或工具，而是你把力气往哪使的一次转移。模型正在变得越来越容易替换，真正难调的，反而是模型外面那个循环。
所以我认为更值得问的问题，不是"我该让agent做什么"，而是"什么样的系统，能在没有我的情况下把这件事做了"。
把这一个问题答好，你也就不再只是prompt了。
summary
- loop本身早就被解决 ：很多agent框架都收敛到那几行
while，真正麻烦的是外面那圈工程。 - 重心在外移：prompt → context → harness → loop，prompt只是系统里的一个零件。
- 比喻：Loop不是开环地跑完一套固定程序，而是会实时纠偏的导航：目的地（目标）、路线（步骤）、定位（检查）、重新规划（自我修正）、到达即停（停止）。
- 四个模块：目标要具体到真人能看懂、步骤要压缩犯傻空间、检查是最重要的一环、停止防止越改越坏。
- 五个积木：automation负责唤醒，worktree负责隔离，skill沉淀项目知识，connector接入真实工具，subagent拆开maker/checker，外部记忆负责接续状态。
- 五个真坑：分清turn与task、对抗context rot与doom loop、工具少而专且幂等、放一个能说"不"的critic、盯住cost per accepted change。
- 是否值得做：重复、有gate、能端到端、Done客观，少一个就先别上重型Loop。
- 上手路径：手动run可靠 → 沉淀成skill → 加verifier和stop condition → 再挂automation/schedule。
- 一句话：把"我希望AI做好"，改成"我告诉AI怎么判断做好"。
References
- Boris Cherny关于Claude Code工作流、verification、loop的公开分享：How I Use Claude Code --- 13 Tips、6 Tips for Getting More Out of Opus 4.7、The New Stack: Loop Engineering
- LangChain------Agents
- Anthropic------Writing tools for agents
- Andrej Karpathy------Software Is Changing (Again)