AI Agent 跑通 Demo 却栽在生产环境：缺的是业务上下文层
AI Agent 在演示中表现出色，但进入生产后往往做出不符合业务的决策——模型不缺推理能力，缺的是客户资格、合同条款、审批策略等业务上下文。解决思路是在 prompt 之外构建独立业务上下文层，而非一味换模型。
完整中文译文
AI Agent 在推理、调用工具、搜索文档和完成多步骤任务方面越来越强大。
然而，许多团队在 AI 系统从演示进入实际业务运营后，发现了同样的令人沮丧的问题：
模型听起来很智能，但它并不理解业务。
试想一个客户问道：
“续费能给我 15% 的折扣吗？”
一个能力强的语言模型理解折扣是什么。它很可能能写出一份极好的回复。
但它不会自动知道：
- 这个客户是否有资格获得折扣，
- 他们目前使用什么套餐，
- 他们的合同何时到期，
- 客户经理是否已经批准了一个优惠，
- 当前的定价政策允许什么，
- 超过 10% 的折扣是否需要审批，
- 或者该客户是否有未解决的支持问题。
模型可能完美地理解了语言，但仍然做出了错误的业务决策。
这就是为什么生产环境中的 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 连接到真实工作流程时，这个区别非常重要。
为什么仅靠 RAG 不能解决问题
检索增强生成（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
这就是上下文架构变得比简单创建嵌入向量和运行向量相似性搜索更有趣的地方。
一个有用的业务 AI 心智模型
简化的生产架构可能如下所示：
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 应该能够回答的五个问题
在允许 AI Agent 执行有意义的业务工作之前，测试你的架构是否能回答这些问题。
1. 这些信息意味着什么？
内部术语可能出乎意料地难以理解。
Qualified Lead
Active Customer
Priority Account
Revenue
High Risk Enterprise
这些词在你的组织内部可能有精确的定义。
如果模型使用通用含义而不是公司特定的含义，即使检索正常工作，下游决策也可能出错。
为重要概念创建业务术语表。
2. 我应该信任哪个来源？
企业经常在多个位置存储相同的信息。
产品价格可能出现在：
- 定价数据库
- 产品数据库
- 知识库
- 归档文档
你的 AI 需要知道哪个系统是权威的。
一个简单的来源层次结构可以防止许多错误：
Pricing Database
↓
Approved Product Database
↓
Current Knowledge Base
↓
Archived Documents
检索质量不仅仅关乎相关性。
3. 这些信息仍然是最新的吗？
业务信息老化很快。
- 员工换岗
- 产品停产
- 政策被取代
- 客户状态变化
六个月前完全正确的文档今天可能成为危险的上下文。
有用的元数据包括：
created_at
updated_at
effective_from
expires_at
version
owner
status
这使得检测我们所说的上下文漂移（context drift）更容易：AI 可用的信息不再匹配当前业务现实的情况。
4. 用户是否有权访问它？
相关信息不一定是授权信息。
假设员工问：
“总结我们对这个客户了解的一切。”
你的检索系统可能在技术上找到：
- 销售笔记
- 发票
- 法律文件
- 内部财务数据
- 安全事件
但这不意味着每个员工都应该收到每条记录。
上下文检索应该继承或执行访问控制。
context = retrieve(
query=user_query,
role=current_user.role,
permissions=current_user.permissions
)
生产实现会更复杂，但原则很简单：
授权应该在敏感上下文到达模型之前发生。
5. AI 应该回答还是升级？
有时候正确的 AI 操作不是回答。
例子可能包括：
- 异常大的折扣
- 高风险账户变更
- 敏感的员工请求
- 冲突的权威来源
因此，好的上下文不仅包括事实，还包括决策边界。
更多的上下文实际上可能使 AI 变得更糟
大型上下文窗口创造了一个可以理解诱惑：
“为什么不发送一切？”
因为一切包含噪声。
如果有人问关于未付款发票的问题，系统可能需要：
- 适用的计费政策
- 最近的计费沟通
它可能不需要：
- 三年的营销邮件
- 工程文档
- 员工手册
- 每个历史支持工单
- 不相关的产品文档
给模型完成正确任务所需的最少量可信上下文。
这提高了相关性，并使问题更容易诊断。
从一个工作流开始
团队有时在 AI 项目中首先尝试组织每个公司文档。
在 AI 提供任何价值之前，这可能变成一个巨大的知识管理项目。
更好的方法是选择一个重要的工作流。
客户支持退款问题：
AI 需要知道什么？
- 当前退款政策
- 之前的案例历史
现在确定每个项目的权威来源。
| 上下文 | 来源 |
|---|---|
| 客户 | CRM |
| 购买订单 | 数据库 |
| 产品 | 产品数据库 |
| 退款政策 | 知识库 |
| 之前的案例 | 帮助台 |
| 例外 | 经理审批系统 |
突然之间，问题变得更容易管理了。
衡量上下文，而不仅仅是输出
团队通常通过阅读最终回复来评估 AI。
这是必要的，但不够充分。
一个光鲜的回答仍然可能基于错误的信息。
有用的问题包括：
- 系统是否检索到了任务所需的信息？
- 它是否使用了权威来源？
- 信息是最新的吗？
- 重要的声明是否可以追溯到可用的业务信息？
- AI 是否只访问了适合该用户的信息？
- 交互是否实际完成了预期的业务目标？
人工纠正率
员工需要因为 AI 误解情况而纠正它的频率是多少？
这将评估从：
“这个回复听起来智能吗？”
转变为：
“系统是否使用正确的信息做出了正确的决策？”
这是一个更有用的生产指标。
一个实用的起点清单
如果你今天正在构建业务 AI 应用程序，从这里开始：
- [ ] 选择一个高价值工作流
- [ ] 定义正确的结果是什么样的
- [ ] 确定所需的上下文
- [ ] 将每个上下文项映射到其权威来源
- [ ] 定义重要的业务术语
- [ ] 添加新鲜度/版本元数据
- [ ] 应用用户权限
- [ ] 仅检索与任务相关的信息
- [ ] 定义人工升级条件
- [ ] 测试正常情况和边缘情况
- [ ] 跟踪检索失败
- [ ] 捕获人工纠正
- [ ] 持续更新上下文
你不需要在第一天就建立一个庞大的企业架构。
你只需要为你试图改进的工作流提供可靠的上下文。
下一代业务 AI 不会仅仅通过组织使用的模型来区分。
许多公司将能使用强大的模型。
更大的差异将来自围绕这些模型的东西：
- 可信的 business knowledge
- 持续的 feedback
通用模型可以理解这句话：
“我们应该批准这个吗？”
一个有用的业务 AI 系统需要理解：
“这里的批准意味着什么，哪些规则适用，哪些信息是最新的，谁在问，以及什么时候应该由人做出最终决定？”
这就是令人印象深刻的 AI 演示与人们实际上可以在工作中使用的系统之间的差距。
有关上下文层、RAG、上下文漂移、治理、CRM 集成、测量和实施步骤的更深入分析，请参阅 CatchAIInfo 的完整 AI 业务上下文精炼指南。