一辆车从地面驶入隧道，网络从 5G 掉到 4G，再掉到无信号，出隧道又切回 5G。整个过程 40 秒。在车端日志里，这 40 秒是这样的：TCP 连接在信号衰减时卡在重传与内核超时退避里；等系统终于宣布连接死亡，车端 SDK 才开始重连——TCP 三次握手加 TLS 握手，在刚恢复的弱信号下又是若干次往返。加起来，这辆车有 8 秒 左右处于「物理上有网、业务上失联」的状态。更麻烦的在服务端：早高峰时段，几千辆车先后穿过同一段隧道，然后几乎同时向 Broker 发起重连。每次重连都要完整握手、鉴权、恢复订阅关系、清理旧连接状态。
本文讲述腾讯15年资深后台工程师，在 AI 时代如何入门大模型推理工程。全文围绕三条主线展开：从资深后台工程师到推理工程新人的抉择、推理工程的入门路径与自检方法、AI Infra 与通用 Infra 的同源与分野。
本文介绍了一套覆盖小游戏从选型、生产到上线迭代全链路的自迭代 Agent 系统。针对单点 AI 提效无法带动整体业务提速的痛点，该系统将分散的 AI 能力串联，由人定义北极星指标与行动边界并审核关键方案，AI 负责策略、开发与数据归因。架构上分为数据感知、运营 Agent、生产 Agent 及游戏基础工程等层级，通过 LangGraph 与 Claude Agent SDK 协同，实现多 Agent 上下文流转与决策闭环。实践表明，该系统两周内可上线 6 款小游戏，最快 2 天完成全流程；运营侧 12 款游戏迭代的正向率超 95%。未来计划将其扩展至更广义的互动玩法，打造可持续探索与优化的互动服务。
SRE 每天面对去重后数百个错误码告警：retcode 含义不清、调用链难追、运行时证据分散。人工排查一个错误码需要 3～8 小时不等，大量时间花在跨系统检索和上下文拼凑上，推给开发后往往还要再查一遍。我们基于智能体编排平台搭建了错误码治理 Agent：将知识库、代码关系图谱、可观测平台数据和代码托管平台四类能力挂载到同一个 Agent，由它自主编排排查流程，分钟级产出根因分析和修复建议。在 50 条 case 对比中，优化后的 action_type 与人工标注一致率从 66% 提升到 88%，硬冲突率从 20% 降至 0%。这篇文章重点分享三个实践：如何组织多源证据、如何让长链路排查稳定产出，以及如何用案例和回归评测持续迭代 Skill。
在电商搜索的演进历程中，“召回”始终是连接用户意图与海量商品的基石。长期以来，业界普遍采用“判别式检索”范式：无论是基于倒排索引的关键词匹配，还是基于ANN近邻检索的Embedding相似度计算，其核心逻辑都是在给定候选集中“寻找”最相似的结果。 然而，随着用户需求的日益多样化与口语化，传统范式在交易搜索场景中面临严峻挑战。基于关键词的倒排索引受限于“词汇鸿沟”，难以处理【“af1” vs “空军一号”，"yeezy" vs "椰子"】这类语义一致但字面不匹配的Query；而基于向量检索的判别模型，在长尾Query和冷启动商品场景下，往往因行为数据稀疏而表现乏力。此外，传统的“召回-粗排-精排”级联架构存在天然的信息漏斗，一旦高价值商品在召回阶段被遗漏，后续链路将无力回天。 过去一年，得物交易搜索团队核心目标是打破这一僵局。我们不再满足于让模型做“选择题”，而是尝试赋予模型“创造力”。我们将生成式建模（Generative Modeling）引入召回场景，探索从“检索”到“生成”的范式跃迁，并围绕大语言模型、多模态表征及序列建模展开了一系列算法研发。
最近看到了一个挺有意思的东西，就是TypeSafe AI 做的 Jev。Reddit 上很多人用它玩 DOOM，也有人拿它玩 Mario。我申请之后，拿到 API Key 后，也做了一个网页小游戏，想看看它到底在里面起什么作用。一开始，我最想弄清楚的其实很简单：同样是让 AI 操作游戏，为什么要用 Jev？GPT 不能做吗？当然能。做完这个 demo，再看了一圈资料，我觉得可能值得讨论的是另一个问题：我们现在搭 Agent，经常让一个通用大模型反复决定下一步。这里面有多少事情，真的需要大模型完整的生成和推理能力？
