把整个组织喂给 agent

设想一个场景：午饭桌上，几句闲聊就把下午要做的事定了。如果这时候就能顺手把活儿交给 agent，让它先去验证、先去设计，那吃完饭回到工位，工作可以无缝接着往下走。

但现实是，没有人吃饭会开着录音。那顿饭里定下来的东西，等我回到工位，还得一句一句重新讲给 AI 听。

这中间有一层沟通损耗。我和同事讨论了一遍、确定了方案，转头要把它转述给 agent，损耗就发生在转述这一步。更糟的是，agent 交付回来的东西常常不符合预期，原因往往不是它不够聪明，而是它没有对问题本身的全局理解，只看到了其中一部分。

让 agent 真正融入企业，卡点不在模型的智能，而在能不能把组织里那些分散、隐性、口头的上下文，正确地喂给它。

最近这件事被摆上了台面。Anthropic 在 6 月 23 日发布了 Claude Tag，把 Claude 做成常驻 Slack 的 AI 队友，它会跟着频道里的工作往前走，一条消息一条消息地积累对团队的理解，不用你每次从头解释。开源世界里有 CopilotKit 的 OpenTag，自托管的"Claude in Slack"平替，自己掌控运行时、自带模型、接自己的工具。国内企业微信也在往同一个方向走，灰度内测的"大圆"助理能自动感知你此刻在哪个群、看哪份文档，不用你复制粘贴任何背景。

还有最近很火的办公智能硬件：录音笔/录音卡/录音豆，形态和十几年前的录音笔没什么大的不同，但是生态的连接能力是很强。会议一键录音，结束后自己总结，并且出纪要和后续待办，并且抄送到相关人员。

它们抢的是同一件事：让 agent 待在工作真正发生的地方，把组织的上下文当燃料吸进去。

缺的不是智能，是组织上下文

人也有信息盲区，这很正常。但人会想办法去补盲区，agent 也该这样。

问题在于，组织里缺失的那块上下文，形态千奇百怪。它可能是随口的一句话、聊天群里的一句提示、一封邮件、一次客户跟进记录、一次会议白板上画的图，也可能是行业里的一些隐形约定、某条渠道的销售情况、服务端的一段错误日志、产品说明书里不起眼的一句话。任何一块缺了，agent 的理解就会有偏颇，它的交付自然走样。

这正是我之前在 Context, Not Control 里讲的那套逻辑，只是抬高了一个 altitude。那篇说的是：不要给 AI 更复杂的流程图，而要给它足够的上下文，然后放手。但那时候我谈的是单个任务的上下文。现在这些产品想做的，是把一整个组织的信息流都接进来，让 agent 不只懂某个任务，而是懂这家公司。

Claude Tag、OpenTag、企业微信的那一波 AI，本质上都是在解决"喂什么、怎么喂"。硅谷一些 AI native 公司走得更激进，想把尽可能多的信息都收集起来：不只是 email 和会议纪要，还有闲聊、即时通讯里的只言片语。在它们的设想里，这些零散信息都是 AI 理解组织的燃料。这个趋势大概率只会越来越明显。

"收集一切"是个错命题

但"尽可能多地收集一切"，这个提法本身是错的。

收进来的东西，可能是燃料，也可能是噪声。闲聊、信息密度不高的内容，如果不加处理就丢给 agent，它会拿着这些低质信息错误地揣测意图。而错误的揣测，比信息缺失更致命：缺了一块，agent 顶多答不全；喂错了一块，它会自信地走向错误的方向。

所以真正成立的命题不是"上下文越多越好"，而是：

正确的、有效的上下文，越多越好。

这一字之差，决定了一整套工序。信息进入组织之前，得先经过一个信息熵减的过程，把低密度的闲聊压成高密度的事实，不要留着模糊地带让 agent 自己猜。收集进来的上下文要先分类、打标、组织好，方便日后回溯，并且带上恰当的背景，而不是一堆裸数据。遇到拿不准的地方，agent 应该主动停下来，跟人再"对齐"一次，而不是带着歧义往下跑。

去噪是一门手艺。能不能把噪声挡在门外、把有效信息留下来，决定了喂进去的到底是燃料还是毒药。

过滤分入口层和检索层

那过滤到底放在哪一端？这里有个绕不过去的纠结。

放在入口过滤吧，问题是：午饭桌上随口定下的那句话、群里飘过的那条提示，你在它出现的那一刻，根本判断不出它是不是信号。很多上下文是事后才变成 load-bearing 的。但要是全都收下、不在入口拦，又回到了上面那个噪声问题。

我的答案是：过滤分两层，两层各管一件事。

入口层只解决一件事：这条到底算不算活儿。 而这一层的开关，就是"@"。讨论归讨论，闲聊归闲聊，当要真正干活了，人 @ 一下，指定某个人或某个 agent 来接活儿。@ 这个动作，就是把"闲聊"显式提升为"信号"的那个按钮。它不需要 AI 去猜哪句话重要，是人主动按下去的。

检索层才解决轻重缓急。 轻重缓急不是信息自带的固有属性，而是相对于"agent 此刻要干什么"才成立的。同一句话，做 A 任务时是噪声，做 B 任务时就是 load-bearing。所以排序没法在入口一次性定死，必须在调用那一刻、相对当前目标去算。

排序还该吃几个客观信号：来源的权威性（服务端的错误日志，权重应该高于某人随口的猜测）、时效性、以及有没有人类显式标记过。最后是分流：最紧急的少数，应该主动 push 来打断你；剩下的绝大多数，按需 pull，默认不占用每一次会话的注意力。

这套两层结构，正好把前面那个"入口还是检索"的纠结化解了：入口只判断"是不是活儿"这种人能一眼定的事，把"哪条最相关"这种依赖任务的事留到检索层。该收的不丢，该排的不在错的时间排。

不是全收：要刻意留出真空地带

讲到这里，要泼一盆冷水。我并不认同把组织里所有的对话，都纳入 agent 的监控范围。

人类的对话，应该保留一定的真空地带。把午饭桌上的录音、把每一句闲聊都收进系统，技术上也许越来越可行，但一个所有话都会被 agent 听见、被索引、被回溯的组织，大家说话会开始端着，反而把那些最有价值的、不设防的交流给扼杀了。完整收集本来就有它天然的限制，而我认为有些限制不该被粗暴地拿掉。

所以这里冒出来一项新的管理工作：组织的管理者，得精心设计哪些场景是 agent 与人的、哪些是人与人的、哪些是 agent 与 agent 的。这不是一个能甩给模型自己去把握分寸的事。

Claude Tag 在机制上给了一个答案：管理员定义 channel 的隔离和权限边界，HR 频道的 Claude 不会把信息带到工程频道，记忆和上下文都被钉死在管理员划定的范围里。这套机制确实托住了一部分。但那条线终究是人划的，不是模型自觉守住的。机制负责执行边界，划在哪里，是管理者的判断。

终局是能动性，不是定时任务

把上下文喂进去，让 agent 被 @ 的时候答得准，这还只是起点。

更高的标准是能动性。一个真正可靠的 agent，不该只会被动接活，它应该有主动性：主动发现问题、主动 propose 方案，在更 high level 的组织目标上发挥自己的能动性。只有做到这一步，它才算得上是组织里不可或缺的"员工"，而不是一个好用的工具。

现在几乎所有 agent 工具都带 cron、schedule、automation 这类功能，无非是用时间来 trigger agent 干活。但时间是最笨的那种信号。定时本身不难，难的是设定"什么应该干"。一个到点就跑的脚本，和一个看到错误日志异常、自己判断该去排查的同事，完全不是一个物种。

而"自己知道该干什么"这件事，恰恰只能从"看见组织完整的信息流和真实世界的问题"里长出来。这就回到了全文的起点：前面花那么大力气去喂上下文、去过滤、去排序、去划边界，最终的目的不是让 agent 答得更准。

上下文不只是回答的燃料，是能动性的燃料。

一个充分吸收了组织信息流的 agent，才有可能自己发现问题、自己设定该干什么。这跟我在 Loop Engineering 里讲的长期自进化 loop 是连着的：让系统自己捕获信号、诊断、提出改进。区别只在于，那篇讲的是产品迭代的 loop，这篇讲的是 agent 在一个组织里、靠组织上下文驱动的那个 loop。

我的思考

写到这里，几个判断对我更清楚了。

第一，让 agent 融入企业，缺的不是智能，是组织上下文。 模型已经够聪明，卡住它的是它看不到那些散在闲聊、邮件、会议、日志、隐形约定里的信息。接下来的差距，大概率拉在"谁把上下文喂对了"，而不是"谁的模型更强"。

第二，"收集一切"是错命题，"正确有效的上下文越多越好"才对。 噪声会让 agent 错误揣测，而错误比缺失更致命。熵减、分类、打标、必要时跟人对齐，这些不是可选项，是上下文进入组织前的必经工序。去噪是一门手艺。

第三，过滤分两层，留真空地带是人的设计责任。 入口靠 @ 把闲聊提升为信号，检索靠相对任务的相关性来排轻重。而到底哪些场景该让 agent 在场、哪些该留给人与人之间的真空地带，这条线得管理者亲手去划，不能指望模型自觉。

第四，终局是能动性，不是定时任务。 cron 只是用时间这种最笨的信号去触发。真正难的是让 agent 自己知道该干什么，而这只能来自它对组织信息流的充分吸收。把整个组织喂给 agent，最终是为了让它从"被 @ 才动"，长成那个不需要你 push、自己就会接活的不可或缺的员工。