8.0
热点
AI SCORE
技术实践2026-08-09 00:00
AI Agent 跑通 Demo 却栽在生产环境：缺的是业务上下文层
dev.to · AI#AI Agent#RAG#业务逻辑
Editor brief · 编辑速览
AI Agent 在演示中表现出色，但进入生产后往往做出不符合业务的决策——模型不缺推理能力，缺的是客户资格、合同条款、审批策略等业务上下文。解决思路是在 prompt 之外构建独立业务上下文层，而非一味换模型。
AI Agent 在推理、调用工具、搜索文档和完成多步骤任务方面越来越强大。
然而，许多团队在 AI 系统从演示进入实际业务运营后，发现了同样的令人沮丧的问题：
模型听起来很智能，但它并不理解业务。
试想一个客户问道：
“续费能给我 15% 的折扣吗？”
一个能力强的语言模型理解折扣是什么。它很可能能写出一份极好的回复。
但它不会自动知道：
模型可能完美地理解了语言，但仍然做出了错误的业务决策。
这就是为什么生产环境中的 AI 需要的不仅仅是提示词（prompts）。
它需要业务上下文（business context）。
当 AI 助手给出糟糕的回答时，第一个反应通常是：
“我们需要一个更好的模型。”
有时候确实如此。
但切换模型并不能解决信息缺失的问题。
想象一下，给世界上最好的销售人员完全不提供访问你的 CRM、定价规则、产品信息、客户历史或公司政策的权限。
他们的通用销售知识仍然会令人印象深刻。
他们为你的公司做出正确决策的能力仍然有限。
AI 系统面临同样的问题。
生产系统不仅需要理解用户的言语，还需要理解围绕这些言语的组织含义：
这个持续改进 AI 系统接收的公司特定信息的过程，越来越被称为 AI 业务上下文精炼（AI business context refinement）。
当 AI 从生成文本转向实际采取行动时，它变得尤为重要。
假设 AI 检索到以下 CRM 字段：
Customer Value: $50,000
从技术上讲，AI 现在有了数据。
但 $50,000 意味着什么？
Customer Value: $50,000
Definition: Annual contract value
Support Tier: Priority
Open Issue: Billing escalation
Discount Policy: Manager approval above 10%
数字没有改变。
当 AI 连接到真实工作流程时，这个区别非常重要。
检索增强生成（Retrieval-augmented generation），即 RAG，是构建业务 AI 最有用的模式之一。
不是期望模型知道私有或当前信息，而是由应用程序检索相关信息并在生成过程中提供。
但有一个重要的区别：
检索信息不等于检索到正确的业务上下文。
想象你的知识库包含三个退款政策：
refund-policy-2024.pdfrefund-policy-final.pdfrefund-policy-new-final-v2.pdf检索系统可能找到所有三个。
现在 AI 有了更多信息。
但它也有了一个新问题。
哪个文档是权威的？
成熟的上下文系统需要文档文本之外的元数据：
Document: Refund Policy
Status: Active
Owner: Customer Operations
Version: 6.2
Effective Date: 2026-06-01
Supersedes: Version 6.1
Allowed Users: Support + Managers
这就是上下文架构变得比简单创建嵌入向量和运行向量相似性搜索更有趣的地方。
简化的生产架构可能如下所示：
Business Systems
│
├── CRM
├── ERP
├── Knowledge Base
├── Support Platform
├── Product Database
├── Pricing System
└── Internal Documents
│
▼
Business Context Layer
│
├── Definitions
├── Relationships
├── Permissions
├── Source Authority
├── Business Rules
├── Customer State
└── Historical Context
│
▼
Retrieval + Tools + APIs
│
▼
AI Model / Agent
│
▼
Business Action
│
▼
Evaluation + Feedback
LLM 很重要。
但它只是一个组件。
围绕模型构建的系统决定了它是否收到做出有用决策所需的信息。
在允许 AI Agent 执行有意义的业务工作之前，测试你的架构是否能回答这些问题。
内部术语可能出乎意料地难以理解。
Qualified Lead
Active Customer
Priority Account
Revenue
High Risk Enterprise
这些词在你的组织内部可能有精确的定义。
如果模型使用通用含义而不是公司特定的含义，即使检索正常工作，下游决策也可能出错。
为重要概念创建业务术语表。
企业经常在多个位置存储相同的信息。
产品价格可能出现在：
你的 AI 需要知道哪个系统是权威的。
一个简单的来源层次结构可以防止许多错误：
Pricing Database
↓
Approved Product Database
↓
Current Knowledge Base
↓
Archived Documents
检索质量不仅仅关乎相关性。
业务信息老化很快。
六个月前完全正确的文档今天可能成为危险的上下文。
有用的元数据包括：
created_at
updated_at
effective_from
expires_at
version
owner
status
这使得检测我们所说的上下文漂移（context drift）更容易：AI 可用的信息不再匹配当前业务现实的情况。
相关信息不一定是授权信息。
假设员工问：
“总结我们对这个客户了解的一切。”
你的检索系统可能在技术上找到：
但这不意味着每个员工都应该收到每条记录。
上下文检索应该继承或执行访问控制。
context = retrieve(
query=user_query,
role=current_user.role,
permissions=current_user.permissions
)
生产实现会更复杂，但原则很简单：
授权应该在敏感上下文到达模型之前发生。
有时候正确的 AI 操作不是回答。
例子可能包括：
因此，好的上下文不仅包括事实，还包括决策边界。
大型上下文窗口创造了一个可以理解诱惑：
“为什么不发送一切？”
因为一切包含噪声。
如果有人问关于未付款发票的问题，系统可能需要：
它可能不需要：
给模型完成正确任务所需的最少量可信上下文。
这提高了相关性，并使问题更容易诊断。
团队有时在 AI 项目中首先尝试组织每个公司文档。
在 AI 提供任何价值之前，这可能变成一个巨大的知识管理项目。
更好的方法是选择一个重要的工作流。
客户支持退款问题：
AI 需要知道什么？
现在确定每个项目的权威来源。
| 上下文 | 来源 |
|---|---|
| 客户 | CRM |
| 购买订单 | 数据库 |
| 产品 | 产品数据库 |
| 退款政策 | 知识库 |
| 之前的案例 | 帮助台 |
| 例外 | 经理审批系统 |
突然之间，问题变得更容易管理了。
团队通常通过阅读最终回复来评估 AI。
这是必要的，但不够充分。
一个光鲜的回答仍然可能基于错误的信息。
有用的问题包括：
员工需要因为 AI 误解情况而纠正它的频率是多少？
这将评估从：
“这个回复听起来智能吗？”
转变为：
“系统是否使用正确的信息做出了正确的决策？”
这是一个更有用的生产指标。
如果你今天正在构建业务 AI 应用程序，从这里开始：
你不需要在第一天就建立一个庞大的企业架构。
你只需要为你试图改进的工作流提供可靠的上下文。
下一代业务 AI 不会仅仅通过组织使用的模型来区分。
许多公司将能使用强大的模型。
更大的差异将来自围绕这些模型的东西：
通用模型可以理解这句话：
“我们应该批准这个吗？”
一个有用的业务 AI 系统需要理解：
“这里的批准意味着什么，哪些规则适用，哪些信息是最新的，谁在问，以及什么时候应该由人做出最终决定？”
这就是令人印象深刻的 AI 演示与人们实际上可以在工作中使用的系统之间的差距。
有关上下文层、RAG、上下文漂移、治理、CRM 集成、测量和实施步骤的更深入分析，请参阅 CatchAIInfo 的完整 AI 业务上下文精炼指南。