AI 系统全景：模型、知识、工具、规则、评测与基础设施如何协作？

大语言模型已经能够理解问题、分析信息、生成代码甚至通过工具执行操作。但当我们真正把 AI 接入业务系统时会发现一个问题模型能力越来越强为什么构建一个可靠的 AI 应用仍然需要知识库、工具、业务规则、评测系统和基础设施原因在于模型只是 AI 系统中的一个组成部分。模型可以分析故障却不一定掌握当前的运行状态可以提出解决方案却不一定有权限执行可以调用工具却不一定能判断业务目标是否真正达成。要让 AI 从回答问题走向解决实际问题就需要理解一个完整 AI 系统的组成结构以及这些部分如何协作。一、先建立 AI 系统的整体认识可以把一个企业 AI 应用理解为一套围绕业务目标组织起来的系统。当用户提出问题时系统需要接收请求、获取必要信息、进行分析、判断下一步行动并在需要时调用业务能力。操作完成后还要验证结果是否符合预期。这个过程涉及多个不同的组成部分。模型理解请求、分析信息、生成答案和提出行动建议。知识系统提供文档、规范、历史案例等参考资料。工具与业务接口连接数据库、业务 API、监控系统等外部能力。规则与工作流约束业务条件、执行顺序、审批和失败处理。评测与可观测性判断系统是否可靠并帮助定位问题。AI 基础设施提供模型运行、计算资源、服务部署和运行保障。这些组件不是相互独立的功能清单而是共同构成一条从请求到业务结果的执行链路。例如用户询问某项订单为什么退款失败系统可能需要先查询订单状态再检索退款规则结合当前数据分析原因。如果需要执行退款还必须检查权限、退款条件和审批要求最后验证退款状态。模型负责分析并不意味着它可以代替所有其他环节。二、模型负责理解与分析但不等于整个系统大语言模型是 AI 应用的核心能力之一。它可以理解自然语言提取问题中的关键信息归纳不同来源的内容并根据上下文生成回答。但模型的能力有明确边界。1. 模型不一定掌握最新的业务状态假设用户询问“这笔订单为什么退款失败”模型可能知道常见的退款失败原因却不知道这笔订单当前的支付状态、退款记录或具体错误码。这些信息必须从实际业务系统中获取。2. 模型的判断不等于事实模型可能根据现有信息提出一个合理的解释但合理不代表已经得到验证。因此涉及重要业务判断时系统需要区分事实、推断和未知信息。3. 模型生成的操作建议不等于操作已经完成模型可以建议关闭某项服务、重启应用或执行退款但真正执行这些操作需要相应的业务能力和权限控制。模型提供智能分析能力整个应用则负责把分析转化为可靠的业务结果。三、知识系统让模型获得回答问题所需的依据模型并不一定天然掌握企业内部的操作手册、产品规范、历史故障记录和最新业务知识。这时可以通过外部知识系统提供相关资料。一种常见方案是 RAG即检索增强生成Retrieval-Augmented Generation。它的基本流程是用户提出问题。系统从知识库中检索相关资料。将检索结果与用户问题一起交给模型。模型结合这些资料生成回答。例如运维人员询问“应用升级失败后应该怎么恢复”系统可以从运维手册中检索版本回滚流程再让模型根据相关内容解释操作步骤。不过知识检索并不能解决所有问题。如果需要确认当前部署的是哪个版本系统仍然需要查询部署平台如果需要确认某项操作是否获得审批则需要读取审批系统中的实际状态。因此知识系统主要解决的是“有哪些相关知识可以作为依据”而不是代替所有业务数据查询和操作。四、工具让 AI 能够连接真实业务系统如果模型只能读取文字并生成回答它的能力主要停留在信息处理层面。当应用需要获取实时数据或执行操作时就需要工具。工具可以是一个查询接口、一个业务 API也可以是能够执行特定操作的程序。例如查询订单及退款状态。获取服务器监控指标。查询最近的部署记录。创建运维工单。调用经过授权的退款或回滚接口。模型可以根据任务需要选择调用哪个工具并生成相应的参数应用程序负责校验参数、执行调用并处理结果。在工具接入方面Function Calling函数调用是一种常见机制模型输出结构化的工具调用请求由应用程序实际执行相应函数再将结果交回模型继续处理。MCPModel Context Protocol模型上下文协议则提供了一种标准化的方式让兼容的 AI 应用连接外部工具和数据资源。需要注意MCP 本身不是业务执行引擎。无论通过哪种方式接入工具实际操作仍然由工具实现及其背后的业务系统完成。工具调用也可能失败例如网络超时、参数错误、权限不足或业务状态不符合要求。因此系统不能只看模型有没有发出调用请求还需要检查真实的执行结果。五、规则与工作流让系统按照约束执行模型具有一定的灵活性但企业业务通常存在一些不能随意改变的约束。例如退款金额不能超过允许的范围。某些操作必须经过人工审批。未获得权限的用户不能执行生产环境操作。失败后最多允许重试一次。操作结果不明确时不能直接重复执行有副作用的请求。这些约束不能只寄希望于模型每次都能正确理解。1. 规则系统负责明确的业务条件规则系统适合处理可以明确表达的条件和判断。例如退款是否满足业务规定可以依据订单状态、退款金额、时间范围等条件进行判断。当规则明确时应尽量通过可验证的程序逻辑执行而不是让模型每次自由推断。2. 工作流负责组织执行过程Workflow工作流用于组织任务的步骤、分支和状态转换。例如退款流程可以规定检查订单状态 → 校验退款条件 → 发起审批 → 执行退款 → 查询退款结果。如果审批未通过流程就不能进入退款执行阶段。工作流也可以规定失败后的处理方式例如最多重试一次仍然失败就停止并报告。3. 模型判断与确定性约束需要协作在一些场景中系统需要模型分析不确定的问题同时又必须遵守明确的执行规则。例如运维 Agent 可以分析日志并提出回滚建议但是否允许执行回滚需要由权限系统、业务规则和工作流共同约束。这并不意味着所有系统都必须使用独立的规则引擎或复杂工作流。简单应用可以通过普通程序逻辑实现这些约束只有当业务复杂度和治理要求增加时才需要更明确的组件划分。六、把这些组件连接起来一个完整的运维案例假设支付服务出现大量超时系统需要分析原因并在必要时采取行动。整个过程可以分为以下阶段。阶段一获取证据系统接收到告警后先获取必要的运行信息。从知识库检索故障处理手册和历史案例。从监控平台查询错误率、响应时间和资源使用情况。从部署平台查询最近的版本变更记录。知识文档提供排查方法实时监控提供当前状态部署记录提供变更事实。阶段二分析问题模型结合这些信息分析可能的原因。例如它发现错误率上升与最近一次部署的时间接近因此提出“新版本可能引发异常”的假设。但时间上的关联还不足以证明因果关系。系统可能需要进一步检查日志、依赖服务和版本差异。阶段三判断是否执行操作如果证据支持回滚方案Agent 可以提出回滚建议。接下来系统需要检查当前版本是否允许回滚。操作是否在授权范围内。是否必须经过人工审批。回滚操作是否存在重复执行的风险。只有满足相应条件工作流才允许进入执行阶段。阶段四执行并验证工具调用回滚接口后系统还需要检查实际状态。例如确认部署版本是否已经恢复、服务健康检查是否通过以及错误率是否回到预期范围。如果接口返回成功但服务仍未恢复就不能直接宣布任务完成。这个案例说明可靠的 AI 应用并不是让模型一次性给出所有答案而是让模型、知识、工具、规则和工作流在各自职责范围内协作并通过实际结果验证任务是否成功。七、评测与可观测性怎样知道系统是否可靠即使系统已经连接模型、知识库和工具也不能由此推断它能够稳定完成任务。需要通过评测和运行记录分别检查系统的质量与执行情况。1. 评测回答质量可以建立固定测试集检查模型是否理解问题、是否使用正确依据、答案是否符合预期。对于知识问答还需要检查检索结果是否相关以及答案是否得到检索证据支持。2. 评测工具使用与任务完成情况对于需要执行操作的系统还需要检查是否选择了正确的工具。参数是否正确。是否遵守权限和审批要求。是否正确处理超时和失败。最终业务目标是否真正完成。回答正确率不能代替端到端任务成功率。3. 记录运行过程可观测性用于帮助开发人员理解系统实际发生了什么。例如系统可以记录请求编号、检索结果、模型调用、工具执行状态、耗时、异常和最终结果。当用户反馈“AI 没有正确处理退款”时这些记录可以帮助定位问题究竟来自数据、检索、模型判断、工具调用还是业务流程。4. 使用固定测试验证修改效果如果调整了检索策略、模型或工作流应使用相同的测试用例比较修改前后的表现。除了答案质量还应关注任务成功率、安全约束、响应时间和运行成本。不能因为某个案例成功了就认定整个系统已经可靠。八、AI 基础设施让能力能够稳定运行前面讨论的是 AI 应用的逻辑组成部分但这些能力最终需要运行在真实的计算和软件环境中。这就是 AI 基础设施AI InfrastructureAI Infra发挥作用的地方。它涉及多个方面计算资源CPU、GPU 等处理器以及内存、显存和存储。模型服务模型加载、推理执行、请求调度和服务接口。数据与网络数据读取、服务通信、存储和传输。运行管理部署、扩缩容、监控、故障恢复和资源管理。例如当多个用户同时调用模型时系统不仅需要考虑模型能否回答问题还需要考虑并发请求、响应延迟、资源使用和服务稳定性。如果模型服务不可用或者工具接口频繁超时上层 Agent 和工作流就可能无法完成任务。不过并不是每个 AI 应用都需要自己部署模型或建设复杂的基础设施。使用云端模型 API也是一种合理的架构选择。具体采用哪种方式应结合业务要求、成本、安全和运维能力判断。九、不同规模的 AI 应用应该如何组合这些能力系统设计不应该从“需要使用多少种技术”出发而应该从业务目标和风险出发。场景一简单文本处理例如总结一段文字、改写一封邮件。可能只需要模型调用和基本的输入输出校验。场景二企业知识问答需要回答内部规范、操作流程等问题。可以在模型之外增加知识检索、访问控制、引用依据和答案评测。场景三实时业务查询例如查询订单状态、监控指标或部署版本。除了知识能力还需要连接真实业务数据源并处理工具调用失败和数据时效性问题。场景四自动执行复杂任务例如分析告警、发起审批、执行回滚并验证恢复结果。这类系统可能需要 Agent、工作流、业务规则、权限控制、状态管理、评测与运行监控的协同。应用越接近真实业务执行越需要明确操作边界和结果验证机制。总结AI 系统不是单个大模型的简单封装而是围绕业务目标组织起来的一套协作体系。模型提供理解和分析能力知识系统提供参考依据工具连接真实业务系统规则与工作流控制业务约束和执行过程评测与可观测性帮助判断质量和定位故障AI 基础设施则保障这些能力能够稳定运行。这些组件并非越多越好也不需要在每个项目中全部独立部署。合理的设计应当根据任务复杂度、风险和实际需求选择必要能力并明确各组件的职责边界。衡量一个 AI 系统是否可靠不只是看模型能不能回答问题更要看系统能否基于可靠证据作出判断、在约束范围内执行操作并通过真实结果验证业务目标是否达成。参考资料Lewis 等《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》https://arxiv.org/abs/2005.11401Model Context Protocol 官方文档https://modelcontextprotocol.io/OpenAI Agents SDKhttps://developers.openai.com/api/docs/guides/agents/sdkOpenAI Agents 中的 Guardrails 与 Human Reviewhttps://developers.openai.com/api/docs/guides/agents/guardrails-approvalsOpenAI Agents 中的 Integrations 与 Observabilityhttps://developers.openai.com/api/docs/guides/agents/integrations-observability