AI编程注意力瓶颈：小龙虾之父的Agent工作流实战

从Token到CPU，再到注意力的瓶颈转移

在一场颇具个人风格的分享中，OpenClaw（OpenCode 生态相关项目）的作者、人称"小龙虾之父"的 Peter，讲述了他过去一年在 AI 编程工作流上的演进思考。他用一句话概括了自己的处境变化：

"去年我被 token 限制，加入 OpenAI 后解决了；然后我被 CPU 限制；而现在，我真正的约束其实是注意力。"

这个观察极具代表性，背后有深刻的技术经济学逻辑。

Token 作为生产力瓶颈的技术根源

Token 作为 LLM 的计量单位，本质上是模型将文本切分后的最小语义单元。GPT-4 的 tiktoken 分词器中，一个英文单词平均对应 1.3 个 token，中文字符则通常以单字节或多字节形式切分，每个汉字约占 2-3 个 token。早期 OpenAI API 的严格速率限制（Rate Limit）和高昂的按 token 计费模式，使得 token 配额成为重度用户的真实生产力瓶颈——这不仅仅是成本问题，更涉及上下文窗口（Context Window）的物理限制：当时 GPT-4 的 8K token 上下文意味着你无法在单次对话中处理大型代码库，必须精心设计 prompt 压缩策略。而今随着模型推理成本持续下降（2023-2025 年间 GPT 级别模型的每百万 token 价格下降超过 95%），这一瓶颈正在快速消解。

Peter 所描述的从 token → CPU → 注意力的瓶颈转移，实际上是软件工程史上一个反复出现的规律：每当某类资源变得廉价，下一层稀缺资源就会浮现。1960年代计算机时代早期，内存是瓶颈；1990年代网络带宽是瓶颈；2020年代 AI 时代，推理算力和 token 配额是瓶颈。而今，人类注意力——这一在认知科学中被定义为"有限的认知处理能力定向分配"——成为最终瓶颈，其背后有深刻的结构性原因：注意力无法并行化、无法外包给更便宜的替代品、也无法通过技术手段成倍扩容。诺贝尔经济学奖得主 Herbert Simon 早在1971年便指出，"信息丰裕必然导致注意力稀缺"，这一判断在 AI agent 爆发的今天显得格外精准。

当模型能力和算力不再是主要瓶颈时，人类开发者的注意力——你需要多频繁地介入 agent 的工作循环——反而成了效率的天花板。Peter 提出的核心工作原则是：优化你需要处于 agent 循环中的频率（optimize how often you need to be in the loop with your agent）。你要做的，是把 agent 能独立完成的事情，从"写 prompt"一直扩展到"验证结果"，这才是真正能榨取更多价值的地方。

围绕这个理念，他展示了三个改变了他编程方式的实用工具与技能。

技能一：Agent Transcript，让PR审查不再是黑箱

OpenClaw 项目遇到的一个典型问题是 PR 泛滥。有些人只是对着编程 agent 输入"fix"加一个编号，agent 就生成长达 4000 行的 PR。这种"零成本"贡献让维护者难以判断：这个人到底花了一分钟还是一小时？他是否真正理解了自己修改的内容？

Peter 的解决方案出乎意料地简单——他一开始还想复杂了，纠结要不要用 hooks、怎么搭建系统，结果发现它本质上只是一个 skill。

这个 skill 背后在解决一个开源软件维护中的经典信息不对称问题。在经济学中，这被称为"柠檬市场"（Lemons Problem）——当质量无法被外部观察时，劣质贡献会驱逐优质贡献。Transcript 作为一种"可验证的工作证明"（Proof of Work），让贡献质量得以被量化感知。

Transcript 机制与可验证计算的关联

从更广的视角看，Transcript 机制在密码学和分布式系统领域有深刻类比。区块链中的 Proof of Work 要求矿工展示计算量，而 Transcript 则是一种「软性工作证明」——通过暴露决策过程而非结果来建立信任。这类机制被称为「可验证计算」（Verifiable Computation）的社会化版本：无需数学证明，仅凭对话记录的长度、决策分叉点和问题排查过程即可提供足够的质量信号。这与 GitHub 早年引入 commit history 可见性、code review 评论数等机制在逻辑上一脉相承——通过增加过程透明度来恢复信任机制。

这个 skill 的逻辑是：当你创建 PR 后（无论用 Codex 还是 Claude，"我们不搞歧视"），它会询问你是否愿意上传一份脱敏后的对话记录（transcript）。如果你愿意，别人认真审阅你 PR 的概率会大幅提升——transcript 越长，维护者对"你确实理解并认真对待了这次修改"的信心就越强。

由于底层就是 JSON，这个技能几乎可以适配所有编程 agent。作为项目的"终身仁慈独裁者"，Peter 直接把它设为默认技能——任何 checkout 仓库的人都会自动获得，agent 也知道在创建 PR 或 issue 时加载它。结果是：采用这一做法的开发者，其 PR 和 issue 质量显著提升。在 AI 辅助开发普及之后，类似的"AI 协作留痕"机制预计将成为开源社区治理的标配工具。

技能二：Auto-Review，把审查反馈送回原始上下文

Peter 最喜爱的技能是自动审查（auto-review）——尽管他调侃说"它也让一切都变慢了"，还给 Anthropic 和 OpenAI 贡献了"数百万"的 token 消费。

传统代码审查流程是：agent 写完代码提 PR，另一个 agent 启动做 review。但这个过程慢，而且存在一个反直觉的问题：审查反馈往往缺少上下文。

Peter 举了个亲身经历的例子：他把一个 PR 加载进 Codex，Codex 审查后发现三个问题，他照着修复了，但由于并未完全理解 PR 的设计意图和约束，结果反而改坏了东西。从表面看那些确实像是问题，但深入理解后，那也许正是刻意的设计决策。

多 Agent 架构中的上下文隔离问题

这个现象在 AI 系统设计中有一个专有名称：上下文窗口隔离（Context Window Isolation）。当一个独立的 reviewer agent 被启动时，它只能看到 PR diff 和代码本身，而无法获取创作这段代码时的完整决策链——包括被放弃的替代方案、特定边界条件的设计理由、以及与项目整体架构的协商过程。

多 Agent 系统中的上下文传递是当前工程实践中最核心的挑战之一。OpenAI 的研究将 Agent 间协作分为两种模式：「共享内存」（Shared Memory）和「消息传递」（Message Passing）。Auto-review 将反馈送回原始会话，本质上是在强制实现「共享内存」语义——避免在消息传递过程中丢失隐性知识（Tacit Knowledge）。这与微服务架构中「避免贫血 DTO」的反模式完全对应：当你把领域对象序列化成简单数据结构跨服务传递时，业务规则和约束往往在传输中隐性丢失。这呼应了 LLM 应用架构设计中的一个核心原则：context is everything，割裂上下文往往比引入新能力代价更大。

这个 auto-review skill 的巧妙之处在于：它调用 CLI 执行审查后，把反馈送回你正在工作的原始会话，因为那个会话拥有远多于审查者的上下文。原始会话可以判断"这条建议对"或"这条建议看似对实则不该改"。更进一步，Peter 设置了指令，让 agent 把这些决策写入 PR 描述中——这样下一个审阅者就不会因为"天真的审查"而再次改坏本不该动的地方。同样，它也被设为默认技能。

技能三：Crapbox，用隔离沙箱解放本地机器

第三个工具源于一个非常真实的痛点：当你同时跑 10 个编程会话时，MacBook 的 CPU 会疯狂运转，风扇"要起飞"，整个系统慢得让人抓狂。他一度不得不动用多台机器——本地电脑、云上的 Mac、Mac Studio 等等——但这显然不是优雅的解法。

他的答案是一个叫 Crapbox 的东西：给 agent 一个隔离的小盒子，通过 rsync 同步仓库变更，从与 GitHub Actions 相同的初始状态出发，在盒子里跑测试。如果你有 CI（他假设你有），它开箱即用。所有昂贵的计算都在盒子里完成，本地 CPU 不再狂转。目前它已支持约 30 个 provider，包括 Parallels 等适配有安全要求的企业环境的方案。

沙箱技术谱系与 Crapbox 的工程定位

Crapbox 所体现的沙箱隔离思想，有着深厚的系统工程根基。现代沙箱技术可以按隔离粒度从粗到细排列：物理机 → 虚拟机（Type-1 Hypervisor 如 KVM/Xen）→ 容器（Linux Namespace + Cgroups，即 Docker）→ microVM（如 AWS Firecracker，将 VM 的强隔离与容器的轻量结合）→ WebAssembly 沙箱。Crapbox 定位于「足够轻量以支持并发 10+ 实例，同时足够隔离以避免状态污染」的中间地带。rsync 增量同步策略（只传输变更文件而非完整镜像）使得冷启动时间从分钟级降至秒级，这是实现「每次 PR 独立环境」的关键工程决策。从1960年代 Unix 的进程隔离，到 2000 年代虚拟机技术（VMware、Xen），再到 Docker 容器和今天的 microVM（如 Firecracker），隔离始终是可靠性工程的第一性原理：让副作用在已知边界内发生，而不是污染整个系统。

Peter 用 rsync 同步仓库变更、从 GitHub Actions 相同初始状态出发的做法，实际上是在实现"幂等性测试环境"（Idempotent Test Environment）——每次执行从相同起点出发，结果可复现，彻底消除"在我本地能跑"（Works on My Machine）这一困扰软件工程数十年的顽疾。对于有合规要求的企业，Parallels 等方案则在 macOS 宿主机上提供了符合 SOC2 审计要求的隔离边界。

有了这个基础原语，更多可能性接踵而至。他为 agent 加上了"眼睛"——可以截图、可以点击，实现了轻量级的 computer use 能力。这意味着 agent 可以在一台全新的干净系统上安装、配置并验证软件（覆盖 Linux、macOS 和 Windows），从根本上避免了"在我本地能跑"的环境污染问题。你想提升的，正是"你所 prompt 的东西确实能工作"的信心，而这需要从一个干净的机器开始验证。

更妙的是，这些环境生成的链接是可分享的。你可以创建一个测试新功能的环境，把链接发给朋友，他们点开就能通过 VNC 试用，且不会遇到传统 computer use 中鼠标焦点乱跳、浏览器弹窗打断之类的烦恼。

用"扩展循环"消化任何输入

Crapbox 的可分享特性引出了 Peter 更宏观的工作流构想。他设想：某公司有个反馈频道，用户提议某个功能，一个 bot 回复"让我来实现"，随后附上一个 VNC 会话链接，让完全不会写代码的人直接试用这个新功能——然后可能发现"这其实是个很蠢的主意"，或者说"对，就该这么做"。

这正是核心理念的落地：扩展循环，让任何输入都能被验证。当反馈在提交给他之前就已经过验证，他只需要关注其中约三分之一真正有价值的部分，就能判断什么值得做——而这一切，只是人们在 Slack 里用 agent 工作时自然产生的副产品。

关于"loops"这个被热议的概念，Peter 直言不讳："说实话，loops 只是 workflow 的一个花哨说法。"这个判断触及了当前 AI agent 领域术语膨胀的核心问题。在技术实现层面，所谓的 agentic loop 无非是一个带有条件分支和外部工具调用的状态机：接收输入 → 调用 LLM → 解析输出 → 决定下一步（调用工具 / 继续推理 / 返回结果）→ 循环。这与经典的 BDI（Belief-Desire-Intention）智能体架构在逻辑结构上高度同构。Peter 用 vision.md 驱动 issue 分类、自动创建 PR 并触发 review 的流程，本质上是一个有向无环图（DAG）工作流——只不过每个节点的执行者是 LLM，而非传统的确定性函数。在他的开源仓库里，创建 issue 会触发一个 agent 根据 vision.md（定义项目方向）判断这是好主意还是蠢主意；若判断为好，就创建 PR；另一个 agent 再启动审查、修复。等他真正有空看开源项目时，很多东西已经"准备好合并"，不必花 20 分钟盯着 agent 干活的信息流。

注意力瓶颈，解决了吗？

面对"注意力问题是否已解决"的提问，Peter 的回答很坦诚：在一定程度上解决了。agent 需要的"照看"更少了，因为你给了它们足够的工具去自主完成工作，直到真正重要的节点才需要你介入。

但他也指出了尚未解决的部分。他现在最困扰的，是工作流"仍然需要如此多的思考"。产出的代码更多、系统更复杂，反而需要更多的整体把控。他有一个精辟的比喻：

"agent 不太擅长理解某一件事如何融入整体大局。它们只专注于眼前那一件事，像戴着眼罩的马，你得推着它们才肯环顾四周。"

近视优化：LLM 全局盲区的系统性根源

这在 AI 对齐与能力研究领域有更系统的表述：被称为"近视优化"（Myopic Optimization）。LLM 在训练时优化的是 token 级别的预测损失，这使其天然倾向于在局部上下文中寻找最优解，而非在系统层面维护全局一致性。在强化学习的框架中，当奖励信号（Reward Signal）只覆盖局部时间步时，智能体会陷入短视策略；而 RLHF（人类反馈强化学习）的奖励模型通常基于单次响应的质量评分，根本无法捕捉「这段代码三个月后是否仍与系统其余部分保持一致」这类跨时间的全局约束。

具体到代码生成场景，这意味着 agent 会在给定的 issue 描述和代码片段内寻找最合理的修复方案，但不会主动质疑"这个 issue 本身是否应该存在"或"这次修改是否与三个月前的架构决策相矛盾"。解决方向包括：显式的 Memory 模块（如 MemGPT 的层级记忆架构）、项目级 AGENTS.md 约束文件（Peter 提到的 invariants），以及人类架构师定期进行的「全局对齐审查」。这也是当前 AI 系统无法替代人类架构师的根本原因：系统级判断需要跨越单次会话的记忆与价值观，而这恰恰是现有 LLM 架构最薄弱的环节。

如果你不去把控整个系统"如何拼接在一起、感觉是否对"，agent 是做不到的。此外他还提醒，coding agent 总是"按最坏情况写代码"，所以在 AGENTS.md 中定义一些不变量（invariants）很有必要，否则 auto-review 有时会矫枉过正。

有意思的细节是：当被问到有没有人"伪造 transcript 让自己显得更聪明"时，Peter 提到他们曾用过一个给 PR 打 1-5 分的审查 bot，结果不止一次有人手动把 2 分改成 5 分，还写上"这是个很棒的 PR，请合并"。人性与 AI 工作流的博弈，看来才刚刚开始。

结语：工具解放的是执行，不是判断

Peter 的分享给出了一条清晰的主线：AI 编程时代的效率边界，正从算力和模型能力转移到人类的注意力上。应对之道不是造更复杂的系统，往往只是一个恰到好处的 skill、一个隔离的沙箱、一条送回原始上下文的反馈路径。

真正难以被自动化的，是对全局的把控与判断——"这真的是我们想要的吗？"这个问题，目前仍然没有任何 agent 能替你回答。

核心要点

核心要点