https://changyi.fun/zh/ Recent content on ChangyiYang's Site Hugo -- 0.163.3 zh Tue, 23 Jun 2026 00:00:00 -0500 https://changyi.fun/zh/posts/hackathon-agent-collab/ Tue, 23 Jun 2026 00:00:00 -0500 https://changyi.fun/zh/posts/hackathon-agent-collab/ <blockquote> <p>TL;DR：Agent execution 的核心在于如何合理并行化 single task——这是 Bitter Lesson 在协作层面的下一题，也是这场 24 小时 hackathon 让我想清楚的事。</p> </blockquote> <p>最近参加了一个 24 小时的 hackathon，结束之后越想越觉得，<strong>新的协作范式和老的已经完全不一样了</strong>。这篇文章把我在现场观察到的几个点串一下，更多算是几个我觉得值得后续认真做的方向，谈不上结论。</p> <h2 id="hackathon-为什么是好的压力测试">Hackathon 为什么是好的压力测试？</h2> <p>之前的合作模型是「人 ↔ 人」。中间多了 agent 之后，如果 agent 还只是人的纯辅助、context 是人的严格子集，问题不大——这其实是过去一年绝大多数日常工作的状态。</p> <p>但 24 小时 hackathon 是另一回事：</p> <ul> <li><strong>deliver 优先级第一</strong>，没人有时间审 agent 的每个判断；</li> <li><strong>agent 的 context 和人的 context 事实上已经独立演化</strong>，但协作仍然要继续；</li> <li><strong>latency 比 throughput 重要</strong>——你跑得再多 task，最终交付的就是一个 demo。</li> </ul> <p>这些约束把日常工作里看不出来的问题一下子全暴露出来，下面所有的现象都是从这里来的。</p> <h2 id="一次-demo-8-小时报废多跳协作里-context-一定会丢">一次 demo 8 小时报废：多跳协作里 context 一定会丢</h2> <p>我们队里吃了一个完整的亏。队友 a 跑通了一个挺漂亮的 demo，让自己的 agent「把所有代码和内容<strong>别加筛选</strong>地提交 GitHub、保证能复现」。他把 PR branch 直接发给我；我又把 branch 丢给自己的 agent，让它复现。结果完全！没法！复现——尤其当 a 的环境和 GPU instance 因为忘记充钱被回收掉之后，我们四个人花了快 2 个小时<strong>还是没能跑起来那个 demo</strong>，直接把之前 8 个小时的努力全废了。</p>