LLM 应用开发架构指南

先想清楚复杂度阶梯

很多 LLM 应用死在过度设计：把一个翻译需求包成 Agent，或在提示链上堆满框架。本技能把方案收敛为四层阶梯，L1 单次调用、L2 提示链、L3 工具调用、L4 Agent，并坚持从最低层开始。

• L1 适合翻译、摘要、分类、改写这类“输入进、输出出”的任务。
• L2 把任务拆成固定步骤，例如 大纲 → 写作 → 润色，每步只干一件事。
• L3 在需要外部数据或操作时出现，例如查库、调 API、搜索、算数。
• L4 只在步骤不固定、需要动态规划时使用；Agent 的自由度等于不确定性。

资料里给了明确反模式警告：80% 的“我要做个 Agent”需求，用 L2/L3 就能更稳定、更便宜、更快。

把工程细节落到四件套

架构不是画完图就结束，真正决定稳定性的是提示链、记忆、工具和 Agent 的具体约束。

• 提示链：步与步之间传 JSON，不传自然语言；抽取类步骤把 temperature 设为 0，创作类再提高；中间结果落日志，坏了能定位。
• 记忆管理：把上下文当成稀缺资源。滑动窗口适合轻量客服，摘要压缩适合长咨询，关键信息抽取适合个性化，外部检索适合超长周期场景。
• 工具调用：工具描述要写清“什么时候用、参数含义、返回什么”；工具数量控制在 10 个以内；返回结果先聚合再塞给模型；所有调用必须有超时与失败兜底。
• Agent：同时满足步骤不固定、有完成判据、允许更高延迟与成本时才上。还要加最大循环数硬限制、每步动作留痕、高危操作人工确认门。

别把 demo 当生产

Demo 和生产之间隔着成本、延迟、可靠性三座山。技能给出的治理清单也很工程化：

• 成本上，简单任务用小模型，复杂任务才上旗舰；相同问题加缓存；按用户或功能监控 token 消耗并告警。
• 延迟上，用户可见路径用流式输出，首 token 时间控制在 2s 内；能并行的链式步骤并行跑；长任务转异步通知。
• 可靠性上，结构化输出用 JSON mode/schema 约束，但仍要做解析容错；关键路径准备降级方案；建立 50～200 条真实 case 的评测集，改 prompt 或换模型后跑回归。

框架是选项，不是前提

L1/L2 场景下，裸调 API 加 100 行封装通常最可控；需要快速试验多种链路、团队多人协作时，框架才更有价值。选框架前先问：文档全吗？社区活跃吗？抽象泄漏时你能读懂源码吗？技能不会替你拍板技术栈，也不会虚构框架 API 细节。

适用边界

这套内容适合已经明确要做 LLM 应用、需要架构决策和工程约束的开发者与团队。它提供方法论和清单，具体框架 API、模型价格、限流策略仍需查官方文档；最终架构也要结合团队技术栈与运维能力判断。