这几天 r/ClaudeAI 上有个帖子冲到了前排，标题很直白：I am done with this shit。发帖人转述了一段 X 上的吐槽：入职一家大公司半个月，spec、代码、测试、PRD、ticket、周报全是 Claude Code 生成的，从 L1 到 L7 每天做同一件事，跟 Claude 对话，一天 12 到 13 个小时，主要动作是按 Enter。管理层反复问的只有一句：“写代码已经不是瓶颈了，为什么还这么慢？”

评论很快过了 800 条。吐槽 AI 的不少，但有一个判断几乎没人反对：这不是 AI 的问题，是管理的问题。 同样的 Claude，在另一些团队里让工程师睡得更好、做得更多。那么反过来问一句：AI 时代，什么样的管理层才配领导卓越的工程师？

最近几天，Graphite 一口气合了十几个 PR。Cross-graph Search、Large Corpus Gate、Topology OOM、Query Budget、Parallel Search、Memory、Cancellation、Timeout，几乎都在做性能优化和 Benchmark。

一开始看得很爽。发现一个慢 Query，Agent 找到 Hot Path，改实现、补测试、跑 Benchmark，然后交出 36 倍甚至 87 万倍的提升。以前要折腾几天的 Performance Optimization，现在几个小时就能跑完一轮。

但 PR 越合越多，越看越觉得不对劲：为什么每个“优化完成”后面，都紧跟着另一个 PR 补 Benchmark？Graphite 每个主要模块的 Unit Test Line Coverage 门槛已经是 98%，到底还有什么没测到？

相信所有把长任务交给 Agent 的人，都有过这样的经历：睡觉前把任务交给 Agent，期待它趁人休息时继续推进。第二天醒来，Agent 早就停了，却留下一份煞有介事的总结：任务已经完成。打开代码一看，连 10% 都没做完。

问题不只在模型偷懒。普通 Agent 默认只管这一轮回答，回答结束，它就把任务也算作结束。/goal 要解决的，是人离开以后，谁来检查原始目标到底完成没有，没完成又由谁启动下一轮。

过去一年，Agent 圈逐渐形成了一个共识：模型会商品化，Harness 才是壁垒。

这个判断有足够多的证据。相同模型接上不同的 context management、tool routing、memory、subagent、sandbox 和 approval，结果可以差很多。OpenAI 公布的一个例子很直接：在 ARC-AGI-3 上，保留 reasoning state 和压缩 context，把 GPT-5.6 Sol 的得分从 13.3% 提高到 38.3%，同时把 output token 降到六分之一。

既然 Harness 能制造这么大的差异，它自然应该成为 Agent 团队投入最多、最不愿交给厂商的一层。可就在大家开始谈 Harness Engineering 的时候，厂商也开始把 Harness 做成 SDK。

2023 年，OpenAI 的可用算力只有 0.2GW。2024 年升到 0.6GW，2025 年再到约 1.9GW。两年涨了 9.5 倍，仍然不够。2026 年 4 月，OpenAI 又把目标推到了 2030 年 30GW。

30GW 是 2025 年可用算力的近 16 倍。可就在这个目标公布四个月后，OpenAI 又签下 PORTS-Pike，一座规划容量约 8 IT-GW 的数据中心。

已经签了多少座数据中心，为什么还在继续签，这 8GW 放进 30GW 以后又算多大？

最近我一直在找下一批能把估值体系打穿的 high alpha。起点很俗：GEV 之后还有谁？SK hynix 之后还有谁？候选清单列了一长串，我扫到最后，发现里面没有 SpaceX。

SpaceX 未必应该进这张清单。可一套方法如果说不清它为什么被排除，给再多 ticker 也只是在排列答案。我没有急着把 SpaceX 塞回去，只追问了一句：它为什么不在？

SpaceX 这家公司有个毛病：太容易让人忘记自己是在做投资。一聊它，火星、星辰大海、人类多行星文明全来了。可在资本面前，情怀一文不值。把 mission 拿掉，SpaceX 留下的是一条很硬的成本曲线：launch cadence、reuse 和 $/kg。原来只能做一次的东西，能不能稳定、便宜、快速地做一百次，这才决定故事值多少钱。

前两天在 Martin Fowler 网站看到一篇文章。作者把同一批任务交给 Sonnet 4.6，一组要求严格按 TDD 做，一组随它写，再让 Opus 4.8 盲评。结果有点打脸：TDD 组没写得更好，Token 至少多烧 3 倍。看到这里，我第一反应不是 TDD 过时了，而是我们可能让 Agent 做了一件看起来很工程、其实很奇怪的事：自己出题，自己答题，再自己宣布通过。

前段时间我在用 Codex 的 /goal 推一个 side project。晚上把目标丢进去，早上起来看一眼，任务还在跑：读文档、拆模块、改 Kotlin、补 React、跑 ./gradlew :backend:check，失败了自己修，再继续。

我第一次有点恍惚，是看到它半夜还在沿着同一个目标往前滚。那一刻它不像一个聊天窗口，更像一个挂在 repo 里的无人值守工程队。于是那个问题就绕不过去了：如果 Codex 能不眠不休地推进项目，直到目标达成，还要工程师干什么？

硅谷发明新词的速度，已经快过 Agent 写代码的速度。Harness Engineering 还没捂热，前段时间 Addy Osmani 又发了一篇 《Loop Engineering》。

所谓 Loop Engineering，是把 automation、worktree、Skill、connector、sub-agent 和外部状态拼成一个闭环：系统自己找活、派活、执行、检查、记录，再进入下一轮。听起来很完整，零件也都能用。

原文其实没回避风险。Addy 明说 verification 仍然落在人身上，loop 跑偏会越挖越深。可这个名字依然危险：它把一种调度结构包装成了能力跃迁，仿佛把 Agent 塞进 while (true)，持续运行便会自然变成持续进步。

当然不会。Loop 能增加尝试次数，不能增加正确答案的密度。

Agentic Coding 最难的，从来不是让 Agent 继续跑。真正卡住它的，是每一轮结束后，谁能证明结果更接近正确。

想象一下这个场景：工程师把一次 Agent 任务从 10 万 Token 压到 4 万，仪表盘绿了六成。月底账单到了，云成本一分钱没少。公司租了 8 张 GPU，包月。模型少说了 6 万 Token，机器照样开着，合同照样付钱。

工程师优化出一大片空闲算力，财务却找不到一美元 Savings。Token Efficiency 的问题就这样暴露了：它从来不是一个孤立的技术指标，计费方式一变，财务含义就跟着变。