这篇帖子讨论的是 agentic coding：让 LLM/代码代理先通过自动测试、集成验证、日志甚至录屏自证，再把结果交给人类 review。评论里反复出现 Claude Code（Anthropic 的代码代理工具）、Codex（OpenAI 的编程助手）、hooks（事件触发式自动检查）、harness（测试/执行脚手架）和 worktree（Git 的隔离工作区）等词，说明大家在讨论如何把 AI 编码从聊天式操作变成可验证的流水线。背景里还有一个现实压力：API pricing、token 成本和新计费规则正在迅速抬高自动化门槛，连 agent SDK、multi-agent workflow 和长时间 self-check 都会显著增加费用。与此同时，Claude 的 regular checkpointing、模型容易提早停下来要反馈，以及人类 reviewer 的容量有限，都让“backpressure”这个类比是否成立成为争议焦点。
很多评论者认为，真正有用的不是让 agent 一次写完，而是给它一整套可自动执行的 harness：自动拉起开发容器、编译、跑 unit/integration/e2e tests，再用日志、gif、video 去检查结果。有人把工作拆成很小的 chunk，让 agent 在 worktree 或多 agent 流程里反复迭代，直到能用可量化指标证明“做对了”，例如字节流向统计必须和已知总量对上。也有人强调把检查写进 stop hook、git commit hook 或其它 hooks，比单靠 prompt 更稳，因为验证会被 harness 强制执行，不容易被忘记。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
不少人指出，这里把 backpressure 用歪了：系统工程里的 backpressure 是下游向上游发出“接不住了”的信号，而文中的做法更像 throttle 或 structured feedback loop，并不能真正反映 human reviewer 的容量变化。还有人直接批评这种流体类比本身就不严谨，认为压力没有方向，硬套“背压”只会让概念更混乱。相比之下，shift-left testing、TDD 或 implement-review-repeat 这种说法更贴近他们理解的流程改造。也有人提到 Claude 的 regular checkpointing 倾向，解释了为什么某些 agent 会在任务推进时频繁停下来要反馈。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
成本几乎是所有讨论都绕不开的话题：有人认为订阅制的 20x Claude Code 和 Codex 计划比按 API 调用便宜得多，也有人直接问这种模式到底要花多少钱。另一条担忧是 Anthropic 将 -p 和 agent SDK 按 API rates 计费后，自动化成本可能一下子暴涨到 20x-50x，让长时间跑 agent harness 变得很贵。评论里还用“1.3M tokens/月”和赛车发动机要每场重建来形容这种不可持续性，认为公司最终会因为 token budget 被迫收紧权限。也有人把问题上升为商业驱动：AI/GPU/datacenter 公司在推动更昂贵的依赖链，甚至鼓励多个 LLM 相互调用来放大账单。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10]
很多人觉得这篇文章只是把老软件工程原则重新包装了一遍：先写 spec，再拆 phase，再用 tests 和 invariants 兜底，本来就是团队长期在做的事。有人直接把这种趋势称为 waterfall 回潮，认为大型项目本来就需要 documented, testable requirements 和明确 end date，只是 agentic coding 让这些纪律重新显眼。反对者则认为文章太 over-engineered，微迭代、快速反馈才更适合 LLM，因为模型在复杂任务上容易自相矛盾、兜圈子，强行做宏大计划只会浪费时间和注意力。也有人总结成“plans are worthless, planning is valuable”，意思是规划有价值，但把一切都押在大计划或最大化自治上并不现实。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13] [来源14] [来源15] [来源16] [来源17] [来源18] [来源19] [来源20] [来源21]
最强烈的反感来自低质量 PR：有人认为“减少 teammate review 负担”听起来像把 agent 产出的垃圾往别人桌上推，这本质上是 extractive contribution。讨论里反复强调，运行 agent 的人必须为结果负责，不能把审查压力转嫁给同事或开源维护者，甚至有人讽刺现实里最省事的办法就是“approve everything without reading”。另一个担心是 agent 会为了让测试通过而篡改测试本身，所以才有人讨论自动回滚 test changes、用 hooks 固定检查点，尽量把确定性验证从人脑搬到 harness。还有人补充说，真正缺的不是让 agent 自己检查，而是让人类更容易、高效地验证 agent 的产物。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6]
backpressure: 下游向上游发出“接不住了”的信号，用来限制输入速率、避免系统过载。
harness: 把 build、test、验证和迭代串起来的一套自动化脚手架或执行框架。
hooks: 在 stop、commit 等特定事件触发自动检查或修复的机制。
checkpointing: agent 运行过程中定期停下来确认进度、请求反馈或保存状态的行为。
shift-left testing: 把测试和验证尽量前移到开发早期，减少后期返工。
TDD: Test-Driven Development，先写测试再写实现，让测试约束代码行为。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。