早上九点，四个模型变成了三个

九点十四分，客服系统的意图识别开始报错。错误信息很短：model_not_found。前一天下班前这套流程还在正常跑，中间没有人改过配置，没有人动过密钥，发布系统里也没有任何变更记录。这套流程每天处理

从 测试能跑 到 敢扛活动 ：一次并发压测的复盘记录

活动前一周才想起来压测一个比较典型的节奏是：业务功能开发完成，日常流量下运行平稳，团队信心充足。直到市场侧通知下周有活动，流量可能翻几倍，才有人想起来——还没做过压测。于是临时组织压测。结果暴露的问题

队列长度设成并发数的 10 倍，超时条数只少了两条

2026-09-21 09:12:04.482 queue depth=120 limit=120 wait_p99=2840ms reject=0 timeout=612026-09-21 09:1

从模型清单到降级顺序：API 选型中的可用性核验

一个模型下线公告，导致四小时业务积压一个做合同审查的团队，业务侧核心流程依赖某款海外模型完成长文本结构化抽取。选型时评估了延迟、准确率、单价，最终锁定这一款。某天早上，调用开始返回 404。排查后发现

密钥轮换、对账接口与公告机制：API 选型中容易漏掉的三项

三套密钥体系，轮换周期各不相同一个做智能工单的团队，业务侧同时使用两家海外模型和一家国产模型。三家平台各自维护一套密钥体系：A 平台 90 天强制轮换，B 平台 180 天，C 平台按项目维度分配密钥

流式接口返回 200，但 content-type 是 application/json：一个被忽略

流式请求发出去了，HTTP 状态码 200，看起来一切正常。客户端按 SSE 解析，一个事件都解析不出来，最后拿到一段完整的 JSON。原因在响应头：content-type 是 applicatio

连接保活设了 30 秒，长连接还是被中间设备掐断

长连接空闲一段时间会被中间设备回收，这是常识。加了保活之后，连接依然被掐，而且掐断的时间点不固定，有时 60 秒，有时 300 秒。排查下来，保活包的间隔是 30 秒，但中间设备的空闲阈值是 60 秒

Agent 图工作流实战 从单体循环到可验证的 AI 自动化

提示词工程解决的是“如何把任务说清楚”；上下文工程解决的是“模型回答时能看到哪些资料”。这两者通常发生在一次调用内部。循环式 Agent 再向前走一步：模型可以调用工具、读取记忆、反复尝试，并自己决定

用 Python 搭建工具调用 Agent 的调试过程

我问这个工具调用 agent 一个不存在城市的天气，原本以为会先在地理编码工具里报错。结果更早失败的是模型请求本身，脚本直接抛了堆栈。后来我只加了一层 try/except，同样的坏输入就不再崩溃，而

告别 API Breaking Changes 噩梦：我是如何用 OpenCode 在 CI/CD

一、 背景与痛点：上游 API 的“突袭”与业务系统的猝死在自动化系统和多个资讯门户的日常运营中，我们的底层服务高度依赖各种第三方数据 API——从实时体育比分、游戏资讯接口，到天气预报和地理位置服务

如何用三段式确定性剪枝，为 LLM Agent 砍掉 35% 的 Token 成本？

在构建大模型（LLM） Agent 或长期对话系统的过程中，许多开发者都会遇到一个棘手的现象：随着对话轮数的增加，Prompt 会变得越来越“重”。起初系统运行得很顺畅，但到了数十轮交互之后，每次请求

新手学Agent开发必掌握的核心技术栈，精准不踩坑！

2026年，AI Agent 智能体开发已然成为技术圈的黄金赛道。但很多新手入门时都会陷入误区：把AI工作流拖拽搭建等同于智能体开发。前者是套用现成工具、拼接模板的浅层应用，可替代性极强、毫无技术壁垒