你好，我是 Changyi 👋

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 个小时的努力全废了。 ...