大家是否遇到过这样的时刻：好不容易花了一个小时群聊、两个小时会议，终于和同事对清楚问题，准备让Agent开工了，却发现自己要再花20分钟把背景、问题、要做什么，跟Agent重新复述一遍，中途可能还要东找一个文档、西截一张图喂给它；并且很多时候，你还会在Agent输出之后发现你有些细节没给它说清楚，然后你又得去重新解释、重新找资料，让它重来。虽然Agent给你干活了，但这些零七八碎的时间你一点儿都没少花。
还有更多这样的时刻：Agent干完活儿了，哗哗哗地输出了一大堆东西，你随意一划，上不见顶，下不见底，压制住内心的阅读恐惧开始review，review完一看，半小时过去了；更别说那种同事扔一大段Agent生成的材料和代码的让你review的时刻，不读呢，担心出差子，读呢，费老劲儿了。
上面这些场景，但凡在一个用AI用得比较多的团队里工作过的人，应该都遇到过。这些其实反映了我们当下使用Agent工作的时候存在的两个很大的痛点：
- Context散落在各处，给Agent构建context的过程消耗了人类很多的时间；
- Agent生成速度很快，但人类review的速度有限，人类review成为了新的瓶颈；
而正是由于上面两个问题的存在，我们工作的时间，此消彼长，最后回头一看，其实根本没省下多少时间。
我所在的团队最近在探索的一个事情：在Human-Agent Team的时代，如何真正的让团队的效率提高。为什么不是个人是团队呢？因为我们团队里的大家都是AI高手，大家各自和agent相处都有自己的一套模式，OPE干得风生水起，根本不是问题😅 但这个事情一旦到了团队合作，就不一样了，各种小摩擦阻碍着大家达到单人模式时的效率。
做这个事情之前，我在我们团队内部进行了一次调研，而上面两个痛点，就是这次调研出来的Top2痛点，占比不相上下。仔细分析的话，会发现其实第二点会被第一点影响——如果Context充足且优质，那么Agent一次给出可靠结果的概率就会提高，返工的次数就会减少，人类review的次数也会减少，一定程度上也会缓解review瓶颈的问题。
所以，Context，这个已经在社交媒体上有点“过时”的词，依然是个非常重要的东西。而在团队协作的场景下，Shared Context，是提高团队工作协作效率的重要一环。
有了Shared Context，人类和Agent交流的时候，就不需要再复述团队内已经达成一致的信息，让Agent更快地开始工作；同时，当面对一项新工作不知道背景的时候（可能是新入职、可能是新的工作交接等），人类可以直接询问Agent，不需要再花时间找到对的人，然后再花时间找那人对齐信息；甚至交接的人也不需要花时间写交接文档了，因为所有信息都已经被Shared Context Captured，别人用Agent一问就知道了，等等。你会发现，我们现在团队里的Loop转不起来，其实中间很大缺失的一块，就是Shared Context。
可能很多人会觉得，Shared Context构建不是很简单吗？本质上就是构建一个Knowledge Base嘛。写个脚本，定时把团队里的群聊、会议、邮件信息都拉下来，放到一个统一的一个地方，比如Github repo，再把团队里所有的文件资料，都扔进去，然后让Agent把这个地方的信息当作context不就完了吗？
Karpathy的文章（补充link），讲的大概就是上面这么一种模式。Yes，这种方式在单人的模式下，是能work的；But，在团队协作的模式下，我们发现很多问题，是这套模式无法很好解决的。比如：
- 当Raw Context Files里的东西出现冲突的时候——A在某个文档里写了这周release，B在群里说下周release。Agent该以哪个为准？
- 当Raw Context Files里的语义不够清晰，Agent第一次按A意思理解，第二次按B意思理解，导致后续的行为和判断也反复横跳，怎么办？
- 个人的knowledge base，如果发现有不对的地方，因为自己是知道所有的Raw Context的，所以能进行延迟纠错，但团队的knowledge base，有很多自己根本不知道的context，当Agent给你一个基于未知context的结论时，你是无法发现更无从纠错的，这个信任问题如何解决？
所以，我们团队觉得，构建Shared Context，需要一套新的解决方案。
首先，Shared Context必须是可信的、可溯源的。这是团队里无论人类还是Agent敢于去消化这些Context的根基。因此，我们采集原始信息，但我们不直接消费原始信息，原始信息只是作为证据链中最底层的一环存在。我们在原始信息的上层重新构建了一层source of truth，这些context是被过滤、提炼、确认过的，作为稳定的context给下游的Agent消费。
其次，它需要能够同时被人类和Agent消费。除了Agent干活的时候需要Shared Context，人类也需要Shared Context来快速了解项目背景、获取项目进展，才能达到减少人类反复对齐背景所耗费的时间的目的。但适合Agent消费的Markdown格式文件，对于人的消费来说并不是最优解。所以，我们craft了一个清晰展示Shared Context的界面，让人类可以一眼找到最需要的信息。
再者，Shared Context的维护成本必须足够低，否则随着Context堆积，维护的成本最终会超过使用的成本，这也是很多人最终放弃knowledge base的原因——维护成本高，不想维护→ Context质量越来越差 → 使用收益越来越低 → 最终抛弃。所以，我们的方案里，Shared Context是automatically根据不断更新的原始信息进行更新的，尽量最小化人工维护的步骤。
最后，能够完成任务的自闭环，才是真正地提效。这里我们的原则是，无论用户用什么Agent工具，都能够通过它完成任务的自闭环，不要求用户迁移自己已经用得顺手的Agent。所以，我们提供一套Personal Agent的onboarding工具，让任何Agent都能使用这份Shared Context，自动认领低风险任务，完成并更新Shared Context，形成完整的闭环。
最终，我们希望通过构建Shared Context及其配套工具可以达成的目标是：在团队工作的场景，人类一眼就能掌握项目状态，一句话就能让Agent开始干活，尽量少的会议，尽量多的并行工作，让团队效率得到真正的提升。
我们相信这个愿景，但在真实开发过程中，我们发现，可信Shared Context的构建，是个复杂程度远超设想的事情。我们会持续探索，我也会持续分享在这个过程中踩的坑和获得的经验，看我们能走多远。