很多知识库、RAG、办公 Agent 项目在演示阶段都跑得很顺，但真正上线后，Token 成本往往不是突然爆掉，而是随着知识规模、上下文长度、使用人数和任务链路复杂度的增长慢慢失控。问题不在于"问了多少次"，而在于每次调用背后的检索、拼接、生成和工具调用越来越重。本文拆解这类项目最常见的成本放大机制。

很多团队做 Agent 工具调用时，最自然的起点是把现有 REST API 包一层变成 MCP Server。这最快，但也最容易踩坑。MCP Server 不是把 REST API 原样包装一遍——工具名称、描述、JSON Schema、粒度、错误信息、发现机制，每一个都会直接影响模型调用准确率和上下文成本。本文用 checklist 结构列出 Agent 工具调用设计最容易踩的 5 个坑：工具描

很多团队做 AI Agent 时，精力都放在模型能力上：选哪个模型、推理够不够强、上下文窗口够不够长。但 Agent 真正上线之后，最容易出问题的往往不是模型变笨了，而是工具调用链路失控——选错工具、传错参数、副作用不可回滚、权限边界没守住。模型能力有上限，但工具调用是开放的，工具数量会涨、参数组合会变、副作用会叠加。本文拆解 Agent 上线后最容易失控的 4 个环节，以及一个最小可用的工具调用

很多团队做 AI Agent 时，精力都放在模型能力上：选哪个模型、推理够不够强、上下文窗口够不够长。但 Agent 真正上线之后，最容易出问题的往往不是模型变笨了，而是工具调用链路失控——选错工具、传错参数、副作用不可回滚、权限边界没守住。模型能力有上限，但工具调用是开放的，工具数量会涨、参数组合会变、副作用会叠加。本文拆解 Agent 上线后最容易失控的 4 个环节，以及一个最小可用的工具调用

很多团队一提 AI 应用成本，第一反应都是看用户问答：单次调用贵不贵、多轮对话长不长、上下文是不是太胖。但真正上线之后，最容易持续把 Token 烧爆的，往往不是用户正面看到的那次问答，而是后台那些“看起来合理、实际上长期失控”的调用链路。本文拆解最常见的 4 类后台高耗调用，以及为什么它们最容易被忽略。

AI 应用从 Demo 到正式上线，真正难的往往不是模型效果，而是工程能力补齐的优先级。如果资源有限，不可能一口气把监控、限流、路由、配额、审计、灰度全部补完。第 6 篇已经给出了完整上线 Checklist，这一篇只讨论一件事：如果预算和人力只够先补 3 项能力，技术负责人到底该怎么选，为什么这样选，以及顺序错了会付出什么代价。

在知识库、Agent、AI 编程等场景中，单次请求的上下文长度往往远超简单问答。而上下文越长，输入 Token 越多，成本和延迟都会同步上升。很多团队的第一反应是"换便宜模型"或"砍上下文"，但真正有效的成本控制，需要从检索策略、上下文拼接、缓存复用和分层路由四个维度来系统优化。本文附伪代码示例。

本文包含一个 16 项大模型应用上线 Checklist，涵盖压测工具、降级阈值、监控方案和审计参数。很多团队把"模型接通了、效果还行"当成里程碑，但从接入成功到业务真正上线，中间还有一段很多人低估的距离——并发能力、异常处理、成本可控、调用追踪、权限管理、灰度发布，这些工程问题不解决，模型就只是"能跑"，不是"能用"。

很多团队在日常使用中觉得直接调模型 API 完全够用，但一到业务高峰就会集中暴露问题。本文以一个典型的 AI 客服系统高峰期故障为案例，还原从"系统崩溃"到"逐步修复"的完整过程——限流被打穿、路由无法切换、成本失控、故障无法定位、事后无法复盘。这 5 个坑不是个例，而是大多数直接调模型的团队迟早会遇到的共性问题。