上下文，而不是提示词：智能体总在同一个地方掉链子

企业智能体上线后的故障清单，读起来往往高度雷同。销售在群里问返点政策，拿到的是上一版条款；同一个问题在工作台里再问一次，答案却是对的。工单系统里的智能体判断某单可以关闭，但它并不知道客户三天前已经在另一个渠道投诉过。业务侧的第一反应通常是"模型不够聪明"，于是提示词越写越长，规则越加越多，问题却照样复现。

把这些故障排到一起看，共同点很清楚：出错的时刻，智能体读到的世界都是残缺的。它拿到了一段对话，却没拿到这段对话背后的合同；它读到了一条工单，却读不到这个客户的历史。提示词能约束模型怎么说话，管不了它能看见什么。

提示词工程解决不了的那一类问题

提示词是对模型行为的约束，上下文是模型可以依据的事实。二者解决的问题不在一个层面上。当一个错误的根因是"事实不在视野里"，加提示词只会让输出更自信地错。我们见过最典型的一种补救：在提示词里逐条写明"如果政策已更新请以最新版本为准"。这句话没有任何作用，因为最新版本压根不在检索范围内。

更麻烦的是，这类问题在演示环节几乎不会暴露。演示是一次性的、上下文被人为准备好的对话；生产环境是连续的、跨系统的、由多人在不同时间推进的协作。前者只需要模型说得好，后者要求系统记得住。

模型决定回答的质量，上下文决定回答是否成立。前者在快速逼近上限，后者仍然是每家企业自己的工程问题。SHARED CONTEXT

把上下文当成一层基础设施来建

可行的做法，是不再把上下文理解为"每次调用时拼进去的一段文字"，而是把它当成平台的一层来建设：知识库、云文档、会话记录与结构化任务表汇聚成一份共享的企业语义层，所有入口读同一份。

• 实体而非文件。智能体需要读到的不是一堆散落的文档，而是客户、项目、合同、任务、人员之间的关系。同一个客户名在三个系统里的三条记录，必须先被认成一个人。
• 写回，而不只是读取。一次协作的结论要落到结构化的事项、负责人和状态上，下一次对话才能站在它上面继续。只读不写的知识库，一个月后就开始失真。
• 一份上下文，多个入口。群聊、工作台、业务系统和定时任务调用的是同一层。入口不同只影响交互形式，不应该影响事实。

这三件事做完，前面那些故障会成批消失——不是因为模型变强了，而是因为智能体每次都读到了完整的同一个世界。

图 · CONTEXT WITH CITATIONS

用引用来源作为验收标准

上下文建得好不好，有一个很朴素的检验办法：让每一个结论都带上它依据的来源，并且让业务人员可以一键点开核对。做不到这一点，通常说明检索命中的内容自己也说不清；做得到，业务人员才会开始把系统当作可以依赖的同事，而不是一个需要事后复查的玩具。

在我们参与的项目里，引用来源还有一个副作用：它会持续暴露知识库里过期、重复和互相矛盾的内容。这些问题在人工时代一直存在，只是从来没有被系统性地摆到台面上。

结语

模型能力是所有人都能买到的公共品，而组织内部那份完整、及时、可被引用的上下文，只能自己建。它决定了智能体是一个会聊天的界面，还是一个真正能接住工作的同事。