今日概览

今日六篇是同一主题的不同切面：Agent 工程化怎么从"提示词技巧"走向"可运行、可验证、可治理的工程循环"。两篇讲循环与框架的方法论（Loop engineering 把 agent 放进工程循环、腾讯 Harness 的记忆与验证闭环），一篇讲生产级落地（腾讯错误码治理 Agent 的单 Agent + Skill 编排），一篇讲知识工程（OpenViking 把散落文档编成 LLM-Wiki），两篇讲模型与算法侧（得物搜索的生成式召回、1.395 元复现 Jev 决策模型）。

今日重点

1. 1.395元复现Jev原型：百度千帆Token Plan最佳实践

TypeSafe AI 的 Jev 不做文本生成，而是通过单次前向传播直接输出带校准概率的结构化决策。百度用 Opencode 在 llama.cpp 里把"单次前向做结构化决策"实现成约 400 行 C++，全程由 AI 自主完成，总成本 1.395 元。

值得关注：

  • 机制改造：把 5 个业务问题打包进一个 Batch，直接对每个序列最后一个 Token 的 Logits 做 Softmax 提取，不生成任何字符串，一次 llama_decode() 同时完成全部推理与概率校准，响应缩到 70ms 级。
  • AI 全程自主：读懂概念 → 翻 llama.cpp 源码 → 写约 400 行 C++ → 修掉多序列 logits 位置索引偏移 → 编译调试 → 撰写文章，全部由 AI 完成；人只在关键节点验收和纠偏。
  • 成本对比：本次基于百度千帆 Token Plan 个人版消耗 313.9 积分，折合 1.395 元；文中对比按量计费模式下"用 GPT-4o 光是试错就可能花掉 20 多元"。
  • 关键澄清：置信度 ≠ 准确率。温度从 0.8 降到 0.3，action 的 deny 置信度从 62.5% 飙升到 89.4%，但那只是分布更尖锐；没有标注好的测试集就算不出准确率。低置信度本身是有用信号（情绪判断只有 55.9%），可用于路由到人工复核。
  • 交互方法论三步：给全部素材 + 明确交付物；指定验收标准（用真实业务场景测）；对技术结论做纠偏（“零幻觉"“校准概率"这类概念要工程化表述）。核心原则是"Agent 负责执行，人负责判断”。

来源：百度Geek说

2. Loop engineering：把 agent 放进工程循环

文章提出"循环工程”：工程师不再逐轮提示 agent，而是设计一个自动化循环系统——读取外部状态、判断下一步、执行、验证、写入状态、判断停止条件。人从每一轮的操作者，变成循环机制的设计者与最终责任人。

值得关注：

  • 六个必需动作：读取外部状态（CI/issue/PR/日志/用户反馈/代码 diff）→ 判断下一步（哪些值得处理、哪些忽略、哪些交给人）→ 执行 → 验证（测试/复现/浏览器检查/代码审查/安全扫描）→ 写入状态（结论、失败原因、已试方案、下一步，写到对话之外）→ 判断停止条件（继续/重试/换策略/升级给人/结束）。少了"写状态"就只是一次会话，少了"停止条件"就是烧 token 的定时器。
  • 六大支撑组件：automation（唤醒）、worktrees（隔离并行）、skills（沉淀项目知识）、plugins（接入外部工具）、subagents（分离读写职责）、memory（状态持久化）。
  • 四层关切的分工：prompt engineering 关心一句话怎么写，context engineering 关心给模型什么材料，harness engineering 关心工具/权限/运行环境，loop engineering 关心这些东西如何持续运转。Harness 是控制件（事前 guides + 事后 sensors），loop 是调度和闭环——只有调度没有控制件，就是定时犯错。
  • 生态佐证：Codex app 已有 automations/worktrees/skills/plugins/MCP/subagents/memories/Goal mode；Claude Code 有 scheduled tasks、/loop、goals、hooks、skills、subagents、worktrees、MCP。OpenAI Cookbook 的 agent improvement loop 用真实 traces 作输入证据；Amplitude 的 Ralph loop 每轮构建 opportunity → 用浏览器点通新功能 → 给功能埋点 → 每个 PR 附浏览器录制 GIF 作验证证据，后期只允许少数低风险机会类型自动合并，涉及用户数据的改动保留人工判断。
  • 定位提醒：loop engineering 的价值在于用可控的自动化杠杆加深对系统的理解，而不是给自动化换个名字、更不是把责任甩给 AI。

来源：大淘宝技术

3. 别再只卷向量检索了，得物交易搜索如何用"生成式"实现召回范式跃迁？

得物交易搜索团队把召回从"做选择题"改成"写答案"：不再从商品池里找最像的，而是让模型直接生成用户真正想要的结果。文章完整复盘从 LLM 语义索引到 HLLM、语义 ID 的技术路径。

值得关注：

  • 传统判别式检索的三个瓶颈：词汇鸿沟（“af1” vs “空军一号”、“yeezy” vs “椰子”）、长尾 Query 与冷启动商品因行为稀疏而乏力、以及"召回-粗排-精排"级联架构的天然信息漏斗——召回阶段漏掉的高价值商品，后续链路无力回天。
  • 语义索引增强的五条路：视觉理解（Qwen2.5-VL-7B + LoRA SFT 提取颜色/材质/设计细节，并用图文一致性二值判断抑制幻觉）、社区语料挖掘（Qwen3-4B 批量解析动态，捕获用户口语化语言）、商品关系推理（用 I2I 图谱把相似商品的属性"知识迁移"给稀疏商品，相当于高质量冷启动）、详情页 OCR（DeepSeek-OCR 提取 + Qwen3 规范化，把"看得见但搜不到"的规格参数纳入索引）、线上行为锚点（把后链路验证过的高频曝光 Q-I Pair 直接补进索引，相当于预设高命中率召回入口）。
  • 生成式召回三条突破路径：HLLM 分层大语言模型做深度语义表征、HSTU 做生成式行为序列建模、以及以语义 ID（SID）为核心的统一生成式召回。
  • 架构与展望：从级联走向"召粗一体"；下一步要解决跨场景/跨域生成式迁移（社区搜索、推荐流、商业化搜索的统一兴趣生成），以及生成式索引的实时性与增量学习——SID 码本目前以天/小时级更新，潮玩服饰每日数千上新场景需要秒级增量量化，同时避免码本漂移影响在线服务。

来源：得物技术

4. OpenViking × LLM-Wiki：让团队文档不再"各说各话"

文章从一个真实场景切入：客户问"这票货没保价，出问题怎么赔"，老王说 1 倍运费、小李的文档写 3 倍最高 1000 元、售后说要分产品——三个人三份正式材料三个答案，连 AI Agent 也只能给出多个带引用的口径，无法判断哪条适用于眼前这个客户。

值得关注：

  • 核心判断：团队缺的不是更多文档，而是一张能串起来的 Wiki 网络。Karpathy 在 2026 年 4 月提出 LLM-Wiki 范式——在原始资料和用户之间增加一层由 LLM 维护的持久化 Markdown Wiki；新资料进入后同步更新实体页、概念页、对比页，补充交叉引用，并标记新旧材料之间的矛盾。
  • 可追溯的知识链：先查客户 Wiki（采购了什么服务、属于哪种业务类型）→ 再查产品 Wiki（对应产品、线路、服务范围）→ 最后关联计费与赔付 Wiki（当前生效标准、适用条件与例外规则）。
  • 落地三步：① 导入——本地文件上传、网页/Git 仓库链接接入、飞书文档数据源同步，批量或定期可用 ov add-resource 配 --watch-interval；② Compile——用自定义 skill 或预置 LLM-Wiki skill，把原始数据按规则重新组织编译成 Wiki，产物回写 OpenViking 供团队查看、检索、复用；③ 接入——按接入指南为 Codex、TRAE 等 Agent 配置插件，访问同一套资源。
  • 自定义 Skill 只需先说清四件事：给谁用、按什么方式组织、哪些事实和条件必须保留、完成后如何检查。
  • 检索范式：层级式渐进读取——先看摘要与概述定位相关模块，再读具体文档详情，可显著节省检索 Token。

来源：字节跳动技术团队

5. 错误码排查从 3～8 小时到分钟级，Agent怎么做到的？

SRE 每天面对去重后数百个错误码告警：retcode 含义不清、调用链难追、运行时证据分散，人工排查一个需要 3～8 小时。腾讯基于智能体编排平台搭建错误码治理 Agent，把知识库、代码关系图谱、可观测平台、代码托管平台四类能力挂到同一个 Agent，分钟级产出根因与修复建议。

值得关注：

  • 架构选型：对比多 Agent 协作与单 Agent 挂载全部能力后选择后者——错误码排查更接近"根据上一步结果决定下一步"的渐进式探索（查到 handler 后追上游、日志显示限流后再确认错误码定义），单 Agent 上下文完整、便于交叉验证；再通过把完整排查流程、工具使用规则和输出约束沉淀进一个 Skill 来控制 Prompt 复杂度。
  • 关键工程约束：代码图谱检索路径固定为"业务仓库查询 → 未命中用 @ 多仓库模式 → 代码托管平台兜底"，避免逐仓库盲试；图谱调用预算从 5 次调到 15 次（5 次容易截断调用链分析，30 次容易超时）；可观测平台在 today_count 与 today_ret_pct 均非 0 时必须调用，时间窗用 error_context.date 而非默认最近 24 小时。
  • 评分与人机分工：知识库、代码定位、实际源码、运行时证据各计 1 分，3～4 分为 high、2 分 medium、0～1 分 low；错误码含义无法补全时置信度最高只能到 medium。代码托管变更信息不计分——知道谁改了代码不能直接推出根因。high 标注"建议采纳"、medium"参考需确认"、low 仅归档，P0/P1 例外推送；SRE 从"告警搬运工"升级为"修复建议审核员"。
  • 效果：50 条 case 对比中，优化后 action_type 与人工标注一致率从 66% 提升到 88%，硬冲突率从 20% 降至 0%；工作流为 11 个节点（含 Start/End）的双路径编排，通过条件分支处理无效输入、正常解析、解析失败三种情况。
  • 迭代机制：把具体失败抽象为通用约束反哺 Skill（不能在未查运行时证据前锁定根因、不能给混合故障的兜底码加白、不能在工具空返回后重复碰运气、不能只搜支持当前结论的证据），并用固化回归 case 守住基线。

来源：腾讯技术工程

6. AI写得快 ≠ 真正提效：一文讲清Harness"记忆"和"验证闭环"

作者踩的坑集中在三处：AI 没有记忆（每次新会话从零摸索链路、命名规则、上次的坑）、AI 改完就停（真正的交付还要验证、提交、等上线、确认线上生效）、AI 会犯错还自作主张（挑"看起来对"的接口、长链路里忘上下文、为结论好看缩小验证范围）。解法不是让 AI 更聪明，而是给它套上一套 Harness。

值得关注：

  • 知识库只有一个来源：会话复盘——任务结束后 AI 自己回顾全过程，把"代码里没有、要反复探索才能拼出来"的知识写成文档，落到两级索引。写入三条硬规则：只写三类内容（阴性知识、代码位置索引、隐含关联关系），代码里已写明的一律不写；新主题落到对应模块目录并在该模块 agents2.md 追加索引；一律"定点修改"，禁止整篇覆盖（覆盖会抹掉 frontmatter 里的成熟度与引用统计）。
  • 两级索引与固定读取顺序：agents.md（只列模块）→ <模块>/agents2.md（文档 + 一句话描述）→ 具体文档。即使知识库长到几百篇，也只读两三篇就命中，不会一上来就全文检索。读整篇用"定向读"只取正文，避免把 frontmatter 元数据拉进上下文。
  • 把"先查知识库再动手"变成硬约束：一个 PreToolUse hook 挂在所有探索类工具上（读文件、搜索、执行命令、MCP 调用），本会话没读过一级索引前一律拦下（exit 2）并提示先去读 agents.md；同时保留 rule 文本做软引导，两层并存。工具链（command/rule/hook 脚本）的源放在 vault 的 toolchain/，每次会话由 SessionStart 脚本自动同步到工作区——改一条规则下次会话就生效。
  • 性能细节：hook 是同步阻塞的，重量级同步放 SessionStart（每会话一次），PreToolUse 上只留轻量判定，否则每次工具调用都要付一遍启动开销。
  • 验证闭环与边界：优先做"等待 skill"——没有等待能力，AI 会在系统还没跑完时就去验证，闭环是假的；最后把"排查 → 编码 → 本地验证 → 提交/合入 → 等生效 → 线上验证 → 汇报"固化成一条 command，并写入"达上限就停、如实上报"的循环控制。适用边界：交付型任务（修 bug、做需求）用严格约束，探索型任务要放开；单点小改用 close-loop，改动面大才上 close-loop-team。

来源：腾讯云开发者

趋势观察

  1. Agent 工程化的重心从"怎么写提示词"转到"怎么设计循环" — Loop engineering、Harness 记忆与验证闭环、错误码 Agent 三条线讲的是同一件事：把状态、验证、权限和停止条件写进流程，而不是指望模型自觉。
  2. 约束要硬，不能靠提示词 — 腾讯用 PreToolUse hook 强制"先读知识库再动手"（读文件/搜索/执行/MCP 全被拦），错误码 Agent 用固定检索路径 + 15 次调用预算，都说明"写在提示词里"只是概率事件，必须做成绕不过去的机制。
  3. 结构化决策与结构化输出在被反复验证 — 1.395 元复现 Jev 证明"单次前向 + 概率输出"可行（但严格区分"置信度≠准确率"），得物把召回从"做选择题"改成"写答案"，方向一致：从生成文本转向生成可直接消费的结构。
  4. 知识沉淀的形态在升级 — 从"塞给 Agent 一堆文档"（OpenViking × LLM-Wiki 的 Wiki 网络）到"两级索引 + 会话复盘自生长"（腾讯 Harness），共同点是让知识可关联、可更新、可追溯，而不是静态资料堆。