本文介绍了一套覆盖小游戏从选型、生产到上线迭代全链路的自迭代 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，经常让一个通用大模型反复决定下一步。这里面有多少事情，真的需要大模型完整的生成和推理能力？
本文探讨了“Loop engineering”这一理念，即工程师不再逐轮提示agent，而是设计包含读取状态、判断任务、执行操作、验证结果、记录状态和判断停止条件的自动化循环系统。文章详细拆解了支撑该系统的六大组件：负责唤醒的自动化机制、隔离并行的worktrees、沉淀项目知识的skills、接入外部工具的插件、分离读写职责的子agent以及确保状态持久化的记忆层。作者强调，loop engineering并非盲目追求全自动，而是通过明确输入输出、严格权限分层与成本控制来保障工程可靠性。工程师的角色从单轮操作者转变为循环机制的设计者与最终责任人，其核心价值在于利用可控的自动化杠杆加深对系统的理解，而非单纯甩锅给AI以逃避责任。
消耗一个 Token，意味着你购买的不是存储空间、计算次数或信息传输，而是模型对你的问题进行一次智力加工的服务。理解一句话、生成一段代码、做出一个判断，这些过去只有人类大脑才能完成的智力活动，现在第一次拥有了可精确计量的单位和可执行的价格。经济学家有一种识别产业革命的朴素方法：看计量单位。我们回顾历次重大的经济变革，会发现一个不起眼但至关重要的变化反复出现——一种新的计量单位的诞生。计量单位定义了什么东西可以被交易、被定价、被纳入经济体系。一旦某种模糊的产出被标准化度量，围绕它的定价、交易、竞争和制度就会自然浮现。
