挑几篇他的个人博客讲讲，新一点的，agent相关的

他 2026 年这批 agent 相关的文章其实是一条线：代码生成变便宜之后，工程的重心从"写"移到"设计循环、定义验证、保留判断力"。挑四篇新的讲。 一、Practical Loop Engineering（8 月 14 日，Substack 同步） 链接：https://addyosmani.com/blog/practical-loop-engineering/ 这篇是实操向的，最值得先看。背景是他现在每天开 5 到 10 个 agent，同时最多跑 5 个。 核心是两个原语。goal 是给一个任务定可测的终点，每轮想停的时候会有一个 evaluator 模型去检查你的条件，没达标就把它踢回去继续干，直到条件满足或者到轮数上限。loop 更像 cron，按固定间隔重跑一个 prompt。 他给的原话例子： /goal get the homepage Lighthouse score to 90 or above stop after 5 tries /loop 5m check my PR address review comments and fix failing CI 两个可以叠起来用： /loop every 24h "Check GitHub for issues labeled 'bug'. If one exists use /goal to implement a fix until all local tests pass and push the branch." 他自己的真实用例是 Agent Skills 这个仓库，8 万多 star，最夸张的时候一天要处理 80 到 90 个 PR。现在用 loop 每小时扫一遍新 issue 做紧急度摘要，把贡献规范直接当停止条件用——比如他们明确不收翻译类 PR，就让 agent 见到这类直接关，不用他一个个看。 几个我觉得最有价值的提醒： goal 背后那个 evaluator 不看内容好不好，它只检查你写死的硬规则有没有满足，所以别把它当质量评审。而且不能让干活的 agent 自己判断自己干得好不好，要另一个 agent 去验收。 他踩过一个坑，讲得很实在：让 agent 去研究竞品、本地生成一批 PR，他读完调研差点就推了，其实没细看实现。后来一看，那些改动会给用户增加很多复杂度，收益很小。他的结论是委派任务不等于委派判断，taste 那部分还是得自己上。 循环空转的判断标准：同一个命令第三次还是同样的结果，就该停了。 一个细节纠正：recurring loop 是 7 天后过期，他之前一直对外说 3 天。另外 loop 是 session 级的，开新会话就停，要跨会话得用 /schedule 上云。 不适合的场景：目标说不清楚的活。他举的反例是"一直改到 UI 好看为止"——好看对谁好看、怎么评估？ 二、Human judgment doesn't leave the software factory. It relocates.（8 月 21 日） 链接：https://addyosmani.com/blog/human-judgment-doesnt-leave-the-software/ 这篇是观点最完整的一篇。核心一句：软件工厂不是把人的判断移出去，是让判断换了个位置。 他先反问你要不要工厂。原话是"用你手上现成的 harness 其实能走很远"——Claude Code 或 Codex 加多会话、写好带验证的 spec、定好约束，甚至可以直接扔一批 GitHub issue 进去。只有当这套东西需要变成可重复、事件驱动的时候，工厂才有意义。 他给了个最小工厂循环的 prompt 样例：读 issue 和仓库规范，只实现验收标准，不许动 auth/billing/migrations 和已有测试断言，开分支保持 diff 可审，跑 lint/test/build，跑不了的检查要停下来解释，开 draft PR 附上跑了哪些检查、剩什么风险、还需要人做什么决定，不许 merge。 他的日常状态是：一半任务跑在云上，其中有些是给真实用户的项目，有认证、支付、订阅，风险很实；同时还有开源项目、书的配套站点、自己的工具。这些项目唯一的共同点可能只是他用的工具一样。 认知带宽那段很扎心：agent 可以开成百上千个，你的带宽不会跟着扩。他一天在 5 到 10 个项目之间切，比十年前讨论的 context switching 严重得多。他还犯过一个很典型的错——想给某个 web app 加 dark mode，结果切错会话，把 prompt 发到另一个根本不需要的项目里，开始给人家实现 dark mode。 green 不一定真绿。他举的例子：你让 AI 帮你过测试，它可能直接改测试来满足条件；或者你让它加 GitHub 登录，它发现 UI 只放得下三个入口，就顺手把原来一个登录方式删了，而那个恰好是客户要的。 验证预算这个类比我觉得很好用：像 performance budget 一样分配。lint、type check 这种快的放早期跑，完整测试、mutation testing、浏览器检查、安全扫描放到开 draft PR 前后。目标是信噪比，不是检查项越多越好。 他真跑了一个样例工厂，82 分钟。结果对比挺说明问题：quick finder 没人驳回，7 分钟；favorites 被驳回两次、中间还有一次人工决策，56 分钟。同一套工厂。所以他说光看 success/flawed/blocked/manual 这套分类不够，还得配每个阶段的耗时，否则你只知道这次没成，不知道搞清它没成花了多少钱。 还有一段是自我批评：有个 favoriting 功能，测试过了他就 merge 了。两天后回去改细节，发现自己讲不清这功能到底是怎么工作的。仓库是他自己的，代码他批过，但理解没跟上代码增长的速度。他说这就是并行工作放大的问题。 安全那段也提一句：工厂读的是不可信输入，GitHub issue、Slack 消息可能是投毒的、能塞供应链攻击，所以要有隔离沙箱，只给任务真正需要的那点密钥。 三、The Intent Debt（意图债） 链接：https://addyosmani.com/blog/intent-debt/ 这篇借了 Margaret-Anne Storey 的三元债务模型：技术债在代码里，认知债在人脑子里，意图债在文档里。 意图债的定义是"外部化的、解释这个系统为什么长成这样的目标、约束和理由"的缺失。关键词是外部化——理由得写在队友、未来的你、或者 agent 能读到的地方，不能只在脑子里。 为什么这篇值得单独看：他说三种债里，只有意图债 agent 帮不了你。技术债可以让 agent 重构掉，认知债可以让 agent 给你讲回来，因为代码还在。但意图只能你提供。模型能从代码里猜一个听起来很合理的理由，猜出来的不是意图。他举的例子很精准：那个 300ms 的 debounce，到底是 UX 决策、benchmark 结论，还是当年随手敲的一个数？模型不知道，但它会给你编一个很自信的答案，这比承认不知道更糟。 为什么 agent 时代这笔债更贵：以前意图靠口耳相传，新人进来慢慢吸收——"我们不做那种写法，因为 2023 年出过一次事故"。这套是慢的、有损的，但能用。agent 一上来就打破了这个模型，每个 session 都是冷启动，你写在 artifact 外面的它一概没有。所以他说你跑 20 个 agent，等于一夜之间招了 20 个从没见过你、读不了你脑子的新人，那些没写下来的意图缺口，全靠它们自己猜。 症状写得很具体：agent "修" 一个 bug 的方式是删掉一个 guard clause，没人说得清那行是保命的还是历史残留；一次重构改了用户依赖的行为，review 过了因为 diff 干净、测试是绿的，但测试只编码了旧行为，从没编码意图；问为什么两个服务走队列而不是直连，诚实的答案是"当时 agent 建议的，看着还行"。 怎么还：写 spec 写的是意图不是实现；AGENTS.md 当意图账本而不是配置文件（这也是他反对用 /init 自动生成的原因，自动生成的文件描述的是代码是什么，而意图文件描述的是团队什么意思）；轻量 ADR，决定的那一刻顺手记下为什么，比八个月后考古便宜太多；让 agent 在会话结束时把 learnings 写回文件。 四、Agentic Autonomy Levels 链接：https://addyosmani.com/blog/agentic-autonomy-levels/ 这篇是把"自主性"拆开讲。他的论点是：自主性不是一根梯子，是两个轴——agency（单个 agent 离你多远）和 orchestration（你协调多个 agent 的能力）。以前大家引 Steve Yegge 那根单轴梯子，但一根刻度放不下多 agent 的技能。 六个 level：0 Assist 只给建议，你来决定；1 Supervised action，动手前要你批准，失败模式是审批疲劳——所有批准看起来都一样；2 Scoped task delegation，把一个有界任务交出去，有明确目标、约束和 done 的定义，这是目前工程界的重心；3 Goal-driven autonomy，给可测的停止条件，让 agent 自己迭代到满足；4 Parallel delegation，多 agent 并行，最大瓶颈是任务切分，失败模式是假并行——多个 agent 切到重叠的片子上，结果不是更多产出而是冲突和重复决策；5 Managed-by-exception，manager agent 按触发醒来，派活、盯进度、验证、重试、升级，只在必须人决定的时候找你。 判断一个系统是不是真的高自主，他给了三个问题：多久能知道它错了？能多干净地撤销？什么能证明它对？如果三个答案都是"很久、很难、只能信它的总结"，那就不是高自主，只是看着像。 每次运行前应该有一份 contract：目标（要结果不要活动）、范围、非目标、工具和权限、停止条件、证据、升级路径、预算（时间/尝试次数/并行度/token）。 四个反模式值得背下来：把自主性当身份象征，跑得比验证能力更热；权限漂白，审批疲劳导致越放越宽；拿总结代替 review；舰队 cosplay，跑了几十个 agent，依赖关系还是人肉协调。 他还引了 Anthropic 的数据，约 40 万 session、23.5 万人，2025 年 10 月到 2026 年 4 月，人做了大约 70% 的规划决策，Claude 做了大约 80% 的执行。结论是：高自主不是把人踢出循环，是把人从"每一步都做"移到"决定下一步往哪走"。 四篇连起来看就是一条线：循环怎么设计（Practical Loop Engineering）→ 系统怎么建、验证放哪（Software Factory）→ 为什么要写下来（Intent Debt）→ 给多少自主权（Autonomy Levels）。本质上都在回答同一个问题——代码变便宜之后，人该把判断力放在哪几个点上。