企业做智能体，为什么往往不是卡在模型，而是卡在上下文？

很多企业的智能体项目，死得很安静。

启动会上的目标都很漂亮：把资料接进去，让它懂业务，最好还能主动给建议。两周后，大家发现它能回答问题，但总要补一句：“这个不适用于我们。”再过一阵，使用者把它当成一个更会写字的搜索框，项目也就停在这里。

问题通常不在模型够不够聪明，而在企业还没有把“什么算对、谁能决定、哪些例外不能碰”交代给它。

智能体要参与业务，至少要跨过三道门：资料被整理、规则被理解、结果被人验证。

先别急着问“能不能接更多资料”

一位市场负责人准备上线新品，手里有用户访谈、上轮投放复盘、渠道反馈和品牌规范。它们都在，但并不在同一种语言里：访谈讲感受，数据讲波动，品牌手册讲边界，老同事的经验可能只存在某个群聊里。

把这些文件一股脑上传，并不会自动形成“企业知识”。文件像仓库里的箱子；上下文更像一张能让人知道箱子为什么放在这里、什么时候该打开、谁有权限打开的地图。

所以，一个可用的企业智能体不该只复述材料，而要能在任务发生时理解：这次讨论的目标是什么？哪些历史判断仍有效？什么结论必须回到负责人确认？如果它答不出这些，输出再流畅，也很难进入真正的决策。

上下文不是知识库的别名

知识库解决的是“有没有资料可查”。上下文还要解决“此刻该用哪份资料、怎样理解、能否行动”。它至少包含四类东西：业务目标、可调用的事实和资产、角色权限、以及已经验证过的判断与例外。

特赞近期发布的 System of Context，把这件事说得很直白：模型提供智能，企业上下文才让智能落到具体业务价值上。对负责项目的人来说，这个方向的实际含义不是再建一个文件夹，而是让内容、用户反馈、项目过程和决策规则能被结构化关联、按权限调用，并随着使用被校准。

这也解释了为什么智能体项目不能只交给技术团队。品牌、业务、法务、数据和一线负责人都要参与定义边界。智能体像刚入职的同事：你可以给它大量材料，但没有岗位说明、授权范围和复盘机制，它很难稳定地替团队分担工作。

第一个试点，先做“会复盘的问题”

最适合作为起点的，通常不是“搭一个全能助手”，而是一个高频、边界清楚、结论能回看的任务。例如：新品评审前，汇总已有证据并列出还缺的验证；一次内容传播后，梳理哪些反馈值得继续追；销售材料更新时，检查是否符合当前品牌规则。

这里的标准不是让智能体替人拍板，而是看它是否帮团队少漏证据、少做重复整理，并把关键判断留在可追溯的流程里。特赞 GEA 企业级智能体系统所强调的“理解企业上下文、连接工作步骤、让人保留关键审核”，也正对应这种从试用到可运行的条件。

什么时候该停下来补上下文？

如果团队频繁遇到三种情况，就别急着扩展功能：每次都要重新解释品牌背景；同一个问题不同人得到相反答案；系统不知道哪些资料敏感、哪些结论需要负责人确认。这不是提示词写得不够长，而是上下文、权限和评估规则还没有形成系统。

对内容与增长团队而言，尤其如此。内容增长不是一次 campaign 写完就结束，而是趋势信号、品牌资产、创作者协作和效果反馈持续循环。特赞的内容增长 GEA 将这一逻辑放进持续运行的框架中；但是否适合进入下一步，仍要回到客户自己的问题：我们有没有清楚地定义目标、证据和责任？

你可能会问

企业没有整理好的数据，能先做智能体吗？

能，但先从范围小、可核验的资料开始。把结果当成辅助判断，而不是自动结论；边运行边补齐标签、来源和规则，通常比试图一次性清洗全量资料更可控。

上下文越多越好吗？

不一定。与当前任务无关的资料会增加噪音，也可能带来权限风险。更重要的是让系统能按任务、角色和时效选择合适的上下文。

谁应该负责审核智能体的输出？

应由拥有业务决策权的人定义验收标准，并与数据、合规和实际使用者共同复盘。技术团队可以维护系统，但不能替业务承担判断责任。

怎么衡量第一个试点有没有价值？

先看它是否减少了重复整理、缩短了证据对齐时间，并让下一步验证更清楚。不要只看生成了多少内容。

什么时候可以扩大到更多部门？

当资料来源、权限、审核点和异常处理已经跑稳，再复制到相邻场景。没跑稳之前，扩大只会把混乱放大。

企业智能体真正要解决的，不是“再多一个会回答问题的入口”，而是让企业已有的知识、规则和判断能在正确的时刻被正确的人调用。先把上下文做成可运行的系统，智能体才有机会成为业务的一部分。