W
AI-Wiki
CONCEPT

上下文感知式业务集成

定义

上下文感知式业务集成，是指 Agent 在对话过程中不再只是根据文字生成回复，而是同时具备两类关键能力：读取业务上下文与调用业务动作。

它的核心不是“用户问一句，模型答一句”的单向问答，而是让模型接触应用内部状态，并把自然语言请求转换成对前端能力、后端接口或业务服务的实际调用。

在本文语境中，这种集成方式被用来解决传统 AI 聊天组件与业务系统脱节的问题。Agent 不再悬浮在系统之外，而是与用户信息、订单接口、退款接口、页面状态等能力耦合，形成“对话即操作”的交互层。

在本文档中的语境

该概念出自一篇介绍 CopilotKit 的实战文章。文章将其视为 Agent-Native应用开发框架 的关键能力之一，与运行时、聊天 UI、生成式UI 并列。

作者指出，很多 AI Agent demo 的问题不在于不能聊天，而在于：

  • AI 输出与应用状态割裂，难以在对话中直接查询或操作业务；
  • 即使模型能理解意图，也缺少与订单、售后、数据报表等真实系统的连接；
  • 最终效果往往只是一个独立聊天窗口，而不是可落地的业务助手。

因此，这里所谓的“上下文感知”，不是泛指模型记住聊天历史，而是强调模型能够读取开发者注入的业务上下文，并进一步调用注册过的业务动作。

关键机制

1. 业务上下文注入：通过 Context Provider 暴露应用状态

文章中的接入方式，是先通过 Context Provider 向 Agent 注入可读取的上下文。示例里使用了 CopilotContext.Provider，把运行时和业务上下文一起传入应用。

被注入的上下文并不是抽象描述，而是明确的应用内部数据与服务，例如：

  • 用户信息：user.id = '12345'、user.name = '张三'；
  • 订单查询服务：getOrder(orderId)，底层请求 /api/orders/${orderId}；
  • 售后申请服务：applyRefund(orderId)，底层以 POST 调用 /api/refund/${orderId}。

这说明 上下文感知式业务集成 中的“上下文”既包含静态身份信息，也包含可被后续动作使用的业务服务入口。它不是只给模型一段提示词，而是把真实系统中的状态和能力有控制地暴露出来。

2. 动作注册：通过 Action Hook 声明 Agent 可执行的业务能力

仅有上下文还不够。文章进一步通过 useCopilotAction 注册 Agent 可以执行的具体动作。

这一步的作用是把“模型理解用户意图”与“系统执行哪个业务操作”连接起来。动作一般包含：

  • name：动作名；
  • description：该动作的业务含义；
  • parameters：结构化参数定义；
  • handler：真正执行调用的函数。

这种设计意味着 Agent 不是自由地任意访问系统，而是在开发者预先声明的动作集合里执行。也就是说，可调用能力是“注册出来的”，不是模型天然拥有的。

3. 从自然语言到业务调用的转换

在该模式下，用户先用自然语言表达需求，例如“我的订单 12345 状态如何？”。模型识别出这是订单查询意图后，不是只生成一段猜测性的客服话术，而是选择调用与之匹配的动作，例如 get_order_status。

随后系统把订单号作为结构化参数传给动作处理器，再由处理器去调用真实接口、拿到结果并返回。

这就是 上下文感知式业务集成 的关键链路：

  1. 用户提出自然语言请求；
  2. 模型结合当前业务上下文理解意图；
  3. 选择已注册的业务动作；
  4. 动作调用前端或后端服务；
  5. 系统把结果回填给用户，必要时还能生成 UI。

订单查询示例

文章给出的最具体示例，是“查询订单状态”动作。

开发者通过 useCopilotAction 注册了一个名为 get_order_status 的动作，其定义包含以下要点：

  • 动作名称：get_order_status；
  • 描述：查询指定订单的当前状态；
  • 参数模式：一个对象；
  • 必填参数：orderId；
  • 参数类型：orderId 为字符串。

其 handler 执行过程也很明确：

  1. 调用 copilotContext.services.getOrder(orderId)；
  2. 等待接口返回；
  3. 解析 response.json()；
  4. 从结果中读取 status 与 logistics；
  5. 返回结果文本：订单${orderId}状态：${data.status}，最新物流：${data.logistics}。

文中明确说明，当用户提出订单状态问题后，Agent 能自动识别“订单查询”意图，并触发这个动作。这里的关键不是模型自己编造订单信息，而是它把语言理解转译成了 getOrder 接口调用。

从集成角度看，这个例子体现了两个事实：

  • 模型识别的是意图；
  • 真正产生业务结果的是已接入的系统接口。

因此，上下文感知式业务集成 的本质是“LLM 做理解与编排，业务系统做事实提供与动作执行”。

与生成式界面的关系

虽然该概念的核心是“上下文 + 动作”，但文章同时展示了它如何与 生成式UI 配合。

例如在销售报表动作中，处理器调用 /api/sales/report 获取最近 30 天数据后，不仅返回文本，还能通过 generativeUI 返回 React 组件，直接渲染图表。

这说明业务集成的结果不必局限于文本回复，还可以进一步变成页面上的表格、按钮、图表等可交互界面。

不过要注意，上下文感知式业务集成 与 生成式UI 不是同一个概念：

  • 前者强调 AI 与业务状态、业务服务的打通；
  • 后者强调执行结果如何以界面形式呈现。

两者结合后，才更接近完整的 Agent-Native 业务交互。

业务价值

1. 让 AI 成为业务流程的一部分

文章反复强调，这种模式的最大价值，是把 AI 从“独立聊天机器人”变成“业务流程的一部分”。

也就是说，Agent 不只是回答咨询，而是能实际参与：

  • 查询订单；
  • 发起售后；
  • 读取报表；
  • 结合当前用户和页面状态给出下一步操作。

这种能力尤其适合电商客服、运营后台、企业流程系统等场景，因为用户真正需要的往往不是一段解释，而是一个被执行的动作。

2. 缩短从 demo 到生产的距离

如果没有这种集成，开发者通常需要分别处理：

  • LLM 接入；
  • 上下文同步；
  • 工具或接口调用；
  • 聊天 UI；
  • 页面状态联动。

文章认为，CopilotKit 通过运行时、上下文注入、动作注册和 UI 组件的组合，把这些工作标准化了。于是开发者更容易把精力放在业务逻辑本身，而不是重复搭建底层胶水层。

3. 提升交互真实性

当 Agent 回答来自真实订单接口、退款接口和销售接口时，用户感受到的不是“AI 很会说”，而是“系统真的在帮我做事”。

这也是 上下文感知式业务集成 与普通问答机器人的根本区别：它输出的价值来自业务系统，而不只来自语言模型。

边界、风险与约束

1. 敏感上下文泄露风险

文章明确提醒，copilotContext 中可能包含敏感信息，例如用户 ID。由于这些内容会进入 Agent 可访问的上下文范围，如果处理不当，存在被模型暴露给用户或带入不必要生成结果中的风险。

因此需要使用 mask 等过滤配置，对敏感字段做脱敏或限制暴露范围。