一次 LLM 请求的一生全景图
从用户输入一句话，到模型生成、流式返回、日志追踪、成本归因和质量回流：把 AI 应用的完整运行链路串起来
阅读定位: 这一页是 AI 分支的横向贯穿页。它不替代 Token / Attention、训练 / 推理、能力边界、向量检索、推理计算、推理模型、模型评测、Tool Calling、Prompt、RAG、Agent、AI 编程 Agent、模型服务、LLMOps 或安全专题，而是把这些专题放进一次真实请求的时间顺序里。
如果你已经知道每个组件，但还没形成“请求从哪里来、在哪里变贵、在哪里变慢、在哪里出错”的整体感，应先读这一页；需要逐字段排障模板时，下钻到
请求 Trace / 可观测性模板；需要证据字段总表时，回到
AI 证据包索引。
用户输入
意图 / 权限
→
上下文组装
Prompt / 历史
→
增强与工具
RAG / Agent
→
网关路由
模型 / 策略
→
模型推理
Prefill / Decode
→
返回与后处理
Stream / 格式
→
运营闭环
Trace / Eval / Cost
| 阶段 | 系统做了什么 | 关键指标 | 最容易出问题的地方 |
|---|
| 输入接收 | 识别用户、会话、权限、任务类型和风险等级 | 请求量、入口失败率、权限命中 | 身份边界不清、恶意输入、任务意图误判 |
| 上下文组装 | 拼 System Prompt、历史、记忆、工具结果和业务约束 | 输入 token、上下文命中率、模板版本 | 上下文过长、指令冲突、污染和陈旧记忆 |
| 增强与工具 | 按需检索知识、调用工具、拆分任务或进入 Agent 循环 | 检索命中、工具成功率、步骤数 | 检索噪声、工具越权、循环失控 |
| 网关路由 | 选择模型、供应商、区域、限流、Fallback 和价格策略 | 路由分布、排队时间、降级率 | 单模型依赖、降级不一致、成本不可见 |
| 模型推理 | Tokenize、Prefill、Decode、采样、KV Cache 管理 | TTFT、tokens/s、P95 / P99、显存 | 长上下文慢、输出过长、批处理抖动 |
| 返回后处理 | 流式输出、结构校验、引用、敏感信息过滤和前端呈现 | 首屏体验、格式错误率、审核拦截率 | JSON 破损、引用错位、流式中断 |
| 运营闭环 | 记录 trace、成本、质量标签、用户反馈和坏例样本 | 单位成本、质量分、回归失败率 | 不可追踪、无法复盘、优化无依据 |
| 请求类型 | 典型链路 | 主要瓶颈 | 不要漏掉的治理点 |
|---|
| 普通 Chat | 输入 → Prompt / 历史 → 路由 → 推理 → 流式返回 | 上下文膨胀、输出过长、模型选择过重 | 历史裁剪、max tokens、质量 / 成本分层 |
| RAG 问答 | 输入 → query rewrite → 检索 / 重排 → 引用拼装 → 推理 | 检索噪声、证据位置、Prefill 成本 | 文档权限、引用可追溯、Top-K 与上下文预算 |
| 工具调用 | 输入 → 工具选择 → 参数生成 → 执行 → 结果回填 → 最终回答 | 工具失败、参数错误、权限越界 | schema 校验、幂等、人工确认和审计日志 |
| Agent 长任务 | 输入 → 计划 → 多轮模型 / 工具 / 观察循环 → 检查点 → 汇总 | 步骤数、状态污染、预算失控、错误累积 | 最大步数、阶段验收、可恢复状态和中途取消 |
| 代码 / 仓库任务 | 输入 → 仓库检索 → 补丁生成 → 测试 → 迭代 → 说明 | 上下文选择、测试成本、误改无关文件 | diff 范围、测试证据、回滚边界和代码审计 |
| 结构化输出 | 输入 → schema / 约束 → 推理 → 解析校验 → 修复 / 重试 | JSON 破损、字段遗漏、采样不稳 | 严格 schema、低温度、解析失败样本和回退路径 |
用户输入
- 自然语言、文件、图片、代码片段、表格或多模态混合输入
- 同一句话在不同产品位置，可能代表完全不同任务
- 输入越开放，越需要分类、权限和风险判断
业务上下文
- 用户身份、组织、角色、订阅等级、地区和数据权限
- 当前页面、当前对象、业务状态和可执行动作
- 决定模型能看什么、能做什么、该保守还是该主动
安全预检
- Prompt 注入、敏感信息、越权请求、危险操作意图
- 高风险任务应提前标记，后续走更严格模型和审核链路
- 不要把所有安全问题都留到模型输出后再处理
关键直觉
LLM 请求不是“用户文本 + 模型 API”这么简单。真正进入模型前，它已经带上身份、权限、任务、历史、业务对象和风险等级。很多生产事故不是模型本身坏，而是入口把不该放进去的信息放进去了，或把不该执行的意图放行了。
| 上下文材料 | 来源 | 作用 | 风险 |
|---|
| System Prompt | 产品和平台配置 | 定义角色、边界、格式和优先级 | 过长、矛盾、版本不可追踪 |
| 开发者 / 业务指令 | 功能模块、任务模板 | 把通用模型约束到具体业务流程 | 和系统指令冲突，或被用户输入覆盖 |
| 历史对话 | 会话存储 | 保持连续性和用户偏好 | 过期信息、错误累积、token 膨胀 |
| 长期记忆 | 用户画像、摘要、向量记忆 | 跨会话个性化和任务延续 | 记忆污染、隐私边界、不可解释 |
| 检索材料 | RAG、搜索、数据库 | 补充最新、专有或可引用知识 | 检索错误、过多噪声、引用不可靠 |
| 工具结果 | API、代码执行、工作流 | 让模型基于真实系统状态回答或行动 | 工具错误、权限越界、格式不稳定 |
上下文预算就是产品预算
上下文越长，Prefill 越贵，TTFT 越慢，错误材料进入模型的机会也越多。好的上下文工程不是“多塞信息”，而是按任务选择最少、最新、最可信、最有约束力的信息。
RAG 请求
- 问题需要私有知识、最新事实或引用来源时触发
- 链路是 query rewrite → 检索 → 重排 → 上下文拼装
- 核心风险是“检到了不该信的内容”，而不是没调模型
工具调用请求
- 需要读取实时状态、执行动作或调用外部能力时触发
- 工具 schema、参数校验、幂等性和错误返回都很重要
- 敏感工具必须有权限校验和人工确认边界
Agent 请求
- 任务需要多步规划、观察、行动和修正时进入 Agent 循环
- 每一步都可能再次触发模型请求、工具调用和上下文重组
- 必须限制最大步数、预算、权限和失败恢复策略
| 判断问题 | 更可能的方案 | 原因 |
|---|
| 答案是否依赖外部资料？ | RAG / 搜索 | 让模型基于可追溯材料回答，减少凭记忆编造 |
| 是否需要改变系统状态？ | 工具调用 / 工作流 | 模型负责决策和参数，真正动作由受控工具执行 |
| 是否需要多步探索和反馈？ | Agent | 单次生成不适合长任务，Agent 需要状态和循环控制 |
| 是否只是格式化、分类、摘要？ | 直接模型请求 | 简单任务不必引入复杂编排，避免成本和不稳定性 |
| 网关动作 | 它回答的问题 | 常见策略 | 观测指标 |
|---|
| 认证与配额 | 谁能调用，能调用多少？ | API key、租户配额、用户限流、优先级 | 拒绝率、限流率、租户消耗 |
| 模型路由 | 这个请求该走哪个模型？ | 按任务、成本、延迟、风险、上下文长度路由 | 路由分布、质量分、单位成本 |
| 缓存策略 | 是否可以减少重复计算？ | Prompt Cache、语义缓存、系统提示缓存 | 命中率、节省 token、缓存错误率 |
| Fallback | 失败或拥堵时怎么办？ | 换供应商、换小模型、缩短上下文、关闭非关键能力 | 降级率、恢复时间、用户影响 |
| 审计与策略 | 哪些请求需要记录、拦截或复核？ | 敏感操作、合规场景、高风险输出、组织策略 | 拦截率、审核通过率、审计完整性 |
为什么网关不是简单代理
当系统进入多模型、多团队、多成本中心和多风险等级以后，网关就是模型能力的交通系统。它决定请求走哪条路、花多少钱、失败怎么退、日志在哪里汇总，以及组织能否真正复盘 AI 行为。
Tokenize
→
Embedding
→
Prefill
→
KV Cache
→
Decode Loop
→
Sampling
→
Stream
| 环节 | 发生了什么 | 为什么影响体验 / 成本 |
|---|
| Tokenize | 文本被切成 token id | token 数决定上下文窗口、计费、Prefill 规模和输出长度 |
| Embedding | token id 变成向量 | 进入 Transformer 计算链路，和位置编码共同形成初始表示 |
| Prefill | 一次性处理完整输入上下文 | 输入越长，首 token 前等待越久，RAG 长上下文尤其明显 |
| KV Cache | 缓存历史 attention 的 Key / Value | 减少重复计算，但会占用显存，影响并发和长上下文容量 |
| Decode Loop | 逐 token 生成输出 | 输出越长，总耗时越高；这是流式体验和成本的核心变量 |
| Sampling | 按温度、top-p、约束选择下一个 token | 影响稳定性、创造性、格式遵循和幻觉概率 |
| Streaming | 把生成中的 token 持续返回给用户 | 改善感知速度，但不等于总成本下降 |
TTFT 与总耗时不是一回事
TTFT 主要受入口排队、上下文长度、Prefill 和网关调度影响；总耗时还受输出长度、Decode 速度、工具调用次数和后处理影响。优化时要先拆指标，不能只说“模型慢”。
格式与结构校验
- JSON、表格、函数参数和引用格式需要校验
- 失败时可以修复、重试、回退模板或转人工
- 结构化输出失败常常是生产系统的隐性大坑
安全与合规后处理
- 敏感信息、违规内容、高风险建议和越权结果要二次检查
- 对外产品尤其需要输出护栏和审计记录
- Agent 行动结果需要和权限系统再次对齐
前端体验
- 流式输出、取消、重试、引用展开和错误提示影响用户信任
- 失败时要告诉用户能做什么，而不是只显示“生成失败”
- 好体验来自可恢复链路，不只是快，可继续下钻到 AI 产品 UX
| 记录对象 | 应该记录什么 | 用来做什么 |
|---|
| 请求 Trace | prompt 版本、模型、路由、RAG 片段、工具调用、延迟分段 | 定位慢、错、贵和不稳定的根因 |
| 成本归因 | 输入 token、输出 token、缓存命中、模型单价、租户和功能归属 | 判断哪个功能值得优化、降级或收费 |
| 质量反馈 | 用户点赞踩、人工标签、LLM-as-Judge、任务成功率 | 建设评测集、回归测试和数据飞轮 |
| 安全审计 | 敏感输入、拦截原因、工具权限、人工确认、输出风险 | 合规追溯、事故复盘和策略改进 |
| 坏例样本 | 失败输入、错误输出、期望输出、上下文快照 | 用于 Prompt 修订、RAG 调优、微调或路由策略迭代 |
没有 Trace，就没有 AI 工程
传统服务的日志能告诉你接口有没有错；AI 服务还要告诉你模型为什么被这样喂、为什么走这个模型、为什么检到这些材料、为什么花了这些 token。没有请求级 Trace，后续评测、成本、安全和质量改进都会悬空。
| 问题 | 必要字段 | 用于定位什么 |
|---|
| 谁发起了请求？ | tenant、user role、入口功能、地域、权限快照 | 越权、配额、成本归属和合规范围 |
| 请求要解决什么任务？ | task type、风险等级、用户意图分类、产品场景 | 路由错误、评测切片和产品指标归因 |
| 模型看到了什么？ | prompt 版本、上下文片段、历史摘要、记忆 key、RAG 文档 id | 幻觉、引用错误、上下文污染和隐私泄露 |
| 为什么走这个模型？ | routing rule、候选模型、fallback 原因、策略版本 | 质量 / 成本 / 延迟取舍是否符合预期 |
| 推理为什么慢？ | queue、TTFT、prefill、decode、output tokens、重试次数 | 入口排队、长上下文、长输出和供应商抖动 |
| 工具做了什么？ | tool name、参数、权限校验、执行结果、错误码、确认记录 | 工具越权、状态副作用和 Agent 跑飞 |
| 它花了多少钱？ | input / output tokens、cache hit、model price、功能归属 | 单位任务成本、缓存收益和商业化定价 |
| 输出有没有被改写？ | 后处理规则、结构化校验、审核拦截、重试修复 | 最终答案和原始模型输出不一致的原因 |
| 用户是否满意？ | 采纳、点赞踩、人工接管、纠错、后续重试 | 线上质量、任务成功率和坏例回流 |
| 能否复现？ | request id、版本快照、随机参数、依赖数据版本、脱敏上下文 | 事故复盘、回归测试和发布回滚 |
| 字段组 | 建议字段 | 必须能回答的问题 | 常见缺口 |
|---|
| 身份与入口 | request_id、session_id、tenant_id、user_id_hash、role、entrypoint、client_version、region | 谁从哪里发起，归属哪个租户和功能？ | 只有接口日志，没有产品入口和租户维度 |
| 任务与风险 | task_type、intent_label、risk_tier、policy_profile、human_review_required、user_visible_mode | 这是什么任务，应该走多强的控制链？ | 把所有请求都当普通 Chat，无法做分层治理 |
| 上下文快照 | prompt_template_id、prompt_version、rendered_prompt_hash、system_prompt_hash、history_summary_id、memory_keys、context_token_count | 模型到底看到了哪一版指令和上下文？ | 只存用户输入，不存模板版本和渲染后摘要 |
| RAG 与证据 | query_rewrite_id、index_id、retriever_version、top_k、reranker_version、doc_ids、chunk_ids、source_versions、evidence_token_count | 答案依赖哪些材料，材料当时是什么版本？ | 只存最终回答，不存检索候选和证据版本 |
| 工具与连接器 | tool_name、tool_version、connector_id、resource_uri_hash、arguments_hash、permission_decision、approval_id、tool_latency_ms、tool_status | 模型要求做什么动作，系统是否允许，结果怎样？ | 工具执行脱离模型 Trace，事故时拼不回完整链路 |
| 路由与模型 | route_rule_id、candidate_models、selected_model、provider、model_version、fallback_from、fallback_reason、temperature、top_p、max_tokens | 为什么选这个模型和参数，是否发生降级？ | 只知道调用了某模型，不知道路由依据和 fallback |
| 推理分段 | queue_ms、prefill_ms、ttft_ms、decode_ms、total_latency_ms、input_tokens、output_tokens、finish_reason、retry_lineage | 慢在哪里，是输入长、排队、解码慢还是重试多？ | 只有总耗时，无法区分 TTFT 和输出阶段 |
| 成本与缓存 | prompt_cache_hit、semantic_cache_hit、cache_key_hash、input_cost、output_cost、tool_cost、total_cost、cost_center | 钱花在输入、输出、工具还是重复请求上？ | 成本只按供应商账单汇总，不能归因到功能 |
| 输出与安全 | raw_output_hash、final_output_hash、schema_validation_status、citation_check_status、guardrail_actions、redaction_actions、blocked_reason | 最终给用户看的内容是否被校验、改写或拦截？ | 只看最终文本，忽略后处理和护栏动作 |
| 反馈与回放 | user_feedback、acceptance_signal、human_label、judge_score、failure_tag、replay_bundle_id、eval_case_id、release_version | 这个请求能否进入坏例、评测、回归和发布复盘？ | 反馈和请求日志分离，无法沉淀成评测资产 |
Trace 模板的底线
不一定每个字段都永久保存原文，但至少要保存可追踪的版本、hash、id、状态和分段指标。隐私敏感场景可以脱敏或分级留存；但如果连 request_id、prompt 版本、模型版本、检索材料、工具动作、token、延迟、成本和反馈都拼不起来，这个 AI 系统就很难被调优、审计或复现。
| 决策点 | 必须留下的证据 | 用于回答的问题 | 缺失后的后果 |
|---|
| 权限裁决 | tenant_id、user_id_hash、policy_version、decision_id、allow / deny、reason、data_scope、tool_scope | 这次请求凭什么能看这些数据、调用这些工具？ | 越权、泄露或误拒时只能猜测当时策略 |
| 路由选择 | task_type、risk_tier、sla_tier、budget_tier、candidate_models、selected_model、route_rule_id | 为什么不是更便宜、更快或更强的模型？ | 质量退化和成本异常无法归到具体路由规则 |
| Fallback 尝试 | attempt_id、fallback_from、fallback_to、fallback_reason、retry_count、stop_reason | 失败发生在哪里，重试或降级是否符合策略？ | 重试链路变成黑箱，慢请求和贵请求难以解释 |
| 成本延迟归因 | input_tokens、output_tokens、queue_ms、ttft_ms、decode_ms、tool_latency_ms、attempt_cost、total_cost | 钱和时间分别花在首轮、重试、工具还是降级链路上？ | 只能看到账单和总耗时，无法做定点优化 |
| 质量与复盘 | quality_score、guardrail_actions、user_feedback、eval_case_id、replay_bundle_id | 这条路径是否值得保留，坏例能否回放？ | 线上反馈不能沉淀为评测样本和修复证据 |
一次请求要像一笔账
真正可运营的 AI 请求，不只是“输入、模型、输出”三段日志，而是一条决策账本：权限为什么放行，路由为什么这样选，失败为什么 fallback，成本延迟花在哪里，坏例怎样回放。
| 目标 | 先看哪些证据 | 常见有效动作 | 错误动作 |
|---|
| 降低首 token 延迟 | TTFT 分段、输入 token、队列、缓存命中 | Prompt 瘦身、RAG 压缩、Prompt Cache、长短请求分池 | 只换更大模型，或盲目提高并发 |
| 降低总耗时 | 输出 token、decode tokens/s、工具步骤、重试次数 | 限制输出长度、分步流式、减少工具往返、推测解码 | 只优化 prefill，却放任长答案无上限 |
| 降低单位成本 | 模型分布、输入 / 输出 token、缓存、失败重试、租户归因 | 小模型优先、复杂任务升级、语义缓存、批处理后台化 | 统一降级到小模型，导致质量和人工成本反弹 |
| 提升正确率 | 失败样本、引用片段、任务切片、人工标签、Judge 解释 | 改检索、改 Prompt、补评测集、调整路由或微调 | 只看平均分，不看关键任务失败 |
| 降低安全风险 | 风险标签、拦截原因、工具权限、敏感数据来源、审计链 | 输入预检、工具限权、输出护栏、人工确认、红队回归 | 只在最终输出处过滤，忽略工具执行前的风险 |
| 回放步骤 | 先找什么证据 | 判断问题 | 下一步去向 |
|---|
| 锁定入口 | request_id、tenant_id、entrypoint、task_type、risk_tier | 这是不是同一类任务的系统性问题，还是某个租户 / 功能的局部问题？ | 分流到产品、权限、成本或安全 owner |
| 还原模型看到的材料 | prompt_version、rendered_prompt_hash、context_pack_id、dropped_segments、memory_keys | 错误是否来自 Prompt 版本、历史污染、记忆误写或上下文截断？ | 上下文组装 / Prompt |
| 重放 RAG | query_rewrite_id、index_version、retrieved_doc_ids、chunk_order、citation_ids、no_answer_reason | 是漏召、错召、过期知识、权限过滤，还是模型没有忠实使用证据？ | RAG / Grounding |
| 重放工具和 Agent | tool_call_id、arguments_hash、permission_decision、observation_id、retry_count、terminal_condition | 工具是否被错误选择、参数是否漂移、权限是否正确、循环是否失控？ | Tool Calling / Agent |
| 拆模型与网关 | route_rule_id、selected_model、fallback_reason、queue_ms、prefill_ms、decode_ms、finish_reason | 慢、贵或质量退化是否来自路由、Fallback、长上下文、重试或模型版本？ | 模型网关 / 模型路由 |
| 核验输出与反馈 | raw_output_hash、final_output_hash、schema_status、guardrail_actions、user_feedback、failure_tag | 最终给用户看的内容是否被后处理改写，坏例是否已经进入评测和回归？ | LLMOps / 反馈闭环 |
| 形成证据包 | replay_bundle_id、eval_case_id、incident_id、release_version、fixed_version | 这次失败能否复现、能否证明修复、能否支持发布或回滚决策？ | AI 证据包索引 / 审计证据链 |
坏例不是一句“模型答错了”
一个可修复的坏例，至少要能还原入口、上下文、检索、工具、路由、生成、后处理和反馈。只有当 request_id 能生成 replay_bundle、eval_case 或 incident_candidate，团队才真正拥有了持续改进的入口。
| 现象 | 可能根因 | 优先排查 |
|---|
| 首 token 很慢 | 上下文过长、Prefill 重、队列拥堵、网关路由慢 | 输入 token、TTFT 分段、排队时间、缓存命中率 |
| 回答贵但价值低 | 大模型滥用、输出过长、RAG 塞太多、无缓存 | 模型路由、max tokens、Top-K、单位功能成本 |
| 回答看似合理但错误 | 检索噪声、幻觉、上下文冲突、评测缺失 | 引用片段、评测集、RAG 命中和重排结果 |
| Agent 跑飞 | 工具权限过大、最大步数缺失、状态污染、错误恢复差 | 步骤 Trace、工具调用参数、权限策略、预算限制 |
| 输出格式经常坏 | 提示不稳定、schema 复杂、采样过发散、缺少校验修复 | 结构化输出约束、温度、重试策略、解析错误样本 |
| 安全问题频发 | 输入预检弱、间接注入、工具越权、后处理缺失 | 安全策略、RAG 文档来源、工具授权、审计日志 |