大语言模型已经能够理解问题、分析信息、生成代码，甚至通过工具执行操作。但当我们真正把 AI 接入业务系统时，会发现一个问题：

模型能力越来越强，为什么构建一个可靠的 AI 应用，仍然需要知识库、工具、业务规则、评测系统和基础设施？

原因在于，模型只是 AI 系统中的一个组成部分。

模型可以分析故障，却不一定掌握当前的运行状态；可以提出解决方案，却不一定有权限执行；可以调用工具，却不一定能判断业务目标是否真正达成。

要让 AI 从回答问题走向解决实际问题，就需要理解一个完整 AI 系统的组成结构，以及这些部分如何协作。

一、先建立 AI 系统的整体认识

可以把一个企业 AI 应用理解为一套围绕业务目标组织起来的系统。

当用户提出问题时，系统需要接收请求、获取必要信息、进行分析、判断下一步行动，并在需要时调用业务能力。操作完成后，还要验证结果是否符合预期。

这个过程涉及多个不同的组成部分。

• 模型：理解请求、分析信息、生成答案和提出行动建议。
• 知识系统：提供文档、规范、历史案例等参考资料。
• 工具与业务接口：连接数据库、业务 API、监控系统等外部能力。
• 规则与工作流：约束业务条件、执行顺序、审批和失败处理。
• 评测与可观测性：判断系统是否可靠，并帮助定位问题。
• AI 基础设施：提供模型运行、计算资源、服务部署和运行保障。

这些组件不是相互独立的功能清单，而是共同构成一条从请求到业务结果的执行链路。

例如，用户询问某项订单为什么退款失败，系统可能需要先查询订单状态，再检索退款规则，结合当前数据分析原因。如果需要执行退款，还必须检查权限、退款条件和审批要求，最后验证退款状态。

模型负责分析，并不意味着它可以代替所有其他环节。

二、模型：负责理解与分析，但不等于整个系统

大语言模型是 AI 应用的核心能力之一。

它可以理解自然语言，提取问题中的关键信息，归纳不同来源的内容，并根据上下文生成回答。

但模型的能力有明确边界。

1. 模型不一定掌握最新的业务状态

假设用户询问：“这笔订单为什么退款失败？”

模型可能知道常见的退款失败原因，却不知道这笔订单当前的支付状态、退款记录或具体错误码。

这些信息必须从实际业务系统中获取。

2. 模型的判断不等于事实

模型可能根据现有信息提出一个合理的解释，但合理不代表已经得到验证。

因此，涉及重要业务判断时，系统需要区分事实、推断和未知信息。

3. 模型生成的操作建议不等于操作已经完成

模型可以建议关闭某项服务、重启应用或执行退款，但真正执行这些操作，需要相应的业务能力和权限控制。

模型提供智能分析能力，整个应用则负责把分析转化为可靠的业务结果。

三、知识系统：让模型获得回答问题所需的依据

模型并不一定天然掌握企业内部的操作手册、产品规范、历史故障记录和最新业务知识。

这时可以通过外部知识系统提供相关资料。

一种常见方案是 RAG，即检索增强生成（Retrieval-Augmented Generation）。

它的基本流程是：

1. 用户提出问题。
2. 系统从知识库中检索相关资料。
3. 将检索结果与用户问题一起交给模型。
4. 模型结合这些资料生成回答。

例如，运维人员询问：“应用升级失败后应该怎么恢复？”

系统可以从运维手册中检索版本回滚流程，再让模型根据相关内容解释操作步骤。

不过，知识检索并不能解决所有问题。

如果需要确认当前部署的是哪个版本，系统仍然需要查询部署平台；如果需要确认某项操作是否获得审批，则需要读取审批系统中的实际状态。

因此，知识系统主要解决的是“有哪些相关知识可以作为依据”，而不是代替所有业务数据查询和操作。

四、工具：让 AI 能够连接真实业务系统

如果模型只能读取文字并生成回答，它的能力主要停留在信息处理层面。

当应用需要获取实时数据或执行操作时，就需要工具。

工具可以是一个查询接口、一个业务 API，也可以是能够执行特定操作的程序。

例如：

• 查询订单及退款状态。
• 获取服务器监控指标。
• 查询最近的部署记录。
• 创建运维工单。
• 调用经过授权的退款或回滚接口。

模型可以根据任务需要选择调用哪个工具，并生成相应的参数；应用程序负责校验参数、执行调用并处理结果。

在工具接入方面，Function Calling（函数调用）是一种常见机制：模型输出结构化的工具调用请求，由应用程序实际执行相应函数，再将结果交回模型继续处理。

MCP（Model Context Protocol，模型上下文协议）则提供了一种标准化的方式，让兼容的 AI 应用连接外部工具和数据资源。

需要注意，MCP 本身不是业务执行引擎。无论通过哪种方式接入工具，实际操作仍然由工具实现及其背后的业务系统完成。

工具调用也可能失败，例如网络超时、参数错误、权限不足或业务状态不符合要求。因此，系统不能只看模型有没有发出调用请求，还需要检查真实的执行结果。

五、规则与工作流：让系统按照约束执行

模型具有一定的灵活性，但企业业务通常存在一些不能随意改变的约束。

例如：

• 退款金额不能超过允许的范围。
• 某些操作必须经过人工审批。
• 未获得权限的用户不能执行生产环境操作。
• 失败后最多允许重试一次。
• 操作结果不明确时，不能直接重复执行有副作用的请求。

这些约束不能只寄希望于模型每次都能正确理解。

1. 规则系统负责明确的业务条件

规则系统适合处理可以明确表达的条件和判断。

例如，退款是否满足业务规定，可以依据订单状态、退款金额、时间范围等条件进行判断。

当规则明确时，应尽量通过可验证的程序逻辑执行，而不是让模型每次自由推断。

2. 工作流负责组织执行过程

Workflow（工作流）用于组织任务的步骤、分支和状态转换。

例如，退款流程可以规定：

检查订单状态 → 校验退款条件 → 发起审批 → 执行退款 → 查询退款结果。

如果审批未通过，流程就不能进入退款执行阶段。

工作流也可以规定失败后的处理方式，例如最多重试一次，仍然失败就停止并报告。

3. 模型判断与确定性约束需要协作

在一些场景中，系统需要模型分析不确定的问题，同时又必须遵守明确的执行规则。

例如，运维 Agent 可以分析日志并提出回滚建议，但是否允许执行回滚，需要由权限系统、业务规则和工作流共同约束。

这并不意味着所有系统都必须使用独立的规则引擎或复杂工作流。简单应用可以通过普通程序逻辑实现这些约束；只有当业务复杂度和治理要求增加时，才需要更明确的组件划分。

六、把这些组件连接起来：一个完整的运维案例

假设支付服务出现大量超时，系统需要分析原因，并在必要时采取行动。

整个过程可以分为以下阶段。

阶段一：获取证据

系统接收到告警后，先获取必要的运行信息。

• 从知识库检索故障处理手册和历史案例。
• 从监控平台查询错误率、响应时间和资源使用情况。
• 从部署平台查询最近的版本变更记录。

知识文档提供排查方法，实时监控提供当前状态，部署记录提供变更事实。

阶段二：分析问题

模型结合这些信息分析可能的原因。

例如，它发现错误率上升与最近一次部署的时间接近，因此提出“新版本可能引发异常”的假设。

但时间上的关联还不足以证明因果关系。系统可能需要进一步检查日志、依赖服务和版本差异。

阶段三：判断是否执行操作

如果证据支持回滚方案，Agent 可以提出回滚建议。

接下来，系统需要检查：

• 当前版本是否允许回滚。
• 操作是否在授权范围内。
• 是否必须经过人工审批。
• 回滚操作是否存在重复执行的风险。

只有满足相应条件，工作流才允许进入执行阶段。

阶段四：执行并验证

工具调用回滚接口后，系统还需要检查实际状态。

例如，确认部署版本是否已经恢复、服务健康检查是否通过，以及错误率是否回到预期范围。

如果接口返回成功，但服务仍未恢复，就不能直接宣布任务完成。

这个案例说明，可靠的 AI 应用并不是让模型一次性给出所有答案，而是让模型、知识、工具、规则和工作流在各自职责范围内协作，并通过实际结果验证任务是否成功。

七、评测与可观测性：怎样知道系统是否可靠？

即使系统已经连接模型、知识库和工具，也不能由此推断它能够稳定完成任务。

需要通过评测和运行记录，分别检查系统的质量与执行情况。

1. 评测回答质量

可以建立固定测试集，检查模型是否理解问题、是否使用正确依据、答案是否符合预期。

对于知识问答，还需要检查检索结果是否相关，以及答案是否得到检索证据支持。

2. 评测工具使用与任务完成情况

对于需要执行操作的系统，还需要检查：

• 是否选择了正确的工具。
• 参数是否正确。
• 是否遵守权限和审批要求。
• 是否正确处理超时和失败。
• 最终业务目标是否真正完成。

回答正确率不能代替端到端任务成功率。

3. 记录运行过程

可观测性用于帮助开发人员理解系统实际发生了什么。

例如，系统可以记录请求编号、检索结果、模型调用、工具执行状态、耗时、异常和最终结果。

当用户反馈“AI 没有正确处理退款”时，这些记录可以帮助定位问题究竟来自数据、检索、模型判断、工具调用，还是业务流程。

4. 使用固定测试验证修改效果

如果调整了检索策略、模型或工作流，应使用相同的测试用例比较修改前后的表现。

除了答案质量，还应关注任务成功率、安全约束、响应时间和运行成本。

不能因为某个案例成功了，就认定整个系统已经可靠。

八、AI 基础设施：让能力能够稳定运行

前面讨论的是 AI 应用的逻辑组成部分，但这些能力最终需要运行在真实的计算和软件环境中。

这就是 AI 基础设施（AI Infrastructure，AI Infra）发挥作用的地方。

它涉及多个方面：

• 计算资源：CPU、GPU 等处理器，以及内存、显存和存储。
• 模型服务：模型加载、推理执行、请求调度和服务接口。
• 数据与网络：数据读取、服务通信、存储和传输。
• 运行管理：部署、扩缩容、监控、故障恢复和资源管理。

例如，当多个用户同时调用模型时，系统不仅需要考虑模型能否回答问题，还需要考虑并发请求、响应延迟、资源使用和服务稳定性。

如果模型服务不可用，或者工具接口频繁超时，上层 Agent 和工作流就可能无法完成任务。

不过，并不是每个 AI 应用都需要自己部署模型或建设复杂的基础设施。使用云端模型 API，也是一种合理的架构选择。具体采用哪种方式，应结合业务要求、成本、安全和运维能力判断。

九、不同规模的 AI 应用，应该如何组合这些能力？

系统设计不应该从“需要使用多少种技术”出发，而应该从业务目标和风险出发。

场景一：简单文本处理

例如总结一段文字、改写一封邮件。

可能只需要模型调用和基本的输入输出校验。

场景二：企业知识问答

需要回答内部规范、操作流程等问题。

可以在模型之外增加知识检索、访问控制、引用依据和答案评测。

场景三：实时业务查询

例如查询订单状态、监控指标或部署版本。

除了知识能力，还需要连接真实业务数据源，并处理工具调用失败和数据时效性问题。

场景四：自动执行复杂任务

例如分析告警、发起审批、执行回滚并验证恢复结果。

这类系统可能需要 Agent、工作流、业务规则、权限控制、状态管理、评测与运行监控的协同。

应用越接近真实业务执行，越需要明确操作边界和结果验证机制。

总结

AI 系统不是单个大模型的简单封装，而是围绕业务目标组织起来的一套协作体系。

模型提供理解和分析能力，知识系统提供参考依据，工具连接真实业务系统，规则与工作流控制业务约束和执行过程，评测与可观测性帮助判断质量和定位故障，AI 基础设施则保障这些能力能够稳定运行。

这些组件并非越多越好，也不需要在每个项目中全部独立部署。合理的设计应当根据任务复杂度、风险和实际需求选择必要能力，并明确各组件的职责边界。

衡量一个 AI 系统是否可靠，不只是看模型能不能回答问题，更要看系统能否基于可靠证据作出判断、在约束范围内执行操作，并通过真实结果验证业务目标是否达成。

参考资料

1. Lewis 等，《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》：https://arxiv.org/abs/2005.11401
2. Model Context Protocol 官方文档：https://modelcontextprotocol.io/
3. OpenAI Agents SDK：https://developers.openai.com/api/docs/guides/agents/sdk
4. OpenAI Agents 中的 Guardrails 与 Human Review：https://developers.openai.com/api/docs/guides/agents/guardrails-approvals
5. OpenAI Agents 中的 Integrations 与 Observability：https://developers.openai.com/api/docs/guides/agents/integrations-observability