【系统架构设计】AI 原生架构：LLM 时代的系统设计
内容提要
本文探讨AI原生架构中LLM作为运行时依赖的工程挑战，涵盖与传统RPC的差异、超时与预算传播、成本治理、不确定输出校验、Agent编排与checkpoint、可观测性及与RAG的边界。核心观点：LLM调用需分层管理，采用双级超时、token预算、schema硬闸门、人审机制及决策模式追踪，并给出优先级建议。
延伸解读
LLM 依赖与传统 RPC 的本质差异
文章指出，LLM 调用与传统 RPC 在输出确定性、延迟构成、计费单位、失败语义等方面存在本质差异。传统 RPC 输出近似确定，而 LLM 输出受采样影响；延迟由 Prefill 和 Decode 组成，且与 token 数强相关；计费按 token 而非 QPS；失败不仅是错误码，还包括幻觉、格式错误等。因此，架构上需将“传输成功”与“业务可接受输出”拆分为两层 SLA，不能简单将 HTTP 200 视为依赖成功。
双级超时与预算传播的实践要点
文章提出 LLM 系统需设置两级超时：单次 completion 超时和整段任务超时。预算传播遵循从外向内分配剩余时间的原则，编排器在每轮调用前检查剩余时间，若不足则停止新轮次。工具调用超时需短于 LLM 轮次剩余时间，并行子任务共享父 deadline。流式与非流式模式需分别配置超时，流式可提前取消节省 token，但终态校验需在流结束后进行。
成本治理：从网关到编排器的分层预算
文章强调 LLM 成本与 prompt 长度、轮次、模型单价、并行 Agent 数耦合，需在架构上定义预算包络。网关层负责硬顶 enforcement，如租户日预算、单次请求 token 上限；编排器负责软顶，如接近预算时减少子 Agent 数、切换小模型。还需设置 token-rate limit 和并发限制，防止单租户拖垮集群。429 错误应退避而非盲目重试，避免重试风暴和双倍计费。
不确定输出的校验与治理策略
文章区分传输正确、契约正确和业务正确三层。契约校验（如 JSON schema）应作为硬闸门，失败时不执行工具或写库；业务校验（如事实准确性）作为软闸门，可触发人审或降级。修复循环应有上限（如最多 2 次），避免 token 黑洞。高风险操作需人审闸门，触发条件应确定性而非依赖模型判断。可回放追踪需记录模型版本、prompt 模板、采样参数等，便于调试和合规。
Q&A
LLM作为运行时依赖与传统RPC在架构上有哪些关键差异？
LLM依赖与传统RPC在多个维度存在差异：输出不确定性（相同输入可能产生不同输出）、延迟构成（Prefill+Decode，受token数影响）、计费单位（按token计费）、失败语义（HTTP 200但内容可能错误）、重试收益（重试可能得到不同答案且增加成本）、上下文约束（token级窗口限制）以及状态性（Agent多轮对话天然有状态）。
如何为LLM调用设计超时和预算传播机制？
采用两级超时模型：L1单次completion超时，L2任务/会话超时。Deadline从入口网关通过X-Request-Deadline或traceparent传播，编排器在每轮LLM调用前计算剩余时间，若不足则进入winding-down。工具调用超时取剩余时间与工具超时的较小值。并行Subagent共享父deadline，避免各自独立超时导致总时间失控。
在AI原生架构中，如何治理LLM调用的成本？
成本治理需要网关层和编排器协同：网关实施租户/团队日预算、单次请求token上限等硬顶；编排器实施Agent任务预算软顶，接近预算时压缩策略（减少Subagent数、切换小模型）。同时需要token-rate limit和concurrency limit防止单租户拖垮集群，并限制Agent fan-out（如Subagent数量上限）。
如何校验LLM的不确定输出并确保工具调用安全？
区分传输正确、契约正确和业务正确。契约正确通过schema硬闸门校验，失败则不执行工具或写库；业务正确通过软闸门（LLM-as-judge、规则引擎、人审）。工具调用需授权分离、执行沙箱、副作用闸门（高风险操作需HITL）。可回放追踪记录模型版本、prompt版本、采样参数等，便于调试。
Agent编排中同步与异步模式如何选择？
同步模式适合用户在线等待、Subagent数量有限、合并逻辑简单的场景；异步模式适合任务超过1-2分钟、Subagent可独立交付artifact、需要先返回task_id的场景。异步必须配套任务状态API、进度通知、取消语义和partial result存储。
在LLM可观测性中，如何在不记录对话内容的情况下追踪决策模式？
通过记录非内容信号：拓扑（agent_role、parent_span_id）、工具（tool_name、latency）、模型（model_id、token数）、策略（effort_tier、subagent_count）、质量代理（schema_valid、citation_count）。使用OpenTelemetry GenAI语义约定，将tool loop每轮作为child span。告警基于决策模式指标，如subagent_spawn_p99、tool_call_loop_count等。
应用架构层与RAG/向量引擎的边界如何划分？
应用层负责编排、预算、校验、人审、trace语义和Agent生命周期；RAG管道（文档解析、切片、embedding、检索、重排）属于llm-infra；向量引擎负责索引、ANN搜索、标量过滤。应用层通过固定检索API契约（query, top_k, filters, tenant_id）与RAG层交互，不直接访问向量库。
