TL;DR：Agent execution 的核心在于如何合理并行化 single task——这是 Bitter Lesson 在协作层面的下一题，也是这场 24 小时 hackathon 让我想清楚的事。
最近参加了一个 24 小时的 hackathon，结束之后越想越觉得，新的协作范式和老的已经完全不一样了。这篇文章把我在现场观察到的几个点串一下，更多算是几个我觉得值得后续认真做的方向，谈不上结论。
Hackathon 为什么是好的压力测试？
之前的合作模型是「人 ↔ 人」。中间多了 agent 之后，如果 agent 还只是人的纯辅助、context 是人的严格子集，问题不大——这其实是过去一年绝大多数日常工作的状态。
但 24 小时 hackathon 是另一回事：
- deliver 优先级第一，没人有时间审 agent 的每个判断；
- agent 的 context 和人的 context 事实上已经独立演化，但协作仍然要继续；
- latency 比 throughput 重要——你跑得再多 task，最终交付的就是一个 demo。
这些约束把日常工作里看不出来的问题一下子全暴露出来，下面所有的现象都是从这里来的。
一次 demo 8 小时报废：多跳协作里 context 一定会丢
我们队里吃了一个完整的亏。队友 a 跑通了一个挺漂亮的 demo，让自己的 agent「把所有代码和内容别加筛选地提交 GitHub、保证能复现」。他把 PR branch 直接发给我；我又把 branch 丢给自己的 agent，让它复现。结果完全！没法！复现——尤其当 a 的环境和 GPU instance 因为忘记充钱被回收掉之后，我们四个人花了快 2 个小时还是没能跑起来那个 demo，直接把之前 8 个小时的努力全废了。
事后复盘很清楚：
- 「保证能复现」这个 prompt 在第一跳就被错误理解：a 的 agent 把它当成「commit 我看到的所有文件」，但 a 自己环境里那些隐式依赖（GPU 类型、本地路径、未追踪的临时配置）从来没被它显式记下来；
- 「a → 我」这一跳没有任何 context handoff：a 只发了 PR link，他自己脑子里那些「我的 agent 没记下来但我知道」的信息也没传递过来；
- 「我 → 我 agent」这一跳直接复现：我的 agent 拿到的是一个隐式假设错误的 branch，它再聪明也救不回来。
旧的人-人协作模型里，信息摩擦只发生在一跳。现在的传递路径变成 agent → 人 → 人 → agent，任何一层假设不对齐都会被下游放大。
Design doc / README 在 agent 时代依然重要，甚至要承载的内容更多了：除了「人想做什么」，还要包括「agent 看到了什么、做了什么假设、用过哪些环境变量」。
为什么 crunch time 人却没事可做？
最反直觉的事是：deadline 前最后一两个小时，我们四个人坐着聊天，因为 agent 都在跑——人没事可做。除了把 Claude 调成 ultra fast，我真想不出还能怎么加速。这在 pre-AI 时代是难以想象的。
这个现象可以从 LLM inference 的角度来理解：
- Agent 提升的是 throughput：同一时间能并行 N 个 task，对团队总产出有明显的提升；
- 但 single-request latency 没怎么变：单条 task 从「下发指令」到「拿到结果」的时间，受限于 agent 本身的 step latency 和 reasoning 深度，加速比远比 throughput 小；
- Hackathon 这种场景 latency 才是关键：你只交付一个 demo，crunch time 真正卡你的是「这一条 task 啥时候能做完」，task 数量多少倒还在其次。
所以 crunch time 真正的问题在于：你已经没办法把单条 task 做得更快了。
还有一个有意思的观察：随着 agentic 能力越来越强，「人是 owner、agent 是辅助」的姿态实际上已经反转，变成 agent 在做事、人在辅助。这里只是一个观察，不带价值判断。Crunch time 让这件事变得最明显。
唯一能加速单个 task 的办法：让单个 task 也并行
既然 single-task 上单纯靠 agent 提速空间有限，唯一剩下的办法是对单个 task 也调高并行度——让多个 agent 同时往一个 task 的不同维度推进。但要做到这一点，前提是 context 能在 agent 之间流转。
Claude 内置的 btw 之类的功能能缓解单 agent 内部「问问题就没法执行」的 ask/execute 互斥，但要让两个 agent 同时开发一份代码、并且最后能干净 merge 起来，完全是另一个量级的问题。本质上这就是 Amdahl’s Law 在协作上同样适用：
- 能并行的部分越大、加速比上限越高；
- 让 context 在 agent 之间能流转，就是把「只能串行」那部分压小的唯一方法；
- 「只有 single agent hold 着 all context」是最严重的串行卡死——这种状态下，第二个 agent 加进来除了制造冲突没有任何加速贡献。
所以在做事的合适节点显式做 checkpoint + context offload，这件事的意义远远不只是「让别人能复现」——它给后续多 agent 共同推进留了一块 common ground。我在 hackathon 里就遇到过这种卡死：我跟 agent 问问题时它没法做事，它在做事时我没法增进我对当前情况的理解——人的理解和 agent 的执行甚至连 overlap 都做不到。
副作用：人会陷进 agent 给的信息茧房
新的协作模式 default 长这样：
agent 先 offload context → 另一个 agent 读 context → 人有选择地从 agent 吸收 context
人一旦吸收得不够，就很容易陷进一种新的失败模式：看 agent 给的判断怎么看怎么对，只会说「继续」。Agent 没有撒谎、没有偷懒，但人事实上已经把判断权交出去了。
agentic 能力越强，这件事就越难——agent 越强、跟它走越省力，主动跳出去 grab 全局反而越累。作为人，得主动定期打破 agent 给你建的信息茧房——这件事的优先级比想象中高得多。
同一个 diminishing returns 也作用在 agent 上：一个 project 真正可以独立并行的维度本来就不多，人多了赛马、agent 多了也是同样的浪费。怎么把一件事拆得能并行、什么时候有意识地赛马、什么时候坚持串行——这个 trade-off 以前只在「人」这一层做，现在要在「人」和「agent」两层同时做。
Bitter Lesson 的下一题
回到 The Bitter Lesson。Sutton 讲的是 AI 模型：最终赢的方法一定是能 scaling 的结构；那些人类精心设计的结构最终都会被它超越。
这条规律对协作流程本身同样成立。Agent 已经是 Bitter Lesson 的受益者——它本身就是 scaling 出来的东西。下一道题是：
怎么 scaling 由 agent 组成的协作系统、让多个 agent 同时为同一个 task 做出进度贡献——让 agent 数量、并行度、context 流动方式都能持续 scale，避免被人类精心设计的「流程」卡住。
目前看，这件事没有任何成熟答案：context 怎么在 agent 之间高效传递、何时 checkpoint、谁来处理冲突、人如何在 agent 群里保持判断而不沦为只会说「继续」的复读机——这些问题大家都还在摸。
Hackathon 之后我反而比来之前更确信：这才是接下来真正值得做的事。