企业 AI 智能体项目失败，多数时候并不是模型不够强，而是在智能体真正采取行动的那一刻，没有人事先决定过它「可以知道什么」。这个决定如今有了正式名称：上下文工程（Context Engineering）。BARC 在 2026 年 9 月 3 日发布的研究表明，把上下文工程制度化的企业，成为 AI 领先者的可能性是其他企业的四倍。
什么是上下文工程？
上下文工程，是在 AI 模型进行推理或执行动作的那一刻，为它组装正确的信息、工具、指令与历史记录的一套方法。它取代了过去反复修改单条提示词的做法。对企业来说，它是把通用模型变成一个了解你的制度、数据与边界的智能体的关键一层。
最清晰的界定来自 DataHub 联合创始人兼 CTO Shirshanka Das 在 BARC 报告中的表述：上下文工程是为单次智能体调用组装正确输入的实践，上下文管理则是在企业层面跨多个智能体、多个数据源治理这些输入的纪律。两者都值得进入董事会议程，因为前者决定一个试点能否跑通，后者决定成功能否被复制。
业内流传最广的比喻出自 Andrej Karpathy：大语言模型像 CPU，上下文窗口像内存。内存里装的是错误数据，CPU 主频再高也只会得出错误答案。所以，如果你的部门去年把模型从一代前沿升级到下一代，智能体的可靠性却毫无起色，问题很可能在内存，而不在处理器。
上下文窗口本身是一笔有限预算。Anthropic 的工程指南《Effective Context Engineering for AI Agents》把目标定义为：找到最小的一组高信号 token，使期望结果的概率最大化。你塞进窗口的每一份制度文件、每一条工具说明、每一轮对话，都在争夺模型的注意力，而模型表现会随着窗口被填满而下降。上下文并非越多越好。
为什么上下文工程对 2026 年的香港企业尤为重要？
香港企业正在把 AI 智能体推向生产环境，与此同时，个人资料私隐专员公署对智能体式 AI 的要求正在收紧。要处理邮件、合同和客户记录、还要兼顾三种书面语言的智能体，必须依靠受治理的上下文才能保持准确与合规。把上下文当作基础设施的企业，与把上下文当作一段提示词的企业，差距正在扩大。
BARC 这项题为《Context Engineering for Agentic AI: Architecture, Use Cases, and Principles for Success》的研究，访问了全球 285 位数据、AI、IT 与业务负责人。研究把 42% 的受访者归为「上下文领先者」，即已落地、制度化或优化了六项基础要素：数据集成、工作流编排、检索方法、联邦式元数据、提示词工程，以及语义层。在这些领先者中，49% 同时达到 AI 领先者标准；其余企业只有 12%。
同一研究也揭示了大多数企业的现状：44% 的受访者只在单个智能体、单个团队或单个平台内管理上下文，43% 则跨团队、跨平台或在全企业范围管理。后者可以把「活跃客户」「已审批供应商」的定义在财务、运营与合规智能体之间复用；前者每次都要重建，而每一次重建，都是两个智能体各说一套的机会。
香港还有两项本地压力。2026 年 8 月 25 日，个人资料私隐专员公署发布了《人工智能：个人资料保障模范框架》的补充指引，专门针对智能体式 AI 的个人资料保障。指引将智能体式 AI 视为独立的风险类别，理由是智能体获得的访问权限与自主程度前所未有。决定智能体能看到什么，因此不再只是工程选择，而是《个人资料（私隐）条例》下的数据最小化决定。另一方面，香港的工作文件混杂英文、繁体与简体中文，在美国演示里表现良好的检索方法，放到香港的合同档案库中往往漏掉一半内容。
上下文工程与提示词工程、RAG 有什么区别？
提示词工程是为单次请求写出更好的指令；检索增强生成（RAG）是为单个答案检索文档作为依据；上下文工程则治理模型在整个任务中看到的一切：指令、检索到的数据、工具定义、记忆与先前步骤。提示词与 RAG 是上下文工程内部的组件，而不是它的替代方案。
这一区分之所以重要，是因为不少香港企业在 2024 或 2025 年做过 RAG 试点，然后得出「AI 对我们来说不够准确」的结论。在我们见过的多数复盘中，检索组件其实工作正常，真正的问题是智能体同时拿到了过期的工具输出、过长的系统提示，以及没有任何规则说明何时应该去查证。Redis 的《State of Context Engineering 2026》报告显示，82% 的 IT 与数据负责人认同，仅靠提示词工程已不足以支撑规模化 AI。
向管理层汇报时，一个实用做法是点明智能体每一步都会收到的四类输入：
--- 指令：系统提示、制度与语气规则，要足够具体以引导行为，但不能死板到在边缘情况下崩溃。
--- 知识：为本次任务检索的文档、记录与指标，最好按需实时拉取，而不是预先批量加载。
--- 工具：智能体可以调用的系统，每一个的说明都要清晰到模型永远不必猜该用哪一个。
--- 历史：任务到目前为止发生了什么，经过压缩，让关键决定留下、噪音消失。
如果供应商只会谈第一类输入，你买到的只是换了名字的提示词工程。
成熟的上下文工程框架包含哪些要素？
按 BARC 的界定，成熟框架包含六项受治理的要素：数据集成、工作流编排、检索方法、联邦式元数据、提示词工程与语义层。语义层承载共享的业务定义，联邦式元数据承载归属与权限。缺了这两项，每个智能体都会自己发明一套「事实」。
对运营总监或数字化转型负责人而言，六项要素可以转化为向内部团队或供应商提出的问题：
--- 数据集成：智能体能读取哪些系统？连接是实时的，还是每季度导出一次？
--- 工作流编排：当任务需要跨两个系统的三个步骤，由谁决定顺序？逻辑记录在哪里？
--- 检索方法：智能体是按关键词、按语义、按元数据筛选，还是组合使用？你能否测出是哪一种失效？
--- 联邦式元数据：是否有记录说明每个数据集归谁所有、哪些岗位可以向智能体开放？
--- 提示词工程：指令是否像其他受控文件一样有版本、有测试、有评审？
--- 语义层：「收入」「人员编制」「客户」在财务智能体与运营智能体眼中，含义是否一致？
BARC 受访者的优先级说明了框架的用途：38% 把一致性与可靠性列为首要目标，34% 选择准确性，只有 12% 选择降低成本，尽管 BARC 预计随着 token 消耗增长，成本的权重会上升。可靠性排在首位，是因为一个八成时间正确、两成时间自信出错的智能体，不能被托付任何涉及客户或账目的工作。
Anthropic 的工程指南补充了三种应写入框架文件的操作模式：按需检索，即智能体只保留轻量引用，需要时才加载完整文档；压缩，即把冗长历史做摘要，避免任务中途耗尽窗口；以及子智能体架构，让每个专门智能体持有干净、狭窄的上下文，再回传精简结果。这些机制，就是「受治理的上下文」几个字背后的实质。
上下文工程在香港企业中如何实际落地？
设想一家在香港与大湾区运营 30 个仓库的物流集团，部署智能体回答客户的派送查询。试点失败的原因，是智能体引用了上一季度的截单时间。解决方法不是换更强的模型，而是一条上下文规则：回答时实时检索现行时间表，标注生效日期，并禁止智能体在没有该表的情况下作答。
在这个物流案例中，第一版把 90 页的运营手册加载进每一段对话，准确率低、单次查询成本却很高，因为手册挤掉了客户真正的问题。第二版只保留手册的两行索引，当查询涉及某一章节时才检索该章节。准确率上升、成本下降，团队还得到一样更有价值的东西：每个答案依赖了手册哪一节的记录，而这正是审计人员会索要的证据。
一家专业服务机构面对的是另一类问题。它的智能体要依据以英文和繁体中文保存的历史范本起草委托函。只按查询语言匹配的检索，会漏掉一半的范本库。上下文工程的答案是一层双语元数据，让无论以哪种语言标注为「责任限制」的条款，都能被任何一种语言的提示词检索到；再加一条权限规则，确保客户甲的范本绝不会在为客户乙起草时出现。
一家区域性银行的合规团队则说明了治理的一面。根据私隐专员公署的智能体式 AI 指引，银行必须能够解释智能体访问了哪些个人资料以及原因。一个记录每次检索、其来源及授权依据的上下文管理层，能给合规负责人一个站得住的答案；一段提示词做不到。
上下文工程最常见的错误有哪些？
五个最常见的错误是：把所有东西塞进窗口、让每个团队各自定义上下文、工具说明含糊、从不压缩历史，以及把指令当作不受追踪的普通文本。每一项都导致同一个症状，即智能体自信地出错；而每一项在设计阶段修正的成本，都远低于部署之后。
第一个错误最昂贵。团队以为一百万 token 的窗口意味着可以放进整个制度库。结果表现下降、单次调用成本上升，智能体还开始引用错误文档，因为两份相似文件被并排放在一起。Anthropic 的指南直接点出这一点：目标是最小的高信号集合，而不是最大的可能集合。
第二个错误是组织层面的。BARC 发现 44% 的企业只在单个智能体或团队内管理上下文。实际后果是人力资源智能体与财务智能体对「员工」有不同定义，两者都被问到人力成本时，管理层拿到两个数字。解决方法是一个由中央拥有、各部门使用的共享语义层。DataHub 的《State of Context Management Report 2026》发现，93% 的企业表示很可能把上下文当作共享基础设施，而非某个团队的专属工具。
第三和第四个错误属于技术层面，但业务部门看得见。含糊的工具说明让智能体选错系统，例如答案在 ERP 里却去查 CRM。未压缩的历史让长任务在十二步中的第九步失败，在运营部门眼里就成了「智能体只能处理简单个案」。
第五个错误是把提示词当作非正式文本。如果系统提示可以由任何人不经评审修改，你就有了一份不受控的制度文件，在驱动对你系统的实际操作。请为它建立版本、测试与评审，像对待任何标准作业程序一样，因为它本质上就是一份标准作业程序。
如何向董事会或 CFO 讲清上下文工程？
把它表述为「可以规模化的 AI 预算」与「每个项目都归零重来的 AI 预算」之间的区别。用 BARC 的数字，49% 对 12%，说明受治理的上下文是 AI 领先的预测指标。然后为共享基础设施，即语义层与元数据归属申请预算，而不是再申请一个孤立试点。
董事会对三种表述有反应。第一是可复制性：每个建立在共享上下文上的智能体，成本都比上一个低；每个孤立建立的智能体，成本都与第一个相同。第二是可审计性：受治理的上下文会留下智能体知道什么、为何知道的记录，这正是私隐专员公署的智能体式 AI 指引与你的内部审计委员会共同想要的。第三是选择权：上下文层与模型无关，当下一代前沿模型出现，或某家供应商放慢发布节奏时，你的投入可以延续，而不必重建。
与 CFO 的对话也应说明上下文工程做不到什么。它不能完全消除幻觉，只能缩小幻觉可以出现的空间。它不能替代数据质量工作；BARC 受访者把数据质量与准备列为首要挑战，占 49%，高于模型局限的 29% 与治理缺口的 25%。一份可信的商业方案会如实写明这一点，并把数据工作与智能体工作一起纳入预算。
如果你已经读过关于前线部署工程师或企业数据保留防护的文章，上下文工程正是把两者连接起来的一层：它是工程师构建的东西，也是防护措施所保护的数据。至于同一概念在单次调用层面的操作细节，可参考用 XML 标签结构化提示词的实操指南。
结论：企业领导者下一步该做什么？
把上下文当作基础设施，而不是一段提示词。盘点你的智能体目前能看到什么，为它们依赖的定义与数据集指定负责人，并在下一个试点之前，先为共享的语义层与元数据层安排预算。BARC 数据中领先的企业正是这样做的，而它们的智能体，才是可以托付真实工作的智能体。
2026 年数据中令人不安的事实是：模型能力已经成为智能体项目中最容易获得的部分，也最不可能是项目失败的原因。把 49% 与 12% 区分开的，是一项耐心的工作：决定智能体可以知道什么、记录这些知识由谁负责，并保持更新。这项工作并不光鲜，却正是一家在香港服务企业 28 年的科技伙伴，早在「上下文工程」这个词出现之前就一直在做的事。懂AI的冷，更懂你的难。UD 同行28年，让科技成为有温度的陪伴。
由 UD 企业 AI 团队审阅。资料来源：BARC 与 DataHub《Context Engineering for Agentic AI》（2026 年 9 月 3 日）；Anthropic Engineering《Effective Context Engineering for AI Agents》；Redis《State of Context Engineering 2026》；DataHub《State of Context Management Report 2026》；私隐专员公署智能体式 AI 指引（2026 年 8 月 25 日）。
准备好为你的 AI 智能体搭建上下文层了吗？
了解了框架，下一步是找出受治理的上下文在你的组织中最快见效的切入点。UD 团队手把手带你完成每一步，从 AI 就绪度评估、数据盘点，到智能体设计、部署上线与成效追踪，28 年企业服务经验，全程陪你走。
