踩坑与经验总结

Q：Agent 的成本怎么控制？线上烧钱太快怎么办？

来源：Agent 岗面试高频题

新手答：“用更便宜的模型。”

高手答：

换模型是最后的手段，换了可能效果也打折。成本控制要从架构层面系统性地做：

1. 分级调度：不是所有步骤都需要最强模型。意图识别、参数校验这种简单任务用小模型（7B / 14B），只有核心推理环节才用大模型。一个任务里可能 80% 的调用走小模型，只有 20% 走大模型
2. Token 预算制：每个任务有 token 预算上限，执行过程中实时统计。接近预算时自动触发“省钱模式”——压缩上下文、跳过非必要步骤、简化输出
3. 缓存复用：相似请求的中间结果做缓存。比如“查北京天气”这种高频工具调用，5 分钟内的结果直接复用，不重复调用 API 也不重复让模型处理
4. 超预算熔断：单用户单日消费超过阈值，自动限流或降级。这不只是省钱，也是防止恶意用户用 prompt injection 让 Agent 无限循环烧钱

差距在哪：新手的”换模型”是一维思考——只在模型选择上做文章。高手的方案是四维的：调度策略（谁用什么模型）、预算控制（花多少停）、缓存复用（重复的不花）、熔断保护（异常的不让花）。面试官考的是”你有没有成本意识和系统设计能力”——这和后端系统的限流、降级、熔断是同一套思路。

追问：开源 Agent 框架（如 LobeChat）为什么特别容易烧 token？

来源：字节实习二面

LobeChat 等开源 Agent 框架烧 token 的原因不是框架本身”浪费”，而是默认配置追求通用性而非经济性：

1. 全量对话历史注入：每次请求把完整对话历史发给模型，10 轮对话后上下文可能已经 8000+ token，但其中大部分和当前问题无关。没有做摘要压缩或滑动窗口
2. System Prompt 膨胀：支持多种场景的通用 System Prompt 往往很长（2000+ token），每次请求都重复发送
3. 插件/工具描述全量加载：即使用户只需要搜索功能，所有已安装插件的 schema 都会写进 tools 参数，每次调用都消耗 token
4. 缺少缓存层：相似问题每次都重新调模型，没有语义缓存。尤其高频场景（”今天天气””最新新闻”）可以直接返回缓存结果
5. 模型选择不分级：所有任务都走同一个大模型，没有根据任务复杂度做路由——简单的意图识别和复杂的推理任务用同样贵的模型

优化方向就是上面四条策略的具体化：压缩历史、动态加载工具 schema、加语义缓存、做模型路由。

---

Q：为什么很多 Agent Demo 很惊艳，但一上线就不稳定？

来源：腾讯大模型应用开发二面

新手答：“因为线上环境比 Demo 复杂。”

高手答：

Demo 往往是在理想条件下演示的——输入干净、工具有限、单次任务、短上下文。模型只要看起来会做事就行了。但线上环境完全不一样：

Demo 环境：理想输入、有限工具、单次任务、短上下文
线上环境：输入脏、任务长、工具多、状态复杂、异常频繁、权限安全约束

Demo 能跑通，只能说明“这个方向可能”。线上稳定，说明的是你把模型的不确定性关进了工程笼子里。

真正难的是做治理，不是做演示。很多团队一开始觉得问题在模型不够强，后来才发现大量问题其实来自状态管理、工具设计、上下文污染和缺少容错机制。

差距在哪：新手只说了“环境复杂”——这是现象不是分析。高手指出了 Demo 和生产环境的具体差异（输入质量、任务长度、状态管理、异常处理），且点出了核心观点：“稳定不靠模型强，靠工程治理”。面试官考的是你有没有把 Agent 从 Demo 推到生产的实战经验。

---

Q：开发 Agent 时踩过什么坑？

来源：Agent 岗面试高频题

新手答：“模型有时候不听话，输出格式不对。”

高手答：

坑太多了，挑几个最痛的：

坑一：死循环——模型反复调同一个工具

模型调了一个工具拿到错误结果，然后用一模一样的参数再调一次，无限循环。

解法：① 加失败计数器，同一工具连续失败 2 次直接终止该路径；② 每次重试前让模型先分析上次失败原因，强制改变参数或策略；③ 超过全局步数上限（比如 15 步）直接结束，输出当前最优结果。

坑二：状态丢失——多轮对话里关键信息不翼而飞

用户在第 3 轮说了“预算 5000 以内”，到第 10 轮模型推荐了个 8000 的方案。不是模型故意忽略，是上下文太长被截断了，或者关键信息被淹没。

解法：① 关键参数实时抽取，写入独立的状态存储（Redis / 数据库），不依赖上下文承载；② 每次调用模型时，把当前任务的关键约束作为 System Prompt 的一部分强制注入，而不是埋在历史消息里；③ 定期用模型做自检——“当前任务的约束条件有哪些？”，发现遗漏立刻补回来。

坑三：JSON 解析翻车——模型输出“差一点点”的 JSON

模型返回的 JSON 格式上“几乎正确”——多了个逗号、少了个引号、在 JSON 前面加了句“好的，以下是结果：”。用 json.loads() 直接崩。

解法：① 用正则先提取 JSON 块（匹配 \{...\} 或 [...]），再解析；② 用 json-repair 之类的库做容错解析；③ 最根本的解法：用模型原生的 function calling / structured output，不要让模型自己拼 JSON 字符串。

坑四：成本失控——一个任务烧掉几十块

复杂任务里模型思考了 30 步，每步都带完整上下文，token 量指数级增长。一个用户的一次请求可能烧掉几十块钱。

解法：① 限制每轮 token 数上限，每个 Agent 有独立的 token 预算；② 实时监控单任务累计成本，超过阈值自动告警并降级（比如切换到更便宜的模型）；③ 上下文管理做好——中间结果落库、历史消息压缩，从源头减少 token 消耗。

差距在哪：新手只能说出一个笼统的“输出格式不对”。高手每个坑都有三层结构：① 具体的故障现象（什么情况下出的）；② 根因分析（为什么会这样）；③ 系统性的解法（不是临时 patch，而是工程化方案）。面试官考的是“你踩过坑之后有没有复盘和系统性修复的习惯”。