今天留两条一手文章。一条在处理模型怎样用更少的内存跑起来，另一条在处理智能体怎样接住团队已有的对话。它们指向的都不是参数表，而是 AI 进到真实环境后最先碰到的两堵墙：机器资源和上下文。

小模型也得把效果守住

Liquid AI 发布了 LFM2.5 系列的 Q4_0 GGUF 检查点，覆盖 230M、350M、1.2B-Instruct 和 2.6B 四个规模。团队采用量化感知蒸馏训练，称这些检查点在维持原生 Q4_0 内存与速度的同时，恢复了 BF16 平均精度损失的 97%。

这个数字是 Liquid AI 自己的测试结果，能不能用还得看你手头的任务。但方向很明确：本地部署和边缘设备不只是在“能不能跑”之间做选择，低比特模型也开始争取把可用性留下来。

如果你在给团队挑本地模型，别只看参数量和跑分。找十来条真实输入，把回答质量、延迟、内存占用放在一张表里看。模型在演示里跑得动，和它能在你的机器上稳定接活，是两回事。

对话要变成能调用的上下文

Slack 首席产品官 Jaime DeLanghe 分享了团队构建人机协作方式的经验：尽量让工作讨论留在可见的公共频道里，再把会议、邮件、日历等上下文连接起来，减少同一件事被反复解释。智能体接入的不是一段孤立提示词，而是团队已经做过的讨论和决定。

这件事听起来简单，落地时却很容易变成聊天记录大杂烩。公开频道能让信息流动，也会把权限、保密范围和有效期摆到台面上。该连的上下文要连，该隔离的客户信息、私人沟通和敏感决策也得隔离。否则智能体拿到的不是知识库，只是一间没收拾过的仓库。

今天可以带走什么

准备把 AI 接进工作流时，先选一个重复出现的小任务：整理项目进展、汇总客户问题，或者从一组文档里找出待办。然后分别写清两件事：它运行时能占用多少资源，它回答时能读取哪些材料。

前者决定这套东西能不能持续跑，后者决定它有没有资格给出靠谱的下一步。模型再强，机器带不动、上下文接不上，最后还是只能停在聊天框里。